From exim@www1.ietf.org Mon Mar 1 00:23:19 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05312 for ; Mon, 1 Mar 2004 00:23:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxftE-0004b0-Af for mip6-archive@odin.ietf.org; Mon, 01 Mar 2004 00:22:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i215MqLZ017660 for mip6-archive@odin.ietf.org; Mon, 1 Mar 2004 00:22:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxftE-0004al-6T for mip6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 00:22:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05252 for ; Mon, 1 Mar 2004 00:22:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxftB-0001lL-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 00:22:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxfsK-0001cF-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 00:21:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxfrQ-0001Si-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 00:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxfrR-0004O3-V1; Mon, 01 Mar 2004 00:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axfqr-0004GH-4w for mip6@optimus.ietf.org; Mon, 01 Mar 2004 00:20:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05059 for ; Mon, 1 Mar 2004 00:20:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axfqo-0001O3-00 for mip6@ietf.org; Mon, 01 Mar 2004 00:20:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axfpr-0001HL-00 for mip6@ietf.org; Mon, 01 Mar 2004 00:19:24 -0500 Received: from mac-0-40-96-34-df-d2.dhcp.ietf59.or.kr ([218.37.226.227] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Axfoq-0001Au-00; Mon, 01 Mar 2004 00:18:21 -0500 Received: from chardonnay ([127.0.0.1] helo=chardonnay.local.levkowetz.com) by chardonnay.local.levkowetz.com with smtp (Exim 3.36 #1 (Debian)) id 1Axfon-0004yI-00; Mon, 01 Mar 2004 06:18:17 +0100 Date: Mon, 1 Mar 2004 06:18:17 +0100 From: Henrik Levkowetz To: mip4@ietf.org, mip6@ietf.org Message-Id: <20040301061817.6bcecbab.henrik@levkowetz.com> In-Reply-To: <20040225023657.260676cd.henrik@levkowetz.com> References: <20040225023657.260676cd.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Mon__1_Mar_2004_06_18_17_+0100_Wobcbpcqzg2MlGYt" Subject: [Mip6] Re: [Mip4] REVISED: MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 --Signature=_Mon__1_Mar_2004_06_18_17_+0100_Wobcbpcqzg2MlGYt Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit I've gotten a bit of pusback about the early hour of the bar-bof, so the time has been changed: REVISED Bar-bof details: Monday evening 22:00 - in the seating area outside Emerald. Possibly we can use Emerald if more people turn up than the area can hold. Henrik Wednesday 25 February 2004, Henrik Levkowetz wrote: > > Proposal of a bar-bof > --------------------- > > With the coming (we hope) of heterogenous deployment of IPv4 and IPv6 > access and transport networks, and Mobile Nodes with MIPv4 and/or MIPv6 > capability and IPv4 and/or IPv6 stacks, the question has been raised > of how to best run Mobile IP in such circumstances, and some solutions > has been proposed. > > The "trivial cases" of MIP4 carrying IPv4 in an all-IPv4 network, and > MIP6 carrying IPv6 in an all-IPv6 network are covered in the MIPv4 and > MIPv6 standards. But by one way of counting, that still leaves about 6 > combinations (14 if you count NAT-PT versions) which may occur in > practice which are not covered by the current standards. A number of > drafts (some mentioned below) has been written, proposing solutions > to some of these cases. > > Some cases may be handled without any additional MIP work if other > transition mechanisms such as e.g. ISATAP is available, but as a Mobile > Node may be expected to come across all conceivable kinds of visited > networks, it cannot rely on any particular other transition mechanism > being in place. > > Below is a list of possible combinations of Host IP stack version, MIP > client/agent version and transport network IP version, followed by a > short summary of my understanding of where the current and proposed > solutions fit in. There exist 8 similar combinations using NAT-PT > which are not explicitly listed here. > > Which solutions will be needed? Which should we work on? How much > interest does this have currently? > > We plan to hold a bar-bof in Seoul, to see how many show up, and what > kind of interest there is in this subject. Place will be announced > on the lists Monday March 1st, and in the MIP4 and MIP6 sessions. > > Henrik > > > > Table of MIP4/6-IP4/6 combinations: > =================================== > > # MN's MIP Access Transpt Short description > IP-stack Client Net & HA if. > --- -------- ------ ------ ------- ----------------- > 1 IPv4 MIP v4 IP v4 v4 "native MIPv4" > 2 IPv6 " " v4 "IPv6 in MIPv4" > > 3 IPv4 MIP v6 " v4 "IPv4 in MIPv6 over IPv4" > 4 IPv6 " " v4 "MIPv6 over IPv4" > > 5 IPv4 MIP v4 IP v6 v6 "MIPv4 over IPv6" > 6 IPv6 " " v6 "IPv6 in MIPv4 over IPv6" > > 7 IPv4 MIP v6 " v6 "IPv4 in MIPv6" > 8 IPv6 " " v6 "native MIPv6" > --- -------- ------ ------ ------- ----------------- > > Variant 1 is the native IP/MIP combination for v4 > > Variant 2 would be supported by the MIPv4 signalling extensions proposed in > draft-tsirtsis-v4v6-mipv4-00.txt > > Variant 5 is known to be supported by an experimental thesis implementation > and is fairly simple > > Variant 6 is known to be supported by an experimental thesis implementation > and is fairly simple > > Variant 7 would be supported by the MIPv6 signalling extensions proposed in > draft-soliman-v4v6-mipv4-00.txt > > Variant 8 is the native IP/MIP combination for v6 > > > > --Signature=_Mon__1_Mar_2004_06_18_17_+0100_Wobcbpcqzg2MlGYt Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQseZeVhrtTJkXCMRAh3cAJ0emUOyIq9apB+g/79c+xNmwFtf5ACdFujZ h/nMne1IpJsTMwfshW0rEd0= =Ucpc -----END PGP SIGNATURE----- --Signature=_Mon__1_Mar_2004_06_18_17_+0100_Wobcbpcqzg2MlGYt-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 1 01:06:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08051 for ; Mon, 1 Mar 2004 01:06:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgYU-0001Yg-Vw for mip6-archive@odin.ietf.org; Mon, 01 Mar 2004 01:05:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2165UKt005989 for mip6-archive@odin.ietf.org; Mon, 1 Mar 2004 01:05:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgYU-0001YW-RP for mip6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 01:05:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08028 for ; Mon, 1 Mar 2004 01:05:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgYS-0006Vt-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 01:05:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgXW-0006Qh-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 01:04:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxgX1-0006Ln-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 01:03:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgX2-0001GM-Md; Mon, 01 Mar 2004 01:04:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxgWT-0001FI-0P for mip6@optimus.ietf.org; Mon, 01 Mar 2004 01:03:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07934 for ; Mon, 1 Mar 2004 01:03:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxgWQ-0006K6-00 for mip6@ietf.org; Mon, 01 Mar 2004 01:03:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxgVS-0006Eg-00 for mip6@ietf.org; Mon, 01 Mar 2004 01:02:23 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AxgUX-00064c-00 for mip6@ietf.org; Mon, 01 Mar 2004 01:01:25 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i2160mw07307; Mon, 1 Mar 2004 07:00:49 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i2160mSj053082; Mon, 1 Mar 2004 07:00:48 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403010600.i2160mSj053082@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: mip6@ietf.org, James Kempf Subject: Re: [Mip6] bootstrap problem definition In-reply-to: Your message of Sat, 28 Feb 2004 14:26:47 +0200. <40408907.7000805@kolumbus.fi> Date: Mon, 01 Mar 2004 07:00:48 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In your previous mail you wrote: > - dynamic home agent address discovery is a security nightmare: I agree > we should not rely on it. I agree that its a security problem, but its also possible that a future protocol would be capable of providing home agent discovery without the problems ;-) => IMHO this future protocol will at least take a long time to appear... > - (3.1.1. Dyn H@ Assignment) dynamically assigned is not the opposite > of statically configurated. And there are known extensions (widely > implemented but not standardized) of IKEv1 to support dynamically > assigned "internal" addresses. Ok. In IKEv2 this supposed to change, as there will be a standard. => the draft is clearly about IKEv1 only. Once more you have to have policy entries in place. => in fact this argument is not true: many IKE implementations support dynamic policy entries which are built according the negociated traffic selectors and authorization, or, perhaps even more common, according the assigned "internal" address of the mobile initiator. > - (3.2.1 AAA) Even I agree that IKE should be clearly integrated with > an AAA system your statement that it can work only with certificates > is not true. Our text is too unclear here. I'm not even myself sure what this sentence meant. But I think we can agree on the following: - It would be desireable to integrate a MIPv6 home agent security system with AAA (on an optional basis; end-to-end security should still be possible) => Ok but I don't understand the parenthesis. - AAA integration in IKEv1 is generally non-existent or at least non-standardized. => I strongly disagree: all IKEv1 implementations for VPN are integrated with a AAA system. Don't believe that the market didn't require this! - AAA integration in IKEv2 should work at least if EAP authentication is used. There's currently no "IKEv2 AAA" application defined, but I think RFC 3579 (RADIUS EAP) or draft-ietf-aaa-eap-04.txt (Diameter EAP) should work. One caveat: I'm not sure we have defined link layer or service type for IPsec gateways anywhere. But that's a small detail. => I can look at our local IPsec VPN server. There is a RADIUS interface but I don't know what it uses (this is a Cisco, it should be proprietary extensions :-). > - (3.2.2 Opp/Local discovery) The idea of using the DNS to get infos > about the home was in a very old message of someone from Digital > in this list (I can grep into my archive to find the reference). Please do! => perhaps there is something older but I got: > Date: Mon, 10 Apr 2000 09:15:28 -0400 > To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM > From: "Powell, Ken" > Subject: [MOBILE-IP] Mobile IPv6 questions >... > Message-ID: > - (4. scenarios) The first scenario (no pre-existing relationship) > has a little chance to work with IKEv1 which requires strong > mutual authentication and authorization. Well, there's always opportunistic IPsec. => OE (Opportunistic Encryption) uses DNSSEC to solve this problem. But I agree its in general unworkable with the combination of MIPv6 and IKE, for reasons that we stated in the draft. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 1 02:09:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16621 for ; Mon, 1 Mar 2004 02:09:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhXZ-0001uP-E1 for mip6-archive@odin.ietf.org; Mon, 01 Mar 2004 02:08:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2178bio007313 for mip6-archive@odin.ietf.org; Mon, 1 Mar 2004 02:08:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhXY-0001te-GH for mip6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 02:08:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16286 for ; Mon, 1 Mar 2004 02:08:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhXU-0004dr-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 02:08:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhWn-0004Yd-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 02:07:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxhW6-0004SZ-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 02:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhW2-00015T-4G; Mon, 01 Mar 2004 02:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxhVY-0000u2-7N for mip6@optimus.ietf.org; Mon, 01 Mar 2004 02:06:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14926 for ; Mon, 1 Mar 2004 02:06:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxhVU-0004Ok-00 for mip6@ietf.org; Mon, 01 Mar 2004 02:06:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxhUV-0004H2-00 for mip6@ietf.org; Mon, 01 Mar 2004 02:05:28 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AxhTg-000446-00 for mip6@ietf.org; Mon, 01 Mar 2004 02:04:36 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i21740w10009; Mon, 1 Mar 2004 08:04:00 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i21740Sj053204; Mon, 1 Mar 2004 08:04:00 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403010704.i21740Sj053204@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Ed Remmell" cc: mip6@ietf.org, "Odile@Treck" , "Jimmy Zhang" Subject: Re: [Mip6] MIPv6 issue (IPsec/IKE interaction) In-reply-to: Your message of Fri, 27 Feb 2004 13:49:45 PST. <000001c3fd7b$9dd93b50$0700a8c0@eremmell> Date: Mon, 01 Mar 2004 08:04:00 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In your previous mail you wrote: We saw an interesting problem occur when we tested MIPv6 with IPsec/IKE: when the MN does a L3 move at the start of phase 2 SA negotiation with the HA, IKE Quick Mode does not complete. => IKE is supposed to recover on timeouts even usually it takes time. It may be our problem, it may be a spec issue. In any case, it is probably a good MIPv6 interop scenario. Please refer to attached packet capture "quickModeFailsAfterMove.pcap" which has filtered out everything except for the IKE messages. We saw this issue happen during our testing, because we set the policy lifetime (in seconds) to 120 seconds, the phase 1 ISAKMP and phase 2 IPsec SAs were re-keyed very frequently (every 90 seconds or so). => with such aggressive timings you should use very short timeouts too! When we tested, we had the MN register with the HA from a foreign link (K-bit in BU set to 1), this setup the phase 1 ISAKMP and phase 2 IPsec SAs between the MN and HA. Then we had the MN move home. The SAs are maintained while the MN is home. Then we had KameCN start a FTP MGET of a large file from the MN (MN is FTP server). During this FTP, we had the MN move to foreign link. Refer to packet #7 in "quickModeFailsAfterMove.pcap", what is happening is that the MN is rekeying its phase 2 IPsec SAs (Quick Mode exachange), but it starts this *AFTER* it has moved to the foreign link so it is sending these from its care-of address 3ffe:ffff::20b:dbff:ffe94:83fc. The HA doesn't have any phase 1 ISAKMP SA associated with that care-of address, instead it has one associated with the MN's home address 3ffe:aaaa::bbbb (see packets #3-5) which was re-keyed while the MN was at home. So, the HA doesn't recognize these Quick Mode packets sent by the MN (because it hasn't yet received any BU K=1 from the MN); the MN retransmits Quick Mode (packets# 8-10) but the HA does not respond. Eventually the MN will timeout Quick Mode, and recover by re-keying the phase 1 ISAKMP SA. But, this can take a long time (2 minutes or so). => I can see two problems in your IKE implementation: - recovering takes too long time (same order than SA lifetimes) - it doesn't detect the address mismatch, i.e., it sees different addresses and just drops messages (it should not process them blindly but should not simply drop them). BTW, we used our own HA-Lite simulator for this testing, because we are unaware of any open source MIPv6 HA that supports IPsec/IKE that we can use to test against. => KAME/FreeBSD Mobile IPv6 + racoon can be adapted to HA and they are open source. IMHO the main issue is the KAME/FreeBSD kernel moves IPsec SAs and SPDs without a warning to IKE but this can be easily fixed. The BU must be protected using IPsec, so the IKE must complete first before it can be sent. It seems that in this scenario the MN should be able to use the old phase 2 IPsec SAs it had at home to protect the BU, to be able to register with the HA from the foreign link without needing to wait for Quick Mode to complete successfully. => as this SA pair doesn't move (the initiator selector is the home address) you should use a long term SA pair and you can use it as soon as it is established at the first time. But, for some reason it didn't send the BU to the HA. => this looks like a bug... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 1 05:58:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09578 for ; Mon, 1 Mar 2004 05:58:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl7R-0005kR-Gt for mip6-archive@odin.ietf.org; Mon, 01 Mar 2004 05:57:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21AvrUB022094 for mip6-archive@odin.ietf.org; Mon, 1 Mar 2004 05:57:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl7R-0005kH-Bw for mip6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 05:57:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09538 for ; Mon, 1 Mar 2004 05:57:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axl7N-0005XR-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 05:57:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axl6S-0005Pf-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 05:56:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axl5d-0005IZ-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 05:56:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl5f-0005Pu-8B; Mon, 01 Mar 2004 05:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axl4p-0005K1-NR for mip6@optimus.ietf.org; Mon, 01 Mar 2004 05:55:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09319 for ; Mon, 1 Mar 2004 05:55:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axl4l-0005A1-00 for mip6@ietf.org; Mon, 01 Mar 2004 05:55:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axl3h-0004wf-00 for mip6@ietf.org; Mon, 01 Mar 2004 05:54:02 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1Axl2N-0004af-00 for mip6@ietf.org; Mon, 01 Mar 2004 05:52:39 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTW00D048UXNA@mailout2.samsung.com> for mip6@ietf.org; Mon, 01 Mar 2004 19:52:09 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTW00AOL8UXJ8@mailout2.samsung.com> for mip6@ietf.org; Mon, 01 Mar 2004 19:52:09 +0900 (KST) Received: from Alperyegin ([124.233.210.1]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HTW00KJS8UVD3@mmp2.samsung.com> for mip6@ietf.org; Mon, 01 Mar 2004 19:52:09 +0900 (KST) Date: Mon, 01 Mar 2004 02:52:08 -0800 From: Alper Yegin Subject: RE: [Mip6] Comments on kempf-mip6-bootstrap In-reply-to: <01ea01c3ff27$8f154890$3e6015ac@dclkempt40> To: "'James Kempf'" , mip6@ietf.org Message-id: <000101c3ff7b$3f004b30$e3e025da@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT > > What is the accounting issue? HA should simply collect some counters, > > and any centralized accounting server should be able to query HA via > > SNMP. > > > > Sure. But it might be cleaner for the HA to be able to issue its own > accounting records directly into the AAA system, as opposed to using a > gateway. Fewer moving parts. There is no 3rd party necessarily in my approach. What you call "AAA system" is my "centralized accounting server". > > I think this is a different discussion than what this I-D should be > > addressing. We should discuss it under another thread. > > > > OK. But, isn't there a connection? The HA might want to use IKEv2 to check > auth/authz for mobility service via the AAA system. Sure, this is "AAA for Mobile IPv6 service". My point was, there is one other level of integration, basically bundling "AAA for Mobile IPv6 service" with "AAA for network access service". This is what 3GPP2 did with Mobile IPv4. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 1 07:52:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16014 for ; Mon, 1 Mar 2004 07:52:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmtw-000890-12 for mip6-archive@odin.ietf.org; Mon, 01 Mar 2004 07:52:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Cq3pG031283 for mip6-archive@odin.ietf.org; Mon, 1 Mar 2004 07:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmtu-00088Q-0h for mip6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 07:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15913 for ; Mon, 1 Mar 2004 07:51:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axmtt-0002uw-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 07:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxmsL-0002XZ-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 07:50:26 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Axmqr-0002Ci-01 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 07:48:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Axmdl-0005zE-96 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 07:35:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxmdT-0005lu-8U; Mon, 01 Mar 2004 07:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxmdA-0005kg-80 for mip6@optimus.ietf.org; Mon, 01 Mar 2004 07:34:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14886 for ; Mon, 1 Mar 2004 07:34:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axmd9-0000g3-00 for mip6@ietf.org; Mon, 01 Mar 2004 07:34:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxmcH-0000Yk-00 for mip6@ietf.org; Mon, 01 Mar 2004 07:33:51 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AxmbT-0000ML-00 for mip6@ietf.org; Mon, 01 Mar 2004 07:32:59 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i21CTCw02574; Mon, 1 Mar 2004 13:29:12 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i21CTCSj054045; Mon, 1 Mar 2004 13:29:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403011229.i21CTCSj054045@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: mip6@ietf.org, Wassim Haddad Subject: Re: [Mip6] comments on draft-haddad-mipv6-omipv6-01.txt In-reply-to: Your message of Mon, 01 Mar 2004 05:44:32 +0200. <4042B1A0.3050307@kolumbus.fi> Date: Mon, 01 Mar 2004 13:29:12 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 In your previous mail you wrote: But you mention that your intent is to provide a more secure signaling scheme than RR is. => in fact OMIPv6 is not more or less secure than the initial mechanism, RR today or any replacement in the future. OMIPv6 plays with the PBK trade-off, i.e., narrower window of vulnerability and longer impact of successful attack. But OMIPv6 is really optimized, i.e., it gives better performance (a RTT per renew or movement). However (and perhaps I'm missing something obvious), it seems that the proposed use of Diffie-Hellman has security impacts which actually make it less secure than standard RR. => I disagree: the security level is the same (i.e., it is poor but this another issue :-). My concerns are listed below; after that there are some suggested modifications which can make your protocol more secure. "Kilroy was here first" -attack If I have understood correctly, in OMIPv6, any change to the binding cache must be authenticated via the derived shared secret. It is even not possible to rerun RR and OMIPv6 without proving the possession of the shared secret. => this is required because if an RR can be rerun at any time an attacker who missed the vulnerability window has just to restart the whole stuff from the beginning. (more about recovery after) As a result, once a shared secret is established, it is hard for other parties to change the binding. This is normally a positive thing, => this is and RR should have this: without this you can't even speak about a vulnerability *window*... however, it becomes negative if it happens that the initial DH exchange was compromised and is now in control of the binding. It can perhaps be argued that this attack is hard, because the attacker would have to be both on the mobile node - correspondent node and home agent - correspondent node paths. => this is the trade-off and as a trade-off it has advantages and disadvantages. However, there is another attack, much more serious that can be executed easily [draft-aura]. More specifically, an attacker can initiate an RR and DH exchange all by himself, without compromising any ongoing legitimate exchange. If the attacker does this before the mobile node in question has established the binding, the mobile node can no longer communicate with the correspondent node at all. Moreover, all the communications from the correspondent node intended to the mobile node go to a location selected by the attacker. => this is the counter part to be immune to the fake RR attack at any time, i.e., with current RR when an attacker wants to mess communications between a mobile node and a correspondent it can initiate a new RR and redirect the traffic to the hell. The only defense for the mobile node, in the case it understands what's happen, is to enter in a race with the attacker. In order to execute this attack, one needs to defeat the RR protocol. => if your hidden argument is that OMIPv6 is more interesting with a stronger mechanism than RR I agree... But this only requires presence on the path from the home agent to the correspondent node. It is not an issue in RR, since nodes that are on that path can perform equally bad attacks anyway and RR limits the vulnerability by requiring that the attack is all the time on this path. With OMIPv6, the attacker would no longer need to be on the path permanently, only once. => this is *again* the trade-off... And if you'd like to use shorter lifetime for OMIPv6 you'll get more vulnerability windows. Perhaps you'd like to adapt the OMIPv6 lifetime to the strength of the initial mechanism? This attack is particularly dangerous for non-mobile nodes. One would normally not assume that hosts without Mobile IPv6 support are vulnerable to problems in Mobile IPv6. => so one should bann RR which has this unfortunate property. However, when the correspondent node supports OMIPv6, an attacker who is at least temporarily on the path between the victim and the correspondent node can now cause the victim's traffic to be permanently redirected (the attacker may have to refresh => s/permanently/for a longer time/ the binding now and then, but he no longer has to be on the path). For instance, an attacker who temporarily visits an office Wireless LAN could set up an OMIPv6-protected binding at www.cnn.com for the office proxy server. As a result, all communications between the proxy server and the www server would fail. => the attack is harder but has when it successful a longer impact... This vulnerability is serious, because a temporary problem expands into a more permanent problem, and can affect any IPv6 node even without Mobile IPv6 support. => I agree for the first statement (with something weaker than permanent) but not for the second which already stands for RR. "Recovery mechanism" -attack Nodes can reboot and forget their state, => IMHO the best is to use stable storage because I don't want to require longer reboot delays (:-). Note that there are some protocols to solve this problem, even with very weak assumptions as in RR. or get an address that someone else was using a while ago. => mobile nodes are supposed to delete previous bindings so there is another condition for this case which is already so unlikely that IMHO it should happen only during attacks. As discussed in [draft-aura], it is necessary to have a recovery mechanism. In essence, such recovery mechanism should be able to undo an OMIPv6-protected binding. For instance, a persistent ICMP error could lead to the correspondent node into believing that the binding is invalid. => the example is just to give a very poor mechanism, isn't it? (:-) Unfortunately, such recovery mechanisms can be exploited by attackers, making it possible to undo a legitimately created OMIPv6-protected binding, and create a new one in place (for instance in the method discussed in the previous section). => so any weak recovery mechanism should be associated with an hold-down, i.e., the correspondent must forbid the creation of a new binding via a restart of the whole stuff during a reasonable delay. There is no hold-down in Mobile IPv6, perhaps we should add this in order to mitigate some attacks? OMIPv6 is currently missing a recovery mechanism, however. Perhaps it can be designed in a way that there is no attack. => I propose stable storage when it is possible for the mobile node side and hold-down against restarts when a binding is detected as being broken for the correspondent node side. Summary While the first attack described above is similar to the one that exists in RR, its results are worse than in OMIPv6. => worse results/harder attacks Findings in [draft-aura] make it hard to see an easy way to fix this; basically a "leap-of-faith" or PBK like approach does not sound suitable for the RO problem, even if they can be successfully used in, e.g., application layer protocols. => please note that PBKs were introduced in the RO context so this is your personal opinion only. The basic problem is that there is no user confirmation about making the leap of faith, leading to the possibility of the attacker doing the operation before you. => and the basic advantage is the attacker has to be before you. Then again, I could be missing something. Let me know what. Possible suggestions on how to improve the security of your approach: - In [draft-roe] we proposed a scheme that incorporated Diffie-Hellman which did not rely _just_ on the RR as its initial authentication. => OMIPv6 doesn't rely just on RR, it just uses what is available which is RR today. Instead, it used a combination of RR and CGA tests. I don't remember => please either give a free license for CGAs to everybody or avoid to use them. if we actually eliminated all but the first home test messages; it seems that at least some optimization is possible there even if we didn't do in the draft. => this is well known that stronger mechanisms than RR exist but: - some of them already provide long term protection - none is standardized for RO. I think we are going to need something like this, maybe not exactly the same proposal, but something better than RR if the Kbm is to be made more permanent. => see before. And with the stronger proposed mechanism, IPsec, the lifetime can be unbound (still less than permanent :-). - While avoiding security infrastructure and configuration is indeed very much desired, I would note that a DH authenticated by a pre-configured shared key between the home agent (or mobile node) and correspondent node would NOT be vulnerable to issues that I described above. => with a pre-configured shared secret between the mobile node and the correspondent node there is no reason not to jump to IPsec. About the home agent I'd like to see a reason to trust it more than somebody else... Similarly, AAA could be used to authenticate the D-H somehow. I think this is what [draft-le] did. => an AAA infrastructure covering the mobile and correspondent nodes is a very strong assumption. And in this case you can again jump to IPsec... - If RR as initial authentication for D-H is deemed sufficient, there would be simpler protocols that would accomplish what you want to do. As you know, unauthenticated Diffie-Hellman is vulnerable to MiTM attacks by active attackers. => this is why OMIPv6 is using another mechanism to provide authentication. Today it is RR so OMIPv6 is as good/poor as RR. It seems that this holds true of RR itself as well; nothing is gained by attackers who just eavesdrop; they have to at least send the Binding Update. => yes, RR is not so poor! (:-) So, if RR as initial authentication was deemed sufficient, it would seem that simply using RR-derived Kbm as the long-term key would be sufficient, and no D-H would be needed. => (assuming you are not joking) D-H has stronger security properties, for instance the shared secret can't be computed from messages so you have PFS and even more... - I won't comment here about skipping care-of address tests as there are other threads in this mailing list about that. But I think something along the lines of draft-vogt sounds promising to reduce the signaling delays related to care-of address tests. => someone proposed to add a *delayed* binding complete message to OMIPv6. Perhaps this will make you happy... BTW this adds no real security too. Some other notes: > and a correspondent node (CN). Such mode is efficient, but it > raises many security concerns and generates an excessive amount > of redundant mobility signaling messages. As I have said before on the list in other contexts, IMHO it would be good if people who feel there are significant issues would document these issues and make it possible for the rest of us to review the findings. Existing analysis in e.g. draft-nikander and in the old design team notes points to very similar risks that exist for on-path attackers anyway. => direct reflection attacks are easier than (mis)using mobile IPv6 RO and there are still some people which are afraid when you'd like to remove/delayed/etc the care-of test... (:-) > long shared secret Hmm... I think the length is not the issue here. Generally in cryptography we feel relatively safe after a certain key length. In base MIPv6, this is 20 octets for the Kbm. I don't think we need more. => there are two reasons to be long: - long enough to be immune to the brute force attack - each time you use a secret you reveal something about it, i.e., you consume its entropy. The 20 octets of the Kbm are used in a very small number of times, this is not the case for the Kabm even IMHO you should not have to refresh it (by a new D-H exchange signed by the previous Kabm). What may be more relevant, however, is *how* you get those key octets => I don't believe there can be an issue about this. and how much security that procedure offers. => this is the point. As I explain at the beginning IMHO the security of the initial mechanism (RR currently) and OMIPv6 are exactly the same from the authentication point of view. > In order to reduce the handover latency, the MN will send the > BU on the direct path immediately after receiving a BA message > from its HA. Note that the MN MAY duplicate the BU message and > send a copy on the path going via its HA. Only one copy is > enough to update the CN's binding cache entry. In this case, > the BU sent via the HA MUST have the same sequence number than > the one sent via the direct path. I didn't quite get this. If the sequence numbers are the same, won't the other BU be dropped. Why would then want to send two? Can you explain? => two paths are available, the same BU is sent over both paths, one should win the race and update the binding, the other one should arrive after and will be dropped as it is recognized as a dupplicate. There are two advantages: - resulting delay is the min of both path delays - there is a lower chance that both BUs are lost (maths show that the lost probability for both is between the min and the product of individual lost probabilities). My rationale is one should use all the possible paths when they are in a reasonable number and likely to be reasonably independent. References => A URL to an "all I-D" repository (like watersprings) and the "expired" mention are enough. [draft-le] draft-le-mobileip-dh-01.txt, expired => I can send it to you (I keep Frank's draft because he was a student of my school :-). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 1 07:57:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16362 for ; Mon, 1 Mar 2004 07:57:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmyd-00005X-57 for mip6-archive@odin.ietf.org; Mon, 01 Mar 2004 07:56:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Cuteg000333 for mip6-archive@odin.ietf.org; Mon, 1 Mar 2004 07:56:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmyc-00005I-Ue for mip6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 07:56:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16339 for ; Mon, 1 Mar 2004 07:56:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axmyc-0003m3-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 07:56:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axmxf-0003fK-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 07:55:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axmwx-0003Xx-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 07:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axmwo-0008LS-TP; Mon, 01 Mar 2004 07:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxmwQ-0008Ju-8v for mip6@optimus.ietf.org; Mon, 01 Mar 2004 07:54:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16208 for ; Mon, 1 Mar 2004 07:54:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxmwP-0003Qr-00 for mip6@ietf.org; Mon, 01 Mar 2004 07:54:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxmvA-0003Bj-00 for mip6@ietf.org; Mon, 01 Mar 2004 07:53:21 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1AxmuC-0002xx-00 for mip6@ietf.org; Mon, 01 Mar 2004 07:52:20 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 1 Mar 2004 13:51:12 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 1 Mar 2004 13:51:11 +0100 Message-ID: Thread-Topic: [DNA] Current IETF-Draft version - POLIMAND Thread-Index: AcP/LnYGYyv1qgefSh++D/u64xWYQgAWgRuw From: "NJEDJOU Eric FTRD/DMR/REN" To: "Pekka Nikander" , "Stefan Aust" , Cc: =?iso-8859-1?Q?Carmelita_G=F6rg?= , "Niko A. Fikouras" , "Cornel Pampu" , "Dna" , "Greg Daley" , X-OriginalArrivalTime: 01 Mar 2004 12:51:12.0344 (UTC) FILETIME=[E0325D80:01C3FF8B] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] RE : [DNA] Current IETF-Draft version - POLIMAND Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Pekka, The problem with MIP6 movement detection handover optimizations (see = http://www.ietf.ord/I-D/draft-daniel-mip6-optimized-vertical-handover-00.= txt for another draft) is that it is being considered out of scope for = DNA because of the mobile IPv6 issue raised and out of scope for MIP6 = because of the link triggers that has to be taken into account. = Actually, it is within the scope of both as=20 DNA -link triggers/hints that will be catalogued/standardized within DNA = will also be used for Mobile IPv6 optimised movement detection. Other = ones may be needed for this specific purpose. Better detecting network = attchment/detachment is a requirement for Mobile IPv6 better performance = movement detection and handover. These issues are therefore strongly = linked.=20 MIP6 -Optimized movement detection an handover schemes are essenttial = for base Mobile IPv6 Operation, which means, the protocol operation = needs exploiting L2 triggers/hints. And MIPv6 implementors use L2 = triggers/hints in a confusing way, if not at all. We could be ping-ponging betwwen these two groups for years. Eric -----Message d'origine----- De : owner-dna@ecselists.eng.monash.edu.au = [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de Pekka = Nikander Envoy=E9 : lundi 1 mars 2004 02:21 =C0 : Stefan Aust Cc : Carmelita G=F6rg; Niko A. Fikouras; Cornel Pampu; Dna; Greg Daley Objet : Re: [DNA] Current IETF-Draft version - POLIMAND Stefan, > http://www.ietf.org/internet-drafts/draft-iponair-dna-polimand-01.txt I had a quick look at this draft. It is certainly interesting, but = looking at our current charter, it seems to be out of scope. Hence, I = would suggest you to consider continuing this work somewhere else, = perhaps in the outskirts of the mobopts RG or the mip6 wg. There may be = some aspects that, in the end of the day, are relevant to DNA, but they = should be separate from the mobile IP specific considerations. --Pekka _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 1 12:57:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24743 for ; Mon, 1 Mar 2004 12:57:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrf6-0005E9-IF for mip6-archive@odin.ietf.org; Mon, 01 Mar 2004 12:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21Hv4D7020088 for mip6-archive@odin.ietf.org; Mon, 1 Mar 2004 12:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrf6-0005Dv-Bj for mip6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 12:57:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24725 for ; Mon, 1 Mar 2004 12:57:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrf4-0002AG-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 12:57:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxreF-00022N-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 12:56:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axrd9-0001ub-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 12:55:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrd9-000501-Ob; Mon, 01 Mar 2004 12:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axrd6-0004zG-8P for mip6@optimus.ietf.org; Mon, 01 Mar 2004 12:55:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24645 for ; Mon, 1 Mar 2004 12:54:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axrd4-0001tc-00 for mip6@ietf.org; Mon, 01 Mar 2004 12:54:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axrc9-0001nj-00 for mip6@ietf.org; Mon, 01 Mar 2004 12:54:02 -0500 Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx with smtp (Exim 4.12) id 1Axrbr-0001hK-00 for mip6@ietf.org; Mon, 01 Mar 2004 12:53:43 -0500 Received: from unknown (HELO eremmell) (elmic@sbcglobal.net@64.170.248.130 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 1 Mar 2004 17:53:42 -0000 From: "Ed Remmell" To: Cc: , "'Odile@Treck'" , "'Jimmy Zhang'" Subject: RE: [Mip6] MIPv6 issue (IPsec/IKE interaction) Date: Mon, 1 Mar 2004 09:53:44 -0800 Message-ID: <000001c3ffb6$2448fe00$0400a8c0@eremmell> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <200403010704.i21740Sj053204@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis - Thanks for your feedback. > => with such aggressive timings you should use very short > timeouts too! We think a 15 second timeout is appropriate for an embedded systems implementation. > => I can see two problems in your IKE implementation: > - recovering takes too long time (same order than SA lifetimes) > - it doesn't detect the address mismatch, i.e., it sees different > addresses and just drops messages (it should not process them > blindly but should not simply drop them). We made a change to have the receiver IKE (HA, in this case) to have it rekey the phase 1 ISAKMP SAs when it detects the address mismatch. > => KAME/FreeBSD Mobile IPv6 + racoon can be adapted to HA and they > are open source. IMHO the main issue is the KAME/FreeBSD kernel moves > IPsec SAs and SPDs without a warning to IKE but this can be easily > fixed. Please provide more detail about "can be easily fixed". We would like to use this configuration in our MIPv6 testbed to test MIPv6 with IKE, if it isn't too difficult to setup. Thanks. - Ed --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.593 / Virus Database: 376 - Release Date: 2/20/2004 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 1 16:23:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07160 for ; Mon, 1 Mar 2004 16:23:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxusN-0002vm-Ur for mip6-archive@odin.ietf.org; Mon, 01 Mar 2004 16:23:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i21LMxfn011260 for mip6-archive@odin.ietf.org; Mon, 1 Mar 2004 16:22:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxusN-0002vX-GR for mip6-web-archive@optimus.ietf.org; Mon, 01 Mar 2004 16:22:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07146 for ; Mon, 1 Mar 2004 16:22:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxusL-00030n-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 16:22:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxurW-0002uN-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 16:22:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxuqT-0002oL-00 for mip6-web-archive@ietf.org; Mon, 01 Mar 2004 16:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxuqU-0002pg-1n; Mon, 01 Mar 2004 16:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxupW-0002ns-Gc for mip6@optimus.ietf.org; Mon, 01 Mar 2004 16:20:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07095 for ; Mon, 1 Mar 2004 16:20:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxupU-0002hw-00 for mip6@ietf.org; Mon, 01 Mar 2004 16:20:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxuoZ-0002cY-00 for mip6@ietf.org; Mon, 01 Mar 2004 16:19:04 -0500 Received: from alpha8.its.monash.edu.au ([130.194.1.8]) by ietf-mx with esmtp (Exim 4.12) id 1Axuo3-0002Wd-00 for mip6@ietf.org; Mon, 01 Mar 2004 16:18:32 -0500 Received: from localhost ([130.194.13.83]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01L78HACWD2W8X3JKE@vaxh.its.monash.edu.au> for mip6@ietf.org; Tue, 2 Mar 2004 02:19:19 +1100 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 8A04F23C003; Tue, 02 Mar 2004 02:19:14 +1100 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by splat.its.monash.edu.au (Postfix) with ESMTP id 71E89164008; Tue, 02 Mar 2004 02:19:14 +1100 (EST) Date: Tue, 02 Mar 2004 00:19:14 +0900 From: Gregory Daley To: NJEDJOU Eric FTRD/DMR/REN Cc: Pekka Nikander , Stefan Aust , basavaraj.patil@nokia.com, =?iso-8859-1?Q?Carmelita_G=F6rg?= , "Niko A. Fikouras" , Cornel Pampu , Dna , Greg Daley , mip6@ietf.org Message-id: <5a6a8a5a671e.5a671e5a6a8a@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-disposition: inline Content-transfer-encoding: 7BIT X-Accept-Language: en Content-Transfer-Encoding: 7BIT Subject: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, I know that this has been cross posted, so I'll respond to both lists, but perhaps we can talk about specific issues in the individual mailing lists subsequently. I'd suggest DNA, unless the MIP6 chairs wish to respond. If we need to discuss needs more generally for multiple interface configuration procedures or vertical handoff, it may be useful to take it up with the chairs of either or both WGs (depending on the circumstances). Please see my take below. ----- Original Message ----- From: NJEDJOU Eric FTRD/DMR/REN Date: Monday, March 1, 2004 9:51 pm Subject: RE : [DNA] Current IETF-Draft version - POLIMAND > Pekka, > The problem with MIP6 movement detection handover optimizations > (see http://www.ietf.ord/I-D/draft-daniel-mip6-optimized-vertical- > handover-00.txt for another draft) is that it is being considered > out of scope for DNA because of the mobile IPv6 issue raised and > out of scope for MIP6 because of the link triggers that has to be > taken into account. Actually, it is within the scope of both as I'd guess while this is frustrating, it's largely a statement of fact. Please inform me of any incorrect statements I make, since there may be subtlties I miss in the drafts. While the drafts being discussed are principally interested in handling multiple connectivity scenarios associated with wireless networks, neither MIPv6 (regarding Link hints) or DNA (Discussing global signalling) are currently chartered to work on these topics. It is indeed possible that the combination of the techniques is seen as the stumbling block by both groups. For example, if indeed it is necessary to provide vertical handover support for MIPv6, is it strictly necessary to talk about link layer interactions (polimand may talk about policy instead, Of course, it is always hard to standardize policy). Whether a document looking at multiple interface connectivity for MIPv6 would be useful or not (or whether there's much difference except the movement detection algorithm) I don't know. Particularly for DNA, we can't really discuss handovers, considering that this term principally refers to session restoration or continuation using mobility protocols. DNA is looking basically at signalling using mechanisms within the local link only. Any reference to other protocols (except in a confined way) can make documents look like they're (for example) MIP specific. If there's a difference in the configuration detection procedures when a host has multiple interfaces, that may be different. For example, a host may wish to wait passively for router advertisements on the GPRS interface (testing reachability when the host switches connections to that interface), and probes fairly aggressively on a WLAN interface. Any decision or action based on this the configuration detection is starting to push into uncomfortable areas as far as DNA's tight charter is concerned. Perhaps this is analogous to the reasoning used in MIP6? > DNA -link triggers/hints that will be catalogued/standardized > within DNA will also be used for Mobile IPv6 optimised movement > detection. Other ones may be needed for this specific purpose. > Better detecting network attchment/detachment is a requirement for > Mobile IPv6 better performance movement detection and handover. > These issues are therefore strongly linked. I think we have to be particularly careful about the word standardized in the previous paragraph. There's already been some out-of-band feedback to DNA that we should avoid delving into standardization of L2 oriented mechanisms. > MIP6 -Optimized movement detection an handover schemes are > essenttial for base Mobile IPv6 Operation, which means, the > protocol operation needs exploiting L2 triggers/hints. And MIPv6 > implementors use L2 triggers/hints in a confusing way, if not at all. While the usage of hints may be unavoidable in some DNA schemes, there will still be some systems where it is not possible to the the kind of hints you desire. It would be short-sighted to design systems which only work if information from the link-layer is reliable and available. > We could be ping-ponging betwwen these two groups for years. I really hope not, but MOBOPTS isn't necessarily a place for killing ideas off to (no matter what some people say!). Our research team has (voluntarily!) submitted some ideas there for further discussion recently and gotten useful feedback. I don't even mind if people winnow their existing work down to a problem statement which is DNA centric. It may be that there's a chance that we'd think it out-of-scope anyway, but that's because the WG scope is very narrow. If the work is clear input into one of the documents on the DNA charter, that may change things. We're only likely to produce 4 documents this year (optimistically). so focussing on how the vertical handover/polimand work can directly help those is more immediately useful. As Pekka said, this may mean leaving MIPv6 specific parts to MIP6WG or MOBOPTS. Greg _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 2 02:21:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21528 for ; Tue, 2 Mar 2004 02:21:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4DX-00042Y-Dr for mip6-archive@odin.ietf.org; Tue, 02 Mar 2004 02:21:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i227LRqb015471 for mip6-archive@odin.ietf.org; Tue, 2 Mar 2004 02:21:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4DU-00041Q-Tp for mip6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 02:21:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21493 for ; Tue, 2 Mar 2004 02:21:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4DR-0004Mr-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:21:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4Ca-0004Gf-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:20:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4CE-00049j-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4CC-0003OA-If; Tue, 02 Mar 2004 02:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4BY-000360-Mh for mip6@optimus.ietf.org; Tue, 02 Mar 2004 02:19:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21294 for ; Tue, 2 Mar 2004 02:19:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4BU-00047d-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:19:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4Ab-00041B-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:18:26 -0500 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4AH-0003uf-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:18:05 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i227I1i5011108; Tue, 2 Mar 2004 00:18:02 -0700 (MST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i227HwQ14124; Tue, 2 Mar 2004 08:17:58 +0100 (MET) Date: Mon, 1 Mar 2004 23:18:02 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt To: James Kempf Cc: Erik Nordmark , Hiroyuki OHNISHI , Jari Arkko , mip6@ietf.org In-Reply-To: "Your message with ID" <024001c3ff42$523cb320$3e6015ac@dclkempt40> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 > Mobile IP has certain fixed per node costs in terms of signaling that are > definitely not there for a node that gets a lease on its DHCP address and > hangs on to it until the lease expires. That would be the justification for > charging more. Presumably an operator could bill per byte/packet which would include the mobile IP signalling packets. Presumably an operator could also bill for each DHCP address lease where a mobile moving around might get many short leases. Neither of those requires any knowledge that the node uses mobile IP. > Like I said, people's opinions about whether or not this is desirable can > vary. :-) But I don't think the IETF should be engineering the protocol to > favor one business model over another (see draft-iab-e2e-futures-txt for a > discussion of tussles and how standards should work in the face of them). So > far, I don't see anything in the protocol that does. I don't think the debate was about designing the protocol to prohibit a business model. Instead the discussion is about whether the protocol should be made to explicitly support a particular business model. One can draw parallels with ESP; you can argue that ESP prohibits a business model where rates is different for UDP and TCP packets since the protocol and port numbers are encrypted. My understanding is that the arguments to change ESP to not encrypt these didn't get a favorable reception when this was discussed a while back. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 2 02:41:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22910 for ; Tue, 2 Mar 2004 02:41:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4Wp-0000Vk-Gp for mip6-archive@odin.ietf.org; Tue, 02 Mar 2004 02:41:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i227fLNR001947 for mip6-archive@odin.ietf.org; Tue, 2 Mar 2004 02:41:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4Wl-0000V5-Ho for mip6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 02:41:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22774 for ; Tue, 2 Mar 2004 02:41:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4Wh-0006yJ-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:41:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4Ul-0006TS-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:39:16 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay4TX-0006Du-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:37:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay4Mw-0002Rx-5v for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:31:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4Mu-0007QT-F8; Tue, 02 Mar 2004 02:31:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4M8-00070h-9t for mip6@optimus.ietf.org; Tue, 02 Mar 2004 02:30:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22311 for ; Tue, 2 Mar 2004 02:30:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4M4-0005Z2-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:30:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4LA-0005Kn-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:29:21 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Ay4KO-0005Ev-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:28:32 -0500 Message-ID: <4b6b01c40028$0a6c0640$3e6015ac@dclkempt40> From: "James Kempf" To: "Erik Nordmark" Cc: "Erik Nordmark" , "Hiroyuki OHNISHI" , "Jari Arkko" , References: Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt Date: Mon, 1 Mar 2004 23:29:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > One can draw parallels with ESP; you can argue that ESP prohibits a > business model where rates is different for UDP and TCP packets since > the protocol and port numbers are encrypted. > My understanding is that the arguments to change ESP to not encrypt > these didn't get a favorable reception when this was discussed a while > back. > Ack. But an ISP can bill specifically for ESP traffic, separately from what would be billed for other services. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 2 03:03:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24408 for ; Tue, 2 Mar 2004 03:03:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4rN-0003Cb-0Z for mip6-archive@odin.ietf.org; Tue, 02 Mar 2004 03:02:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2282abw012308 for mip6-archive@odin.ietf.org; Tue, 2 Mar 2004 03:02:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4rM-0003CR-Kg for mip6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 03:02:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24267 for ; Tue, 2 Mar 2004 03:02:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4rI-0002Pf-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 03:02:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4pu-00023U-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 03:01:07 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay4oi-0001po-01 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:59:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay4cL-0002n8-6k for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 02:47:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4cH-0001Ha-C0; Tue, 02 Mar 2004 02:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4ba-00019H-Mj for mip6@optimus.ietf.org; Tue, 02 Mar 2004 02:46:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23510 for ; Tue, 2 Mar 2004 02:46:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4bW-0000P4-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:46:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4aZ-0000DZ-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:45:16 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4ZC-0007dY-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:43:50 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i227hjKL013670; Tue, 2 Mar 2004 16:43:45 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i227hjSW010558; Tue, 2 Mar 2004 16:43:45 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id SAA10556 ; Tue, 2 Mar 2004 16:43:45 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id QAA26017; Tue, 2 Mar 2004 16:43:44 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp id QAA23804; Tue, 2 Mar 2004 16:43:43 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw.toshiba.co.jp with ESMTP id i227hg51009479; Tue, 2 Mar 2004 16:43:42 +0900 (JST) Received: from steelhead ([159.119.168.62]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0HTX009OYUSR9U@tsbpo1.po.toshiba.co.jp>; Tue, 2 Mar 2004 16:43:41 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1AxWHW-0001gp-00; Sun, 29 Feb 2004 11:07:18 -0800 Date: Sun, 29 Feb 2004 11:07:17 -0800 From: Yoshihiro Ohba Subject: Re: [Mip6] comments on draft-ohnishi-mip6-aaa-problem-statement-00.txt In-reply-to: <4b6b01c40028$0a6c0640$3e6015ac@dclkempt40> To: James Kempf Cc: Erik Nordmark , Hiroyuki OHNISHI , Jari Arkko , mip6@ietf.org Message-id: <20040229190717.GI6087@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.5.1+cvs20040105i References: <4b6b01c40028$0a6c0640$3e6015ac@dclkempt40> Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 On Mon, Mar 01, 2004 at 11:29:02PM -0800, James Kempf wrote: > > One can draw parallels with ESP; you can argue that ESP prohibits a > > business model where rates is different for UDP and TCP packets since > > the protocol and port numbers are encrypted. > > My understanding is that the arguments to change ESP to not encrypt > > these didn't get a favorable reception when this was discussed a while > > back. > > > > Ack. But an ISP can bill specifically for ESP traffic, separately from what > would be billed for other services. That is ok, as long as the billing is as a result of "AAA for network access", and it does not require "AAA for ESP traffic". Yoshihiro Ohba > > jak > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 2 05:43:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01978 for ; Tue, 2 Mar 2004 05:43:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay7MY-0002eB-I3 for mip6-archive@odin.ietf.org; Tue, 02 Mar 2004 05:43:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22AgvCJ010174 for mip6-archive@odin.ietf.org; Tue, 2 Mar 2004 05:42:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay7MW-0002dy-Ev for mip6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 05:42:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01830 for ; Tue, 2 Mar 2004 05:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay7MS-0000Ck-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 05:42:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay7Ka-0007Y0-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 05:40:57 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay7Jt-0007MY-02 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 05:40:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ay7Dy-0006ON-Qm for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 05:34:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay7Dv-0001bb-Go; Tue, 02 Mar 2004 05:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay7DH-0001aq-Of for mip6@optimus.ietf.org; Tue, 02 Mar 2004 05:33:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01569 for ; Tue, 2 Mar 2004 05:33:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay7DE-0006ji-00 for mip6@ietf.org; Tue, 02 Mar 2004 05:33:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay7CF-0006dZ-00 for mip6@ietf.org; Tue, 02 Mar 2004 05:32:20 -0500 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1Ay7BH-0006WX-00 for mip6@ietf.org; Tue, 02 Mar 2004 05:31:19 -0500 Received: from speedy ([134.102.155.204]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id i22AUlm14087; Tue, 2 Mar 2004 11:30:47 +0100 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host [134.102.155.204] claimed to be speedy From: "Stefan Aust" To: "'Gregory Daley'" , "'NJEDJOU Eric FTRD/DMR/REN'" Cc: "'Pekka Nikander'" , , "=?iso-8859-1?Q?'Carmelita_G=F6rg'?=" , "'Niko A. Fikouras'" , "'Cornel Pampu'" , "'Dna'" , Date: Tue, 2 Mar 2004 11:31:07 +0100 Message-ID: <002301c40041$797ce900$cc9b6686@speedy> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5a6a8a5a671e.5a671e5a6a8a@mail1.monash.edu.au> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Mip6] AW: RE : [DNA] Current IETF-Draft version - POLIMAND Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Dear Greg, dear all. Thank you very much for your comments regarding the draft. We hope that we can support the current work items in the DNA WG with our draft=20 submission and we are grateful for the ongoing discussion concerning = L2/L3=20 interaction.=20 However, in this draft it is described how the interaction of L2/L3 can = be used to establish handovers based on a policy. We will think about to = extend this draft in a way that is more independent of MIP. Proactive handover=20 decision can be appropiate to force Neighbor Discovery/Neighbor Unreachability Detection=20 for DNA, for instance. However, we think that it might be important to inform the MN=20 on the fastest way that the MN will change its point of attachment. The first=20 implementation of POLIMAND has shown that lossless handovers can be = provided by using=20 L2 information for vertical handovers in overlay networks. Kind regards, Stefan > -----Urspr=FCngliche Nachricht----- > Von: owner-dna@ecselists.eng.monash.edu.au=20 > [mailto:owner-dna@ecselists.eng.monash.edu.au] Im Auftrag von=20 > Gregory Daley > Gesendet: Montag, 1. M=E4rz 2004 16:19 > An: NJEDJOU Eric FTRD/DMR/REN > Cc: Pekka Nikander; Stefan Aust; basavaraj.patil@nokia.com;=20 > Carmelita G=F6rg; Niko A. Fikouras; Cornel Pampu; Dna; Greg=20 > Daley; mip6@ietf.org > Betreff: Re: RE : [DNA] Current IETF-Draft version - POLIMAND >=20 >=20 > Hi, >=20 > I know that this has been cross posted, so I'll > respond to both lists, but perhaps we can talk about > specific issues in the individual mailing lists > subsequently. I'd suggest DNA, unless the MIP6 > chairs wish to respond. >=20 > If we need to discuss needs more generally for=20 > multiple interface configuration procedures or > vertical handoff, it may be useful to take it up=20 > with the chairs of either or both WGs (depending > on the circumstances). >=20 > Please see my take below. > ----- Original Message ----- > From: NJEDJOU Eric FTRD/DMR/REN > Date: Monday, March 1, 2004 9:51 pm > Subject: RE : [DNA] Current IETF-Draft version - POLIMAND >=20 > > Pekka, > > The problem with MIP6 movement detection handover optimizations > > (see http://www.ietf.ord/I-D/draft-daniel-mip6-optimized-vertical- > > handover-00.txt for another draft) is that it is being considered=20 > > out of scope for DNA because of the mobile IPv6 issue raised and=20 > > out of scope for MIP6 because of the link triggers that has to be=20 > > taken into account. Actually, it is within the scope of both as=20 >=20 > I'd guess while this is frustrating, it's largely a statement=20 > of fact. >=20 > Please inform me of any incorrect statements I make, since=20 > there may be subtlties I miss in the drafts. >=20 > While the drafts being discussed are principally interested=20 > in handling multiple connectivity scenarios associated with=20 > wireless networks, neither MIPv6 (regarding Link hints) or > DNA (Discussing global signalling) are currently chartered to=20 > work on these topics. >=20 > It is indeed possible that the combination of the techniques > is seen as the stumbling block by both groups. >=20 > For example, if indeed it is necessary to provide vertical=20 > handover support for MIPv6, is it strictly necessary to talk=20 > about link layer interactions (polimand may talk about policy=20 > instead, Of course, it is always hard to standardize policy). >=20 > Whether a document looking at multiple interface connectivity=20 > for MIPv6 would be useful or not (or whether there's much=20 > difference except the movement detection algorithm) I don't know. >=20 > Particularly for DNA, we can't really discuss handovers,=20 > considering that this term principally refers to session=20 > restoration or continuation using mobility protocols. >=20 > DNA is looking basically at signalling using mechanisms=20 > within the local link only. Any reference to other > protocols (except in a confined way) can make documents > look like they're (for example) MIP specific. >=20 > If there's a difference in the configuration detection=20 > procedures when a host has multiple interfaces, that may be different. >=20 > For example, a host may wish to wait passively for router=20 > advertisements on the GPRS interface (testing reachability=20 > when the host switches connections to that interface), and=20 > probes fairly aggressively on a WLAN interface. >=20 > Any decision or action based on this the configuration=20 > detection is starting to push into uncomfortable areas as far=20 > as DNA's tight charter is concerned. Perhaps this is=20 > analogous to the reasoning used in MIP6? >=20 > > DNA -link triggers/hints that will be catalogued/standardized > > within DNA will also be used for Mobile IPv6 optimised movement=20 > > detection. Other ones may be needed for this specific purpose.=20 > > Better detecting network attchment/detachment is a requirement for=20 > > Mobile IPv6 better performance movement detection and handover.=20 > > These issues are therefore strongly linked.=20 >=20 > I think we have to be particularly careful about the word=20 > standardized in the previous paragraph. There's already been=20 > some out-of-band feedback to DNA that we should avoid delving=20 > into standardization of L2 oriented mechanisms. >=20 > > MIP6 -Optimized movement detection an handover schemes are > > essenttial for base Mobile IPv6 Operation, which means, the=20 > > protocol operation needs exploiting L2 triggers/hints. And MIPv6=20 > > implementors use L2 triggers/hints in a confusing way, if=20 > not at all. >=20 > While the usage of hints may be unavoidable in some DNA schemes,=20 > there will still be some systems where it is not possible to=20 > the the kind of hints you desire. It would be short-sighted to=20 > design systems which only work if information from the=20 > link-layer is reliable and available.=20 >=20 > > We could be ping-ponging betwwen these two groups for years. >=20 > I really hope not, but MOBOPTS isn't necessarily a place for=20 > killing ideas off to (no matter what some people say!). =20 > Our research team has (voluntarily!) submitted some ideas=20 > there for further discussion recently and gotten useful feedback. >=20 > I don't even mind if people winnow their existing work down=20 > to a problem statement which is DNA centric. It may be that=20 > there's a chance that we'd think it out-of-scope anyway, but=20 > that's because the WG scope is very narrow. >=20 > If the work is clear input into one of the documents on the=20 > DNA charter, that may change things. >=20 > We're only likely to produce 4 documents this year=20 > (optimistically). so focussing on how the vertical=20 > handover/polimand work can directly help those is more=20 > immediately useful. >=20 > As Pekka said, this may mean leaving MIPv6 specific parts to=20 > MIP6WG or MOBOPTS. > =20 > Greg >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 2 10:05:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12973 for ; Tue, 2 Mar 2004 10:05:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBRv-0000Mm-UK for mip6-archive@odin.ietf.org; Tue, 02 Mar 2004 10:04:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22F4lTd001395 for mip6-archive@odin.ietf.org; Tue, 2 Mar 2004 10:04:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBRv-0000MQ-B9 for mip6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 10:04:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12930 for ; Tue, 2 Mar 2004 10:04:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBRt-00032c-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 10:04:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBQs-0002vB-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 10:03:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyBQE-0002nq-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 10:03:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBQD-0007uv-2a; Tue, 02 Mar 2004 10:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBPq-0007Xr-Ad for mip6@optimus.ietf.org; Tue, 02 Mar 2004 10:02:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12745 for ; Tue, 2 Mar 2004 10:02:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBPo-0002mw-00 for mip6@ietf.org; Tue, 02 Mar 2004 10:02:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBP3-0002gi-00 for mip6@ietf.org; Tue, 02 Mar 2004 10:01:51 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AyBOD-0002YK-00 for mip6@ietf.org; Tue, 02 Mar 2004 10:00:57 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AyBOB-0000qZ-00; Tue, 02 Mar 2004 16:00:55 +0100 Received: from atiswww by irams1.ira.uka.de with local (Exim 3.30 #7 ) id 1AyBOB-0003pc-00; Tue, 02 Mar 2004 16:00:55 +0100 Received: from 210.93.162.110 ([210.93.162.110]) by mailhost.ira.uka.de (IMP) with HTTP for ; Tue, 2 Mar 2004 16:00:54 +0100 Message-ID: <1078239654.4044a1a701ae0@mailhost.ira.uka.de> Date: Tue, 2 Mar 2004 16:00:55 +0100 From: Christian Vogt To: Jari Arkko Cc: mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 210.93.162.110 Content-Transfer-Encoding: 8bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jari! > I already sent some comments earlier, but I reread this draft > prior to the meeting. Here are some additional comments. Overall > I find your draft quite promising. There's probably a need to > change the approach to byte counts rather than fixed time > limits, as dicussed earlier. You are referring to the following question: How can a correspondent node (CN) know how much data it may sent to a "good" mobile node's (MN's) new care-of address (CoA), while that CoA is being verified by a concurrent CoA test, without allowing a malicious node to misuse the concurrent CoA test for a flooding attack. And yes, the 3-seconds time limit on the concurrent CoA test, which we proposed in version -00 of the [2], does not solve the problem for two reasons. The first reason is the one you mentioned in an earlier email: The amount of data a CN may send within three seconds can be arbitrarily high. It is only limited by the pipe between the CN and the target IP address. A second reason is that a 3-seconds time limit alone does not prevent a malicious node from continually refreshing a tentative CoA registration. It might seem to be an obvious approach to replace the 3-seconds time limit by a constant byte (or packet) limit. A constant byte limit would bound the data volume that a CN may send to a yet-to-be-verified CoA. But a constant byte limit has a similar shortfall than the constant time time limit proposed in [2], namely: Whatever limit is chosen, it might still allow for a flooding attack against a node at a narrow link. This observation led us to the idea of balancing the data volume that a CN can send to an "unconfirmed" CoA of a MN with the data volume that the CN has earlier sent to a "confirmed" CoA of the same MN. With "unconfirmed" CoA I mean a CoA for which a concurrent CoA test is still ongoing. With "confirmed" CoA I mean a CoA for which the CN has obtained assurance, through a CoA test, that the MN is indeed reachable at that CoA. We called this approach "Credit-Based Authorization", meaning that a MN must collect some "credit" (in terms of data volume) before it can do a concurrent CoA test. In an email, you suggest using the data volume originated *by the MN*, and sent to the CN, as the counter-balance to what the CN may sent to a yet-to-be-verified CoA of the MN. Yes, this is a good idea. As discussed during our conversation after yesterday's MIP6 session, one should probably use both types of traffic, which would also allow for applications with asymmetric data flows. > However, if as suggested you would change the approach to > specifically take this into account, this would no longer be a > problem. Basically, a CN would agree to send out at most X bytes > of traffic while in the tentative state, where X is, say, 10 % of > the bytes sent by the MN during the last few minutes. This would > result in the attacker (mobile node) having to send at least 100 > bytes to get just 10 bytes to the attacker, clearly less than the > 1-1 reflection simply using TCP SYNs. Still, the 10% is more than > enough to transfer the data needed until the care-of test answer > arrives: if you have a constant data rate, 10% of data sent during > three minutes gives you 18 s to complete the care-of address test. > > If you exceed X, you move the stream back to the home address. We are currently working on version -01 of [2] in which we specify Credit-Based Authorization, but we did not finish the new version in time for this IETF meeting. I do have a slide on Credit-Based Authorization, which I will show during my presentation of Early Binding Updates at the MOBOPTS session on Wednesday afternoon, provided there is sufficient time. (It is only a 10-minutes presentation.) > If this draft goes further, it might make sense to separate > the home address and care-of address optimizations. That is, > you could have one draft that explains how the home address > tests can be initiated before handover takes place. Or would > this be considered too simple for a draft?... I don't know. One argument that might be against separating Early Binding Update I-D is that, in Mobile IPv6, a MN may already do a home-address (HoA) test whenever it whishes. Though the MIPv6 specification suggest to do the HoA test after a handover, a MN may also do it before the handover without violating the protocol specification. In fact, a HoA test can be done at any time as long as the Home Keygen Token retrieved from it is not expired when eventually used for Binding Update message authentication. Nonetheless, I think that splitting the I-D is an excellent idea, because both the early HoA test as well as the concurrent CoA test require additional commentary. As far as the HoA test goes, I may just cite your previous email: > Perhaps the separate draft that I suggested makes sense, because > you would also have to describe the exception that you talk about > in the above [...] ...namely having the MN do a HoA test even when it is at home. As far as the CoA test goes, there is this credit-based authorization method which will be specified in version -01 of [2]. Certainly, splitting the I-D into two separate I-Ds would make both of them easier to read. > Maybe the byte count scheme could be called the "Adaptive > Amplification Attack Prevention" (AAAP) or "Attack Cost > War for Amplification" (ACWA). We called it "Credit-Based Authorization" for now. It does not sound too spectacular, I admit. "Counter-Balance-Based Egress Monitoring could be another alternative. > Hmm... I wonder if this has been described anywhere else. > Seems like a rather general scheme. But maybe not, as it > only makes sense in movements. Write a paper somewhere on this, > interested? Credit-Based Authorization is definitely an important topic per se and needs dedicated consideration. And yes, we intend to elaborate further on this topic. Writing a paper is an excellent idea! The following comments are not related to Credit-Based Authorization. > Maybe with some simulation data should be included, and rules > to tell when it makes sense: delay at movement vs. potentially > unnecessary messaging if we didn't move after all. You are right. Simulation analyses are still on our to-do list. > Presumably you could do an EBU as soon as you receive the Home Test > message. I think this would simplify your state machine. I agree. This is true. When writing this I-D, we thought from an implementor's perspective: An Early-Binding-Update-enabled MN would probably implement standard binding updates as well, and that code could just be re-used here. But, you are right: The state machine gets simpler if Early Binding Updates are used in all situations. Jari, I appreciate your detailed comments on Early Binding Updates. Best regards, - Christian [1] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt [2] http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt | | Christian Vogt | Institute of Telematics, University of Karlsruhe | www.tm.uka.de/~chvogt/ | Quoting Jari Arkko : > I already sent some comments earlier, but I reread this draft > prior to the meeting. Here are some additional comments. Overall > I find your draft quite promising. There's probably a need to > change the approach to byte counts rather than fixed time > limits, as dicussed earlier. > > > We propose a modified binding-update procedure that > > evades the latency of both address tests. > > If this draft goes further, it might make sense to separate > the home address and care-of address optimizations. That is, > you could have one draft that explains how the home address > tests can be initiated before handover takes place. Or would > this be considered too simple for a draft?... I don't know. > Maybe with some simulation data should be included, and rules > to tell when it makes sense: delay at movement vs. potentially > unnecessary messaging if we didn't move after all. Anyway, > this part of the optimization would work well with any other > optimization scheme as well, not just the care-of-test-less > early binding updates. Or without any other optimization. > > > before changing its point of network attachment. At home, the > > mobile node does not use Mobile IPv6. It hence does not run a > > home-address test, and it does not acquire a Home Keygen > > Token, before it moves to a foreign link. Also, when the > > mobile node powers on at a foreign > > I don't see a reason why the predictive home test strategy > wouldn't work even in this case. In either case, you have to have > some ability to "guess" that you will be moving soon, or otherwise > you'll just be doing some extra signaling. > > > One may consider letting the mobile node perform a home-address > > test even while being at home. This could accelerate handovers > > from the home link to a foreign link. The Home Test Init and > > Home Test messages would continue to obey to the rules defined > > in sections 9.4 and 11.6 of [1], except that they would not have > > to be tunneled between the mobile node and its home agent. > > This is true. But if you are going to adopt predictive home tests, > I would apply them even to the home case. > > Perhaps the separate draft that I suggested makes sense, because > you would also have to describe the exception that you talk about > in the above. > > > These observations lead to the following exception: When a mobile > > node wants to register a new care-of address with a correspondent > > node, and the mobile node does not yet know a valid Home Keygen > > Token, the mobile node runs a standard binding update instead of > > an Early Binding Update. When the standard binding update is > > complete, the mobile node can communicate through its new care-of > > address. The > > Presumably you could do an EBU as soon as you receive the Home > Test message. I think this would simplify your state machine. > > > test. We claim that testing the mobile node's reachability at > > its new care-of address may also be done at (3). Data trans- > > mission to and from the new care-of address may wait or, as > > with Early Binding Updates, start with appropriate restrictions > > until the mobile node has provided proof to the correspondent > > node that it is reachable at its new care-of address. > > This is the issue we discussed earlier. As has been stated by > Francis and others, in the Internet we already (unfortunately, > since ingress filtering is not ubiquitous) have the possibility > to spoof source addresses, leading to 1-1 reflection attacks on > e.g. TCP SYN packets. So 1-1 reflection is not necessarily > something we need to prevent in Mobile IPv6. Base RR attempts, > however, to prevent 1-N reflection attacks where you send one > (or some) packets and get many more packets to the victim's > network. The basic scenario is tricking someone into opening a > stream, and moving the stream towards the victim and letting > the "someone" pump data towards the victim for a while. > > Your -00 draft with the 3 second time limit still has this issue, > as a CN which supports EBUs could pump 3 seconds of data stream > to the victim. How serious is this? It depends on the interface > speed and effort needed to open the particular stream. Lets say > 10 packets to open the stream and get over the slow start (maybe > someone can help me with the actual numbers...). If the CN is a > mobile on a congested GPRS link, there may not be many packets > sent during the 3 seconds. But if the CN is an idle web server on > an OC-3 link there could be a lot of packets, particularly since > the attacker can send some spoofed TCP ACKs, having learned the > sequence numbers while opening the stream. > > However, if as suggested you would change the approach to > specifically take this into account, this would no longer be a > problem. Basically, a CN would agree to send out at most X bytes > of traffic while in the tentative state, where X is, say, 10 % of > the bytes sent by the MN during the last few minutes. This would > result in the attacker (mobile node) having to send at least 100 > bytes to get just 10 bytes to the attacker, clearly less than the > 1-1 reflection simply using TCP SYNs. Still, the 10% is more than > enough to transfer the data needed until the care-of test answer > arrives: if you have a constant data rate, 10% of data sent during > three minutes gives you 18 s to complete the care-of address test. > > If you exceed X, you move the stream back to the home address. > > The drawback of this scheme is that on the first binding you may > be unable to do this, even if you had ongoing data transfer with > the mobile while it was at home. This is because the IP stack would > not be counting the received bytes. > The Home Keygen Token and > > > the Care-of Keygen Token are likely to arrive at the mobile node > > via disjoint paths: The former passes through the mobile node's > > home agent, the latter does not. An attacker will thus have a > > hard time to capture both tokens. > > Strictly speaking, this is not the main worry. As documented in [1], > the attacker is free to choose the care-of path. So I would worry > more about attackers posing as mobile nodes and doing the RR test > than attackers being able to eavesdrop on an RR test performed > by a legitimate node. In order to pose as a mobile node, you need > to be on the path to the home agent, and your draft does not change > that so I think you are ok. (Also, if you are on the path to the > home agent you can do all sorts of other nasty stuff.) > > (You say all this later in the text, but I just wanted to say > that two paths are not a protection in RR, your method, or other > methods.) > > > Another way to mitigate the threat of flooding attacks is to > > grant Early Binding Updates to trusted nodes only. Recall that > > the > > I wouldn't put too much emphasis on this. However, if we had some > stronger home test mechanisms (e.g. CGA), you could combine EBUs > with them, getting more security. > > --Jari ------------------------------------------------------------- This message was sent through ATIS: http://atiswww.ira.uka.de _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 2 10:57:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16502 for ; Tue, 2 Mar 2004 10:57:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCGH-00008i-Dn for mip6-archive@odin.ietf.org; Tue, 02 Mar 2004 10:56:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i22FunQA000532 for mip6-archive@odin.ietf.org; Tue, 2 Mar 2004 10:56:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCGH-00008V-7j for mip6-web-archive@optimus.ietf.org; Tue, 02 Mar 2004 10:56:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16480 for ; Tue, 2 Mar 2004 10:56:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyCGE-00024j-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 10:56:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyCFN-0001wF-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 10:55:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyCEd-0001ne-00 for mip6-web-archive@ietf.org; Tue, 02 Mar 2004 10:55:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCEZ-0008Oa-09; Tue, 02 Mar 2004 10:55:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyCDa-0008Kj-BL for mip6@optimus.ietf.org; Tue, 02 Mar 2004 10:54:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16288 for ; Tue, 2 Mar 2004 10:53:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyCDX-0001b0-00 for mip6@ietf.org; Tue, 02 Mar 2004 10:53:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyCCW-0001RD-00 for mip6@ietf.org; Tue, 02 Mar 2004 10:52:56 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AyCBz-0001Hs-00 for mip6@ietf.org; Tue, 02 Mar 2004 10:52:23 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 18D0F6A902; Tue, 2 Mar 2004 17:52:20 +0200 (EET) Message-ID: <4044AD2D.8020401@kolumbus.fi> Date: Tue, 02 Mar 2004 17:50:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Vogt Cc: mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 References: <1078239654.4044a1a701ae0@mailhost.ira.uka.de> In-Reply-To: <1078239654.4044a1a701ae0@mailhost.ira.uka.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit What you say looks reasonable. I'm just responding to one issue that probably needs more care than we originally thought when we talked: > In an email, you suggest using the data volume originated *by the MN*, > and sent to the CN, as the counter-balance to what the CN may sent to a > yet-to-be-verified CoA of the MN. Yes, this is a good idea. As > discussed during our conversation after yesterday's MIP6 session, > one should probably use both types of traffic, which would also allow > for applications with asymmetric data flows. This would indeed be desireable. However, you can't really count on the packets that the CN sends actually being delivered to the MN. For instance, the MN might be on a slow link, sending fake TCP ACKs towards the the CN. The CN would be sending data at a high rate, but most of the packets would be dropped by a router on the path. (This observation was made by Erik Nordmark.) But this isn't necessarily a serious limitation, as the long credit collecting period vs. short care-of test RTT gives you some maneuvering room. And if you happen to run out of "credit", the world will not end, it will just work a bit slower... --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 00:20:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02215 for ; Wed, 3 Mar 2004 00:20:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOnc-0006C1-Av for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 00:20:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i235K4Sh023799 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 00:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOnb-0006Ba-0g for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 00:20:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02175 for ; Wed, 3 Mar 2004 00:19:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOnY-0004Bb-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 00:20:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOma-00043h-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 00:19:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyOlf-0003vl-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 00:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOle-0005j1-GF; Wed, 03 Mar 2004 00:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyOkp-0005gm-3r for mip6@optimus.ietf.org; Wed, 03 Mar 2004 00:17:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02000 for ; Wed, 3 Mar 2004 00:17:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyOkm-0003nZ-00 for mip6@ietf.org; Wed, 03 Mar 2004 00:17:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyOjt-0003f4-00 for mip6@ietf.org; Wed, 03 Mar 2004 00:16:14 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AyOjM-0003UR-00 for mip6@ietf.org; Wed, 03 Mar 2004 00:15:40 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i235F6S09258; Wed, 3 Mar 2004 06:15:07 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i235F6Sj060273; Wed, 3 Mar 2004 06:15:06 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403030515.i235F6Sj060273@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Christian Vogt cc: Jari Arkko , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 In-reply-to: Your message of Tue, 02 Mar 2004 16:00:55 +0100. <1078239654.4044a1a701ae0@mailhost.ira.uka.de> Date: Wed, 03 Mar 2004 06:15:06 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 In your previous mail you wrote: A second reason is that a 3-seconds time limit alone does not prevent a malicious node from continually refreshing a tentative CoA registration. => this can be easily solve by some kind of hold-down mechanism... In this case IMHO the best is just not to reset the timer on "refresh". It might seem to be an obvious approach to replace the 3-seconds time limit by a constant byte (or packet) limit. A constant byte limit would bound the data volume that a CN may send to a yet-to-be-verified CoA. But a constant byte limit has a similar shortfall than the constant time time limit proposed in [2], namely: Whatever limit is chosen, it might still allow for a flooding attack against a node at a narrow link. => I agree: as the line speed can be between some kbits/s to a hundred Mbits/s (wireless) or some Gbits/s (wired) you either kill performance or victims behind a narrow link. This observation led us to the idea of balancing the data volume that a CN can send to an "unconfirmed" CoA of a MN with the data volume that the CN has earlier sent to a "confirmed" CoA of the same MN. With "unconfirmed" CoA I mean a CoA for which a concurrent CoA test is still ongoing. With "confirmed" CoA I mean a CoA for which the CN has obtained assurance, through a CoA test, that the MN is indeed reachable at that CoA. We called this approach "Credit-Based Authorization", meaning that a MN must collect some "credit" (in terms of data volume) before it can do a concurrent CoA test. => this is very complex and does nothing for a victim behind a narrow link and an attacker behind a fast link. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 01:10:40 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05390 for ; Wed, 3 Mar 2004 01:10:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPa6-0005Rf-SL for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 01:10:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i236AAqI020923 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 01:10:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPa6-0005RM-NO for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 01:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05356 for ; Wed, 3 Mar 2004 01:10:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPa3-0004pV-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 01:10:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyPZ7-0004gw-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 01:09:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyPY6-0004XL-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 01:08:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPY4-0004xD-Pn; Wed, 03 Mar 2004 01:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyPXI-0004nA-Kf for mip6@optimus.ietf.org; Wed, 03 Mar 2004 01:07:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05237 for ; Wed, 3 Mar 2004 01:07:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyPXF-0004Nb-00 for mip6@ietf.org; Wed, 03 Mar 2004 01:07:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyPWM-0004Df-00 for mip6@ietf.org; Wed, 03 Mar 2004 01:06:19 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1AyPVU-0003tt-00 for mip6@ietf.org; Wed, 03 Mar 2004 01:05:24 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HTZ00I5BKW5GZ@mailout1.samsung.com> for mip6@ietf.org; Wed, 03 Mar 2004 15:04:53 +0900 (KST) Received: from ep_ms7_bk (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTZ00KVZKVJ2M@mailout1.samsung.com> for mip6@ietf.org; Wed, 03 Mar 2004 15:04:31 +0900 (KST) Received: from ep_spt02 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HTZ0065KKVJFL@ms7.samsung.com> for mip6@ietf.org; Wed, 03 Mar 2004 15:04:31 +0900 (KST) Content-return: prohibited Date: Wed, 03 Mar 2004 06:04:41 +0000 (GMT) From: Kyungjoo Suh Subject: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz8zRyBTdGFu?= =?windows-1252?B?ZGFyZHMgUiZhbXA7RCBMYWIuP2VuZ2luZWVy?= To: "mip6@ietf.org " , =?windows-1252?Q?=3F=3F=3F_?= Reply-to: joo.suh@samsung.com Message-id: <7906627.1078293862563.JavaMail.weblogic@ep_app24> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040303060422551@joo.suh X-MTR: 20040303060422551@joo.suh X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL,PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT Hi, New draft is available which is Fast multicast protocol. This document defines the Fast Multicast Protocol for Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile node (MN) can receive multicast data with reduced loss and delay after handoffs. Please refer to following document. sincerely, Kyungjoo Suh (Joo) =================================================================================================== I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt -------------------------------------------------------------------------------- To: IETF-Announce: ; Subject: I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to: Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : 2004-2-6 This document defines the Fast Multicast Protocol for Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile node (MN) can receive multicast data with reduced loss and delay after handoffs. The proposed protocol can be implemented by the simple modification of the Fast Handovers protocol [1] so that it can be easily applied to the Fast Handovers for Mobile IPv6. This document does not need a certain assumption of a specific multicast routing protocol, so that any existing multicast routing protocol can be used with the proposed protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 03:24:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10532 for ; Wed, 3 Mar 2004 03:24:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRfY-0004Cy-4M for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 03:23:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i238NuAw016176 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 03:23:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRfD-0004C6-CL for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 03:23:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10268 for ; Wed, 3 Mar 2004 03:23:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRew-00043J-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 03:23:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRdZ-0003eE-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 03:21:54 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRc4-0003QU-01 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 03:20:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyRT9-0005xA-L5 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 03:11:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRT7-0002fQ-SL; Wed, 03 Mar 2004 03:11:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRRz-0002QK-Ec for mip6@optimus.ietf.org; Wed, 03 Mar 2004 03:10:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09648 for ; Wed, 3 Mar 2004 03:09:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRRb-0001pF-00 for mip6@ietf.org; Wed, 03 Mar 2004 03:09:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRQj-0001d4-00 for mip6@ietf.org; Wed, 03 Mar 2004 03:08:38 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AyRPX-0001Gu-00 for mip6@ietf.org; Wed, 03 Mar 2004 03:07:24 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i2386i0J002347; Wed, 3 Mar 2004 00:06:45 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i2386eQ03921; Wed, 3 Mar 2004 09:06:41 +0100 (MET) Date: Wed, 3 Mar 2004 00:06:45 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 To: Jari Arkko Cc: Francis Dupont , Christian Vogt , mip6@ietf.org In-Reply-To: "Your message with ID" <4045897D.1000205@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 > Btw, there is some discussion about this in the mobopts list too. Sorry for starting things on that list; I hadn't seen the discussion on this list yet. > Re: victim behind a narrow link and attacker behind a > fast link. You are right that this doesn't do anything > for this case. But isn't this already the case today? > I mean an attacker behind a fast link can send a zillion > spoofed TCP SYNs to www.cnn.com and have the responses > go my GPRS link, which would be hosed. The effort required > for this would be a sending a zillion packets. To do this > via early binding updates, you'd need more than a zillion > packets. Or alternatively directly flood the victim. In the case of the BU with a victim as the CoA the victim can actually tell the attacker's IP address - it is contained in the Home Address option. Thus the direct flood and the BU using the victim as the CoA have similar properties: - victim can tell the address of the attacker - ingress filtering can't prevent the attack since the source address is not spoofed The difference is the limit on bandwidth. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 05:48:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17711 for ; Wed, 3 Mar 2004 05:48:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTus-0002fN-Vt for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 05:47:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23Also3010249 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 05:47:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTud-0002eR-Ib for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 05:47:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17671 for ; Wed, 3 Mar 2004 05:47:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTuL-0005SP-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 05:47:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTtU-0005K9-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 05:46:29 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyTt3-0005BB-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 05:46:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTt2-0002NZ-R1; Wed, 03 Mar 2004 05:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyTrw-0002Lb-Sx for mip6@optimus.ietf.org; Wed, 03 Mar 2004 05:45:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17529 for ; Wed, 3 Mar 2004 05:44:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyTrZ-00050c-00 for mip6@ietf.org; Wed, 03 Mar 2004 05:44:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyTqh-0004r1-00 for mip6@ietf.org; Wed, 03 Mar 2004 05:43:36 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AyTqC-0004g3-00 for mip6@ietf.org; Wed, 03 Mar 2004 05:43:04 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i23AgUS31222; Wed, 3 Mar 2004 11:42:30 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i23AgUSj061157; Wed, 3 Mar 2004 11:42:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403031042.i23AgUSj061157@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 In-reply-to: Your message of Wed, 03 Mar 2004 09:30:05 +0200. <4045897D.1000205@kolumbus.fi> Date: Wed, 03 Mar 2004 11:42:30 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 In your previous mail you wrote: > ... We called this approach "Credit-Based Authorization", > meaning that a MN must collect some "credit" (in terms of data volume) > before it can do a concurrent CoA test. > > => this is very complex and does nothing for a victim behind a narrow > link and an attacker behind a fast link. Lets explore this a little bit. => just ask implementors... IMHO they don't be happy with this: a defense against a not-existant attack when ingress filtering is used (when ingress filtering is not used/effective attackers have simpler and more efficient ways to bomb you). Francis, I presume the credit based scheme must also ensure that Alt-CoA is not used, right? => any mechanism which does not perform or does delay a care-of address check has to refuse fake alternate care-of addresses. I argue this is the only needed care. Because if we don't ensure that, an attacker that is under ingress filtering could do attacks that he previously couldn't. This is because the care-of test would have to be done for the claimed address, but the care-of test is not needed in the tentative stage. => we already know that. Re: victim behind a narrow link and attacker behind a fast link. You are right that this doesn't do anything for this case. But isn't this already the case today? => so the credit stuff is not useful? I mean an attacker behind a fast link can send a zillion spoofed TCP SYNs to www.cnn.com and have the responses go my GPRS link, which would be hosed. => a zillion to www.cnn.com won't work. A zillion to a different www..com will work pretty well. The effort required for this would be a sending a zillion packets. => the attacker only needs enough zombies to make the load per zombie acceptable for zombie connections. To do this via early binding updates, you'd need more than a zillion packets. => this is not a problem at all today and the reason attackers won't misuse Mobile IPv6 is they can use plain IPv6 with less effort. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 06:11:42 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18757 for ; Wed, 3 Mar 2004 06:11:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUHO-0004j3-Jj for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 06:11:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23BBA22018165 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 06:11:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUH4-0004gf-DA for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 06:11:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18737 for ; Wed, 3 Mar 2004 06:10:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyUGl-0001QX-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 06:10:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyUFv-0001GX-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 06:09:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyUFH-000164-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 06:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUFK-0004Wb-6e; Wed, 03 Mar 2004 06:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUF2-0004VG-S8 for mip6@optimus.ietf.org; Wed, 03 Mar 2004 06:08:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18665 for ; Wed, 3 Mar 2004 06:08:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyUEf-00014S-00 for mip6@ietf.org; Wed, 03 Mar 2004 06:08:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyUDf-0000uK-00 for mip6@ietf.org; Wed, 03 Mar 2004 06:07:19 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AyUCl-0000dI-00 for mip6@ietf.org; Wed, 03 Mar 2004 06:06:24 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i23B5jS00811; Wed, 3 Mar 2004 12:05:46 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i23B5jSj061252; Wed, 3 Mar 2004 12:05:45 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403031105.i23B5jSj061252@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Jari Arkko , Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 In-reply-to: Your message of Wed, 03 Mar 2004 00:06:45 PST. Date: Wed, 03 Mar 2004 12:05:45 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 In your previous mail you wrote: Or alternatively directly flood the victim. In the case of the BU with a victim as the CoA the victim can actually tell the attacker's IP address - it is contained in the Home Address option. Thus the direct flood and the BU using the victim as the CoA have similar properties: - victim can tell the address of the attacker - ingress filtering can't prevent the attack since the source address is not spoofed => I disagree for the second: this is a property of the direct flood, not of the reflection flood using or not Mobile IPv6. BTW the standard reflection flood has not the first property (i.e., victim cannot tell the address of the attacker). The difference is the limit on bandwidth. => which is not effective as the limit is per correspondent and is relative to the bandwidth of attacker(s). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 06:43:54 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19998 for ; Wed, 3 Mar 2004 06:43:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUmY-00080Q-8W for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 06:43:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23BhM7L030768 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 06:43:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUmE-0007wj-3n for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 06:43:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19959 for ; Wed, 3 Mar 2004 06:42:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyUlv-0006r9-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 06:42:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyUl6-0006fk-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 06:41:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyUkG-0006Si-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 06:41:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUkI-0007Xj-Rb; Wed, 03 Mar 2004 06:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyUjz-0007VD-Bo for mip6@optimus.ietf.org; Wed, 03 Mar 2004 06:40:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19846 for ; Wed, 3 Mar 2004 06:40:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyUjb-0006P5-00 for mip6@ietf.org; Wed, 03 Mar 2004 06:40:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyUig-0006E9-00 for mip6@ietf.org; Wed, 03 Mar 2004 06:39:22 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AyUhs-0005xh-00 for mip6@ietf.org; Wed, 03 Mar 2004 06:38:32 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i23Bbo0J023387; Wed, 3 Mar 2004 03:37:51 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i23BbjQ27360; Wed, 3 Mar 2004 12:37:45 +0100 (MET) Date: Wed, 3 Mar 2004 03:37:50 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 To: Francis Dupont Cc: Erik Nordmark , Jari Arkko , Christian Vogt , mip6@ietf.org In-Reply-To: "Your message with ID" <200403031105.i23B5jSj061252@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 > Thus the direct flood and the BU using the victim as the CoA > have similar properties: > - victim can tell the address of the attacker > - ingress filtering can't prevent the attack since the source > address is not spoofed > > => I disagree for the second: this is a property of the direct flood, > not of the reflection flood using or not Mobile IPv6. > BTW the standard reflection flood has not the first property > (i.e., victim cannot tell the address of the attacker). I agree it isn't the property of the reflection flood (but I didn't talk about that case.) With mobile IPv6 with a relaxed/delayed test of the Care-of address you do have the property that the attackers address is disclosed to the victim. With X as attacker, A the victim, B the "server": X starts a session with B to get B to send a high-bandwith stream of packets to X. X then sends a HoTI/HoT to B (no need for CoTI/CoT since the CoA test is delayed in this case). X sends a BU to B specifying that the CoA is A. B starts the CoA test with A, and starts sending the high-bandwidth stream to A. These packets are CN->MN packets thus per the mobile IPv6 specification they contain the Home Address option with the value X. (And X continues to send predicted "acks" to B to ensure that the high-bandwidth stream continues to flow to A.) Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 08:10:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24728 for ; Wed, 3 Mar 2004 08:10:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW8Z-0002Ak-VX for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 08:10:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23DABtb008342 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 08:10:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyW8F-00028T-PG for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 08:10:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24587 for ; Wed, 3 Mar 2004 08:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyW7z-00067n-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 08:09:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyW6P-0005bG-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 08:07:58 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyW4h-0005Bn-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 08:06:11 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyVq6-0003g9-US for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 07:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVq2-0000Vi-2O; Wed, 03 Mar 2004 07:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyVpB-0000Jy-Sb for mip6@optimus.ietf.org; Wed, 03 Mar 2004 07:50:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23298 for ; Wed, 3 Mar 2004 07:49:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyVoh-0002K9-00 for mip6@ietf.org; Wed, 03 Mar 2004 07:49:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyVnp-0002AU-00 for mip6@ietf.org; Wed, 03 Mar 2004 07:48:46 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AyVnH-0001zp-00 for mip6@ietf.org; Wed, 03 Mar 2004 07:48:11 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i23ClYS09019; Wed, 3 Mar 2004 13:47:34 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i23ClYSj061575; Wed, 3 Mar 2004 13:47:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403031247.i23ClYSj061575@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Jari Arkko , Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 In-reply-to: Your message of Wed, 03 Mar 2004 03:37:50 PST. Date: Wed, 03 Mar 2004 13:47:34 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 In your previous mail you wrote: > Thus the direct flood and the BU using the victim as the CoA > have similar properties: > - victim can tell the address of the attacker > - ingress filtering can't prevent the attack since the source > address is not spoofed > > => I disagree for the second: this is a property of the direct flood, > not of the reflection flood using or not Mobile IPv6. > BTW the standard reflection flood has not the first property > (i.e., victim cannot tell the address of the attacker). I agree it isn't the property of the reflection flood (but I didn't talk about that case.) => perhaps I have abusively translate "the BU using the victim as the CoA" as the reflection flood using Mobile IPv6. With mobile IPv6 with a relaxed/delayed test of the Care-of address you do have the property that the attackers address is disclosed to the victim. => this is the first property, the second is to be immune to the ingress filtering (the CoA is the source address and is the address of the victim so the ingress filtering is the proper defense). With X as attacker, A the victim, B the "server": X sends a BU to B specifying that the CoA is A. => this is blocked by the ingress filtering (*). B starts the CoA test with A, and starts sending the high-bandwidth stream to A. => a full sending window. These packets are CN->MN packets thus per the mobile IPv6 specification they contain the Home Address option with the value X. => I agree and this is not a nice property for the attacker. (And X continues to send predicted "acks" to B to ensure that the high-bandwidth stream continues to flow to A.) => A sends "resets" to B too... (*) the important thing is the reflection flood using IPv6 or Mobile IPv6 with relaxed/delayed CoA test, and the direct flood using fake source address are *blocked* by the ingress filtering. So we are loosing our time to discuss about mitigating against a second order attack when a first order one is available and shared the same defense. This is RIDICULOUS! Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 11:21:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07878 for ; Wed, 3 Mar 2004 11:21:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZ6z-00013A-0P for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 11:20:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23GKitt004030 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 11:20:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZ6y-00012v-Ls for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 11:20:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07875 for ; Wed, 3 Mar 2004 11:20:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyZ6y-0004D6-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 11:20:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZ6B-00041a-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 11:19:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyZ5S-0003q6-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 11:19:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZ5J-0000r4-EX; Wed, 03 Mar 2004 11:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyZ50-0000pn-Bj for mip6@optimus.ietf.org; Wed, 03 Mar 2004 11:18:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07750 for ; Wed, 3 Mar 2004 11:18:40 -0500 (EST) From: Rod.Walsh@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyZ4z-0003m1-00 for mip6@ietf.org; Wed, 03 Mar 2004 11:18:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyZ40-0003Yb-00 for mip6@ietf.org; Wed, 03 Mar 2004 11:17:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AyZ34-0003Mm-00 for mip6@ietf.org; Wed, 03 Mar 2004 11:16:43 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23GGaC11673; Wed, 3 Mar 2004 18:16:36 +0200 (EET) X-Scanned: Wed, 3 Mar 2004 18:16:21 +0200 Nokia Message Protector V1.3.13 2004020314 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i23GGLkW030234; Wed, 3 Mar 2004 18:16:21 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00wQTWsg; Wed, 03 Mar 2004 18:16:19 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i23GGI727246; Wed, 3 Mar 2004 18:16:18 +0200 (EET) Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 18:16:18 +0200 Received: from trebe003.NOE.Nokia.com ([172.22.232.175]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 3 Mar 2004 18:16:19 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt Date: Wed, 3 Mar 2004 18:16:19 +0200 Message-ID: Thread-Topic: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt Thread-Index: AcQA5fky7nbS7wPuRySf/BMDFyvICwAFmd9A To: , X-OriginalArrivalTime: 03 Mar 2004 16:16:19.0740 (UTC) FILETIME=[DCCD75C0:01C4013A] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Joo I quickly read your Internet draft with interest and would like to know = if you will intend to discuss it on the mobopts mail list? I have been working on multicast to mobiles for some time and would be = happy to exchange ideas. Here are some early thoughts on your document: The problem and solution seem to do a good job for multicast receivers. How does the PAR learn of the NAR address? (In the sense that: Is there = something that would be in scope for Multicast Fast Handover, that's = different from unicast/existing fast handover?) Some discussion on IGMP/MLD-snooping and the role of access points as = switches could be appropriate too - to deal with the situation where AP = changes but AR does not. Also, there are several security risks. Of particular trouble are the = DoS possibilities of setting up state in many "NARs" by a = broken/malicious "MN", and sending to multiple ARs malicious multicast = data (e.g. to destroy usability of the "expected service"). SSM is worth = mentioning and also access control. As far as I am certain there are 2 = ongoing activities on multicast (AR) access control: MCOP, IGAP. And I = think there's a 3rd in MAGMA - so no need to address the whole access = control solution, just explain the impact and use for this fast = multicast handover. (I guess you already have these ideas for the 01 = draft :) Tunnelling multicast from PAR to NAR is not so scalable, this should be = mentioned. Perhaps suggest a means to time-out these tunnels so that the = tunnelling is only transitory since using the "PAR" as the tunnel = other-end point reduces scalability of that AR. The differentiation between receiver-only, sender-only and = reciever+sender MNs would be a good discussion item too. For instance, I = think your solution is great for receivers, but for senders (especially = send-only non-group-members) it does not solve the problem. Perhaps this = is just an issue of limiting the scope to receiver mobility. Maybe it is = currently helping readability to not cover sender mobility in this = draft, so one option is to consider these aspects in a separate draft - = at the same time or a later stage. Also, one small NIT: please make it explicit which references are = normative (essential) and which are informative (I guess all 4 are = normative)? Have you had any earlier feedback or discussion on the MIPSHOP (or other = WG) email lists? Cheers, Rod. -----Original Message----- From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On Behalf Of ext Kyungjoo Suh Sent: Wednesday, March 03, 2004 3:05 PM To: mip6@ietf.org ; ???=20 Subject: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt Hi,=20 New draft is available which is Fast multicast protocol. This document defines the Fast Multicast Protocol for Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile node (MN) can receive multicast data with reduced loss and delay after handoffs.=20 Please refer to following document. sincerely, Kyungjoo Suh (Joo)=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt -------------------------------------------------------------------------= ------- To: IETF-Announce: ;=20 Subject: I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt=20 From: Internet-Drafts at ietf.org=20 Date: Fri, 06 Feb 2004 15:41:59 -0500=20 Reply-to: Internet-Drafts at ietf.org=20 Sender: owner-ietf-announce at ietf.org=20 -------------------------------------------------------------------------= ------- A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : 2004-2-6 =09 This document defines the Fast Multicast Protocol for Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile node (MN) can receive multicast data with reduced loss and delay after handoffs. The proposed protocol can be implemented by the simple modification of the Fast Handovers protocol [1] so that it can be easily applied to the Fast Handovers for Mobile IPv6. This document does not need a certain assumption of a specific multicast routing protocol, so that any existing multicast routing protocol can be used with the proposed protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt To remove yourself from the IETF Announcement list, send a message to=20 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-suh-mipshop-fmcast-mip6-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html=20 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-suh-mipshop-fmcast-mip6-00.txt". =09 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. =09 =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. = _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 14:09:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18643 for ; Wed, 3 Mar 2004 14:09:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybju-0000SE-JJ for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 14:09:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i23J96li001739 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 14:09:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybju-0000Ry-Cx for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 14:09:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18558 for ; Wed, 3 Mar 2004 14:09:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aybjs-0006OH-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 14:09:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aybis-0006AC-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 14:08:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aybhx-0005ww-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 14:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybht-0008S0-Vb; Wed, 03 Mar 2004 14:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aybgy-0008Q9-R7 for mip6@optimus.ietf.org; Wed, 03 Mar 2004 14:06:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18381 for ; Wed, 3 Mar 2004 14:06:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aybgw-0005jE-00 for mip6@ietf.org; Wed, 03 Mar 2004 14:06:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AybgA-0005Xl-00 for mip6@ietf.org; Wed, 03 Mar 2004 14:05:15 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AybfN-0005Ko-00; Wed, 03 Mar 2004 14:04:25 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1Aybf8-0003ef-00; Wed, 03 Mar 2004 20:04:11 +0100 Received: from atiswww by irams1.ira.uka.de with local (Exim 3.30 #7 ) id 1Aybf8-0005fq-00; Wed, 03 Mar 2004 20:04:10 +0100 Received: from 210.93.162.110 ([210.93.162.110]) by mailhost.ira.uka.de (IMP) with HTTP for ; Wed, 3 Mar 2004 20:04:09 +0100 Message-ID: <1078340649.40462c29dddda@mailhost.ira.uka.de> Date: Wed, 3 Mar 2004 20:04:09 +0100 From: Christian Vogt To: Francis.Dupont@enst-bretagne.fr, jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, kempf@docomolabs-usa.com Cc: mip6@ietf.org, mobopts@irtf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 210.93.162.110 Content-Transfer-Encoding: 8bit Subject: [Mip6] Re: Comments on Early Binding Updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.0 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Francis, Jari, Erik, and James! Below are a few comments on your emails which you have sent to the MIP6 and MOBOPTS mailing lists following (or immediately preceding) my presentation on Early Binding Updates (http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt) at the MOBOPTS session. Best regards - Christian | | Christian Vogt | Institute of Telematics, University of Karlsruhe | www.tm.uka.de/~chvogt/ | Francis Dupont wrote on misuse of Early Binding Updates for flooding attacks: > > A second reason is that a 3-seconds time limit alone > > does not prevent a malicious node from continually > > refreshing a tentative CoA registration. > > this can be easily solve by some kind of hold-down > mechanism... In this case IMHO the best is just not to > reset the timer on "refresh". Francis, you propose that a mobile node be required to do a standard binding update within each two successive Early Binding Updates. This would be a simple and easy-to-implement mechanism. Unfortunately however, an attacker could easily trick this mechanism: It would direct a large data stream towards the attacked victim node for a time slightly shorter than an unconfirmed care-of address's (CoA's) lifetime. When the unconfirmed CoA is about to expire, the attacker would direct the data stream to itself by means of a standard Binding Update message, and it would immediately re-direct the data stream, by means of an Early Binding Update message, to the attacked victim node. The attacker could repeat this procedure indefinitely. There is another disadvantage of the hold-down mechanism: Suppose a mobile node sends to the correspondent node an Early Binding Update message. Then, all of a sudden, the handover fails, and the mobile node falls back to the original sub-network. In this situation, the mobile node would want to send to the correspondent node another Early Binding Update message, re-updating the correspondent node to the old CoA. With the hold-down mechanism, however, this second Early Binding Update message would be rejected, because there has been no standard binding update between this and the first Early Binding Update message. Jari Arkko commented on Credit-Based Authorization: > However, you can't really count on the packets that > the CN sends actually being delivered to the MN. For > instance, the MN might be on a slow link, sending > fake TCP ACKs towards the the CN. The CN would be > sending data at a high rate, but most of the packets > would be dropped by a router on the path. (This > observation was made by Erik Nordmark.) This is very true. If this threat is considered serious, one should refrain from using downlink packets as a criteria for credit collection. (A solution to use downlink packets nonetheless might be to have the correspondent node send to the mobile node, at random times, Challenge messages to which the mobile node must respond. Such Challenge messages would be dropped at the router with the same probability as any other data packet. The correspondent node would record for how many Challenge messages it receives a response. The mobile node's CREDIT counter would increase more or less fast depending on the percentage of responded-to Challenge messages. This "solution", however, is probably too complex and therefore unapplicable.) Francis Dupont commented on Credit-Based Authorization: > this is very complex and does nothing for a victim behind > a narrow link and an attacker behind a fast link James Kempf wrote on the same issue: > Jari's point - that the rate be constructed based on the > previous rate - might be more doable, but there might be > an issue with an MN that was on a broadband link, since > it could concievably bomb a node on a lower bandwidth > link (a point which has already been mentioned). IMO, there are two reason why an attacker may want to use reflection for a flooding attack. First, the attacker may want to reveal its identity. Second, the attacker may want to make use of an amplification which comes along with the reflection. Revealing one's identity is not possible with Mobile IPv6, because the correspondent node tags all outgoing data packets with the intended recipient's (i.e., the attacker's) home address. The home address, in turn, cannot be spoofed, because Early Binding Updates require the mobile node (or attacker) to do a home-address test before an Early Binding Update message can be sent. Amplification is also not possible with Early Binding Updates if Credit-Based Authorization is applied. This is because the data volume sent to an attacked victim node is limited by the data volume that the attacker must send itself. Francis and James, you argue that the attacker might be willing to spend this effort if it sits on a fast link. But if this is the case, there are other, more efficient attacks, which are already possible without Mobile IPv6. Jari Arkko elaborates on this: > But isn't this already the case today? I mean an attacker > behind a fast link can send a zillion spoofed TCP SYNs to > www.cnn.com and have the responses go my GPRS link, which > would be hosed. Erik Nordmark wrote: > It might be worth-while to think about bandwidth and rate > limiting as an alternative to byte/packet counting. While > it is hard to determine the actual rate at which the MN can > send, I think it would be interesting to understand this > part. For instance, if the MN can only send at 64 kbps > could one restrict the CN to send at 64 kbps until the CoA > has been confirmed? Using the uplink (mobile-node-to-correspondent-node) data rate as a limit on how much data the correspondent node can send to an unconfirmed CoA makes sense, because the uplink data rate is what determines the data rate with which an attacker can wage a flooding attack *without* Mobile IPv6. Thus, if a mobile node's (or attacker's) credit was based on the uplink data rate, misusing Early Binding Updates for flooding attacks would probably become inattractive. The disadvantage of using the uplink data rate as a limit on how much data the correspondent node can send to an unconfirmed CoA gets obvious if the former is much less than the latter. This is, e.g., the case with asymmetric applications like video streaming. If the correspondent node reduced the downlink data rate to the recently observed uplink data rate, it would not be able to send all packets that it receives from the application. The correspondent node would thus have to either buffer or drop those packets that do not fit within the limited downlink data rate. Buffering data packets is probably infeasible, as it significantly increases the required resources at the correspondent node. Moreover, a buffer may eventually overflow anyway. Throwing away packets is not a solution either, since it may seriously impact ongoing connections which are sensitive to data loss. TCP connections are one example. One might therefore restrict Early Binding Updates to loss-*in*sensitive applications only (which would include most delay-sensitive applications). Yet, making Early Binding Updates (an L3 protocol) applicable to only a certain set of applications is not a wise idea IMO. Francis Dupont wrote: > the important thing is the reflection flood using IPv6 > or Mobile IPv6 with relaxed/delayed CoA test, and the > direct flood using fake source address are *blocked* > by the ingress filtering. Yes, Francis, this is true if ingress filtering was universally applied. Until now, however, this is not the case. The correspondent node should therefore have a different means - e.g., the CoA test - to determine whether or not the mobile node is reachable. Mobile IPv6 goes the most secure way and requires a CoA test *before* CoA registration. If the CoA-test requirement is to be more relaxed, like with Early Binding Updates, the correspondent node needs more intelligence to prevent flooding attacks. One mechanism to provide this intelligence is Credit-Based Authentication. I agree that an attacker could bypass ingress filtering, if applied, by using an Alternate CoA option. In other words, the Alternate CoA option could render ingress filtering useless. As you say, Francis, the Alternate CoA option should therefore not be used with Early Binding Updates. I have previously mentioned this on the MIP6 mailing list (February 10, 2004). Francis Dupont wrote: > Is the "Early Binding Updates" document for mobopts > (an IRTF WG) or for mip6 (an IETF WG)? When submitting the Internet-Draft on Early Binding Updates, we assumed that it may best fit into the MIP6 WG. This is why the Internet-Draft has the "mip6" infix in its name. Of course, if the MIP6 community finds that there is a better place for Early Binding Updates, we would not hesitate to move the Internet-Draft. ------------------------------------------------------------- This message was sent through ATIS: http://atiswww.ira.uka.de _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 19:16:23 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09258 for ; Wed, 3 Mar 2004 19:16:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygWo-0000Cj-Un for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 19:15:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240FsiZ000781 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 19:15:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygWo-0000CW-Mr for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:15:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09205 for ; Wed, 3 Mar 2004 19:15:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygWn-0001cZ-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 19:15:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygVu-0001QF-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 19:14:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AygV2-0001Bk-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 19:14:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygUy-0008Oq-VQ; Wed, 03 Mar 2004 19:14:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygUO-0008Nk-KE for mip6@optimus.ietf.org; Wed, 03 Mar 2004 19:13:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08918 for ; Wed, 3 Mar 2004 19:13:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygUN-0000z6-00 for mip6@ietf.org; Wed, 03 Mar 2004 19:13:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygTH-0000iJ-00 for mip6@ietf.org; Wed, 03 Mar 2004 19:12:16 -0500 Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx with esmtp (Exim 4.12) id 1AygSP-0000Hz-00 for mip6@ietf.org; Wed, 03 Mar 2004 19:11:21 -0500 Received: from eamrcnt717.exu.ericsson.se (eamrcnt717.exu.ericsson.se [138.85.90.249]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id i240ApfX025653 for ; Wed, 3 Mar 2004 18:10:51 -0600 (CST) Received: from eamrcnt750.exu.ericsson.se ([138.85.133.51]) by eamrcnt717.exu.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Wed, 3 Mar 2004 18:06:06 -0600 Received: by eamrcnt750.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Mar 2004 18:10:32 -0600 Received: from [142.133.72.115] (142.133.72.115 [142.133.72.115]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 17VGX00Z; Wed, 3 Mar 2004 19:10:47 -0500 Date: Wed, 3 Mar 2004 19:10:18 -0500 (EST) From: Suresh Krishnan X-X-Sender: lmcsukr@localhost.localdomain Reply-To: Suresh Krishnan To: Christian Vogt cc: Francis.Dupont@enst-bretagne.fr, , , , , Subject: Re: [Mip6] Re: Comments on Early Binding Updates In-Reply-To: <1078340649.40462c29dddda@mailhost.ira.uka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 04 Mar 2004 00:06:06.0609 (UTC) FILETIME=[7D7C5810:01C4017C] Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.6 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Hi Christian, I had just one comment. On Wed, 3 Mar 2004, Christian Vogt wrote: ... >Francis Dupont commented on Credit-Based Authorization: > >> this is very complex and does nothing for a victim behind >> a narrow link and an attacker behind a fast link > >James Kempf wrote on the same issue: > >> Jari's point - that the rate be constructed based on the >> previous rate - might be more doable, but there might be >> an issue with an MN that was on a broadband link, since >> it could concievably bomb a node on a lower bandwidth >> link (a point which has already been mentioned). > >IMO, there are two reason why an attacker may want to use reflection for >a flooding attack. First, the attacker may want to reveal its identity. >Second, the attacker may want to make use of an amplification which >comes along with the reflection. > >Revealing one's identity is not possible with Mobile IPv6, because the In fact it is the exact opposite. The attacking node's identity WILL ALWAYS be revealed in mobile ipv6. Did you mean hide instead of reveal? Regards Suresh This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 19:34:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10026 for ; Wed, 3 Mar 2004 19:34:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygoJ-0001Vr-M0 for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 19:33:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i240XxUl005814 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 19:33:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygoJ-0001Vh-Fv for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 19:33:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09994 for ; Wed, 3 Mar 2004 19:33:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygoH-0004UK-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 19:33:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygnM-0004KU-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 19:33:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AygmO-0004AS-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 19:32:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygmO-0001IZ-Pq; Wed, 03 Mar 2004 19:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygmL-0001H7-Ph for mip6@optimus.ietf.org; Wed, 03 Mar 2004 19:31:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09909 for ; Wed, 3 Mar 2004 19:31:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygmK-00049g-00 for mip6@ietf.org; Wed, 03 Mar 2004 19:31:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyglT-000409-00 for mip6@ietf.org; Wed, 03 Mar 2004 19:31:05 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Aygks-0003qb-00; Wed, 03 Mar 2004 19:30:26 -0500 Message-ID: <01ae01c4017f$f412be80$5f6115ac@dclkempt40> From: "James Kempf" To: "Thomas Schmidt" , Cc: , , References: <40465FB5.6080608@fhtw-berlin.de> Subject: Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt Date: Wed, 3 Mar 2004 16:30:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > I quickly read your Internet draft with interest and would like to > > know if you will intend to discuss it on the mobopts mail list? > > > > I have been working on multicast to mobiles for some time and would > > be happy to exchange ideas. > > Actually, we've found it the case of FMIPv4 on 802.11 that the performance for reactive handover is perfectly adequate. There is some slight additional delay and one loses packets during the L2 handover (if the proprietary buffer fowarding at the AP is turned off) but other than that, it works fine. Unfortuantely, I can't send the paper out because it is under consideration for publication. We haven't specifically looked at multicast, but I can't see how it could be a problem. The multicast traffic will get forwarded through the tunnel until the mobile node does MLD for the group with the new router, at which point the routing change will propagate. There is of course an issue with the route propagating, and, in that sense, HMIP might be better if the multicast routing tree is rooted in the MAP. jak > > > > Here are some early thoughts on your document: > > > > The problem and solution seem to do a good job for multicast > > receivers. > > > A matter of debate could be, wether FMIPv6 is a well suited fundament > for multicast distribution. FMIP must be eager to anticipate handovers > (if it will work well), thus exhibiting a significant likelyhood of > wrong predictions. > > In the multicast case this will lead to an unwanted quantity of uneeded > remote subscriptions, unneccessary branches in the multicast trees ... > > ... from our point of view the smoother hmipv6 MAP architecture is much > more appropriate as multicast agents ... > > > How does the PAR learn of the NAR address? (In the sense that: Is > > there something that would be in scope for Multicast Fast Handover, > > that's different from unicast/existing fast handover?) > > > > If we understand correctly: This is just taken from FMIPv6's prediction. > There should be nothing exclusive to multicast. > > > Some discussion on IGMP/MLD-snooping and the role of access points as > > switches could be appropriate too - to deal with the situation where > > AP changes but AR does not. > > Mhmm, this might be more a concern of underlying L2 specification. The > FMIPv6 approach leaves L2 specs to additional documents. > > > > Also, there are several security risks. Of particular trouble are the > > DoS possibilities of setting up state in many "NARs" by a > > broken/malicious "MN", and sending to multiple ARs malicious > > multicast data (e.g. to destroy usability of the "expected service"). > > SSM is worth mentioning and also access control. As far as I am > > certain there are 2 ongoing activities on multicast (AR) access > > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need > > to address the whole access control solution, just explain the impact > > and use for this fast multicast handover. (I guess you already have > > these ideas for the 01 draft :) > > > > Tunnelling multicast from PAR to NAR is not so scalable, this should > > be mentioned. Perhaps suggest a means to time-out these tunnels so > > that the tunnelling is only transitory since using the "PAR" as the > > tunnel other-end point reduces scalability of that AR. > > > Tunneling in this approach only occurs, if NAR refuses to subscribe to > the wanted multicast group ... question is: when will this happen? On > which bases would a NAR decide not to support a specific group? > > Cheers, > > Thomas & Matthias > > > > > > The differentiation between receiver-only, sender-only and > > reciever+sender MNs would be a good discussion item too. For > > instance, I think your solution is great for receivers, but for > > senders (especially send-only non-group-members) it does not solve > > the problem. Perhaps this is just an issue of limiting the scope to > > receiver mobility. Maybe it is currently helping readability to not > > cover sender mobility in this draft, so one option is to consider > > these aspects in a separate draft - at the same time or a later > > stage. > > > > Also, one small NIT: please make it explicit which references are > > normative (essential) and which are informative (I guess all 4 are > > normative)? > > > > Have you had any earlier feedback or discussion on the MIPSHOP (or > > other WG) email lists? > > > > > > Cheers, Rod. > > > > > > > > -----Original Message----- From: mip6-admin@ietf.org > > [mailto:mip6-admin@ietf.org]On Behalf Of ext Kyungjoo Suh Sent: > > Wednesday, March 03, 2004 3:05 PM To: mip6@ietf.org ; ??? Subject: > > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > > > Hi, > > > > New draft is available which is Fast multicast protocol. > > > > This document defines the Fast Multicast Protocol for Mobile IPv6 [2] > > in the Fast Handovers environments whereby a mobile node (MN) can > > receive multicast data with reduced loss and delay after handoffs. > > > > Please refer to following document. > > > > sincerely, Kyungjoo Suh (Joo) > > > > > > > > ============================================================================ ======================= > > > > > > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > -------------------------------------------------------------------------- ------ > > > > > > To: IETF-Announce: ; Subject: I-D > > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at > > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to: > > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org > > > > -------------------------------------------------------------------------- ------ > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh > > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : > > 2004-2-6 This document defines the Fast Multicast Protocol for > > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile > > node (MN) can receive multicast data with reduced loss and delay > > after handoffs. The proposed protocol can be implemented by the > > simple modification of the Fast Handovers protocol [1] so that it can > > be easily applied to the Fast Handovers for Mobile IPv6. This > > document does not need a certain assumption of a specific multicast > > routing protocol, so that any existing multicast routing protocol can > > be used with the proposed protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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. > > > > > > > > > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 20:06:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11511 for ; Wed, 3 Mar 2004 20:06:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhJj-0004jQ-CX for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 20:06:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2416RpM018187 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 20:06:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhJi-0004jG-PL for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 20:06:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11427 for ; Wed, 3 Mar 2004 20:06:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhJg-00028d-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:06:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhIY-0001uy-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:05:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyhHP-0001hQ-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:04:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhHO-0004Uf-91; Wed, 03 Mar 2004 20:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhHD-0004TO-6Y for mip6@optimus.ietf.org; Wed, 03 Mar 2004 20:03:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11239 for ; Wed, 3 Mar 2004 20:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhHB-0001YP-00 for mip6@ietf.org; Wed, 03 Mar 2004 20:03:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhG1-0001Je-00 for mip6@ietf.org; Wed, 03 Mar 2004 20:02:38 -0500 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1AyhF5-000158-00 for mip6@ietf.org; Wed, 03 Mar 2004 20:01:39 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU100G0Q1HW97@mailout3.samsung.com> for mip6@ietf.org; Thu, 04 Mar 2004 10:01:08 +0900 (KST) Received: from ep_ms7_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU100LPZ1HEW3@mailout3.samsung.com> for mip6@ietf.org; Thu, 04 Mar 2004 10:00:50 +0900 (KST) Received: from ep_spt04 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU100C781HDDW@ms7.samsung.com> for mip6@ietf.org; Thu, 04 Mar 2004 10:00:50 +0900 (KST) Content-return: prohibited Date: Thu, 04 Mar 2004 01:00:59 +0000 (GMT) From: Kyungjoo Suh Subject: Re :Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz8zRyBTdGFu?= =?windows-1252?B?ZGFyZHMgUiZhbXA7RCBMYWIuP2VuZ2luZWVy?= To: James Kempf , =?windows-1252?Q?=3F=3F=3F_?= Cc: Thomas Schmidt , "Rod.Walsh@nokia.com " , "mip6@ietf.org " , "mobopts@irtf.org " Reply-to: joo.suh@samsung.com Message-id: <7691622.1078362037466.JavaMail.weblogic@ep_app44> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040304010037420@joo.suh X-MTR: 20040304010037420@joo.suh X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.3 required=5.0 tests=AWL,OPT_HEADER, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT HI, Rod, Thoma, and James, First of all, thank you so much for reviewing the draft. Here I quickly answer for some questions. welcome any comments. How does the PAR learn of the NAR address ? answer : We assume that the proposed scheme is operating on top of FMIPv6. In the FMIPv6 spec. it is assumed that PAR knows the NAR's address. Actually, this problem is not mentioned in the FMIPv6 spec. but left as unsolved problem. The problem is addressed in Seamoby WG. It is related to the CARD (Candidate Access Router Discovery) protocol and the reverse address translation (RAT). Precise information can be obtained from the current draft of the CARD protocol. In this version of draft, we do not address this problem because we are not proposing an enhancement version of FMIPv6 but a mutlicast protocol operating with FMIPv6. Therefore we assumed the same network situations (environments) as it assumed in the FMIPv6 draft. Except this assumption, to know the NAR address in advance, roughly there are two methods that can be applied to the proposed protocol. First, we may explicitly preconfigure or set the address of neighboring AR (this address is the address assigned to the wireless interface of the AR) to each AR. Second, a neighbor AR learning algorithm (NALA) can be used. To learn the neighbor AR's address, MN may send the previous AR's address to its current AR after performing handoff. Using this method, AR can learn the addresses of neighboring ARs. For more precise information on the second method, please refer to the ARIP draft (draft-....). Some discussion on IGMP/MLD-snooping and the role of access points as switches could be appropriate too- to deal with the situation where AP changes but AR does not. answer : In this version of draft, we only assume that the AR has the functionality of a AP to simplify our ideas. In the next version, we will also consider the situations what you mentioned. (draft-ietf-magma-snoop-10.txt : Considerations for IGMP and MLD Snooping Switches) (draft-ietf-magma-igmp-proxy-04.txt : IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")) Security Risks. answer : You're right. We just explain the protocol operation in this version. And we are going to include the solution for security risk in next version. As you mentioned, existing solutions such as MCOP, IGAP, and MAGMA to achieve SSM can be applied to our proposal. But, as I mentioned the operation of the proposed protocol is operating on top of FMIPv6. If FMIPv6 is secure enough, there may be no problems at all what you mentioned. This is because by the secure operations (signalings) of FMIPv6 itself (we think the secure operation of FMIPv6 is not fully addressed in the WG yet). such as secured (AAA passed) Router Solicitation for Proxy, Proxy Router Advertisement, HI, HACK, FBU and etc. The situation (DoS possibilities) happens when the malicious HI message is received at NAR not knowing that the message is generated by some attackers. But, the malicious HI messages cannot be generated if only authorized MNs are allowed to perform the FMIPv6 procedure. Even with this assumption (Secure FMIPv6), we admit that there are a lot of security holes that we didn't think of. Tunnelling answer : As mentioned earlier, our proposal is based on the FMIPv6 protocol. In the FMIPv6 protocol, there is a tunnelling scheme between PAR and the NCoA to forwarding data destined to the MN during MN's handoff. The FMIPv6 protocol only explains how create this tunnel. There is no explicit scheme for tunnel destruction. But, I think that the tunnels in the FMIPv6 spec. are soft-state based tunnels as they are in MIPv6. In other words, those tunnels are destroyed after some predefined threshold time for existence. Also we may consider an explicit tunnel destroy mechanism using MLD Done message. In our proposal, MN sends the MLD Done message to the PAR when it start receiving multicast packets directly from NAR. Therefore, PAR can destroy the tunnel when it receives the MLD Done message. However, thanks about your pointing outs. Scope of draft You're right. Our current draft concentrating on solving the multicast receiver problem when it handoffs. We also considered the case when MN becomes a sender. Two distinct mechanisms that we are currently thinking exist for a multicast sender problem. The first solution is a quite primitive one and it is to make MN to use the home-agent based multicast scheme when it is a multicast sender. In the second solution, MN may use the temporal "reverse" tunnel from PAR to MN until NAR finishes the join process to the multicast tree. We have a plan to include the multicast sender situation in the next version. Reference answer : We know that draft-ietf-mobileip-ipv6-24.txt is last version and will be RFC soon. Again, thank you for your comments. best regards, Joo (Kyungjoo Suh) ------- Original Message --------------------------------------------------------------------------------------------------------------------------------------------------------- Sender : James Kempf Date : 2004-03-04 09:30 Title : Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > I quickly read your Internet draft with interest and would like to > > know if you will intend to discuss it on the mobopts mail list? > > > > I have been working on multicast to mobiles for some time and would > > be happy to exchange ideas. > > Actually, we've found it the case of FMIPv4 on 802.11 that the performance for reactive handover is perfectly adequate. There is some slight additional delay and one loses packets during the L2 handover (if the proprietary buffer fowarding at the AP is turned off) but other than that, it works fine. Unfortuantely, I can't send the paper out because it is under consideration for publication. We haven't specifically looked at multicast, but I can't see how it could be a problem. The multicast traffic will get forwarded through the tunnel until the mobile node does MLD for the group with the new router, at which point the routing change will propagate. There is of course an issue with the route propagating, and, in that sense, HMIP might be better if the multicast routing tree is rooted in the MAP. jak > > > > Here are some early thoughts on your document: > > > > The problem and solution seem to do a good job for multicast > > receivers. > > > A matter of debate could be, wether FMIPv6 is a well suited fundament > for multicast distribution. FMIP must be eager to anticipate handovers > (if it will work well), thus exhibiting a significant likelyhood of > wrong predictions. > > In the multicast case this will lead to an unwanted quantity of uneeded > remote subscriptions, unneccessary branches in the multicast trees ... > > ... from our point of view the smoother hmipv6 MAP architecture is much > more appropriate as multicast agents ... > > > How does the PAR learn of the NAR address? (In the sense that: Is > > there something that would be in scope for Multicast Fast Handover, > > that's different from unicast/existing fast handover?) > > > > If we understand correctly: This is just taken from FMIPv6's prediction. > There should be nothing exclusive to multicast. > > > Some discussion on IGMP/MLD-snooping and the role of access points as > > switches could be appropriate too - to deal with the situation where > > AP changes but AR does not. > > Mhmm, this might be more a concern of underlying L2 specification. The > FMIPv6 approach leaves L2 specs to additional documents. > > > > Also, there are several security risks. Of particular trouble are the > > DoS possibilities of setting up state in many "NARs" by a > > broken/malicious "MN", and sending to multiple ARs malicious > > multicast data (e.g. to destroy usability of the "expected service"). > > SSM is worth mentioning and also access control. As far as I am > > certain there are 2 ongoing activities on multicast (AR) access > > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need > > to address the whole access control solution, just explain the impact > > and use for this fast multicast handover. (I guess you already have > > these ideas for the 01 draft :) > > > > Tunnelling multicast from PAR to NAR is not so scalable, this should > > be mentioned. Perhaps suggest a means to time-out these tunnels so > > that the tunnelling is only transitory since using the "PAR" as the > > tunnel other-end point reduces scalability of that AR. > > > Tunneling in this approach only occurs, if NAR refuses to subscribe to > the wanted multicast group ... question is: when will this happen? On > which bases would a NAR decide not to support a specific group? > > Cheers, > > Thomas & Matthias > > > > > > The differentiation between receiver-only, sender-only and > > reciever+sender MNs would be a good discussion item too. For > > instance, I think your solution is great for receivers, but for > > senders (especially send-only non-group-members) it does not solve > > the problem. Perhaps this is just an issue of limiting the scope to > > receiver mobility. Maybe it is currently helping readability to not > > cover sender mobility in this draft, so one option is to consider > > these aspects in a separate draft - at the same time or a later > > stage. > > > > Also, one small NIT: please make it explicit which references are > > normative (essential) and which are informative (I guess all 4 are > > normative)? > > > > Have you had any earlier feedback or discussion on the MIPSHOP (or > > other WG) email lists? > > > > > > Cheers, Rod. > > > > > > > > -----Original Message----- From: mip6-admin@ietf.org > > [mailto:mip6-admin@ietf.org]On Behalf Of ext Kyungjoo Suh Sent: > > Wednesday, March 03, 2004 3:05 PM To: mip6@ietf.org ; ??? Subject: > > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > > > Hi, > > > > New draft is available which is Fast multicast protocol. > > > > This document defines the Fast Multicast Protocol for Mobile IPv6 [2] > > in the Fast Handovers environments whereby a mobile node (MN) can > > receive multicast data with reduced loss and delay after handoffs. > > > > Please refer to following document. > > > > sincerely, Kyungjoo Suh (Joo) > > > > > > > > ============================================================================ ======================= > > > > > > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > -------------------------------------------------------------------------- ------ > > > > > > To: IETF-Announce: ; Subject: I-D > > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at > > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to: > > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org > > > > -------------------------------------------------------------------------- ------ > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh > > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : > > 2004-2-6 This document defines the Fast Multicast Protocol for > > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile > > node (MN) can receive multicast data with reduced loss and delay > > after handoffs. The proposed protocol can be implemented by the > > simple modification of the Fast Handovers protocol [1] so that it can > > be easily applied to the Fast Handovers for Mobile IPv6. This > > document does not need a certain assumption of a specific multicast > > routing protocol, so that any existing multicast routing protocol can > > be used with the proposed protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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. > > > > > > > > > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 20:26:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12615 for ; Wed, 3 Mar 2004 20:26:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhcd-0006Ij-Q5 for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 20:25:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i241PxHs024215 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 20:25:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhcd-0006IU-KY for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 20:25:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12532 for ; Wed, 3 Mar 2004 20:25:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhcb-0005hV-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:25:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayhbh-0005VA-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:25:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayham-0005HT-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:24:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhaj-000675-QL; Wed, 03 Mar 2004 20:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhah-00066g-7b for mip6@optimus.ietf.org; Wed, 03 Mar 2004 20:23:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12316 for ; Wed, 3 Mar 2004 20:23:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhaf-0005GG-00 for mip6@ietf.org; Wed, 03 Mar 2004 20:23:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhZe-00050v-00 for mip6@ietf.org; Wed, 03 Mar 2004 20:22:56 -0500 Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx with esmtp (Exim 4.12) id 1AyhYg-0004eo-00 for mip6@ietf.org; Wed, 03 Mar 2004 20:21:54 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HU100EC62FO1Z@mailout2.samsung.com> for mip6@ietf.org; Thu, 04 Mar 2004 10:21:24 +0900 (KST) Received: from ep_ms7_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU100AXN2BYBI@mailout2.samsung.com> for mip6@ietf.org; Thu, 04 Mar 2004 10:19:10 +0900 (KST) Received: from ep_spt02 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HU100CX72BYDW@ms7.samsung.com> for mip6@ietf.org; Thu, 04 Mar 2004 10:19:10 +0900 (KST) Content-return: prohibited Date: Thu, 04 Mar 2004 01:19:20 +0000 (GMT) From: Kyungjoo Suh Subject: Re :Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz8zRyBTdGFu?= =?windows-1252?B?ZGFyZHMgUiZhbXA7RCBMYWIuP2VuZ2luZWVy?= To: Kyungjoo Suh , James Kempf , Thomas Schmidt , "Rod.Walsh@nokia.com " , "mip6@ietf.org " , "mobopts@irtf.org " Reply-to: joo.suh@samsung.com Message-id: <4971616.1078363140064.JavaMail.weblogic@ep_app24> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20040304011900053@joo.suh X-MTR: 20040304011900053@joo.suh X-EPLocale: ko_KR.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,OPT_HEADER, PRIORITY_NO_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT HI, Rod, Thoma, and James, First of all, thank you so much for reviewing the draft. Here I quickly answer for some questions. welcome any comments. How does the PAR learn of the NAR address ? answer : We assume that the proposed scheme is operating on top of FMIPv6. In the FMIPv6 spec. it is assumed that PAR knows the NAR's address. Actually, this problem is not mentioned in the FMIPv6 spec. but left as unsolved problem. The problem is addressed in Seamoby WG. It is related to the CARD (Candidate Access Router Discovery) protocol and the reverse address translation (RAT). Precise information can be obtained from the current draft of the CARD protocol. In this version of draft, we do not address this problem because we are not proposing an enhancement version of FMIPv6 but a mutlicast protocol operating with FMIPv6. Therefore we assumed the same network situations (environments) as it assumed in the FMIPv6 draft. Except this assumption, to know the NAR address in advance, roughly there are two methods that can be applied to the proposed protocol. First, we may explicitly preconfigure or set the address of neighboring AR (this address is the address assigned to the wireless interface of the AR) to each AR. Second, a neighbor AR learning algorithm (NALA) can be used. To learn the neighbor AR's address, MN may send the previous AR's address to its current AR after performing handoff. Using this method, AR can learn the addresses of neighboring ARs. For more precise information on the second method, please refer to the ARIP draft (draft-....). Some discussion on IGMP/MLD-snooping and the role of access points as switches could be appropriate too- to deal with the situation where AP changes but AR does not. answer : In this version of draft, we only assume that the AR has the functionality of a AP to simplify our ideas. In the next version, we will also consider the situations what you mentioned. (draft-ietf-magma-snoop-10.txt : Considerations for IGMP and MLD Snooping Switches) (draft-ietf-magma-igmp-proxy-04.txt : IGMP/MLD-based Multicast Forwarding ("IGMP/MLD Proxying")) Security Risks. answer : You're right. We just explain the protocol operation in this version. And we are going to include the solution for security risk in next version. As you mentioned, existing solutions such as MCOP, IGAP, and MAGMA to achieve SSM can be applied to our proposal. But, as I mentioned the operation of the proposed protocol is operating on top of FMIPv6. If FMIPv6 is secure enough, there may be no problems at all what you mentioned. This is because by the secure operations (signalings) of FMIPv6 itself (we think the secure operation of FMIPv6 is not fully addressed in the WG yet). such as secured (AAA passed) Router Solicitation for Proxy, Proxy Router Advertisement, HI, HACK, FBU and etc. The situation (DoS possibilities) happens when the malicious HI message is received at NAR not knowing that the message is generated by some attackers. But, the malicious HI messages cannot be generated if only authorized MNs are allowed to perform the FMIPv6 procedure. Even with this assumption (Secure FMIPv6), we admit that there are a lot of security holes that we didn't think of. Tunnelling answer : As mentioned earlier, our proposal is based on the FMIPv6 protocol. In the FMIPv6 protocol, there is a tunnelling scheme between PAR and the NCoA to forwarding data destined to the MN during MN's handoff. The FMIPv6 protocol only explains how create this tunnel. There is no explicit scheme for tunnel destruction. But, I think that the tunnels in the FMIPv6 spec. are soft-state based tunnels as they are in MIPv6. In other words, those tunnels are destroyed after some predefined threshold time for existence. Also we may consider an explicit tunnel destroy mechanism using MLD Done message. In our proposal, MN sends the MLD Done message to the PAR when it start receiving multicast packets directly from NAR. Therefore, PAR can destroy the tunnel when it receives the MLD Done message. However, thanks about your pointing outs. Scope of draft You're right. Our current draft concentrating on solving the multicast receiver problem when it handoffs. We also considered the case when MN becomes a sender. Two distinct mechanisms that we are currently thinking exist for a multicast sender problem. The first solution is a quite primitive one and it is to make MN to use the home-agent based multicast scheme when it is a multicast sender. In the second solution, MN may use the temporal "reverse" tunnel from PAR to MN until NAR finishes the join process to the multicast tree. We have a plan to include the multicast sender situation in the next version. Reference answer : We know that draft-ietf-mobileip-ipv6-24.txt is last version and will be RFC soon. Again, thank you for your comments. best regards, Joo (Kyungjoo Suh) ------- Original Message --------------------------------------------------------------------------------------------------------------------------------------------------------- Sender : James Kempf Date : 2004-03-04 09:30 Title : Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > I quickly read your Internet draft with interest and would like to > > know if you will intend to discuss it on the mobopts mail list? > > > > I have been working on multicast to mobiles for some time and would > > be happy to exchange ideas. > > Actually, we've found it the case of FMIPv4 on 802.11 that the performance for reactive handover is perfectly adequate. There is some slight additional delay and one loses packets during the L2 handover (if the proprietary buffer fowarding at the AP is turned off) but other than that, it works fine. Unfortuantely, I can't send the paper out because it is under consideration for publication. We haven't specifically looked at multicast, but I can't see how it could be a problem. The multicast traffic will get forwarded through the tunnel until the mobile node does MLD for the group with the new router, at which point the routing change will propagate. There is of course an issue with the route propagating, and, in that sense, HMIP might be better if the multicast routing tree is rooted in the MAP. jak > > > > Here are some early thoughts on your document: > > > > The problem and solution seem to do a good job for multicast > > receivers. > > > A matter of debate could be, wether FMIPv6 is a well suited fundament > for multicast distribution. FMIP must be eager to anticipate handovers > (if it will work well), thus exhibiting a significant likelyhood of > wrong predictions. > > In the multicast case this will lead to an unwanted quantity of uneeded > remote subscriptions, unneccessary branches in the multicast trees ... > > ... from our point of view the smoother hmipv6 MAP architecture is much > more appropriate as multicast agents ... > > > How does the PAR learn of the NAR address? (In the sense that: Is > > there something that would be in scope for Multicast Fast Handover, > > that's different from unicast/existing fast handover?) > > > > If we understand correctly: This is just taken from FMIPv6's prediction. > There should be nothing exclusive to multicast. > > > Some discussion on IGMP/MLD-snooping and the role of access points as > > switches could be appropriate too - to deal with the situation where > > AP changes but AR does not. > > Mhmm, this might be more a concern of underlying L2 specification. The > FMIPv6 approach leaves L2 specs to additional documents. > > > > Also, there are several security risks. Of particular trouble are the > > DoS possibilities of setting up state in many "NARs" by a > > broken/malicious "MN", and sending to multiple ARs malicious > > multicast data (e.g. to destroy usability of the "expected service"). > > SSM is worth mentioning and also access control. As far as I am > > certain there are 2 ongoing activities on multicast (AR) access > > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need > > to address the whole access control solution, just explain the impact > > and use for this fast multicast handover. (I guess you already have > > these ideas for the 01 draft :) > > > > Tunnelling multicast from PAR to NAR is not so scalable, this should > > be mentioned. Perhaps suggest a means to time-out these tunnels so > > that the tunnelling is only transitory since using the "PAR" as the > > tunnel other-end point reduces scalability of that AR. > > > Tunneling in this approach only occurs, if NAR refuses to subscribe to > the wanted multicast group ... question is: when will this happen? On > which bases would a NAR decide not to support a specific group? > > Cheers, > > Thomas & Matthias > > > > > > The differentiation between receiver-only, sender-only and > > reciever+sender MNs would be a good discussion item too. For > > instance, I think your solution is great for receivers, but for > > senders (especially send-only non-group-members) it does not solve > > the problem. Perhaps this is just an issue of limiting the scope to > > receiver mobility. Maybe it is currently helping readability to not > > cover sender mobility in this draft, so one option is to consider > > these aspects in a separate draft - at the same time or a later > > stage. > > > > Also, one small NIT: please make it explicit which references are > > normative (essential) and which are informative (I guess all 4 are > > normative)? > > > > Have you had any earlier feedback or discussion on the MIPSHOP (or > > other WG) email lists? > > > > > > Cheers, Rod. > > > > > > > > -----Original Message----- From: mip6-admin@ietf.org > > [mailto:mip6-admin@ietf.org]On Behalf Of ext Kyungjoo Suh Sent: > > Wednesday, March 03, 2004 3:05 PM To: mip6@ietf.org ; ??? Subject: > > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > > > Hi, > > > > New draft is available which is Fast multicast protocol. > > > > This document defines the Fast Multicast Protocol for Mobile IPv6 [2] > > in the Fast Handovers environments whereby a mobile node (MN) can > > receive multicast data with reduced loss and delay after handoffs. > > > > Please refer to following document. > > > > sincerely, Kyungjoo Suh (Joo) > > > > > > > > ============================================================================ ======================= > > > > > > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > > -------------------------------------------------------------------------- ------ > > > > > > To: IETF-Announce: ; Subject: I-D > > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at > > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to: > > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org > > > > -------------------------------------------------------------------------- ------ > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh > > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : > > 2004-2-6 This document defines the Fast Multicast Protocol for > > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile > > node (MN) can receive multicast data with reduced loss and delay > > after handoffs. The proposed protocol can be implemented by the > > simple modification of the Fast Handovers protocol [1] so that it can > > be easily applied to the Fast Handovers for Mobile IPv6. This > > document does not need a certain assumption of a specific multicast > > routing protocol, so that any existing multicast routing protocol can > > be used with the proposed protocol. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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. > > > > > > > > > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list > > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 20:30:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12832 for ; Wed, 3 Mar 2004 20:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhgU-0006ho-Kp for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 20:29:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i241TwPd025770 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 20:29:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyhgU-0006hZ-FH for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 20:29:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12764 for ; Wed, 3 Mar 2004 20:29:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyhgS-0006OO-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:29:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyhfW-0006Ej-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:28:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhea-00064t-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 20:28:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayheb-0006PM-8W; Wed, 03 Mar 2004 20:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayhdg-0006O5-Bw for mip6@optimus.ietf.org; Wed, 03 Mar 2004 20:27:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12662 for ; Wed, 3 Mar 2004 20:27:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayhde-0005uG-00 for mip6@ietf.org; Wed, 03 Mar 2004 20:27:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayhcp-0005ja-00 for mip6@ietf.org; Wed, 03 Mar 2004 20:26:11 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Ayhc6-0005YX-00; Wed, 03 Mar 2004 20:25:26 -0500 Message-ID: <024d01c40187$a0e79200$5f6115ac@dclkempt40> From: "James Kempf" To: "Christian Vogt" , , , Cc: , References: <1078340649.40462c29dddda@mailhost.ira.uka.de> Date: Wed, 3 Mar 2004 17:25:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Re: Comments on Early Binding Updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Christian, > Yes, Francis, this is true if ingress filtering was universally applied. > Until now, however, this is not the case. The correspondent node should > therefore have a different means - e.g., the CoA test - to determine > whether or not the mobile node is reachable. Mobile IPv6 goes the most > secure way and requires a CoA test *before* CoA registration. If the > CoA-test requirement is to be more relaxed, like with Early Binding > Updates, the correspondent node needs more intelligence to prevent > flooding attacks. One mechanism to provide this intelligence is > Credit-Based Authentication. > Ingress filtering won't work if the MN is trying to bomb someone on its old link. The MN could send off the early BU, then move to a new subnet, leaving the victim on the old subnet subject to the attack. With standard RR, the MN could do the same trick for nodes on its link, but there the MN has some incentive not to, since the impact of a DoS attack on the MN's own traffic may be negative. Also, I've got a little concern about fixed time limits on the traffic restriction, in addition to the other issues you've mentioned here. If the layer 2 handover latency has considerable variability, it may be difficult to gauge the traffic restriction timeout such that a sufficient percentage of mobile nodes get adequate handover performance to maintain user satisfaction. As an example, according to Bill Arbaugh's work, the handover latency for 802.11 ranges anywhere from about 70 to 200 ms. Unless the time limit is outside 99.999% of the variability for the layer 2 handover technology in all kinds of deployments, it might lead to undesirable packet drops. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 21:15:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16289 for ; Wed, 3 Mar 2004 21:15:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiOA-0004Hm-K8 for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242F6LR016467 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiO9-0004HR-LX for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:15:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16225 for ; Wed, 3 Mar 2004 21:15:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiO7-0007it-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 21:15:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiN6-0007Xp-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 21:14:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyiM9-0007Mz-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 21:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiMA-0003qZ-UD; Wed, 03 Mar 2004 21:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiLR-0003iQ-63 for mip6@optimus.ietf.org; Wed, 03 Mar 2004 21:12:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16053 for ; Wed, 3 Mar 2004 21:12:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiLO-0007BM-00 for mip6@ietf.org; Wed, 03 Mar 2004 21:12:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyiKe-0006y6-00 for mip6@ietf.org; Wed, 03 Mar 2004 21:11:28 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AyiJm-0006jL-00 for mip6@ietf.org; Wed, 03 Mar 2004 21:10:35 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AyiIw-00022j-00; Thu, 04 Mar 2004 03:09:42 +0100 Received: from atiswww by irams1.ira.uka.de with local (Exim 3.30 #7 ) id 1AyiIv-0005PS-00; Thu, 04 Mar 2004 03:09:41 +0100 Received: from 210.93.162.110 ([210.93.162.110]) by mailhost.ira.uka.de (IMP) with HTTP for ; Thu, 4 Mar 2004 03:09:41 +0100 Message-ID: <1078366181.40468fe55b264@mailhost.ira.uka.de> Date: Thu, 4 Mar 2004 03:09:41 +0100 From: Christian Vogt To: Suresh Krishnan Cc: Francis.Dupont@enst-bretagne.fr, jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, kempf@docomolabs-usa.com, mip6@ietf.org Subject: Re: [Mip6] Re: Comments on Early Binding Updates References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 210.93.162.110 Content-Transfer-Encoding: 8bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.8 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > > Revealing one's identity is not possible with > > Mobile IPv6... > > In fact it is the exact opposite. The attacking > node's identity WILL ALWAYS be revealed in mobile > ipv6. Did you mean hide instead of reveal? Oh my God, thanks Suresh. Yes, I meant to say "conceal" or "hide one's identity". I guess it was late when I wrote that email... Thanks for pointing to this. - Christian | | Christian Vogt | Institute of Telematics, University of Karlsruhe | www.tm.uka.de/~chvogt/ | ------------------------------------------------------------- This message was sent through ATIS: http://atiswww.ira.uka.de _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 21:36:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18411 for ; Wed, 3 Mar 2004 21:36:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiiX-0000JT-Jh for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 21:36:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i242a9qF001199 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 21:36:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyiiX-0000JG-ES for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 21:36:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18338 for ; Wed, 3 Mar 2004 21:36:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyiiU-0004or-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 21:36:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyihT-0004YD-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 21:35:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyigS-0004Gy-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 21:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyigT-0008E7-Db; Wed, 03 Mar 2004 21:34:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyifX-0007uB-0I for mip6@optimus.ietf.org; Wed, 03 Mar 2004 21:33:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17965 for ; Wed, 3 Mar 2004 21:33:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyifU-00040I-00 for mip6@ietf.org; Wed, 03 Mar 2004 21:33:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyieO-0003b7-00 for mip6@ietf.org; Wed, 03 Mar 2004 21:31:52 -0500 Received: from [203.177.23.162] (helo=eazix-win2ks0.eazix.com) by ietf-mx with esmtp (Exim 4.12) id 1AyidL-0003Fs-00 for mip6@ietf.org; Wed, 03 Mar 2004 21:30:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Mar 2004 10:46:52 +0800 Message-ID: Thread-Topic: QoS documents Thread-Index: AcQBku1nc+rHyY6GQYq60ENErZzx8w== From: "Rodel Miguel" To: Content-Transfer-Encoding: quoted-printable Subject: [Mip6] QoS documents Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, Could someone please point me to the latest QoS papers/drafts/rfc/wg for = MIPv6? I'm currently gathering resources for my research topic. =20 Thank you very much. Best Regards, Rodel _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 3 23:57:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27748 for ; Wed, 3 Mar 2004 23:57:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykum-0008HC-5o for mip6-archive@odin.ietf.org; Wed, 03 Mar 2004 23:56:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i244uubG031808 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 23:56:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykul-0008Gx-UY for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 23:56:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27538 for ; Wed, 3 Mar 2004 23:56:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aykuj-0001Ar-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 23:56:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aykt1-0000fW-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 23:55:08 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AykrK-0000KL-01 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 23:53:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AykhR-00062L-72 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 23:43:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AykhM-0006WR-15; Wed, 03 Mar 2004 23:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aykh0-0006PT-JW for mip6@optimus.ietf.org; Wed, 03 Mar 2004 23:42:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26440 for ; Wed, 3 Mar 2004 23:42:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aykgy-00062Y-00 for mip6@ietf.org; Wed, 03 Mar 2004 23:42:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aykfl-0005kR-00 for mip6@ietf.org; Wed, 03 Mar 2004 23:41:25 -0500 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1Aykeh-0005IR-00 for mip6@ietf.org; Wed, 03 Mar 2004 23:40:19 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i244dcdO028953; Wed, 3 Mar 2004 20:39:39 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i244dYQ03812; Thu, 4 Mar 2004 05:39:34 +0100 (MET) Date: Wed, 3 Mar 2004 20:39:36 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 To: Francis Dupont Cc: Erik Nordmark , Jari Arkko , Christian Vogt , mip6@ietf.org In-Reply-To: "Your message with ID" <200403031247.i23ClYSj061575@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 > => this is the first property, the second is to be immune to > the ingress filtering (the CoA is the source address and is the > address of the victim so the ingress filtering is the proper defense). Are you saying that the source address of the BU must be the (new) CoA? Hmm - maybe that is sufficient in the MIPv6 case (I have multi6 in the back of my head as well, which has a variant of the same issues.) Perhaps the draft discusses this, but when you handle an early binding update, when is "HoA check" in the binding cache updated? In basic MIPv6 this happens when the BU is processed i.e. after that the MN can no longer send packets with the old CoA as the source since the Home Address option check will drop such packets. If the same thing applies in the early binding update case it means that the attacker can not send any "ack" packets to the CN since they would contain the "old" CoA - oops - they would not carry a home address option thus they would not be subject to "the HOA and IP src must match the binding cache" check. Hmm... Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 01:06:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02851 for ; Thu, 4 Mar 2004 01:06:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylzJ-0008J2-Vn for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 01:05:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2465f0I031922 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 01:05:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AylzJ-0008In-Jr for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:05:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02684 for ; Thu, 4 Mar 2004 01:05:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AylzG-0007Hx-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:05:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AylxD-0006fD-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:03:32 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AylvU-0006Am-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:01:44 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AylgB-0006ts-BE for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 00:45:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aylfp-0006jF-B3; Thu, 04 Mar 2004 00:45:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyleR-00069g-Mu for mip6@optimus.ietf.org; Thu, 04 Mar 2004 00:44:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01125 for ; Thu, 4 Mar 2004 00:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyleP-0002p3-00 for mip6@ietf.org; Thu, 04 Mar 2004 00:44:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyldJ-0002Wn-00 for mip6@ietf.org; Thu, 04 Mar 2004 00:42:58 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aylbx-00028s-00; Thu, 04 Mar 2004 00:41:33 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i245erX17814; Thu, 4 Mar 2004 06:40:53 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i245eqSj064280; Thu, 4 Mar 2004 06:40:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040540.i245eqSj064280@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Christian Vogt cc: jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, kempf@docomolabs-usa.com, mip6@ietf.org, mobopts@irtf.org In-reply-to: Your message of Wed, 03 Mar 2004 20:04:09 +0100. <1078340649.40462c29dddda@mailhost.ira.uka.de> Date: Thu, 04 Mar 2004 06:40:52 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mip6] Re: Comments on Early Binding Updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 In your previous mail you wrote: Francis Dupont wrote on misuse of Early Binding Updates for flooding attacks: > > A second reason is that a 3-seconds time limit alone > > does not prevent a malicious node from continually > > refreshing a tentative CoA registration. > > this can be easily solve by some kind of hold-down > mechanism... In this case IMHO the best is just not to > reset the timer on "refresh". Francis, you propose that a mobile node be required to do a standard binding update within each two successive Early Binding Updates. => no, what I suggested is to wait 3 seconds from the first EBU and not to reset this timer to 3 seconds (i.e., let it run down to 0) when other EBUs is received. So a tentative CoA registration can't be refreshed continually for more than 3 seconds. Unfortunately however, an attacker could easily trick this mechanism: It would direct a large data stream towards the attacked victim node for a time slightly shorter than an unconfirmed care-of address's (CoA's) lifetime. => if ingress filtering is used and is effective, it can't. If ingress filtering is not used or is not effective, you are already dead and relaxed/delayed CoA check won't change this. When the unconfirmed CoA is about to expire, the attacker would direct the data stream to itself by means of a standard Binding Update message, and it would immediately re-direct the data stream, by means of an Early Binding Update message, to the attacked victim node. The attacker could repeat this procedure indefinitely. => this doesn't matter. There is another disadvantage of the hold-down mechanism: Suppose a mobile node sends to the correspondent node an Early Binding Update message. Then, all of a sudden, the handover fails, and the mobile node falls back to the original sub-network. In this situation, the mobile node would want to send to the correspondent node another Early Binding Update message, re-updating the correspondent node to the old CoA. With the hold-down mechanism, however, this second Early Binding Update message would be rejected, because there has been no standard binding update between this and the first Early Binding Update message. => this could be a problem with a real hold-down mechanism, but not for my simpler proposal: re-updates are not dropped, they just don't reset the timeout. Note that to remove a binding is not a problem (RO is an optimization), the thing to avoid is to keep an old binding. BTW the draft 24 takes care of this, for instance Kbm is different for deleting bindings... Jari Arkko commented on Credit-Based Authorization: => I am not interested to waste time about ineffective defense against inexistent attacks.. IMO, there are two reason why an attacker may want to use reflection for a flooding attack. First, the attacker may want to reveal its identity. => you mean hide? I can't see why the attacker may want to reveal its identity... Second, the attacker may want to make use of an amplification which comes along with the reflection. => unfortunately the attacker doesn't need any bounded amplification... But if this is the case, there are other, more efficient attacks, which are already possible without Mobile IPv6. => I buy this argument! Francis Dupont wrote: > the important thing is the reflection flood using IPv6 > or Mobile IPv6 with relaxed/delayed CoA test, and the > direct flood using fake source address are *blocked* > by the ingress filtering. Yes, Francis, this is true if ingress filtering was universally applied. => I know it is not universally applied and more I know exactly why... But my point is that when ingress filtering is not applied or is ineffective, you are a setting duck and nasty things can happen even if there is no moblte IPv6 capable correspondent node somewhere. Until now, however, this is not the case. The correspondent node should therefore have a different means - e.g., the CoA test - to determine whether or not the mobile node is reachable. Mobile IPv6 goes the most secure way and requires a CoA test *before* CoA registration. =>note this is true *only* for a common correspondent, not a home agent. If the CoA-test requirement is to be more relaxed, like with Early Binding Updates, the correspondent node needs more intelligence to prevent flooding attacks. => I strongly disagree about this need. I agree that an attacker could bypass ingress filtering, if applied, by using an Alternate CoA option. In other words, the Alternate CoA option could render ingress filtering useless. As you say, Francis, the Alternate CoA option should therefore not be used with Early Binding Updates. I have previously mentioned this on the MIP6 mailing list (February 10, 2004). => this is the only really need! Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 01:30:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05004 for ; Thu, 4 Mar 2004 01:30:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymMc-0004bY-Ny for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 01:29:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246TkQo017700 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 01:29:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymMc-0004bP-BN for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:29:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04852 for ; Thu, 4 Mar 2004 01:29:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymMZ-0004sF-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:29:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymKy-0004NE-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:28:05 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AymJC-0003uk-04 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:26:14 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aym9L-0007TI-Fh for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:16:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aym9K-000373-8s; Thu, 04 Mar 2004 01:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aym8X-0002tV-FF for mip6@optimus.ietf.org; Thu, 04 Mar 2004 01:15:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03900 for ; Thu, 4 Mar 2004 01:15:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aym8U-0001qM-00 for mip6@ietf.org; Thu, 04 Mar 2004 01:15:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aym7b-0001fM-00 for mip6@ietf.org; Thu, 04 Mar 2004 01:14:16 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aym6o-0001Ia-00; Thu, 04 Mar 2004 01:13:26 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i246Clt19360; Thu, 4 Mar 2004 07:12:47 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i246ClSj064381; Thu, 4 Mar 2004 07:12:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040612.i246ClSj064381@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" cc: "Christian Vogt" , jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, mip6@ietf.org, mobopts@irtf.org In-reply-to: Your message of Wed, 03 Mar 2004 17:25:47 PST. <024d01c40187$a0e79200$5f6115ac@dclkempt40> Date: Thu, 04 Mar 2004 07:12:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mip6] Re: Comments on Early Binding Updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 In your previous mail you wrote: Ingress filtering won't work if the MN is trying to bomb someone on its old link. => yes some ingress filtering mechanisms are ineffective when the attacker moves after the launch of its attack but this has nothing to do with using mobile IPv6 for the attack... The MN could send off the early BU, then move to a new subnet, leaving the victim on the old subnet subject to the attack. With standard RR, the MN could do the same trick for nodes on its link, but there the MN has some incentive not to, since the impact of a DoS attack on the MN's own traffic may be negative. => attacks from someone on the same link are a real issue and one way to solve it, SEND, gives near nothing... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 02:00:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07400 for ; Thu, 4 Mar 2004 02:00:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymph-0007s6-BH for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 01:59:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i246xnpQ030254 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 01:59:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymph-0007rt-4y for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 01:59:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07137 for ; Thu, 4 Mar 2004 01:59:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aympd-00036l-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:59:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymoZ-0002sM-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:58:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aymnw-0002fb-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 01:58:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymnw-0007cg-Vi; Thu, 04 Mar 2004 01:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AymnL-0007bh-Ho for mip6@optimus.ietf.org; Thu, 04 Mar 2004 01:57:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06937 for ; Thu, 4 Mar 2004 01:57:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AymnI-0002eB-00 for mip6@ietf.org; Thu, 04 Mar 2004 01:57:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AymmK-0002U4-00 for mip6@ietf.org; Thu, 04 Mar 2004 01:56:20 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aymlb-0002BC-00 for mip6@ietf.org; Thu, 04 Mar 2004 01:55:35 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i246t2t21043; Thu, 4 Mar 2004 07:55:02 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i246t1Sj064509; Thu, 4 Mar 2004 07:55:02 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040655.i246t1Sj064509@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Jari Arkko , Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 In-reply-to: Your message of Wed, 03 Mar 2004 20:39:36 PST. Date: Thu, 04 Mar 2004 07:55:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 In your previous mail you wrote: > => this is the first property, the second is to be immune to > the ingress filtering (the CoA is the source address and is the > address of the victim so the ingress filtering is the proper defense). Are you saying that the source address of the BU must be the (new) CoA? => yes! Hmm - maybe that is sufficient in the MIPv6 case (I have multi6 in the back of my head as well, which has a variant of the same issues.) => I don't know a case where a real alternate CoA is needed or even useful with a common correspondent in Mobile IPv6. If such a case exists for multi-homing, it should be written down to: - analyze possible security issues - avoid that someone proposes to zap this feature to make correspondent code simpler! Perhaps the draft discusses this... => this is for Christian. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 02:11:53 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20344 for ; Thu, 4 Mar 2004 02:11:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn0v-0004KE-3c for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 02:11:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247BPcl016619 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 02:11:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayn0u-0004Jy-Pg for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:11:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20308 for ; Thu, 4 Mar 2004 02:11:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayn0r-0005gs-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 02:11:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayn02-0005WT-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 02:10:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aymza-0005LX-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 02:10:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymzb-0003Yv-EA; Thu, 04 Mar 2004 02:10:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aymyr-0003DE-OX for mip6@optimus.ietf.org; Thu, 04 Mar 2004 02:09:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18223 for ; Thu, 4 Mar 2004 02:09:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aymyo-0005J0-00 for mip6@ietf.org; Thu, 04 Mar 2004 02:09:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aymxt-00056u-00 for mip6@ietf.org; Thu, 04 Mar 2004 02:08:18 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Aymx1-0004tK-00; Thu, 04 Mar 2004 02:07:24 -0500 Message-ID: <03fe01c401b7$671be1e0$5f6115ac@dclkempt40> From: "James Kempf" To: "Francis Dupont" Cc: "Christian Vogt" , , , , References: <200403040612.i246ClSj064381@givry.rennes.enst-bretagne.fr> Date: Wed, 3 Mar 2004 23:07:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Re: Comments on Early Binding Updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > => attacks from someone on the same link are a real issue and > one way to solve it, SEND, gives near nothing... Sure. It wasn't intended to. It's only intended to secure the IP address/L2 address resolution, and router discovery, not third party DoS attacks. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 02:31:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23050 for ; Thu, 4 Mar 2004 02:31:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynJg-0001gO-F7 for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 02:30:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i247Umeo006468 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 02:30:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynJg-0001gF-4g for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 02:30:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22940 for ; Thu, 4 Mar 2004 02:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynJc-0002CC-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 02:30:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynIi-0001pI-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 02:29:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AynHx-0001bN-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 02:29:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynHz-00016Q-OU; Thu, 04 Mar 2004 02:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AynHK-0000oE-TH for mip6@optimus.ietf.org; Thu, 04 Mar 2004 02:28:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22522 for ; Thu, 4 Mar 2004 02:28:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AynHH-0001WD-00 for mip6@ietf.org; Thu, 04 Mar 2004 02:28:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynGH-0001Hq-00 for mip6@ietf.org; Thu, 04 Mar 2004 02:27:17 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AynFE-00013s-00 for mip6@ietf.org; Thu, 04 Mar 2004 02:26:12 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 701F76A906; Thu, 4 Mar 2004 09:26:11 +0200 (EET) Message-ID: <4046D98A.10607@kolumbus.fi> Date: Thu, 04 Mar 2004 09:23:54 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: Francis Dupont , Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >>=> this is the first property, the second is to be immune to >>the ingress filtering (the CoA is the source address and is the >>address of the victim so the ingress filtering is the proper defense). > > > Are you saying that the source address of the BU must be the (new) CoA? > > Hmm - maybe that is sufficient in the MIPv6 case (I have multi6 in the back > of my head as well, which has a variant of the same issues.) Its a necessary but imho insufficient condition that the new care-of address is the source of EBUs. The HAO and the home tests ensure that the victim will always know where the stuff is coming from. Its the same also if I send to him the packets directly. But what we in my opinion should prevent is the amplification, not pure reflection. > Perhaps the draft discusses this, but when you handle an early binding update, > when is "HoA check" in the binding cache updated? > In basic MIPv6 this happens when the BU is processed i.e. after that > the MN can no longer send packets with the old CoA as the source since > the Home Address option check will drop such packets. That's right. > If the same thing applies in the early binding update case it means I think it should. > that the attacker can not send any "ack" packets to the CN since they > would contain the "old" CoA - oops - they would not carry a home address > option thus they would not be subject to "the HOA and IP src must match > the binding cache" check. > Hmm... Well, isn't the sending of the acks already prevented by ingress filtering? I mean if you have ingress filtering, you might not even be able to send the EBU to begin with, let alone spoofed ACKs. However, we are in part trying to build these things so that the lack of ingress filtering doesn't open up the situation for many new attacks. Remember that the victim can have ingress filtering but the attacker not. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 03:02:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26242 for ; Thu, 4 Mar 2004 03:02:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynny-0006p4-9O for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:02:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248258V026214 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:02:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynnw-0006oe-BC for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:02:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26001 for ; Thu, 4 Mar 2004 03:02:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynns-0001Ja-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:02:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynm9-0000mq-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:00:14 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aynkg-0000Tw-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 02:58:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyndQ-0000Gb-Q4 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 02:51:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyndM-0004hS-TL; Thu, 04 Mar 2004 02:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyndB-0004gC-EC for mip6@optimus.ietf.org; Thu, 04 Mar 2004 02:50:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24662 for ; Thu, 4 Mar 2004 02:50:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynd7-0006I6-00 for mip6@ietf.org; Thu, 04 Mar 2004 02:50:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynbz-00061n-00 for mip6@ietf.org; Thu, 04 Mar 2004 02:49:43 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1Aynb9-0005lE-00; Thu, 04 Mar 2004 02:48:51 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i247mAt25110; Thu, 4 Mar 2004 08:48:10 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i247m7Sj064754; Thu, 4 Mar 2004 08:48:07 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040748.i247m7Sj064754@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "James Kempf" cc: "Christian Vogt" , jari.arkko@kolumbus.fi, Erik.Nordmark@sun.com, mip6@ietf.org, mobopts@irtf.org In-reply-to: Your message of Wed, 03 Mar 2004 23:07:46 PST. <03fe01c401b7$671be1e0$5f6115ac@dclkempt40> Date: Thu, 04 Mar 2004 08:48:07 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mip6] Re: Comments on Early Binding Updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 In your previous mail you wrote: > => attacks from someone on the same link are a real issue and > one way to solve it, SEND, gives near nothing... Sure. It wasn't intended to. It's only intended to secure the IP address/L2 address resolution, and router discovery, not third party DoS attacks. => (likely to be ou of the scope :-) The point I tried to raise is that some smart devices can detect attackers which are stealing your address but without what SEND had promised they can't know which are real owners so either are limited to detection or can be misued for DoS (e.g. when they "locked" to the first seen)... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 03:17:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27593 for ; Thu, 4 Mar 2004 03:17:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo2m-00015J-3h for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:17:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248HOur004166 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:17:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo2l-000155-C2 for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:17:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27586 for ; Thu, 4 Mar 2004 03:17:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo2j-0004wy-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:17:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo1r-0004mN-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:16:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo1X-0004bV-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:16:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo1R-0000sY-Fk; Thu, 04 Mar 2004 03:16:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo0h-0000qY-TB for mip6@optimus.ietf.org; Thu, 04 Mar 2004 03:15:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27471 for ; Thu, 4 Mar 2004 03:15:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo0f-0004XF-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:15:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynzj-0004Jb-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:14:15 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Aynym-00046N-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:13:16 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 7AFD56A906; Thu, 4 Mar 2004 10:13:14 +0200 (EET) Message-ID: <4046E491.7070303@kolumbus.fi> Date: Thu, 04 Mar 2004 10:10:57 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Christian Vogt , Erik.Nordmark@sun.com, kempf@docomolabs-usa.com, mip6@ietf.org, mobopts@irtf.org References: <200403040540.i245eqSj064280@givry.rennes.enst-bretagne.fr> In-Reply-To: <200403040540.i245eqSj064280@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Re: Comments on Early Binding Updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.3 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => if ingress filtering is used and is effective, it can't. If ingress > filtering is not used or is not effective, you are already dead and > relaxed/delayed CoA check won't change this. Ah, I think I can see our difference now better. Thanks for the explanation. My view is that there's different levels of being "dead". What I want to prevent is an amplification attack where bad guys can cause a lot more packets to the victims than what they have to send. My current view is that even with no ingress filtering, there is no such clear attack in plain IP which would enable significant amplification. But I may have missed something. I think we can agree that if vulnerability X makes the ingress filtering-less situation much worse ("more dead") than it already is, this would be a problem. Alternatively, your opinion is that the situation is already so bad without ingress filtering that its hopeless, and some increase in vulnerabilities does not matter any more. OTOH, there seems to be a nasty issue with the victims not getting protection from their OWN ingress filter but from the attacker's ingress, if any. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 03:25:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28179 for ; Thu, 4 Mar 2004 03:25:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9p-0001j2-Pz for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:24:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248Ofe2006631 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:24:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9p-0001is-EZ for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:24:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28031 for ; Thu, 4 Mar 2004 03:24:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo9n-0006YV-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:24:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo7y-00060G-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:22:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo6P-0005ZS-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:21:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo6M-0001FS-Nh; Thu, 04 Mar 2004 03:21:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo5d-0001Dc-ON for mip6@optimus.ietf.org; Thu, 04 Mar 2004 03:20:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27744 for ; Thu, 4 Mar 2004 03:20:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo5b-0005Sc-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:20:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo4j-0005Ij-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:19:25 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo3z-00058R-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:18:39 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 8A5C96A906; Thu, 4 Mar 2004 10:18:38 +0200 (EET) Message-ID: <4046E5D5.7080006@kolumbus.fi> Date: Thu, 04 Mar 2004 10:16:21 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Erik Nordmark , Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 References: <200403040804.i2484sSj064874@givry.rennes.enst-bretagne.fr> In-Reply-To: <200403040804.i2484sSj064874@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis Dupont wrote: > In your previous mail you wrote: > > But what we in my opinion > should prevent is the amplification, not pure reflection. > > => this is the detail we disagree: if we prevent pure reflection, > we prevent this attack and all others using the same hole but > which are *reality*, not speculations. I can understand that. But isn't there still a difference? I mean you and I have no power whatsoever to get the service providers to use ingress filtering. But we do have a choice of protocol designs, and there we can have an effect. I agree that if we could make the world ingress filtered, we wouldn't need any of this. But while this is not yet the case, I wouldn't like to let the 5% of the Internet that is not ingress filtered cause even more serious attacks to the rest than they already can do. > => it doesn't matter to get new attacks, it does matter to get no new > attacks which have a definitive advantage over current attacks, e.g. > which defeat ingress filtering by hiding the source address... Agreed. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 03:55:46 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01014 for ; Thu, 4 Mar 2004 03:55:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyodR-0005oK-TX for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 03:55:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248tHpk022332 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:55:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyodR-0005o7-HZ for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:55:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00806 for ; Thu, 4 Mar 2004 03:55:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyodP-0005vC-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:55:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayoc3-0005Vm-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:53:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyobJ-0005HD-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:53:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyoXQ-0001jX-Bg for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoXO-0005Bo-Hk; Thu, 04 Mar 2004 03:49:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoWO-0004wv-QJ for mip6@optimus.ietf.org; Thu, 04 Mar 2004 03:48:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00219 for ; Thu, 4 Mar 2004 03:47:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoWL-0004EW-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:47:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoVD-0003vq-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:46:48 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AyoU4-0003R2-00; Thu, 04 Mar 2004 03:45:36 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i248j2t31835; Thu, 4 Mar 2004 09:45:02 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i248j0Sj065101; Thu, 4 Mar 2004 09:45:00 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040845.i248j0Sj065101@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Christian Vogt , Erik.Nordmark@sun.com, kempf@docomolabs-usa.com, mip6@ietf.org, mobopts@irtf.org In-reply-to: Your message of Thu, 04 Mar 2004 10:10:57 +0200. <4046E491.7070303@kolumbus.fi> Date: Thu, 04 Mar 2004 09:45:00 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Subject: [Mip6] Re: Comments on Early Binding Updates Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 In your previous mail you wrote: > => if ingress filtering is used and is effective, it can't. If ingress > filtering is not used or is not effective, you are already dead and > relaxed/delayed CoA check won't change this. Ah, I think I can see our difference now better. Thanks for the explanation. My view is that there's different levels of being "dead". What I want to prevent is an amplification attack where bad guys can cause a lot more packets to the victims than what they have to send. => I object: what you call an amplification attack causes a number of packets of the same order. Packets are larger (MTU size in place of ACKs) but they don't come for free and are limited to a sending window per correspondent. This for the theory but unfortunately we know what happens in the real world: DDoS attackers use zombies which both give unbound amplification and hide the real origin of the attacks. They don't seem to use reflection even when reflection disperses traffic between sources and the victim. My current view is that even with no ingress filtering, there is no such clear attack in plain IP which would enable significant amplification. => do you ever read the news? so bad without ingress filtering that its hopeless, and some increase in vulnerabilities does not matter any more. => it doesn't matter: using mobile IPv6 has a very bad property for attackers: it makes them easier to track because of the HoA. OTOH, there seems to be a nasty issue with the victims not getting protection from their OWN ingress filter but from the attacker's ingress, if any. => this is a bad thing which has nothing to do with Mobile IPv6... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 06:13:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09379 for ; Thu, 4 Mar 2004 06:13:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayqmg-0003o0-DP for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 06:12:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i24BCwC3014624 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 06:12:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayqmg-0003nn-5g for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 06:12:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09249 for ; Thu, 4 Mar 2004 06:12:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayqmc-0004P7-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 06:12:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayqkb-0003gY-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 06:10:50 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyqiY-0003ET-02 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 06:08:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyqWM-0003yA-M0 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 05:56:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqWK-00012X-Ad; Thu, 04 Mar 2004 05:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyqVl-00010h-Ak for mip6@optimus.ietf.org; Thu, 04 Mar 2004 05:55:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08094 for ; Thu, 4 Mar 2004 05:55:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyqVh-0000li-00 for mip6@ietf.org; Thu, 04 Mar 2004 05:55:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyqV8-0000bw-00 for mip6@ietf.org; Thu, 04 Mar 2004 05:54:50 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AyqUS-0000Km-00 for mip6@ietf.org; Thu, 04 Mar 2004 05:54:08 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i24ArMH16862; Thu, 4 Mar 2004 11:53:22 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i24ArMSj065432; Thu, 4 Mar 2004 11:53:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403041053.i24ArMSj065432@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Erik Nordmark , Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 In-reply-to: Your message of Thu, 04 Mar 2004 10:16:21 +0200. <4046E5D5.7080006@kolumbus.fi> Date: Thu, 04 Mar 2004 11:53:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 In your previous mail you wrote: I can understand that. But isn't there still a difference? I mean you and I have no power whatsoever to get the service providers to use ingress filtering. => IMHO you should talk with some ISP people.. The reason ingress filtering is not universlly deployed is not the one you seems to believe... But we do have a choice of protocol designs, and there we can have an effect. I agree that if we could make the world ingress filtered, we wouldn't need any of this. => we have to make the world ingress filtered because the current attacks are already enough deadly. But while this is not yet the case, I wouldn't like to let the 5% of the Internet that is not ingress filtered cause even more serious attacks to the rest than they already can do. => they already can do more than enough. As I said, we should mainly care to avoid new attacks which cannot be handled by ingress filtering Regards Francis.Dupont@enst-bretagne.fr PS: If I apply your proposed criterion we should kill Mobile IPv6 ASAP: imagine that a bad guy gets control over a home agent, just because it runs our favorite junk OS, and to seem more secure whole HA-MN tunnels are protected by ESP. With a very small number of BUs and IKE DPD the attacker can remotely divert all the traffic destinated to MNs to where he'd like and as this traffic is ESP victim knows only the HA address and can't send TCP RST for instance. PPS: here "control" is control over the AAA system of the HA: it is enough and should be easier and more discrete than full control. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 4 21:19:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28616 for ; Thu, 4 Mar 2004 21:19:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4vW-0002Hf-Sx for mip6-archive@odin.ietf.org; Thu, 04 Mar 2004 21:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i252J2LT008772 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 21:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4vW-0002HP-MX for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 21:19:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28583 for ; Thu, 4 Mar 2004 21:18:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4vT-0007it-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 21:19:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4uU-0007X3-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 21:17:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Az4tZ-0007Lf-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 21:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4ta-00023A-1S; Thu, 04 Mar 2004 21:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Az4si-00021W-3G for mip6@optimus.ietf.org; Thu, 04 Mar 2004 21:16:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28512 for ; Thu, 4 Mar 2004 21:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Az4sf-00079E-00 for mip6@ietf.org; Thu, 04 Mar 2004 21:16:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Az4rc-0006xi-00 for mip6@ietf.org; Thu, 04 Mar 2004 21:15:01 -0500 Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx with smtp (Exim 4.12) id 1Az4qh-0006nD-00 for mip6@ietf.org; Thu, 04 Mar 2004 21:14:03 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.214.240 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 5 Mar 2004 02:14:03 -0000 Message-ID: <00f001c40257$854553e0$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , "Jari Arkko" Cc: "Erik Nordmark" , "Christian Vogt" , References: <200403040804.i2484sSj064874@givry.rennes.enst-bretagne.fr> Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 Date: Thu, 4 Mar 2004 18:13:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis, I am trying to understand your argument better.. > In your previous mail you wrote: > > But what we in my opinion > should prevent is the amplification, not pure reflection. > > => this is the detail we disagree: if we prevent pure reflection, > we prevent this attack and all others using the same hole but > which are *reality*, not speculations. > > I mean if you have ingress filtering, > > => this is the only case which makes sense. > > you might not even > be able to send the EBU to begin with, let alone spoofed ACKs. > > However, we are in part trying to build these things so that the > lack of ingress filtering doesn't open up the situation for many > new attacks. > > => it doesn't matter to get new attacks, it does matter to get no new > attacks which have a definitive advantage over current attacks, e.g. > which defeat ingress filtering by hiding the source address... > I can see your point. Your point is about why would anyone use MIPv6 when one can use plain IPv6 to launch the reflection attack. Using MIPv6 also has a dis-advantage that it exposes the home address of the attacker. But does it mean that we can design protocols with this vulnerability expecting that ingress filtering will get deployed in the future which will automatically solve this problem ? Then why do we have to CoTI/CoT messages at all in the base protocol ? Assume we ban the alternate care-of-address option, and also that ingress filtering will get deployed in the future, does that mean CoT/CoTI is not needed at all ? I don't think that the reason that EBU just limits the attack to a very small amount of time is good enough as the attacker just have to send a lot more EBUs for it to increase the magnitude. -mohan > Regards > > Francis.Dupont@enst-bretagne.fr > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 5 07:31:58 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05362 for ; Fri, 5 Mar 2004 07:31:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzEUC-00082K-WF for mip6-archive@odin.ietf.org; Fri, 05 Mar 2004 07:31:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i25CVSnU030888 for mip6-archive@odin.ietf.org; Fri, 5 Mar 2004 07:31:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzEUC-000827-QS for mip6-web-archive@optimus.ietf.org; Fri, 05 Mar 2004 07:31:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05358 for ; Fri, 5 Mar 2004 07:31:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzEUC-0006qu-00 for mip6-web-archive@ietf.org; Fri, 05 Mar 2004 07:31:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzETG-0006hS-00 for mip6-web-archive@ietf.org; Fri, 05 Mar 2004 07:30:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AzESx-0006Y6-00 for mip6-web-archive@ietf.org; Fri, 05 Mar 2004 07:30:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzESp-0007wb-UB; Fri, 05 Mar 2004 07:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzESJ-0007un-Lw for mip6@optimus.ietf.org; Fri, 05 Mar 2004 07:29:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05324 for ; Fri, 5 Mar 2004 07:29:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzESJ-0006X4-00 for mip6@ietf.org; Fri, 05 Mar 2004 07:29:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzERX-0006NP-00 for mip6@ietf.org; Fri, 05 Mar 2004 07:28:43 -0500 Received: from 94.180.32.202.ts.2iij.net ([202.32.180.94] helo=mail.64translator.com) by ietf-mx with esmtp (Exim 4.12) id 1AzEQt-0006AI-00 for mip6@ietf.org; Fri, 05 Mar 2004 07:28:03 -0500 Received: from bahamas.64translator.com ([10.21.32.3]) by mail.64translator.com (8.12.6p3/8.12.6) with ESMTP id i25CRP40034545 for ; Fri, 5 Mar 2004 21:27:25 +0900 (JST) (envelope-from H.Miyata@jp.yokogawa.com) Received: from [127.0.0.1] (localhost [127.0.0.1]) by bahamas.64translator.com (8.12.9p2/8.12.9) with ESMTP id i25CRGAv059829 for ; Fri, 5 Mar 2004 21:27:20 +0900 (JST) (envelope-from H.Miyata@jp.yokogawa.com) Mime-Version: 1.0 (Apple Message framework v612) Content-Transfer-Encoding: 7bit Message-Id: <7025EC44-6EA0-11D8-96D1-000A95872830@jp.yokogawa.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: mip6@ietf.org From: Hiroshi MIYATA Date: Fri, 5 Mar 2004 21:27:16 +0900 X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Subject: [Mip6] Connectathon MIPv6 test summary Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I put the summary of MIPv6 interoperability test at Connectathon2004. It is not test result, I can not disclose test result due to NDA. Please visit here. http://www.tahi.org/presentation/ Thanks, ...miyata@tahi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Mar 6 12:42:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27642 for ; Sat, 6 Mar 2004 12:42:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfoA-0000FA-Gi for mip6-archive@odin.ietf.org; Sat, 06 Mar 2004 12:41:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26HfsSO000928 for mip6-archive@odin.ietf.org; Sat, 6 Mar 2004 12:41:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Azfo9-0000Et-N1 for mip6-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 12:41:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27518 for ; Sat, 6 Mar 2004 12:41:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Azfo8-0000zh-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:41:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Azfn1-0000hb-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:40:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Azfly-0000Zl-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:39:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Azfly-0003vH-Dp for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:39:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfWw-0006Zb-7C; Sat, 06 Mar 2004 12:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayf8o-0002HW-An for mip6@optimus.ietf.org; Wed, 03 Mar 2004 17:47:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02344 for ; Wed, 3 Mar 2004 17:46:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayf8l-0000UP-00 for mip6@ietf.org; Wed, 03 Mar 2004 17:46:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayf7s-0000FR-00 for mip6@ietf.org; Wed, 03 Mar 2004 17:46:06 -0500 Received: from hermes.rz.fhtw-berlin.de ([141.45.5.100]) by ietf-mx with esmtp (Exim 4.12) id 1Ayf6S-0007ZP-00; Wed, 03 Mar 2004 17:44:36 -0500 Received: from fhtw-berlin.de (APointe-a-Pitre-101-2-3-22.w80-15.abo.wanadoo.fr [80.15.129.22]) (authenticated bits=0) by hermes.rz.fhtw-berlin.de (8.12.11/8.12.2) with ESMTP id i23MiA0q026355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 3 Mar 2004 23:44:23 +0100 (MET) Message-ID: <40465FB5.6080608@fhtw-berlin.de> Date: Wed, 03 Mar 2004 23:44:05 +0100 From: Thomas Schmidt User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rod.Walsh@nokia.com CC: joo.suh@samsung.com, mip6@ietf.org, mobopts@irtf.org Subject: Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Rod, hi Joo, Rod.Walsh@nokia.com wrote: > I quickly read your Internet draft with interest and would like to > know if you will intend to discuss it on the mobopts mail list? > > I have been working on multicast to mobiles for some time and would > be happy to exchange ideas. > > > Here are some early thoughts on your document: > > The problem and solution seem to do a good job for multicast > receivers. > A matter of debate could be, wether FMIPv6 is a well suited fundament for multicast distribution. FMIP must be eager to anticipate handovers (if it will work well), thus exhibiting a significant likelyhood of wrong predictions. In the multicast case this will lead to an unwanted quantity of uneeded remote subscriptions, unneccessary branches in the multicast trees ... ... from our point of view the smoother hmipv6 MAP architecture is much more appropriate as multicast agents ... > How does the PAR learn of the NAR address? (In the sense that: Is > there something that would be in scope for Multicast Fast Handover, > that's different from unicast/existing fast handover?) > If we understand correctly: This is just taken from FMIPv6's prediction. There should be nothing exclusive to multicast. > Some discussion on IGMP/MLD-snooping and the role of access points as > switches could be appropriate too - to deal with the situation where > AP changes but AR does not. Mhmm, this might be more a concern of underlying L2 specification. The FMIPv6 approach leaves L2 specs to additional documents. > > Also, there are several security risks. Of particular trouble are the > DoS possibilities of setting up state in many "NARs" by a > broken/malicious "MN", and sending to multiple ARs malicious > multicast data (e.g. to destroy usability of the "expected service"). > SSM is worth mentioning and also access control. As far as I am > certain there are 2 ongoing activities on multicast (AR) access > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need > to address the whole access control solution, just explain the impact > and use for this fast multicast handover. (I guess you already have > these ideas for the 01 draft :) > > Tunnelling multicast from PAR to NAR is not so scalable, this should > be mentioned. Perhaps suggest a means to time-out these tunnels so > that the tunnelling is only transitory since using the "PAR" as the > tunnel other-end point reduces scalability of that AR. > Tunneling in this approach only occurs, if NAR refuses to subscribe to the wanted multicast group ... question is: when will this happen? On which bases would a NAR decide not to support a specific group? Cheers, Thomas & Matthias > The differentiation between receiver-only, sender-only and > reciever+sender MNs would be a good discussion item too. For > instance, I think your solution is great for receivers, but for > senders (especially send-only non-group-members) it does not solve > the problem. Perhaps this is just an issue of limiting the scope to > receiver mobility. Maybe it is currently helping readability to not > cover sender mobility in this draft, so one option is to consider > these aspects in a separate draft - at the same time or a later > stage. > > Also, one small NIT: please make it explicit which references are > normative (essential) and which are informative (I guess all 4 are > normative)? > > Have you had any earlier feedback or discussion on the MIPSHOP (or > other WG) email lists? > > > Cheers, Rod. > > > > -----Original Message----- From: mip6-admin@ietf.org > [mailto:mip6-admin@ietf.org]On Behalf Of ext Kyungjoo Suh Sent: > Wednesday, March 03, 2004 3:05 PM To: mip6@ietf.org ; ??? Subject: > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > > Hi, > > New draft is available which is Fast multicast protocol. > > This document defines the Fast Multicast Protocol for Mobile IPv6 [2] > in the Fast Handovers environments whereby a mobile node (MN) can > receive multicast data with reduced loss and delay after handoffs. > > Please refer to following document. > > sincerely, Kyungjoo Suh (Joo) > > > > =================================================================================================== > > > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt > > -------------------------------------------------------------------------------- > > > To: IETF-Announce: ; Subject: I-D > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to: > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org > > -------------------------------------------------------------------------------- > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date : > 2004-2-6 This document defines the Fast Multicast Protocol for > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile > node (MN) can receive multicast data with reduced loss and delay > after handoffs. The proposed protocol can be implemented by the > simple modification of the Fast Handovers protocol [1] so that it can > be easily applied to the Fast Handovers for Mobile IPv6. This > document does not need a certain assumption of a specific multicast > routing protocol, so that any existing multicast routing protocol can > be used with the proposed protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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-suh-mipshop-fmcast-mip6-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. > > > > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Mar 6 12:42:28 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27685 for ; Sat, 6 Mar 2004 12:42:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfoH-0000I1-Oy for mip6-archive@odin.ietf.org; Sat, 06 Mar 2004 12:42:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26Hg19d001096 for mip6-archive@odin.ietf.org; Sat, 6 Mar 2004 12:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfoH-0000HX-AR for mip6-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 12:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27546 for ; Sat, 6 Mar 2004 12:41:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzfoF-00010h-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzfnD-0000jK-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:40:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Azfm0-0000Zl-04 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:39:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AzfhM-0003pQ-GY for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:34:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfWx-0006aU-Av; Sat, 06 Mar 2004 12:24:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayv7P-000891-7N for mip6@optimus.ietf.org; Thu, 04 Mar 2004 10:50:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28046 for ; Thu, 4 Mar 2004 10:50:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv7M-0003ky-00 for mip6@ietf.org; Thu, 04 Mar 2004 10:50:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayv6R-0003YC-00 for mip6@ietf.org; Thu, 04 Mar 2004 10:49:39 -0500 Received: from hermes.rz.fhtw-berlin.de ([141.45.5.100]) by ietf-mx with esmtp (Exim 4.12) id 1Ayv5Y-0003LO-00; Thu, 04 Mar 2004 10:48:44 -0500 Received: from fhtw-berlin.de (APointe-a-Pitre-101-2-3-22.w80-15.abo.wanadoo.fr [80.15.129.22]) (authenticated bits=0) by hermes.rz.fhtw-berlin.de (8.12.11/8.12.2) with ESMTP id i24FmUla006492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Mar 2004 16:48:33 +0100 (MET) Message-ID: <40474FCB.6020607@fhtw-berlin.de> Date: Thu, 04 Mar 2004 16:48:27 +0100 From: Thomas Schmidt User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Rod.Walsh@nokia.com, joo.suh@samsung.com, mip6@ietf.org, mobopts@irtf.org Subject: Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt References: <40465FB5.6080608@fhtw-berlin.de> <01ae01c4017f$f412be80$5f6115ac@dclkempt40> In-Reply-To: <01ae01c4017f$f412be80$5f6115ac@dclkempt40> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.67+CVS20040221, clamav-milter version 0.66n Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.2 required=5.0 tests=AWL,OPT_HEADER autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Jak, James Kempf wrote: > > Actually, we've found it the case of FMIPv4 on 802.11 that the performance > for reactive handover is perfectly adequate. There is some slight additional > delay and one loses packets during the L2 handover (if the proprietary > buffer fowarding at the AP is turned off) but other than that, it works > fine. Yes, basically the predictive handover delay / time of packet loss is (approximately) proportional to (RTT(PAR,NAR) - L2-handoff), if routers are not too close to each other. On the contrary, reactive handover delay is (approximately) proportional to (RTT(PAR,NAR)/2 + L2-handoff). (see reference to ICN04 in http://www.rz.fhtw-berlin.de/projekte/ipv6/mipv6.html) >Unfortuantely, I can't send the paper out because it is under > consideration for publication. Does the paper already carry a title (so we can whatch out?) So then you can cite our paper ;) > We haven't specifically looked at multicast, > but I can't see how it could be a problem. The multicast traffic will get > forwarded through the tunnel until the mobile node does MLD for the group > with the new router, at which point the routing change will propagate. The idea of the fmcast is to do a predictive remote subscription, which would be clearly neat, if there wasn't the issue with routing ... This routing issue becomes even more apparent if you look at multicast senders: the erection of a source tree for a moving source is heavy weight and may take up to the order of minutes. We don't want to initiate this with every (micromobile) handover or, even worse, without use. > There > is of course an issue with the route propagating, and, in that sense, HMIP > might be better if the multicast routing tree is rooted in the MAP. Maybe you want to take a look at ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-schmidt-waehlisch-mhmipv6-01.txt. cheers thomas & matthias _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Mar 6 12:42:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27707 for ; Sat, 6 Mar 2004 12:42:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfoH-0000I0-OG for mip6-archive@odin.ietf.org; Sat, 06 Mar 2004 12:42:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26Hg1xB001098 for mip6-archive@odin.ietf.org; Sat, 6 Mar 2004 12:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfoG-0000HW-N1 for mip6-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 12:42:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27543 for ; Sat, 6 Mar 2004 12:41:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzfoF-00010c-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:41:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzfnC-0000jC-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:40:55 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Azfm0-0000Zl-03 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:39:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Azfi5-0003qT-VK for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:35:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfWv-0006ZR-CR; Sat, 06 Mar 2004 12:24:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyYXM-0006fi-1W for mip6@optimus.ietf.org; Wed, 03 Mar 2004 10:43:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06064 for ; Wed, 3 Mar 2004 10:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyYXJ-0004zo-00 for mip6@ietf.org; Wed, 03 Mar 2004 10:43:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyYWE-0004h9-00 for mip6@ietf.org; Wed, 03 Mar 2004 10:42:47 -0500 Received: from myra.general.services.metu.edu.tr ([144.122.144.147]) by ietf-mx with esmtp (Exim 4.12) id 1AyYUj-0004Eg-00; Wed, 03 Mar 2004 10:41:14 -0500 Received: from metu.edu.tr (ee-167-166.eee.metu.edu.tr [144.122.167.166]) by myra.general.services.metu.edu.tr (8.11.7/8.11.7) with ESMTP id i23FeU700784; Wed, 3 Mar 2004 17:40:32 +0200 (EET) Message-ID: <4045FBB0.1080002@metu.edu.tr> Date: Wed, 03 Mar 2004 17:37:20 +0200 From: Buyurman Baykal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Updated CFP for Med-Hoc-Net 2004 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We apologize if you receive multiple copies of this message ------------------------------------------------------------------------------ ANNOUNCEMENTS: - PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004. - PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM ------------------------------------------------------------------------------ Med-Hoc-Net 2004 The Third Annual Mediterranean Ad Hoc Networking Workshop June 27-30, 2004, Bodrum, Turkey http://www.medhoc04/diit/unict.it Call for Papers ------------------------------------------------------------------------------ Scope: Ad hoc network applications are emerging continuously imposing their own stringent constraints which cannot be fulfilled by generic approaches and thus spur new research efforts. Therefore, ad hoc networks attract growing attention from the research community. The aim of Med-Hoc-Net 2004 is to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the globe to share their ideas, views, results, and experiences in the field of ad-hoc networking and communications. Med-Hoc-Net 2004 will include presentations of theoretical and experimental achievements, innovative ad-hoc systems, prototyping efforts, case studies, and advancements in technology directly affecting ad-hoc networking and communications infrastructures. The papers solicited in Med-Hoc-Net 2004 cover a variety of topics including but not limited to: - Novel ad-hoc network architectures and applications, - Sensor network applications and protocols, - Implementations, testbeds, and prototypes, - Interfacing ad-hoc systems with different networks, - Resource discovery and management, - Power management and control, - Call admission and traffic shaping policies for ad-hoc networks, - Multimedia location services, - Self organization and network reconfiguration, - Protocols for QoS support in ad-hoc networks, - QoS support in Bluetooth, HIPERLAN, IEEE 802.11 etc., - MAC protocols, scheduling, and radio resource sharing in ad hoc networks, - Unicast and multicast routing algorithms and protocols, - Transport layer protocols for multi-hop networks, - Congestion control, - Performance evaluation of ad-hoc network protocols through simulations, analysis, and measurements, - Security in ad-hoc networks, - Fault tolerance and error recovery - Signal processing algorithms (coding, compression) for ad-hoc networks The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be published in the Elsevier Ad Hoc Networks Journal. Manuscripts must be formatted according to the IEEE double-column standard format, except the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 12 pages. NEW: THE PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004 PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM Papers should be submitted in pdf or ps format through EDAS system (http://edas.info) according to the following timetable: Important Dates: Full Paper Electronic Submission: March 12, 2004 Tutorial proposal submission: April 15, 2004 Notification of Acceptance/Rejection: May 3, 2004 Camera ready submission of full papers: May 17, 2004 Tutorial date: June 27, 2004 Conference dates: June 28-30, 2004 Organization Committee: General Chair: Ian F. Akyildiz, Georgia Institute of Technology, USA General Vice Chair: Erdal Cayirci, Istanbul Technical University, TURKEY Technical Program Chairs: Giacomo Morabito, University of Catania, ITALY Eylem Ekici, Ohio State University, USA Tutorial Chairs: Francesca Cuomo, University of Rome - La Sapienza, ITALY Christos Douligeris, University of Piraeus, GREECE Publicity Chairs: Buyurman Baykal, Middle East Technical University, TURKEY Jaudelice Cavalcante de Oliveira, Drexel University, USA Registration Chair: Sebnem Baydere, Yeditepe University, TURKEY Technical Program Committee: Khaldoun Al Agha, Laboratoire de Recherche en Informatique, FRANCE Hamid Aghvami, King's College London, UK Eitan Altman, INRIA, FRANCE Roberto Battiti, University of Trento, ITALY Raouf Boutaba, University of Waterloo, CANADA Walid Dabbous, INRIA, FRANCE Magda El Zarki, University of California at Irvine, USA Luigi Fratta, Politecnico di Milano, ITALY Mario Gerla, UCLA, USA Paul J. M. Havinga, University of Twente, NETHERLANDS Ahmed Helmy, University of Southern California, USA Farouk Kamoun, ENSI, TUNISIA Holger Karl, Technical University of Berlin, GERMANY Ulf Korner, Lund Institute of Technology, SWEDEN Bhaskar Krishnamachari, University of Southern California, USA Marwan Krunz, University of Arizona, USA Albert Levi, Sabanci University, TURKEY Janise McNair, University of Florida, USA Lazaros Merakos, University of Athens, GREECE Ioanis Nikolaidis, University of Alberta, CANADA Ariel Orda, Technion, ISRAEL Sergio Palazzo, University of Catania, ITALY Giovanni Pau, UCLA, USA Chiara Petrioli, University of Rome "La Sapienza", ITALY Andreas Pitsillides, University of Cyprus, CYPRUS Guy Pujolle, LIP6, FRANCE Paolo Santi, CNR, ITALY Adrian Segall, Technion, ISRAEL Ness Shroff, Purdue University, USA Moshe Sidi, Technion, ISRAEL Raghupathy Sivakumar, Georgia Institute of Technology, USA Ioannis Stavrakakis, University of Athens, GREECE Ivan Stojmenovic, University of Ottawa, CANADA Violet R. Syrotiuk, Arizona State University, USA Leandros Tassiulas, University of Thessaly, GREECE Damla Turgut, University of Central Florida, USA Bernhard H. Walke, Aachen University of Technology, GERMANY Wenye Wang, North Carolina State University, USA Michele Zorzi, University of Ferrara, ITALY _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sat Mar 6 12:42:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27727 for ; Sat, 6 Mar 2004 12:42:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfoM-0000IQ-1B for mip6-archive@odin.ietf.org; Sat, 06 Mar 2004 12:42:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i26Hg5VB001132 for mip6-archive@odin.ietf.org; Sat, 6 Mar 2004 12:42:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfoL-0000IB-Nt for mip6-web-archive@optimus.ietf.org; Sat, 06 Mar 2004 12:42:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27569 for ; Sat, 6 Mar 2004 12:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AzfoK-00011G-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:42:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AzfnI-0000kF-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:41:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Azfm2-0000Zl-00 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:39:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Azfci-0003gQ-04 for mip6-web-archive@ietf.org; Sat, 06 Mar 2004 12:30:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AzfWw-0006a8-Pl; Sat, 06 Mar 2004 12:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AygS1-0007rz-Ij for mip6@optimus.ietf.org; Wed, 03 Mar 2004 19:10:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08541 for ; Wed, 3 Mar 2004 19:10:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AygRy-0000L4-00 for mip6@ietf.org; Wed, 03 Mar 2004 19:10:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AygQS-0007io-00 for mip6@ietf.org; Wed, 03 Mar 2004 19:09:21 -0500 Received: from dcs-server2.cs.uiuc.edu ([128.174.252.3]) by ietf-mx with esmtp (Exim 4.12) id 1AygPq-0007Wj-00 for mip6@ietf.org; Wed, 03 Mar 2004 19:08:42 -0500 Received: from brooklyn (brooklyn.cs.uiuc.edu [128.174.244.80]) (authenticated bits=0) by dcs-server2.cs.uiuc.edu (8.12.10/8.12.10) with ESMTP id i2408ZW8026623 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 3 Mar 2004 18:08:42 -0600 (CST) From: "Robin Kravets" To: Date: Wed, 3 Mar 2004 18:08:16 -0600 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Mip6] ACM MobiCom 2004 CFP - Paper registrations due March 8 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable We apologize in advance if you receive multiple copies of this CFP. ---------------------------------------------------------------------- =20 CALL FOR PAPERS =20 MobiCom 2004 The Tenth Annual International Conference on Mobile Computing and Networking =20 September 26 - October 1, 2004 Philadelphia, PA, USA (dates and location are subject to final approval) http://www.sigmobile.org/mobicom/2004/ Sponsored by ACM SIGMOBILE IMPORTANT DATES: Paper registrations due: March 8, 2004 Paper submissions due: March 15, 2004 Notification of acceptance: June 21, 2004 Camera-ready versions due: July 25, 2004 =20 ACM MobiCom 2004, the Tenth Annual International Conference on Mobile Computing and Networking, is the tenth in the series of annual = conferences sponsored by ACM SIGMOBILE and dedicated to addressing the challenges in = the areas of mobile computing and wireless and mobile networking. The = MobiCom conference series serves as the premier international forum addressing networks, systems, algorithms, and applications that support the = symbiosis of mobile computers and wireless networks. MobiCom is a highly = selective, single-track conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. =20 PAPERS: Authors are invited to submit full papers presenting new = research related to the theory or practice of mobile computing and networking. = All submissions must describe original research that is not published or currently under review by another conference or journal. Areas of = interest include, but are 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 - Operating system and middleware support for mobile computing and=20 networking - Distributed systems aspects of mobile computing - New mobile and wireless applications - Integration and interworking of wired and wireless networks=09 - Performance of mobile and wireless networks and systems=20 - Location-dependent applications and protocols - Security and privacy of mobile/wireless systems - Mobile ad hoc and sensor networks - Wireless multimedia systems - Algorithms and protocols for power management and control - Service creation and management environments for mobile/wireless systems =20 The program committee will referee all papers, and accepted papers will = be published in the conference proceedings. Selected papers will appear in = a special issue of the ACM/Kluwer Wireless Networks (WINET) journal. =20 CHALLENGES PAPERS: The conference also solicits short papers (maximum of = 8 pages) that challenge the mobile computing community with revolutionary = new approaches, new technologies, or visionary applications. Such papers = should provide stimulating ideas or grand visions that may open up exciting = avenues of far-reaching future research. Descriptions of new products or simple evolution of existing work are not appropriate as Challenges Papers. Challenges Papers will be reviewed and should be submitted using the = normal submission procedure. The title of such papers must start with the word "Challenges," i.e., "Challenges: ... `rest of the title'." =20 SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically. Authors should prepare a PDF or a PostScript version of their full paper. Papers must be no longer than 15 pages (8 pages for Challenges submissions), font size not smaller than 10 points, and must = fit properly on U.S. "letter"-sized paper (8.5x11 inches) with reasonable margins. Detailed instructions for the paper submission procedure and = format will be available on the conference web pages. The deadline for = registering the title and the abstract of the paper with our electronic submission system is March 8, 2004 and the deadline for submitting the actual paper = is March 15, 2004. All deadlines are 11:59PM EST. All submitted papers will be judged based on their quality through double-blind review process, where the identities of the authors are withheld from the reviewers. Authors should not be identifiable by any = means from the paper or from the PDF or the Postscript file. Guidelines for preparing the paper for blind reviewing, as well as electronic paper submission instructions, will be available on the conference web pages. Submitted or substantially similar papers must not be currently under = review for any other publication. Please direct any questions regarding paper submission to the Program Co-Chairs, Samir Das and Ravi Jain at mobicom_pcchairs@acm.org. =20 TUTORIALS: Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the = instructors and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Co-Chairs, Andrew Campbell (campbell@ee.columbia.edu) and Taieb Znati (tznati@nsf.gov). The = deadline for tutorial proposals is April 05, 2004. =20 PANELS: Panel proposals are solicited 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, Prathima Agrawal (pagrawal@eng.auburn.edu) and Tao Zhang (tao@research.telcordia.com). The deadline for panel proposals is April = 26, 2004. =20 RESEARCH DEMOS AND EXHIBITS: Proposals for research demos are solicited. Proposals should not exceed 3 pages and should include a description of = the demo and equipment to be used. Send proposals to the Research Demo = Chair, Elizabeth Belding-Royer (ebelding@cs.ucsb.edu). The deadline for demo proposals is July 12, 2004. We are also planning an Expo featuring = exhibits of the latest mobile computing products and services. STUDENT POSTER SESSION: Student posters are solicited that present = recent and on-going research by students on mobile computing and mobile and wireless networking topics. Student posters should not exceed 2 pages = and should include a description of the student's research. See above for = paper formatting requirements. Accepted posters will be put on the conference = web page; however, they will not be printed in the conference proceedings. = Send poster submissions to the Student Poster Co-Chairs, Chiara Petrioli (petrioli@di.uniroma1.it) and Stefano Basagni (basagni@ece.neu.edu). The deadline for student posters is July 12, 2004. BEST STUDENT PAPER AWARD: Papers with a student as a primary author will = be considered for the Best Student Paper Award, with a cash award of 1000 = USD. Students must indicate with their submission that they would like to be considered for this award. The student author of the awarded paper is expected to present the paper at the conference. =20 GENERAL CHAIR Zygmunt Haas Cornell University =20 PROGRAM CO-CHAIRS Samir R. Das Stony Brook University, SUNY =20 Ravi Jain DoCoMo USA Labs STEERING COMMITTEE CHAIR Imrich Chlamtac University of Texas at Dallas ACM PROGRAM DIRECTOR Ginger Ignatoff Additional committee members will be announced on the conference web = page. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Mar 7 13:07:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28475 for ; Sun, 7 Mar 2004 13:07:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B02ff-0006Qn-80 for mip6-archive@odin.ietf.org; Sun, 07 Mar 2004 13:06:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i27I6dKW024720 for mip6-archive@odin.ietf.org; Sun, 7 Mar 2004 13:06:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B02fe-0006Qd-MB for mip6-web-archive@optimus.ietf.org; Sun, 07 Mar 2004 13:06:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28407 for ; Sun, 7 Mar 2004 13:06:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B02fc-0004ag-00 for mip6-web-archive@ietf.org; Sun, 07 Mar 2004 13:06:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B02de-00040E-00 for mip6-web-archive@ietf.org; Sun, 07 Mar 2004 13:04:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B02bg-0003UR-01 for mip6-web-archive@ietf.org; Sun, 07 Mar 2004 13:02:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B02N5-0003so-Qp for mip6-web-archive@ietf.org; Sun, 07 Mar 2004 12:47:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B02Mf-0005af-9k; Sun, 07 Mar 2004 12:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B02M4-0005Ug-A3 for mip6@optimus.ietf.org; Sun, 07 Mar 2004 12:46:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27813 for ; Sun, 7 Mar 2004 12:46:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B02M2-0001V0-00 for mip6@ietf.org; Sun, 07 Mar 2004 12:46:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B02L3-0001Ia-00 for mip6@ietf.org; Sun, 07 Mar 2004 12:45:21 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1B02Jo-00017b-00 for mip6@ietf.org; Sun, 07 Mar 2004 12:44:05 -0500 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by iramx2.ira.uni-karlsruhe.de with smtp (Exim 3.30 #10 (Debian)) id 1B02Jd-0004hC-00; Sun, 07 Mar 2004 18:43:53 +0100 Message-ID: <02dd01c4046b$c24dd8f0$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: "Mohan Parthasarathy" Cc: "Francis Dupont" , "Jari Arkko" , "Erik Nordmark" , References: <200403040804.i2484sSj064874@givry.rennes.enst-bretagne.fr> <00f001c40257$854553e0$6401a8c0@adithya> Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 Date: Sun, 7 Mar 2004 18:43:52 +0100 Organization: Institute of Telematics, University of Karlsruhe (TH) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.7 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 PiBJIGRvbid0IHRoaW5rIHRoYXQgdGhlIHJlYXNvbiB0aGF0IEVCVSBqdXN0IGxpbWl0cyANCj4g dGhlIGF0dGFjayB0byBhIHZlcnkgc21hbGwgYW1vdW50IG9mIHRpbWUgaXMgZ29vZA0KPiBlbm91 Z2ggYXMgdGhlIGF0dGFja2VyIGp1c3QgaGF2ZSB0byBzZW5kIGEgbG90IG1vcmUgDQo+IEVCVXMg Zm9yIGl0IHRvIGluY3JlYXNlIHRoZSBtYWduaXR1ZGUuDQoNCg0KSGkgTW9oYW4sDQoNCkkgYWdy ZWUgdGhhdCBzb2xlbHkgbGltaXRpbmcgdGhlIHRpbWUgZHVyaW5nIHdoaWNoIGRhdGEgcGFja2V0 cyBjYW4gYmUgc2VudCB0byBhbiB1bnZlcmlmaWVkIGNhcmUtb2YgYWRkcmVzcyAtIGkuZS4sIGEg Y2FyZS1vZiBhZGRyZXNzIGZvciB3aGljaCBhIGNhcmUtb2YtYWRkcmVzcyB0ZXN0IGhhcyBub3Qg eWV0IGJlZW4gYWNjb21wbGlzaGVkIC0gaXMgaW5zdWZmaWNpZW50IHRvIHByZXZlbnQgZmxvb2Rp bmcgYXR0YWNrcy4gRm9yIHRoaXMgcmVhc29uLCBFYXJseSBCaW5kaW5nIFVwZGF0ZXMgYXBwbHkg YSBtZWNoYW5pc20sIENyZWRpdC1CYXNlZCBBdXRob3JpemF0aW9uLCB0byBlbnN1cmUgdGhhdCB0 aGUgZGF0YSB2b2x1bWUgc2VudCB0byBhIG1vYmlsZSBub2RlIGF0IGFuIHVudmVyaWZpZWQgY2Fy ZS1vZiBhZGRyZXNzIGlzIGxpbWl0ZWQgYnkgdGhlIGVmZm9ydCB3aGljaCB0aGUgbW9iaWxlIG5v ZGUgaGFzIHJlY2VudGx5IHNwZW50IHdoaWxlIGl0cyBjYXJlLW9mIGFkZHJlc3Mgd2FzIHZlcmlm aWVkLg0KDQpJIGdhdmUgYSBwcmVzZW50YXRpb24gb2YgQ3JlZGl0LUJhc2VkIEF1dGhvcml6YXRp b24gZHVyaW5nIHRoZSBNT0JPUFRTLVNlc3Npb24gb2YgdGhlIDU5dGggSUVURiBtZWV0aW5nLiBU aGUgbWVjaGFuaXNtIHdpbGwgYmUgZGV0YWlsZWQgaW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUg SW50ZXJuZXQtRHJhZnQgb24gRWFybHkgQmluZGluZyBVcGRhdGVzLg0KDQpLaW5kIHJlZ2FyZHMs DQoNCg0KLSBDaHJpc3RpYW4NCg0KDQp8DQp8IENocmlzdGlhbiBWb2d0DQp8IEluc3RpdHV0ZSBv ZiBUZWxlbWF0aWNzLCBVbml2ZXJzaXR5IG9mIEthcmxzcnVoZSAoVEgpDQp8IHd3dy50bS51a2Eu ZGUvfmNodm9ndC8NCnwNCg0KDQpNb2hhbiBQYXJ0aGFzYXJhdGh5IHdyb3RlOg0KPiBGcmFuY2lz LA0KPiANCj4gSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB5b3VyIGFyZ3VtZW50IGJldHRlci4u DQo+IA0KPj4gSW4geW91ciBwcmV2aW91cyBtYWlsIHlvdSB3cm90ZToNCj4+IA0KPj4gICAgQnV0 IHdoYXQgd2UgaW4gbXkgb3Bpbmlvbg0KPj4gICAgc2hvdWxkIHByZXZlbnQgaXMgdGhlIGFtcGxp ZmljYXRpb24sIG5vdCBwdXJlIHJlZmxlY3Rpb24uDQo+PiANCj4+ID0+IHRoaXMgaXMgdGhlIGRl dGFpbCB3ZSBkaXNhZ3JlZTogaWYgd2UgcHJldmVudCBwdXJlIHJlZmxlY3Rpb24sDQo+PiB3ZSBw cmV2ZW50IHRoaXMgYXR0YWNrIGFuZCBhbGwgb3RoZXJzIHVzaW5nIHRoZSBzYW1lIGhvbGUgYnV0 DQo+PiB3aGljaCBhcmUgKnJlYWxpdHkqLCBub3Qgc3BlY3VsYXRpb25zLg0KPj4gDQo+PiAgICBJ IG1lYW4gaWYgeW91IGhhdmUgaW5ncmVzcyBmaWx0ZXJpbmcsDQo+PiANCj4+ID0+IHRoaXMgaXMg dGhlIG9ubHkgY2FzZSB3aGljaCBtYWtlcyBzZW5zZS4NCj4+IA0KPj4gICAgeW91IG1pZ2h0IG5v dCBldmVuDQo+PiAgICBiZSBhYmxlIHRvIHNlbmQgdGhlIEVCVSB0byBiZWdpbiB3aXRoLCBsZXQg YWxvbmUgc3Bvb2ZlZCBBQ0tzLg0KPj4gDQo+PiAgICBIb3dldmVyLCB3ZSBhcmUgaW4gcGFydCB0 cnlpbmcgdG8gYnVpbGQgdGhlc2UgdGhpbmdzIHNvIHRoYXQgdGhlDQo+PiAgICBsYWNrIG9mIGlu Z3Jlc3MgZmlsdGVyaW5nIGRvZXNuJ3Qgb3BlbiB1cCB0aGUgc2l0dWF0aW9uIGZvciBtYW55DQo+ PiAgICBuZXcgYXR0YWNrcy4NCj4+IA0KPj4gPT4gaXQgZG9lc24ndCBtYXR0ZXIgdG8gZ2V0IG5l dyBhdHRhY2tzLCBpdCBkb2VzIG1hdHRlciB0byBnZXQgbm8gbmV3DQo+PiBhdHRhY2tzIHdoaWNo IGhhdmUgYSBkZWZpbml0aXZlIGFkdmFudGFnZSBvdmVyIGN1cnJlbnQgYXR0YWNrcywgZS5nLg0K Pj4gd2hpY2ggZGVmZWF0IGluZ3Jlc3MgZmlsdGVyaW5nIGJ5IGhpZGluZyB0aGUgc291cmNlIGFk ZHJlc3MuLi4NCj4+IA0KPiBJIGNhbiBzZWUgeW91ciBwb2ludC4gWW91ciBwb2ludCBpcyBhYm91 dCB3aHkgd291bGQgYW55b25lIHVzZSBNSVB2Ng0KPiB3aGVuIA0KPiBvbmUgY2FuIHVzZSBwbGFp biBJUHY2IHRvIGxhdW5jaCB0aGUgcmVmbGVjdGlvbiBhdHRhY2suIFVzaW5nIE1JUHY2DQo+IGFs c28gaGFzIA0KPiBhIGRpcy1hZHZhbnRhZ2UgdGhhdCBpdCBleHBvc2VzIHRoZSBob21lIGFkZHJl c3Mgb2YgdGhlIGF0dGFja2VyLiBCdXQNCj4gZG9lcyBpdCBtZWFuIHRoYXQgd2UgY2FuIGRlc2ln biBwcm90b2NvbHMgd2l0aCB0aGlzIHZ1bG5lcmFiaWxpdHkNCj4gZXhwZWN0aW5nIHRoYXQgaW5n cmVzcyBmaWx0ZXJpbmcgd2lsbCBnZXQgZGVwbG95ZWQgaW4gdGhlIGZ1dHVyZQ0KPiB3aGljaCB3 aWxsIGF1dG9tYXRpY2FsbHkgc29sdmUgdGhpcyBwcm9ibGVtID8gVGhlbiB3aHkgZG8gd2UgaGF2 ZSB0bw0KPiBDb1RJL0NvVCBtZXNzYWdlcyBhdCBhbGwgaW4gDQo+IHRoZSBiYXNlIHByb3RvY29s ID8gQXNzdW1lIHdlIGJhbiB0aGUgYWx0ZXJuYXRlIGNhcmUtb2YtYWRkcmVzcw0KPiBvcHRpb24s IA0KPiBhbmQgYWxzbyB0aGF0IGluZ3Jlc3MgZmlsdGVyaW5nIHdpbGwgZ2V0IGRlcGxveWVkIGlu IHRoZSBmdXR1cmUsIGRvZXMNCj4gdGhhdCBtZWFuIENvVC9Db1RJIGlzIG5vdCBuZWVkZWQgYXQg YWxsID8gSSBkb24ndCB0aGluayB0aGF0IHRoZQ0KPiByZWFzb24gdGhhdCANCj4gRUJVIGp1c3Qg bGltaXRzIHRoZSBhdHRhY2sgdG8gYSB2ZXJ5IHNtYWxsIGFtb3VudCBvZiB0aW1lIGlzIGdvb2QN Cj4gZW5vdWdoIGFzIHRoZSBhdHRhY2tlciBqdXN0IGhhdmUgdG8gc2VuZCBhIGxvdCBtb3JlIEVC VXMgZm9yIGl0IHRvDQo+IGluY3JlYXNlIHRoZSBtYWduaXR1ZGUuDQo+IA0KPiAtbW9oYW4NCg0K _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 8 13:04:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17322 for ; Mon, 8 Mar 2004 13:04:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0P6a-0003KT-Vx for mip6-archive@odin.ietf.org; Mon, 08 Mar 2004 13:03:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i28I3uZN012796 for mip6-archive@odin.ietf.org; Mon, 8 Mar 2004 13:03:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0P6a-0003KJ-Po for mip6-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 13:03:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17284 for ; Mon, 8 Mar 2004 13:03:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0P6Y-0003OZ-00 for mip6-web-archive@ietf.org; Mon, 08 Mar 2004 13:03:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0P5Y-0003FH-00 for mip6-web-archive@ietf.org; Mon, 08 Mar 2004 13:02:53 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0P50-00035q-00 for mip6-web-archive@ietf.org; Mon, 08 Mar 2004 13:02:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0P4j-00035z-Iw; Mon, 08 Mar 2004 13:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0P4W-00035G-5X for mip6@optimus.ietf.org; Mon, 08 Mar 2004 13:01:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17133 for ; Mon, 8 Mar 2004 13:01:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0P4U-00034I-00 for mip6@ietf.org; Mon, 08 Mar 2004 13:01:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0P3b-0002v9-00 for mip6@ietf.org; Mon, 08 Mar 2004 13:00:51 -0500 Received: from smtp810.mail.sc5.yahoo.com ([66.163.170.80]) by ietf-mx with smtp (Exim 4.12) id 1B0P2k-0002la-00 for mip6@ietf.org; Mon, 08 Mar 2004 12:59:58 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 8 Mar 2004 17:59:57 -0000 Message-ID: <009101c40537$2c4472c0$861167c0@adithya> From: "Mohan Parthasarathy" To: "Christian Vogt" Cc: "Francis Dupont" , "Jari Arkko" , "Erik Nordmark" , References: <200403040804.i2484sSj064874@givry.rennes.enst-bretagne.fr> <00f001c40257$854553e0$6401a8c0@adithya> <02dd01c4046b$c24dd8f0$5347038d@tm.unikarlsruhe.de> Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 Date: Mon, 8 Mar 2004 09:59:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA17134 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > > I don't think that the reason that EBU just limits > > the attack to a very small amount of time is good > > enough as the attacker just have to send a lot more > > EBUs for it to increase the magnitude. > > > Hi Mohan, > > I agree that solely limiting the time during which data packets can be = sent to an unverified care-of address - i.e., a care-of address for which a care-of-address test has not yet been accomplished - = is insufficient to prevent flooding attacks. For this reason, Early Binding Updates apply a mechanism, Credit-Based Authorizati= on, to ensure that the data volume sent to a mobile node at an unverified care-of address is limited by the effort which the mobile n= ode has recently spent while its care-of address was verified. > > I gave a presentation of Credit-Based Authorization during the MOBOPTS-= Session of the 59th IETF meeting. The mechanism will be detailed in the next version of the Internet-Draft on Early Binding Updat= es. > Ok. By limiting the amount of data sent during the "unverified care-of-ad= dress" window, you still want it to be useful for applications that wanted to use EBU. Not k= nowing the details, i will wait for your next version of the draft. -mohan > Kind regards, > > > - Christian > > > | > | Christian Vogt > | Institute of Telematics, University of Karlsruhe (TH) > | www.tm.uka.de/~chvogt/ > | > > > Mohan Parthasarathy wrote: > > Francis, > > > > I am trying to understand your argument better.. > > > >> In your previous mail you wrote: > >> > >> But what we in my opinion > >> should prevent is the amplification, not pure reflection. > >> > >> =3D> this is the detail we disagree: if we prevent pure reflection, > >> we prevent this attack and all others using the same hole but > >> which are *reality*, not speculations. > >> > >> I mean if you have ingress filtering, > >> > >> =3D> this is the only case which makes sense. > >> > >> you might not even > >> be able to send the EBU to begin with, let alone spoofed ACKs. > >> > >> However, we are in part trying to build these things so that the > >> lack of ingress filtering doesn't open up the situation for many > >> new attacks. > >> > >> =3D> it doesn't matter to get new attacks, it does matter to get no = new > >> attacks which have a definitive advantage over current attacks, e.g. > >> which defeat ingress filtering by hiding the source address... > >> > > I can see your point. Your point is about why would anyone use MIPv6 > > when > > one can use plain IPv6 to launch the reflection attack. Using MIPv6 > > also has > > a dis-advantage that it exposes the home address of the attacker. But > > does it mean that we can design protocols with this vulnerability > > expecting that ingress filtering will get deployed in the future > > which will automatically solve this problem ? Then why do we have to > > CoTI/CoT messages at all in > > the base protocol ? Assume we ban the alternate care-of-address > > option, > > and also that ingress filtering will get deployed in the future, does > > that mean CoT/CoTI is not needed at all ? I don't think that the > > reason that > > EBU just limits the attack to a very small amount of time is good > > enough as the attacker just have to send a lot more EBUs for it to > > increase the magnitude. > > > > -mohan > > 2*zT=A8=A5Sx%S=CBLSz=A2z=D7=E8=AE=08m=B6>?=FF 0?=EB_=A2=B8?T=A8=A5T=A9=FF= -+-Sw=E8=FEh=A9 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 8 22:15:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18387 for ; Mon, 8 Mar 2004 22:15:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Xhy-0004Jd-Js for mip6-archive@odin.ietf.org; Mon, 08 Mar 2004 22:15:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i293F6h3016585 for mip6-archive@odin.ietf.org; Mon, 8 Mar 2004 22:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Xhy-0004JL-5D for mip6-web-archive@optimus.ietf.org; Mon, 08 Mar 2004 22:15:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18375 for ; Mon, 8 Mar 2004 22:15:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Xhv-0006xC-00 for mip6-web-archive@ietf.org; Mon, 08 Mar 2004 22:15:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Xgx-0006nF-00 for mip6-web-archive@ietf.org; Mon, 08 Mar 2004 22:14:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Xfz-0006dm-00 for mip6-web-archive@ietf.org; Mon, 08 Mar 2004 22:13:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Xfw-0004Cy-N5; Mon, 08 Mar 2004 22:13:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Xf7-0004BW-G1 for mip6@optimus.ietf.org; Mon, 08 Mar 2004 22:12:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18308 for ; Mon, 8 Mar 2004 22:12:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Xf4-0006UX-00 for mip6@ietf.org; Mon, 08 Mar 2004 22:12:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0XeE-0006M8-00 for mip6@ietf.org; Mon, 08 Mar 2004 22:11:15 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B0Xdp-0006Co-00 for mip6@ietf.org; Mon, 08 Mar 2004 22:10:49 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2835389961; Tue, 9 Mar 2004 05:10:43 +0200 (EET) Message-ID: <404D30EE.1060200@kolumbus.fi> Date: Tue, 09 Mar 2004 04:50:22 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: mip6@ietf.org Subject: Re: [Mip6] comments on draft-haddad-mipv6-omipv6-01.txt References: <200403011229.i21CTCSj054045@givry.rennes.enst-bretagne.fr> In-Reply-To: <200403011229.i21CTCSj054045@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Francis, > however, it becomes negative if it happens that the initial > DH exchange was compromised and is now in control of the binding. > It can perhaps be argued that this attack is hard, because the > attacker would have to be both on the mobile node - correspondent > node and home agent - correspondent node paths. > > => this is the trade-off and as a trade-off it has advantages and > disadvantages. Fair enough. I think that's a reasonable position (even if we still disagree about the seriousness of the disadvantages). In any case, I think it would be useful if we could develop some analysis model that would help quantify the effects in some manner, better than arguing "its good that we prevent attacks later than the lock-on time" or "its bad that attackers can grab an address for a long time". > But this only requires presence on the path from the home > agent to the correspondent node. It is not an issue in RR, since > nodes that are on that path can perform equally bad attacks anyway > and RR limits the vulnerability by requiring that the attack is all > the time on this path. With OMIPv6, the attacker would no longer > need to be on the path permanently, only once. > > => this is *again* the trade-off... And if you'd like to use > shorter lifetime for OMIPv6 you'll get more vulnerability > windows. Perhaps you'd like to adapt the OMIPv6 lifetime > to the strength of the initial mechanism? That's one possibility. Clearly if you had some pre-arranged security association you could set the lifetime infinitely long. I think we agree that in other cases the lifetime should not be infinitely long. > This attack is particularly dangerous for non-mobile nodes. > One would normally not assume that hosts without Mobile IPv6 > support are vulnerable to problems in Mobile IPv6. > > => so one should bann RR which has this unfortunate property. But I'm sure you see the difference here. With RR, the vulnerability exists ~ the time that the attacker is on path. With OMIPv6, the vulnerability exists ~ this amount of time + the lifetime of the DH key. In the assumed scenario, the host is not MIPv6-aware at all, so it would be unable to establish its own BCE and key. This is the kind of thing I think the analysis model should somehow take into account: effects to plain IPv6 nodes, effects to MIPv6 nodes that did establish the BCE in time, effects to nodes that did not, etc. > This vulnerability is serious, because a temporary problem expands > into a more permanent problem, and can affect any IPv6 node even > without Mobile IPv6 support. > > => I agree for the first statement (with something weaker than permanent) > but not for the second which already stands for RR. Ok. > "Recovery mechanism" -attack > > Nodes can reboot and forget their state, > > => IMHO the best is to use stable storage because I don't want to > require longer reboot delays (:-). Note that there are some protocols > to solve this problem, even with very weak assumptions as in RR. Stable storage can help, yes. > Findings in > [draft-aura] make it hard to see an easy way to fix this; basically a > "leap-of-faith" or PBK like approach does not sound suitable for the > RO problem, even if they can be successfully used in, e.g., > application layer protocols. > > => please note that PBKs were introduced in the RO context so > this is your personal opinion only. Of course. > => an AAA infrastructure covering the mobile and correspondent nodes > is a very strong assumption. Sure. I was just listing other possibilities. > => someone proposed to add a *delayed* binding complete message to > OMIPv6. Perhaps this will make you happy... BTW this adds no real > security too. I'd have to see the specific proposal. But I suspect that if we are going to do improved RR mechanisms, we are going to see a number of proposals, learn their mistakes and propose better mechanisms in the next round. We've already seen this in the case of draft-vogt which at the beginning had a problem which is now being addressed. I think that the long-term effect of a successful attack in OMIPv6 is a showstopper. But perhaps there's some modification of the approach that makes this problem go away? > As I have said before on the list in other contexts, IMHO it would be > good if people who feel there are significant issues would document > these issues and make it possible for the rest of us to review the > findings. Existing analysis in e.g. draft-nikander and in the old > design team notes points to very similar risks that exist for > on-path attackers anyway. > > => direct reflection attacks are easier than (mis)using mobile IPv6 RO > and there are still some people which are afraid when you'd like to > remove/delayed/etc the care-of test... (:-) I'm personally happy as long as we don't introduce additional amplification. But I agree that people will worry about things, so that's why its really important to address concerns that come up, e.g. fixed delay => credit-debit. Other than that, I'm not sure what else we can do, except see if the proposals stand up after exposing them to review and thinking for some time. If you remember the initial RR designs, many of them were eventually shown to be problematic in one way or the other. > > long shared secret > > Hmm... I think the length is not the issue here. Generally in > cryptography we feel relatively safe after a certain key length. > In base MIPv6, this is 20 octets for the Kbm. I don't think we > need more. > > => there are two reasons to be long: > - long enough to be immune to the brute force attack > - each time you use a secret you reveal something about it, i.e., > you consume its entropy. The 20 octets of the Kbm are used > in a very small number of times, this is not the case for Once to be exact... > the Kabm even IMHO you should not have to refresh it (by > a new D-H exchange signed by the previous Kabm). Well, I agree that refresh is necessary if a very large number of uses is needed. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 9 19:27:30 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09266 for ; Tue, 9 Mar 2004 19:27:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rYr-0006QR-OY for mip6-archive@odin.ietf.org; Tue, 09 Mar 2004 19:27:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2A0R1ol024694 for mip6-archive@odin.ietf.org; Tue, 9 Mar 2004 19:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rYr-0006Q3-5m for mip6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 19:27:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09260 for ; Tue, 9 Mar 2004 19:26:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0rYp-0004O0-00 for mip6-web-archive@ietf.org; Tue, 09 Mar 2004 19:26:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0rXs-0004Em-00 for mip6-web-archive@ietf.org; Tue, 09 Mar 2004 19:26:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0rX0-000468-00 for mip6-web-archive@ietf.org; Tue, 09 Mar 2004 19:25:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0rWx-0006Jt-2m; Tue, 09 Mar 2004 19:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0eyc-00020U-Bv for mip6@optimus.ietf.org; Tue, 09 Mar 2004 06:00:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20306 for ; Tue, 9 Mar 2004 06:00:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0eyY-00077w-00 for mip6@ietf.org; Tue, 09 Mar 2004 06:00:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0exb-0006wZ-00 for mip6@ietf.org; Tue, 09 Mar 2004 05:59:45 -0500 Received: from myra.general.services.metu.edu.tr ([144.122.144.147]) by ietf-mx with esmtp (Exim 4.12) id 1B0ex5-0006kV-00; Tue, 09 Mar 2004 05:59:11 -0500 Received: from metu.edu.tr (ee-167-166.eee.metu.edu.tr [144.122.167.166]) by myra.general.services.metu.edu.tr (8.11.7/8.11.7) with ESMTP id i29AwS717213; Tue, 9 Mar 2004 12:58:29 +0200 (EET) Message-ID: <404DA29F.6080901@metu.edu.tr> Date: Tue, 09 Mar 2004 12:55:27 +0200 From: Buyurman Baykal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Last CFP for Med-Hoc-Net 2004 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,LINES_OF_YELLING autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We apologize if you receive multiple copies of this message ---------------------------------------------------------------------- ANNOUNCEMENTS: **Deadline Approaching** - PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004. - PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM ---------------------------------------------------------------------- Med-Hoc-Net 2004 The Third Annual Mediterranean Ad Hoc Networking Workshop June 27-30, 2004, Bodrum, Turkey http://www.medhoc04.diit.unict.it Call for Papers ---------------------------------------------------------------------- Scope: Ad hoc network applications are emerging continuously imposing their own stringent constraints which cannot be fulfilled by generic approaches and thus spur new research efforts. Therefore, ad hoc networks attract growing attention from the research community. The aim of Med-Hoc-Net 2004 is to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the globe to share their ideas, views, results, and experiences in the field of ad-hoc networking and communications. Med-Hoc-Net 2004 will include presentations of theoretical and experimental achievements, innovative ad-hoc systems, prototyping efforts, case studies, and advancements in technology directly affecting ad-hoc networking and communications infrastructures. The papers solicited in Med-Hoc-Net 2004 cover a variety of topics including but not limited to: - Novel ad-hoc network architectures and applications, - Sensor network applications and protocols, - Implementations, testbeds, and prototypes, - Interfacing ad-hoc systems with different networks, - Resource discovery and management, - Power management and control, - Call admission and traffic shaping policies for ad-hoc networks, - Multimedia location services, - Self organization and network reconfiguration, - Protocols for QoS support in ad-hoc networks, - QoS support in Bluetooth, HIPERLAN, IEEE 802.11 etc., - MAC protocols, scheduling, and radio resource sharing in ad hoc networks, - Unicast and multicast routing algorithms and protocols, - Transport layer protocols for multi-hop networks, - Congestion control, - Performance evaluation of ad-hoc network protocols through simulations, analysis, and measurements, - Security in ad-hoc networks, - Fault tolerance and error recovery - Signal processing algorithms (coding, compression) for ad-hoc networks The program committee will referee all papers, and accepted papers will be published in the conference proceedings. Papers of particular merit will be published in the Elsevier Ad Hoc Networks Journal. Manuscripts must be formatted according to the IEEE double-column standard format, except the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 12 pages. NEW: THE PAPER SUBMISSION DEADLINE IS EXTENDED TO MARCH 12, 2004 PAPERS WILL BE SUBMITTED THROUGH EDAS SYSTEM Papers should be submitted in pdf or ps format through EDAS system (http://edas.info) according to the following timetable: Important Dates: Full Paper Electronic Submission: March 12, 2004 Tutorial proposal submission: April 15, 2004 Notification of Acceptance/Rejection: May 3, 2004 Camera ready submission of full papers: May 17, 2004 Tutorial date: June 27, 2004 Conference dates: June 28-30, 2004 Organization Committee: General Chair: Ian F. Akyildiz, Georgia Institute of Technology, USA General Vice Chair: Erdal Cayirci, Istanbul Technical University, TURKEY Technical Program Chairs: Giacomo Morabito, University of Catania, ITALY Eylem Ekici, Ohio State University, USA Tutorial Chairs: Francesca Cuomo, University of Rome - La Sapienza, ITALY Christos Douligeris, University of Piraeus, GREECE Publicity Chairs: Buyurman Baykal, Middle East Technical University, TURKEY Jaudelice Cavalcante de Oliveira, Drexel University, USA Registration Chair: Sebnem Baydere, Yeditepe University, TURKEY Technical Program Committee: Khaldoun Al Agha, Laboratoire de Recherche en Informatique, FRANCE Hamid Aghvami, King's College London, UK Eitan Altman, INRIA, FRANCE Roberto Battiti, University of Trento, ITALY Raouf Boutaba, University of Waterloo, CANADA Walid Dabbous, INRIA, FRANCE Magda El Zarki, University of California at Irvine, USA Luigi Fratta, Politecnico di Milano, ITALY Mario Gerla, UCLA, USA Paul J. M. Havinga, University of Twente, NETHERLANDS Ahmed Helmy, University of Southern California, USA Farouk Kamoun, ENSI, TUNISIA Holger Karl, Technical University of Berlin, GERMANY Ulf Korner, Lund Institute of Technology, SWEDEN Bhaskar Krishnamachari, University of Southern California, USA Marwan Krunz, University of Arizona, USA Albert Levi, Sabanci University, TURKEY Janise McNair, University of Florida, USA Lazaros Merakos, University of Athens, GREECE Ioanis Nikolaidis, University of Alberta, CANADA Ariel Orda, Technion, ISRAEL Sergio Palazzo, University of Catania, ITALY Giovanni Pau, UCLA, USA Chiara Petrioli, University of Rome "La Sapienza", ITALY Andreas Pitsillides, University of Cyprus, CYPRUS Guy Pujolle, LIP6, FRANCE Paolo Santi, CNR, ITALY Adrian Segall, Technion, ISRAEL Ness Shroff, Purdue University, USA Moshe Sidi, Technion, ISRAEL Raghupathy Sivakumar, Georgia Institute of Technology, USA Ioannis Stavrakakis, University of Athens, GREECE Ivan Stojmenovic, University of Ottawa, CANADA Violet R. Syrotiuk, Arizona State University, USA Leandros Tassiulas, University of Thessaly, GREECE Damla Turgut, University of Central Florida, USA Bernhard H. Walke, Aachen University of Technology, GERMANY Wenye Wang, North Carolina State University, USA Michele Zorzi, University of Ferrara, ITALY _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 10 17:28:29 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10483 for ; Wed, 10 Mar 2004 17:28:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CBF-0005RT-Uk for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 17:28:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2AMS1Z4020913 for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 17:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1CBF-0005RE-Mt for mip6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 17:28:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10474 for ; Wed, 10 Mar 2004 17:27:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1CBD-0000bM-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 17:27:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1CAG-0000T1-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 17:27:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1C9e-0000KQ-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 17:26:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1C9J-0005JZ-VD; Wed, 10 Mar 2004 17:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1C8K-0005Fx-Va for mip6@optimus.ietf.org; Wed, 10 Mar 2004 17:25:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10391 for ; Wed, 10 Mar 2004 17:24:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1C8I-0000B0-00 for mip6@ietf.org; Wed, 10 Mar 2004 17:24:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1C7N-00002W-00 for mip6@ietf.org; Wed, 10 Mar 2004 17:24:02 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1C6x-0007hI-00 for mip6@ietf.org; Wed, 10 Mar 2004 17:23:35 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2AMN3O09035; Wed, 10 Mar 2004 14:23:03 -0800 X-mProtect: <200403102223> 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 smtpdUItpCY; Wed, 10 Mar 2004 14:23:01 PST Message-ID: <404F953C.96235103@iprg.nokia.com> Date: Wed, 10 Mar 2004 14:22:52 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mobile IPv6 Mailing List CC: "Basavaraj Patil (NTC/Dallas)" , Gopal Dommety Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Preconfigured Kbm as working group document Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello folks, I would like to request that the following document be considered as a working group document: "Preconfigured Binding Management Keys for Mobile IPv6" draft-perkins-mip6-precfgKbm-00.txt This short document was discussed at the recent IETF meeting, and the basic idea has been discussed sporadically several times in the past. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 10 21:44:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22104 for ; Wed, 10 Mar 2004 21:44:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GB5-0002Pw-8Y for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 21:44:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B2i7Cx009288 for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 21:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GB5-0002Pj-38 for mip6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 21:44:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22075 for ; Wed, 10 Mar 2004 21:44:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GB2-0000w9-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 21:44:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GA3-0000mJ-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 21:43:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1G93-0000ZY-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 21:42:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1G93-0002Gz-Vv; Wed, 10 Mar 2004 21:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1G8O-0002GU-Js for mip6@optimus.ietf.org; Wed, 10 Mar 2004 21:41:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21996 for ; Wed, 10 Mar 2004 21:41:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1G8L-0000UB-00 for mip6@ietf.org; Wed, 10 Mar 2004 21:41:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1G7e-0000Kj-00 for mip6@ietf.org; Wed, 10 Mar 2004 21:40:34 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B1G6i-0007mz-00 for mip6@ietf.org; Wed, 10 Mar 2004 21:39:36 -0500 content-class: urn:content-classes:message Subject: RE: [Mip6] Preconfigured Kbm as working group document Date: Wed, 10 Mar 2004 21:38:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip6] Preconfigured Kbm as working group document X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQG7rFqKYXP9MQASKyzDSGj3kHVYgAIe01w From: "Soliman Hesham" To: "Charles E. Perkins" , "Mobile IPv6 Mailing List" Cc: "Basavaraj Patil (NTC/Dallas)" , "Gopal Dommety" Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I have a couple of questions: - We discussed this before for the base spec and=20 I believe it was suggested that a CoA test would=20 be needed, thoughts? - What's the max lifetime for the BSA in this scenario? I didn't see anything in the draft about that. - Why does the draft say that if nonces exist the "MAY be ignored" ? shouldn't they just be ignored? under what circumstances are the nonces acceptable? Thanks, Hesham > -----Original Message----- > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On Behalf Of > Charles E. Perkins > Sent: Wednesday, March 10, 2004 5:23 PM > To: Mobile IPv6 Mailing List > Cc: Basavaraj Patil (NTC/Dallas); Gopal Dommety > Subject: [Mip6] Preconfigured Kbm as working group document >=20 >=20 >=20 > Hello folks, >=20 > I would like to request that the following document > be considered as a working group document: > "Preconfigured Binding Management Keys for Mobile IPv6" > draft-perkins-mip6-precfgKbm-00.txt >=20 > This short document was discussed at the recent > IETF meeting, and the basic idea has been discussed > sporadically several times in the past. >=20 > Regards, > Charlie P. >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 10 22:02:41 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22737 for ; Wed, 10 Mar 2004 22:02:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GSb-00035w-HU for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 22:02:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B32Dmb011890 for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 22:02:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GSb-00035h-C7 for mip6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 22:02:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22700 for ; Wed, 10 Mar 2004 22:02:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GSY-0003Sa-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:02:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GRa-0003Ii-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:01:10 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1GQY-00039G-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:00:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GQW-0002xr-LC; Wed, 10 Mar 2004 22:00:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GPh-0002vo-0k for mip6@optimus.ietf.org; Wed, 10 Mar 2004 21:59:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22580 for ; Wed, 10 Mar 2004 21:59:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GPd-00030c-00 for mip6@ietf.org; Wed, 10 Mar 2004 21:59:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GOk-0002s8-00 for mip6@ietf.org; Wed, 10 Mar 2004 21:58:15 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1GOG-0002ih-00 for mip6@ietf.org; Wed, 10 Mar 2004 21:57:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2B2vB925574; Wed, 10 Mar 2004 18:57:11 -0800 X-mProtect: <200403110257> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14175.americas.nokia.com (172.18.141.75, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFVRgjB; Wed, 10 Mar 2004 18:57:09 PST Message-ID: <404FD57B.2000401@iprg.nokia.com> Date: Wed, 10 Mar 2004 18:56:59 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "Charles E. Perkins" , Mobile IPv6 Mailing List , "Basavaraj Patil (NTC/Dallas)" , Gopal Dommety Subject: Re: [Mip6] Preconfigured Kbm as working group document References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi Hesham, Soliman Hesham wrote: > I have a couple of questions: > > - We discussed this before for the base spec and > I believe it was suggested that a CoA test would > be needed, thoughts? did you see the Security Considerations section of the draft? > A correspondent node and a mobile node MAY use a preconfigured > binding management key (Kbm) to manage the authentication > requirements for binding cache management messages. Such keys must > be handled carefully to avoid inadvertent exposure to the threats > outlined in [2]. > A mobile node MUST use a different binding management key (Kbm) > for each node in its Binding Update List. This ensures that the > sender of a Binding Update can always be uniquely determined. This > is necessary, as this authorization method does not provide any > guarantee that the given care-of address is legitimate. > For the same > reason, this method SHOULD only be applied between nodes that are > under the same administration. The return routability procedure is > RECOMMENDED for all general use and MUST be the default, unless the > user explicitly overrides this by entering a key for a particular > peer. if the CN does not trust the MN not to misbehave, then it shouldnt use this mechanism. it should use return routability. > - Why does the draft say that if nonces exist the "MAY be > ignored" ? shouldn't they just be ignored? under what circumstances > are the nonces acceptable? the actual text says > The Nonce Indices option SHOULD NOT > be present. If it is present, the nonce indices supplied MAY be > ignored do you want the packet dropped and an ICMP error generated? Vijay ps: the draft is available at http://people.nokia.net/charliep/txt/mobilev6/precfg.txt > > Thanks, > Hesham > > > -----Original Message----- > > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org]On Behalf Of > > Charles E. Perkins > > Sent: Wednesday, March 10, 2004 5:23 PM > > To: Mobile IPv6 Mailing List > > Cc: Basavaraj Patil (NTC/Dallas); Gopal Dommety > > Subject: [Mip6] Preconfigured Kbm as working group document > > > > > > > > Hello folks, > > > > I would like to request that the following document > > be considered as a working group document: > > "Preconfigured Binding Management Keys for Mobile IPv6" > > draft-perkins-mip6-precfgKbm-00.txt > > > > This short document was discussed at the recent > > IETF meeting, and the basic idea has been discussed > > sporadically several times in the past. > > > > Regards, > > Charlie P. > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 10 22:07:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23009 for ; Wed, 10 Mar 2004 22:07:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GXL-0003Rq-Qc for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 22:07:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B3777M013243 for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 22:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GXL-0003RQ-E8 for mip6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 22:07:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22962 for ; Wed, 10 Mar 2004 22:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GXI-0004LO-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:07:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GWJ-0004Ah-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:06:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1GVI-0003u0-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:05:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GVL-0003Hh-1M; Wed, 10 Mar 2004 22:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1GUe-0003GS-Ar for mip6@optimus.ietf.org; Wed, 10 Mar 2004 22:04:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22857 for ; Wed, 10 Mar 2004 22:04:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1GUb-0003rw-00 for mip6@ietf.org; Wed, 10 Mar 2004 22:04:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1GU4-0003ik-00 for mip6@ietf.org; Wed, 10 Mar 2004 22:03:45 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B1GTF-0003Ug-00 for mip6@ietf.org; Wed, 10 Mar 2004 22:02:53 -0500 content-class: urn:content-classes:message Subject: RE: [Mip6] Preconfigured Kbm as working group document Date: Wed, 10 Mar 2004 22:02:23 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip6] Preconfigured Kbm as working group document X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQHFI52YBuyc6ilTUCq/9aefbt9hQAAMRwg From: "Soliman Hesham" To: "Vijay Devarapalli" Cc: "Charles E. Perkins" , "Mobile IPv6 Mailing List" , "Basavaraj Patil (NTC/Dallas)" , "Gopal Dommety" Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Vijay, > > A correspondent node and a mobile node MAY use a preconfigured > > binding management key (Kbm) to manage the authentication > > requirements for binding cache management messages. =20 > Such keys must > > be handled carefully to avoid inadvertent exposure to=20 > the threats > > outlined in [2]. >=20 > > A mobile node MUST use a different binding management key (Kbm) > > for each node in its Binding Update List. This ensures that the > > sender of a Binding Update can always be uniquely=20 > determined. This > > is necessary, as this authorization method does not provide any > > guarantee that the given care-of address is legitimate. >=20 > > For the same > > reason, this method SHOULD only be applied between=20 > nodes that are > > under the same administration. The return routability=20 > procedure is > > RECOMMENDED for all general use and MUST be the=20 > default, unless the > > user explicitly overrides this by entering a key for a=20 > particular > > peer. >=20 > if the CN does not trust the MN not to misbehave, then it > shouldnt use this mechanism. it should use return routability. =3D> I read this section, but I think your conclusion is not clear and is not reflected by the text. For instance, being under the same administration does not imply "trust" (which is conditional in itself). A public access network may be under the same administration but operators don't typically trust subscribers to always do the right thing,=20 especially when you consider anonymous subscriptions ..etc. >=20 > > - Why does the draft say that if nonces exist the "MAY be > > ignored" ? shouldn't they just be ignored? under what circumstances > > are the nonces acceptable? >=20 > the actual text says >=20 > > The Nonce Indices option SHOULD NOT > > be present. If it is present, the nonce indices supplied MAY be > > ignored >=20 > do you want the packet dropped and an ICMP error generated? =3D> This seems like an appropriate reply, unless there=20 is a reason that a packet can be accepted with nonce indices.=20 > ps: the draft is available at=20 > http://people.nokia.net/charliep/txt/mobilev6/precfg.txt =3D> It's on the IETF web page as well. Hesham >=20 > >=20 > > Thanks, > > Hesham > >=20 > > > -----Original Message----- > > > From: mip6-admin@ietf.org=20 > [mailto:mip6-admin@ietf.org]On Behalf Of > > > Charles E. Perkins > > > Sent: Wednesday, March 10, 2004 5:23 PM > > > To: Mobile IPv6 Mailing List > > > Cc: Basavaraj Patil (NTC/Dallas); Gopal Dommety > > > Subject: [Mip6] Preconfigured Kbm as working group document > > >=20 > > >=20 > > >=20 > > > Hello folks, > > >=20 > > > I would like to request that the following document > > > be considered as a working group document: > > > "Preconfigured Binding Management Keys for Mobile IPv6" > > > draft-perkins-mip6-precfgKbm-00.txt > > >=20 > > > This short document was discussed at the recent > > > IETF meeting, and the basic idea has been discussed > > > sporadically several times in the past. > > >=20 > > > Regards, > > > Charlie P. > > >=20 > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip6 > > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 10 22:28:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23626 for ; Wed, 10 Mar 2004 22:28:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gru-0004yY-H1 for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 22:28:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B3SMUm019125 for mip6-archive@odin.ietf.org; Wed, 10 Mar 2004 22:28:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gru-0004yO-B6 for mip6-web-archive@optimus.ietf.org; Wed, 10 Mar 2004 22:28:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23603 for ; Wed, 10 Mar 2004 22:28:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Grr-0007IP-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:28:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Gqx-00078r-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:27:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1Gqa-0006zJ-00 for mip6-web-archive@ietf.org; Wed, 10 Mar 2004 22:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gqc-0004n8-IE; Wed, 10 Mar 2004 22:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1Gpv-0004dW-4r for mip6@optimus.ietf.org; Wed, 10 Mar 2004 22:26:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23507 for ; Wed, 10 Mar 2004 22:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1Gpr-0006yG-00 for mip6@ietf.org; Wed, 10 Mar 2004 22:26:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1Gov-0006pT-00 for mip6@ietf.org; Wed, 10 Mar 2004 22:25:18 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1Goe-0006gD-00 for mip6@ietf.org; Wed, 10 Mar 2004 22:25:00 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2B3OTt28806; Wed, 10 Mar 2004 19:24:29 -0800 X-mProtect: <200403110324> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14175.americas.nokia.com (172.18.141.75, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHFTJn8; Wed, 10 Mar 2004 19:24:27 PST Message-ID: <404FDBE1.2030901@iprg.nokia.com> Date: Wed, 10 Mar 2004 19:24:17 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: "Charles E. Perkins" , Mobile IPv6 Mailing List , "Basavaraj Patil (NTC/Dallas)" , Gopal Dommety Subject: Re: [Mip6] Preconfigured Kbm as working group document References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > > > A correspondent node and a mobile node MAY use a preconfigured > > > binding management key (Kbm) to manage the authentication > > > requirements for binding cache management messages. > > Such keys must > > > be handled carefully to avoid inadvertent exposure to > > the threats > > > outlined in [2]. > > > > > A mobile node MUST use a different binding management key (Kbm) > > > for each node in its Binding Update List. This ensures that the > > > sender of a Binding Update can always be uniquely > > determined. This > > > is necessary, as this authorization method does not provide any > > > guarantee that the given care-of address is legitimate. > > > > > For the same > > > reason, this method SHOULD only be applied between > > nodes that are > > > under the same administration. The return routability > > procedure is > > > RECOMMENDED for all general use and MUST be the > > default, unless the > > > user explicitly overrides this by entering a key for a > > particular > > > peer. > > > > if the CN does not trust the MN not to misbehave, then it > > shouldnt use this mechanism. it should use return routability. > > => I read this section, but I think your conclusion > is not clear and is not reflected by the text. I think the security considerations section is pretty clear. it says when in doubt dont this mechanism. return routability is the default mechanism and the one that is applicable for general use. > > > - Why does the draft say that if nonces exist the "MAY be > > > ignored" ? shouldn't they just be ignored? under what circumstances > > > are the nonces acceptable? > > > > the actual text says > > > > > The Nonce Indices option SHOULD NOT > > > be present. If it is present, the nonce indices supplied MAY be > > > ignored > > > > do you want the packet dropped and an ICMP error generated? > > => This seems like an appropriate reply, unless there > is a reason that a packet can be accepted with nonce > indices. okay. > > > ps: the draft is available at > > http://people.nokia.net/charliep/txt/mobilev6/precfg.txt > > => It's on the IETF web page as well. I thought it was not available on the IETF website (it had expired in October). I should have checked. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 11 02:05:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07868 for ; Thu, 11 Mar 2004 02:05:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KF2-0005ke-Jk for mip6-archive@odin.ietf.org; Thu, 11 Mar 2004 02:04:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2B74Smg022094 for mip6-archive@odin.ietf.org; Thu, 11 Mar 2004 02:04:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KF0-0005js-TX for mip6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 02:04:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07182 for ; Thu, 11 Mar 2004 02:04:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1KEx-0001Su-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 02:04:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1KE2-0001Kt-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 02:03:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1KDc-0001CC-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 02:03:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KDd-0005Fv-Px; Thu, 11 Mar 2004 02:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1KD1-00052X-Jb for mip6@optimus.ietf.org; Thu, 11 Mar 2004 02:02:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04850 for ; Thu, 11 Mar 2004 02:02:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1KCy-0001BO-00 for mip6@ietf.org; Thu, 11 Mar 2004 02:02:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1KC2-00013I-00 for mip6@ietf.org; Thu, 11 Mar 2004 02:01:23 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B1KBR-0000v9-00 for mip6@ietf.org; Thu, 11 Mar 2004 02:00:45 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2B03C8996E; Thu, 11 Mar 2004 09:00:46 +0200 (EET) Message-ID: <40500E18.6040302@kolumbus.fi> Date: Thu, 11 Mar 2004 08:58:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" Cc: Mobile IPv6 Mailing List , "Basavaraj Patil (NTC/Dallas)" , Gopal Dommety Subject: Re: [Mip6] Preconfigured Kbm as working group document References: <404FDBE1.2030901@iprg.nokia.com> In-Reply-To: <404FDBE1.2030901@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I don't have anything against the preconfigured kbm draft. However, I think it would be appropriate to discuss priorities a little bit. Is the primary purpose of the preconfigured kbm to improve the latency and reduce signaling associated with RR? Or something else? I'm asking because latency/signaling reduction might be solved by one of the optimized RR proposals. We're not there quite yet, probably some revision rounds are needed before any of the current proposals can really be considered for WG items. But assuming we get there, such mechanisms would be much more generally applicable than the preconfigured kbm approach. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 11 12:34:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12463 for ; Thu, 11 Mar 2004 12:34:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1U40-0005Ez-6K for mip6-archive@odin.ietf.org; Thu, 11 Mar 2004 12:33:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2BHXiJ5020139 for mip6-archive@odin.ietf.org; Thu, 11 Mar 2004 12:33:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1U40-0005Ek-0d for mip6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 12:33:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12446 for ; Thu, 11 Mar 2004 12:33:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1U3y-0003FC-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 12:33:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1U34-00037W-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 12:32:47 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1U2N-00030Z-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 12:32:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1U2L-00055U-Oa; Thu, 11 Mar 2004 12:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1U26-00054W-KH for mip6@optimus.ietf.org; Thu, 11 Mar 2004 12:31:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12387 for ; Thu, 11 Mar 2004 12:31:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1U25-0002zM-00 for mip6@ietf.org; Thu, 11 Mar 2004 12:31:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1U1H-0002sJ-00 for mip6@ietf.org; Thu, 11 Mar 2004 12:30:56 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1U0L-0002ee-00 for mip6@ietf.org; Thu, 11 Mar 2004 12:29:57 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2BHTOF32007; Thu, 11 Mar 2004 09:29:24 -0800 X-mProtect: <200403111729> Nokia Silicon Valley Messaging Protection Received: from danira-pool055227.americas.nokia.com (10.241.55.227, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdEyjmCh; Thu, 11 Mar 2004 09:29:22 PST Message-ID: <4050A1E8.1090706@iprg.nokia.com> Date: Thu, 11 Mar 2004 09:29:12 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Hesham, Soliman Hesham wrote: >- We discussed this before for the base spec and >I believe it was suggested that a CoA test would >be needed, thoughts? > > No, because the correspondent node has to have some reason to believe that the mobile node is trustworthy. This is very reasonable for many situations, like between you and your co-workers for instance. Or, since I actually don't know about that, then between me and my co-workers, but I would assume so for you also. >- What's the max lifetime for the BSA in this scenario? >I didn't see anything in the draft about that. > > There isn't any max lifetime defined for the BSA. >- Why does the draft say that if nonces exist the "MAY be >ignored" ? shouldn't they just be ignored? under what circumstances >are the nonces acceptable? > > According to the standards language conventions, "MAY" does not presuppose a list of conditions. It means that the protocol partner must be prepared for the possibility that they be ignored. It means that the sender doesn't have any particularly good reason to include the nonces, but it is not an error to do so. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 11 22:49:33 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15252 for ; Thu, 11 Mar 2004 22:49:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dfW-0005Rh-VU for mip6-archive@odin.ietf.org; Thu, 11 Mar 2004 22:49:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C3n6QA020929 for mip6-archive@odin.ietf.org; Thu, 11 Mar 2004 22:49:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dfW-0005RU-RD for mip6-web-archive@optimus.ietf.org; Thu, 11 Mar 2004 22:49:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15232 for ; Thu, 11 Mar 2004 22:49:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1dfT-00056B-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 22:49:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1deT-0004xC-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 22:48:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1ddW-0004od-00 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 22:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ddU-0005KK-W6; Thu, 11 Mar 2004 22:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1dcv-0005Jo-Vw for mip6@optimus.ietf.org; Thu, 11 Mar 2004 22:46:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15175 for ; Thu, 11 Mar 2004 22:46:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1dcs-0004iE-00 for mip6@ietf.org; Thu, 11 Mar 2004 22:46:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1dbx-0004ZN-00 for mip6@ietf.org; Thu, 11 Mar 2004 22:45:25 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1B1das-0004Hk-00 for mip6@ietf.org; Thu, 11 Mar 2004 22:44:18 -0500 content-class: urn:content-classes:message Subject: RE: [Mip6] Preconfigured Kbm as working group document Date: Thu, 11 Mar 2004 22:43:49 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Topic: [Mip6] Preconfigured Kbm as working group document X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Index: AcQHjmcBycvcksZ4Tiu0WLL7WPLnAgAVDu6g From: "Soliman Hesham" To: "Charles E. Perkins" Cc: "Mobile IPv6 Mailing List" Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > >- We discussed this before for the base spec and=20 > >I believe it was suggested that a CoA test would=20 > >be needed, thoughts? > > =20 > > > No, because the correspondent node has to have some reason > to believe that the mobile node is trustworthy. This is very > reasonable for many situations, like between you and your > co-workers for instance. Or, since I actually don't know > about that, then between me and my co-workers, but I would > assume so for you also. =3D> If this is the intended scenario then it would be=20 helpful to say that in the draft to avoid mistaking it with other types of deployments. I don't have a problem with using it for this purpose. >=20 > >- What's the max lifetime for the BSA in this scenario? > >I didn't see anything in the draft about that. > > =20 > > > There isn't any max lifetime defined for the BSA. =3D> I know, should there be one? or at least should=20 there be a statement that says there is no upper limit (except the size of the field) for the lifetime? If for nothing else, to distinguish this from RR based Kbms. >=20 > >- Why does the draft say that if nonces exist the "MAY be > >ignored" ? shouldn't they just be ignored? under what circumstances > >are the nonces acceptable? > > =20 > > > According to the standards language conventions, "MAY" does not > presuppose a list of conditions. It means that the protocol partner > must be prepared for the possibility that they be ignored. It means > that the sender doesn't have any particularly good reason to include > the nonces, but it is not an error to do so. =3D> It's a matter of taste I think. I prefer to have one way of doing it because it simplifies the implementation of the CN (the part where=20 it receives and processes the BU).=20 Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 00:04:17 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18013 for ; Fri, 12 Mar 2004 00:04:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1epq-0000lk-2r for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 00:03:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C53oWw002956 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 00:03:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1epp-0000lb-SV for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 00:03:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17870 for ; Fri, 12 Mar 2004 00:03:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1epn-0007YV-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 00:03:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1enU-00070v-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 00:01:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1emv-0006rt-02 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 00:00:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1ekE-0000e3-27 for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 23:58:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ekC-0000Iw-LM; Thu, 11 Mar 2004 23:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1ejR-00007B-4P for mip6@optimus.ietf.org; Thu, 11 Mar 2004 23:57:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17692 for ; Thu, 11 Mar 2004 23:57:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1ejO-0006TH-00 for mip6@ietf.org; Thu, 11 Mar 2004 23:57:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1eiS-0006MA-00 for mip6@ietf.org; Thu, 11 Mar 2004 23:56:12 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1ei8-0006FB-00 for mip6@ietf.org; Thu, 11 Mar 2004 23:55:53 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2C4tJF05936; Thu, 11 Mar 2004 20:55:19 -0800 X-mProtect: <200403120455> Nokia Silicon Valley Messaging Protection Received: from danira-pool052205.americas.nokia.com (10.241.52.205, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdVuzpfM; Thu, 11 Mar 2004 20:55:15 PST Message-ID: <405142A8.4020203@iprg.nokia.com> Date: Thu, 11 Mar 2004 20:55:04 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: <404FDBE1.2030901@iprg.nokia.com> <40500E18.6040302@kolumbus.fi> In-Reply-To: <40500E18.6040302@kolumbus.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jari, Jari Arkko wrote: > Is the primary purpose of the preconfigured kbm to improve the > latency and reduce signaling associated with RR? Yes, that's it. > I'm asking because latency/signaling reduction might be solved > by one of the optimized RR proposals. ..... > ..... such mechanisms would be much more > generally applicable than the preconfigured kbm approach. They will be more generally applicable, but generality is not the point of my draft. Simplicity and performance and the fact that the code already exists in most cases, is the point of my draft. It's basically good-tasting fruit that is hanging so low that it is almost falling off the branch if we would just extend our hand to catch it. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 00:04:24 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18130 for ; Fri, 12 Mar 2004 00:04:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1epx-0000nU-Fe for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 00:03:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2C53vI8003058 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 00:03:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1epx-0000nF-B6 for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 00:03:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17906 for ; Fri, 12 Mar 2004 00:03:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1epv-0007a8-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 00:03:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1enh-00072p-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 00:01:37 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1en0-0006rt-01 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 00:00:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1efS-0000We-4R for mip6-web-archive@ietf.org; Thu, 11 Mar 2004 23:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1efN-0008Gq-A7; Thu, 11 Mar 2004 23:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1eeU-0008GQ-Pe for mip6@optimus.ietf.org; Thu, 11 Mar 2004 23:52:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17519 for ; Thu, 11 Mar 2004 23:52:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1eeS-0005t5-00 for mip6@ietf.org; Thu, 11 Mar 2004 23:52:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1edW-0005mi-00 for mip6@ietf.org; Thu, 11 Mar 2004 23:51:06 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1ecZ-0005aA-00 for mip6@ietf.org; Thu, 11 Mar 2004 23:50:07 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2C4nYX30313; Thu, 11 Mar 2004 20:49:34 -0800 X-mProtect: <200403120449> Nokia Silicon Valley Messaging Protection Received: from danira-pool052205.americas.nokia.com (10.241.52.205, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd6vSa2g; Thu, 11 Mar 2004 20:49:30 PST Message-ID: <4051414E.1090108@iprg.nokia.com> Date: Thu, 11 Mar 2004 20:49:18 -0800 From: "Charles E. Perkins" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Hesham, Soliman Hesham wrote: >--DS-3429925659732912225 > > > No, because the correspondent node has to have some reason > > to believe that the mobile node is trustworthy. This is very > > reasonable for many situations, like between you and your > > co-workers for instance. Or, since I actually don't know > > about that, then between me and my co-workers, but I would > > assume so for you also. > >=> If this is the intended scenario then it would be >helpful to say that in the draft to avoid mistaking it >with other types of deployments. I don't have a problem >with using it for this purpose. > > I thought the draft did say that, but I will look to see and make sure. > > There isn't any max lifetime defined for the BSA. > >=> I know, should there be one? or at least should >there be a statement that says there is no upper >limit (except the size of the field) for the lifetime? >If for nothing else, to distinguish this from RR based >Kbms. > > O.K. I will put that in, thanks. > > >- Why does the draft say that if nonces exist the "MAY be > > >ignored" ? shouldn't they just be ignored? under what circumstances > > >are the nonces acceptable? > > > > > > > > According to the standards language conventions, "MAY" does not > > presuppose a list of conditions. It means that the protocol partner > > must be prepared for the possibility that they be ignored. It means > > that the sender doesn't have any particularly good reason to include > > the nonces, but it is not an error to do so. > >=> It's a matter of taste I think. I prefer to >have one way of doing it because it simplifies >the implementation of the CN (the part where >it receives and processes the BU). > > Well, that's fine except unless your platform is different than someone else's platform in a way that causes different views of what is easier. On the other hand, if the ambiguity is viewed as problematic then I don't have a problem one way or the other and if the nonces are strictly disallowed it makes the packet smaller and less processing. But I don't see that as an issue anyway. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 08:04:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18928 for ; Fri, 12 Mar 2004 08:04:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mK7-0004La-Gx for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 08:03:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CD3ZeN016710 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 08:03:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mK7-0004LR-98 for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 08:03:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18925 for ; Fri, 12 Mar 2004 08:03:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1mK6-0007Ux-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 08:03:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1mJ8-0007Nh-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 08:02:35 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1mIe-0007Gc-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 08:02:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mIc-0004E7-5X; Fri, 12 Mar 2004 08:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1mI7-0004CY-5O for mip6@optimus.ietf.org; Fri, 12 Mar 2004 08:01:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18883 for ; Fri, 12 Mar 2004 08:01:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1mI6-0007FW-00 for mip6@ietf.org; Fri, 12 Mar 2004 08:01:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1mHJ-00078y-00 for mip6@ietf.org; Fri, 12 Mar 2004 08:00:42 -0500 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 1B1mGn-0006zi-00 for mip6@ietf.org; Fri, 12 Mar 2004 08:00:09 -0500 Received: from [IPv6:::1] (teldanex.local.nikander.com [192.168.0.194]) by n97.nomadiclab.com (Postfix) with ESMTP id 79EFB8; Fri, 12 Mar 2004 15:12:17 +0200 (EET) In-Reply-To: <405142A8.4020203@iprg.nokia.com> References: <404FDBE1.2030901@iprg.nokia.com> <40500E18.6040302@kolumbus.fi> <405142A8.4020203@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1EC12861-7425-11D8-A780-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Mobile IPv6 Mailing List , Jari Arkko From: Pekka Nikander Subject: Re: [Mip6] Preconfigured Kbm as working group document Date: Fri, 12 Mar 2004 14:59:38 +0200 To: "Charles E. Perkins" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie, > They will be more generally applicable, but generality is not the > point of my draft. Simplicity and performance and the fact that > the code already exists in most cases, is the point of my draft. > It's basically good-tasting fruit that is hanging so low that it is > almost falling off the branch if we would just extend our hand > to catch it. The draft is simple, indeed. Actually, a little bit too simple to my taste. For example, it is not quite so clear about omitting the RR procedure. That is, such an omission is more implied than clearly spelled out. What comes to the taste of this fruit, I admit that the initial taste is very tempting. However, I am a bit worried about the potential aftertaste. That is, I'm afraid that after a couple of years this fruit may get a taste that resembles a well known meat product sold in small tins. This is actually a more generic issue. I am worried about any new protocol that has potential reflection/amplification vulnerabilities and does not have adequate scalable protections. Such protocols are prone to cause nasty DoS problems, which from the economic point of view are the network level equivalent of spam. But you know that well enough. I would suggest that you first produce a strong enough applicability statement, clearly spelling out where the draft would be applicable and what are the potential consequences if a large number of CNs accept preconfigured Kbms with an MN that turns out to be untrustworthy. For example, if there are strong enough assurances about real life traceability of any such MN, then using this kind of optimisation may be ok. However, if such assurances cannot be reached, I would consider this pretty risky, at least if used in the Internet. We have to remember that, in reflection attacks that take place in the Internet, the victims are nodes that do not take part into the mechanism. To add more emotion to the argument (perhaps wrongly), I'd say that we must protect the innocent. --Pekka N. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 09:36:00 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23698 for ; Fri, 12 Mar 2004 09:35:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nl5-0002t6-3R for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 09:35:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CEZVN1011099 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 09:35:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nl4-0002sw-M8 for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 09:35:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23570 for ; Fri, 12 Mar 2004 09:35:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nl2-00056v-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 09:35:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1njf-0004kw-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 09:34:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1nid-0004V8-03 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 09:32:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nfn-0002Xu-FU; Fri, 12 Mar 2004 09:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1nfI-0002Vy-2Q for mip6@optimus.ietf.org; Fri, 12 Mar 2004 09:29:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23275 for ; Fri, 12 Mar 2004 09:29:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1nfG-00047J-00 for mip6@ietf.org; Fri, 12 Mar 2004 09:29:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1neL-00041F-00 for mip6@ietf.org; Fri, 12 Mar 2004 09:28:34 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1B1ndg-0003um-00 for mip6@ietf.org; Fri, 12 Mar 2004 09:27:52 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1B1ndZ-0007Um-00; Fri, 12 Mar 2004 15:27:45 +0100 Received: from i72jerom.tm.uni-karlsruhe.de ([141.3.70.155] helo=i72jerom) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1B1ndY-0005Hm-00; Fri, 12 Mar 2004 15:27:44 +0100 From: "amalek" To: , , , , , , Cc: , "=?iso-8859-1?Q?'Tobias_K=FCfner'?=" Date: Fri, 12 Mar 2004 15:28:24 +0100 Message-ID: <000a01c4083e$46d168a0$9b46038d@tm.unikarlsruhe.de> 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, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Mip6] Question about draft-haddad-mipv6-bub-01 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear BUB authors, We noticed a problem in your draft concerning the source address of the BU. Consider the situation when the BUB test and the DH exchange have been completed successfully. Then your draft says: When MN1 switches to a new network (i.e., gets a new care-of address), it sends a BU message to MN2 on the path going through the two HAs. MN1 MAY duplicate the BU message and another copy on the direct path. What is the source address of the mandatory BU going through the HAs? The HoA? Then, how does the CN determine the CoA? You say "The MNs MUST NOT use the alternate care-of address option in the BU messages". And --- independent from the way the CoA is included in the BU --- why can't a MN bomb/flood a 3rd party this way? The CoA? Then the BU would leave the first HA (i.e. the MN-HA tunnel) with a topologically incorrect source address. If ingress filtering is applied (what you assume, right?), it would be dropped. If ingress filtering is not applied, again, why can't a MN bomb/flood a 3rd party this way? BTW a more general question: Why do you want the BU to go through both HAs? Is it because of what you call "double jumping problem"? Another question: If you assume ingress filtering to be applied everywhere, don't you think we can find a simpler solution --- less complex than DH and RR? And a last question: Why do you think BUB should only be applied to scenarios where both nodes are located in foreign networks? What happens if one of them returns to its home network? Best Regards Abbas and Tobias _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 12:09:08 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03402 for ; Fri, 12 Mar 2004 12:09:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1q9H-0006mR-U4 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 12:08:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CH8dOj026057 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 12:08:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1q9H-0006mC-OZ for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 12:08:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03354 for ; Fri, 12 Mar 2004 12:08:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1q9G-00034w-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 12:08:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1q8S-0002wo-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 12:07:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1q7j-0002p2-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 12:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1q7h-0006Lc-8L; Fri, 12 Mar 2004 12:07:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1q7S-0006KH-0D for mip6@optimus.ietf.org; Fri, 12 Mar 2004 12:06:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03210 for ; Fri, 12 Mar 2004 12:06:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1q7Q-0002nN-00 for mip6@ietf.org; Fri, 12 Mar 2004 12:06:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1q6W-0002fz-00 for mip6@ietf.org; Fri, 12 Mar 2004 12:05:49 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1q5d-0002Qh-00 for mip6@ietf.org; Fri, 12 Mar 2004 12:04:54 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CH4CX16572; Fri, 12 Mar 2004 09:04:12 -0800 X-mProtect: <200403121704> 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 smtpdFRucGP; Fri, 12 Mar 2004 09:04:11 PST Message-ID: <4051ED81.F0305BEC@iprg.nokia.com> Date: Fri, 12 Mar 2004 09:04:01 -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 Nikander CC: Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: <404FDBE1.2030901@iprg.nokia.com> <40500E18.6040302@kolumbus.fi> <405142A8.4020203@iprg.nokia.com> <1EC12861-7425-11D8-A780-000393CE1E8C@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Pekka, Pekka Nikander wrote: > The draft is simple, indeed. Actually, a little bit too > simple to my taste. For example, it is not quite so clear > about omitting the RR procedure. That is, such an omission > is more implied than clearly spelled out. I think, in general, that it's a mistake for protocol specifications to spend a lot of time detailing what is omitted. For instance, I don't specify that the correspondent node does NOT have to be a DHCP relay, or a SIP proxy, just to put it to extreme cases. Worse yet, once a particular omission is identified, then people reasonably start to ask why the other omissions were not identified. Maybe they should have been considered after all, right??? _not_ In this case, simplicity is quite appropriate. > What comes to the taste of this fruit, I admit that the initial > taste is very tempting. However, I am a bit worried about the > potential aftertaste. That is, I'm afraid that after a couple > of years this fruit may get a taste that resembles a well known > meat product sold in small tins. Well, it's not spam. And, moreover, we already have the experience to know that it works. Otherwise, there would be trouble already with Mobile IPv4 and the way home agents are configured. > This is actually a more generic issue. I am worried about any > new protocol that has potential reflection/amplification > vulnerabilities and does not have adequate scalable protections. This is not a new protocol. This is a way to establish a security association between nodes that satisfy certain stringent conditions. There is no protocol. In fact, the technique suggested is, practically speaking, far more secure than return routability. > Such protocols are prone to cause nasty DoS problems, which > from the economic point of view are the network level equivalent > of spam. But you know that well enough. If I knew who was sending me spam, my problems would immediately be improved drastically. > I would suggest that you first produce a strong enough > applicability statement, clearly spelling out where the draft > would be applicable and what are the potential consequences > if a large number of CNs accept preconfigured Kbms with > an MN that turns out to be untrustworthy. You are asking me to state what would happen if the specification were not followed. That leads to a tarpit I intend to avoid. The use case is clear, and anyone who has used the protocol knows it immediately. > We have to remember that, in reflection attacks that take place > in the Internet, the victims are nodes that do not take part > into the mechanism. To add more emotion to the argument (perhaps > wrongly), I'd say that we must protect the innocent. While I agree with your statement, it does not apply to the discussion. The mobile node is always clearly known to the correspondent node, and if your trusted co-worker causes you to bomb the White House with IPv6 packets, you know where to go for redress. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 13:54:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10536 for ; Fri, 12 Mar 2004 13:54:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1rn0-0008KA-53 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 13:53:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CIrkKC031992 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 13:53:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1rmz-0008Jv-V9 for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 13:53:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10494 for ; Fri, 12 Mar 2004 13:53:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1rmx-0003Iq-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 13:53:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1rm4-0003A7-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 13:52:49 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1rlJ-00032f-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 13:52:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1rlI-00089J-PV; Fri, 12 Mar 2004 13:52:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1rkz-00086w-Al for mip6@optimus.ietf.org; Fri, 12 Mar 2004 13:51:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10395 for ; Fri, 12 Mar 2004 13:51:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1rkx-00030J-00 for mip6@ietf.org; Fri, 12 Mar 2004 13:51:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1rk3-0002uH-00 for mip6@ietf.org; Fri, 12 Mar 2004 13:50:44 -0500 Received: from teldanex.hiit.fi ([212.68.5.99] helo=n97.nomadiclab.com) by ietf-mx with esmtp (Exim 4.12) id 1B1rjZ-0002nJ-00 for mip6@ietf.org; Fri, 12 Mar 2004 13:50:14 -0500 Received: from [IPv6:::1] (polle.local.nikander.com [192.168.0.193]) by n97.nomadiclab.com (Postfix) with ESMTP id 1AD818; Fri, 12 Mar 2004 21:02:22 +0200 (EET) In-Reply-To: <4051ED81.F0305BEC@iprg.nokia.com> References: <404FDBE1.2030901@iprg.nokia.com> <40500E18.6040302@kolumbus.fi> <405142A8.4020203@iprg.nokia.com> <1EC12861-7425-11D8-A780-000393CE1E8C@nomadiclab.com> <4051ED81.F0305BEC@iprg.nokia.com> Mime-Version: 1.0 (Apple Message framework v612) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <05BF05E7-7456-11D8-A780-000393CE1E8C@nomadiclab.com> Content-Transfer-Encoding: 7bit Cc: Mobile IPv6 Mailing List From: Pekka Nikander Subject: Re: [Mip6] Preconfigured Kbm as working group document Date: Fri, 12 Mar 2004 20:49:41 +0200 To: "Charles E. Perkins" X-Mailer: Apple Mail (2.612) Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie, >> I would suggest that you first produce a strong enough >> applicability statement... > >> We have to remember that, in reflection attacks that take place >> in the Internet, the victims are nodes that do not take part >> into the mechanism. To add more emotion to the argument (perhaps >> wrongly), I'd say that we must protect the innocent. > > While I agree with your statement, it does not apply > to the discussion. The mobile node is always clearly > known to the correspondent node, and if your trusted > co-worker causes you to bomb the White House with IPv6 > packets, you know where to go for redress. I completely agree with you that so is the case as long as the system is used within a small group of users. A single administrative domain may _not_ be such a small group of users, even though I agree that it usually is. Hence, I still call for a stronger applicability statement and a stronger security considerations sections. But perhaps they could be added as a part of the WG process, if you feel uncomfortable with adding them as an author. --Pekka N. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 14:11:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11470 for ; Fri, 12 Mar 2004 14:11:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s3U-0000vf-59 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 14:10:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CJAm76003565 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 14:10:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s3T-0000vQ-VV for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 14:10:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11421 for ; Fri, 12 Mar 2004 14:10:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1s3R-0005Zq-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:10:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1s2T-0005SU-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:09:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1s1m-0005Li-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:09:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s1m-0000l6-QT; Fri, 12 Mar 2004 14:09:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1s1X-0000k6-Ju for mip6@optimus.ietf.org; Fri, 12 Mar 2004 14:08:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11337 for ; Fri, 12 Mar 2004 14:08:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1s1V-0005Kt-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:08:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1s0b-0005Dx-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:07:50 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B1rzy-00054u-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:07:10 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2CJ6Rf29818; Fri, 12 Mar 2004 11:06:27 -0800 X-mProtect: <200403121906> 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 smtpdHvVcfo; Fri, 12 Mar 2004 11:06:24 PST Message-ID: <40520A26.DE60047D@iprg.nokia.com> Date: Fri, 12 Mar 2004 11:06:14 -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 Nikander CC: Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: <404FDBE1.2030901@iprg.nokia.com> <40500E18.6040302@kolumbus.fi> <405142A8.4020203@iprg.nokia.com> <1EC12861-7425-11D8-A780-000393CE1E8C@nomadiclab.com> <4051ED81.F0305BEC@iprg.nokia.com> <05 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Pekka, Pekka Nikander wrote: > Hence, I still call for a stronger applicability statement > and a stronger security considerations sections. I would be quite happy to add the stronger statements, and I would be even happier if you would supply the text that would do the trick. Making these things clear was the intention of the text I already put in there, but if more text is needed then let's make it happen. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 14:37:31 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13491 for ; Fri, 12 Mar 2004 14:37:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sSt-0002RO-7V for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 14:37:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CJb3hE009372 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 14:37:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sSs-0002Qk-Fv for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 14:37:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13389 for ; Fri, 12 Mar 2004 14:36:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sSp-0001lq-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:36:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sR4-0001JY-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:35:11 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B1sQO-00018X-01 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:34:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B1sK9-0006Lr-2W for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:28:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sK9-0001sd-6N; Fri, 12 Mar 2004 14:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sJr-0001s9-Ej for mip6@optimus.ietf.org; Fri, 12 Mar 2004 14:27:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12886 for ; Fri, 12 Mar 2004 14:27:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sJo-0000OE-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:27:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sIt-0000Gx-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:26:43 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B1sIA-0000AU-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:25:58 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id CF8088984E; Fri, 12 Mar 2004 21:25:51 +0200 (EET) Message-ID: <40520E38.2060207@kolumbus.fi> Date: Fri, 12 Mar 2004 21:23:36 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" Cc: Pekka Nikander , Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: <404FDBE1.2030901@iprg.nokia.com> <40500E18.6040302@kolumbus.fi> <405142A8.4020203@iprg.nokia.com> <1EC12861-7425-11D8-A780-000393CE1E8C@nomadiclab.com> <4051ED81.F0305BEC@iprg.nokia.com> <05 <40520A26.DE60047D@iprg.nokia.com> In-Reply-To: <40520A26.DE60047D@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charles E. Perkins wrote: > Hello Pekka, > > > Pekka Nikander wrote: > > >>Hence, I still call for a stronger applicability statement >>and a stronger security considerations sections. > > > I would be quite happy to add the stronger statements, > and I would be even happier if you would supply the > text that would do the trick. Making these things > clear was the intention of the text I already put in > there, but if more text is needed then let's make it > happen. Some thoughts below, hope this helps: I think the difference is between a closed, trusted group of users such as the employees of my department vs. a large set of known but not necessarily trusted users. As an example of the latter, if a major CDMA 2000 operator decided to switch to MIPv6 RO with preconfigured Kbms for a zillion subscribers, we might get problems. Yes, you could track the subscribers down (at least if they are not prepaid), but that would be generally too late and would not help if their machines were compromised due to a virus, for instance. So I think this is more about "trust" than about being "under the same administration" as you currently mention in the I-D. Perhaps you could say "under the same administration and trusted", and then adding some text that warns how subscribers of an operator generally cannot be trusted this way. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 14:43:21 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14217 for ; Fri, 12 Mar 2004 14:43:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sYY-0003BA-D5 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 14:42:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CJgstr012214 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 14:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sYY-0003Av-1M for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 14:42:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14176 for ; Fri, 12 Mar 2004 14:42:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sYV-0002ya-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:42:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sXZ-0002pt-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:41:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1sWj-0002hK-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 14:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sWk-00031g-F8; Fri, 12 Mar 2004 14:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1sVu-0002vI-Bj for mip6@optimus.ietf.org; Fri, 12 Mar 2004 14:40:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13971 for ; Fri, 12 Mar 2004 14:40:07 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1sVr-0002Vz-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:40:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1sUg-0002FB-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:38:55 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1B1sSs-0001ma-00 for mip6@ietf.org; Fri, 12 Mar 2004 14:37:02 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2CJatA26362; Fri, 12 Mar 2004 21:36:55 +0200 (EET) X-Scanned: Fri, 12 Mar 2004 21:36:49 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2CJanRH013364; Fri, 12 Mar 2004 21:36:49 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 001LrieL; Fri, 12 Mar 2004 21:36:48 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2CJalH17062; Fri, 12 Mar 2004 21:36:47 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 12 Mar 2004 13:36:46 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Preconfigured Kbm as working group document Date: Fri, 12 Mar 2004 13:36:46 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DBF83@daebe007.americas.nokia.com> Thread-Topic: [Mip6] Preconfigured Kbm as working group document Thread-Index: AcQIaFsK1xVDJUuXSpC4wnhRHnF5mwAAIPog To: , Cc: , X-OriginalArrivalTime: 12 Mar 2004 19:36:46.0613 (UTC) FILETIME=[5B186450:01C40869] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable >=20 > Charles E. Perkins wrote: > > Hello Pekka, > >=20 > >=20 > > Pekka Nikander wrote: > >=20 > >=20 > >>Hence, I still call for a stronger applicability statement > >>and a stronger security considerations sections.=20 > >=20 > >=20 > > I would be quite happy to add the stronger statements, > > and I would be even happier if you would supply the > > text that would do the trick. Making these things > > clear was the intention of the text I already put in > > there, but if more text is needed then let's make it > > happen. >=20 > Some thoughts below, hope this helps: >=20 > I think the difference is between a closed, trusted group > of users such as the employees of my department vs. a large > set of known but not necessarily trusted users. As an example > of the latter, if a major CDMA 2000 operator decided to switch > to MIPv6 RO with preconfigured Kbms for a zillion subscribers, > we might get problems. Yes, you could track the subscribers > down (at least if they are not prepaid), but that would be > generally too late and would not help if their machines were > compromised due to a virus, for instance. >=20 > So I think this is more about "trust" than about being "under > the same administration" as you currently mention in the I-D. > Perhaps you could say "under the same administration and trusted", > and then adding some text that warns how subscribers of an > operator generally cannot be trusted this way. >=20 > --Jari >=20 I agree that it should be made clear in the I-D that this solution is primarily applicable to small "closed user groups" type of=20 scenarios. People should not necessarily extrapolate the closed user group to include a large enterprise (thousands of people for eg.) or as Jari mentions all the users within the administrative domain of a single operator. I guess I should ask for WG consensus on the I-D in a separate email in order to ensure more people are paying attention. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Fri Mar 12 18:31:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27383 for ; Fri, 12 Mar 2004 18:31:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w78-0001Ti-1E for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 18:30:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2CNUoFt005682 for mip6-archive@odin.ietf.org; Fri, 12 Mar 2004 18:30:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w77-0001TZ-Sq for mip6-web-archive@optimus.ietf.org; Fri, 12 Mar 2004 18:30:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27375 for ; Fri, 12 Mar 2004 18:30:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1w75-0007eg-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 18:30:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1w67-0007dK-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 18:29:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B1w5O-0007cL-00 for mip6-web-archive@ietf.org; Fri, 12 Mar 2004 18:29:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w5N-0001L0-Bn; Fri, 12 Mar 2004 18:29:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B1w58-0001KL-Mf for mip6@optimus.ietf.org; Fri, 12 Mar 2004 18:28:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27309 for ; Fri, 12 Mar 2004 18:28:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B1w55-0007bQ-00 for mip6@ietf.org; Fri, 12 Mar 2004 18:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B1w4D-0007aZ-00 for mip6@ietf.org; Fri, 12 Mar 2004 18:27:49 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B1w3r-0007ZO-00 for mip6@ietf.org; Fri, 12 Mar 2004 18:27:27 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 131FE8981A; Sat, 13 Mar 2004 01:27:21 +0200 (EET) Message-ID: <405246D1.9060509@kolumbus.fi> Date: Sat, 13 Mar 2004 01:25:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko Cc: "Charles E. Perkins" , Pekka Nikander , Mobile IPv6 Mailing List Subject: Re: [Mip6] Preconfigured Kbm as working group document References: <404FDBE1.2030901@iprg.nokia.com> <40500E18.6040302@kolumbus.fi> <405142A8.4020203@iprg.nokia.com> <1EC12861-7425-11D8-A780-000393CE1E8C@nomadiclab.com> <4051ED81.F0305BEC@iprg.nokia.com> <05 <40520A26.DE60047D@iprg.nokia.com> <40520E38.2060207@kolumbus.fi> In-Reply-To: <40520E38.2060207@kolumbus.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Charlie, I know its bad to respond to one's own e-mails, but... thinking some more about this, I realize that I didn't give you good advice. The situation isn't all that different from the home agent, which also doesn't check for correct care-of address. So the crucial thing which we need to ensure is that no one applies this method with a constant Kbm for lots of mobile nodes, which you already state in your draft. I think we may also need to say something about administrative contacts, something which you would expect from an operator who runs a home agent service but which may not be obvious for a correspondent node. I'm not quite sure how to formulate that requirement, but the idea is that if you get a lot of problems associated with a given home address through a correspondent node, you should be able to get to a responsive network manager of the correspondent node by inspecting e.g. the whois database. [Note that it isn't enough to contact the home agent administrator, because you method allows bindings to be established without any packets passing through the home agent.] Other comments on your draft. It may be obvious, but the draft doesn't exactly say it outloud: Kbm is indexed by the home address. Also, the replay protection appears to work only if the BCE is kept alive at all times. Did you intend to do this, or have another data structure that keeps some state when the BCE is not active for a given home address? --Jari > Some thoughts below, hope this helps: > > I think the difference is between a closed, trusted group > of users such as the employees of my department vs. a large > set of known but not necessarily trusted users. As an example > of the latter, if a major CDMA 2000 operator decided to switch > to MIPv6 RO with preconfigured Kbms for a zillion subscribers, > we might get problems. Yes, you could track the subscribers > down (at least if they are not prepaid), but that would be > generally too late and would not help if their machines were > compromised due to a virus, for instance. > > So I think this is more about "trust" than about being "under > the same administration" as you currently mention in the I-D. > Perhaps you could say "under the same administration and trusted", > and then adding some text that warns how subscribers of an > operator generally cannot be trusted this way. > > --Jari > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Mar 14 15:02:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04074 for ; Sun, 14 Mar 2004 15:02:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bod-0007es-BS for mip6-archive@odin.ietf.org; Sun, 14 Mar 2004 15:02:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2EK2VPX029431 for mip6-archive@odin.ietf.org; Sun, 14 Mar 2004 15:02:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2boc-0007eB-Pm for mip6-web-archive@optimus.ietf.org; Sun, 14 Mar 2004 15:02:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03967 for ; Sun, 14 Mar 2004 15:02:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2boZ-00040d-00 for mip6-web-archive@ietf.org; Sun, 14 Mar 2004 15:02:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2bml-0003YE-00 for mip6-web-archive@ietf.org; Sun, 14 Mar 2004 15:00:36 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2blG-0003AF-00 for mip6-web-archive@ietf.org; Sun, 14 Mar 2004 14:59:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2bl1-00046Z-62; Sun, 14 Mar 2004 14:58:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2YvD-0003fH-Iw for mip6@optimus.ietf.org; Sun, 14 Mar 2004 11:57:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27316 for ; Sun, 14 Mar 2004 11:57:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2YvC-0005fs-00 for mip6@ietf.org; Sun, 14 Mar 2004 11:57:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2YuF-0005XI-00 for mip6@ietf.org; Sun, 14 Mar 2004 11:56:07 -0500 Received: from ms-smtp-03-qfe0.socal.rr.com ([66.75.162.135] helo=ms-smtp-03-eri0.socal.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1B2YtH-0005Lt-00 for mip6@ietf.org; Sun, 14 Mar 2004 11:55:07 -0500 Received: from san.rr.com (66-75-224-68.san.rr.com [66.75.224.68]) by ms-smtp-03-eri0.socal.rr.com (8.12.10/8.12.7) with ESMTP id i2EGspUL000247; Sun, 14 Mar 2004 08:54:51 -0800 (PST) Message-ID: <40548E48.80601@san.rr.com> Date: Sun, 14 Mar 2004 08:54:32 -0800 From: Ramin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: rs1_39a95057101, rs2_a44d3b12f79, rs3_c9a1c503d8 MIME-Version: 1.0 To: Alpesh CC: mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, kleung@cisco.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com Subject: Re: [Mip6] [MIPv6] - New I-D - Authentication mechanism in MIPv6 - draft-patel-mipv6-auth-protocol-01.txt References: <40326D46.5080105@cisco.com> In-Reply-To: <40326D46.5080105@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Does the draft permit or dis-allow the following: Multiple mobile nodes with *distinct home addresses* use the *same NAI and the same shared key* in order to request the HA to bind their CoA to their HoA. Thank you, -Ramin Alpesh wrote: > Hi - > > A new I-D are available for comments. It describes a hash based > authentication for MIPv6. > > Abstract This document defines new > mobility options to enable authentication between mobility > entities. These options can be used in addition to or in lieu > of IPsec to authenticate mobility messages as defined in [1]. > Location: > ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-01.txt > > > Your comments are welcome. > Alpesh > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 15 10:12:34 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01785 for ; Mon, 15 Mar 2004 10:12:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tl9-0000z6-9y for mip6-archive@odin.ietf.org; Mon, 15 Mar 2004 10:12:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2FFC7Wb003780 for mip6-archive@odin.ietf.org; Mon, 15 Mar 2004 10:12:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tl8-0000yt-GG for mip6-web-archive@optimus.ietf.org; Mon, 15 Mar 2004 10:12:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01726 for ; Mon, 15 Mar 2004 10:12:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2tl6-0004lM-00 for mip6-web-archive@ietf.org; Mon, 15 Mar 2004 10:12:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2tk3-0004eH-00 for mip6-web-archive@ietf.org; Mon, 15 Mar 2004 10:10:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B2tjB-0004Xc-00 for mip6-web-archive@ietf.org; Mon, 15 Mar 2004 10:10:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tjA-0000OD-DP; Mon, 15 Mar 2004 10:10:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B2tiI-0000CS-GM for mip6@optimus.ietf.org; Mon, 15 Mar 2004 10:09:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01424 for ; Mon, 15 Mar 2004 10:09:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B2tiG-0004QU-00 for mip6@ietf.org; Mon, 15 Mar 2004 10:09:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B2thJ-0004If-00 for mip6@ietf.org; Mon, 15 Mar 2004 10:08:10 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx with esmtp (Exim 4.12) id 1B2tgl-0004Am-00 for mip6@ietf.org; Mon, 15 Mar 2004 10:07:35 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=i72mail01.tm.uka.de) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1B2tgc-00005k-00; Mon, 15 Mar 2004 16:07:26 +0100 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by i72mail01.tm.uka.de with esmtp (Exim 4.30) id 1B2tgb-0007RF-H4; Mon, 15 Mar 2004 16:07:25 +0100 Message-ID: <01dd01c40a9f$39957330$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: "Charles Perkins" Cc: References: <697DAA22C5004B4596E033803A7CEF44024DBF83@daebe007.americas.nokia.com> Subject: Re: [Mip6] Preconfigured Kbm as working group document Date: Mon, 15 Mar 2004 16:07:25 +0100 Organization: Institute of Telematics, University of Karlsruhe (TH) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgQ2hhcmxpZSwgaGkgTUlQNiBmb2xrcyENCg0KVXNpbmcgcHJlLWNvbmZpZ3VyZWQgYmluZGlu Zy1tYW5hZ2VtZW50IGtleXMgYXMgYSBtZWFucyBmb3IgYXV0aGVudGljYXRpb24gaXMsIGluIG15 IG9waW5pb24sIGFuIGV4Y2VsbGVudCBhbHRlcm5hdGl2ZSB0byB0aGUgUmV0dXJuIFJvdXRhYmls aXR5J3MgaG9tZS1hZGRyZXNzIHRlc3QuIEFwYXJ0IGZyb20gdGVjaG5pY2FsIGlzc3VlcyAtIGxp a2UgSmFyaSdzIGNvbW1lbnQgb24gdGhlIGxvc3Mgb2Ygc2VxdWVuY2UtbnVtYmVyIHN0YXRlIHdo ZW4gYSBCQ0UgYmVjb21lcyBleHBpcmVkIC0gcHJlLWNvbmZpZ3VyZWQga2V5cyBhcmUgc3VwZXJp b3IgdG8gdGhlIGhvbWUtYWRkcmVzcyB0ZXN0IHdpdGggcmVzcGVjdCB0byBzZWN1cml0eSBhbmQg c2lnbmFsaW5nIG92ZXJoZWFkLg0KDQpJdCBzZWVtcyB0aGF0IHBhcnQgb2YgdGhlIG9uZ29pbmcg Y29udHJvdmVyc3kgd2FzIHNwYXJrZWQgYnkgdGhlIGRpc2JlbGllZiB0aGF0IGVtcGxveW1lbnQg b2YgcHJlLWNvbmZpZ3VyZWQga2V5cyByZWR1bmRhbnRpemVzIHRoZSBSZXR1cm4gUm91dGFiaWxp dHkncyBjYXJlLW9mLWFkZHJlc3MgdGVzdC4gQXMgZGlzY3Vzc2VkLCB0aGlzIGRlcGVuZHMgb24g dGhlIHNjZW5hcmlvLiBJcyB0aGVyZSBhIHNtYWxsIGdyb3VwIG9mIHBlb3BsZSB3aG8gdHJ1c3Qg ZWFjaCBvdGhlcj8gVGhlbiwgb2YgY291cnNlLCBncm91cCBtZW1iZXJzIGFyZSBub3QgZ29pbmcg dG8gbWlzdXNlIHRoZWlyIHByZS1jb25maWd1cmVkIGtleXMgZm9yIGZsb29kaW5nIGF0dGFja3Mg b24gaW5ub2NlbnQgbm9kZXMuIE9yIGFyZSB3ZSB0YWxraW5nIGFib3V0IHRoZSBjdXN0b21lciBi YXNlIG9mIGEgYmlnIElTUD8gVGhlbiwgcHJvcGVyIGF1dGhlbnRpY2F0aW9uIGRvZXMgdXN1YWxs eSBub3QgaW1wbHkgdHJ1c3QsIGFuZCBpdCBtYXkgbm90IGJlIGZlYXNpYmxlIHRvIHVzZSBwcmUt Y29uZmlndXJlZCBrZXlzIHdpdGhvdXQgY2hlY2tpbmcgYSBtb2JpbGUgbm9kZSdzIHJlYWNoYWJp bGl0eS4gVHJhY2FiaWxpdHkgaXMgbm90IGEgY29tcGVuc2F0aW9uIGZvciB0aGUgbWlzc2luZyBj YXJlLW9mLWFkZHJlc3MgdGVzdCwgYmVjYXVzZSBpdCBpcyBhIHJlYWN0aXZlIG1lYXN1cmUsIHdo ZXJlYXMgYSBjYXJlLW9mLWFkZHJlc3MgdGVzdCBpcyBhIHByb2FjdGl2ZSwgcHJldmVudGl2ZSBv bmUuDQoNClRoZXNlIHRoaW5ncyBzYWlkLCBtYXliZSB0aGUgb3BlcmF0b3IgaXNzdWluZyBwcmUt Y29uZmlndXJlZCBrZXlzIHNob3VsZCBtYWtlIGl0cyBvd24gZGVjaXNpb24gb24gd2hldGhlciBv ciBub3QgdG8gY29tYmluZSBlbXBsb3ltZW50IG9mIHByZS1jb25maWd1cmVkIGtleXMgd2l0aCBh IGNhcmUtb2YtYWRkcmVzcyB0ZXN0PyBNYXliZSB0aGlzIGNvdWxkIGJlIHJlYWxpemVkIGJ5IGEg Q29USS9Db1QgZXhjaGFuZ2UsIGFuZCBieSBhdXRoZW50aWNhdGluZyBhIEJpbmRpbmcgVXBkYXRl IHdpdGggYSBrZXkgcHJvZHVjZWQgd2l0aCB0aGUgcHJlLWNvbmZpZ3VyZWQga2V5IGFuZCB0aGUg Q2FyZS1vZiBLZXlnZW4gVG9rZW4/IFRoZSAoNjQtYml0KSBwcmUtY29uZmlndXJlZCBrZXkgd291 bGQgcGxheSB0aGUgcm9sZSBvZiB0aGUgSG9tZSBLZXlnZW4gVG9rZW4gaW4gdGhpcyBjYXNlLiBP bmUgd291bGQgc3RpbGwgYXZvaWQgdGhlIEhvVEkvSG9UIGV4Y2hhbmdlLCBhbmQgb25lIHdvdWxk IGF2b2lkIGludm9sdmluZyB0aGUgaG9tZSBhZ2VudCBpbiB0aGUgYmluZGluZy11cGRhdGUgcHJv Y2VkdXJlLg0KDQpUaGVzZSB0aG91Z2h0cyBhcmUgbWVyZWx5IHN1Z2dlc3Rpb25zLiBUaGV5IG1p Z2h0IGhlbHAgdG8gYnJvYWRlbiB0aGUgc2NvcGUgb2YgYXBwbGljYWJpbGl0eSBmb3IgcHJlLWNv bmZpZ3VyZWQga2V5cyB0byBlbnZpcm9ubWVudHMgd2hlcmUgZW5kLWhvc3RzIGhhdmUgYWRtaW5p c3RyYXRpdmUgcmVsYXRpb25zaGlwcyB3aXRoIGVhY2ggb3RoZXIsIGJ1dCBkbyBub3QgbmVjZXNz YXJpbHkgdHJ1c3QgZWFjaCBvdGhlci4gDQoNCkJlc3QgcmVnYXJkcywNCg0KDQotIENocmlzdGlh bg0KDQoNCnwNCnwgQ2hyaXN0aWFuIFZvZ3QNCnwgSW5zdGl0dXRlIG9mIFRlbGVtYXRpY3MsIFVu aXZlcnNpdHkgb2YgS2FybHNydWhlIChUSCkNCnwgd3d3LnRtLnVrYS5kZS9+Y2h2b2d0Lw0KfA0K _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 16 21:56:32 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14768 for ; Tue, 16 Mar 2004 21:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RDx-0007fS-H2 for mip6-archive@odin.ietf.org; Tue, 16 Mar 2004 21:56:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H2u54g029471 for mip6-archive@odin.ietf.org; Tue, 16 Mar 2004 21:56:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RDx-0007fG-52 for mip6-web-archive@optimus.ietf.org; Tue, 16 Mar 2004 21:56:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14699 for ; Tue, 16 Mar 2004 21:56:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3RDu-0002dm-00 for mip6-web-archive@ietf.org; Tue, 16 Mar 2004 21:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3RCx-0002Wl-00 for mip6-web-archive@ietf.org; Tue, 16 Mar 2004 21:55:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3RC0-0002Qq-00 for mip6-web-archive@ietf.org; Tue, 16 Mar 2004 21:54:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RBw-0007Wt-Uc; Tue, 16 Mar 2004 21:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3RBS-0007UT-B4 for mip6@optimus.ietf.org; Tue, 16 Mar 2004 21:53:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA14627 for ; Tue, 16 Mar 2004 21:53:26 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3RBP-0002MO-00 for mip6@ietf.org; Tue, 16 Mar 2004 21:53:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3RAm-0002GZ-00 for mip6@ietf.org; Tue, 16 Mar 2004 21:52:49 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1B3R9X-00029h-00 for mip6@ietf.org; Tue, 16 Mar 2004 21:51:32 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2H2pV405635 for ; Wed, 17 Mar 2004 04:51:31 +0200 (EET) X-Scanned: Wed, 17 Mar 2004 04:51:21 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i2H2pLKd024758 for ; Wed, 17 Mar 2004 04:51:21 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00MZdLN9; Wed, 17 Mar 2004 04:51:19 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2H2pJF13093 for ; Wed, 17 Mar 2004 04:51:19 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 16 Mar 2004 20:51:17 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2004 20:51:17 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> Thread-Topic: Consensus call: draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQLq+l68V/VmAeST367juon0Rnfwg== To: X-OriginalArrivalTime: 17 Mar 2004 02:51:17.0674 (UTC) FILETIME=[B84F98A0:01C40BCA] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable WG members, We would like to call for consensus on the following: Should I-D: draft-perkins-mip6-precfgKbm-00.txt "Preconfigured=20 Binding Management Keys for Mobile IPv6" become a WG document and pursued on standards track? Please express your thoughts by Monday, March 22nd 04. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 17 00:56:43 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21833 for ; Wed, 17 Mar 2004 00:56:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3U2L-0001Zy-3B for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 00:56:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H5uGnH006068 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 00:56:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3U2K-0001Zn-Ns for mip6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 00:56:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21797 for ; Wed, 17 Mar 2004 00:56:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3U2H-0006yV-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 00:56:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3U1N-0006rz-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 00:55:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3U0S-0006m2-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 00:54:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3TzP-0001Bh-Tc; Wed, 17 Mar 2004 00:53:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3TyQ-0001A8-81 for mip6@optimus.ietf.org; Wed, 17 Mar 2004 00:52:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21733 for ; Wed, 17 Mar 2004 00:52:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3TyN-0006Zb-00 for mip6@ietf.org; Wed, 17 Mar 2004 00:52:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3TxP-0006Ri-00 for mip6@ietf.org; Wed, 17 Mar 2004 00:51:12 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B3Twb-0006GR-00 for mip6@ietf.org; Wed, 17 Mar 2004 00:50:21 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 226008984E; Wed, 17 Mar 2004 07:50:01 +0200 (EET) Message-ID: <4057E677.6080204@kolumbus.fi> Date: Wed, 17 Mar 2004 07:47:35 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: mip6@ietf.org Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt References: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Basavaraj.Patil@nokia.com wrote: > WG members, > > We would like to call for consensus on the following: > > Should I-D: draft-perkins-mip6-precfgKbm-00.txt "Preconfigured > Binding Management Keys for Mobile IPv6" become a WG document > and pursued on standards track? Hmm... I'd like to have something resembling Charlie's draft at least, but I wonder if we have all the options on the table yet. Following a bit what Christian said in his e-mail and what I also said earlier, there seems to a bit of question marks on the scope. How about asking this consensus question instead: 1. Should Charlie's draft become a WG document as-is? (With applicability etc. statements added and some technical issues corrected of course.) 2. Should Charlie's draft focus on home address tests only, and leave care-of address tests to base or other improvements? Note: there will be such improvements. Some have already been discussed in the WG. 3. Should Charlie's draft be combined with another approach that helps also with care-of address tests? 4. Should we do nothing? If you'd ask this question, I'd have more trouble deciding between options 1 through 3. Somehow I think the end result should be that we have a very widely applicable mechanism that is still not problematic wrt the care-of addresses; this would seem to imply something 2 or 3 as the best option. OTOH, you can perhaps go there as well, later, as an extension of 1. Also, I have a question to the chairs. How many alternate security mechanisms are we allowed to adopt as WG items? If it is just one, then we should be really careful what to choose here. Probably something else would take priority over Charlie's draft. If more than one, then its less of an issue. One or more than one per home/care-of test improvement? But there might be somewhat differently applicable methods on this too. (In the interest of full disclosure: I have a draft in the works that improves home address test performance without requiring preconfiguration.) --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 17 01:40:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23449 for ; Wed, 17 Mar 2004 01:40:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Uj5-0004m0-7J for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 01:40:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2H6eRPf018342 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 01:40:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Uj4-0004ll-VI for mip6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 01:40:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23446 for ; Wed, 17 Mar 2004 01:40:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Uj1-0003oL-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 01:40:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3Ui5-0003i0-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 01:39:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3Uhh-0003b3-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 01:39:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Uhh-0004bU-V8; Wed, 17 Mar 2004 01:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3Uh8-0004aE-3D for mip6@optimus.ietf.org; Wed, 17 Mar 2004 01:38:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23347 for ; Wed, 17 Mar 2004 01:38:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3Uh4-0003Z6-00 for mip6@ietf.org; Wed, 17 Mar 2004 01:38:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3UgO-0003Sc-00 for mip6@ietf.org; Wed, 17 Mar 2004 01:37:40 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3Ufc-0003HW-00 for mip6@ietf.org; Wed, 17 Mar 2004 01:36:52 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 16 Mar 2004 22:40:01 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2H6aKK2025437; Tue, 16 Mar 2004 22:36:21 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn3-280.cisco.com [10.21.65.24]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARF77999; Tue, 16 Mar 2004 22:36:19 -0800 (PST) Message-Id: <4.3.2.7.2.20040316223018.01d78ed0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 16 Mar 2004 22:36:19 -0800 To: Ramin From: Kent Leung Subject: Re: [Mip6] [MIPv6] - New I-D - Authentication mechanism in MIPv6 - draft-patel-mipv6-auth-protocol-01.txt Cc: Alpesh , mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com In-Reply-To: <40548E48.80601@san.rr.com> References: <40326D46.5080105@cisco.com> <40326D46.5080105@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL autolearn=no version=2.60 Hi Ramin. The draft does not disallow this scenario. It specifies an authentication method between an HA and the MN (identified by either NAI or HoA). Kent At 08:54 AM 3/14/2004 -0800, Ramin wrote: >Does the draft permit or dis-allow the following: >Multiple mobile nodes with *distinct home addresses* use the *same NAI and >the same shared key* in order to request the HA to bind their CoA to their HoA. > >Thank you, > >-Ramin > > >Alpesh wrote: > >>Hi - >> >>A new I-D are available for comments. It describes a hash based >>authentication for MIPv6. >> >> Abstract This document defines new >>mobility options to enable authentication between mobility >>entities. These options can be used in addition to or in lieu of >>IPsec to authenticate mobility messages as defined in [1]. >>Location: >>ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-01.txt >> >> >>Your comments are welcome. >>Alpesh >> >> >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 17 12:20:11 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23189 for ; Wed, 17 Mar 2004 12:20:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ehj-00006P-FX for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 12:19:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HHJhoG000387 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 12:19:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3ehj-000069-9r for mip6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 12:19:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23124 for ; Wed, 17 Mar 2004 12:19:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3ehh-0007iK-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 12:19:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3egm-0007Yq-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 12:18:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3eg7-0007QX-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 12:18:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3eg6-00085D-5Y; Wed, 17 Mar 2004 12:18:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3efj-00081r-CM for mip6@optimus.ietf.org; Wed, 17 Mar 2004 12:17:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22994 for ; Wed, 17 Mar 2004 12:17:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3efh-0007Nc-00 for mip6@ietf.org; Wed, 17 Mar 2004 12:17:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3eee-0007Ef-00 for mip6@ietf.org; Wed, 17 Mar 2004 12:16:32 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1B3ed0-000724-00 for mip6@ietf.org; Wed, 17 Mar 2004 12:14:50 -0500 Message-ID: <007301c40c43$6efaaa40$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt Date: Wed, 17 Mar 2004 09:15:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I believe the document should become a WG item. It fits into our charter item for alternative route optimization security mechanisms. The document needs some work yet, along the lines of the discussion that has been happening, but that's OK. jak ----- Original Message ----- From: To: Sent: Tuesday, March 16, 2004 6:51 PM Subject: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt WG members, We would like to call for consensus on the following: Should I-D: draft-perkins-mip6-precfgKbm-00.txt "Preconfigured Binding Management Keys for Mobile IPv6" become a WG document and pursued on standards track? Please express your thoughts by Monday, March 22nd 04. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 17 12:53:35 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26075 for ; Wed, 17 Mar 2004 12:53:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fDm-0003KP-79 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 12:52:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HHqoYB012793 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 12:52:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fDm-0003KG-1u for mip6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 12:52:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26018 for ; Wed, 17 Mar 2004 12:52:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fDk-0005N3-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 12:52:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fCx-0005DS-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 12:52:00 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3fC6-00053f-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 12:51:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3fC7-0005YP-TB for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 12:51:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fC2-0003Az-RZ; Wed, 17 Mar 2004 12:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fBz-0003AA-FR for mip6@optimus.ietf.org; Wed, 17 Mar 2004 12:50:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25874 for ; Wed, 17 Mar 2004 12:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fBx-00051u-00 for mip6@ietf.org; Wed, 17 Mar 2004 12:50:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fAx-0004tl-00 for mip6@ietf.org; Wed, 17 Mar 2004 12:49:55 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1B3fAS-0004kW-00 for mip6@ietf.org; Wed, 17 Mar 2004 12:49:24 -0500 Message-ID: <01c501c40c48$430387e0$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Jari Arkko" , Cc: References: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> <4057E677.6080204@kolumbus.fi> Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt Date: Wed, 17 Mar 2004 09:49:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jari, The WG charter explicitly mentions improving RR by using a shared key, so this draft is right on target as far as charter items go (item 3, bullet 4). The charter says nothing explicit about improvements to RR such as draft-vogt-mip6-early-binding-updates-00.txt or draft-haddad-mipv6-bub-01.txt would introduce, though I suppose item 1 could be interpreted broadly enough to include such improvements. For this reason, I believe we ought to keep these two items separate, namely have one draft that explicitly addresses item 3, bullet 4 and another that looks at other RR improvements. draft-perkins-mip6-precfgKbm-00.txt looks like a good start on the former, though as I mentioned in a previous email message, it needs improvments along the lines that have been discussed on this list. My only concern would be whether the current editor of draft-perkins-mip6-precfgKbm-00.txt would have enough time to devote to it, and getting sufficient technical resources devoted to buffing up the design. Perhaps a dedicated design team might be appropriate? jak ----- Original Message ----- From: "Jari Arkko" To: Cc: Sent: Tuesday, March 16, 2004 9:47 PM Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt > Basavaraj.Patil@nokia.com wrote: > > WG members, > > > > We would like to call for consensus on the following: > > > > Should I-D: draft-perkins-mip6-precfgKbm-00.txt "Preconfigured > > Binding Management Keys for Mobile IPv6" become a WG document > > and pursued on standards track? > > Hmm... I'd like to have something resembling Charlie's > draft at least, but I wonder if we have all the options > on the table yet. Following a bit what Christian said > in his e-mail and what I also said earlier, there seems > to a bit of question marks on the scope. How about asking > this consensus question instead: > > 1. Should Charlie's draft become a WG document as-is? > (With applicability etc. statements added and some > technical issues corrected of course.) > > 2. Should Charlie's draft focus on home address tests > only, and leave care-of address tests to base or > other improvements? Note: there will be such > improvements. Some have already been discussed in the > WG. > > 3. Should Charlie's draft be combined with another > approach that helps also with care-of address tests? > > 4. Should we do nothing? > > If you'd ask this question, I'd have more trouble deciding > between options 1 through 3. Somehow I think the end result > should be that we have a very widely applicable mechanism > that is still not problematic wrt the care-of addresses; > this would seem to imply something 2 or 3 as the best option. > OTOH, you can perhaps go there as well, later, as an extension > of 1. > > Also, I have a question to the chairs. How many alternate > security mechanisms are we allowed to adopt as WG items? > If it is just one, then we should be really careful what to > choose here. Probably something else would take priority over > Charlie's draft. If more than one, then its less of an issue. > One or more than one per home/care-of test improvement? But > there might be somewhat differently applicable methods on > this too. > > (In the interest of full disclosure: I have a draft > in the works that improves home address test performance > without requiring preconfiguration.) > > --Jari > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 17 13:13:07 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27268 for ; Wed, 17 Mar 2004 13:13:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fWy-00059h-KP for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 13:12:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HICeOc019811 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 13:12:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fWx-00059Q-S5 for mip6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 13:12:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27209 for ; Wed, 17 Mar 2004 13:12:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fWv-0000eY-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 13:12:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fVx-0000Uk-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 13:11:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3fV1-0000ME-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 13:10:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fUo-0004s1-N1; Wed, 17 Mar 2004 13:10:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3fUF-0004qa-E5 for mip6@optimus.ietf.org; Wed, 17 Mar 2004 13:09:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27142 for ; Wed, 17 Mar 2004 13:09:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3fU7-0000FR-00 for mip6@ietf.org; Wed, 17 Mar 2004 13:09:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3fTH-00008V-00 for mip6@ietf.org; Wed, 17 Mar 2004 13:08:51 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B3fSh-0007md-00 for mip6@ietf.org; Wed, 17 Mar 2004 13:08:15 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i2HI7fK2019903; Wed, 17 Mar 2004 10:07:42 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-186.cisco.com [128.107.163.186]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARG11757; Wed, 17 Mar 2004 10:07:40 -0800 (PST) Message-ID: <405893EC.6050801@cisco.com> Date: Wed, 17 Mar 2004 10:07:40 -0800 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com CC: mip6@ietf.org Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt References: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Raj - I have no problem in it becoming a WG item. Just think that some more work is needed. With static keys between MN and CN, now HA has no control. With MIP, HA is still the anchor and I think it should have some control on what the MN can and cannot do. With direct communication between MN and CN, are we permiting communication without any control by HA? Am not sure if it blends well in certain scenarios. Alpesh Basavaraj.Patil@nokia.com wrote: >WG members, > >We would like to call for consensus on the following: > >Should I-D: draft-perkins-mip6-precfgKbm-00.txt "Preconfigured >Binding Management Keys for Mobile IPv6" become a WG document >and pursued on standards track? > >Please express your thoughts by Monday, March 22nd 04. > >-Chairs > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 17 13:53:01 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29047 for ; Wed, 17 Mar 2004 13:53:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3g8J-0007lt-Bf for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 13:52:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HIp5HS029836 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 13:51:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3g88-0007kJ-OZ for mip6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 13:51:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28865 for ; Wed, 17 Mar 2004 13:50:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3g7r-0005rC-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 13:50:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3g7A-0005it-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 13:50:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3g69-0005Zw-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 13:49:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3g68-0007dB-3H; Wed, 17 Mar 2004 13:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3g5q-0007ax-ND for mip6@optimus.ietf.org; Wed, 17 Mar 2004 13:48:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28711 for ; Wed, 17 Mar 2004 13:48:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3g5o-0005X1-00 for mip6@ietf.org; Wed, 17 Mar 2004 13:48:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3g4u-0005Q9-00 for mip6@ietf.org; Wed, 17 Mar 2004 13:47:44 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B3g4I-0005Cp-00 for mip6@ietf.org; Wed, 17 Mar 2004 13:47:07 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2HIkKd12582; Wed, 17 Mar 2004 10:46:20 -0800 X-mProtect: <200403171846> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.30.3, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnJxIIW; Wed, 17 Mar 2004 10:46:18 PST Message-ID: <4058A02B.1030000@iprg.nokia.com> Date: Wed, 17 Mar 2004 10:59:55 -0800 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf CC: Jari Arkko , Basavaraj.Patil@nokia.com, mip6@ietf.org Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt References: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> <4057E677.6080204@kolumbus.fi> <01c501c40c48$430387e0$366115ac@dcml.docomolabsusa.com> In-Reply-To: <01c501c40c48$430387e0$366115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit James Kempf wrote: > Jari, > > The WG charter explicitly mentions improving RR by using a shared key, so > this draft is right on target as far as charter items go (item 3, bullet 4). > The charter says nothing explicit about improvements to RR such as > draft-vogt-mip6-early-binding-updates-00.txt or > draft-haddad-mipv6-bub-01.txt would introduce, though I suppose item 1 could > be interpreted broadly enough to include such improvements. > > For this reason, I believe we ought to keep these two items separate, namely > have one draft that explicitly addresses item 3, bullet 4 and another that > looks at other RR improvements. I agree. > Perhaps a dedicated design team might be appropriate? a design team is too heavy a solution. I thought a design team is needed when there are a lot of issues, no concensus at all and a lot of missing things. this is not the case with this document. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 17 14:37:09 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01790 for ; Wed, 17 Mar 2004 14:37:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gqG-0002VZ-Ik for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 14:36:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HJae6B009640 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 14:36:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gqG-0002VK-85 for mip6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 14:36:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01779 for ; Wed, 17 Mar 2004 14:36:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gqD-0004rI-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 14:36:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3gpH-0004je-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 14:35:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3goK-0004aM-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 14:34:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gmj-00024R-Cb; Wed, 17 Mar 2004 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3gmT-00023E-FQ for mip6@optimus.ietf.org; Wed, 17 Mar 2004 14:32:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01507 for ; Wed, 17 Mar 2004 14:32:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3gmQ-0004EC-00 for mip6@ietf.org; Wed, 17 Mar 2004 14:32:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3glP-0003wy-00 for mip6@ietf.org; Wed, 17 Mar 2004 14:31:40 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B3gk7-0003gK-01 for mip6@ietf.org; Wed, 17 Mar 2004 14:30:19 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by mx2.foretec.com with esmtp (Exim 4.24) id 1B3gVQ-0001cn-07 for mip6@ietf.org; Wed, 17 Mar 2004 14:15:08 -0500 Message-ID: <021901c40c54$39952b80$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" Cc: "Jari Arkko" , , References: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> <4057E677.6080204@kolumbus.fi> <01c501c40c48$430387e0$366115ac@dcml.docomolabsusa.com> <4058A02B.1030000@iprg.nokia.com> Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt Date: Wed, 17 Mar 2004 11:15:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > a design team is too heavy a solution. I thought a design > team is needed when there are a lot of issues, no concensus > at all and a lot of missing things. this is not the case > with this document. > I didn't think we had that many issues nor lack of concensus on the bootstrapping problem statement document, yet we have a design team there. The criteria for a design team are not so clear cut I think. Anyway, I'm happy with making it a WG draft, so long as the issues that were brought up are addressed in some manner. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 22 11:39:52 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05280 for ; Mon, 22 Mar 2004 11:39:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SSR-0008Vt-96 for mip6-archive@odin.ietf.org; Mon, 22 Mar 2004 11:39:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MGdNnE032719 for mip6-archive@odin.ietf.org; Mon, 22 Mar 2004 11:39:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SSR-0008Vd-3B for mip6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 11:39:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05190 for ; Mon, 22 Mar 2004 11:39:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5SSQ-0002AT-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 11:39:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SQn-0001lA-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 11:37:44 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B5SOL-0001Dp-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 11:35:09 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1B5SOM-000379-NP for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 11:35:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SOF-0007fr-RH; Mon, 22 Mar 2004 11:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5SNH-0007cE-HO for mip6@optimus.ietf.org; Mon, 22 Mar 2004 11:34:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04706 for ; Mon, 22 Mar 2004 11:34:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5SNG-00012C-00 for mip6@ietf.org; Mon, 22 Mar 2004 11:34:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SMS-0000tD-00 for mip6@ietf.org; Mon, 22 Mar 2004 11:33:13 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B5SLf-0000jB-00 for mip6@ietf.org; Mon, 22 Mar 2004 11:32:24 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 0885589960; Mon, 22 Mar 2004 18:32:22 +0200 (EET) Message-ID: <405F1479.3070508@kolumbus.fi> Date: Mon, 22 Mar 2004 18:29:45 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf , Basavaraj.Patil@nokia.com Cc: mip6@ietf.org Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt References: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> <4057E677.6080204@kolumbus.fi> <01c501c40c48$430387e0$366115ac@dcml.docomolabsusa.com> In-Reply-To: <01c501c40c48$430387e0$366115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Re: charter. The draft does fall within the charter, and I think we should do it (perhaps with some agreement first on how ambitious scope it should have). But I believe we have also other issues that we should take care of in the RO space, perhaps even higher priority issues. So I'd really like to ensure that we can actually do more than Charlie's draft. This brings me to ... Raj: You didn't answer my question on whether more than one improvement can be adopted by the WG. My reading of the charter item: - Route optimization will require security mechanisms for trusting and updating the binding information.Return-routability is the basic mechanism for route-optimization. Mechanisms using a shared secret Key/Security Association will be considered. Methods for establishing a security association between the mobile node and the correspondent node are out of the scope of the WG. is that shared secrets are just one example and other mechanisms can be considered. If that's your interpretation as well, then I don't need to worry that we are preventing other necessary work to take place. Also, I have a question about the charter ;-) It says: It should be noted that there are potential optimizations that might make mobile IP more attractive for use by certain applications (e.g., making handovers "faster"). The latter category of optimizations is explicitly out-of-scope at this time; this WG will focus on issues for which there is strong consensus that the work is needed to get basic mobility deployable on a large scale. What does this mean, exactly? Why does it not apply to the kbm draft, as its main purpose (I think) is to have less signaling and delay? Would it apply other alternatives to RR? Or is this paragraph in the charter to avoid collision with MIPSHOP? That's my interpretation, but I'm not sure this is the way others read it... --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 22 12:44:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08271 for ; Mon, 22 Mar 2004 12:44:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TSn-0006Mg-6U for mip6-archive@odin.ietf.org; Mon, 22 Mar 2004 12:43:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MHhnfs024455 for mip6-archive@odin.ietf.org; Mon, 22 Mar 2004 12:43:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TSm-0006MJ-93 for mip6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 12:43:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08249 for ; Mon, 22 Mar 2004 12:43:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5TSk-0001n2-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 12:43:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5TRv-0001gC-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 12:42:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5TR7-0001YJ-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 12:42:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TR3-0006EH-Do; Mon, 22 Mar 2004 12:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5TQa-0006DY-BL for mip6@optimus.ietf.org; Mon, 22 Mar 2004 12:41:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08163 for ; Mon, 22 Mar 2004 12:41:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5TQY-0001W0-00 for mip6@ietf.org; Mon, 22 Mar 2004 12:41:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5TPb-0001QY-00 for mip6@ietf.org; Mon, 22 Mar 2004 12:40:32 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1B5TOe-0001L0-00 for mip6@ietf.org; Mon, 22 Mar 2004 12:39:32 -0500 Message-ID: <01ec01c41034$b633d310$366115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Mon, 22 Mar 2004 09:40:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Issue 1: Third Party Bombing Through the HA Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I'd like to raise an issue that Francis brought up in draft-dupont-mipv6-3bombing-00.txt to the list for some discussion. Charter item 1 says that the WG will maintain an issues list on the current spec, with interop being mentioned as the only reason, but I think this item, which is a security item, also needs attention. If discussion of this issue proves that the spec text needs amending, I think we ought to list it in the issues list. The issue is that the HA currently is not required to do a return routability test on a BU sent from the MN. The issue list and discussion on this from the time the decision was made, cited in Francis' draft, says that the owner of the HA is expected to have a business relationship with the MN's owner, and thereby to take action if an MN does third party bombing through the HA, presumably by terminating the MN's account. Is there any way that the home network can actuallly detect that a MN has started a third party bombing attack and terminate it? Other than when the victim contacts the home network operator out of band and tells them? If not, then this could be a significant security vulnerability. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Wed Mar 24 11:43:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05530 for ; Wed, 24 Mar 2004 11:43:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BTM-0004fm-Ry for mip6-archive@odin.ietf.org; Wed, 24 Mar 2004 11:43:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2OGhKro017958 for mip6-archive@odin.ietf.org; Wed, 24 Mar 2004 11:43:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BTM-0004fY-LY for mip6-web-archive@optimus.ietf.org; Wed, 24 Mar 2004 11:43:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05518 for ; Wed, 24 Mar 2004 11:43:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BTL-0001zQ-00 for mip6-web-archive@ietf.org; Wed, 24 Mar 2004 11:43:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BSN-0001ww-00 for mip6-web-archive@ietf.org; Wed, 24 Mar 2004 11:42:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6BS6-0001um-00 for mip6-web-archive@ietf.org; Wed, 24 Mar 2004 11:42:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BS5-0004ZL-6W; Wed, 24 Mar 2004 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6BRJ-0004Wg-DW for mip6@optimus.ietf.org; Wed, 24 Mar 2004 11:41:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05399 for ; Wed, 24 Mar 2004 11:41:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6BRI-0001tM-00 for mip6@ietf.org; Wed, 24 Mar 2004 11:41:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6BQN-0001qt-00 for mip6@ietf.org; Wed, 24 Mar 2004 11:40:15 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1B6BPZ-0001lR-00 for mip6@ietf.org; Wed, 24 Mar 2004 11:39:25 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2OGcd5P023688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Mar 2004 08:38:39 -0800 (PST) Received: from san.rr.com (ramin.qualcomm.com [129.46.73.69]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2OGcalG012817; Wed, 24 Mar 2004 08:38:37 -0800 (PST) Message-ID: <4061B95B.8060309@san.rr.com> Date: Wed, 24 Mar 2004 08:37:47 -0800 From: Ramin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en MIME-Version: 1.0 To: Kent Leung CC: Alpesh , mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com Subject: Re: [Mip6] [MIPv6] - New I-D - Authentication mechanism in MIPv6 - draft-patel-mipv6-auth-protocol-01.txt References: <40326D46.5080105@cisco.com> <40326D46.5080105@cisco.com> <4.3.2.7.2.20040316223018.01d78ed0@mira-sjcm-2.cisco.com> In-Reply-To: <4.3.2.7.2.20040316223018.01d78ed0@mira-sjcm-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Kent Leung wrote: > Hi Ramin. > > The draft does not disallow this scenario. It specifies an > authentication > method between an HA and the MN (identified by either NAI or HoA). The draft also does not seem to disallow MN_1 with to change the CoA<-->HoA binding for MN_2 with (assuming that both shared secrets are valid and bound to their NAI). Can you please confirm? -Ramin > > Kent > > At 08:54 AM 3/14/2004 -0800, Ramin wrote: > >> Does the draft permit or dis-allow the following: >> Multiple mobile nodes with *distinct home addresses* use the *same >> NAI and the same shared key* in order to request the HA to bind their >> CoA to their HoA. >> >> Thank you, >> >> -Ramin >> >> >> Alpesh wrote: >> >>> Hi - >>> >>> A new I-D are available for comments. It describes a hash based >>> authentication for MIPv6. >>> >>> Abstract This document defines new >>> mobility options to enable authentication between mobility >>> entities. These options can be used in addition to or in lieu >>> of IPsec to authenticate mobility messages as defined in [1]. >>> Location: >>> ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-01.txt >>> >>> >>> Your comments are welcome. >>> Alpesh >>> >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www.ietf.org/mailman/listinfo/mip6 >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 25 13:30:50 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12879 for ; Thu, 25 Mar 2004 13:30:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZcU-0007Vm-3c for mip6-archive@odin.ietf.org; Thu, 25 Mar 2004 13:30:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PIUMMK028873 for mip6-archive@odin.ietf.org; Thu, 25 Mar 2004 13:30:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZcT-0007Vc-Su for mip6-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 13:30:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12844 for ; Thu, 25 Mar 2004 13:30:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZcR-0006dF-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 13:30:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ZbT-0006a7-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 13:29:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6Zaa-0006YI-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 13:28:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZaX-0007KN-Ac; Thu, 25 Mar 2004 13:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ZYn-000723-7X for mip6@optimus.ietf.org; Thu, 25 Mar 2004 13:26:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12732 for ; Thu, 25 Mar 2004 13:26:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ZYl-0006TL-00 for mip6@ietf.org; Thu, 25 Mar 2004 13:26:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6ZXs-0006R0-00 for mip6@ietf.org; Thu, 25 Mar 2004 13:25:36 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1B6ZXX-0006O2-00 for mip6@ietf.org; Thu, 25 Mar 2004 13:25:15 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i2PIOgGX016084; Thu, 25 Mar 2004 10:24:42 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn4-105.cisco.com [10.21.80.105]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ARM38654; Thu, 25 Mar 2004 10:24:41 -0800 (PST) Message-Id: <4.3.2.7.2.20040325101316.02882720@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Mar 2004 10:24:11 -0800 To: Ramin From: Kent Leung Subject: Re: [Mip6] [MIPv6] - New I-D - Authentication mechanism in MIPv6 - draft-patel-mipv6-auth-protocol-01.txt Cc: Alpesh , mip6@ietf.org, gdommety@cisco.com, basavaraj.patil@nokia.com, chowdury@nortelnetworks.com, mkhalil@nortelnetworks.com, haseebak@nortelnetworks.com In-Reply-To: <4061B95B.8060309@san.rr.com> References: <4.3.2.7.2.20040316223018.01d78ed0@mira-sjcm-2.cisco.com> <40326D46.5080105@cisco.com> <40326D46.5080105@cisco.com> <4.3.2.7.2.20040316223018.01d78ed0@mira-sjcm-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL autolearn=no version=2.60 Let me see if I understand clearly.. This is a different case where 2 MNs (MN_1 and MN_2) have 2 NAIs (NAI_1, and NAI_2) which are associated with the same HoA. And that the HoA session can be moved using different NAIs (which have their own SAs with the HA). This draft specifies the authentication mechanism for Binding messages between MN and HA. How the NAI to HoA mapping is accomplished is outside the scope of the draft. So this issue would have to be covered in that particular draft where HoA is assigned to an NAI and how to deal with same HoA for multiple NAIs. Typically, NAIs will have different HoAs. From authentication perspective, it's straightforward that there's a security association between MN (identified by IP address or NAI) and HA. Hope this helps. Kent At 08:37 AM 3/24/2004 -0800, Ramin wrote: >Kent Leung wrote: > >>Hi Ramin. >> >>The draft does not disallow this scenario. It specifies an authentication >>method between an HA and the MN (identified by either NAI or HoA). > >The draft also does not seem to disallow MN_1 with Shared_secret_1> to change the CoA<-->HoA binding for MN_2 with Shared_secret_2> (assuming that both shared secrets are valid and bound to >their NAI). > >Can you please confirm? > >-Ramin > >> >>Kent >> >>At 08:54 AM 3/14/2004 -0800, Ramin wrote: >> >>>Does the draft permit or dis-allow the following: >>>Multiple mobile nodes with *distinct home addresses* use the *same NAI >>>and the same shared key* in order to request the HA to bind their CoA to >>>their HoA. >>> >>>Thank you, >>> >>>-Ramin >>> >>> >>>Alpesh wrote: >>> >>>>Hi - >>>> >>>>A new I-D are available for comments. It describes a hash based >>>>authentication for MIPv6. >>>> >>>> Abstract This document defines new >>>>mobility options to enable authentication between mobility >>>>entities. These options can be used in addition to or in lieu of >>>>IPsec to authenticate mobility messages as defined in [1]. >>>>Location: >>>>ftp://ftp-eng.cisco.com/mipdrafts/MIPv6/draft-patel-mipv6-auth-protocol-01.txt >>>> >>>> >>>>Your comments are welcome. >>>>Alpesh >>>> >>>> >>>> >>>>_______________________________________________ >>>>Mip6 mailing list >>>>Mip6@ietf.org >>>>https://www.ietf.org/mailman/listinfo/mip6 >> > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 25 16:14:25 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24929 for ; Thu, 25 Mar 2004 16:14:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cAn-0000nK-Uo for mip6-archive@odin.ietf.org; Thu, 25 Mar 2004 16:13:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2PLDv4T003049 for mip6-archive@odin.ietf.org; Thu, 25 Mar 2004 16:13:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6cAn-0000n6-Ct for mip6-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 16:13:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24843 for ; Thu, 25 Mar 2004 16:13:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6cAl-0003Ls-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 16:13:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6c9B-00035L-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 16:12:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1B6c70-0002he-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 16:10:02 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1B6c71-0005Sn-9W for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 16:10:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6c6y-0000Jj-Sh; Thu, 25 Mar 2004 16:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6c6j-0000JD-9C for mip6@optimus.ietf.org; Thu, 25 Mar 2004 16:09:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24037 for ; Thu, 25 Mar 2004 16:09:42 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6c6h-0002eD-00 for mip6@ietf.org; Thu, 25 Mar 2004 16:09:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6c3v-000265-00 for mip6@ietf.org; Thu, 25 Mar 2004 16:06:52 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B6c1F-0001cT-00 for mip6@ietf.org; Thu, 25 Mar 2004 16:04:06 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2PL45p15773 for ; Thu, 25 Mar 2004 23:04:05 +0200 (EET) X-Scanned: Thu, 25 Mar 2004 23:03:59 +0200 Nokia Message Protector V1.3.21 2004031416 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i2PL3x9k003988 for ; Thu, 25 Mar 2004 23:03:59 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00aInvon; Thu, 25 Mar 2004 23:03:58 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i2PL3us17638 for ; Thu, 25 Mar 2004 23:03:57 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 25 Mar 2004 15:03:55 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2004 15:03:55 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DBFE8@daebe007.americas.nokia.com> Thread-Topic: draft-perkins-mip6-precfgKbm-00.txt Thread-Index: AcQSrK50ibvLLELkQLavmBOGtKG9DQ== To: X-OriginalArrivalTime: 25 Mar 2004 21:03:55.0307 (UTC) FILETIME=[AF0287B0:01C412AC] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] draft-perkins-mip6-precfgKbm-00.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable There is consensus in the WG to make I-D : draft-perkins-mip6-precfgKbm-00.txt a WG document. However a couple of improvements have been suggested to the draft. These enhancements can be discussed on the ML and incorporated if there is agreement.=20 The I-D will be published as a WG I-D shortly. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Thu Mar 25 20:00:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06400 for ; Thu, 25 Mar 2004 20:00:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fhF-0003c9-0r for mip6-archive@odin.ietf.org; Thu, 25 Mar 2004 19:59:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2Q0xe3Z013893 for mip6-archive@odin.ietf.org; Thu, 25 Mar 2004 19:59:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6fhE-0003c0-Qc for mip6-web-archive@optimus.ietf.org; Thu, 25 Mar 2004 19:59:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06367 for ; Thu, 25 Mar 2004 19:59:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6fhD-0002FF-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 19:59:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6fgL-0002Bx-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 19:58:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B6ffd-00028W-00 for mip6-web-archive@ietf.org; Thu, 25 Mar 2004 19:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ffd-0003K0-1h; Thu, 25 Mar 2004 19:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B6ffE-0003JE-0L for mip6@optimus.ietf.org; Thu, 25 Mar 2004 19:57:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06301 for ; Thu, 25 Mar 2004 19:57:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B6ffB-00026F-00 for mip6@ietf.org; Thu, 25 Mar 2004 19:57:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B6feK-00023V-00 for mip6@ietf.org; Thu, 25 Mar 2004 19:56:41 -0500 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1B6fdV-0001xL-00 for mip6@ietf.org; Thu, 25 Mar 2004 19:55:49 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HV500B07RW11I@mailout1.samsung.com> for mip6@ietf.org; Fri, 26 Mar 2004 09:55:13 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HV50074TRW063@mailout1.samsung.com> for mip6@ietf.org; Fri, 26 Mar 2004 09:55:13 +0900 (KST) Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HV50073NRW0K6@mmp2.samsung.com> for mip6@ietf.org; Fri, 26 Mar 2004 09:55:12 +0900 (KST) Date: Fri, 26 Mar 2004 09:55:27 +0900 From: "S. Daniel Park" Subject: RE: [Mip6] draft-perkins-mip6-precfgKbm-00.txt In-reply-to: <697DAA22C5004B4596E033803A7CEF44024DBFE8@daebe007.americas.nokia.com> To: Basavaraj.Patil@nokia.com, mip6@ietf.org Cc: "'S. Daniel Park'" Message-id: <00cb01c412cd$075170f0$67cadba8@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7BIT Content-Transfer-Encoding: 7BIT not sure because I didn't follow up this thread fully but this is my personal concern. If this draft would be a RFC as standard track, I guess current RR in 24version will not be used for Mobile IPv6 with the implementation aspect. Is there any consideration or requirement ? I hope to see more improved and clarified something in this draft. Regards. - Daniel (Soohong Daniel Park) - Mobile Platform Laboratory, SAMSUNG Electronics. > -----Original Message----- > From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org] On > Behalf Of Basavaraj.Patil@nokia.com > Sent: Friday, March 26, 2004 6:04 AM > To: mip6@ietf.org > Subject: [Mip6] draft-perkins-mip6-precfgKbm-00.txt > > > > There is consensus in the WG to make I-D : > draft-perkins-mip6-precfgKbm-00.txt a WG document. > > However a couple of improvements have been suggested to the > draft. These enhancements can be discussed on the ML and > incorporated if there is agreement. > > The I-D will be published as a WG I-D shortly. > > -Chairs > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Sun Mar 28 10:45:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22077 for ; Sun, 28 Mar 2004 10:45:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cSu-0005Ly-Vf for mip6-archive@odin.ietf.org; Sun, 28 Mar 2004 10:44:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2SFimA1020573 for mip6-archive@odin.ietf.org; Sun, 28 Mar 2004 10:44:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cSu-0005Lk-On for mip6-web-archive@optimus.ietf.org; Sun, 28 Mar 2004 10:44:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22052 for ; Sun, 28 Mar 2004 10:44:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7cSs-0001w7-00 for mip6-web-archive@ietf.org; Sun, 28 Mar 2004 10:44:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7cRt-0001oB-00 for mip6-web-archive@ietf.org; Sun, 28 Mar 2004 10:43:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7cRE-0001gT-00 for mip6-web-archive@ietf.org; Sun, 28 Mar 2004 10:43:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cRB-0005AY-5S; Sun, 28 Mar 2004 10:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7cQp-00057Y-6a for mip6@optimus.ietf.org; Sun, 28 Mar 2004 10:42:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21977 for ; Sun, 28 Mar 2004 10:42:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7cQm-0001eq-00 for mip6@ietf.org; Sun, 28 Mar 2004 10:42:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7cPo-0001Xv-00 for mip6@ietf.org; Sun, 28 Mar 2004 10:41:37 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx with esmtp (Exim 4.12) id 1B7cOs-0001L5-00 for mip6@ietf.org; Sun, 28 Mar 2004 10:40:39 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2SFe05P009506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Mar 2004 07:40:01 -0800 (PST) Received: from NAEXFE03.na.qualcomm.com (naexfe03.qualcomm.com [172.30.32.23]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id i2SFdwVJ021496; Sun, 28 Mar 2004 07:39:58 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.61]) by NAEXFE03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 28 Mar 2004 07:39:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Comments on kempf-mip6-bootstrap Date: Sun, 28 Mar 2004 07:40:35 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F327DAA@NAEX01.na.qualcomm.com> Thread-Topic: [Mip6] Comments on kempf-mip6-bootstrap Thread-Index: AcP+k0LapUUIStLATZm93M2y8DHgmgWRlvDA From: "Barany, Pete" To: "Alper Yegin" , X-OriginalArrivalTime: 28 Mar 2004 15:39:58.0158 (UTC) FILETIME=[ECCE36E0:01C414DA] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, In regards to your first point below, I am not quite sure what you are saying. During the IKEv2 IKE_AUTH phase, the initiator message looks as follows (per IKEv2 -12 I-D): HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr] AUTH, SAi2, TSi, TSr} --> The responder message looks like: <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Are you saying that in the initiator's message the TSi, TSr will be wildcarded (i.e., is that what you mean by NULL)? Wouldn't the TSi included (at a minimum), the dynamic HoA, protocol MH in order to update SPD? Also, are saying that the IDi in the initiator's message will be mapped to the SPI(s) in SAi2? If so, is the SPI mapped (indirectly via the IDi) to a name selector? Thanks. Regards, Pete -----Original Message----- From: mip6-admin@ietf.org [mailto:mip6-admin@ietf.org] On Behalf Of Alper Yegin Sent: Saturday, February 28, 2004 11:08 PM To: mip6@ietf.org Subject: [Mip6] Comments on kempf-mip6-bootstrap Hello James, Jari, I've just read the draft. Please see my comments below. With IKEv1, the mobile node needs to have a statically defined home address in order that the home agent can make an authorization decision and identify the credentials during the IKE Phase 1 ISAKMP exchange. In this document, we discuss why these constraints may be problematic in some deployment scenarios. IKEv2 allows named SPIs with address selectors set to NULL. Names can be NAI and FQDN. If we use IKEv2, do we still have a problem? However, support for dynamic home address assignment would be desirable for the following reasons: DHCP-based address assignment Some ISPs may want to use DHCPv6 from the home network to configure home addresses [7]. I think we are concerned that the MN might get different DHCP addresses each time it asks for one. Note that deployments can ensure that the host (MN) gets the same IP address (home address) by supplying a client-id with DHCP requests. So, this may not be a problem.=20 Currently, the address of the home agent is specified in the security policy database. Support for multiple home agents requires the configuration of multiple security policy database entries. We are talking about SPDs on the MN, right? If so, is this a problem? MN can set the HA address in the SPD once it determines which HA it will be using. The challenge is, I think, bootstrapping the keys for a given HA. Ease of deployment ISP may want to allow "opportunistic" discovery and utilization of its mobility services without any prearranged contact. These scenarios will require dynamic home address assignment. ... and keys. The current IKEv1-based dynamic key exchange protocol described in [5] has no integration with backend authentication, authorization and accounting techniques unless the authentication credentials and trust relationships use certificates. Isn't this an implementation issue? For example can't I use LDAP to retrieve the keys for a MN when my HA receives an IKE request? Well, there isn't a RADIUS or Diameter application for this scenario, maybe this is what you mean. But I think this doesn't require integration of IKE with RADIUS/Diameter. Using certificates may require the ISP to deploy a PKI, which may not be possible or desirable in certain circumstances. Where a traditional AAA infrastructure is used, the home agent is not able to leverage authentication and authorization information established between the mobile node, the foreign AAA server, and the home AAA server when the mobile node gains access to the foreign network, in order to authenticate the mobile node's identity and determine if the mobile node is authorized for mobility service. This is talking about integration of AAA for network access and AAA for mobility management. I think "AAA for mobility management" does not necessarily imply this level of integration.=20 The lack of connection to the AAA infrastructure also means the home agent does not know where to issue accounting records at appropriate times during the mobile node's session, as determined by the business relationship between the home ISP and the mobile node's owner. Presumably, some backend AAA protocol between the home agent and home AAA could be utilized but IKEv1 does not contain support for exchanging the right kind of information, primarily the NAI [6], with the mobile node. Mobility management and network access are two separate services. We shouldn't assume they have to be integrated.=20 The home agent discovery protocol does not support "opportunistic" or local discovery mechanisms in a roaming partner's local access network. It is expected that the mobile node must know the prefix of the home subnet in order to be able to discover a home agent, it must either obtain that information through prefix update or have it statically configured. A more typical pattern for interdomain service discovery in the Internet is that the client (mobile node in this case) knows the domain name of the service, and uses DNS in some manner to find the server in the other domain. For local service discovery, DHCP is typically used. If HAs are located on the visited links, then the current dynamic home agent discovery is good enough. If they are somewhere deeper in the access network, then a DHCP-based discovery, or what HMIP approach can be utilized. Another scenario involves turning an existing security association in the user's home network for a different purpose into a new security association suitable for protecting Mobile IPv6. For instance, an existing security association for a VPN service could be used to generate suitable Mobile IPv6 security associations, on a first-come-first-served home address basis. Wouldn't some (most?) problems we encountered with the Mobile IPv6 service also apply to the VPN service?=20 For instance, when the mobile node boots and connects to the network for the first time, it could create a security association with the access operator's home agent. This home agent could then be used as the mobile node moves into a different position or even into a different access network. We are applying this type of a technique to the DHCP security problem. Please see draft-yegin-eap-boot-rfc3118-00.txt Regards, Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 29 04:56:44 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22640 for ; Mon, 29 Mar 2004 04:56:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tV9-0002ur-FG for mip6-archive@odin.ietf.org; Mon, 29 Mar 2004 04:56:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2T9uFqV011210 for mip6-archive@odin.ietf.org; Mon, 29 Mar 2004 04:56:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tV9-0002uj-6O for mip6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 04:56:15 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22603 for ; Mon, 29 Mar 2004 04:56:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tV6-0002hD-00 for mip6-web-archive@ietf.org; Mon, 29 Mar 2004 04:56:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tU8-0002ZF-00 for mip6-web-archive@ietf.org; Mon, 29 Mar 2004 04:55:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7tT7-0002Oy-00 for mip6-web-archive@ietf.org; Mon, 29 Mar 2004 04:54:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tT2-0002b2-DN; Mon, 29 Mar 2004 04:54:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tSP-0002Wb-6h for mip6@optimus.ietf.org; Mon, 29 Mar 2004 04:53:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22476 for ; Mon, 29 Mar 2004 04:53:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tSM-0002Ke-00 for mip6@ietf.org; Mon, 29 Mar 2004 04:53:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tRX-0002CU-00 for mip6@ietf.org; Mon, 29 Mar 2004 04:52:31 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B7tQp-000236-00 for mip6@ietf.org; Mon, 29 Mar 2004 04:51:48 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 5BCD1898C0; Mon, 29 Mar 2004 12:51:41 +0300 (EEST) Message-ID: <4067F110.8090002@kolumbus.fi> Date: Mon, 29 Mar 2004 12:49:04 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com Cc: mip6@ietf.org Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt References: <697DAA22C5004B4596E033803A7CEF44024DBFE8@daebe007.americas.nokia.com> In-Reply-To: <697DAA22C5004B4596E033803A7CEF44024DBFE8@daebe007.americas.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > There is consensus in the WG to make I-D : > draft-perkins-mip6-precfgKbm-00.txt a WG document. I'm not opposed to making this document a WG item, but I was kind of hoping to get an answer to some of my questions from the chairs before we make a decision. Here are the questions from my March 22nd e-mail to you and James Kempf: > Re: charter. The draft does fall within the charter, > and I think we should do it (perhaps with some > agreement first on how ambitious scope it should have). > But I believe we have also other issues that we should > take care of in the RO space, perhaps even higher priority > issues. So I'd really like to ensure that we can actually > do more than Charlie's draft. This brings me to ... > > Raj: You didn't answer my question on whether > more than one improvement can be adopted by the > WG. My reading of the charter item: > > - Route optimization will require security mechanisms for > trusting and updating the binding information.Return-routability > is the basic mechanism for route-optimization. Mechanisms using > a shared secret Key/Security Association will be considered. > Methods for establishing a security association between the > mobile node and the correspondent node are out of the scope > of the WG. > > is that shared secrets are just one example and other > mechanisms can be considered. If that's your interpretation > as well, then I don't need to worry that we are preventing > other necessary work to take place. > > Also, I have a question about the charter It says: > > It should be noted that there are potential optimizations > that might make mobile IP more attractive for use by certain > applications (e.g., making handovers "faster"). The latter > category of optimizations is explicitly out-of-scope at this > time; this WG will focus on issues for which there is strong > consensus that the work is needed to get basic mobility > deployable on a large scale. > > What does this mean, exactly? Why does it not apply to > the kbm draft, as its main purpose (I think) is to have > less signaling and delay? Would it apply other alternatives > to RR? Or is this paragraph in the charter to avoid collision > with MIPSHOP? That's my interpretation, but I'm not sure > this is the way others read it... _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Mon Mar 29 05:05:59 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23021 for ; Mon, 29 Mar 2004 05:05:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7te6-0003sd-9S for mip6-archive@odin.ietf.org; Mon, 29 Mar 2004 05:05:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2TA5UR1014889 for mip6-archive@odin.ietf.org; Mon, 29 Mar 2004 05:05:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7te2-0003s0-Tt for mip6-web-archive@optimus.ietf.org; Mon, 29 Mar 2004 05:05:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23012 for ; Mon, 29 Mar 2004 05:05:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tdz-0003xX-00 for mip6-web-archive@ietf.org; Mon, 29 Mar 2004 05:05:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tdA-0003pw-00 for mip6-web-archive@ietf.org; Mon, 29 Mar 2004 05:04:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B7tcf-0003hR-00 for mip6-web-archive@ietf.org; Mon, 29 Mar 2004 05:04:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tcg-0003l9-LL; Mon, 29 Mar 2004 05:04:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B7tcC-0003iS-NB for mip6@optimus.ietf.org; Mon, 29 Mar 2004 05:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22928 for ; Mon, 29 Mar 2004 05:03:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B7tc9-0003fD-00 for mip6@ietf.org; Mon, 29 Mar 2004 05:03:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B7tbJ-0003XD-00 for mip6@ietf.org; Mon, 29 Mar 2004 05:02:38 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1B7tam-0003OM-00 for mip6@ietf.org; Mon, 29 Mar 2004 05:02:04 -0500 Received: from kolumbus.fi (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id ADCC0898C1; Mon, 29 Mar 2004 13:02:05 +0300 (EEST) Message-ID: <4067F380.4040303@kolumbus.fi> Date: Mon, 29 Mar 2004 12:59:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "S. Daniel Park" Cc: Basavaraj.Patil@nokia.com, mip6@ietf.org Subject: Re: [Mip6] draft-perkins-mip6-precfgKbm-00.txt References: <00cb01c412cd$075170f0$67cadba8@LocalHost> In-Reply-To: <00cb01c412cd$075170f0$67cadba8@LocalHost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit S. Daniel Park wrote: > not sure because I didn't follow up this thread fully but > this is my personal concern. > > If this draft would be a RFC as standard track, I guess > current RR in 24version will not be used for Mobile IPv6 > with the implementation aspect. Is there any consideration > or requirement ? I hope to see more improved and clarified > something in this draft. I may have misunderstood the question, but the proposed mechanism is an alternative and optional scheme for authorizing BUs related to route optimization. As such, the base RR mechanism is used by default unless this specific scheme is implemented and configured on. The proposed mechanism is applicable only to a certain (limited) class of situations, so you would not always have such a configuration available. Or perhaps you are asking whether the mechanism is used in addition to RR? I think the authors have inteded the mechanim to be used as a replacement (for the situations that it applies to) rather than as an add-on. There has also been some discussion on the list about whether the proposed mechanism should be merged with care of address testing from the base RFC or possibly some improvement of that, such as CBA/EBU. I personally think that something along those lines might be fruitful and would make the mechanism more widely applicable, though it may be too early to tell yet. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 17:51:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20658 for ; Tue, 30 Mar 2004 17:51:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rji-0006Zv-MP for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2379RiL005736 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 02:09:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQVS-0001Ty-16 for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:09:26 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18202 for ; Wed, 3 Mar 2004 02:09:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQVO-0005vX-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:09:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQUN-0005hf-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:08:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyQT8-0005LB-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:07:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQTA-0000Eq-It; Wed, 03 Mar 2004 02:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4Ef-0004ZX-Kt for mip6@optimus.ietf.org; Tue, 02 Mar 2004 02:22:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21622 for ; Tue, 2 Mar 2004 02:22:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4Eb-0004YW-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:22:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4Dq-0004Qg-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:21:47 -0500 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4D0-0004H8-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:20:54 -0500 Received: from FTRDMEL2.rd.francetelecom.fr ([10.193.117.153]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 2 Mar 2004 08:20:33 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE : [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND Date: Tue, 2 Mar 2004 08:20:33 +0100 Message-ID: Thread-Topic: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND Thread-Index: AcP/8xlYYhDFS/ufQVyVVXdwNqhlUAAMj8XA From: "NJEDJOU Eric FTRD/DMR/REN" To: "James Kempf" , "Gregory Daley" Cc: "Pekka Nikander" , "Stefan Aust" , , =?iso-8859-1?Q?Carmelita_G=F6rg?= , "Niko A. Fikouras" , "Cornel Pampu" , "Dna" , "Greg Daley" , X-OriginalArrivalTime: 02 Mar 2004 07:20:33.0829 (UTC) FILETIME=[D9EEF550:01C40026] Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable > -----Message d'origine----- > De : owner-dna@ecselists.eng.monash.edu.au=20 > [mailto:owner-dna@ecselists.eng.monash.edu.au] De la part de=20 > James Kempf > Envoy=E9 : mardi 2 mars 2004 01:02 > =C0 : Gregory Daley; NJEDJOU Eric FTRD/DMR/REN > Cc : Pekka Nikander; Stefan Aust; basavaraj.patil@nokia.com;=20 > Carmelita G=F6rg; Niko A. Fikouras; Cornel Pampu; Dna; Greg=20 > Daley; mip6@ietf.org > Objet : Re: [Mip6] Re: RE : [DNA] Current IETF-Draft version=20 > - POLIMAND >=20 >=20 > I hesitate to even bring this up, but there's a long history=20 > in the IETF of trying to figure out where to do this kind of=20 > work. We've been working on multiple interface (vertical)=20 > handover, handover optimization, and such in MIP and Seamoby=20 > for over three years. There are some experimental protocols=20 > (CARD, CTP, FMIP, HMIP) approaching publication, but they=20 > still need a lot of work before they are ready for=20 > deployment. The effort has been hampered by a lack of=20 > impending product or deployment pressure.=20 Well these protocols (CARD, CTP, FMIP, HMIP) could not and can not be = ready for deployment as they essentially assume that IPv6, then Mobile = IPv6 be deployed, at least partially, as the aforementionned protocols = rely on IPv6 and mobile IPv6. Mobile IPv6 products are now coming out = from vendors shelves. We can avoid to wait for (CARD, CTP, FMIP, HMIP) = before providing optimisation for MIPv6 handover by bringing "simple" = additions to the base specification that would already provide smoother = handover as a sort of "work around". Then when we would get enough = feedback from MIPv6 deployment issues we would be able to rethink at the = way CARD,... Could be adapted.=20 >IETF does not=20 > function well when a particular technology does not have a=20 > group of vendors and network operators behind it who need=20 > interoperability for their product or deployment, and that=20 > has been the case for this particular technology. > The result is that the work has been moved to the IRTF=20 > MOBOPTS research group, and I would advise that any proposals=20 > be taken there. >=20 It already the case, at least for ours. > jak >=20 > ----- Original Message -----=20 > From: "Gregory Daley" > To: "NJEDJOU Eric FTRD/DMR/REN" > Cc: "Pekka Nikander" ; "Stefan=20 > Aust" ;=20 > ; "Carmelita G=F6rg"=20 > ; "Niko A. Fikouras"=20 > ; "Cornel Pampu"=20 > ; "Dna" ;=20 > "Greg Daley" ; > Sent: Monday, March 01, 2004 7:19 AM > Subject: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND >=20 >=20 > > Hi, > > > > I know that this has been cross posted, so I'll > > respond to both lists, but perhaps we can talk about > > specific issues in the individual mailing lists > > subsequently. I'd suggest DNA, unless the MIP6 > > chairs wish to respond. > > > > If we need to discuss needs more generally for > > multiple interface configuration procedures or > > vertical handoff, it may be useful to take it up > > with the chairs of either or both WGs (depending > > on the circumstances). > > > > Please see my take below. > > ----- Original Message ----- > > From: NJEDJOU Eric FTRD/DMR/REN > > Date: Monday, March 1, 2004 9:51 pm > > Subject: RE : [DNA] Current IETF-Draft version - POLIMAND > > > > > Pekka, > > > The problem with MIP6 movement detection handover=20 > optimizations (see=20 > > > http://www.ietf.ord/I-D/draft-daniel-mip6-optimized-vertical- > > > handover-00.txt for another draft) is that it is being considered=20 > > > out of scope for DNA because of the mobile IPv6 issue=20 > raised and out=20 > > > of scope for MIP6 because of the link triggers that has=20 > to be taken=20 > > > into account. Actually, it is within the scope of both as > > > > I'd guess while this is frustrating, it's largely a=20 > statement of fact. > > > > Please inform me of any incorrect statements I make, since=20 > there may=20 > > be subtlties I miss in the drafts. > > > > While the drafts being discussed are principally interested in=20 > > handling multiple connectivity scenarios associated with wireless=20 > > networks, neither MIPv6 (regarding Link hints) or DNA (Discussing=20 > > global signalling) are currently chartered to work on these topics. > > > > It is indeed possible that the combination of the=20 > techniques is seen=20 > > as the stumbling block by both groups. > > > > For example, if indeed it is necessary to provide vertical handover=20 > > support for MIPv6, is it strictly necessary to talk about=20 > link layer=20 > > interactions (polimand may talk about policy instead, Of=20 > course, it is=20 > > always hard to standardize policy). > > > > Whether a document looking at multiple interface connectivity for=20 > > MIPv6 would be useful or not (or whether there's much difference=20 > > except the movement detection algorithm) I don't know. > > > > Particularly for DNA, we can't really discuss handovers,=20 > considering=20 > > that this term principally refers to session restoration or=20 > > continuation using mobility protocols. > > > > DNA is looking basically at signalling using mechanisms within the=20 > > local link only. Any reference to other protocols (except in a=20 > > confined way) can make documents look like they're (for=20 > example) MIP=20 > > specific. > > > > If there's a difference in the configuration detection=20 > procedures when=20 > > a host has multiple interfaces, that may be different. > > > > For example, a host may wish to wait passively for router=20 > > advertisements on the GPRS interface (testing reachability when the=20 > > host switches connections to that interface), and probes fairly=20 > > aggressively on a WLAN interface. > > > > Any decision or action based on this the configuration detection is=20 > > starting to push into uncomfortable areas as far as DNA's tight=20 > > charter is concerned. Perhaps this is analogous to the reasoning=20 > > used in MIP6? > > > > > DNA -link triggers/hints that will be=20 > catalogued/standardized within=20 > > > DNA will also be used for Mobile IPv6 optimised movement=20 > detection.=20 > > > Other ones may be needed for this specific purpose.=20 > Better detecting=20 > > > network attchment/detachment is a requirement for Mobile=20 > IPv6 better=20 > > > performance movement detection and handover. These issues are=20 > > > therefore strongly linked. > > > > I think we have to be particularly careful about the word=20 > standardized=20 > > in the previous paragraph. There's already been some out-of-band=20 > > feedback to DNA that we should avoid delving into=20 > standardization of=20 > > L2 oriented mechanisms. > > > > > MIP6 -Optimized movement detection an handover schemes are=20 > > > essenttial for base Mobile IPv6 Operation, which means,=20 > the protocol=20 > > > operation needs exploiting L2 triggers/hints. And MIPv6=20 > > > implementors use L2 triggers/hints in a confusing way, if not at > all. > > > > While the usage of hints may be unavoidable in some DNA=20 > schemes, there=20 > > will still be some systems where it is not possible to the=20 > the kind of=20 > > hints you desire. It would be short-sighted to design=20 > systems which=20 > > only work if information from the link-layer is reliable and=20 > > available. > > > > > We could be ping-ponging betwwen these two groups for years. > > > > I really hope not, but MOBOPTS isn't necessarily a place=20 > for killing=20 > > ideas off to (no matter what some people say!). Our=20 > research team has=20 > > (voluntarily!) submitted some ideas there for further discussion=20 > > recently and gotten useful feedback. > > > > I don't even mind if people winnow their existing work down to a=20 > > problem statement which is DNA centric. It may be that there's a=20 > > chance that we'd think it out-of-scope anyway, but that's=20 > because the=20 > > WG scope is very narrow. > > > > If the work is clear input into one of the documents on the DNA=20 > > charter, that may change things. > > > > We're only likely to produce 4 documents this year=20 > (optimistically).=20 > > so focussing on how the vertical handover/polimand work can=20 > directly=20 > > help those is more immediately useful. > > > > As Pekka said, this may mean leaving MIPv6 specific parts=20 > to MIP6WG or=20 > > MOBOPTS. > > > > Greg > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www.ietf.org/mailman/listinfo/mip6 > > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 17:52:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20875 for ; Tue, 30 Mar 2004 17:52:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjk-0006ZK-24 for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i295TFCR016370 for mip6-archive@odin.ietf.org; Tue, 9 Mar 2004 00:29:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0ZlV-0003fy-Pj for mip6-web-archive@optimus.ietf.org; Tue, 09 Mar 2004 00:26:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22631 for ; Tue, 9 Mar 2004 00:26:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0ZlE-0003eX-00 for mip6-web-archive@ietf.org; Tue, 09 Mar 2004 00:26:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0ZkM-0003Re-00 for mip6-web-archive@ietf.org; Tue, 09 Mar 2004 00:25:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0Zj9-000341-00 for mip6-web-archive@ietf.org; Tue, 09 Mar 2004 00:24:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Zik-0002Y9-L9; Tue, 09 Mar 2004 00:24:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0Ylm-0007Ow-GC for mip6@optimus.ietf.org; Mon, 08 Mar 2004 23:23:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20318 for ; Mon, 8 Mar 2004 23:23:03 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0Ylk-0001eW-00 for mip6@ietf.org; Mon, 08 Mar 2004 23:23:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0Ykn-0001Vg-00 for mip6@ietf.org; Mon, 08 Mar 2004 23:22:05 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx with esmtp (Exim 4.12) id 1B0Yjp-0001Mr-00 for mip6@ietf.org; Mon, 08 Mar 2004 23:21:05 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i294L5a25681 for ; Tue, 9 Mar 2004 06:21:05 +0200 (EET) X-Scanned: Tue, 9 Mar 2004 06:21:01 +0200 Nokia Message Protector V1.3.20 2004022613 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id i294L18o005003 for ; Tue, 9 Mar 2004 06:21:01 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00ZK51k1; Tue, 09 Mar 2004 06:20:59 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i294KrH13556 for ; Tue, 9 Mar 2004 06:20:53 +0200 (EET) Received: from daebe007.NOE.Nokia.com ([10.241.35.107]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 8 Mar 2004 22:20:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Mar 2004 22:20:51 -0600 Message-ID: <697DAA22C5004B4596E033803A7CEF44032EAAAB@daebe007.americas.nokia.com> Thread-Topic: IETf59 MIP6 WG Slides Thread-Index: AcQFjZx2ZXsYWfg9QOW0a+LhUQqOXw== To: X-OriginalArrivalTime: 09 Mar 2004 04:20:52.0187 (UTC) FILETIME=[E87732B0:01C4058D] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] IETf59 MIP6 WG Slides Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Slides used at the IETF59 MIP6 WG meeting are at: http://www.mindspring.com/~bpatil/IETF59/ -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 17:52:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20893 for ; Tue, 30 Mar 2004 17:52:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjg-0006ZK-GP for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248ea6m014592 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:40:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoP5-0003mR-Ni for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:40:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29279 for ; Thu, 4 Mar 2004 03:40:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoOv-000279-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:40:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoMa-0001Qx-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:37:52 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyoLG-0001A5-01 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:36:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyoDN-00014M-5Y for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:28:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoD8-0002CE-7g; Thu, 04 Mar 2004 03:28:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoCD-00028m-TJ for mip6@optimus.ietf.org; Thu, 04 Mar 2004 03:27:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28499 for ; Thu, 4 Mar 2004 03:27:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoCA-0007CY-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:27:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoAn-0006rr-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:25:42 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo9N-0006NW-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:24:13 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1Ayo93-0007Gi-00; Thu, 04 Mar 2004 09:23:53 +0100 Received: from atiswww by irams1.ira.uka.de with local (Exim 3.30 #7 ) id 1Ayo92-0003Oj-00; Thu, 04 Mar 2004 09:23:52 +0100 Received: from 218.37.229.38 ([218.37.229.38]) by mailhost.ira.uka.de (IMP) with HTTP for ; Thu, 4 Mar 2004 09:23:52 +0100 Message-ID: <1078388632.4046e79842afc@mailhost.ira.uka.de> Date: Thu, 4 Mar 2004 09:23:52 +0100 From: Christian Vogt To: Erik Nordmark Cc: Francis Dupont , Jari Arkko , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 218.37.229.38 Content-Transfer-Encoding: 8bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit > Perhaps the draft discusses this, but when you handle an > early binding update, when is "HoA check" in the binding > cache updated? Hi Erik, you are right: An Early Binding Update message is authenticated by a key which was produced with a Home Keygen Token. The correspondent node must verify this authentication. (I think this is what you refer to as a "HoA check [update]".) So here again, if ingress filtering was employed at the mobile node's (i.e., the attacker's) access network, the mobile node (attacker) would not be able to fake the IP source address of the Early Binding Update message as well as of any data packet. As an aside: An Early Binding Update message is authenticated in the same way as a standard Mobile IPv6 Binding Update message when used by a mobile node which returns to its home network and wishes to delete an existing binding. When the correspondent node receives an Early Binding Update message, it updates the associated binding-cache entry, which then becomes tentative. The updated, tentative binding-cache entry is equivalent to a standard Mobile IPv6 binding-cache entry, except that its lifetime is shorter. Best regards - Christian | | Christian Vogt | Institute of Telematics, University of Karlsruhe | www.tm.uka.de/~chvogt/ | Quoting Erik Nordmark : > > => this is the first property, the second is to be > > immune to the ingress filtering (the CoA is the source > > address and is the address of the victim so the > > ingress filtering is the proper defense). > > Are you saying that the source address of the BU must > be the (new) CoA? > > Hmm - maybe that is sufficient in the MIPv6 case (I have > multi6 in the back of my head as well, which has a > variant of the same issues.) > > Perhaps the draft discusses this, but when you handle an > early binding update, when is "HoA check" in the binding > cache updated? > > In basic MIPv6 this happens when the BU is processed > i.e. after that the MN can no longer send packets with > the old CoA as the source since the Home Address option > check will drop such packets. If the same thing applies > in the early binding update case it means that the > attacker can not send any "ack" packets to the CN since > they would contain the "old" CoA - oops - they would not > carry a home address option thus they would not be > subject to "the HOA and IP src must match the binding > cache" check. Hmm... > > Erik ------------------------------------------------------------- This message was sent through ATIS: http://atiswww.ira.uka.de _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 17:52:37 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21005 for ; Tue, 30 Mar 2004 17:52:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjg-0006ZK-CE for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B93UDL006218 for mip6-archive@odin.ietf.org; Wed, 11 Feb 2004 04:03:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqHK-0001cD-9U for mip6-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 04:03:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23184 for ; Wed, 11 Feb 2004 04:03:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqqHH-00021L-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 04:03:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqqGN-0001wr-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 04:02:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqqFx-0001s7-00 for mip6-web-archive@ietf.org; Wed, 11 Feb 2004 04:02:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqFu-0001OO-7H; Wed, 11 Feb 2004 04:02:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqqFV-0001NP-Ox for mip6@optimus.ietf.org; Wed, 11 Feb 2004 04:01:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23150 for ; Wed, 11 Feb 2004 04:01:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqqFT-0001rk-00 for mip6@ietf.org; Wed, 11 Feb 2004 04:01:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqqEX-0001mG-00 for mip6@ietf.org; Wed, 11 Feb 2004 04:00:38 -0500 Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx with esmtp (Exim 4.12) id 1AqqE9-0001eG-00 for mip6@ietf.org; Wed, 11 Feb 2004 04:00:13 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0HSW00A6CWSJWK@dns2.cselt.it> for mip6@ietf.org; Wed, 11 Feb 2004 09:55:31 +0100 (MET) Received: from iowa2k01b.cselt.it ([163.162.242.204]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Feb 2004 09:58:56 +0100 Received: from EXC2K04A.cselt.it ([163.162.161.229]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Feb 2004 09:58:56 +0100 Received: from EXC2K01B.cselt.it ([163.162.4.97]) by EXC2K04A.cselt.it with Microsoft SMTPSVC(5.0.2195.5329); Wed, 11 Feb 2004 09:59:42 +0100 Date: Wed, 11 Feb 2004 09:59:42 +0100 From: Giaretta Gerardo To: mip6@ietf.org Message-id: <625BE97BF4795E43970345790166B9BCD4DC9E@EXC2K01B.cselt.it> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: New I-D: Mobile IPv6 Authorization and Configuration based on EAP Thread-Index: AcPwfSgq40XlKxUrTYC4Ejr0UCRavg== content-class: urn:content-classes:message X-OriginalArrivalTime: 11 Feb 2004 08:59:43.0194 (UTC) FILETIME=[63C503A0:01C3F07D] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] New I-D: Mobile IPv6 Authorization and Configuration based on EAP Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, we submitted a new I-D, draft-giaretta-mip6-authorization-eap-00.txt. It defines a method for performing dynamic Mobile IPv6 authorization and = configuration relaying on a AAA infrastructure: the necessary = interaction between the AAA server of the home provider and the mobile = node is realized using EAP, exploiting the capability of some EAP = methods (e.g. PEAPv2) to convey generic information items together with = authentication data.=20 =20 The Internet-Draft is available from the on-line Internet-Drafts = directories. The URL is: http://www.ietf.org/internet-drafts/draft-giaretta-mip6-authorization-eap= -00.txt Any comments are welcome. Best Regards, --Gerardo Giaretta =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 17:57:03 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22015 for ; Tue, 30 Mar 2004 17:57:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjc-0006a4-SX for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248ehwI014642 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:40:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoPH-0003ns-Mo for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:40:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29342 for ; Thu, 4 Mar 2004 03:40:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoPF-0002ES-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:40:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoMv-0001V8-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:38:13 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyoLI-0001A5-02 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:36:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyoAF-0000y6-Ss for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoAC-0001sI-17; Thu, 04 Mar 2004 03:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayo9J-0001YD-AT for mip6@optimus.ietf.org; Thu, 04 Mar 2004 03:24:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27943 for ; Thu, 4 Mar 2004 03:24:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ayo9F-0006KU-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:24:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ayo7W-0005p1-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:22:18 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ayo5w-0005Tb-03 for mip6@ietf.org; Thu, 04 Mar 2004 03:20:41 -0500 Received: from p2.piuha.net ([131.160.192.2]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aynpo-0000cr-KI for mip6@ietf.org; Thu, 04 Mar 2004 03:04:00 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id A97126A906; Thu, 4 Mar 2004 10:03:55 +0200 (EET) Message-ID: <4046E263.7010204@kolumbus.fi> Date: Thu, 04 Mar 2004 10:01:39 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Erik Nordmark , Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 References: <200403040655.i246t1Sj064509@givry.rennes.enst-bretagne.fr> In-Reply-To: <200403040655.i246t1Sj064509@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Francis Dupont wrote: > => I don't know a case where a real alternate CoA is needed or even > useful with a common correspondent in Mobile IPv6. I also don't know of a practical case where this would be needed. (I may still disagree on whether skipping alt-coa is a defense.) --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 17:57:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22044 for ; Tue, 30 Mar 2004 17:57:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rjd-0006ZK-2E for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GGgc6v017353 for mip6-archive@odin.ietf.org; Mon, 16 Feb 2004 11:42:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AslpO-0004Vo-Nz for mip6-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 11:42:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04011 for ; Mon, 16 Feb 2004 11:42:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AslpN-00072J-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:42:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsloU-0006xI-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:41:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aslnt-0006s6-00 for mip6-web-archive@ietf.org; Mon, 16 Feb 2004 11:41:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aslns-0004JH-SX; Mon, 16 Feb 2004 11:41:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aslng-0004IU-2Q for mip6@optimus.ietf.org; Mon, 16 Feb 2004 11:40:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03819 for ; Mon, 16 Feb 2004 11:40:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aslne-0006qU-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:40:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aslmu-0006ig-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:40:04 -0500 Received: from iramx1.ira.uni-karlsruhe.de ([141.3.10.80]) by ietf-mx with esmtp (Exim 4.12) id 1Aslls-0006aa-00 for mip6@ietf.org; Mon, 16 Feb 2004 11:39:01 -0500 Received: from i72ms2.tm.uni-karlsruhe.de ([141.3.70.17] helo=i72mail01.tm.uka.de) by iramx1.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1Asllc-0004ak-00; Mon, 16 Feb 2004 17:38:44 +0100 Received: from i72chvogt.tm.uni-karlsruhe.de ([141.3.71.83] helo=i72ChVogt) by i72mail01.tm.uka.de with esmtp (Exim 4.30) id 1Asllc-0004fH-7s; Mon, 16 Feb 2004 17:38:44 +0100 Message-ID: <020001c3f4a2$faeb74c0$5347038d@tm.unikarlsruhe.de> From: "Christian Vogt" To: "Jari Arkko" Cc: "Brian Haley" , References: <001b01c3ee73$aa4f9da0$5347038d@tm.unikarlsruhe.de> <4027C703.2080209@hp.com> <021d01c3efe8$15f14390$5347038d@tm.unikarlsruhe.de> <403024A4.6020006@kolumbus.fi> Subject: Re: [Mip6] New I-D: Early Binding Updates for Mobile IPv6 Date: Mon, 16 Feb 2004 16:38:52 +0100 Organization: Institute of Telematics, University of Karlsruhe (TH) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: base64 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=2.5 required=5.0 tests=AWL,MIME_BASE64_LATIN, MIME_BASE64_TEXT autolearn=no version=2.60 Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SGkgSmFyaSwNCg0KbXkgY29tbWVudHMgYXJlIGJldHdlZW4gdGhlIHNuaXBwZXRzIG9mIHlvdXIg ZW1haWwuIFlvdXIgY29tcGxldGUgZW1haWwgaXMgZ2l2ZW4gYXQgdGhlIGJvdHRvbS4NCg0KPiAt IFRoZSBiYXNlIGRyYWZ0IGFscmVhZHkgYWxsb3dzIGNhY2hpbmcgYW5kIHJlLXVzZSBvZiBob21l DQo+ICAgIGtleWdlbiB0b2tlbnMuIChPciBtYXliZSBJIGp1c3QgdGhvdWdodCBpdCBkb2VzPyBB bnl3YXksDQo+ICAgIGl0IGRvZXMgbm90IG1hdHRlciBlaXRoZXIgd2F5LCBpdHMgZ29vZCB0aGF0 IHlvdSBkcmFmdA0KPiAgICBleHBsYWlucyBob3cgdG8gZG8gaXQganVzdCBiZWZvcmUgbW92ZW1l bnQuKQ0KDQpZZXMsIHRoZSBNb2JpbGUgSVB2NiBzcGVjaWZpY2F0aW9uIGV4cGxpY2l0bHkgYWxs b3dzIHJlLXVzaW5nIGJvdGggSG9tZSBhbmQsIHdoZXJlIGFwcGxpY2FibGUsIENhcmUtb2YgS2V5 Z2VuIFRva2Vucy4gVGhpcyBhbGxvd3MgYSBNTiB0byBkbyBhbiBhbnRpY2lwYXRlZCAob3IgcGVy aW9kaWMpIGhvbWUtYWRkcmVzcyB0ZXN0IHByaW9yIHRvIGhhbmRvdmVyIGFzIHByb3Bvc2VkIGlu IFsyXSB3aXRob3V0IHZpb2xhdGluZyB0aGUgTW9iaWxlIElQdjYgcHJvdG9jb2wgcHJvY2VkdXJl LiAoU2VlIHRoZSBsYXN0IHR3byBwYXJhZ3JhcGhzIG9mIHNlY3Rpb24gNS4yLjcgaW4gWzFdIGFz IHdlbGwgYXMgdGhlIHNlY29uZCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiA0IGluIFsyXS4pIFRoZSBw b3NzaWJpbGl0eSBvZiBhbnRpY2lwYXRlZCAob3IgcGVyaW9kaWMpIGhvbWUtYWRkcmVzcyB0ZXN0 cywgdGhvdWdoLCBpcyBub3QgbWVudGlvbmVkIGluIFsxXS4NCg0KPiAtIFlvdXIgYXJndW1lbnQg dGhhdCB0aGUgYXR0YWNrZXIgaGFzIHRvIGtlZXAgYSBsb3Qgb2YNCj4gICAgc3RhdGUgaWYgbXVs dGlwbGUgQ05zIGFyZSB1c2VkLiBIbW0uLi4uIEkgbWVtb3J5IGlzDQo+ICAgIGNoZWFwIHRoZXNl IGRheXMuIEkgdGhpbmsgaXQgaXMgbW9yZSBpbnRlcmVzdGluZyB0bw0KPiAgICB0cmFjayB0aGUg YmFuZHdpZHRoIHRoYXQgdGhlIGF0dGFja2VyIHZzLiB2aWN0aW1zIGhhdmUNCj4gICAgdG8gdXNl Lg0KPiANCj4gLSBTcGVha2luZyBvZiBiYW5kd2lkdGgsIHdoeSBub3QgYWRvcHQgYSBwYWNrZXQg Y291bnQNCj4gICAgbGlmZXRpbWUgaW5zdGVhZCBvZiBhIHRpbWUgYmFzZWQgbGlmZXRpbWU/IFRo cmVlDQo+ICAgIHNlY29uZHMgY2FuIGJlIHZlcnkgbGl0dGxlIG9uIGEgR1BSUyBsaW5rIGFuZCBx dWl0ZSBhDQo+ICAgIGxvdCBvbiBhIGZpYmVyLi4uDQoNClRoaXMgaXMgYW4gZXhjZWxsZW50IG9i c2VydmF0aW9uLiBIb3dldmVyLCBjb3VudGluZyBieXRlcyBpbiByYXRoZXIgdGhhbiBwYWNrZXRz IHdvdWxkIGJlIG1vcmUgYWNjdXJhdGUuIFRoZSBDTiBjb3VsZCBkZXRlcm1pbmUgYSBjZXJ0YWlu IGRhdGEgdm9sdW1lLCBzYXkgRCwgcHJpb3IgdG8gdGhlIE1OJ3MgaGFuZG92ZXIuIChJIHNrZXRj aCBhIHdheSBvZiBkb2luZyB0aGlzIGJlbG93LikgV2hlbiB0aGUgQ04gcmVjZWl2ZWQgYW4gRWFy bHkgQmluZGluZyBVcGRhdGUgKEVCVSkgbWVzc2FnZSBmcm9tIHRoZSBNTiwgaXQgd291bGQgc2Vu ZCBzdWJzZXF1ZW50IHBhY2tldHMgdG8gdGhlIE1OJ3MgbmV3IGNhcmUtb2YgYWRkcmVzcyBhcyBs b25nIGFzIHRoZXNlIHBhY2tldHMsIHRha2VuIHRvZ2V0aGVyLCBkaWQgbm90IGV4Y2VlZCBEIGJ5 dGVzIGluIHNpemUuIE9uY2UgdGhlIHRocmVzaG9sZCBEIHdhcyBwYXNzZWQsIHRoZSBDTiB3b3Vs ZCBzd2l0Y2ggdG8gdGhlIE1OJ3MgaG9tZSBhZGRyZXNzICh3aGljaCBpcyBvaywgYmVjYXVzZSB0 aGUgaG9tZSBhZGRyZXNzIGhhZCBhbHJlYWR5IGJlZW4gdmVyaWZpZWQgYnkgYSBob21lLWFkZHJl c3MgdGVzdCBhdCB0aGF0IHRpbWUpLg0KDQpOb3csIGhvdyBjYW4gdGhlIENOIGRldGVybWluZSB0 aGUgZGF0YSB2b2x1bWUgRD8gT25lIHdheSBvZiBkb2luZyB0aGlzIGlzIGFkZGluZyB1cCB0aGUg c2l6ZXMgb2YgZGF0YSBwYWNrZXRzLCB3aGljaCB0aGUgQ04gc2VudCB0byBhbiBlYXJsaWVyIGNh cmUtb2YgYWRkcmVzcyBvZiB0aGUgTU4gYWZ0ZXIgaGF2aW5nIHJlY2VpdmVkIGEgc3RhbmRhcmQg QmluZGluZyBVcGRhdGUgbWVzc2FnZSBmb3IgdGhlIGNhcmUtb2YgYWRkcmVzcy4gTm90ZSB0aGF0 IHJlY2VwdGlvbiBvZiBhIChwcm9wZXJseSBhdXRoZW50aWNhdGVkKSBzdGFuZGFyZCBCaW5kaW5n IFVwZGF0ZSBpbXBsaWVzIHRoYXQgYSBzdWNjZXNzZnVsIGNhcmUtb2YtYWRkcmVzcyB0ZXN0IGhh cyBiZWVuIGRvbmUgZm9yIHRoZSBwYXJ0aWN1bGFyIGNhcmUtb2YgYWRkcmVzcy4gQXMgYW4gYWNj dW11bGF0aXZlIHN1bSwgRCBzaG91bGQgcHJvYmFibHkgYmUgbGltaXRlZCBieSBhIGNvbnN0YW50 IHVwcGVyIGJvdW5kLCBvciBpdCBzaG91bGQgYmUgZXhwb25lbnRpYWxseSByZWR1Y2VkIG92ZXIg dGltZS4gRXhwb25lbnRpYWxseSByZWR1Y2luZyBEIHdvdWxkIGhhdmUgdGhlIGFkdmFudGFnZSB0 aGF0IHRoZSBkYXRhIHZvbHVtZSBEIGlzIGtlcHQgZnJlc2guIEFkbWl0dGVkbHksIGl0IHdvdWxk IGltcGx5IGEgaGlnaGVyIG92ZXJoZWFkIGF0IHRoZSBDTidzIHNpZGUuDQoNCj4gLSBEaWQgeW91 IHNwZWNpZnkgc29tZXdoZXJlIHdoYXQgaGFwcGVucyBpZiB0aGUNCj4gICAgQ04gZG9lcyBub3Qg c3VwcG9ydCB5b3VyIHNjaGVtZT8gRG9lcyB0aGUgTU4gaGF2ZQ0KPiAgICB0byByZXNlbmQgdGhl IG9wdGltaXN0aWNhbGx5IGRlbGl2ZXJlZCBwYWNrZXRzPw0KPiAgICBEbyB5b3UgaGF2ZSBzaW11 bGF0aW9uIHJlc3VsdHMgb24gd2hhdCB0aGF0IG1lYW5zDQo+ICAgIGZvciBwZXJmb3JtYW5jZT8N Cg0KT3VyIGN1cnJlbnQgYXNzdW1wdGlvbiBpcyB0aGF0IHRoZSBNTiBzaG91bGQgc2V0IHRoZSBB LWZsYWcgaW4gdGhlIEVhcmx5IEJpbmRpbmcgVXBkYXRlIChFQlUpIG1lc3NhZ2UgYWZ0ZXIgdGhl IHZlcnkgZmlyc3QgaGFuZG92ZXIuIFRoZSBBLWZsYWcgd291bGQgc29saWNpdCBhbiBFYXJseSBC aW5kaW5nIEFja25vd2xlZGdlbWVudCAoRUJBKSBtZXNzYWdlIGZyb20gdGhlIENOLCBpZiB0aGUg Q04gc3VwcG9ydHMgRUJVcy4gVGhlIE1OIHNob3VsZCB3YWl0IGZvciBhIHJldHVybmluZyBFQkEg bWVzc2FnZSBiZWZvcmUgc2VuZGluZyBkYXRhIHRvIHRoZSBDTiBmcm9tIHRoZSBuZXcgY2FyZS1v ZiBhZGRyZXNzLiANCg0KVGhpcyB3YXksIHRoZSBNTiB3b3VsZCBsZWFybiB3aGV0aGVyIG9yIG5v dCB0aGUgQ04gc3VwcG9ydHMgRUJVcyBvciBub3QgYmVjYXVzZS4uLg0KDQooMSkgLi4udGhlIENO IHJldHVybnMgYW4gRUJBIG1lc3NhZ2UgaWYgaXQgYWNjZXB0cyB0aGUgRUJVIG1lc3NhZ2UuDQoo MikgLi4udGhlIENOIHJldHVybnMgYSBCaW5kaW5nIEVycm9yIG1lc3NhZ2Ugd2l0aCBTdGF0dXMg Y29kZSAyICgiVW5yZWNvZ25pemVkIE1IIFR5cGUgdmFsdWUiKSBpZiBpdCBkb2VzIG5vdCBhY2Nl cHQgdGhlIEVCVSBtZXNzYWdlLiBPZiBjb3Vyc2UsIGZvciB0aGlzIHRvIGJlIHRydWUsIHRoZSBF QlUgbWVzc2FnZSBtdXN0IGhhdmUgYSBNSCBUeXBlIGRpZmZlcmVudCBmcm9tIHRoZSBNSCBUeXBl IG9mIHRoZSBzdGFuZGFyZCBCaW5kaW5nIFVwZGF0ZSBtZXNzYWdlLiAoU2VlIHNlY3Rpb24gOS4y IG9mIFsxXS4pDQoNCkNvbnNlcXVlbnRseSwgaWYgdGhlIE1OIG5laXRoZXIgcmVjZWl2ZXMgYW4g RUJBIG1lc3NhZ2Ugbm9yIGEgQmluZGluZyBFcnJvciBtZXNzYWdlLCB0aGUgTU4ga25vd3MgdGhh dCBlaXRoZXIgaXRzIEVCVSBtZXNzYWdlIG9yIHRoZSByZXNwb25zZSBnb3QgbG9zdC4NCg0KQmVz dCByZWdhcmRzDQoNCg0KLSBDaHJpc3RpYW4NCg0KDQpbMV0gTW9iaWxpdHkgU3VwcG9ydCBpbiBJ UHY2LCANCiAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LW1vYmlsZWlwLWlwdjYtMjQudHh0DQpbMl0gRWFybHkgQmluZGluZyBVcGRhdGVzIGZvciBNb2Jp bGUgSVB2Ng0KICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXZv Z3QtbWlwNi1lYXJseS1iaW5kaW5nLXVwZGF0ZXMtMDAudHh0DQoNCg0KfA0KfCBDaHJpc3RpYW4g Vm9ndA0KfCBJbnN0aXR1dGUgb2YgVGVsZW1hdGljcywgVW5pdmVyc2l0eSBvZiBLYXJsc3J1aGUg KFRIKQ0KfCB3d3cudG0udWthLmRlL35jaHZvZ3QvDQp8DQoNCg0KSmFyaSBBcmtrbyB3cm90ZToN Cj4gQWZ0ZXIgYSBxdWljayByZWFkLCB0aGlzIGRyYWZ0IGxvb2tzIGludGVyZXN0aW5nLiBRdWl0 ZQ0KPiBwcm9taXNpbmcsIGFjdHVhbGx5Lg0KPiANCj4gQSBjb3VwbGUgb2YgY29tbWVudHM6DQo+ IA0KPiAtIFRIZSBiYXNlIGRyYWZ0IGFscmVhZHkgYWxsb3dzIGNhY2hpbmcgYW5kIHJlLXVzZSBv ZiBob21lDQo+ICAgIGtleWdlbiB0b2tlbnMuIChPciBtYXliZSBJIGp1c3QgdGhvdWdodCBpdCBk b2VzPyBBbnl3YXksDQo+ICAgIGl0IGRvZXMgbm90IG1hdHRlciBlaXRoZXIgd2F5LCBpdHMgZ29v ZCB0aGF0IHlvdSBkcmFmdA0KPiAgICBleHBsYWlucyBob3cgdG8gZG8gaXQganVzdCBiZWZvcmUg bW92ZW1lbnQuKQ0KPiANCj4gLSBZb3VyIGFyZ3VtZW50IHRoYXQgdGhlIGF0dGFja2VyIGhhcyB0 byBrZWVwIGEgbG90IG9mDQo+ICAgIHN0YXRlIGlmIG11bHRpcGxlIENOcyBhcmUgdXNlZC4gSG1t Li4uLiBJIG1lbW9yeSBpcw0KPiAgICBjaGVhcCB0aGVzZSBkYXlzLiBJIHRoaW5rIGl0IGlzIG1v cmUgaW50ZXJlc3RpbmcgdG8NCj4gICAgdHJhY2sgdGhlIGJhbmR3aWR0aCB0aGF0IHRoZSBhdHRh Y2tlciB2cy4gdmljdGltcyBoYXZlDQo+ICAgIHRvIHVzZS4NCj4gDQo+IC0gU3BlYWtpbmcgb2Yg YmFuZHdpZHRoLCB3aHkgbm90IGFkb3B0IGEgcGFja2V0IGNvdW50DQo+ICAgIGxpZmV0aW1lIGlu c3RlYWQgb2YgYSB0aW1lIGJhc2VkIGxpZmV0aW1lPyBUaHJlZQ0KPiAgICBzZWNvbmRzIGNhbiBi ZSB2ZXJ5IGxpdHRsZSBvbiBhIEdQUlMgbGluayBhbmQgcXVpdGUgYQ0KPiAgICBsb3Qgb24gYSBm aWJlci4uLg0KPiANCj4gLSBEaWQgeW91IHNwZWNpZnkgc29tZXdoZXJlIHdoYXQgaGFwcGVucyBp ZiB0aGUNCj4gICAgQ04gZG9lcyBub3Qgc3VwcG9ydCB5b3VyIHNjaGVtZT8gRG9lcyB0aGUgTU4g aGF2ZQ0KPiAgICB0byByZXNlbmQgdGhlIG9wdGltaXN0aWNhbGx5IGRlbGl2ZXJlZCBwYWNrZXRz Pw0KPiAgICBEbyB5b3UgaGF2ZSBzaW11bGF0aW9uIHJlc3VsdHMgb24gd2hhdCB0aGF0IG1lYW5z DQo+ICAgIGZvciBwZXJmb3JtYW5jZT8NCj4gDQo+IC0tSmFyaQ0KDQo= _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:03:14 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23765 for ; Tue, 30 Mar 2004 18:03:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rja-0006YH-45 for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248e2h7014353 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:40:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoOZ-0003j6-Vb for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:39:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29172 for ; Thu, 4 Mar 2004 03:39:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoOX-00020i-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:39:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoMC-0001MS-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:37:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AyoLD-0001A1-01 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:36:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AyoHx-0001H2-UE for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:33:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoHw-0002bP-2Y; Thu, 04 Mar 2004 03:33:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyoHF-0002WR-Cb for mip6@optimus.ietf.org; Thu, 04 Mar 2004 03:32:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28894 for ; Thu, 4 Mar 2004 03:32:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyoHD-0000US-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:32:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyoGH-0000KO-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:31:22 -0500 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1AyoFq-0000AJ-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:30:54 -0500 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i248UF0J016476; Thu, 4 Mar 2004 00:30:15 -0800 (PST) Received: from bobo (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.7p1+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id i248UAQ19438; Thu, 4 Mar 2004 09:30:10 +0100 (MET) Date: Thu, 4 Mar 2004 00:30:15 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 To: Jari Arkko Cc: Erik Nordmark , Francis Dupont , Christian Vogt , mip6@ietf.org In-Reply-To: "Your message with ID" <4046D98A.10607@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 > Well, isn't the sending of the acks already prevented by ingress > filtering? I mean if you have ingress filtering, you might not even > be able to send the EBU to begin with, let alone spoofed ACKs. You can't send the EBU, but you can send the ACKs if you don't need the HAO to send them i.e. if the attacker is "at home". This seems a bit assymetric; when the MN is sending while away from home the CoA/HoA need to match the binding cache entry at the CN. But when sending while at home there is no check that there isn't a binding cache entry at the CN. > However, we are in part trying to build these things so that the > lack of ingress filtering doesn't open up the situation for many > new attacks. Remember that the victim can have ingress filtering > but the attacker not. Agreed. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:05:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24274 for ; Tue, 30 Mar 2004 18:05:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjY-0006YH-Pw for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2HGMsjb010992 for mip6-archive@odin.ietf.org; Wed, 17 Mar 2004 11:22:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3doT-0002ql-Q8 for mip6-web-archive@optimus.ietf.org; Wed, 17 Mar 2004 11:22:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16698 for ; Wed, 17 Mar 2004 11:22:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3do8-0004Z9-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 11:22:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dn2-0004MC-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 11:21:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B3dm2-0004AS-00 for mip6-web-archive@ietf.org; Wed, 17 Mar 2004 11:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dly-0002k6-P0; Wed, 17 Mar 2004 11:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B3dlf-0002i6-Ci for mip6@optimus.ietf.org; Wed, 17 Mar 2004 11:19:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16562 for ; Wed, 17 Mar 2004 11:19:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B3dle-00049C-00 for mip6@ietf.org; Wed, 17 Mar 2004 11:19:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B3dkl-000420-00 for mip6@ietf.org; Wed, 17 Mar 2004 11:18:48 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1B3dkF-0003tV-00 for mip6@ietf.org; Wed, 17 Mar 2004 11:18:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i2HGHXW01064; Wed, 17 Mar 2004 08:17:33 -0800 X-mProtect: <200403171617> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141214.americas.nokia.com (172.18.141.214, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOj5mN2; Wed, 17 Mar 2004 08:17:30 PST Message-ID: <405879A1.9000405@iprg.nokia.com> Date: Wed, 17 Mar 2004 08:15:29 -0800 From: Charlie P Organization: NOKIA User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko CC: Basavaraj.Patil@nokia.com, mip6@ietf.org Subject: Re: [Mip6] Consensus call: draft-perkins-mip6-precfgKbm-00.txt References: <697DAA22C5004B4596E033803A7CEF440342E6F7@daebe007.americas.nokia.com> <4057E677.6080204@kolumbus.fi> In-Reply-To: <4057E677.6080204@kolumbus.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Jari, I am of course amenable to adding features to the draft according to working group direction. Adding the care-of address as a feature would of course expand applicability, and I agree with the usefulness of that specification. However, I am reluctant to take up the work of doing that if the document were still not interesting to the working group. I am also, as you know, quite happy to explicitly delineate the appropriate applicability of the protocol in both cases -- namely, with and without the CoTI/CoT exchange. It is my belief that this will not present any major new specification difficulties, given that CoTI/CoT is already specified in the base document. I never expected that the draft would be published by the working group as is! Regards, Charlie P. Jari Arkko wrote: > Basavaraj.Patil@nokia.com wrote: > >> WG members, >> >> We would like to call for consensus on the following: >> >> Should I-D: draft-perkins-mip6-precfgKbm-00.txt "Preconfigured >> Binding Management Keys for Mobile IPv6" become a WG document >> and pursued on standards track? > > > Hmm... I'd like to have something resembling Charlie's > draft at least, but I wonder if we have all the options > on the table yet. Following a bit what Christian said > in his e-mail and what I also said earlier, there seems > to a bit of question marks on the scope. How about asking > this consensus question instead: > > 1. Should Charlie's draft become a WG document as-is? > (With applicability etc. statements added and some > technical issues corrected of course.) > > 2. Should Charlie's draft focus on home address tests > only, and leave care-of address tests to base or > other improvements? Note: there will be such > improvements. Some have already been discussed in the > WG. > > 3. Should Charlie's draft be combined with another > approach that helps also with care-of address tests? > > 4. Should we do nothing? > > If you'd ask this question, I'd have more trouble deciding > between options 1 through 3. Somehow I think the end result > should be that we have a very widely applicable mechanism > that is still not problematic wrt the care-of addresses; > this would seem to imply something 2 or 3 as the best option. > OTOH, you can perhaps go there as well, later, as an extension > of 1. > > Also, I have a question to the chairs. How many alternate > security mechanisms are we allowed to adopt as WG items? > If it is just one, then we should be really careful what to > choose here. Probably something else would take priority over > Charlie's draft. If more than one, then its less of an issue. > One or more than one per home/care-of test improvement? But > there might be somewhat differently applicable methods on > this too. > > (In the interest of full disclosure: I have a draft > in the works that improves home address test performance > without requiring preconfiguration.) > > --Jari > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:08:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25217 for ; Tue, 30 Mar 2004 18:08:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006Xa-1U for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i248AUae001532 for mip6-archive@odin.ietf.org; Thu, 4 Mar 2004 03:10:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aynw4-0000OQ-D3 for mip6-web-archive@optimus.ietf.org; Thu, 04 Mar 2004 03:10:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27121 for ; Thu, 4 Mar 2004 03:10:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aynvr-0003Rr-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:10:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aynuv-0003FI-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:09:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aynty-00033M-00 for mip6-web-archive@ietf.org; Thu, 04 Mar 2004 03:08:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ayntw-0008A0-7J; Thu, 04 Mar 2004 03:08:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyntP-00083J-PW for mip6@optimus.ietf.org; Thu, 04 Mar 2004 03:07:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26925 for ; Thu, 4 Mar 2004 03:07:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyntB-0002rb-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:07:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AynsK-0002c7-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:06:37 -0500 Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx with esmtp (Exim 4.12) id 1AynrD-00028f-00 for mip6@ietf.org; Thu, 04 Mar 2004 03:05:27 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id i2484st27344; Thu, 4 Mar 2004 09:04:54 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i2484sSj064874; Thu, 4 Mar 2004 09:04:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200403040804.i2484sSj064874@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Erik Nordmark , Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 In-reply-to: Your message of Thu, 04 Mar 2004 09:23:54 +0200. <4046D98A.10607@kolumbus.fi> Date: Thu, 04 Mar 2004 09:04:54 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 In your previous mail you wrote: But what we in my opinion should prevent is the amplification, not pure reflection. => this is the detail we disagree: if we prevent pure reflection, we prevent this attack and all others using the same hole but which are *reality*, not speculations. I mean if you have ingress filtering, => this is the only case which makes sense. you might not even be able to send the EBU to begin with, let alone spoofed ACKs. However, we are in part trying to build these things so that the lack of ingress filtering doesn't open up the situation for many new attacks. => it doesn't matter to get new attacks, it does matter to get no new attacks which have a definitive advantage over current attacks, e.g. which defeat ingress filtering by hiding the source address... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:08:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25254 for ; Tue, 30 Mar 2004 18:08:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjW-0006a4-Kh for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2379TWT005839 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 02:09:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQVU-0001Vk-Qu for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:09:29 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18261 for ; Wed, 3 Mar 2004 02:09:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQVR-0005vu-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:09:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQUO-0005hu-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:08:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyQT9-0005MR-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:07:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQTC-0000GO-3h; Wed, 03 Mar 2004 02:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay4O0-0007eV-AL for mip6@optimus.ietf.org; Tue, 02 Mar 2004 02:32:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22397 for ; Tue, 2 Mar 2004 02:32:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay4Nw-0005l6-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:32:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay4My-0005f1-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:31:13 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1Ay4M7-0005ZQ-00 for mip6@ietf.org; Tue, 02 Mar 2004 02:30:19 -0500 Message-ID: <4b7101c40028$3a823480$3e6015ac@dclkempt40> From: "James Kempf" To: "NJEDJOU Eric FTRD/DMR/REN" , "Gregory Daley" Cc: "Pekka Nikander" , "Stefan Aust" , , =?iso-8859-1?Q?Carmelita_G=F6rg?= , "Niko A. Fikouras" , "Cornel Pampu" , "Dna" , "Greg Daley" , References: Subject: Re: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND Date: Mon, 1 Mar 2004 23:30:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > Well these protocols (CARD, CTP, FMIP, HMIP) could not and can not be ready for deployment as they essentially assume that IPv6, then Mobile IPv6 be deployed, at least partially, as the aforementionned protocols rely on IPv6 and mobile IPv6. Mobile IPv6 products are now coming out from vendors shelves. We can avoid to wait for (CARD, CTP, FMIP, HMIP) before providing optimisation for MIPv6 handover by bringing "simple" additions to the base specification that would already provide smoother handover as a sort of "work around". Then when we would get enough feedback from MIPv6 deployment issues we would be able to rethink at the way CARD,... Could be adapted. > CARD and CTP are independent of IP version. As for FMIP, there are two versions, one for IPv4 and one for IPv6. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:08:51 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25258 for ; Tue, 30 Mar 2004 18:08:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjX-0006a4-1E for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2379Ndb005567 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 02:09:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQVO-0001RO-Jh for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:09:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18133 for ; Wed, 3 Mar 2004 02:09:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQVL-0005v7-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:09:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQUJ-0005fc-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:08:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyQT7-0005Ku-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQT9-0000DZ-Dk; Wed, 03 Mar 2004 02:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxxPF-00035T-SY for mip6@optimus.ietf.org; Mon, 01 Mar 2004 19:05:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14077 for ; Mon, 1 Mar 2004 19:05:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxxPC-0004NQ-00 for mip6@ietf.org; Mon, 01 Mar 2004 19:05:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxxOL-0004H5-00 for mip6@ietf.org; Mon, 01 Mar 2004 19:04:10 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AxxNR-0004AH-00 for mip6@ietf.org; Mon, 01 Mar 2004 19:03:13 -0500 Message-ID: <058f01c3ffe9$c79eecd0$3e6015ac@dclkempt40> From: "James Kempf" To: "Gregory Daley" , "NJEDJOU Eric FTRD/DMR/REN" Cc: "Pekka Nikander" , "Stefan Aust" , , =?iso-8859-1?Q?Carmelita_G=F6rg?= , "Niko A. Fikouras" , "Cornel Pampu" , "Dna" , "Greg Daley" , References: <5a6a8a5a671e.5a671e5a6a8a@mail1.monash.edu.au> Subject: Re: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND Date: Mon, 1 Mar 2004 16:02:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=no version=2.60 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable I hesitate to even bring this up, but there's a long history in the IETF = of trying to figure out where to do this kind of work. We've been working on multiple interface (vertical) handover, handover optimization, and such i= n MIP and Seamoby for over three years. There are some experimental protoco= ls (CARD, CTP, FMIP, HMIP) approaching publication, but they still need a lo= t of work before they are ready for deployment. The effort has been hampere= d by a lack of impending product or deployment pressure. IETF does not function well when a particular technology does not have a group of vendo= rs and network operators behind it who need interoperability for their produ= ct or deployment, and that has been the case for this particular technology. The result is that the work has been moved to the IRTF MOBOPTS research group, and I would advise that any proposals be taken there. jak ----- Original Message -----=20 From: "Gregory Daley" To: "NJEDJOU Eric FTRD/DMR/REN" Cc: "Pekka Nikander" ; "Stefan Aust" ; ; "Carmelita G=F6= rg" ; "Niko A. Fikouras" ; "Cornel Pampu" ; "Dna" ; "Greg Daley" ; Sent: Monday, March 01, 2004 7:19 AM Subject: [Mip6] Re: RE : [DNA] Current IETF-Draft version - POLIMAND > Hi, > > I know that this has been cross posted, so I'll > respond to both lists, but perhaps we can talk about > specific issues in the individual mailing lists > subsequently. I'd suggest DNA, unless the MIP6 > chairs wish to respond. > > If we need to discuss needs more generally for > multiple interface configuration procedures or > vertical handoff, it may be useful to take it up > with the chairs of either or both WGs (depending > on the circumstances). > > Please see my take below. > ----- Original Message ----- > From: NJEDJOU Eric FTRD/DMR/REN > Date: Monday, March 1, 2004 9:51 pm > Subject: RE : [DNA] Current IETF-Draft version - POLIMAND > > > Pekka, > > The problem with MIP6 movement detection handover optimizations > > (see http://www.ietf.ord/I-D/draft-daniel-mip6-optimized-vertical- > > handover-00.txt for another draft) is that it is being considered > > out of scope for DNA because of the mobile IPv6 issue raised and > > out of scope for MIP6 because of the link triggers that has to be > > taken into account. Actually, it is within the scope of both as > > I'd guess while this is frustrating, it's largely a statement > of fact. > > Please inform me of any incorrect statements I make, since > there may be subtlties I miss in the drafts. > > While the drafts being discussed are principally interested in > handling multiple connectivity scenarios associated with > wireless networks, neither MIPv6 (regarding Link hints) or > DNA (Discussing global signalling) are currently chartered to > work on these topics. > > It is indeed possible that the combination of the techniques > is seen as the stumbling block by both groups. > > For example, if indeed it is necessary to provide vertical > handover support for MIPv6, is it strictly necessary to talk > about link layer interactions (polimand may talk about policy instead, > Of course, it is always hard to standardize policy). > > Whether a document looking at multiple interface connectivity > for MIPv6 would be useful or not (or whether there's much difference > except the movement detection algorithm) I don't know. > > Particularly for DNA, we can't really discuss handovers, > considering that this term principally refers to session > restoration or continuation using mobility protocols. > > DNA is looking basically at signalling using mechanisms > within the local link only. Any reference to other > protocols (except in a confined way) can make documents > look like they're (for example) MIP specific. > > If there's a difference in the configuration detection > procedures when a host has multiple interfaces, that may be > different. > > For example, a host may wish to wait passively for router > advertisements on the GPRS interface (testing reachability > when the host switches connections to that interface), and > probes fairly aggressively on a WLAN interface. > > Any decision or action based on this the configuration detection > is starting to push into uncomfortable areas as far as DNA's tight > charter is concerned. Perhaps this is analogous to the reasoning > used in MIP6? > > > DNA -link triggers/hints that will be catalogued/standardized > > within DNA will also be used for Mobile IPv6 optimised movement > > detection. Other ones may be needed for this specific purpose. > > Better detecting network attchment/detachment is a requirement for > > Mobile IPv6 better performance movement detection and handover. > > These issues are therefore strongly linked. > > I think we have to be particularly careful about the word > standardized in the previous paragraph. > There's already been some out-of-band feedback to DNA that we > should avoid delving into standardization of L2 oriented > mechanisms. > > > MIP6 -Optimized movement detection an handover schemes are > > essenttial for base Mobile IPv6 Operation, which means, the > > protocol operation needs exploiting L2 triggers/hints. And MIPv6 > > implementors use L2 triggers/hints in a confusing way, if not at all. > > While the usage of hints may be unavoidable in some DNA schemes, > there will still be some systems where it is not possible to > the the kind of hints you desire. It would be short-sighted to > design systems which only work if information from the link-layer > is reliable and available. > > > We could be ping-ponging betwwen these two groups for years. > > I really hope not, but MOBOPTS isn't necessarily a place for > killing ideas off to (no matter what some people say!). > Our research team has (voluntarily!) submitted some ideas there > for further discussion recently and gotten useful feedback. > > I don't even mind if people winnow their existing work down to > a problem statement which is DNA centric. > It may be that there's a chance that we'd think it out-of-scope > anyway, but that's because the WG scope is very narrow. > > If the work is clear input into one of the documents on the DNA > charter, that may change things. > > We're only likely to produce 4 documents this year (optimistically). > so focussing on how the vertical handover/polimand work can > directly help those is more immediately useful. > > As Pekka said, this may mean leaving MIPv6 specific parts to > MIP6WG or MOBOPTS. > > Greg > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:11:22 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25912 for ; Tue, 30 Mar 2004 18:11:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjV-0006a4-Vt for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2379XA3006077 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 02:09:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQVZ-0001Zk-3e for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:09:33 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18349 for ; Wed, 3 Mar 2004 02:09:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQVV-0005wW-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:09:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQUQ-0005iE-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:08:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyQTB-0005Nv-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:07:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQTD-0000Hh-QJ; Wed, 03 Mar 2004 02:07:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyBG4-0004rw-Bc for mip6@optimus.ietf.org; Tue, 02 Mar 2004 09:52:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12141 for ; Tue, 2 Mar 2004 09:52:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyBG2-00019b-00 for mip6@ietf.org; Tue, 02 Mar 2004 09:52:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyBF8-000124-00 for mip6@ietf.org; Tue, 02 Mar 2004 09:51:35 -0500 Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81]) by ietf-mx with esmtp (Exim 4.12) id 1AyBEH-0000vf-00 for mip6@ietf.org; Tue, 02 Mar 2004 09:50:42 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtp (Exim 3.30 #10 (Debian)) id 1AyBEE-0000dV-00; Tue, 02 Mar 2004 15:50:38 +0100 Received: from atiswww by irams1.ira.uka.de with local (Exim 3.30 #7 ) id 1AyBEE-000323-00; Tue, 02 Mar 2004 15:50:38 +0100 Received: from 210.93.162.110 ([210.93.162.110]) by mailhost.ira.uka.de (IMP) with HTTP for ; Tue, 2 Mar 2004 15:50:37 +0100 Message-ID: <1078239037.40449f3e038cc@mailhost.ira.uka.de> Date: Tue, 2 Mar 2004 15:50:38 +0100 From: Christian Vogt To: Jari Arkko Cc: mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 210.93.162.110 Content-Transfer-Encoding: 8bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi Jari! > I already sent some comments earlier, but I reread this draft > prior to the meeting. Here are some additional comments. Overall > I find your draft quite promising. There's probably a need to > change the approach to byte counts rather than fixed time > limits, as dicussed earlier. You are referring to the following question: How can a correspondent node (CN) know how much data it may sent to a "good" mobile node's (MN's) new care-of address (CoA), while that CoA is being verified by a concurrent CoA test, without allowing a malicious node to misuse the concurrent CoA test for a flooding attack. And yes, the 3-seconds time limit on the concurrent CoA test, which we proposed in version -00 of the [2], does not solve the problem for two reasons. The first reason is the one you mentioned in an earlier email: The amount of data a CN may send within three seconds can be arbitrarily high. It is only limited by the pipe between the CN and the target IP address. A second reason is that a 3-seconds time limit alone does not prevent a malicious node from continually refreshing a tentative CoA registration. It might seem to be an obvious approach to replace the 3-seconds time limit by a constant byte (or packet) limit. A constant byte limit would bound the data volume that a CN may send to a yet-to-be-verified CoA. But a constant byte limit has a similar shortfall than the constant time time limit proposed in [2], namely: Whatever limit is chosen, it might still allow for a flooding attack against a node at a narrow link. This observation led us to the idea of balancing the data volume that a CN can send to an "unconfirmed" CoA of a MN with the data volume that the CN has earlier sent to a "confirmed" CoA of the same MN. With "unconfirmed" CoA I mean a CoA for which a concurrent CoA test is still ongoing. With "confirmed" CoA I mean a CoA for which the CN has obtained assurance, through a CoA test, that the MN is indeed reachable at that CoA. We called this approach "Credit-Based Authorization", meaning that a MN must collect some "credit" (in terms of data volume) before it can do a concurrent CoA test. In an email, you suggest using the data volume originated *by the MN*, and sent to the CN, as the counter-balance to what the CN may sent to a yet-to-be-verified CoA of the MN. Yes, this is a good idea. As discussed during our conversation after yesterday's MIP6 session, one should probably use both types of traffic, which would also allow for applications with asymmetric data flows. > However, if as suggested you would change the approach to > specifically take this into account, this would no longer be a > problem. Basically, a CN would agree to send out at most X bytes > of traffic while in the tentative state, where X is, say, 10 % of > the bytes sent by the MN during the last few minutes. This would > result in the attacker (mobile node) having to send at least 100 > bytes to get just 10 bytes to the attacker, clearly less than the > 1-1 reflection simply using TCP SYNs. Still, the 10% is more than > enough to transfer the data needed until the care-of test answer > arrives: if you have a constant data rate, 10% of data sent during > three minutes gives you 18 s to complete the care-of address test. > > If you exceed X, you move the stream back to the home address. We are currently working on version -01 of [2] in which we specify Credit-Based Authorization, but we did not finish the new version in time for this IETF meeting. I do have a slide on Credit-Based Authorization, which I will show during my presentation of Early Binding Updates at the MOBOPTS session on Wednesday afternoon, provided there is sufficient time. (It is only a 10-minutes presentation.) > If this draft goes further, it might make sense to separate > the home address and care-of address optimizations. That is, > you could have one draft that explains how the home address > tests can be initiated before handover takes place. Or would > this be considered too simple for a draft?... I don't know. One argument that might be against separating Early Binding Update I-D is that, in Mobile IPv6, a MN may already do a home-address (HoA) test whenever it whishes. Though the MIPv6 specification suggest to do the HoA test after a handover, a MN may also do it before the handover without violating the protocol specification. In fact, a HoA test can be done at any time as long as the Home Keygen Token retrieved from it is not expired when eventually used for Binding Update message authentication. Nonetheless, I think that splitting the I-D is an excellent idea, because both the early HoA test as well as the concurrent CoA test require additional commentary. As far as the HoA test goes, I may just cite your previous email: > Perhaps the separate draft that I suggested makes sense, because > you would also have to describe the exception that you talk about > in the above [...] ...namely having the MN do a HoA test even when it is at home. As far as the CoA test goes, there is this credit-based authorization method which will be specified in version -01 of [2]. Certainly, splitting the I-D into two separate I-Ds would make both of them easier to read. > Maybe the byte count scheme could be called the "Adaptive > Amplification Attack Prevention" (AAAP) or "Attack Cost > War for Amplification" (ACWA). We called it "Credit-Based Authorization" for now. It does not sound too spectacular, I admit. "Counter-Balance-Based Egress Monitoring could be another alternative. > Hmm... I wonder if this has been described anywhere else. > Seems like a rather general scheme. But maybe not, as it > only makes sense in movements. Write a paper somewhere on this, > interested? Credit-Based Authorization is definitely an important topic per se and needs dedicated consideration. And yes, we intend to elaborate further on this topic. Writing a paper is an excellent idea! The following comments are not related to Credit-Based Authorization. > Maybe with some simulation data should be included, and rules > to tell when it makes sense: delay at movement vs. potentially > unnecessary messaging if we didn't move after all. You are right. Simulation analyses are still on our to-do list. > Presumably you could do an EBU as soon as you receive the Home Test > message. I think this would simplify your state machine. I agree. This is true. When writing this I-D, we thought from an implementor's perspective: An Early-Binding-Update-enabled MN would probably implement standard binding updates as well, and that code could just be re-used here. But, you are right: The state machine gets simpler if Early Binding Updates are used in all situations. Jari, I appreciate your detailed comments on Early Binding Updates. Best regards, - Christian [1] http://www.arkko.com/publications/draft-aura-mipv6-bu-attacks-01.txt [2] http://www.ietf.org/internet-drafts/draft-vogt-mip6-early-binding-updates-00.txt | | Christian Vogt | Institute of Telematics, University of Karlsruhe (TH) | www.tm.uni-karlsruhe.de/~chvogt/ | Quoting Jari Arkko : > I already sent some comments earlier, but I reread this draft > prior to the meeting. Here are some additional comments. Overall > I find your draft quite promising. There's probably a need to > change the approach to byte counts rather than fixed time > limits, as dicussed earlier. > > > We propose a modified binding-update procedure that > > evades the latency of both address tests. > > If this draft goes further, it might make sense to separate > the home address and care-of address optimizations. That is, > you could have one draft that explains how the home address > tests can be initiated before handover takes place. Or would > this be considered too simple for a draft?... I don't know. > Maybe with some simulation data should be included, and rules > to tell when it makes sense: delay at movement vs. potentially > unnecessary messaging if we didn't move after all. Anyway, > this part of the optimization would work well with any other > optimization scheme as well, not just the care-of-test-less > early binding updates. Or without any other optimization. > > > before changing its point of network attachment. At home, the > > mobile node does not use Mobile IPv6. It hence does not run a > > home-address test, and it does not acquire a Home Keygen > > Token, before it moves to a foreign link. Also, when the > > mobile node powers on at a foreign > > I don't see a reason why the predictive home test strategy > wouldn't work even in this case. In either case, you have to have > some ability to "guess" that you will be moving soon, or otherwise > you'll just be doing some extra signaling. > > > One may consider letting the mobile node perform a home-address > > test even while being at home. This could accelerate handovers > > from the home link to a foreign link. The Home Test Init and > > Home Test messages would continue to obey to the rules defined > > in sections 9.4 and 11.6 of [1], except that they would not have > > to be tunneled between the mobile node and its home agent. > > This is true. But if you are going to adopt predictive home tests, > I would apply them even to the home case. > > Perhaps the separate draft that I suggested makes sense, because > you would also have to describe the exception that you talk about > in the above. > > > These observations lead to the following exception: When a mobile > > node wants to register a new care-of address with a correspondent > > node, and the mobile node does not yet know a valid Home Keygen > > Token, the mobile node runs a standard binding update instead of > > an Early Binding Update. When the standard binding update is > > complete, the mobile node can communicate through its new care-of > > address. The > > Presumably you could do an EBU as soon as you receive the Home > Test message. I think this would simplify your state machine. > > > test. We claim that testing the mobile node's reachability at > > its new care-of address may also be done at (3). Data trans- > > mission to and from the new care-of address may wait or, as > > with Early Binding Updates, start with appropriate restrictions > > until the mobile node has provided proof to the correspondent > > node that it is reachable at its new care-of address. > > This is the issue we discussed earlier. As has been stated by > Francis and others, in the Internet we already (unfortunately, > since ingress filtering is not ubiquitous) have the possibility > to spoof source addresses, leading to 1-1 reflection attacks on > e.g. TCP SYN packets. So 1-1 reflection is not necessarily > something we need to prevent in Mobile IPv6. Base RR attempts, > however, to prevent 1-N reflection attacks where you send one > (or some) packets and get many more packets to the victim's > network. The basic scenario is tricking someone into opening a > stream, and moving the stream towards the victim and letting > the "someone" pump data towards the victim for a while. > > Your -00 draft with the 3 second time limit still has this issue, > as a CN which supports EBUs could pump 3 seconds of data stream > to the victim. How serious is this? It depends on the interface > speed and effort needed to open the particular stream. Lets say > 10 packets to open the stream and get over the slow start (maybe > someone can help me with the actual numbers...). If the CN is a > mobile on a congested GPRS link, there may not be many packets > sent during the 3 seconds. But if the CN is an idle web server on > an OC-3 link there could be a lot of packets, particularly since > the attacker can send some spoofed TCP ACKs, having learned the > sequence numbers while opening the stream. > > However, if as suggested you would change the approach to > specifically take this into account, this would no longer be a > problem. Basically, a CN would agree to send out at most X bytes > of traffic while in the tentative state, where X is, say, 10 % of > the bytes sent by the MN during the last few minutes. This would > result in the attacker (mobile node) having to send at least 100 > bytes to get just 10 bytes to the attacker, clearly less than the > 1-1 reflection simply using TCP SYNs. Still, the 10% is more than > enough to transfer the data needed until the care-of test answer > arrives: if you have a constant data rate, 10% of data sent during > three minutes gives you 18 s to complete the care-of address test. > > If you exceed X, you move the stream back to the home address. > > The drawback of this scheme is that on the first binding you may > be unable to do this, even if you had ongoing data transfer with > the mobile while it was at home. This is because the IP stack would > not be counting the received bytes. > The Home Keygen Token and > > > the Care-of Keygen Token are likely to arrive at the mobile node > > via disjoint paths: The former passes through the mobile node's > > home agent, the latter does not. An attacker will thus have a > > hard time to capture both tokens. > > Strictly speaking, this is not the main worry. As documented in [1], > the attacker is free to choose the care-of path. So I would worry > more about attackers posing as mobile nodes and doing the RR test > than attackers being able to eavesdrop on an RR test performed > by a legitimate node. In order to pose as a mobile node, you need > to be on the path to the home agent, and your draft does not change > that so I think you are ok. (Also, if you are on the path to the > home agent you can do all sorts of other nasty stuff.) > > (You say all this later in the text, but I just wanted to say > that two paths are not a protection in RR, your method, or other > methods.) > > > Another way to mitigate the threat of flooding attacks is to > > grant Early Binding Updates to trusted nodes only. Recall that > > the > > I wouldn't put too much emphasis on this. However, if we had some > stronger home test mechanisms (e.g. CGA), you could combine EBUs > with them, getting more security. > > --Jari ------------------------------------------------------------- This message was sent through ATIS: http://atiswww.ira.uka.de _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:17:57 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27868 for ; Tue, 30 Mar 2004 18:17:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006ZK-Gs for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K77MdK021142 for mip6-archive@odin.ietf.org; Fri, 20 Feb 2004 02:07:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4ko-0005Tk-Gy for mip6-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 02:07:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00584 for ; Fri, 20 Feb 2004 02:07:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au4kk-0003Pd-00 for mip6-web-archive@ietf.org; Fri, 20 Feb 2004 02:07:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au4j1-00034R-00 for mip6-web-archive@ietf.org; Fri, 20 Feb 2004 02:05:29 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Au4gd-0002jX-02 for mip6-web-archive@ietf.org; Fri, 20 Feb 2004 02:02:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Au4RK-0000mR-ME for mip6-web-archive@ietf.org; Fri, 20 Feb 2004 01:47:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au4RI-0001GE-6P; Fri, 20 Feb 2004 01:47:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atj2U-0000NB-8v for mip6@optimus.ietf.org; Thu, 19 Feb 2004 02:56:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04534 for ; Thu, 19 Feb 2004 02:56:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atj2Q-00034n-00 for mip6@ietf.org; Thu, 19 Feb 2004 02:56:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atj1Y-00030z-00 for mip6@ietf.org; Thu, 19 Feb 2004 02:55:09 -0500 Received: from myra.general.services.metu.edu.tr ([144.122.144.147]) by ietf-mx with esmtp (Exim 4.12) id 1Atj0p-0002vj-00; Thu, 19 Feb 2004 02:54:24 -0500 Received: from metu.edu.tr (ee-167-166.eee.metu.edu.tr [144.122.167.166]) by myra.general.services.metu.edu.tr (8.11.7/8.11.7) with ESMTP id i1J7s6B27207; Thu, 19 Feb 2004 09:54:06 +0200 (EET) Message-ID: <40346B9A.3070004@metu.edu.tr> Date: Thu, 19 Feb 2004 09:54:02 +0200 From: Buyurman Baykal User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] Med-Hoc-Net 2004 Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=1.1 required=5.0 tests=MAILTO_TO_SPAM_ADDR autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit We apologize if you receive multiple copies of this message ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Med-Hoc-Net 2004 ================ The Third Annual Mediterranean Ad Hoc Networking Workshop June 27-30, 2004, Bodrum, Turkey http://www.medhoc04.diit.unict.it/ **Deadline approaching** Full Paper Electronic Submission: March 2, 2004 Call for Papers --------------- Ad hoc network applications are emerging continuously imposing their own stringent constraints which cannot be fulfilled by generic approaches and thus spur new research efforts. The aim of Med-Hoc-Net 2004 is to serve as a platform for researchers and visionaries from academia, research labs, and industry from all over the globe to share their ideas, views, results, and experiences in the field of ad-hoc networking and communications. Med-Hoc-Net 2004 will include presentations of theoretical and experimental achievements, innovative ad-hoc systems, prototyping efforts, case studies, and advancements in technology directly affecting ad-hoc networking and communications infrastructures. After Sardinia (Italy) and Mahdia (Tunisia), this year the workshop will take place in another beautiful spot on the Mediterranean Sea: Bodrum (Turkey) where you will find wonderful nature and amazing historical sites close to hand. Bodrum is easy to reach via frequent flight connections from Istanbul. Topics of Interest: ------------------- The papers solicited in Med-Hoc-Net 2004 cover a variety of topics including but not limited to: - Novel ad-hoc network architectures and applications, - Sensor network applications and protocols, - Implementations, testbeds, and prototypes, - Interfacing ad-hoc systems with different networks, - Resource discovery and management, - Power management and control, - Call admission and traffic shaping policies for ad-hoc networks, - Multimedia location services, - Self organization and network reconfiguration, - Protocols for QoS support in ad-hoc networks, - QoS support in Bluetooth, HIPERLAN, IEEE 802.11 etc., - MAC protocols, scheduling, and radio resource sharing in ad hoc networks, - Unicast and multicast routing algorithms and protocols, - Transport layer protocols for multi-hop networks, - Congestion control, - Performance evaluation of ad-hoc network protocols through simulations, analysis, and measurements, - Security in ad-hoc networks, - Fault tolerance and error recovery - Signal processing algorithms (coding, compression) for ad-hoc networks The program committee will referee all papers, and accepted papers will be published in the conference proceedings. PAPERS OF PARTICULAR MERIT WILL BE PUBLISHED IN AD HOC NETWORKS (ELSEVIER) JOURNAL. Submission and Important Dates: ------------------------------- Manuscripts must be formatted according to the IEEE double-column standard format, except the font size, which must be 11pt. Authors should use only standard fonts, i.e., Times Roman, Courier, Symbol, and Helvetica, or their equivalent. The maximum length of the manuscript is 12 pages. Papers should be submitted in pdf or ps format via email to medhoc04@diit.unict.it according to the following timetable: Full Paper Electronic Submission: March 2, 2004 Tutorial proposal deadline: April 15, 2004 Notification of Acceptance/Rejection: May 3, 2004 Camera ready submission of full papers: May 17, 2004 Tutorial date: June 27, 2004 Conference dates: June 28-30, 2004 Tutorials: ---------- Proposals for tutorials are solicited. Tutorials should address key topics on Wireless Ad-Hoc Networks and Mobile Communications, dealing with both experimental and theoretical research advances in these fields. Evaluation of proposals will be based on the expertise and experience of the instructors, and on the relevance of the subject matter for the workshop. Potential instructors are requested to submit a tutorial proposal of at most 3 pages, including a biographical sketch, to the Tutorial Chairs, Francesca Cuomo (cuomo@infocom.uniroma1.it) and Christos Douligeris (cdoulig@unipi.gr) by the tutorial proposal deadline above (April 15, 2004). Keynote Speakers: ----------------- Leonard Kleinrock (UCLA, USA), Imrich Chlamtac (UTDallas, USA). Steering Committee: ------------------- Khaldoun Al Agha (LRI, France), Mario Gerla (UCLA, USA), Farouk Kamoun (ENSI, Tunisia), Giovanni Pau (UCLA, USA), and Guy Pujolle (LIP6, France). Organization Committee: ----------------------- General Chair: Ian F. Akyildiz, Georgia Institute of Technology, USA General Vice Chair: Erdal Cayirci, Istanbul Technical University, TURKEY Technical Program Chairs: Giacomo Morabito, University of Catania, ITALY Eylem Ekici, Ohio State University, USA Tutorial Chairs: Francesca Cuomo, University of Rome - La Sapienza, ITALY Christos Douligeris, University of Piraeus, GREECE Publicity Chairs: Buyurman Baykal, Middle East Technical University, TURKEY Jaudelice Cavalcante de Oliveira, Drexel University, USA Registration Chair: Sebnem Baydere, Yeditepe University, TURKEY Technical Program Committee: ---------------------------- Khaldoun Al Agha, Laboratoire de Recherche en Informatique, FRANCE Hamid Aghvami, King's College London, UK Eitan Altman, INRIA, FRANCE Roberto Battiti, University of Trento, ITALY Raouf Boutaba, University of Waterloo, CANADA Walid Dabbous, INRIA, FRANCE Magda El Zarki, University of California at Irvine, USA Luigi Fratta, Politecnico di Milano, ITALY Mario Gerla, UCLA, USA Paul J. M. Havinga, University of Twente, NETHERLANDS Ahmed Helmy, University of Southern California, USA Farouk Kamoun, ENSI, TUNISIA Holger Karl, Technical University of Berlin, GERMANY Ulf Korner, Lund Institute of Technology, SWEDEN Bhaskar Krishnamachari, University of Southern California, USA Marwan Krunz, University of Arizona, USA Albert Levi, Sabanci University, TURKEY Janise McNair, University of Florida, USA Lazaros Merakos, University of Athens, GREECE Ioanis Nikolaidis, University of Alberta, CANADA Ariel Orda, Technion, ISRAEL Sergio Palazzo, University of Catania, ITALY Giovanni Pau, UCLA, USA Chiara Petrioli, University of Rome "La Sapienza", ITALY Andreas Pitsillides, University of Cyprus, CYPRUS Guy Pujolle, LIP6, FRANCE Paolo Santi, CNR, ITALY Adrian Segall, Technion, ISRAEL Ness Shroff, Purdue University, USA Moshe Sidi, Technion, ISRAEL Raghupathy Sivakumar, Georgia Institute of Technology, USA Ioannis Stavrakakis, University of Athens, GREECE Ivan Stojmenovic, University of Ottawa, CANADA Violet R. Syrotiuk, Arizona State University, USA Leandros Tassiulas, University of Thessaly, GREECE Damla Turgut, University of Central Florida, USA Bernhard H. Walke, Aachen University of Technology, GERMANY Wenye Wang, North Carolina State University, USA Michele Zorzi, University of Ferrara, ITALY -------------------------------------------------- For more information on the workshop, please check http://www.medhoc04.diit.unict.it/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:18:27 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28006 for ; Tue, 30 Mar 2004 18:18:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006a4-UM for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA43O6bf007735 for mip6-archive@odin.ietf.org; Mon, 3 Nov 2003 22:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrna-00020d-2S for mip6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 22:24:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11477 for ; Mon, 3 Nov 2003 22:23:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrnW-00049d-00 for mip6-web-archive@ietf.org; Mon, 03 Nov 2003 22:24:02 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AGrnW-00049a-00 for mip6-web-archive@ietf.org; Mon, 03 Nov 2003 22:24:02 -0500 Received: from [132.151.6.22] (helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AGrnY-00086f-9O for mip6-web-archive@ietf.org; Mon, 03 Nov 2003 22:24:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrnU-0001zp-BJ; Mon, 03 Nov 2003 22:24:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGrmr-0001iU-EQ for mip6@optimus.ietf.org; Mon, 03 Nov 2003 22:23:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11378 for ; Mon, 3 Nov 2003 22:23:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGrmn-00046W-00 for mip6@ietf.org; Mon, 03 Nov 2003 22:23:17 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AGrmn-00043p-00 for mip6@ietf.org; Mon, 03 Nov 2003 22:23:17 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id hA43MQu32721; Mon, 3 Nov 2003 19:22:26 -0800 X-mProtect: <200311040322> Nokia Silicon Valley Messaging Protection Received: from danira-pool05588.americas.nokia.com (10.241.55.88, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdRYrXqV; Mon, 03 Nov 2003 19:22:23 PST Message-ID: <3FA71B47.5070506@iprg.nokia.com> Date: Mon, 03 Nov 2003 19:21:43 -0800 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Soliman Hesham CC: mip6@ietf.org Subject: Re: multi-interfaced vs multi-addressed [Re: [Mip6] Draft Agenda for WG meeting at IETF58] References: <748C6D0A58C0F94CA63C198B6674697A01922E6D@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A01922E6D@ftmail.lab.flarion.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello Hesham, Soliman Hesham wrote: >Case 2: Two addresses on two different interfaces. >Now, the MN may want to put some connections on i/f 1 >and others on i/f 2, why? because i/f 1 is cheap and free >but doesn't provide QoS for instance so it's ok to put my >web browsing on that. On the other hand i/f 2 provides QoS >(for a price) so I'll only use it for real time apps. > >Today MIPv6 does not allow case 2 to take place. Of course >you could do the same with case 1 (i.e. just to be a pain >the MN wants to use two CoAs assigned to the same interface) >but there is no benefit. The benefit is clearer when there >are two interfaces. > How does Mobile IPv6 prevent case 2? If I want my applications to bind to a case 2 address/socket, why does Mobile IP get in the way? Furthermore, I dispute your claim that case 1 has no benefit. Clearly, it does when the addresses have separate DNS names. Regards, Charlie P. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:19:15 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28262 for ; Tue, 30 Mar 2004 18:19:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjR-0006a4-I4 for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i237asJ7011900 for mip6-archive@odin.ietf.org; Wed, 3 Mar 2004 02:36:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQvi-0002UX-Ba for mip6-web-archive@optimus.ietf.org; Wed, 03 Mar 2004 02:36:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07142 for ; Wed, 3 Mar 2004 02:36:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQvP-0002lP-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:36:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQuY-0002dV-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:35:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyQuD-0002V6-00 for mip6-web-archive@ietf.org; Wed, 03 Mar 2004 02:35:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQuF-0000sK-6k; Wed, 03 Mar 2004 02:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyQts-0000kv-1y for mip6@optimus.ietf.org; Wed, 03 Mar 2004 02:34:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06885 for ; Wed, 3 Mar 2004 02:34:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyQtU-0002SW-00 for mip6@ietf.org; Wed, 03 Mar 2004 02:34:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyQsZ-0002IQ-00 for mip6@ietf.org; Wed, 03 Mar 2004 02:33:20 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AyQre-00027x-00 for mip6@ietf.org; Wed, 03 Mar 2004 02:32:22 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 605376A902; Wed, 3 Mar 2004 09:32:21 +0200 (EET) Message-ID: <4045897D.1000205@kolumbus.fi> Date: Wed, 03 Mar 2004 09:30:05 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Christian Vogt , mip6@ietf.org Subject: Re: [Mip6] comments on draft-vogt-mip6-early-binding-updates-00 References: <200403030515.i235F6Sj060273@givry.rennes.enst-bretagne.fr> In-Reply-To: <200403030515.i235F6Sj060273@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL,SUBJ_HAS_UNIQ_ID autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Btw, there is some discussion about this in the mobopts list too. And then to our discussion, inline: > It might seem to be an obvious approach to replace the 3-seconds time > limit by a constant byte (or packet) limit. A constant byte limit would > bound the data volume that a CN may send to a yet-to-be-verified > CoA. But a constant byte limit has a similar shortfall than the > constant time time limit proposed in [2], namely: Whatever limit is > chosen, it might still allow for a flooding attack against a node at a > narrow link. > > => I agree: as the line speed can be between some kbits/s to a hundred > Mbits/s (wireless) or some Gbits/s (wired) you either kill performance > or victims behind a narrow link. Right. > This observation led us to the idea of balancing the data volume that a > CN can send to an "unconfirmed" CoA of a MN with the data volume > that the CN has earlier sent to a "confirmed" CoA of the same MN. With > "unconfirmed" CoA I mean a CoA for which a concurrent CoA test is still > ongoing. With "confirmed" CoA I mean a CoA for which the CN has > obtained assurance, through a CoA test, that the MN is indeed reachable > at that CoA. We called this approach "Credit-Based Authorization", > meaning that a MN must collect some "credit" (in terms of data volume) > before it can do a concurrent CoA test. > > => this is very complex and does nothing for a victim behind a narrow > link and an attacker behind a fast link. Lets explore this a little bit. As Christian's draft contains the fixed 3 sec limit, presumably his implementation does as well, so we don't have practical experience about the complexity. But what would we have to do? I think the algorithm is here: - Upon creating a BCE, set a counter to zero. - Upon receiving a packet from the MN with a HAO, check if the BCE is in final (non-tentative) state. If yes, increment a counter in the BCE with the size of the packet. - In order to avoid collecting a lot of credit for a long time, the credit must be aged somehow. There's fancy ways of doing this, but a simple scheme might be to divide the current credit by two every 30 seconds. - When sending a packet to the mobile node when the BCE is in the tentative stage, decrement the counter with the size of the packet. If you reach zero, delete the BCE or move it back to its previous location. Is this all, or is something else also needed? Francis, I presume the credit based scheme must also ensure that Alt-CoA is not used, right? Because if we don't ensure that, an attacker that is under ingress filtering could do attacks that he previously couldn't. This is because the care-of test would have to be done for the claimed address, but the care-of test is not needed in the tentative stage. Re: victim behind a narrow link and attacker behind a fast link. You are right that this doesn't do anything for this case. But isn't this already the case today? I mean an attacker behind a fast link can send a zillion spoofed TCP SYNs to www.cnn.com and have the responses go my GPRS link, which would be hosed. The effort required for this would be a sending a zillion packets. To do this via early binding updates, you'd need more than a zillion packets. --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:20:05 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28662 for ; Tue, 30 Mar 2004 18:20:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Xa-Mm for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGARTrB011097 for mip6-archive@odin.ietf.org; Tue, 16 Dec 2003 05:27:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWCQG-0002rZ-PN for mip6-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 05:27:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08430 for ; Tue, 16 Dec 2003 05:27:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWCQA-0001Wo-00 for mip6-web-archive@ietf.org; Tue, 16 Dec 2003 05:27:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWCQ9-0001Wd-00 for mip6-web-archive@ietf.org; Tue, 16 Dec 2003 05:27:18 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWCQ8-0001Wa-00 for mip6-web-archive@ietf.org; Tue, 16 Dec 2003 05:27:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWCQ2-0002qq-Nj; Tue, 16 Dec 2003 05:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWCPO-0002oo-M1 for mip6@optimus.ietf.org; Tue, 16 Dec 2003 05:26:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08355 for ; Tue, 16 Dec 2003 05:26:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWCPL-0001QY-00 for mip6@ietf.org; Tue, 16 Dec 2003 05:26:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWCPK-0001QO-00 for mip6@ietf.org; Tue, 16 Dec 2003 05:26:26 -0500 Received: from p2.piuha.net ([131.160.192.2]) by ietf-mx with esmtp (Exim 4.12) id 1AWCPK-0001QK-00 for mip6@ietf.org; Tue, 16 Dec 2003 05:26:26 -0500 Received: from kolumbus.fi (p3.piuha.net [131.160.192.3]) by p2.piuha.net (Postfix) with ESMTP id 513306A903; Tue, 16 Dec 2003 12:26:26 +0200 (EET) Message-ID: <3FDEDDA1.4010608@kolumbus.fi> Date: Tue, 16 Dec 2003 12:25:37 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Greg O'Shea" Cc: mip6@ietf.org Subject: Re: [Mip6] suggested contents of the IANA registry for MIPv6 References: <579E83556A36E44EB2945CCE990B3174C7AEA8@EUR-MSG-02.europe.corp.microsoft.com> In-Reply-To: <579E83556A36E44EB2945CCE990B3174C7AEA8@EUR-MSG-02.europe.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Greg O'Shea wrote: > I can build with 143-146 or I can build with 144-147. > > Which is it? I need to know. 144-147 are the numbers that I gave to IANA, and ADs and chairs were a part of that discussion. Go with them. I suppose the IANA web site will be eventually updated ;-) --Jari _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:21:16 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29002 for ; Tue, 30 Mar 2004 18:21:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjQ-0006Zv-Jy for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB2FL4uf013796 for mip6-archive@odin.ietf.org; Tue, 2 Dec 2003 10:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCKl-0003aR-Vg for mip6-web-archive@optimus.ietf.org; Tue, 02 Dec 2003 10:21:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21531 for ; Tue, 2 Dec 2003 10:20:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCKj-0002DC-00 for mip6-web-archive@ietf.org; Tue, 02 Dec 2003 10:21:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ARCKj-0002D9-00 for mip6-web-archive@ietf.org; Tue, 02 Dec 2003 10:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCKk-0003ZH-4j; Tue, 02 Dec 2003 10:21:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ARCKW-0003Ws-FR for mip6@optimus.ietf.org; Tue, 02 Dec 2003 10:20:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21508 for ; Tue, 2 Dec 2003 10:20:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARCKR-0002CB-00 for mip6@ietf.org; Tue, 02 Dec 2003 10:20:43 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx with esmtp (Exim 4.12) id 1ARCKQ-0002BT-00 for mip6@ietf.org; Tue, 02 Dec 2003 10:20:42 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hB2FK84t028027 for ; Tue, 2 Dec 2003 07:20:08 -0800 (PST) Received: from naexfe02.na.qualcomm.com (naexfe02.qualcomm.com [129.46.51.214]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id hB2FK60N002454 for ; Tue, 2 Dec 2003 07:20:06 -0800 (PST) Received: from NAEX01.qualcomm.com ([129.46.51.60]) by naexfe02.na.qualcomm.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 2 Dec 2003 07:20:06 -0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6470.0 Date: Tue, 2 Dec 2003 07:20:05 -0800 Message-ID: <17D8F6DF3ED94D40BD607380866D9B7F33D1E0@NAEX01.na.qualcomm.com> Thread-Topic: [rohc] Actions against mailing list spam Thread-Index: AcGibIGhibuLPGB3RRq5rXLTYPX7goQs9Yzg From: "Barany, Pete" To: X-OriginalArrivalTime: 02 Dec 2003 15:20:06.0075 (UTC) FILETIME=[C3F008B0:01C3B8E7] Content-Transfer-Encoding: quoted-printable Subject: [Mip6] FW: [rohc] Actions against mailing list spam Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, About two years ago the IETF ROHC WG (see forwarded e-mail below) and several other IETF WGs (e.g., IETF AVT WG) had major problems with spam (quantity and 'quality'). It appears that the IETF MIP6 WG is suffering from this same problem. Both the ROHC and AVT WGs took appropriate action to eliminate the problem. Would it be possible to do the same for the MIP6 WG? Thanks in advance. Regards, Pete =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Lars-Erik Jonsson (EPL) [mailto:Lars-Erik.Jonsson@epl.ericsson.se] Sent: Monday, January 21, 2002 2:58 AM To: 'rohc@cdt.luth.se' Subject: [rohc] Actions against mailing list spam The ROHC mailing list has had major problems with spam, and the amount of irrelevant postings is not decreasing. As for other IETF mailing lists, we are therefore considering changing the list configuration so that posts are only automatically accepted from those subscribed to the list. Let us know your opinions on this. /L-E & Carsten --- Mailing list for Robust Header Compression WG Archive: http://www.cdt.luth.se/rohc/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:22:36 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29387 for ; Tue, 30 Mar 2004 18:22:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjK-0006YH-3x for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Ij4Uc026755 for mip6-archive@odin.ietf.org; Fri, 7 Nov 2003 13:45:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBbU-0006wj-QQ for mip6-web-archive@optimus.ietf.org; Fri, 07 Nov 2003 13:45:04 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28641 for ; Fri, 7 Nov 2003 13:44:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBbS-000154-00 for mip6-web-archive@ietf.org; Fri, 07 Nov 2003 13:45:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AIBbS-000151-00 for mip6-web-archive@ietf.org; Fri, 07 Nov 2003 13:45:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBbS-0006vV-AP; Fri, 07 Nov 2003 13:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBb4-0006q1-4J for mip6@optimus.ietf.org; Fri, 07 Nov 2003 13:44:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28596 for ; Fri, 7 Nov 2003 13:44:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBb1-00014i-00 for mip6@ietf.org; Fri, 07 Nov 2003 13:44:35 -0500 Received: from motgate6.mot.com ([144.189.100.106]) by ietf-mx with esmtp (Exim 4.12) id 1AIBb1-00014A-00 for mip6@ietf.org; Fri, 07 Nov 2003 13:44:35 -0500 Received: from az33exr03.mot.com (pobox3.mot.com [10.64.251.242]) by motgate6.mot.com (Motorola/Motgate6) with ESMTP id hA7IiGm5004723; Fri, 7 Nov 2003 11:44:17 -0700 (MST) Received: from thorgal.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (Motorola/az33exr03) with ESMTP id hA7IiEBJ005862; Fri, 7 Nov 2003 12:44:15 -0600 Received: from test9.crm.mot.com (test9.crm.mot.com [10.161.201.219]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8357B2EC98; Fri, 7 Nov 2003 19:44:14 +0100 (CET) To: "Pascal Thubert (pthubert)" Cc: mip6@ietf.org Subject: Re: [Mip6] HAHA architecture References: From: Alexandru Petrescu Date: Fri, 07 Nov 2003 19:44:14 +0100 In-Reply-To: (Pascal Thubert's message of "Thu, 6 Nov 2003 17:10:57 -0000") Message-ID: User-Agent: Gnus/5.090017 (Oort Gnus v0.17) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , "Pascal Thubert (pthubert)" writes: > - MN register to closest HA (primary HA) > - primary HA instanciates a MRHA tunnel and creates a route over that > tunnel to the MN (MNP) that is being registered > - primary HA redistributes that route to other HAs using HAHA protocol. > This is a proactive model where HAHA looks like a classical Routing > Protocol after all. Could HAHA not only look but also act as a classical routing protocol? Could the HA's just exchange routing information instead of BCE sync messages? If yes, then maybe the AR's to which MN attaches can also participate in this routing protocol exchanges and thus no need of Mobile IP at all, no? Alex GBU _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:30:39 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01296 for ; Tue, 30 Mar 2004 18:30:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjL-0006WI-0z for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i2MH9o6Z011358 for mip6-archive@odin.ietf.org; Mon, 22 Mar 2004 12:09:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Svk-0002wa-R3 for mip6-web-archive@optimus.ietf.org; Mon, 22 Mar 2004 12:09:40 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06583 for ; Mon, 22 Mar 2004 12:09:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Sve-0005nJ-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 12:09:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5Sul-0005hs-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 12:08:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B5SuA-0005ca-00 for mip6-web-archive@ietf.org; Mon, 22 Mar 2004 12:08:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5StG-0002B3-Hq; Mon, 22 Mar 2004 12:07:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B5Sr0-00023G-2d for mip6@optimus.ietf.org; Mon, 22 Mar 2004 12:04:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06379 for ; Mon, 22 Mar 2004 12:04:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B5Sqy-0005Fb-00 for mip6@ietf.org; Mon, 22 Mar 2004 12:04:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B5SqB-000597-00 for mip6@ietf.org; Mon, 22 Mar 2004 12:03:56 -0500 Received: from auds952.usa.alcatel.com ([143.209.238.7]) by ietf-mx with esmtp (Exim 4.12) id 1B5SpM-0004wt-00 for mip6@ietf.org; Mon, 22 Mar 2004 12:03:04 -0500 Received: from alcatel.com (localhost [127.0.0.1]) by auds952.usa.alcatel.com (8.12.10/8.12.10) with ESMTP id i2MH2WTN012110 for ; Mon, 22 Mar 2004 11:02:32 -0600 (CST) Message-ID: <405F1D83.EEE6CB42@alcatel.com> Date: Mon, 22 Mar 2004 11:08:19 -0600 From: Tim Ozugur X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] CFP:Broadband Wireless Networking Symposium 2004 - Extended Deadline Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL,LINES_OF_YELLING, LINES_OF_YELLING_2 autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit (Apologies if you are receiving this message more than once) ----------------------------------------------------------------------- CALL FOR PAPERS BroadNets 2004 Broadband Wireless Networking Symposium 2004 October 25 - 29, 2004 San Jose, California, USA www.broadnets.org ***** Extended Submission Deadline: April 1, 2004 ***** ----------------------------------------------------------------------- SCOPE ----- BroadNets 2004 is a new conference focusing on broadband networking and covers the entire gamut of next generation networks with ultra-high bandwidth available all the way from access networks (xDSL, Cable, EPON, Broadband Wireless, multi-Gigabit uplinks), to regional and metropolitan networks to wide-area core networks. The conference will consist of the following two symposia: ** Broadband Wireless Networking that is defined to cover high-speed wireless networking for access, regional and backhaul networks including backhaul capacity provisioning using wireless, including the WLAN networks and WMAN. ** Broadband Optical Networking includes WDM technologies, Ethernet and MPLS integration into the optical layer, Next-Gen SONET/SDH, as well as SAN extentions over DWDM/SONET/SDH. BroadNets 2004 will thus offer a unique forum for researchers from academia, government and industry to share ideas and disseminate new results in these important areas. In addition to expansion in scope, BroadNets 2004 will expand its target audience by encouraging industry contributions, through architecture and position papers. More details can be found at www.broadnets.org. This Call for Papers describes the details for the Broadband Wireless Networking Symposium ONLY. (Refer to the broadnets.org website for the Broadband Optical Symposium details.) We are soliciting full papers in all research, development, and deployment areas on broadband wireless networking. Applications/position/system papers from industry are also encouraged. Topics of interest include, but not limited to, the following: - 3G/4G Systems - Fixed Broadband Wireless Access - Wireless Local Area Networks - WLAN Hotspots - Wireless indoor & home networks - Wireless Personal Area Networks including IEEE 802.15 - IEEE 802.16 (WiMax) Standards Activities and Products - Wireless Metropolitan Area Networks - Wireless Wide Area Networks - Free-Space Optics - Ultra Wideband (UWB) Networks - Ad-hoc networks - Cellular mobile/WLAN interoperability - System architecture - Network Topology management - Neighbour discovery - Unicast and multicast routing - Quality-of-Service support - Security techniques and systems - Resource management - Software-defined radio - Space-time processing, MIMO systems - Digital signal processing - Smart (directional) antennas - Power control - Wireless emergency systems - Standards, Licensing and regulation - Interference mitigation for multiple access - Economics and business cases IMPORTANT DATES --------------- Full papers due: April 1, 2004 Notification of acceptance: June 7, 2004 Final manuscript due: July 7, 2004 Conference Dates: October 25 - 29, 2004 PAPER SUBMISSION INSTRUCTIONS ----------------------------- Authors are invited to submit full papers of up to 20 double-spaced pages in Times 10pt font, including references, figures and tables. All submissions should be submitted electronically to EDAS system at http://edas.info/Conferences.cgi and in Postscript or Adobe PDF format. Papers of particular merit will be considered for a special issue of ACM/Kluwer Mobile Networks (MONET) Journal. PROPOSALS FOR WORKSHOPS, TUTORIALS AND PANELS --------------------------------------------- Proposals for workshops, tutorials and panels on broadband wireless networking and related topics are solicited. Contact information for respective Chairs can be found at www.broadnets.org. Workshop proposals should consist of: 1) title of the workshop, 2) description of potential audience, 3) description of the workshop topic and justification of why the proposed topic is interesting and timely and, 4) intended format of the workshop. Please submit your proposals to the appropriate Chairs by April 1, 2004. Tutorial proposals should consist of: 1) title and outline of materials to be presented, 2) description of potential audience, 3) justification of why the proposed topic is interesting and timely and, 4) biographical sketch of the presenter(s). Please submit your proposals to the appropriate Chairs by May 1, 2004. Panel topics should address innovative, controversial, or otherwise provocative issues of interest related to broadband wireless networking and communications. Please submit your proposals to the appropriate Chairs by May 1, 2004. CONFERENCE INFORMATION ---------------------- For the general information about the organization of the BroadNets 2004 conference, please visit http://www.broadnets.org or contact one of the conference chairs listed below (more details are on the website). CONFERENCE ORGANIZING COMMITTEE ------------------------------- BroadNets Conference General Chair: Dr. Raj Jain, Nayna Networks/Ohio State University, raj@nayna.com Broadband Wireless Networking Symposium Chair: Dr. Zhensheng Zhang, San Diego Research Center, zzhang@ieee.org Technical Program Co-Chairs: Dr. Parameswaran Ramanathan, Univ. of Wisconsin-Madison, parmesh@ece.wisc.edu Dr. Thomas Hou, Virginia Tech, thou@vt.edu Panels Co-Chairs: Dr. Byrav Ramamurthy, University of Nebraska - Lincoln, byrav@cse.unl.edu Dr. Loukas Paraschis, Cisco Systems, loukas@cisco.com Tutorials Co-Chairs: Dr. Hakki Candan Cankaya, Alcatel USA, hakki.cankaya@alcatel.com Dr. Surendar Chandra, Univ of Notre Dame, surendar@cse.nd.edu Workshops Co-Chairs: Dr. Nasir Ghani, Tennessee Tech University, nghani@ieee.org Dr. Rajeev Shorey, National University of Singapore and IBM Research India, rajeev@comp.nus.edu.sg Exhibits and Sponsorships Chairs: Dr. Samrat Ganguly, NEC Labs, samrat@nec-labs.com Dr. Javier Aracil, Universidad Publica de Navarra, Spain, javier.aracil@unavarra.es Publications Chair: Dr. Srinivasan Ramasubramanian, U. of Arizona srini@ece.arizona.edu Local Arrangements Co-Chairs: Dr. Subhankar Dhar, San Jose State University, dhar_s@cob.sjsu.edu Dr. Sukesh Pai, Microsoft, sukeshp@microsoft.com Publicity Co-Chairs: Dr. Tim Ozugur, Alcatel USA, tim.ozugur@alcatel.com Dr. Gaoxi Xiao, Nanyang Technological Univ. Singapore, egxxiao@ntu.edu.sg Dr. Marcos Rogerio Salvador, CPqD Telecom & IT Solutions, marcosrs@cpqd.com.br Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, University of Maryland, Baltimore County, krishna@umbc.edu -------------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:33:10 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01895 for ; Tue, 30 Mar 2004 18:33:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjH-0006YH-JB for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hB67cOAw017174 for mip6-archive@odin.ietf.org; Sat, 6 Dec 2003 02:38:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASX1D-0004RW-C3 for mip6-web-archive@optimus.ietf.org; Sat, 06 Dec 2003 02:38:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29167 for ; Sat, 6 Dec 2003 02:38:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASX19-0003Ih-00 for mip6-web-archive@ietf.org; Sat, 06 Dec 2003 02:38:19 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ASX19-0003Ie-00 for mip6-web-archive@ietf.org; Sat, 06 Dec 2003 02:38:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASX1B-0004PW-Am; Sat, 06 Dec 2003 02:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASX0d-0004GX-5n for mip6@optimus.ietf.org; Sat, 06 Dec 2003 02:37:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29143; Sat, 6 Dec 2003 02:37:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASX0X-0003I2-00; Sat, 06 Dec 2003 02:37:41 -0500 Received: from argc.paf.se ([195.66.31.71] helo=paf.se) by ietf-mx with esmtp (Exim 4.12) id 1ASX0W-0003Hz-00; Sat, 06 Dec 2003 02:37:40 -0500 Received: by paf.se (CommuniGate Pro PIPE 4.1) with PIPE id 1263794; Sat, 06 Dec 2003 08:40:29 +0100 Received: from localhost [127.0.0.1] by argc.paf.se with SpamAssassin (2.55 1.174.2.19-2003-05-19-exp); Sat, 06 Dec 2003 08:40:22 +0100 From: "Lamar Wolfe" To: asrg@ietf.org Cc: , , , , , , , Date: Sat, 06 Dec 03 16:27:18 GMT Message-Id: <217l-g$-kz6w1ry3q5a$zdo47@uh0bewv> X-Spam-Flag: YES X-Spam-Status: Yes, hits=10.8 required=5.0 tests=DATE_IN_PAST_03_06,FORGED_MUA_THEBAT,HGH,HTML_70_80, HTML_EVENT_UNSAFE,HTML_JAVASCRIPT,HTML_SHOUTING3, HTML_WITH_BGCOLOR,KNOWN_MAILING_LIST,MIME_HTML_ONLY, MISSING_MIMEOLE,MISSING_OUTLOOK_NAME,RCVD_IN_DSBL version=2.55 X-Spam-Level: ********** X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_3FD187E6.2D08BA13" Subject: [Mip6] [Idr] Top athletes reveal secrets,, xu Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------------=_3FD187E6.2D08BA13 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit This mail is probably spam. The original message has been attached along with this report, so you can recognize or block similar unwanted mail in future. See http://spamassassin.org/tag/ for more details. Content preview: Young and Strong Medically Proven and Recognized Around the World HGH replenishes what TIME has taken away !Look Better and Feel Better ! Be Sexy and Athletic ! Increases your Energy *** Speeds up your Metabolism Improves Mental Clarity and Thinking Abilities !Part of the daily routines of: Doctors, Celebrities, Models, Athletes, Politicians, and even World Leaders ! [...] Content analysis details: (10.80 points, 5 required) HGH (1.1 points) BODY: Human Growth Hormone HTML_SHOUTING3 (0.1 points) BODY: HTML has very strong "shouting" markup HTML_JAVASCRIPT (0.2 points) BODY: JavaScript code HTML_70_80 (0.3 points) BODY: Message is 70% to 80% HTML HTML_WITH_BGCOLOR (0.1 points) BODY: HTML mail with non-white background HTML_EVENT_UNSAFE (0.2 points) BODY: HTML contains unsafe auto-executing code DATE_IN_PAST_03_06 (0.3 points) Date: is 3 to 6 hours before Received: date KNOWN_MAILING_LIST (-0.3 points) Email came from some known mailing list software RCVD_IN_DSBL (4.3 points) RBL: Received via a relay in list.dsbl.org [RBL check: found 33.187.235.24.list.dsbl.org.] MISSING_MIMEOLE (0.1 points) Message has X-MSMail-Priority, but no X-MimeOLE MIME_HTML_ONLY (0.1 points) Message only has text/html MIME parts FORGED_MUA_THEBAT (4.3 points) Forged mail pretending to be from The Bat! MISSING_OUTLOOK_NAME (0.0 points) Message looks like Outlook, but isn't The original message did not contain plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. ------------=_3FD187E6.2D08BA13 Content-Type: message/rfc822; x-spam-type=original Content-Description: original message before SpamAssassin Content-Disposition: attachment Return-Path: Envelope-To: anders@lowinger.se X-Spam-Status: SpamAssassin Failed Received: from [132.151.6.22] (HELO optimus.ietf.org) by paf.se (CommuniGate Pro SMTP 4.1) with ESMTP id 1263793 for anders@lowinger.se; Sat, 06 Dec 2003 08:39:51 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASWz7-0003tJ-QD; Sat, 06 Dec 2003 02:36:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ASWyh-0003pF-92 for idr@optimus.ietf.org; Sat, 06 Dec 2003 02:35:47 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28943; Sat, 6 Dec 2003 02:35:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ASWyc-0003DA-00; Sat, 06 Dec 2003 02:35:42 -0500 Received: from d235-187-33.home1.cgocable.net ([24.235.187.33]) by ietf-mx with smtp (Exim 4.12) id 1ASWyb-0003D6-00; Sat, 06 Dec 2003 02:35:41 -0500 Received: from (HELO tega8n) [19.65.69.195] by d235-187-33.home1.cgocable.net with ESMTP id 45796721; Sat, 06 Dec 2003 16:27:18 -0500 Message-ID: <217l-g$-kz6w1ry3q5a$zdo47@uh0bewv> From: "Lamar Wolfe" Reply-To: "Lamar Wolfe" To: asrg@ietf.org Cc: , , , , , , , X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5462C47DBAB22E8__A90" X-Priority: 3 X-MSMail-Priority: Normal Subject: [Idr] Top athletes reveal secrets,, xu Sender: idr-admin@ietf.org Errors-To: idr-admin@ietf.org X-BeenThere: idr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Inter-Domain Routing List-Post: List-Help: List-Subscribe: , List-Archive: Date: Sat, 06 Dec 03 16:27:18 GMT --5462C47DBAB22E8__A90 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Young and Strong

Medical= ly Proven and Recognized Around the World
HGH
replenishes what TIME = has taken away !

Look Better and Feel Better !
Be Sexy and Athletic !
Increases your Energy *** Speeds up your Met= abolism
Improves Mental Clarity and Thinking Abilities !
Part of the = daily routines of:
Doctors, Celebrities, Models, Athletes, Politicians, and even World Lead= ers !
Time, stress, and aging REDUCE and EXHAUST
the very hormones we n= eed to remain youthful and vibrant.
You can now REPLENISH what time has= taken away !

With Doctor Approved HGH !

60 day 100% Money-Back Guaran= tee!

This way to loo= k and feel better with HGH!!

gtjlf nnqczbx ldyrf qdpse bdqkipqqli p fc --5462C47DBAB22E8__A90-- _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr ------------=_3FD187E6.2D08BA13-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:35:49 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02544 for ; Tue, 30 Mar 2004 18:35:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8RjE-0006WI-AQ for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:29:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA42KH1h021192 for mip6-archive@odin.ietf.org; Mon, 3 Nov 2003 21:20:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqnp-0005TD-4U for mip6-web-archive@optimus.ietf.org; Mon, 03 Nov 2003 21:20:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09323 for ; Mon, 3 Nov 2003 21:19:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqne-0003AM-00 for mip6-web-archive@ietf.org; Mon, 03 Nov 2003 21:20:06 -0500 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AGqne-0003AJ-00 for mip6-web-archive@ietf.org; Mon, 03 Nov 2003 21:20:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqne-0005No-N4; Mon, 03 Nov 2003 21:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGqml-0005GC-Fc for mip6@optimus.ietf.org; Mon, 03 Nov 2003 21:19:11 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09300; Mon, 3 Nov 2003 21:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGqmi-00038x-00; Mon, 03 Nov 2003 21:19:08 -0500 Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx with esmtp (Exim 4.12) id 1AGqmh-00038o-00; Mon, 03 Nov 2003 21:19:08 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:208:dff:fe40:3f37]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 7E67815210; Tue, 4 Nov 2003 11:19:05 +0900 (JST) Date: Tue, 04 Nov 2003 11:19:02 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Soohong Daniel Park Cc: "'Vijay Devarapalli'" , "'Soliman Hesham'" , ipv6@ietf.org, mip6@ietf.org, dna@eng.monash.edu.au Subject: Re: [Mip6] Re: A list of issues for RFC2462 update In-Reply-To: <01ae01c399d5$e748d660$b7cbdba8@daniel> References: <3F987C5B.9070905@iprg.nokia.com> <01ae01c399d5$e748d660$b7cbdba8@daniel> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> On Fri, 24 Oct 2003 11:24:08 +0900, >>>>> Soohong Daniel Park said: > I agreed with your mention and this issue is work in progress > at the DNA BOF. A second BOF will be scheduled during > this meeting. > For more reference, please look into this draft. > http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requiremen > t-01.txt Thanks for the pointer. I think this is a good summary of DAD related issues raised so far. (Again, this does not mean I'm going to propose a change in rfc2462bis due to the issue) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:40:56 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03908 for ; Tue, 30 Mar 2004 18:40:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj9-0006WI-D9 for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9G718OB010790 for mip6-archive@odin.ietf.org; Thu, 16 Oct 2003 03:01:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA28C-0002nx-7B for mip6-web-archive@optimus.ietf.org; Thu, 16 Oct 2003 03:01:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22217 for ; Thu, 16 Oct 2003 03:00:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA288-0001KP-00 for mip6-web-archive@ietf.org; Thu, 16 Oct 2003 03:01:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AA287-0001KL-00 for mip6-web-archive@ietf.org; Thu, 16 Oct 2003 03:01:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA287-0002nF-8X; Thu, 16 Oct 2003 03:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AA27B-0002i0-Ku for mip6@optimus.ietf.org; Thu, 16 Oct 2003 03:00:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22154 for ; Thu, 16 Oct 2003 02:59:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AA276-0001Im-00 for mip6@ietf.org; Thu, 16 Oct 2003 03:00:00 -0400 Received: from omgo.iij.ad.jp ([202.232.30.157]) by ietf-mx with esmtp (Exim 4.12) id 1AA275-0001IS-00 for mip6@ietf.org; Thu, 16 Oct 2003 03:00:00 -0400 Received: from jc-smtp.iij.ad.jp ([192.168.176.35]) by omgo.iij.ad.jp (8.12.10/8.12.9) with ESMTP id h9G6xuuH020240 for ; Thu, 16 Oct 2003 15:59:56 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.65.65]) by jc-smtp.iij.ad.jp (8.12.10/8.12.9) with ESMTP id h9G6xVeS009551 for ; Thu, 16 Oct 2003 15:59:31 +0900 (JST) Date: Thu, 16 Oct 2003 15:58:46 +0900 (JST) Message-Id: <20031016.155846.03060450.keiichi@iij.ad.jp> To: mip6@ietf.org From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= X-Mailer: Mew version 4.0.59 on Emacs 21.3.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip6] I-D on route optimization hints Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I have submitted an I-D that describes a mechanism to distribute RO hint information. The hint information is used to judge whether a mobile node initiate route optimization procedure or not, based on addresses. The I-D can be retreived from ftp://ftp.ietf.org/internet-drafts/draft-shima-mip6-rohints-00.txt The abstract is: This memo describes the distribution mechanism of route optimization hints, which can be used by a mobile node to determine when the node should initiate the route optimization procedure when communicating with correspondent nodes. Usually, a mobile node will perform RO procedure to any correspondent node as described in Mobile IPv6 specification [1]. However, in some cases, it is better not to perform RO. A typical example is a firewalled network. This memo also describes a configuration of a firewall which makes mobile nodes possible to move between an intranet and the Internet by using RO hints. Any comments are welcome. Best Regards, --- Keiichi SHIMA IIJ Research Laboratory KAME Project _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:41:45 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04174 for ; Tue, 30 Mar 2004 18:41:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Rj9-0006WI-B9 for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBa7H0024258 for mip6-archive@odin.ietf.org; Tue, 18 Nov 2003 06:36:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM49P-0006JB-HM for mip6-web-archive@optimus.ietf.org; Tue, 18 Nov 2003 06:36:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16770 for ; Tue, 18 Nov 2003 06:35:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM49L-0003Fo-00 for mip6-web-archive@ietf.org; Tue, 18 Nov 2003 06:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AM49L-0003Fl-00 for mip6-web-archive@ietf.org; Tue, 18 Nov 2003 06:36:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM49M-0006Hu-Pe; Tue, 18 Nov 2003 06:36:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM497-0006Dr-M6 for mip6@optimus.ietf.org; Tue, 18 Nov 2003 06:35:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16722; Tue, 18 Nov 2003 06:35:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM493-0003Et-00; Tue, 18 Nov 2003 06:35:45 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay) by ietf-mx with esmtp (Exim 4.12) id 1AM492-0003Ep-00; Tue, 18 Nov 2003 06:35:45 -0500 Received: from chardonnay ([127.0.0.1]) by chardonnay with smtp (Exim 3.36 #1 (Debian)) id 1AM45x-0000BC-00; Tue, 18 Nov 2003 12:32:33 +0100 Date: Tue, 18 Nov 2003 12:32:15 +0100 From: Henrik Levkowetz To: Soliman Hesham Cc: mip4@ietf.org, mip6@ietf.org Message-Id: <20031118123215.37b8b7bc.henrik@levkowetz.com> In-Reply-To: <9E3BA3946476AD4EB94672712B12A85F041FFE@ftmail.lab.flarion.com> References: <9E3BA3946476AD4EB94672712B12A85F041FFE@ftmail.lab.flarion.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Signature=_Tue__18_Nov_2003_12_32_15_+0100_eqVtAg0_vzwl9R/." Subject: [Mip6] Re: [Mip4] tying flow movement to MIP RE: [Mipshop] Minutes of Multiple Lin k Flows BAR BOF Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --Signature=_Tue__18_Nov_2003_12_32_15_+0100_eqVtAg0_vzwl9R/. Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Monday 17 November 2003, Hesham wrote: > => Sure, I'm not sure what "less general" means though. I was refering back to what I wrote earlier in this thread: "The cost of this solution is in having to do re-registration of multiple sessions when you move, but such a cost is already implicit in the fact that with multiple connections through different connection media you have to be able to handle each media individually, whether it is by separate sessions or by filter adaptations. But I believe completely separate sessions will adapt better to any other non-movement-specific solution to multihoming that may appear." Henrik --Signature=_Tue__18_Nov_2003_12_32_15_+0100_eqVtAg0_vzwl9R/. Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ugNNeVhrtTJkXCMRAmUGAJ9fAy/PtZRYbsZIwolA0Lksz03WagCfVWeJ pmULHS/dMexwvrUAc+Fcpfo= =aMyL -----END PGP SIGNATURE----- --Signature=_Tue__18_Nov_2003_12_32_15_+0100_eqVtAg0_vzwl9R/.-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6 From exim@www1.ietf.org Tue Mar 30 18:56:55 2004 Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08155 for ; Tue, 30 Mar 2004 18:56:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B8Riv-0006Yx-Qs for mip6-archive@odin.ietf.org; Tue, 30 Mar 2004 17:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IF3WTI030909 for mip6-archive@odin.ietf.org; Wed, 18 Feb 2004 10:03:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTEa-00082P-64 for mip6-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:03:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16520 for ; Wed, 18 Feb 2004 10:03:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTEY-0005ud-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 10:03:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTCr-0005Zk-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 10:01:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtTBK-0005Hl-00 for mip6-web-archive@ietf.org; Wed, 18 Feb 2004 10:00:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTBF-0005dx-Ay; Wed, 18 Feb 2004 10:00:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTAf-0005W1-Cs for mip6@optimus.ietf.org; Wed, 18 Feb 2004 09:59:29 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15652; Wed, 18 Feb 2004 09:59:25 -0500 (EST) Message-Id: <200402181459.JAA15652@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip6@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 18 Feb 2004 09:59:25 -0500 Subject: [Mip6] I-D ACTION:draft-ietf-mip6-mipv6-mib-01.txt Sender: mip6-admin@ietf.org Errors-To: mip6-admin@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org X-Spam-Status: No, hits=0.4 required=5.0 tests=AWL,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=2.60 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : The Mobile IPv6 MIB Author(s) : G. Keeni, K. Nagami, K. Koide, S. Gundavelli Filename : draft-ietf-mip6-mipv6-mib-01.txt Pages : 59 Date : 2004-2-18 This memo defines a portion of the Management Information Base (MIB), the the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, Mobile-IPv6 MIB will be used to monitor and control Mobile Node, Home Agent and Correspondent Node functions of an MIPv6 entity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mipv6-mib-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip6-mipv6-mib-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip6-mipv6-mib-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: <2004-2-18101239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-mipv6-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-mipv6-mib-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-18101239.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www.ietf.org/mailman/listinfo/mip6