From exim@www1.ietf.org Mon Feb 2 13:07:48 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27151 for ; Mon, 2 Feb 2004 13:07: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 1AniTg-00071A-Po for mip4-archive@odin.ietf.org; Mon, 02 Feb 2004 13:07:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12I7KqE026970 for mip4-archive@odin.ietf.org; Mon, 2 Feb 2004 13:07:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniTg-00070t-BE for mip4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:07: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 NAA26965 for ; Mon, 2 Feb 2004 13:07:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniTe-0002Rs-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:07:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniP2-0001Jh-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:02:34 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AniMu-0000tL-01 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:00:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by mx2.foretec.com with esmtp (Exim 4.24) id 1AniD4-00070Q-8L for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 12:50:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCz-0004m7-O5; Mon, 02 Feb 2004 12:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniCF-0004bu-J4 for mip4@optimus.ietf.org; Mon, 02 Feb 2004 12:49: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 MAA25633 for ; Mon, 2 Feb 2004 12:49:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniCD-0007MO-00 for mip4@ietf.org; Mon, 02 Feb 2004 12:49:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ani8A-0006Mp-00 for mip4@ietf.org; Mon, 02 Feb 2004 12:45:09 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1Ani1u-0004dL-00 for mip4@ietf.org; Mon, 02 Feb 2004 12:38:38 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i12HblqJ014509; Mon, 2 Feb 2004 18:37:47 +0100 Date: Mon, 2 Feb 2004 18:37:46 +0100 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] [Issue 22] Section 3.4 para 1 is too simplified Message-Id: <20040202183746.45be8c4d.henrik@levkowetz.com> In-Reply-To: <4018268D.1E4B7D17@iprg.nokia.com> References: <4018268D.1E4B7D17@iprg.nokia.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__2_Feb_2004_18_37_46_+0100_c1FSBFmV0lgq/zOj" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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__2_Feb_2004_18_37_46_+0100_c1FSBFmV0lgq/zOj Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Wednesday, 28 Jan 2004, Charles E. Perkins wrote: > Please refer to previous discussion at the following URL: > http://www.mip4.org/issues/tracker/mip4/issue22 > as necessary. > > Here is a proposed new paragraph, utilizing the word > "typically" along with some other minor improvement. > > A mobility agent typically returns a Registration Reply message to > a mobile node which has sent a Registration Request (Section 3.3) > message. If the mobile node is requesting service from a foreign > agent, that foreign agent will typically receive the Reply from the > home agent and subsequently relay it to the mobile node. Reply > messages contain the necessary codes to inform the mobile node about > the status of its Request, along with the lifetime granted by the > home agent, which MAY be smaller than the original Request. This change looks good to me. Henrik --Signature=_Mon__2_Feb_2004_18_37_46_+0100_c1FSBFmV0lgq/zOj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHorreVhrtTJkXCMRAkOrAJ4tZSDKfSLIDba8NA2jPhaNhJSRfQCff42B OVxUDP1z1DF09O/9wFPJ8JE= =u6FJ -----END PGP SIGNATURE----- --Signature=_Mon__2_Feb_2004_18_37_46_+0100_c1FSBFmV0lgq/zOj-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 2 13:13:43 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28164 for ; Mon, 2 Feb 2004 13:13: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 1AniZR-0007qh-L3 for mip4-archive@odin.ietf.org; Mon, 02 Feb 2004 13:13:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IDHCi030163 for mip4-archive@odin.ietf.org; Mon, 2 Feb 2004 13:13:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniZR-0007qN-0s for mip4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:13: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 NAA28133 for ; Mon, 2 Feb 2004 13:13:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniZP-0003nx-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:13:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniYM-0003cK-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:12:10 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AniXH-0003QA-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:11:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniXI-0007YH-9r; Mon, 02 Feb 2004 13:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AniX0-0007W5-EC for mip4@optimus.ietf.org; Mon, 02 Feb 2004 13:10: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 NAA27888 for ; Mon, 2 Feb 2004 13:10:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AniWy-0003N4-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:10:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AniVR-0002zY-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:09:10 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AniSG-0001y1-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:05:52 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i12I5KqJ015048; Mon, 2 Feb 2004 19:05:20 +0100 Date: Mon, 2 Feb 2004 19:05:20 +0100 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] [Issue 21] MN-AAA extension not considered in FA to HA forwarding rules Message-Id: <20040202190520.37822722.henrik@levkowetz.com> In-Reply-To: <401830D9.CED2FA09@iprg.nokia.com> References: <401830D9.CED2FA09@iprg.nokia.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__2_Feb_2004_19_05_20_+0100_5kEwTjivoe3xu3=s" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 --Signature=_Mon__2_Feb_2004_19_05_20_+0100_5kEwTjivoe3xu3=s Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, > ... On Wednesday, 28 Jan 2004, Charles E. Perkins wrote: > > The problem with this text results from the > previous change to Mobile IP whereby registrations > can be authorized by including alternative > "authorization-enabling" extensions, for instance > the "MN-AAA Authentication" extension. I fixed > this by rewording the bullet item as suggested at > the working group meeting. > > OLD: > - It MUST process and remove any Extensions following the > Mobile-Home Authentication Extension, > NEW: > - It MUST process and remove any Extensions which do not > precede any authorization-enabling extension. > > I _think_ this also takes care of the case where a > foreign agent doesn't recognize the authorization-enabling > extension. Perhaps we should designate new Extension > with subtypes that would take care of all future > authentication-enabling extensions. That would be > the clearest resolution of this problem. I think the proposed text actually also implies that the last authorization-enabling extension should be processed and removed, which isn't what we want, I guess. What about " - It MUST process and remove any Extensions following the last authorization-enabling extension." or maybe " - It MUST process and remove any Extensions which are not covered by any authorization-enabling extension." Regards, Henrik --Signature=_Mon__2_Feb_2004_19_05_20_+0100_5kEwTjivoe3xu3=s Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHpFgeVhrtTJkXCMRAkUFAJ9C99bMoIARPfECdcIauNU7R6W0XACgqWU/ EIvegGZwaWW96ZyWsAYzEFc= =b7DV -----END PGP SIGNATURE----- --Signature=_Mon__2_Feb_2004_19_05_20_+0100_5kEwTjivoe3xu3=s-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 2 13:28:15 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28979 for ; Mon, 2 Feb 2004 13:28: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 1AninT-0000QE-Kx for mip4-archive@odin.ietf.org; Mon, 02 Feb 2004 13:27:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IRl3g001616 for mip4-archive@odin.ietf.org; Mon, 2 Feb 2004 13:27:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AninT-0000Pz-D0 for mip4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:27: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 NAA28966 for ; Mon, 2 Feb 2004 13:27:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AninR-0005e2-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:27:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anima-0005Xg-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:26:53 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1Anilk-0005Rz-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:26:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anill-0000KQ-Jf; Mon, 02 Feb 2004 13: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 1Anilf-0000Jq-Ul for mip4@optimus.ietf.org; Mon, 02 Feb 2004 13:25: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 NAA28867 for ; Mon, 2 Feb 2004 13:25:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anild-0005Qt-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:25:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anikk-0005Kn-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:24:58 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AnikA-0005Cq-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:24:22 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i12INXqJ015336; Mon, 2 Feb 2004 19:23:33 +0100 Date: Mon, 2 Feb 2004 19:23:34 +0100 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: Jayshree Bharatia , mip4@ietf.org Subject: Re: [Mip4] [issue 19] Multiple authorization-enabling extensions should be permitted Message-Id: <20040202192334.1f934324.henrik@levkowetz.com> In-Reply-To: <401AAB5D.2D176864@iprg.nokia.com> References: <870397D7C140C84DB081B88396458DAF746CE1@zrc2c000.us.nortel.com> <401AAB5D.2D176864@iprg.nokia.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__2_Feb_2004_19_23_34_+0100_ZrnLzRJJ18JEy9pX" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Mon__2_Feb_2004_19_23_34_+0100_ZrnLzRJJ18JEy9pX Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, On Friday, 30 Jan 2004, Charles E. Perkins wrote: > Here is the actual new text that should > have been pasted in: > > a) The home agent MUST check for the presence of at least > one authorization-enabling extension, and ensure that > all indicated authentications are carried out. At least > one authorization-enabling extension MUST be present in > the Registration Request; and the home agent MUST either > check the Authenticator value in the extension or verify > that the authenticator value has been checked by another > agent with which it has a security association. If no > authorization-enabling extension is found, or if the > Authenticator is invalid, the home agent MUST reject the > mobile node's registration and SHOULD send a Registration > Reply to the mobile node with Code 131. The home agent > MUST then discard the Request and SHOULD log the error > as a security exception. If the home agent receives a > Registration Request without a Mobile-Home Authentication > extension from a Mobile Node that has a security association > with this home agent, the home agent MUST discard the Mobile > Node's Registration Request. It seems to me that this text doesn't clearly indicate if _all_ authorization-enabling extensions much be successfully verified by the home agent or its proxy, or if it is sufficient that _one_ of the authorization_enabling extensions are successfully verified. So there are two issues here 1) Which of these alternatives do we want to require? 2) The alternative chosen should be clearly indicated in the text > b) The home agent MUST check that the registration > Identification field is correct using the context selected > by the SPI within the authorization-enabling extension > that the home agent used to authenticate the Mobile Node's > Registration Request. See Section 5.7 for a description of > how this is performed. If incorrect, the home agent MUST > reject the Request and SHOULD send a Registration Reply to > the mobile node with Code 133, including an Identification > field computed in accordance with the rules specified in > Section 5.7. The home agent MUST do no further processing > with such a Request, though it SHOULD log the error as a > security exception. This part of the text sounds to me as if it is enough that one of the authorization-enabling extensions can be successfully verified. This part is fine with me if we make that choice clearer under a). Regards, Henrik --Signature=_Mon__2_Feb_2004_19_23_34_+0100_ZrnLzRJJ18JEy9pX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHpWmeVhrtTJkXCMRAqR7AKDeo7zqvF5FBm2b/828k/ibnFHQ2ACePlQS pF4drC9lSt5vulYXglfSPLY= =DKy7 -----END PGP SIGNATURE----- --Signature=_Mon__2_Feb_2004_19_23_34_+0100_ZrnLzRJJ18JEy9pX-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 2 13:45:26 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00445 for ; Mon, 2 Feb 2004 13:45:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anj46-0002h1-Sv for mip4-archive@odin.ietf.org; Mon, 02 Feb 2004 13:44:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12IiwDw010345 for mip4-archive@odin.ietf.org; Mon, 2 Feb 2004 13:44:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Anj46-0002gm-NF for mip4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 13:44: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 NAA00426 for ; Mon, 2 Feb 2004 13:44:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Anj44-00016y-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:44:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anj2C-0000dN-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:43:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnizN-00005z-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 13:40:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnizN-00029F-ET; Mon, 02 Feb 2004 13:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aniyu-00026g-3q for mip4@optimus.ietf.org; Mon, 02 Feb 2004 13:39: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 NAA29858 for ; Mon, 2 Feb 2004 13:39:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aniyr-0007kQ-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:39:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Anix9-0007PU-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:37:48 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1Aniw6-0006Xd-00 for mip4@ietf.org; Mon, 02 Feb 2004 13:36:42 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i12IWQqJ015475; Mon, 2 Feb 2004 19:32:26 +0100 Date: Mon, 2 Feb 2004 19:32:26 +0100 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] [issue 19] Multiple authorization-enabling extensions should be permitted Message-Id: <20040202193226.343e18b8.henrik@levkowetz.com> In-Reply-To: <40184B0F.F7199D88@iprg.nokia.com> References: <40184B0F.F7199D88@iprg.nokia.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__2_Feb_2004_19_32_26_+0100_t6/i1hw3aDR_qU5G" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Mon__2_Feb_2004_19_32_26_+0100_t6/i1hw3aDR_qU5G Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit > - On Wednesday, 28 Jan 2004, Charles E. Perkins wrote: > > Section 3.6.1.3 ... > New text: > > This section describes the ordering of any mandatory and any optional > Extensions that a mobile node appends to a Registration Request. > This ordering is REQUIRED: > > a) The IP header, followed by the UDP header, followed by the > fixed-length portion of the Registration Request, followed by > > b) If present, any non-authentication Extensions expected to be > used by the home agent or other authorizing agent (which may > or may not also be useful to the foreign agent), followed by > > c) All authorization-enabling extensions, followed by > > d) If present, any non-authentication Extensions used only by > the foreign agent, followed by > > e) The Mobile-Foreign Authentication Extension, if present. > > Note that items (a) and (c) MUST appear in every Registration Request > sent by the mobile node. Items (b), (d), and (e) are optional. > However, item (e) MUST be included when the mobile node and the > foreign agent share a mobility security association. With this new wording, it might be good (in order to avoid confusion) to refer back to the definition in Section 1.6 of "Authorization- enabling extension": ... c) All authorization-enabling extensions, (see Section 1.6) followed by ... Regards, Henrik --Signature=_Mon__2_Feb_2004_19_32_26_+0100_t6/i1hw3aDR_qU5G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHpe7eVhrtTJkXCMRAj4bAJ90N7LyK+N0Dk5fHE7G/Ka0aNQE1QCg2vRK LefIDhJN4i4J7RFxMZ4+Koc= =pTH1 -----END PGP SIGNATURE----- --Signature=_Mon__2_Feb_2004_19_32_26_+0100_t6/i1hw3aDR_qU5G-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 2 14:14:17 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03398 for ; Mon, 2 Feb 2004 14:14: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 1AnjW2-0006ZY-8j for mip4-archive@odin.ietf.org; Mon, 02 Feb 2004 14:13:50 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12JDoOB025258 for mip4-archive@odin.ietf.org; Mon, 2 Feb 2004 14:13:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjW2-0006ZJ-2h for mip4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 14:13: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 OAA03375 for ; Mon, 2 Feb 2004 14:13:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjVz-0006Sw-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 14:13:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjV3-0006N2-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 14:12:49 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AnjUF-0006IA-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 14:11:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjUG-0006TE-TX; Mon, 02 Feb 2004 14:12:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnjU8-0006SB-Ms for mip4@optimus.ietf.org; Mon, 02 Feb 2004 14:11: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 OAA03349 for ; Mon, 2 Feb 2004 14:11:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnjU6-0006HG-00 for mip4@ietf.org; Mon, 02 Feb 2004 14:11:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnjTD-0006CG-00 for mip4@ietf.org; Mon, 02 Feb 2004 14:10:56 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AnjSj-00065y-00 for mip4@ietf.org; Mon, 02 Feb 2004 14:10:25 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i12IbjqJ015620; Mon, 2 Feb 2004 19:37:50 +0100 Date: Mon, 2 Feb 2004 19:37:46 +0100 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] [Issue 18] The FA is rejecting with Error Code 136 which is meant for the home agent Message-Id: <20040202193746.2aab9e40.henrik@levkowetz.com> In-Reply-To: <4018507B.A4881E58@iprg.nokia.com> References: <4018507B.A4881E58@iprg.nokia.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__2_Feb_2004_19_37_46_+0100_YUbZx.m16wCCqaF+" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Mon__2_Feb_2004_19_37_46_+0100_YUbZx.m16wCCqaF+ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Wednesday, 28 Jan 2004, Charles E. Perkins wrote: > New text: > if the foreign agent does not serve the mobile node as a home agent, > the foreign agent rejects the Registration Request with code > TBD-IANA (Invalid Home Agent Address). > > New text in IANA Considerations: > In this revised specification, a new Code value (for the field in the > Registration Request message) is needed within the range typically > used for Foreign Agent messages. This error code is needed to > indicate the status "Invalid Home Agent Address". See section 3.7.2 > for details. This text, with the correction pointed out by Jayshree (s/Request/Reply) looks good to me. Regards, Henrik --Signature=_Mon__2_Feb_2004_19_37_46_+0100_YUbZx.m16wCCqaF+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAHpj6eVhrtTJkXCMRAidNAJ9thZp1p3OOaVLn1nSTDVQ+oXr2jwCgugud fcTC/lqaGNTz/SNq3SYRGOk= =aXy1 -----END PGP SIGNATURE----- --Signature=_Mon__2_Feb_2004_19_37_46_+0100_YUbZx.m16wCCqaF+-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 2 18:56:29 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24101 for ; Mon, 2 Feb 2004 18:56: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 1Annv9-0003Dj-8q for mip4-archive@odin.ietf.org; Mon, 02 Feb 2004 18:56:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i12Nu3Hn012380 for mip4-archive@odin.ietf.org; Mon, 2 Feb 2004 18: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 1Annv9-0003Db-2P for mip4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 18:56: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 SAA24019 for ; Mon, 2 Feb 2004 18:55:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Annv5-0000eS-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 18:56:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnnuB-0000Sm-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 18:55:04 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AnntY-0000Mi-02 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 18:54:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AnnnN-0000EG-45 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 18:48:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnnnN-0002Zo-0n; Mon, 02 Feb 2004 18:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnnnH-0002ZX-3B for mip4@optimus.ietf.org; Mon, 02 Feb 2004 18:47: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 SAA23692 for ; Mon, 2 Feb 2004 18:47:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnnnE-0007Xd-00 for mip4@ietf.org; Mon, 02 Feb 2004 18:47:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnnmG-0007Th-00 for mip4@ietf.org; Mon, 02 Feb 2004 18:46:52 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Annlz-0007Pm-00 for mip4@ietf.org; Mon, 02 Feb 2004 18:46:35 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i12NjwM23083; Mon, 2 Feb 2004 17:45:58 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i12NjrI17834; Mon, 2 Feb 2004 17:45:54 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HSHE08-0001W8-00; Mon, 02 Feb 2004 18:45:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16414.57643.587441.82950@gargle.gargle.HOWL> Date: Mon, 2 Feb 2004 17:45:47 -0600 From: Pete McCann To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: [Mip4] [Issue 20] Missing description - FA rejection code when MN-HA auth.ext.invalid In-Reply-To: <401834B5.B0438217@iprg.nokia.com> References: <401834B5.B0438217@iprg.nokia.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 re-read the issue and I don't understand what it is saying. I think it may have been mistakenly attributed to me or incorrectly transcribed. I think it is fine to reject this, barring a more cogent statement of the issue. Maybe it had something to do with the FA modifying rejection codes, interfering with the MN-HA authentication extension, which is the topic of the new draft you are working on. -Pete Charles E. Perkins writes: > > Hello folks, > > Please refer to previous discussion at the following URL: > http://www.mip4.org/issues/tracker/mip4/issue20 > as necessary. > > The suggestion was to mandate some action on the part of > a foreign agent if no MN-HA authentication extension is > present. Presumably, this really means, to reject in case > there is no authorization-enabling extension. But this > should anyway be a rare case, and there is little danger > since the home agent or other authorizing agent will > reject the Request. > > I propose that no action be taken, and that the > suggestion to change the specification be rejected. > > Comments? > > Regards, > Charlie P. > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 2 19:16:31 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25940 for ; Mon, 2 Feb 2004 19:16: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 1AnoEV-0006BZ-SU for mip4-archive@odin.ietf.org; Mon, 02 Feb 2004 19:16:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i130G3mb023771 for mip4-archive@odin.ietf.org; Mon, 2 Feb 2004 19:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnoEV-0006BK-OA for mip4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 19:16: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 TAA25880 for ; Mon, 2 Feb 2004 19:16:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnoEU-0003ri-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 19:16:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnoDU-0003jF-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 19:15:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnoCW-0003bE-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 19:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnoCX-0005sN-Gx; Mon, 02 Feb 2004 19:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnoBm-0005rj-Gh for mip4@optimus.ietf.org; Mon, 02 Feb 2004 19:13: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 TAA25685 for ; Mon, 2 Feb 2004 19:13:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnoBl-0003TW-00 for mip4@ietf.org; Mon, 02 Feb 2004 19:13:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnoAq-0003Km-00 for mip4@ietf.org; Mon, 02 Feb 2004 19:12:17 -0500 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 1AnoA6-00039l-00 for mip4@ietf.org; Mon, 02 Feb 2004 19:11:30 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id i130AGi03820; Mon, 2 Feb 2004 16:10:16 -0800 X-mProtect: <200402030010> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141100.americas.nokia.com (172.18.141.100, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwB1FdV; Mon, 02 Feb 2004 16:10:12 PST Message-ID: <401EE6DA.4030103@iprg.nokia.com> Date: Mon, 02 Feb 2004 16:10:02 -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: Pete McCann CC: mip4@ietf.org Subject: Re: [Mip4] [Issue 20] Missing description - FA rejection code when MN-HA auth.ext.invalid References: <401834B5.B0438217@iprg.nokia.com> <16414.57643.587441.82950@gargle.gargle.HOWL> In-Reply-To: <16414.57643.587441.82950@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hello Pete, There are two separate issues that could be discussed: - What happens if the FA _knows_ that the Registration Request is guaranteed to be rejected because there isn't any MN-HA extension? - What happens when the FA wants to insert an error code into a Registration Reply? The latter question should be answered by the FA error extension draft which is, I think, basically about done and ready to be disseminated as a new Internet Draft. Regards, Charlie P. Pete McCann wrote: >I re-read the issue and I don't understand what it is saying. I think >it may have been mistakenly attributed to me or incorrectly >transcribed. > >I think it is fine to reject this, barring a more cogent statement of >the issue. Maybe it had something to do with the FA modifying >rejection codes, interfering with the MN-HA authentication extension, >which is the topic of the new draft you are working on. > >-Pete > > >Charles E. Perkins writes: > > > > Hello folks, > > > > Please refer to previous discussion at the following URL: > > http://www.mip4.org/issues/tracker/mip4/issue20 > > as necessary. > > > > The suggestion was to mandate some action on the part of > > a foreign agent if no MN-HA authentication extension is > > present. Presumably, this really means, to reject in case > > there is no authorization-enabling extension. But this > > should anyway be a rare case, and there is little danger > > since the home agent or other authorizing agent will > > reject the Request. > > > > I propose that no action be taken, and that the > > suggestion to change the specification be rejected. > > > > Comments? > > > > Regards, > > Charlie P. > > > > -- > > Mip4 mailing list > > Mip4@ietf.org > > https://www.ietf.org/mailman/listinfo/mip4 > > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 2 19:18:30 2004 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26203 for ; Mon, 2 Feb 2004 19:18: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 1AnoGR-0006GW-MU for mip4-archive@odin.ietf.org; Mon, 02 Feb 2004 19:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i130I3i9024078 for mip4-archive@odin.ietf.org; Mon, 2 Feb 2004 19:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnoGR-0006GH-IU for mip4-web-archive@optimus.ietf.org; Mon, 02 Feb 2004 19:18: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 TAA26096 for ; Mon, 2 Feb 2004 19:18:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnoGQ-00048g-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 19:18:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnoFR-0003zW-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 19:17:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AnoES-0003ra-00 for mip4-web-archive@ietf.org; Mon, 02 Feb 2004 19:16:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AnoET-000681-RZ; Mon, 02 Feb 2004 19: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 1AnoDh-0005xh-Fo for mip4@optimus.ietf.org; Mon, 02 Feb 2004 19: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 TAA25857 for ; Mon, 2 Feb 2004 19:15:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AnoDg-0003l5-00 for mip4@ietf.org; Mon, 02 Feb 2004 19:15:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AnoCn-0003dr-00 for mip4@ietf.org; Mon, 02 Feb 2004 19:14:18 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AnoCB-0003T2-00 for mip4@ietf.org; Mon, 02 Feb 2004 19:13:39 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id i130D5J04972; Mon, 2 Feb 2004 18:13:05 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i130D3I03457; Mon, 2 Feb 2004 18:13:03 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HSHF9I-0001JO-00; Mon, 02 Feb 2004 19:12:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16414.59273.36441.23322@gargle.gargle.HOWL> Date: Mon, 2 Feb 2004 18:12:57 -0600 From: Pete McCann To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] [Issue 20] Missing description - FA rejection code when MN-HA auth.ext.invalid In-Reply-To: <401EE6DA.4030103@iprg.nokia.com> References: <401834B5.B0438217@iprg.nokia.com> <16414.57643.587441.82950@gargle.gargle.HOWL> <401EE6DA.4030103@iprg.nokia.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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, Charlie, Charles E. Perkins writes: > > Hello Pete, > > There are two separate issues that could be discussed: > > - What happens if the FA _knows_ that the Registration Request > is guaranteed to be rejected because there isn't any MN-HA > extension? I agree this aspect should be rejected. We should not have the FA checking extensions for which it is not responsible. > - What happens when the FA wants to insert an error code into > a Registration Reply? > > The latter question should be answered by the FA error extension > draft which is, I think, basically about done and ready to be > disseminated as a new Internet Draft. Yup. -Pete > Regards, > Charlie P. > > > Pete McCann wrote: > > >I re-read the issue and I don't understand what it is saying. I think > >it may have been mistakenly attributed to me or incorrectly > >transcribed. > > > >I think it is fine to reject this, barring a more cogent statement of > >the issue. Maybe it had something to do with the FA modifying > >rejection codes, interfering with the MN-HA authentication extension, > >which is the topic of the new draft you are working on. > > > >-Pete > > > > > >Charles E. Perkins writes: > > > > > > Hello folks, > > > > > > Please refer to previous discussion at the following URL: > > > http://www.mip4.org/issues/tracker/mip4/issue20 > > > as necessary. > > > > > > The suggestion was to mandate some action on the part of > > > a foreign agent if no MN-HA authentication extension is > > > present. Presumably, this really means, to reject in case > > > there is no authorization-enabling extension. But this > > > should anyway be a rare case, and there is little danger > > > since the home agent or other authorizing agent will > > > reject the Request. > > > > > > I propose that no action be taken, and that the > > > suggestion to change the specification be rejected. > > > > > > Comments? > > > > > > Regards, > > > Charlie P. > > > > > > -- > > > Mip4 mailing list > > > Mip4@ietf.org > > > https://www.ietf.org/mailman/listinfo/mip4 > > > > > > > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 3 14:49: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 OAA26920 for ; Tue, 3 Feb 2004 14:49:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6XI-0007sM-9a for mip4-archive@odin.ietf.org; Tue, 03 Feb 2004 14:48:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i13Jmeaq030270 for mip4-archive@odin.ietf.org; Tue, 3 Feb 2004 14:48:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6XH-0007s9-OU for mip4-web-archive@optimus.ietf.org; Tue, 03 Feb 2004 14:48: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 OAA26911 for ; Tue, 3 Feb 2004 14:48:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6XF-0003zt-00 for mip4-web-archive@ietf.org; Tue, 03 Feb 2004 14:48:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao6WL-0003uJ-00 for mip4-web-archive@ietf.org; Tue, 03 Feb 2004 14:47:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ao6Vf-0003om-00 for mip4-web-archive@ietf.org; Tue, 03 Feb 2004 14:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ao6Vg-0007n9-SI; Tue, 03 Feb 2004 14: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 1Ao5rb-0004fa-V2 for mip4@optimus.ietf.org; Tue, 03 Feb 2004 14:05: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 OAA24894 for ; Tue, 3 Feb 2004 14:05:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5rZ-0007Hv-00 for mip4@ietf.org; Tue, 03 Feb 2004 14:05:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ao5qf-0007Cl-00 for mip4@ietf.org; Tue, 03 Feb 2004 14:04:38 -0500 Received: from myra.general.services.metu.edu.tr ([144.122.144.147]) by ietf-mx with esmtp (Exim 4.12) id 1Ao5po-00077c-00; Tue, 03 Feb 2004 14:03:44 -0500 Received: from metu.edu.tr (pri1-41.metu.edu.tr [144.122.204.41]) by myra.general.services.metu.edu.tr (8.11.7/8.11.7) with ESMTP id i13J38q17855; Tue, 3 Feb 2004 21:03:09 +0200 (EET) Message-ID: <401FEFDA.8030309@metu.edu.tr> Date: Tue, 03 Feb 2004 21:00:42 +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: [Mip4] MedHocNet'04 Call for Papers Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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/ 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, HomeRF, 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/ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 4 15:17: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 PAA24241 for ; Wed, 4 Feb 2004 15:17:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTSf-0001YX-LX for mip4-archive@odin.ietf.org; Wed, 04 Feb 2004 15:17:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i14KHPHu005977 for mip4-archive@odin.ietf.org; Wed, 4 Feb 2004 15:17:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTSf-0001YK-G7 for mip4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 15:17: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 PAA24187 for ; Wed, 4 Feb 2004 15:17:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTSe-000798-00 for mip4-web-archive@ietf.org; Wed, 04 Feb 2004 15:17:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTRi-00074B-00 for mip4-web-archive@ietf.org; Wed, 04 Feb 2004 15:16:27 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoTRJ-0006zJ-00 for mip4-web-archive@ietf.org; Wed, 04 Feb 2004 15:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTRI-0001Aw-N0; Wed, 04 Feb 2004 15:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoTQf-000115-Tc for mip4@optimus.ietf.org; Wed, 04 Feb 2004 15:15: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 PAA23999 for ; Wed, 4 Feb 2004 15:15:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoTQe-0006yD-00 for mip4@ietf.org; Wed, 04 Feb 2004 15:15:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoTPl-0006td-00 for mip4@ietf.org; Wed, 04 Feb 2004 15:14:26 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1AoTP5-0006ji-00 for mip4@ietf.org; Wed, 04 Feb 2004 15:13:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EB5B.5121336C" Date: Wed, 4 Feb 2004 15:13:13 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816622@tatara.tatarasystems.com> Thread-Topic: dynamic assignment Thread-Index: AcPpwHKXgKq1L9eVQRe7dnOXI8soTwBl9xBA From: "Jeremy A. Greene" To: Subject: [Mip4] dynamic assignment Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EB5B.5121336C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From draft-ietf-mip4-dynamic-assignment-00.txt, I have a few questions. 1. Does the Requested HA do full auth or not? And if so, can/does the redirected HA (and ultimately Assigned HA) also do auth? a. Could permit separating the 'signaling' path from the data path. 2. The text below seems to be incorrect? The initial RRQ can be a subnet bcast? I gather this is referring to the bcast always being rejected w/ the ha addr field set to a unicast ha addr? 6. Requested Home Agent Selection=20 The destination IP address of the first Registration Request in=20 the Mobile IP session is the Requested HA. This address MUST=20 be a unicast IP address. =20 3. Below, the red text seems unnecessary since it's a unicast? No. Dest IP Addr HA field Processing at Assigned HA=20 -- ------------ ------------ -------------------------=20 1 Unicast Unicast RFC 3344: Normal HA processing=20 Same as Dest per RFC 3344.=20 IP addr =20 =20 Unicast RFC 3344: HA denies the=20 Different registration with error code=20 than Dest IP 136 and sets HA field to its=20 Addr own IP address in the reply as=20 per section 3.8.3.2.=20 =20 OR=20 =20 New Behavior: Dest IP=20 corresponds to the HA receiving=20 RRQ, if authentication is=20 successful, reject RRQ with a=20 new error code (REDIRECT-HA- REQ). HA puts its address in HA=20 address field of Reject. HA=20 suggests an alternate HA to use=20 in the new REDIRECTED-HA- ADDRESS extension. =20 Jeremy ------_=_NextPart_001_01C3EB5B.5121336C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From draft-ietf-mip4-dynamic-assignment-00.txt, I have a few = questions.

1.    Does the Requested HA do full auth or not? = And if so, can/does the redirected HA (and ultimately Assigned HA) also do = auth?

a.    Could permit separating the = ‘signaling’ path from the data path.

2.    The text below seems to be incorrect? The = initial RRQ can be a subnet bcast? I gather this is referring to the bcast = always being rejected w/ the ha addr field set to a unicast ha addr?

        =
6. Requested Home Agent Selection =

    &nbs=
p;      The destination IP address of the =
first Registration Request in 
    &nbs=
p;   the Mobile IP session is the Requested HA.  This address MUST =

        be a =
unicast IP address. 

3.    Below, the red text seems unnecessary since = it’s a unicast?

        No. Dest IP Addr  HA field     = Processing at Assigned HA

    &nbs= p;   --  ------------  ------------ ------------------------- =

    &nbs= p;   1   Unicast       = Unicast      RFC 3344: Normal HA processing

    &nbs= p;            = ;         Same as Dest per RFC 3344.

    &nbs= p;                &= nbsp;    IP addr      

    &nbs= p;            = ;            =           

    &nbs= p;            = ;         Unicast      RFC   3344:   HA   denies   the

    &nbs= p;            = ;         Different    registration  with  error  = code

    &nbs= p;            = ;         than Dest IP 136 and sets HA field to its

    &nbs= p;            = ;         Addr         own IP address in = the reply as

    &nbs= p;            = ;            =           per section 3.8.3.2.

    &nbs= p;            = ;            =           

    &nbs= p;            = ;            =             &= nbsp;           OR

    &nbs= p;            = ;            =            

    &nbs= p;            = ;            =            New    Behavior:    Dest    IP

   =             &= nbsp;           &n= bsp;            corresponds to the HA receiving

   =             &= nbsp;           &n= bsp;            RRQ,   if   authentication   = is

    &nbs= p;            = ;            =            successful, reject RRQ with a

    &nbs= p;            = ;            =            new  error  code  (REDIRECT-HA-

    &nbs= p;            = ;            =            REQ). HA puts its address in HA

    &nbs= p;            = ;            =            address  field  of  Reject.  HA =

    &nbs= p;            = ;            =            suggests an alternate HA to use

    &nbs= p;            = ;            =            in   the   new   = REDIRECTED-HA-

     =             &= nbsp;           &n= bsp;          ADDRESS extension.

 

=

Jeremy

------_=_NextPart_001_01C3EB5B.5121336C-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 4 20:25:06 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 UAA12243 for ; Wed, 4 Feb 2004 20:25: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 1AoYFx-00063m-I8 for mip4-archive@odin.ietf.org; Wed, 04 Feb 2004 20:24:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i151Objh023290 for mip4-archive@odin.ietf.org; Wed, 4 Feb 2004 20:24:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoYFx-00063Z-9v for mip4-web-archive@optimus.ietf.org; Wed, 04 Feb 2004 20:24: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 UAA12240 for ; Wed, 4 Feb 2004 20:24:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoYFv-0003Gb-00 for mip4-web-archive@ietf.org; Wed, 04 Feb 2004 20:24:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoYF1-0003Bm-00 for mip4-web-archive@ietf.org; Wed, 04 Feb 2004 20:23:40 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoYEP-00036I-00 for mip4-web-archive@ietf.org; Wed, 04 Feb 2004 20:23:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoYEP-0005xv-Cj; Wed, 04 Feb 2004 20:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoYDv-0005xE-NY for mip4@optimus.ietf.org; Wed, 04 Feb 2004 20:22: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 UAA12185 for ; Wed, 4 Feb 2004 20:22:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoYDt-00034e-00 for mip4@ietf.org; Wed, 04 Feb 2004 20:22:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoYCy-0002zb-00 for mip4@ietf.org; Wed, 04 Feb 2004 20:21:33 -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 1AoYC3-0002qL-00 for mip4@ietf.org; Wed, 04 Feb 2004 20:20:35 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2004 17:26:22 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i151K3fG020780; Wed, 4 Feb 2004 17:20:04 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn1-659.cisco.com [10.21.98.147]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id APZ46060; Wed, 4 Feb 2004 17:20:02 -0800 (PST) Message-Id: <4.3.2.7.2.20040204170357.02a2dd10@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 04 Feb 2004 17:20:01 -0800 To: "Jeremy A. Greene" From: Kent Leung Subject: Re: [Mip4] dynamic assignment Cc: In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816622@tatara.tatarasystem s.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_5005427==_.ALT" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_50_60, HTML_FONTCOLOR_RED,HTML_MESSAGE autolearn=no version=2.60 --=====================_5005427==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Jeremy. Thanks for your feedback. Comments below. At 03:13 PM 2/4/2004 -0500, Jeremy A. Greene wrote: > From draft-ietf-mip4-dynamic-assignment-00.txt, I have a few questions. > >1. Does the Requested HA do full auth or not? And if so, can/does the >redirected HA (and ultimately Assigned HA) also do auth? > >a. Could permit separating the signaling path from the data path. The HA that processes the RRQ does the authentication. For example, MN sends RRQ to HA1. HA1 authenticates RRQ and sends rejected RRP with alternative HA2. MN sends RRQ to HA2. HA2 authenticates RRQ and sends accepted RRP. >2. The text below seems to be incorrect? The initial RRQ can be a >subnet bcast? I gather this is referring to the bcast always being >rejected w/ the ha addr field set to a unicast ha addr? > > 6. Requested Home Agent Selection > The destination IP address of the first Registration Request in > the Mobile IP session is the Requested HA. This address MUST > be a unicast IP address. The reason that this address should not be subnet directed broadcast address is CERT Advisory CA-1998-01 as mentioned in the spec. Maybe we should change this to "This address SHOULD be a unicast IP address". >3. Below, the red text seems unnecessary since it s a unicast? > > No. Dest IP Addr HA field Processing at Assigned HA > > -- ------------ ------------ ------------------------- > > 1 Unicast Unicast RFC 3344: Normal HA processing > > Same as Dest per RFC 3344. > > IP addr > > > > Unicast RFC 3344: HA denies the > > Different registration with error code > > than Dest IP 136 and sets HA field to its > > Addr own IP address in the reply as > > per section 3.8.3.2. > > > > OR > > > > New Behavior: Dest IP > > corresponds to the HA receiving > > RRQ, if authentication is > > successful, reject RRQ with a > > new error code (REDIRECT-HA- > > REQ). HA puts its address in HA > > address field of Reject. HA > > suggests an alternate HA to use > > in the new REDIRECTED-HA- > > ADDRESS extension. > > So you're saying that this is implicit? The HA would not have received the RRQ if the destination IP address did not belong to that HA. Maybe better wording is "IP address in HA field is not HA's, ... reject ..."? Kent --=====================_5005427==_.ALT Content-Type: text/html; charset="us-ascii" Hi Jeremy.  Thanks for your feedback.  Comments below.

At 03:13 PM 2/4/2004 -0500, Jeremy A. Greene wrote:

From draft-ietf-mip4-dynamic-assignment-00.txt, I have a few questions.

1.    Does the Requested HA do full auth or not? And if so, can/does the redirected HA (and ultimately Assigned HA) also do auth?

a.    Could permit separating the signaling path from the data path.


The HA that processes the RRQ does the authentication.  For example, MN sends RRQ to HA1.
HA1 authenticates RRQ and sends rejected RRP with alternative HA2.  MN sends RRQ to HA2.
HA2 authenticates RRQ and sends accepted RRP.


2.    The text below seems to be incorrect? The initial RRQ can be a subnet bcast? I gather this is referring to the bcast always being rejected w/ the ha addr field set to a unicast ha addr?

       
6. Requested Home Agent Selection


          
The destination IP address of the first Registration Request in


       
the Mobile IP session is the Requested
HA.  This address
MUST 

       
be a unicast IP address. 


The reason that this address should not be subnet directed broadcast address is
CERT Advisory CA-1998-01 as mentioned in the spec.

Maybe we should change this to "This address SHOULD be a unicast IP address".


3.    Below, the red text seems unnecessary since it s a unicast?

        No. Dest IP Addr  HA field     Processing at Assigned HA

        --  ------------  ------------ -------------------------

        1   Unicast       Unicast      RFC 3344: Normal HA processing

                          Same as Dest per RFC 3344.

                          IP addr      

                                       

                          Unicast      RFC   3344:   HA   denies   the

                          Different    registration  with  error  code

                          than Dest IP 136 and sets HA field to its

                          Addr         own IP address in the reply as

                                       per section 3.8.3.2.

                                       

                                                     OR

                                        

                                        New    Behavior:    Dest    IP

                                        corresponds to the HA receiving

                                        RRQ,   if   authentication   is

                                        successful, reject RRQ with a

                                        new  error  code  (REDIRECT-HA-

                                        REQ). HA puts its address in HA

                                        address  field  of  Reject.  HA

                                        suggests an alternate HA to use

                                        in   the   new   REDIRECTED-HA-

                                        ADDRESS extension.

 


So you're saying that this is implicit?  The HA would not have received the
RRQ if the destination IP address did not belong to that HA.

Maybe better wording is "IP address in HA field is not HA's, ... reject ..."?

Kent
--=====================_5005427==_.ALT-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 5 08:41: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 IAA14951 for ; Thu, 5 Feb 2004 08:41: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 1AojkX-0003N6-IT for mip4-archive@odin.ietf.org; Thu, 05 Feb 2004 08:41:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15Dev1f012956 for mip4-archive@odin.ietf.org; Thu, 5 Feb 2004 08:40:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AojkX-0003Mt-85 for mip4-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 08:40: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 IAA14944 for ; Thu, 5 Feb 2004 08:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AojkV-0007Sa-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 08:40:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AojjY-0007N5-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 08:39:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aojif-0007Hy-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 08: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 1Aojie-0003I6-GA; Thu, 05 Feb 2004 08:39:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aojib-0003HA-BV for mip4@optimus.ietf.org; Thu, 05 Feb 2004 08:38: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 IAA14922 for ; Thu, 5 Feb 2004 08:38:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aojia-0007HZ-00 for mip4@ietf.org; Thu, 05 Feb 2004 08:38:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aojhc-0007Cp-00 for mip4@ietf.org; Thu, 05 Feb 2004 08:37:56 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Aojh2-00078K-00 for mip4@ietf.org; Thu, 05 Feb 2004 08:37:20 -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 1Aojh1-0001Cf-00; Thu, 05 Feb 2004 14:37:19 +0100 Date: Thu, 5 Feb 2004 14:36:55 +0100 From: Henrik Levkowetz To: mip4@ietf.org, Farid Adrangi Cc: mkulkarn@cisco.com, gdommety@cisco.com, egelasco@cisco.com, qzhang@liqwidnet.com, sami.vaarala@iki.fi, dorothy.gellert@nokia.com, nitsan@checkpoint.com, Pete McCann Message-Id: <20040205143655.4d9c3f43.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Missing Security Considerations in draft-ietf-mip4-vpn-problem-statement-00.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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've just done the writeup needed from the wg chairs to submit draft-ietf-mip4-vpn-problem-statement-00.txt to the ADs and IESG. As part of this writeup, I checked the draft for conformance to the ID-nits, . Unfortunately, there's 1 point of those listed here which the document does not conform to: it has no Security Considerations section. As this is a problem statement document, I don't expect such a section to be particularly lengthy, but we do require one. Farid, I believe you have the current source; could you propose text for such a section and get a new version out when we have an agreement on the text? Regards, Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 5 11:05: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 LAA21017 for ; Thu, 5 Feb 2004 11:05: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 1Aolzy-0006eg-LH for mip4-archive@odin.ietf.org; Thu, 05 Feb 2004 11:05:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15G52N2025581 for mip4-archive@odin.ietf.org; Thu, 5 Feb 2004 11:05:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aolzy-0006eS-D0 for mip4-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 11:05: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 LAA20996 for ; Thu, 5 Feb 2004 11:04:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aolzv-0006C0-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 11:04:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aolyw-000660-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 11:03:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aolxy-00060h-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 11:02:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aoly0-0006He-Nv; Thu, 05 Feb 2004 11:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AolOD-0002pZ-Ge for mip4@optimus.ietf.org; Thu, 05 Feb 2004 10:26: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 KAA19613 for ; Thu, 5 Feb 2004 10:25:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AolOB-0002W2-00 for mip4@ietf.org; Thu, 05 Feb 2004 10:25:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AolNG-0002RC-00 for mip4@ietf.org; Thu, 05 Feb 2004 10:25:03 -0500 Received: from markov.ece.neu.edu ([129.10.60.83] helo=SMTP1.ECE.NEU.EDU) by ietf-mx with esmtp (Exim 4.12) id 1AolMV-0002MM-00; Thu, 05 Feb 2004 10:24:15 -0500 Received: from calvin.ece.neu.edu (calvin.ece.neu.edu [129.10.62.61]) by SMTP1.ECE.NEU.EDU (8.12.5/8.12.5) with SMTP id i14NABNY023877; Wed, 4 Feb 2004 18:10:12 -0500 (EST) Received: from bibbiena.ece.neu.edu ([129.10.60.216]) by calvin.ece.neu.edu (SAVSMTP 3.1.0.29) with SMTP id M2004020418101226537 ; Wed, 04 Feb 2004 18:10:12 -0500 Received: from localhost (basagni@localhost) by bibbiena.ece.neu.edu (8.11.6+Sun/8.9.3) with ESMTP id i14NACa18135; Wed, 4 Feb 2004 18:10:12 -0500 (EST) X-Authentication-Warning: bibbiena.ece.neu.edu: basagni owned process doing -bs Date: Wed, 4 Feb 2004 18:10:12 -0500 (EST) From: Stefano Basagni X-X-Sender: basagni@bibbiena To: "Prof. Stefano Basagni" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [Mip4] MobiQuitous 04: Now accepting SUBMISSIONS Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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=LINES_OF_YELLING autolearn=no version=2.60 Dear Colleagues, please, find below the Call for Papers for MobiQuitous 04. PAPER REGISTRATION AND SUBMISSION ARE NOW OPEN via our electronic submission system (EDAS). See the conference web page for details. Notice that the paper submission deadline has been postponed to February 16 (with paper registration due by February 14). We *TRULY* apologize if you receive multiple copies of this Call for Papers. *********************************************************************** PRELIMINARY ANNOUNCEMENT and CALL FOR PAPERS MobiQuitous 2004 http://www.mobiquitous.org The First Annual International Conference on Mobile and Ubiquitous Systems: Networking and Services August 22-25, 2004 Boston, Massachusetts, USA Held in cooperation with AAAI Pending Sponsorhips: The IEEE Computer Society Technical Committee on Distributed Processing ACM SIGMOBILE *********************************************************************** The combination of mobile and ubiquitous computing is emerging as a promising new paradigm with the goal to provide computing and communication services all the time, everywhere, transparently and invisibly to the user, using devices embedded in the surrounding physical environment. In this context, the communication devices, the objects with which they interact, or both may be mobile. The implementation of such a paradigm requires advances in wireless network technologies and devices, development of infrastructures supporting cognitive environments, and discovery and identification of ubiquitous computing applications and services. The first ACM Annual International Conference on Mobile and Ubiquitous Systems: networking and services (Mobiquitous 04) will cover all these aspects, representing a forum where practitioners and researchers coming from the many areas involved in ubiquitous solutions design and deployment will be able to interact exchanging the cross-layer experiences needed to build the overall ubiquitous systems. Areas addressed by the conference include: applications, service-oriented computing, middleware, networking, agents, knowledge management and databases. PAPERS: Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. The conference is interested in contributions addressing all the areas associated with mobile and ubiquitous architectures, infrastructure and services. Technical works clearly identifying how the specific contributions fit to an overall working solution are particularly of interest. Topics include, but are not limited to, the following feature topics: * Ubiquitous architectures and systems * Wearable computing and personal area network * Wireless technologies for mobile and ubiquitous communications (Bluetooth, ZigBee, 802.15.x, WiFi) * Wireless Internet access in ubiquitous systems * Reconfigurability and personalization of wireless network * Service discovery mechanisms, knowledge discovery, matching and composition mechanisms * Wireless/mobile service management and delivery * Security, privacy and social issues of mobile and ubiquitous systems * Peer-to-peer knowledge management * Emerging industrial/business scenarios * Multimodal interfaces (speech, video kinetic, tactile) * Smart spaces * Ad hoc and sensor networking * Localization and tracking * Context and location aware application * Multimedia encoding and transcoding * Middleware services * Agent technologies in ubiquitous, wearable, and mobile systems * Hardware and software platforms for ubiquitous systems, and testbeds * User interfaces * Toolkits, development environments, and languages for ubiquitous computing * Ontologies for mobile and ubiquitous computing SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically (see the conference web page for details). Authors should prepare a Portable Document Format (PDF) or postscript version of their full paper. Papers must not exceed 8 pages double column (US Letter size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. PUBLICATION: All submitted papers will be rigorously reviewed by technical program committee members. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks journal. 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 Chair by March 1, 2004. DEMOS: Proposals for research and industrial demos are solicited. A maximum of 3 pages should be submitted which include a description of the demo and needed equipment. Proposals should be submitted to the Demo Chair by March 1, 2004 (responses will be given by April 30, 2004). *********************************************************************** IMPORTANT DATES *********************************************************************** Paper registration deadline: FEBRUARY 14 2004, 11:59pm PST Paper submission deadline: FEBRUARY 16 2004, 11:59pm PST Notification of acceptance: APRIL 30 2004 Camera-ready version due: MAY 15 2004 ********************************************************************** Papers submitted to MobiQuitous 2004 must be registered with EDAS by 11:59pm, PST, February 14, 2004. The deadline for submitting a registered paper is 11:59pm, PST, February 16, 2004. *** ORGANIZING COMMITTEE * General Co-Chairs Imrich Chlamtac University of Texas at Dallas, U.S.A. chlamtac@utdallas.edu Fausto Giunchiglia Universita` di Trento, Italy fausto@dit.unitn.it * General Vice Co-Chairs Michele Zorzi Universita` di Padova, Italy zorzi@dei.unipd.it Valentina Tamma University of Liverpool, U.K. valli@csc.liv.ac.uk * Program Co-Chairs * NETWORKING Tom La Porta Penn State University, U.S.A. tlp@cse.psu.edu Chiara Petrioli Universita` di Roma "La Sapienza," Italy petrioli@dsi.uniroma1.it * SERVICES Tim Finin Univ. of Maryland Baltimore County, U.S.A. finin@cs.umbc.edu Chiara Ghidini ITC-IRST, Trento, Italy ghidini@itc.it * Tutorial Chair Mani Srivastava Univ. of California Los Angeles, U.S.A. mbs@ucla.edu * Publicity Co-Chairs Stefano Basagni Northeastern University, U.S.A. Ilya Zaihrayeu Universita` di Trento, Italy * Registration Chair Robin Kravets Univ. of Illinois Urbana-Champaign, U.S.A. * Demo Chair Yannis Labrou Fujitsu Labs of America, U.S.A. yannis@fla.fujitsu.com * Local Arrangements Chair Prithwish Basu BBN Technologies, U.S.A. * Publication Chair Roger Whitaker Cardiff University, U.K. -- Stefano Basagni, Ph.D. Assistant Professor of Computer Engineering Dept. of Electrical and Computer Engineering 312 Dana Research Center Northeastern University 360 Huntington Ave. Boston, MA 02115 Tel. 617 373 3061, Fax 617 373 8970 E-mail: basagni@ece.neu.edu *** http://www.ece.neu.edu/faculty/basagni/ *** -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 5 12: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 MAA24098 for ; Thu, 5 Feb 2004 12: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 1Aomuv-0006TY-Lr for mip4-archive@odin.ietf.org; Thu, 05 Feb 2004 12:03:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15H3rdK024886 for mip4-archive@odin.ietf.org; Thu, 5 Feb 2004 12:03:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aomuv-0006Sc-DA for mip4-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 12:03: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 MAA23982 for ; Thu, 5 Feb 2004 12:03:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aomuu-0004sX-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 12:03:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AomtH-0004a3-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 12:02:12 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AomsN-0004TZ-01 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 12:01:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AomrL-00043c-Mh for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 12:00:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomrC-0005ff-5s; Thu, 05 Feb 2004 12:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AomqG-0005cQ-JH for mip4@optimus.ietf.org; Thu, 05 Feb 2004 11:59: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 LAA23850 for ; Thu, 5 Feb 2004 11:59:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AomqF-0004I6-00 for mip4@ietf.org; Thu, 05 Feb 2004 11:59:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AompL-0004D4-00 for mip4@ietf.org; Thu, 05 Feb 2004 11:58:08 -0500 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1Aomoo-00047P-00 for mip4@ietf.org; Thu, 05 Feb 2004 11:57:34 -0500 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-outer.mc,v 1.5 2003/11/26 00:10:29 root Exp $) with ESMTP id i15Gum09031564; Thu, 5 Feb 2004 16:56:48 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.12.9-20030918-01/8.12.9/d: large-inner.mc,v 1.9 2004/01/09 01:01:50 root Exp $) with SMTP id i15Gv7P3011464; Thu, 5 Feb 2004 16:57:41 GMT Received: from orsmsx331.amr.corp.intel.com ([192.168.65.56]) by orsmsxvs040.jf.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2004020508564205059 ; Thu, 05 Feb 2004 08:56:42 -0800 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 5 Feb 2004 08:56:42 -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.6487.1 Date: Thu, 5 Feb 2004 08:56:41 -0800 Message-ID: <96D13222E704DC4D868F0009F0EE53E1C4BD14@orsmsx410.jf.intel.com> Thread-Topic: Missing Security Considerations in draft-ietf-mip4-vpn-problem-statement-00.txt Thread-Index: AcPr7Tbm8CBqpG0dSo684HE+tqYZHQAG8WiA From: "Adrangi, Farid" To: "Henrik Levkowetz" , Cc: , , , , , , , "Pete McCann" X-OriginalArrivalTime: 05 Feb 2004 16:56:42.0024 (UTC) FILETIME=[07716A80:01C3EC09] X-Scanned-By: MIMEDefang 2.31 (www . roaringpenguin . com / mimedefang) Content-Transfer-Encoding: quoted-printable Subject: [Mip4] RE: Missing Security Considerations in draft-ietf-mip4-vpn-problem-statement-00.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Sure, will do. BR, Farid > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Thursday, February 05, 2004 5:37 AM > To: mip4@ietf.org; Adrangi, Farid > Cc: mkulkarn@cisco.com; gdommety@cisco.com;=20 > egelasco@cisco.com; qzhang@liqwidnet.com;=20 > sami.vaarala@iki.fi; dorothy.gellert@nokia.com;=20 > nitsan@checkpoint.com; Pete McCann > Subject: Missing Security Considerations in=20 > draft-ietf-mip4-vpn-problem-statement-00.txt >=20 >=20 > Hi, >=20 > I've just done the writeup needed from the wg chairs to=20 > submit draft-ietf-mip4-vpn-problem-statement-00.txt to the=20 > ADs and IESG. As part of this writeup, I checked the draft for conformance to the ID-> nits, . =20 >=20 > Unfortunately,=20 > there's 1 point of those listed here which the document does=20 > not conform to: it has no Security Considerations section. >=20 > As this is a problem statement document, I don't expect such=20 > a section to be particularly lengthy, but we do require one. =20 > Farid, I believe you have the current source; could you=20 > propose text for such a section and get a new version out=20 > when we have an agreement on the text? >=20 > Regards, > Henrik >=20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 5 15:46: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 PAA05578 for ; Thu, 5 Feb 2004 15:46: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 1AoqOG-0006xZ-Pc for mip4-archive@odin.ietf.org; Thu, 05 Feb 2004 15:46:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i15KkOk5026749 for mip4-archive@odin.ietf.org; Thu, 5 Feb 2004 15:46:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqOG-0006xM-Kc for mip4-web-archive@optimus.ietf.org; Thu, 05 Feb 2004 15:46: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 PAA05530 for ; Thu, 5 Feb 2004 15:46:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AoqOF-0004Nx-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 15:46:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AoqND-0004H1-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 15:45:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AoqMy-0004BA-00 for mip4-web-archive@ietf.org; Thu, 05 Feb 2004 15:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AoqMy-0006aF-K1; Thu, 05 Feb 2004 15: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 1AoqMX-0006Yg-NP for mip4@optimus.ietf.org; Thu, 05 Feb 2004 15:44:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05381; Thu, 5 Feb 2004 15:44:35 -0500 (EST) Message-Id: <200402052044.PAA05381@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 05 Feb 2004 15:44:35 -0500 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-aaa-key-03.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 IPv4 Working Group of the IETF. Title : AAA Registration Keys for Mobile IPv4 Author(s) : C. Perkins, P. Calhoun Filename : draft-ietf-mip4-aaa-key-03.txt Pages : 28 Date : 2004-2-5 AAA servers, such as RADIUS and DIAMETER, are in use within the Internet today to provide authentication and authorization services for dial-up computers. Mobile IP for IPv4 requires strong authentication between the mobile node and its home agent. When the mobile node shares an AAA Security Association with its home AAA server, however, it is possible to use that AAA Security Association to create derived Mobility Security Associations between the mobile node and its home agent, and again between the mobile node and the foreign agent currently offering connectivity to the mobile node. This document specifies extensions to Mobile IP registration messages that can be used to create Mobility Security Associations between the mobile node and its home agent, and/or between the mobile node and a foreign agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-aaa-key-03.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-mip4-aaa-key-03.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-mip4-aaa-key-03.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-5155332.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-aaa-key-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-aaa-key-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-5155332.I-D@ietf.org> --OtherAccess-- --NextPart-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 6 09:03: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 JAA26035 for ; Fri, 6 Feb 2004 09:03: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 1Ap6ZD-0007Ai-JF for mip4-archive@odin.ietf.org; Fri, 06 Feb 2004 09:02:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16E2lVX027564 for mip4-archive@odin.ietf.org; Fri, 6 Feb 2004 09:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6ZD-0007AV-FN for mip4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 09:02: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 JAA26013 for ; Fri, 6 Feb 2004 09:02:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6ZC-0006Mk-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 09:02:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap6YJ-0006J6-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 09:01:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6XU-0006FY-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 09:01:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6XU-00073v-B6; Fri, 06 Feb 2004 09:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap6XE-00073Q-Cq for mip4@optimus.ietf.org; Fri, 06 Feb 2004 09:00: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 JAA25988 for ; Fri, 6 Feb 2004 09:00:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap6XC-0006FE-00 for mip4@ietf.org; Fri, 06 Feb 2004 09:00:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap6WF-0006Bv-00 for mip4@ietf.org; Fri, 06 Feb 2004 08:59:44 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap6VU-00066g-00 for mip4@ietf.org; Fri, 06 Feb 2004 08:58:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ECB9.49F85FE8" Date: Fri, 6 Feb 2004 08:58:25 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC81666F@tatara.tatarasystems.com> Thread-Topic: vpn question Thread-Index: AcPsuVQ/61UW7+HlRZO0F/l5rObF1w== From: "Jeremy A. Greene" To: Subject: [Mip4] vpn question Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ECB9.49F85FE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Having read the vpn traversal draft, I'm left wondering (and amazed at the 6 tunnel, 129 byte overhead) as to why?! =20 The definition of 'home' network when talking about wireless seems a bit misplaced - there is no such thing as 'my' air space. =20 Granted, if I'm some oddball wandering around with my laptop, come into my office and connect to a lan, that it may be desirable to drop the vpn. But a) I don't think that's very real and b) it's probably a very good thing to have such a nomadic device always use a vpn. =20 The much more likely use of mip in the near term is for WAN and WiFi handoff - and in that case you need the vpn! =20 So, it seems that the premise of a) not wanting to keep my vpn up while in my 'home' network and b) not wanting data that comes in over a wireless connection to go through the dmz (and all related security functions) is not true. =20 In short, the easiest way to secure a wireless connection is to always be outside the firewall and vpn in. Given that, why bother with such a complex and super-high overhead solution?=20 =20 I also question the position that routers/vpns/firewalls/etc. are not likely to have an ha. Maybe true at the inception of mip, but that's a long, long time ago. =20 Jeremy =20 =20 =20 =20 =20 ------_=_NextPart_001_01C3ECB9.49F85FE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Having read the vpn traversal = draft, I’m left wondering (and amazed at the 6 tunnel, 129 byte overhead) = as to why?!

 

The definition of = ‘home’ network when talking about wireless seems a bit misplaced – there = is no such thing as ‘my’ air space.

 

Granted, if I’m some = oddball wandering = around with my laptop, come into my office and connect to a lan, that it may be = desirable to drop the vpn. But a) I don’t think that’s very real and b) = it’s probably a very good thing to have such a nomadic device always use a = vpn.

 

The much more likely use of mip in = the near term is for WAN and WiFi handoff – and in that case you need = the vpn!

 

So, it seems that the premise of a) = not wanting to keep my vpn up while in my ‘home’ network and b) = not wanting data that comes in over a wireless connection to go through the = dmz (and all related security functions) is not true.

 

In short, the easiest way to secure = a wireless connection is to always be outside the firewall and vpn in. = Given that, why bother with such a complex and super-high overhead solution? =

 

I also question the position that = routers/vpns/firewalls/etc. are not = likely to have an ha. Maybe true at the inception of mip, but that’s a long, = long time ago.

 

Jeremy

 

 

 

 

 

------_=_NextPart_001_01C3ECB9.49F85FE8-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 6 10:12: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 KAA29503 for ; Fri, 6 Feb 2004 10:12: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 1Ap7eD-0008En-Qx for mip4-archive@odin.ietf.org; Fri, 06 Feb 2004 10:12:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i16FC1HT031657 for mip4-archive@odin.ietf.org; Fri, 6 Feb 2004 10:12:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7eD-0008EU-LW for mip4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 10:12: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 KAA29433 for ; Fri, 6 Feb 2004 10:11:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7eB-0003Ed-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 10:11:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7dF-00039C-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 10:11:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7cH-00033j-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 10:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7cI-0007Uu-L8; Fri, 06 Feb 2004 10:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ap7c1-0007JA-LG for mip4@optimus.ietf.org; Fri, 06 Feb 2004 10: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 KAA29240 for ; Fri, 6 Feb 2004 10:09:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ap7bz-00030V-00 for mip4@ietf.org; Fri, 06 Feb 2004 10:09:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ap7b9-0002xE-00 for mip4@ietf.org; Fri, 06 Feb 2004 10:08:52 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Ap7aH-0002tT-00 for mip4@ietf.org; Fri, 06 Feb 2004 10:07:57 -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 1Ap7aL-0002Pn-00; Fri, 06 Feb 2004 16:08:01 +0100 Date: Fri, 6 Feb 2004 16:07:59 +0100 From: Henrik Levkowetz To: "Jeremy A. Greene" Cc: Subject: Re: [Mip4] vpn question Message-Id: <20040206160759.5056fd19.henrik@levkowetz.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC81666F@tatara.tatarasystems.com> References: <87ED4812394BA14980CC352C3A7483CC81666F@tatara.tatarasystems.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Jeremy, The only reaon why you would ever consider deploying the mechanisms in this draft is that you want to deploy mobile-ip, and you have a legacy VPN setup which you are totally unwilling to change. In other scenarios, you would be well adviced NOT to go through the contortions necessary - but real life experience shows that trying to roll out mobile-ip, one comes across exactly the situation described here. Friday 6 February 2004, Jeremy A. Greene wrote: > Having read the vpn traversal draft, I'm left wondering (and amazed at > the 6 tunnel, 129 byte overhead) as to why?! You refer to the 129 bytes as if they were the norm, when they are an unusual worst case. The normal case looks like this: The VPN accounts for 57 bytes without NAT travesal, 65 with. That is the baseline for VPNs. If you were to add Mobile-IP to this in a more regular setup than the one discussed here, it would add 20 bytes. If using NAT traversal, 32 bytes; but then you would not need NAT traversal for the VPN, so the expected MIP overhead would be at most 24 bytes. This gives a total of 89 bytes as the baseline for VPN + MIP. The extra contortions this draft uses would add another MIP tunnel, at the cost of 20 bytes. You will not reasonably expect to need NAT traversal for both the MIP tunnels, so it stays at 20 bytes; giving a net overhead compared to the baseline of _ 20 _ bytes for this solution. The expected overhead would thus be 109 bytes; where the VPN accounts for more than half (57), mobility accounts for 40, and NAT traversal accounts for 12. > The definition of 'home' network when talking about wireless seems a bit > misplaced - there is no such thing as 'my' air space. Home network is a concept orthogonal to wireless. It's where your permanent IP-address is topologically correct, or equivalently where you Home Agent is situated > Granted, if I'm some oddball wandering around with my laptop, come into > my office and connect to a lan, that it may be desirable to drop the > vpn. But a) I don't think that's very real and b) it's probably a very > good thing to have such a nomadic device always use a vpn. Your choice. The protocols doesn't force you to do it in one particular way. But some people want to get rid of the bandwidth limitations of having to go up to your VPN gateway and down again when they are in the office. > The much more likely use of mip in the near term is for WAN and WiFi > handoff - and in that case you need the vpn! Sure. > So, it seems that the premise of a) not wanting to keep my vpn up while > in my 'home' network and b) not wanting data that comes in over a > wireless connection to go through the dmz (and all related security > functions) is not true. Here we disagree. > In short, the easiest way to secure a wireless connection is to always > be outside the firewall and vpn in. Given that, why bother with such a > complex and super-high overhead solution? You shouldn't. You really shouldn't. But if the network admins won't change an existing VPN setup, but still want to roll out Mobile-IP, this is the proposed solution. If you have an alternative (and there _are_ other ways, which mostly require changes to IPsec) then do write it up! :-) > I also question the position that routers/vpns/firewalls/etc. are not > likely to have an ha. Maybe true at the inception of mip, but that's a > long, long time ago. It's still a reality for some of the deployment cases we (at ipUnplugged) come across today. Regards, Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 6 19:17: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 TAA01100 for ; Fri, 6 Feb 2004 19:17: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 1ApG9e-0001cb-K7 for mip4-archive@odin.ietf.org; Fri, 06 Feb 2004 19:17:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i170H2dA006229 for mip4-archive@odin.ietf.org; Fri, 6 Feb 2004 19: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 1ApG9e-0001cO-C4 for mip4-web-archive@optimus.ietf.org; Fri, 06 Feb 2004 19:17: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 TAA01084 for ; Fri, 6 Feb 2004 19:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApG9c-0006x1-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 19:17:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApG8f-0006u2-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 19:16:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ApG7k-0006rA-00 for mip4-web-archive@ietf.org; Fri, 06 Feb 2004 19:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApG7i-0001XR-MS; Fri, 06 Feb 2004 19:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ApAKY-0007Ut-B8 for mip4@optimus.ietf.org; Fri, 06 Feb 2004 13:03: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 NAA07467 for ; Fri, 6 Feb 2004 13:03:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ApAKW-0007Ib-00 for mip4@ietf.org; Fri, 06 Feb 2004 13:03:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ApAJf-0007Fh-00 for mip4@ietf.org; Fri, 06 Feb 2004 13:03:00 -0500 Received: from dcs-server2.cs.uiuc.edu ([128.174.252.3]) by ietf-mx with esmtp (Exim 4.12) id 1ApAIq-0007CB-00 for mip4@ietf.org; Fri, 06 Feb 2004 13:02:08 -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 i16I28ZP001310 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Fri, 6 Feb 2004 12:02:08 -0600 (CST) From: "Robin Kravets" To: Date: Fri, 6 Feb 2004 12:04:07 -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 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Mip4] ACM MobiCom 2004 CFP Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 9 09:41: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 JAA21277 for ; Mon, 9 Feb 2004 09:41:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCau-0006L9-79 for mip4-archive@odin.ietf.org; Mon, 09 Feb 2004 09:41:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19Ef4D0024367 for mip4-archive@odin.ietf.org; Mon, 9 Feb 2004 09: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 1AqCat-0006Kw-Vz for mip4-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 09:41: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 JAA21242 for ; Mon, 9 Feb 2004 09:41:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCas-0004SM-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 09:41:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCZt-0004N7-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 09:40:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqCYu-0004Gy-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 09:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqCYv-00064w-HO; Mon, 09 Feb 2004 09: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 1AqCY3-00062v-1N for mip4@optimus.ietf.org; Mon, 09 Feb 2004 09:38: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 JAA21174 for ; Mon, 9 Feb 2004 09:38:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqCY1-0004Dx-00 for mip4@ietf.org; Mon, 09 Feb 2004 09:38:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqCX3-00049d-00 for mip4@ietf.org; Mon, 09 Feb 2004 09:37:05 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AqCWC-00041R-00 for mip4@ietf.org; Mon, 09 Feb 2004 09:36:12 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i19EZcqJ026687; Mon, 9 Feb 2004 15:35:38 +0100 Date: Mon, 9 Feb 2004 15:35:40 +0100 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann Message-Id: <20040209153540.08b06367.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__9_Feb_2004_15_35_40_+0100_mqYinQbCa/OjP+Op" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Mon__9_Feb_2004_15_35_40_+0100_mqYinQbCa/OjP+Op Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit SECOND REQUEST - To date, no response to this WG last call has been received. If enough responses are not received to support the acceptance of this document, it *will not* be submitted to the IESG for publication. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. -------- This message announces a WG last call on "Mobile IPv4 Dynamic Home Agent Assignment" . The last call will conclude at 24:00 UTC on Friday, 13th Feb 2004. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechanism for dynamic home agent assignment and HA redirection. The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection. This draft is available as Regards, Henrik --Signature=_Mon__9_Feb_2004_15_35_40_+0100_mqYinQbCa/OjP+Op Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAJ5q8eVhrtTJkXCMRAvhaAKCBbvZuNs6MhtKnGE13HDYzAGtUgwCfSuqp rPH95/wWRJGUhV2yg4gKQqM= =iGt2 -----END PGP SIGNATURE----- --Signature=_Mon__9_Feb_2004_15_35_40_+0100_mqYinQbCa/OjP+Op-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 9 17:10:47 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 RAA21066 for ; Mon, 9 Feb 2004 17:10:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJbg-0000Nf-AH for mip4-archive@odin.ietf.org; Mon, 09 Feb 2004 17:10:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19MAKVx001457 for mip4-archive@odin.ietf.org; Mon, 9 Feb 2004 17:10:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJbg-0000NQ-2C for mip4-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 17:10: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 RAA20986 for ; Mon, 9 Feb 2004 17:10:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJbd-0004ln-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 17:10:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJaU-0004YA-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 17:09:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqJZS-0004LG-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 17: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 1AqJZS-00007b-LF; Mon, 09 Feb 2004 17:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqJYn-0008MF-OH for mip4@optimus.ietf.org; Mon, 09 Feb 2004 17:07: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 RAA20502 for ; Mon, 9 Feb 2004 17:07:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqJYl-0004CY-00 for mip4@ietf.org; Mon, 09 Feb 2004 17:07:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqJXZ-0003xP-00 for mip4@ietf.org; Mon, 09 Feb 2004 17:06:06 -0500 Received: from smtp-2.hut.fi ([130.233.228.92] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AqJWQ-0003i5-00 for mip4@ietf.org; Mon, 09 Feb 2004 17:04:54 -0500 Received: from maldini.hut.fi (maldini-m.hut.fi [130.233.228.122]) by smtp-2.hut.fi (8.12.10/8.12.10) with ESMTP id i19M4ri9001525 for ; Tue, 10 Feb 2004 00:04:53 +0200 Received: (from apache@localhost) by maldini.hut.fi (8.12.10/8.12.6/Submit) id i19M4rKN015549 for mip4@ietf.org; Tue, 10 Feb 2004 00:04:53 +0200 To: mip4@ietf.org Message-ID: <1076364293.4028040544897@webmail2.hut.fi> Date: Tue, 10 Feb 2004 00:04:53 +0200 (EET) From: sami.vaarala@iki.fi MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: HUT webmail, IMP 2.2.6 X-Authenticated-Sender: svaarala@cc.hut.fi X-Originating-IP: 82.133.140.89 X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-2.hut.fi) Content-Transfer-Encoding: 8bit Subject: [Mip4] MIPv4 implementation (Netseal) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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.9 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Please add the following regarding Netseal's MIPv4 implementation: IP: 4 Operating Systems: Windows, Linux Name: Netseal MPN License: Commercial Comments: High availability HA (Linux), MN (Windows) Best regards, -Sami -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 9 17:42:13 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 RAA24719 for ; Mon, 9 Feb 2004 17:42: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 1AqK66-0002d9-U5 for mip4-archive@odin.ietf.org; Mon, 09 Feb 2004 17:41:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i19MfksV010105 for mip4-archive@odin.ietf.org; Mon, 9 Feb 2004 17:41:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqK66-0002cu-Nw for mip4-web-archive@optimus.ietf.org; Mon, 09 Feb 2004 17:41: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 RAA24686 for ; Mon, 9 Feb 2004 17:41:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqK64-0001ol-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 17:41:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqK4m-0001Wm-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 17:40:25 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AqK3V-0001Jg-00 for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 17:39:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AqK3W-0002E2-1c for mip4-web-archive@ietf.org; Mon, 09 Feb 2004 17:39:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqK3R-0002XH-Np; Mon, 09 Feb 2004 17: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 1AqK2x-0002Vz-98 for mip4@optimus.ietf.org; Mon, 09 Feb 2004 17:38: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 RAA24444 for ; Mon, 9 Feb 2004 17:38:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqK2u-0001Gx-00 for mip4@ietf.org; Mon, 09 Feb 2004 17:38:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqK1z-0001BH-00 for mip4@ietf.org; Mon, 09 Feb 2004 17:37:31 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AqK1X-00015j-00 for mip4@ietf.org; Mon, 09 Feb 2004 17:37:03 -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 1AqK1U-00020D-00; Mon, 09 Feb 2004 23:37:00 +0100 Date: Mon, 9 Feb 2004 23:36:54 +0100 From: Henrik Levkowetz To: sami.vaarala@iki.fi Cc: mip4@ietf.org Subject: Re: [Mip4] MIPv4 implementation (Netseal) Message-Id: <20040209233654.47304924.henrik@levkowetz.com> In-Reply-To: <1076364293.4028040544897@webmail2.hut.fi> References: <1076364293.4028040544897@webmail2.hut.fi> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Tuesday 10 February 2004, sami.vaarala@iki.fi wrote: > IP: 4 > Operating Systems: Windows, Linux > Name: Netseal MPN > License: Commercial > Comments: High availability HA (Linux), MN (Windows) Yup, it's on the list now :-) Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 07:50:26 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 HAA14515 for ; Tue, 10 Feb 2004 07:50:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXKv-0000PG-Bv for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 07:49:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ACnvbm001562 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 07:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXKv-0000P7-7j for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 07:49: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 HAA14484 for ; Tue, 10 Feb 2004 07:49:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqXKu-0002YX-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 07:49:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqXJt-0002RX-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 07:48:54 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqXJ2-0002Lr-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 07:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXJ2-0000Hd-Uy; Tue, 10 Feb 2004 07:48:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqXIw-0000HM-Fz for mip4@optimus.ietf.org; Tue, 10 Feb 2004 07: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 HAA14460 for ; Tue, 10 Feb 2004 07:47:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqXIv-0002Ka-00 for mip4@ietf.org; Tue, 10 Feb 2004 07:47:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqXI3-0002El-00 for mip4@ietf.org; Tue, 10 Feb 2004 07:46:59 -0500 Received: from smtp-4.hut.fi ([130.233.228.94] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AqXH7-00028N-00 for mip4@ietf.org; Tue, 10 Feb 2004 07:46:02 -0500 Received: from maldini.hut.fi (maldini-m.hut.fi [130.233.228.122]) by smtp-4.hut.fi (8.12.10/8.12.10) with ESMTP id i1ACk0TO011078 for ; Tue, 10 Feb 2004 14:46:00 +0200 Received: (from apache@localhost) by maldini.hut.fi (8.12.10/8.12.6/Submit) id i1ACk0Sw031340 for mip4@ietf.org; Tue, 10 Feb 2004 14:46:00 +0200 To: mip4@ietf.org Message-ID: <1076417160.4028d288af997@webmail2.hut.fi> Date: Tue, 10 Feb 2004 14:46:00 +0200 (EET) From: sami.vaarala@iki.fi MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: HUT webmail, IMP 2.2.6 X-Authenticated-Sender: svaarala@cc.hut.fi X-Originating-IP: 213.173.159.46 X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-4.hut.fi) Content-Transfer-Encoding: 8bit Subject: [Mip4] draft-vaarala-mip4-optudp-00 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Here's a small strawman draft regarding MIPv4 overhead optimization: http://www.ietf.org/internet-drafts/draft-vaarala-mip4-optudp-00.txt The draft applies when the MN sends most of its traffic to *one* particular CN, in which case overhead to that particular CN can be optimized. The mechanism applies at least to the case where MIPv4 provides mobility for IPsec tunneling - e.g. the normal IPsec-over-MIPv4 situation. It might also apply to some VoIP scenarios. Has anyone else been working on overhead optimizations? I'm sure all vendors have heard of the "overhead issue" :-) The abstract of the draft is as follows: This document specifies an extension to Mobile IPv4 UDP encapsulation (RFC 3519) which enables optimization of overhead when UDP encapsulation is used, and most of the mobile node's data traffic is destined to one particular correspondent node. Any feedback appreciated, -Sami -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 08:43: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 IAA18220 for ; Tue, 10 Feb 2004 08:43: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 1AqYAB-0003zZ-Tm for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 08:42:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ADgtWL015339 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 08:42:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYAB-0003zK-Oj for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 08:42: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 IAA18206 for ; Tue, 10 Feb 2004 08:42:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYAA-0001Hi-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 08:42:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqY9L-0001Au-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 08:42:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqY8N-00010W-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 08:41:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqY8N-0003oi-Ed; Tue, 10 Feb 2004 08:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqY8H-0003o4-L6 for mip4@optimus.ietf.org; Tue, 10 Feb 2004 08:40: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 IAA17982 for ; Tue, 10 Feb 2004 08:40:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqY8G-0000zc-00 for mip4@ietf.org; Tue, 10 Feb 2004 08:40:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqY7J-0000nH-00 for mip4@ietf.org; Tue, 10 Feb 2004 08:39:58 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AqY6g-0000fe-00 for mip4@ietf.org; Tue, 10 Feb 2004 08:39:18 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1ADcjqJ012960; Tue, 10 Feb 2004 14:38:45 +0100 Date: Tue, 10 Feb 2004 14:38:45 +0100 From: Henrik Levkowetz To: sami.vaarala@iki.fi Cc: mip4@ietf.org Subject: Re: [Mip4] draft-vaarala-mip4-optudp-00 Message-Id: <20040210143845.27fe3fde.henrik@levkowetz.com> In-Reply-To: <1076417160.4028d288af997@webmail2.hut.fi> References: <1076417160.4028d288af997@webmail2.hut.fi> 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__10_Feb_2004_14_38_45_+0100_5immD=4Gr1RFHtSw" X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Tue__10_Feb_2004_14_38_45_+0100_5immD=4Gr1RFHtSw Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Sami, On Tuesday, 10 Feb 2004, sami.vaarala@iki.fi wrote: > Here's a small strawman draft regarding MIPv4 overhead optimization: > > http://www.ietf.org/internet-drafts/draft-vaarala-mip4-optudp-00.txt > > The draft applies when the MN sends most of its traffic to > *one* particular CN, in which case overhead to that particular > CN can be optimized. The mechanism applies at least to the > case where MIPv4 provides mobility for IPsec tunneling - > e.g. the normal IPsec-over-MIPv4 situation. It might also > apply to some VoIP scenarios. Quite interesting, and still straightforward. Comments after a swift read-through: In section 2.3, Optimized UDP Tunnel Reply Extension, I think it would be good to have an explicit flag to indicate acceptance or rejection of optimized tunnelling, rather than letting presence/ absence of the extension itself indicate this. To support legacy HAs you still need to handle absence as a no to optimization, though. Having an explicit flag is 1) cleaner, and 2) if there in the future would be more than one optimization possibilities, it would be nice if a HA could indicate that Yes, it understands optimization, but No, it won't accept the particular one proposed in the RRQ. In section 5, Security Considerations, it is not immediately obvious to me what you mean when you say the "inner" IPv4 header can be easily tampered with - in the optimized case there is no inner IPv4 header, no? In section 6, Alternatives, New message type - I don't see any benefit from this Multiple preferred CNs - possible, but should maybe be left as a later exercise, once there is some experience with this implementation? In that case, an index into a list of CNs would be more appropriate than a set of bits, though. FA support - Mixed feelings. It's needed in order to be a complete solution, at the same time as FA deployment seems to be negligible. Best, Henrik --Signature=_Tue__10_Feb_2004_14_38_45_+0100_5immD=4Gr1RFHtSw Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAKN7leVhrtTJkXCMRAnlEAKDz33RQHMtZg7VPfeAs9sYiDuly/ACdHmEf z1aZDYVqov6GnCE3lZns2Hg= =2l2m -----END PGP SIGNATURE----- --Signature=_Tue__10_Feb_2004_14_38_45_+0100_5immD=4Gr1RFHtSw-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 09:21: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 JAA19429 for ; Tue, 10 Feb 2004 09:21: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 1AqYl3-0005zB-SQ for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 09:21:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AEL12d022980 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 09: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 1AqYl2-0005yZ-3M for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 09:21: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 JAA19414 for ; Tue, 10 Feb 2004 09:20:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYl0-0004aE-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 09:20:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYk6-0004Tt-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 09:20:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqYj7-0004N0-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 09:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqYj7-0005q6-PM; Tue, 10 Feb 2004 09: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 1AqYj2-0005pb-O4 for mip4@optimus.ietf.org; Tue, 10 Feb 2004 09:18: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 JAA19307 for ; Tue, 10 Feb 2004 09:18:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqYj1-0004MD-00 for mip4@ietf.org; Tue, 10 Feb 2004 09:18:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqYi8-0004Gy-00 for mip4@ietf.org; Tue, 10 Feb 2004 09:18:01 -0500 Received: from nuoli.com ([212.182.218.5]) by ietf-mx with smtp (Exim 4.12) id 1AqYhU-00046B-00 for mip4@ietf.org; Tue, 10 Feb 2004 09:17:20 -0500 Received: (qmail 32054 invoked by uid 89); 10 Feb 2004 14:13:56 -0000 Message-ID: <20040210141356.32051.qmail@nuoli.com> References: <1076417160.4028d288af997@webmail2.hut.fi> <20040210143845.27fe3fde.henrik@levkowetz.com> In-Reply-To: <20040210143845.27fe3fde.henrik@levkowetz.com> From: sami.vaarala@iki.fi To: Henrik Levkowetz Cc: sami.vaarala@iki.fi, mip4@ietf.org Date: Tue, 10 Feb 2004 16:13:56 +0200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: draft-vaarala-mip4-optudp-00 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, > In section 2.3, Optimized UDP Tunnel Reply Extension, I think it would > be good to have an explicit flag to indicate acceptance or rejection of > [...] > optimization possibilities, it would be nice if a HA could indicate that > Yes, it understands optimization, but No, it won't accept the particular > one proposed in the RRQ. I agree. So we'd either need to have (a) a flags field (perhaps in both RRQ and RRP extensions) or (b) a reply code field. We added a reply code in the NAT reply, but only needed a single error code after all. Which do you prefer? (I'd rather go with the flag.) > In section 5, Security Considerations, it is not immediately obvious to > me what you mean when you say the "inner" IPv4 header can be easily > tampered with - in the optimized case there is no inner IPv4 header, no? Right, that's just bad wording. The intent is to say that in normal MIPv4 one can easily tamper with the inner header, i.e. the one which results after decapsulation. Similarly here, by tampering with the "outer" (the only) IP header, you can tamper with the "inner" header, i.e. the one resulting after decapsulation. Best, -Sami -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 10:03: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 KAA20814 for ; Tue, 10 Feb 2004 10:03: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 1AqZPc-00026e-9O for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 10:02:56 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AF2uHw008094 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 10:02:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZPc-00026N-1p for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 10:02: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 KAA20765 for ; Tue, 10 Feb 2004 10:02:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZPZ-0000To-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 10:02:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZOc-0000Oa-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 10:01:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqZNl-0000JW-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 10:01:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZNl-0000U9-8W; Tue, 10 Feb 2004 10:01:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqZMo-0008Ms-Od for mip4@optimus.ietf.org; Tue, 10 Feb 2004 10:00: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 JAA20678 for ; Tue, 10 Feb 2004 09:59:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqZMm-0000E5-00 for mip4@ietf.org; Tue, 10 Feb 2004 10:00:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqZLv-00008Z-00 for mip4@ietf.org; Tue, 10 Feb 2004 09:59:08 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AqZL2-0007kJ-00 for mip4@ietf.org; Tue, 10 Feb 2004 09:58:12 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1AEveqJ014555; Tue, 10 Feb 2004 15:57:40 +0100 Date: Tue, 10 Feb 2004 15:57:41 +0100 From: Henrik Levkowetz To: sami.vaarala@iki.fi Cc: sami.vaarala@iki.fi, mip4@ietf.org Message-Id: <20040210155741.1d956a67.henrik@levkowetz.com> In-Reply-To: <20040210141356.32051.qmail@nuoli.com> References: <1076417160.4028d288af997@webmail2.hut.fi> <20040210143845.27fe3fde.henrik@levkowetz.com> <20040210141356.32051.qmail@nuoli.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__10_Feb_2004_15_57_41_+0100_dvBUSiGGuvX.oM7." X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] Re: draft-vaarala-mip4-optudp-00 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Tue__10_Feb_2004_15_57_41_+0100_dvBUSiGGuvX.oM7. Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Sami, On Tuesday, 10 Feb 2004, sami.vaarala@iki.fi wrote: > > In section 2.3, Optimized UDP Tunnel Reply Extension, I think it would > > be good to have an explicit flag to indicate acceptance or rejection of > > [...] > > optimization possibilities, it would be nice if a HA could indicate that > > Yes, it understands optimization, but No, it won't accept the particular > > one proposed in the RRQ. > > I agree. So we'd either need to have (a) a flags field (perhaps in > both RRQ and RRP extensions) or (b) a reply code field. We added a > reply code in the NAT reply, but only needed a single error code after > all. Which do you prefer? (I'd rather go with the flag.) In this case I think I'd go with a flag, too. > > In section 5, Security Considerations, it is not immediately obvious to > > me what you mean when you say the "inner" IPv4 header can be easily > > tampered with - in the optimized case there is no inner IPv4 header, no? > > Right, that's just bad wording. The intent is to say that in normal > MIPv4 one can easily tamper with the inner header, i.e. the one which > results after decapsulation. Yes. > Similarly here, by tampering with the > "outer" (the only) IP header, you can tamper with the "inner" header, > i.e. the one resulting after decapsulation. Yes, but actually to a slightly lesser extent - the expanded inner header source and destination can't be tampered with, nor can protocol, while you're right for most of the other fields (length, tos, id, flags, ttl). No? Henrik Henrik -- Those are my principles. If you don't like them, I have others. -- Groucho Marx --Signature=_Tue__10_Feb_2004_15_57_41_+0100_dvBUSiGGuvX.oM7. Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAKPFleVhrtTJkXCMRAgHDAKCXyvso5+UHshg6G9YwZBnRXsZYqQCeI5GP 9uog9PUlKmvDPQPr7HwcW3w= =7KWI -----END PGP SIGNATURE----- --Signature=_Tue__10_Feb_2004_15_57_41_+0100_dvBUSiGGuvX.oM7.-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 12:53: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 MAA00139 for ; Tue, 10 Feb 2004 12:53: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 1Aqc4A-0003G0-A2 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 12:52:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AHqws0012517 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 12:52:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqc49-0003Fo-W7 for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 12:52: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 MAA00113 for ; Tue, 10 Feb 2004 12:52:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqc48-0003V5-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 12:52:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqc3F-0003Q8-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 12:52:02 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqc2J-0003LQ-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 12:51:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqc2L-0003uA-D9 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 12:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqc2H-0003Bd-3u; Tue, 10 Feb 2004 12:51:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqc2E-0003BM-H3 for mip4@optimus.ietf.org; Tue, 10 Feb 2004 12:50: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 MAA00065 for ; Tue, 10 Feb 2004 12:50:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqc2C-0003KM-00 for mip4@ietf.org; Tue, 10 Feb 2004 12:50:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqc1H-0003G5-00 for mip4@ietf.org; Tue, 10 Feb 2004 12:50:00 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqc0o-0003At-00 for mip4@ietf.org; Tue, 10 Feb 2004 12:49:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3EFFE.2975A1D4" Date: Tue, 10 Feb 2004 12:48:59 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC8166E8@tatara.tatarasystems.com> Thread-Topic: radius mip? Thread-Index: AcPv/jhMvuwvC2NaSfKbkc1pTWYz8w== From: "Jeremy A. Greene" To: , Subject: [Mip4] radius mip? Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3EFFE.2975A1D4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In looking at general aaa support for mip (2977) and the mip4-aaa-key-03 draft, I am still not clear if there is any radius support for either SA information distributed to the HA, or dynamic key distribution to both the HA and MN. =20 It seems that at least cisco uses radius to distribute SAs to HAs. And they may even do dynamic keying using radius. But I can't find any drafts or rfcs - not that it would be surprising that cisco did something proprietary. Or calling what is really diameter, radius.=20 =20 Jeremy =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C3EFFE.2975A1D4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In looking at general aaa support = for mip (2977) and the mip4-aaa-key-03 draft, I am still not clear if there is any = radius support for either SA information distributed to the HA, or dynamic key = distribution to both the HA and MN.

 

It seems that at least cisco uses = radius to distribute SAs to HAs. And they may even do dynamic keying using = radius. But I can’t find any drafts or rfcs – not that it would be = surprising that cisco did something proprietary. Or call= ing what is reall= y diameter, radius.

 

Jeremy

 

 

 

 

 

 

 

 

 

------_=_NextPart_001_01C3EFFE.2975A1D4-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 13:26:26 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 NAA01217 for ; Tue, 10 Feb 2004 13:26:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqca7-0005pp-Pe for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 13:25:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AIPxsl022423 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 13: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 1Aqca7-0005pa-Jz for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 13: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 NAA01178 for ; Tue, 10 Feb 2004 13:25:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqca5-0006WZ-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 13:25:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcZ7-0006QH-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 13:24:58 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqcYB-0006Ji-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 13:23:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqcYC-0005eK-Pa; Tue, 10 Feb 2004 13: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 1AqcXD-0005Xe-RY for mip4@optimus.ietf.org; Tue, 10 Feb 2004 13:23: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 NAA01104 for ; Tue, 10 Feb 2004 13:22:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqcXB-0006Ch-00 for mip4@ietf.org; Tue, 10 Feb 2004 13:22:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqcWF-00067E-00 for mip4@ietf.org; Tue, 10 Feb 2004 13:22:00 -0500 Received: from syd-iport-1.cisco.com ([64.104.193.196]) by ietf-mx with esmtp (Exim 4.12) id 1AqcVL-0005wC-00 for mip4@ietf.org; Tue, 10 Feb 2004 13:21:03 -0500 Received: from syd-core-1.cisco.com (64.104.193.198) by syd-iport-1.cisco.com with ESMTP; 10 Feb 2004 10:25:32 +0000 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by syd-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1ALJe3K028384; Wed, 11 Feb 2004 05:19:41 +0800 (WST) Received: from cisco.com (dhcp-128-107-163-52.cisco.com [128.107.163.52]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQD73412; Tue, 10 Feb 2004 10:20:22 -0800 (PST) Message-ID: <402920E6.9040002@cisco.com> Date: Tue, 10 Feb 2004 10:20:22 -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: Mip4 issue tracker CC: mip4@ietf.org References: <20040126224932.6dd9a0f5.henrik@levkowetz.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [issue43] draft-ietf-mip4-experimental-messages Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Henrik - Regarding this issue if we should define experimental subtypes for existing option types, our position is that this is not needed. The definition of experimental options permits the usage of experimental subtypes. Also, reserving experimental subtypes for existing options may not be a good idea as some implementations may already be using unallocated numbers (past experience). Our opinion is that we should move forward by closing this issue. Thanks Alpesh Henrik Levkowetz wrote: >This comment from Henrik Levkowetz has been added to issue 43: > >draft: draft-ietf-mip4-experimental-messages -> draft-ietf-mip4-experimental-messages > >We would like to move forward with draft-ietf-mip4-experimental-messages. > >There is currently one open issue, reflected here: > > > >The possible positions seems to be either of: > * "Yes, add experimental sub-type number" > * "No, do not add experimental sub-type number" > >I'd like to get a little bit more feedback from the list on this issue, >please comment on this, indicating your preference. > > Henrik >_________________________________________________ >Mip4 issue tracker > >_________________________________________________ > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 17:18: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 RAA24685 for ; Tue, 10 Feb 2004 17:18: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 1AqgCm-0008RP-GK for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 17:18:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMI8Zm032443 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 17:18:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgCm-0008RC-BX for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:18: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 RAA24659 for ; Tue, 10 Feb 2004 17:18:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgCk-0006zK-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:18:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgBm-0006sc-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:17:07 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgAn-0006k3-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:16:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgAl-0007tv-KI; Tue, 10 Feb 2004 17:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgAN-0007rw-EE for mip4@optimus.ietf.org; Tue, 10 Feb 2004 17:15: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 RAA24406 for ; Tue, 10 Feb 2004 17:15:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgAL-0006cy-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:15:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqg9O-0006S2-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:14:38 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqg89-00064r-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:13:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F023.05F94650" Date: Tue, 10 Feb 2004 17:12:51 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC8166FD@tatara.tatarasystems.com> Thread-Topic: dynamic keys Thread-Index: AcPwIxTdhx83mZF7RMOrbssqEkfOXQ== From: "Jeremy A. Greene" To: , Subject: [Mip4] dynamic keys Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_60_70, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F023.05F94650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires the use of a single, widely used (by all MNs??), long term pre-shared key between the MN and AAAH. Since this key is directly used to calculate dynamic keys, this does not seem terrible secure. =20 Am I missing something? =20 Jeremy =20 =20 ------_=_NextPart_001_01C3F023.05F94650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the mip4-aaa-key-03 draft (and = aaa-diameter-mobileip-16) it requires the use of a single, widely used (by all MNs??), long = term pre-shared key between the MN and AAAH. Since this key is directly used = to calculate dynamic keys, this does not seem terrible secure.

 

Am I missing = something?

 

Jeremy

 

 

------_=_NextPart_001_01C3F023.05F94650-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 17:42: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 RAA26941 for ; Tue, 10 Feb 2004 17:42: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 1Aqga9-00028l-NC for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 17:42:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMgHPK008221 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 17:42:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqga9-00028W-IL for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:42: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 RAA26936 for ; Tue, 10 Feb 2004 17:42:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqga7-0002gd-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:42:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgZF-0002bP-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:41:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgYv-0002Ux-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17: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 1AqgYx-00024d-Az; Tue, 10 Feb 2004 17:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgYL-00022e-9U for mip4@optimus.ietf.org; Tue, 10 Feb 2004 17:40: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 RAA26816 for ; Tue, 10 Feb 2004 17:40:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqgYI-0002U9-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:40:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqgXR-0002Np-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:39:30 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AqgWx-0002H5-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:38:59 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AMcQ307866; Tue, 10 Feb 2004 16:38:26 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.174.248]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i1AMcOW20457; Tue, 10 Feb 2004 16:38:24 -0600 (CST) Message-ID: <40295D5B.6070905@lucent.com> Date: Tue, 10 Feb 2004 16:38:19 -0600 From: Tom Hiller Organization: Lucent Technologies 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 CC: aaa-wg@merit.edu, mip4@ietf.org References: <87ED4812394BA14980CC352C3A7483CC8166E8@tatara.tatarasystems.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC8166E8@tatara.tatarasystems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auemail2.firewall.lucent.com id i1AMcQ307866 Content-Transfer-Encoding: quoted-printable Subject: [Mip4] Re: [AAA-WG]: radius mip? Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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: quoted-printable Content-Transfer-Encoding: quoted-printable Jeremy, mip4-aaa-key-03 distributes nonces to the mobile. The mobile uses the nonces to derive session keys, such as MN-HA key. The draft does not=20 deal with delivering session keys to the HA (or FA). draft-ietf-aaa-diameter-mobileip-16.txt deals with delivering keys to=20 the HA (and FA), but it only applies to Diameter. ----- 3GPP2 has text in its packet data standard ("Wireless IP Network=20 Standard") for the HA to obtain the MN-HA key from the home RADIUS=20 server. The text defines a RADIUS VSA to carry the MN-HA key, and=20 what's in the RADIUS Access-Request and Access-Accept, for example. -Tom Jeremy A. Greene wrote: > In looking at general aaa support for mip (2977) and the mip4-aaa-key-0= 3=20 > draft, I am still not clear if there is any radius support for either S= A=20 > information distributed to the HA, or dynamic key distribution to both=20 > the HA and MN. >=20 > =20 >=20 > It seems that at least cisco uses radius to distribute SAs to HAs. And=20 > they may even do dynamic keying using radius. But I can=92t find any=20 > drafts or rfcs =96 not that it would be surprising that cisco did=20 > something proprietary. Or calling what is really diameter, radius. >=20 > =20 >=20 > Jeremy >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =09 >=20 > =20 >=20 > =20 >=20 > =09 >=20 > =20 >=20 > =20 >=20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 17:47: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 RAA27142 for ; Tue, 10 Feb 2004 17:47:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgex-0002Y2-MT for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 17:47:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMlFjm009788 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 17:47:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgex-0002Xn-FO for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:47: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 RAA27091 for ; Tue, 10 Feb 2004 17:47:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgeu-00037S-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:47:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqge3-00031t-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:46:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgdk-0002wE-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgdm-0002GI-Pv; Tue, 10 Feb 2004 17:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgcv-0002CN-Gx for mip4@optimus.ietf.org; Tue, 10 Feb 2004 17:45: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 RAA27001 for ; Tue, 10 Feb 2004 17:45:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgcs-0002uj-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:45:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgbv-0002qE-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:44:08 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqgb4-0002hH-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:43:14 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1AMge309568; Tue, 10 Feb 2004 16:42:40 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.174.248]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i1AMgdW25173; Tue, 10 Feb 2004 16:42:39 -0600 (CST) Message-ID: <40295E5E.4090600@lucent.com> Date: Tue, 10 Feb 2004 16:42:38 -0600 From: Tom Hiller Organization: Lucent Technologies 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 CC: mip4@ietf.org, aaa-wg@merit.edu References: <87ED4812394BA14980CC352C3A7483CC8166FD@tatara.tatarasystems.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC8166FD@tatara.tatarasystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [AAA-WG]: dynamic keys Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Jeremy, The aaa-keys draft says that the long held secret should be periodically refreshed, but does not say how. - Tom Jeremy A. Greene wrote: > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires > the use of a single, widely used (by all MNs??), long term pre-shared > key between the MN and AAAH. Since this key is directly used to > calculate dynamic keys, this does not seem terrible secure. > > > > Am I missing something? > > > > Jeremy > > > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 17:54: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 RAA27580 for ; Tue, 10 Feb 2004 17:54: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 1Aqgll-0002zJ-Rn for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 17:54:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1AMsHA4011479 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 17:54:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqgll-0002z4-Mp for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 17:54: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 RAA27576 for ; Tue, 10 Feb 2004 17:54:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqglj-00045L-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:54:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgkm-0003zd-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:53:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqgkV-0003u3-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 17:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqgkX-0002sX-2r; Tue, 10 Feb 2004 17: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 1Aqgjo-0002oA-Sm for mip4@optimus.ietf.org; Tue, 10 Feb 2004 17:52: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 RAA27501 for ; Tue, 10 Feb 2004 17:52:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqgjm-0003sK-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:52:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqgis-0003k3-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:51:19 -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 1Aqgi4-0003Tx-00 for mip4@ietf.org; Tue, 10 Feb 2004 17:50:28 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1AMnuu5020375; Tue, 10 Feb 2004 14:49:57 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-171-71-203-28.cisco.com [171.71.203.28]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQE05489; Tue, 10 Feb 2004 14:49:54 -0800 (PST) Message-Id: <4.3.2.7.2.20040210144430.03a2e160@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Feb 2004 14:49:53 -0800 To: "Jeremy A. Greene" From: Kent Leung Subject: Re: [Mip4] radius mip? Cc: , In-Reply-To: <87ED4812394BA14980CC352C3A7483CC8166E8@tatara.tatarasystem s.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_69912809==_.ALT" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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.5 required=5.0 tests=AWL,HTML_30_40, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.60 --=====================_69912809==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Cisco uses RADIUS Vendor-Specific Attribute (Type 26) to download the SA from AAA server to HA for MN authentication. CDMA2000's IS-835 also uses RADIUS Vendor-Specific Attribute as well. Kent At 12:48 PM 2/10/2004 -0500, Jeremy A. Greene wrote: >In looking at general aaa support for mip (2977) and the mip4-aaa-key-03 >draft, I am still not clear if there is any radius support for either SA >information distributed to the HA, or dynamic key distribution to both the >HA and MN. > > > >It seems that at least cisco uses radius to distribute SAs to HAs. And >they may even do dynamic keying using radius. But I can t find any drafts >or rfcs not that it would be surprising that cisco did something >proprietary. Or calling what is really diameter, radius. > > > >Jeremy > > > > > > > > > > > > > > > > > > --=====================_69912809==_.ALT Content-Type: text/html; charset="us-ascii"
Cisco uses RADIUS Vendor-Specific Attribute (Type 26) to download the SA
from AAA server to HA for MN authentication.

CDMA2000's IS-835 also uses RADIUS Vendor-Specific Attribute as well.

Kent


At 12:48 PM 2/10/2004 -0500, Jeremy A. Greene wrote:

In looking at general aaa support for mip (2977) and the mip4-aaa-key-03 draft, I am still not clear if there is any radius support for either SA information distributed to the HA, or dynamic key distribution to both the HA and MN.

 

It seems that at least cisco uses radius to distribute SAs to HAs. And they may even do dynamic keying using radius. But I can t find any drafts or rfcs not that it would be surprising that cisco did something proprietary. Or calling what is really diameter, radius.

 

Jeremy

 

 

 

 

 

 

 

 

 
--=====================_69912809==_.ALT-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 18:13:47 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 SAA28976 for ; Tue, 10 Feb 2004 18:13:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh4D-0000TY-CO for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 18:13:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ANDL01001822 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 18:13:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh4D-0000TJ-7C for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 18:13: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 SAA28925 for ; Tue, 10 Feb 2004 18:13:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh4A-0005vn-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 18:13:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqh39-0005qn-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 18:12:16 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh2u-0005lX-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 18:12:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh2w-0008Qt-5n; Tue, 10 Feb 2004 18:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh2B-00089D-Ou for mip4@optimus.ietf.org; Tue, 10 Feb 2004 18:11: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 SAA28746 for ; Tue, 10 Feb 2004 18:11:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh28-0005kV-00 for mip4@ietf.org; Tue, 10 Feb 2004 18:11:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqh1E-0005eo-00 for mip4@ietf.org; Tue, 10 Feb 2004 18:10:17 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqh0U-0005UB-00 for mip4@ietf.org; Tue, 10 Feb 2004 18:09:30 -0500 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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Feb 2004 18:09:00 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC8166FE@tatara.tatarasystems.com> Thread-Topic: [AAA-WG]: dynamic keys Thread-Index: AcPwJz5FhjyFzgnRQ7WMGF/VxzGqGwAAasRQ From: "Jeremy A. Greene" To: "Tom Hiller" Cc: , Content-Transfer-Encoding: quoted-printable Subject: [Mip4] RE: [AAA-WG]: dynamic keys Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 So, a disgruntled, recently dismissed employee still having the aaah key could eavesdrop on a wireless connection to get the nonce and compute the session keys pretty easily, I would think (since the vpn has to come up after the mip session). In general, this seems like a very insecure solution -- why bother going to all the work to make dynamic keys if it's so easy to get them anyway? Jeremy -----Original Message----- From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of Tom Hiller Sent: Tuesday, February 10, 2004 5:43 PM Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [AAA-WG]: dynamic keys Jeremy, The aaa-keys draft says that the long held secret should be periodically refreshed, but does not say how. - Tom Jeremy A. Greene wrote: > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires=20 > the use of a single, widely used (by all MNs??), long term pre-shared=20 > key between the MN and AAAH. Since this key is directly used to=20 > calculate dynamic keys, this does not seem terrible secure. >=20 > =20 >=20 > Am I missing something? >=20 > =20 >=20 > Jeremy >=20 > =20 >=20 > =20 >=20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 18:18: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 SAA29547 for ; Tue, 10 Feb 2004 18:18: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 1Aqh8v-00020y-Fv for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 18:18:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ANIDhD007730 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 18:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh8v-00020I-9c for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 18:18: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 SAA29501 for ; Tue, 10 Feb 2004 18:18:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh8s-0006O2-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 18:18:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqh7y-0006J7-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 18:17:15 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh7j-0006Dx-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 18:16:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh7l-0001ew-QN; Tue, 10 Feb 2004 18:17:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqh7C-0001WC-Dm for mip4@optimus.ietf.org; Tue, 10 Feb 2004 18:16: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 SAA29328 for ; Tue, 10 Feb 2004 18:16:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqh79-0006D5-00 for mip4@ietf.org; Tue, 10 Feb 2004 18:16:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqh6H-000675-00 for mip4@ietf.org; Tue, 10 Feb 2004 18:15:30 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqh5S-00060S-00 for mip4@ietf.org; Tue, 10 Feb 2004 18:14:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F02B.958FE000" Subject: RE: [Mip4] radius mip? Date: Tue, 10 Feb 2004 18:14:08 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC8166FF@tatara.tatarasystems.com> Thread-Topic: [Mip4] radius mip? Thread-Index: AcPwKDYweLmGfh6/TqaswD4iq7NlXAAAwTVQ From: "Jeremy A. Greene" To: "Kent Leung" Cc: , Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_50_60, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F02B.958FE000 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks - as it turns out I managed to find this in cisco's docs. They embed their tacacs+ avps into the radius attribute 26. So that answers the downloading of SAs to HAs. Although I haven't been able to find how they do dynamic key distribution (not that it really matters, since I don't think it's done much anyway, and it seems quite insecure to boot). =20 Jeremy =20 -----Original Message----- From: Kent Leung [mailto:kleung@cisco.com]=20 Sent: Tuesday, February 10, 2004 5:50 PM To: Jeremy A. Greene Cc: aaa-wg@merit.edu; mip4@ietf.org Subject: Re: [Mip4] radius mip? =20 Cisco uses RADIUS Vendor-Specific Attribute (Type 26) to download the SA from AAA server to HA for MN authentication. CDMA2000's IS-835 also uses RADIUS Vendor-Specific Attribute as well. Kent At 12:48 PM 2/10/2004 -0500, Jeremy A. Greene wrote: In looking at general aaa support for mip (2977) and the mip4-aaa-key-03 draft, I am still not clear if there is any radius support for either SA information distributed to the HA, or dynamic key distribution to both the HA and MN. =20 It seems that at least cisco uses radius to distribute SAs to HAs. And they may even do dynamic keying using radius. But I can t find any drafts or rfcs not that it would be surprising that cisco did something proprietary. Or calling what is really diameter, radius.=20 =20 Jeremy =20 =20 =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C3F02B.958FE000 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks – as it turns out I = managed to find this in cisco’s docs. They embed their tacacs+ avps into = the radius attribute 26. So that answers the downloading of SAs to HAs. Although I = haven’t been able to find how they do dynamic key distribution (not that it = really matters, since = I don’t think it’s done much anyway, and it seems quite insecure to = boot).

 

Jeremy

 

-----Original = Message-----
From: Kent Leung [mailto:kleung@cisco.com]
Sent: Tuesday, February = 10, 2004 5:50 PM
To: Jeremy A. Greene
Cc: aaa-wg@merit.edu; mip4@ietf.org
Subject: Re: [Mip4] = radius mip?

 


Cisco uses RADIUS Vendor-Specific Attribute (Type 26) to download the = SA
from AAA server to HA for MN authentication.

CDMA2000's IS-835 also uses RADIUS Vendor-Specific Attribute as = well.

Kent


At 12:48 PM 2/10/2004 -0500, Jeremy A. Greene wrote:


In looking at = general aaa support for mip (2977) and the mip4-aaa-key-03 draft, I am still not = clear if there is any radius support for either SA information distributed to the = HA, or dynamic key distribution to both the HA and MN.

 

It seems that at least cisco uses radius to distribute = SAs to HAs. And they may even do dynamic keying using radius. But I can t find = any drafts or rfcs not that it would be surprising that cisco did something proprietary. Or calling what is really diameter, radius.

 

Jeremy

 

 

 

 

 

 

 

 

 

------_=_NextPart_001_01C3F02B.958FE000-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 19:04:48 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 TAA01115 for ; Tue, 10 Feb 2004 19:04: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 1Aqhra-0005wP-QN for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 19:04:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B04Mla022831 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 19:04:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqhra-0005w7-JQ for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 19:04: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 TAA01097 for ; Tue, 10 Feb 2004 19:04:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqhrX-0002v9-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 19:04:19 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqhqX-0002oR-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 19:03:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqhqF-0002iu-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 19:02:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhqG-0005iO-Tr; Tue, 10 Feb 2004 19:03:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqhpU-0005hU-1l for mip4@optimus.ietf.org; Tue, 10 Feb 2004 19:02:12 -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 TAA01041 for ; Tue, 10 Feb 2004 19:02:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqhpQ-0002gS-00 for mip4@ietf.org; Tue, 10 Feb 2004 19:02:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqhoS-0002a5-00 for mip4@ietf.org; Tue, 10 Feb 2004 19:01:08 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AqhnS-0002QR-00 for mip4@ietf.org; Tue, 10 Feb 2004 19:00:06 -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 1AqhnL-0002nP-00; Wed, 11 Feb 2004 00:59:59 +0100 Date: Wed, 11 Feb 2004 00:59:57 +0100 From: Henrik Levkowetz To: "Jeremy A. Greene" Cc: , Subject: Re: [Mip4] dynamic keys Message-Id: <20040211005957.6f999f52.henrik@levkowetz.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC8166FD@tatara.tatarasystems.com> References: <87ED4812394BA14980CC352C3A7483CC8166FD@tatara.tatarasystems.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Jeremy, Tuesday 10 February 2004, Jeremy A. Greene wrote: > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires > the use of a single, widely used (by all MNs??), long term pre-shared > key between the MN and AAAH. Since this key is directly used to > calculate dynamic keys, this does not seem terrible secure. I see no reason why the preshared key between MN and AAAH should be the same for all MNs, rather than individual per-MN? Or is it I who have missed something? Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 19:39: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 TAA04706 for ; Tue, 10 Feb 2004 19:39: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 1AqiOk-0008OO-CW for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 19:38:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B0cc70032254 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 19:38:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiOk-0008O9-62 for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 19:38: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 TAA04650 for ; Tue, 10 Feb 2004 19:38:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqiOi-0000nm-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 19:38:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqiNX-0000Yz-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 19:37:24 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqiMG-0000F6-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 19:36:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiMF-0007yl-A2; Tue, 10 Feb 2004 19:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqiM3-0007y2-5Z for mip4@optimus.ietf.org; Tue, 10 Feb 2004 19:35: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 TAA04277 for ; Tue, 10 Feb 2004 19:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqiM1-0000CY-00 for mip4@ietf.org; Tue, 10 Feb 2004 19:35:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqiKo-0007mb-00 for mip4@ietf.org; Tue, 10 Feb 2004 19:34:35 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AqiK1-0007e5-00 for mip4@ietf.org; Tue, 10 Feb 2004 19:33:45 -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 1AqiJz-0002po-00; Wed, 11 Feb 2004 01:33:43 +0100 Date: Wed, 11 Feb 2004 01:33:42 +0100 From: Henrik Levkowetz To: "Jeremy A. Greene" Cc: , Subject: Re: [Mip4] dynamic keys Message-Id: <20040211013342.097db155.henrik@levkowetz.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816700@tatara.tatarasystems.com> References: <87ED4812394BA14980CC352C3A7483CC816700@tatara.tatarasystems.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=_Wed__11_Feb_2004_01_33_42_+0100_BxqkrZzS9UQAYMjl" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__11_Feb_2004_01_33_42_+0100_BxqkrZzS9UQAYMjl Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Jeremy, Tuesday 10 February 2004, Jeremy A. Greene wrote: > So, it doesn't make the initial deployment any easier (if there's one > HA), just ongoing use more secure. Each MN needs to be manually > configured in some manually intensive secure manner and/or use a > proprietary mechanism. > > I guess I was looking more for a standardized server-side-only (aaa) > configuration solution. More like the web, using server-side cert and > client-side username/pw (over ssl). But this is the same difference. If you can distribute username/passwd individually to users, you have your initial deployment shared secret, no? Henrik --Signature=_Wed__11_Feb_2004_01_33_42_+0100_BxqkrZzS9UQAYMjl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKXhmeVhrtTJkXCMRAsVRAKDHWb+TmEN+seW15JhItYCnU9rp9wCg6m+x RdfHJwWh7Q3blY0afSUzwkk= =ynIr -----END PGP SIGNATURE----- --Signature=_Wed__11_Feb_2004_01_33_42_+0100_BxqkrZzS9UQAYMjl-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 20:02: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 UAA07806 for ; Tue, 10 Feb 2004 20:02: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 1Aqill-0002AH-34 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 20:02:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B12Psh008315 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 20:02:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aqilk-0002A2-Nk for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 20:02: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 UAA07731 for ; Tue, 10 Feb 2004 20:02:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aqili-0005H7-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 20:02:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqikb-00052e-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 20:01:13 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqijZ-0004lq-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 20:00:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqijX-0001mx-Op; Tue, 10 Feb 2004 20:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqijJ-0001kc-Pj for mip4@optimus.ietf.org; Tue, 10 Feb 2004 19:59: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 TAA07432 for ; Tue, 10 Feb 2004 19:59:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqijH-0004j9-00 for mip4@ietf.org; Tue, 10 Feb 2004 19:59:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aqihi-0004Ij-00 for mip4@ietf.org; Tue, 10 Feb 2004 19:58:15 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqiey-0003aw-03 for mip4@ietf.org; Tue, 10 Feb 2004 19:55:24 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by mx2.foretec.com with esmtp (Exim 4.24) id 1Aqi6T-0004pN-5S for mip4@ietf.org; Tue, 10 Feb 2004 19:19:45 -0500 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] dynamic keys Date: Tue, 10 Feb 2004 19:19:11 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816700@tatara.tatarasystems.com> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPwMf6Bv31+Or2lS4m+mScmR6lahAAACzcg From: "Jeremy A. Greene" To: "Henrik Levkowetz" Cc: , Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 So, it doesn't make the initial deployment any easier (if there's one HA), just ongoing use more secure. Each MN needs to be manually configured in some manually intensive secure manner and/or use a proprietary mechanism. I guess I was looking more for a standardized server-side-only (aaa) configuration solution. More like the web, using server-side cert and client-side username/pw (over ssl). Jeremy -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Tuesday, February 10, 2004 7:00 PM To: Jeremy A. Greene Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys Hi Jeremy, Tuesday 10 February 2004, Jeremy A. Greene wrote: > In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it requires > the use of a single, widely used (by all MNs??), long term pre-shared > key between the MN and AAAH. Since this key is directly used to > calculate dynamic keys, this does not seem terrible secure. I see no reason why the preshared key between MN and AAAH should be the same for all MNs, rather than individual per-MN? Or is it I who have missed something? Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 10 21:48: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 VAA13980 for ; Tue, 10 Feb 2004 21:48: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 1AqkQJ-0002hQ-BG for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 21:48:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1B2mN2E010372 for mip4-archive@odin.ietf.org; Tue, 10 Feb 2004 21:48:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkQJ-0002hA-68 for mip4-web-archive@optimus.ietf.org; Tue, 10 Feb 2004 21:48: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 VAA13949 for ; Tue, 10 Feb 2004 21:48:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkQG-0003Bi-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 21:48:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqkPN-00036L-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 21:47:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqkOx-00030N-00 for mip4-web-archive@ietf.org; Tue, 10 Feb 2004 21:46:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqkOz-0002Z8-0o; Tue, 10 Feb 2004 21: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 1AqkOT-0002WF-Po for mip4@optimus.ietf.org; Tue, 10 Feb 2004 21:46: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 VAA13861 for ; Tue, 10 Feb 2004 21:46:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqkOQ-0002zP-00 for mip4@ietf.org; Tue, 10 Feb 2004 21:46:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqkNd-0002sq-00 for mip4@ietf.org; Tue, 10 Feb 2004 21:45:38 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1AqkMd-0002fO-00 for mip4@ietf.org; Tue, 10 Feb 2004 21:44:35 -0500 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] dynamic keys Date: Tue, 10 Feb 2004 21:44:05 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816701@tatara.tatarasystems.com> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPwNrUg1E8Mj+b/Tg20yMV8/CHqVgAEZLeQ From: "Jeremy A. Greene" To: "Henrik Levkowetz" Cc: , Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Username/pw can be tied to their existing ones (like existing aaa pw or through MS domain etc.). And username/pws tend to be easier to remember and update. And a md5 key is not the easiest thing to remember or type in. Anyway, it seems that it's a more traditional approach that people have already dealt with in one way or another. This seems like another thing to deal with. Jeremy -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Tuesday, February 10, 2004 7:34 PM To: Jeremy A. Greene Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys Hi Jeremy, Tuesday 10 February 2004, Jeremy A. Greene wrote: > So, it doesn't make the initial deployment any easier (if there's one > HA), just ongoing use more secure. Each MN needs to be manually > configured in some manually intensive secure manner and/or use a > proprietary mechanism. >=20 > I guess I was looking more for a standardized server-side-only (aaa) > configuration solution. More like the web, using server-side cert and > client-side username/pw (over ssl). But this is the same difference. If you can distribute username/passwd individually to users, you have your initial deployment shared secret, no? Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 11 05:10:13 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 FAA25429 for ; Wed, 11 Feb 2004 05:10: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 1AqrJR-0006n1-49 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 05:09:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BA9iiP026015 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 05:09:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqrJJ-0006lF-PD for mip4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 05:09: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 FAA25403 for ; Wed, 11 Feb 2004 05:09:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqrJG-0000oY-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 05:09:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqrIL-0000iO-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 05:08:38 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqrHk-0000cW-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 05:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqrHm-0006Z9-CE; Wed, 11 Feb 2004 05:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqrHM-0006XL-1A for mip4@optimus.ietf.org; Wed, 11 Feb 2004 05:07: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 FAA25347 for ; Wed, 11 Feb 2004 05:07:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqrHI-0000bj-00 for mip4@ietf.org; Wed, 11 Feb 2004 05:07:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqrGU-0000Wq-00 for mip4@ietf.org; Wed, 11 Feb 2004 05:06:42 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AqrG4-0000RT-00 for mip4@ietf.org; Wed, 11 Feb 2004 05:06:16 -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 1AqrG1-00038r-00; Wed, 11 Feb 2004 11:06:13 +0100 Date: Wed, 11 Feb 2004 11:06:12 +0100 From: Henrik Levkowetz To: "Jeremy A. Greene" Cc: , Subject: Re: [Mip4] dynamic keys Message-Id: <20040211110612.58c1b648.henrik@levkowetz.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816701@tatara.tatarasystems.com> References: <87ED4812394BA14980CC352C3A7483CC816701@tatara.tatarasystems.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=_Wed__11_Feb_2004_11_06_12_+0100_/xljPidYQNycIS8o" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__11_Feb_2004_11_06_12_+0100_/xljPidYQNycIS8o Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Tuesday 10 February 2004, Jeremy A. Greene wrote: > Username/pw can be tied to their existing ones (like existing aaa pw > or through MS domain etc.). And username/pws tend to be easier to > remember and update. And a md5 key is not the easiest thing to > remember or type in. Anyway, it seems that it's a more traditional > approach that people have already dealt with in one way or another. > This seems like another thing to deal with. I see no reason why a one-time username/password (or a pre-existing one, if it is deemed strong enough), cannot be run through a hash function to give you your initial AAAH-MN key. As long as the hash function is the same at both ends, the entropy of the username/password used as input is sufficient, and the method of distributing the username/password is deemed secure enough for the application in hand, you're home free. There's no reason to bother a user with entering a string of hex digits, for instance. Henrik --Signature=_Wed__11_Feb_2004_11_06_12_+0100_/xljPidYQNycIS8o Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKf6UeVhrtTJkXCMRAicFAKD00Sf4dOA8/u7BI0NdxvVRTcuosACgwgjP 36GudAcCUQ/odtquyW9spKo= =m1SM -----END PGP SIGNATURE----- --Signature=_Wed__11_Feb_2004_11_06_12_+0100_/xljPidYQNycIS8o-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 11 09:56:13 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 JAA03232 for ; Wed, 11 Feb 2004 09:56: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 1AqvmD-0008LW-4A for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 09:55:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BEtjga032082 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 09:55:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvmC-0008LN-V4 for mip4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 09:55: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 JAA03223 for ; Wed, 11 Feb 2004 09:55:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqvmB-0004T8-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 09:55:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqvlF-0004Ny-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 09:54:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AqvkX-0004IY-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 09:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvkX-0008Gc-Rc; Wed, 11 Feb 2004 09:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqvkR-0008Fo-Cb for mip4@optimus.ietf.org; Wed, 11 Feb 2004 09:53: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 JAA03187 for ; Wed, 11 Feb 2004 09:53:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqvkP-0004Hx-00 for mip4@ietf.org; Wed, 11 Feb 2004 09:53:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqvjX-0004BT-00 for mip4@ietf.org; Wed, 11 Feb 2004 09:52:59 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Aqvit-000447-00 for mip4@ietf.org; Wed, 11 Feb 2004 09:52:19 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BEphr04385; Wed, 11 Feb 2004 08:51:44 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.174.61]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i1BEpgd22408; Wed, 11 Feb 2004 08:51:42 -0600 (CST) Message-ID: <402A4179.6090304@lucent.com> Date: Wed, 11 Feb 2004 08:51:37 -0600 From: Tom Hiller Organization: Lucent Technologies 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 CC: mip4@ietf.org, aaa-wg@merit.edu Subject: Re: [AAA-WG]: RE: [Mip4] dynamic keys References: <87ED4812394BA14980CC352C3A7483CC816700@tatara.tatarasystems.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816700@tatara.tatarasystems.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Jeremy, In 3GPP2 there is an over the air provisioning mechanisms that sets up a TLS connection between the mobile and a trusted provisioning server. The mobile runs http over TLS to get various parameters, including the MN-AAA shared secret. The trusted provisioning system provides this information to the home AAA server of the mobile, too. The trusted provisioning system can run without user intervention, so that mobile station information may be updated. http://www.3gpp2.org/Public_html/specs/C.S0040-0_v1.0_110403.pdf - Tom Jeremy A. Greene wrote: > So, it doesn't make the initial deployment any easier (if there's one > HA), just ongoing use more secure. Each MN needs to be manually > configured in some manually intensive secure manner and/or use a > proprietary mechanism. > > I guess I was looking more for a standardized server-side-only (aaa) > configuration solution. More like the web, using server-side cert and > client-side username/pw (over ssl). > > Jeremy > > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Tuesday, February 10, 2004 7:00 PM > To: Jeremy A. Greene > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [Mip4] dynamic keys > > Hi Jeremy, > > Tuesday 10 February 2004, Jeremy A. Greene wrote: > >>In the mip4-aaa-key-03 draft (and aaa-diameter-mobileip-16) it > > requires > >>the use of a single, widely used (by all MNs??), long term pre-shared >>key between the MN and AAAH. Since this key is directly used to >>calculate dynamic keys, this does not seem terrible secure. > > > I see no reason why the preshared key between MN and AAAH should be the > same for all MNs, rather than individual per-MN? Or is it I who have > missed something? > > Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 11 11:54:13 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 LAA09191 for ; Wed, 11 Feb 2004 11: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 1AqxcP-0007SG-Hq for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 11:53:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BGrjgg028650 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 11:53:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxcP-0007S1-9y for mip4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 11:53: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 LAA09163 for ; Wed, 11 Feb 2004 11:53:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxcO-0001kA-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 11:53:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxbR-0001el-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 11:52:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aqxaj-0001Zr-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 11: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 1Aqxaj-0007Ni-Ny; Wed, 11 Feb 2004 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AqxaV-0007MJ-8B for mip4@optimus.ietf.org; Wed, 11 Feb 2004 11:51: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 LAA09112 for ; Wed, 11 Feb 2004 11:51:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AqxaU-0001Yt-00 for mip4@ietf.org; Wed, 11 Feb 2004 11:51:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AqxZh-0001TB-00 for mip4@ietf.org; Wed, 11 Feb 2004 11:50:57 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1AqxYu-0001Gi-00 for mip4@ietf.org; Wed, 11 Feb 2004 11:50:08 -0500 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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] dynamic keys Date: Wed, 11 Feb 2004 11:49:37 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816721@tatara.tatarasystems.com> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPwhq/7ub8IzJibRTSkuIumQTV/XgAImNRA From: "Jeremy A. Greene" To: "Henrik Levkowetz" Cc: , Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Not clear on how this would practically work since the server side (aaah) almost definitely will not have access to anything but verifying a text username and password string (say to a MS domain server). But, more importantly, there's a concern in the 802.11, wpa area that touches on this: http://wifinetnews.com/archives/002452.html=20 Jeremy -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Wednesday, February 11, 2004 5:06 AM To: Jeremy A. Greene Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys Tuesday 10 February 2004, Jeremy A. Greene wrote: > Username/pw can be tied to their existing ones (like existing aaa pw > or through MS domain etc.). And username/pws tend to be easier to > remember and update. And a md5 key is not the easiest thing to > remember or type in. Anyway, it seems that it's a more traditional > approach that people have already dealt with in one way or another. > This seems like another thing to deal with. I see no reason why a one-time username/password (or a pre-existing one, if it is deemed strong enough), cannot be run through a hash function to give you your initial AAAH-MN key. As long as the hash function is the same at both ends, the entropy of the username/password used as input is sufficient, and the method of distributing the username/password is deemed secure enough for the application in hand, you're home free. There's no reason to bother a user with entering a string of hex digits, for instance.=20 Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 11 15:00: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 PAA17596 for ; Wed, 11 Feb 2004 15:00: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 1Ar0WX-0007LP-0x for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 14:59:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BJxrZj028228 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 14:59:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0WW-0007LD-RM for mip4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 14:59: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 OAA17559 for ; Wed, 11 Feb 2004 14:59:49 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0WU-0005kh-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 14:59:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0VY-0005fC-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 14:58:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0Ug-0005a9-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 14:57:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar0Ui-0007F2-EH; Wed, 11 Feb 2004 14: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 1Ar0Ud-0007El-Ug for mip4@optimus.ietf.org; Wed, 11 Feb 2004 14:57: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 OAA17506 for ; Wed, 11 Feb 2004 14:57:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar0Ub-0005ZX-00 for mip4@ietf.org; Wed, 11 Feb 2004 14:57:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar0Tj-0005UE-00 for mip4@ietf.org; Wed, 11 Feb 2004 14:56:59 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar0Sr-0005OI-00 for mip4@ietf.org; Wed, 11 Feb 2004 14:56:05 -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 1Ar0So-0003Qa-00; Wed, 11 Feb 2004 20:56:02 +0100 Date: Wed, 11 Feb 2004 20:55:55 +0100 From: Henrik Levkowetz To: "Jeremy A. Greene" Cc: , Subject: Re: [Mip4] dynamic keys Message-Id: <20040211205555.5b79a2fd.henrik@levkowetz.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816721@tatara.tatarasystems.com> References: <87ED4812394BA14980CC352C3A7483CC816721@tatara.tatarasystems.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=_Wed__11_Feb_2004_20_55_55_+0100_Ag.noD02yMM6pD=k" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__11_Feb_2004_20_55_55_+0100_Ag.noD02yMM6pD=k Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Jeremy, Wednesday 11 February 2004, Jeremy A. Greene wrote: > But, more importantly, there's a concern in the 802.11, wpa area that > touches on this: > http://wifinetnews.com/archives/002452.html No, there's no real similarity here. The concern in this article is that it uses a broken procedure to generate a temporary session key, resulting in eavesdropping being possible, and goes on to discusses offline attacks on the passphrase. Offline attacks on an authenticating password/username combination is not that relevant in a bootstrap scenario where you only use a specific username/password combination once, and any repeated use will be blocked. Henrik --Signature=_Wed__11_Feb_2004_20_55_55_+0100_Ag.noD02yMM6pD=k Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKojLeVhrtTJkXCMRAjURAJ0Vz/6HeaSVTVEfN+0Fh8nC7ce9hwCggYnm a6xNyI1HYt+n1Zr3sxyQD90= =J4Za -----END PGP SIGNATURE----- --Signature=_Wed__11_Feb_2004_20_55_55_+0100_Ag.noD02yMM6pD=k-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 11 15:54: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 PAA22903 for ; Wed, 11 Feb 2004 15:54: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 1Ar1Ms-0004Zz-UD for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 15:53:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BKrwJU017597 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 15:53:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Ms-0004Zk-Ph for mip4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 15:53: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 PAA22843 for ; Wed, 11 Feb 2004 15:53:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1Mr-0003xZ-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 15:53:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1Ly-0003py-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 15:53:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1L2-0003j2-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 15:52:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1Kz-00048e-9c; Wed, 11 Feb 2004 15:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1KM-00047M-Kn for mip4@optimus.ietf.org; Wed, 11 Feb 2004 15:51:22 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22554; Wed, 11 Feb 2004 15:51:20 -0500 (EST) Message-Id: <200402112051.PAA22554@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Wed, 11 Feb 2004 15:51:20 -0500 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-vpn-problem-statement-01.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 IPv4 Working Group of the IETF. Title : Problem Statement: Mobile IPv4 Traversal of VPN Gateways Author(s) : F. Adrangi, H. Levkowetz Filename : draft-ietf-mip4-vpn-problem-statement-01.txt Pages : 20 Date : 2004-2-11 Deploying Mobile-IP v4 in networks which are connected to the Internet through a VPN (Virtual Private Network) gateway presents some problems which do not currently have well-described solutions. This document aims to describe and illustrate these problems, and propose some guidelines for possible solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-statement-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-mip4-vpn-problem-statement-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-mip4-vpn-problem-statement-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-11160516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-vpn-problem-statement-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-vpn-problem-statement-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-11160516.I-D@ietf.org> --OtherAccess-- --NextPart-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 11 16:13: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 QAA24701 for ; Wed, 11 Feb 2004 16:13: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 1Ar1fH-0006k4-3g for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 16:12:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLCxsA025910 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 16:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1fG-0006jp-UT for mip4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16: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 QAA24579 for ; Wed, 11 Feb 2004 16:12:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1fF-0006sJ-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 16:12:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1dt-0006XB-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 16:11:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1cQ-0006Cw-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 16: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 1Ar1cQ-0006eB-Bg; Wed, 11 Feb 2004 16:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1bi-0006bv-F9 for mip4@optimus.ietf.org; Wed, 11 Feb 2004 16:09: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 QAA24126 for ; Wed, 11 Feb 2004 16:09:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1bf-00060q-00 for mip4@ietf.org; Wed, 11 Feb 2004 16:09:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1a8-0005f6-00 for mip4@ietf.org; Wed, 11 Feb 2004 16:07:42 -0500 Received: from [65.213.122.34] (helo=TATARA.TataraSystems.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1ZE-0005R4-00 for mip4@ietf.org; Wed, 11 Feb 2004 16:06:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F0E2.D8D32FE0" Subject: RE: [Mip4] dynamic keys Date: Wed, 11 Feb 2004 16:05:58 -0500 Message-ID: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> Thread-Topic: [Mip4] dynamic keys Thread-Index: AcPw2RSuPxQ0PVgJQcqJBQutF0JPtQACKI/g From: "Jeremy A. Greene" To: "Henrik Levkowetz" Cc: , Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_50_60,HTML_MESSAGE autolearn=no version=2.60 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3F0E2.D8D32FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was referring to the offline attacks. Where does it say in the mip-key or diameter-aaa drafts that username/pw would only be used once? =20 >From section 5 of the mip-key draft: =20 1. Using the Key Generation Nonce from the extension, the mobile node calculates =20 key =3D HMAC-MD5 (AAA-key, {Key Generation Nonce || home address}) ... The secret key used within the HMAC-MD5 computation is indicated by the AAA Security Association indexed by the AAA SPI, which has been previously configured as the basis for the AAA Security Association between the mobile node and the AAA server creating the key material. =20 If I understand what you're suggesting, the aaa-key above would be generated from a username/password on the MN (and HA, somehow). But the text above seems to imply it will be used every time the aaah sends a new nonce to create new 'session' keys. =20 And I still think there's a practical issue of using passwords to create a hash on the MN since the HA won't be able to verify it without the password clear-text to run through the same hash. =20 Sorry if I'm being slow on this, but everything with security is way too confusing! =20 Jeremy =20 -----Original Message----- From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 Sent: Wednesday, February 11, 2004 2:56 PM To: Jeremy A. Greene Cc: mip4@ietf.org; aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys =20 Jeremy, =20 Wednesday 11 February 2004, Jeremy A. Greene wrote: > But, more importantly, there's a concern in the 802.11, wpa area that > touches on this: > http://wifinetnews.com/archives/002452.html=20 =20 No, there's no real similarity here. The concern in this article is that it uses a broken procedure to generate a temporary session key, resulting in eavesdropping being possible, and goes on to discusses offline attacks on the passphrase. Offline attacks on an authenticating password/username combination is not that relevant in a bootstrap scenario where you only use a specific username/password combination once, and any repeated use will be blocked. =20 Henrik ------_=_NextPart_001_01C3F0E2.D8D32FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was referring to the offline attacks. Where does it say in the = mip-key or diameter-aaa drafts that username/pw would only be used = once?

 

From section 5 of the mip-key draft:

 

1. Using the Key Generation = Nonce from the extension, the mobile

    &nbs= p;  node calculates

 

=

    &nbs= p;     key =3D HMAC-MD5 (AAA-key, {Key Generation Nonce || = home

    &nbs= p;     address})

...

The secret key used within = the HMAC-MD5 computation is indicated by

   the AAA = Security Association indexed by the AAA SPI, which has been

   previously = configured as the basis for the AAA Security Association

   between the = mobile node and the AAA server creating the key material.

 

If I understand what you’re suggesting, the aaa-key above = would be generated from a username/password on the MN (and HA, somehow). But = the text above seems to imply it will be used every time the aaah sends a new = nonce to create new ‘session’ keys.

 

And I still think there’s a practical issue of using = passwords to create a hash on the MN since the HA won’t be able to verify it = without the password clear-text to run through the same hash.

 

Sorry if I’m being slow on this, but everything with = security is way too confusing!

 

Jeremy

 

-----Original Message-----
From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
Sent: Wednesday, February 11, 2004 2:56 PM
To: Jeremy A. Greene
Cc: mip4@ietf.org; aaa-wg@merit.edu
Subject: Re: [Mip4] dynamic keys

 

Jeremy,

 

Wednesday 11 February 2004, Jeremy A. Greene = wrote:

> But, more importantly, there's a concern in the 802.11, wpa = area that

> touches on this:

> http://wifinetnews.com/archives/002452.html =

 

No, there's no real similarity here.  The concern in this = article is

that it uses a broken procedure to generate a temporary session = key,

resulting in eavesdropping being possible, and goes on to = discusses

offline attacks on the passphrase.  Offline attacks on an authenticating

password/username combination is not that relevant in a = bootstrap

scenario where you only use a specific username/password = combination

once, and any repeated use will be blocked.

 

      Henrik

------_=_NextPart_001_01C3F0E2.D8D32FE0-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 11 16:29:13 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 QAA27293 for ; Wed, 11 Feb 2004 16:29: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 1Ar1uX-0000Kf-PI for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 16:28:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BLSjAw001271 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 16:28:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1uX-0000KQ-IZ for mip4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 16:28: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 QAA27268 for ; Wed, 11 Feb 2004 16:28:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1uV-00028z-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 16:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1te-00022v-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 16:27:51 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1sy-0001wN-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 16:27:08 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Ar1sw-0006WY-Tk for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 16:27:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar1ss-0008R9-4u; Wed, 11 Feb 2004 16: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 1Ar1sc-0008OW-DC for mip4@optimus.ietf.org; Wed, 11 Feb 2004 16:26: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 QAA27016 for ; Wed, 11 Feb 2004 16:26:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar1sa-0001ur-00 for mip4@ietf.org; Wed, 11 Feb 2004 16:26:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar1rl-0001mh-00 for mip4@ietf.org; Wed, 11 Feb 2004 16:25:53 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar1qr-0001aP-00 for mip4@ietf.org; Wed, 11 Feb 2004 16:24:57 -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 1Ar1qm-0003Vs-00; Wed, 11 Feb 2004 22:24:52 +0100 Date: Wed, 11 Feb 2004 22:24:51 +0100 From: Henrik Levkowetz To: "Jeremy A. Greene" Cc: , Subject: Re: [Mip4] dynamic keys Message-Id: <20040211222451.04d5f459.henrik@levkowetz.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> References: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.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=_Wed__11_Feb_2004_22_24_51_+0100_x+TaNmDqZhnfjC4c" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__11_Feb_2004_22_24_51_+0100_x+TaNmDqZhnfjC4c Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Ok, I guess we may have talked past each other a little bit. I was referring to your comments some mails back about the problems with pre-shared keys being troublesome, and it being better if one could use the more conventional username/password. I intended to show that you could use a username/password combination to bootstrap the process, preferably by using the username/password once for authentication and for protecting the transfer of a more long-term mn-aaah shared secret; this in turn would be used as described in the aaa-key draft to generate mn-ha keys. Sorry if I was insufficiently clear about this. Henrik Wednesday 11 February 2004, Jeremy A. Greene wrote: > I was referring to the offline attacks. Where does it say in the mip-key > or diameter-aaa drafts that username/pw would only be used once? > > > > >From section 5 of the mip-key draft: > > > > 1. Using the Key Generation Nonce from the extension, the mobile > > node calculates > > > > key = HMAC-MD5 (AAA-key, {Key Generation Nonce || home > > address}) > > ... > > The secret key used within the HMAC-MD5 computation is indicated by > > the AAA Security Association indexed by the AAA SPI, which has been > > previously configured as the basis for the AAA Security Association > > between the mobile node and the AAA server creating the key material. > > > > If I understand what you're suggesting, the aaa-key above would be > generated from a username/password on the MN (and HA, somehow). But the > text above seems to imply it will be used every time the aaah sends a > new nonce to create new 'session' keys. > > > > And I still think there's a practical issue of using passwords to create > a hash on the MN since the HA won't be able to verify it without the > password clear-text to run through the same hash. > > > > Sorry if I'm being slow on this, but everything with security is way too > confusing! > > > > Jeremy > > > > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, February 11, 2004 2:56 PM > To: Jeremy A. Greene > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [Mip4] dynamic keys > > > > Jeremy, > > > > Wednesday 11 February 2004, Jeremy A. Greene wrote: > > > But, more importantly, there's a concern in the 802.11, wpa area that > > > touches on this: > > > http://wifinetnews.com/archives/002452.html > > > > No, there's no real similarity here. The concern in this article is > > that it uses a broken procedure to generate a temporary session key, > > resulting in eavesdropping being possible, and goes on to discusses > > offline attacks on the passphrase. Offline attacks on an authenticating > > password/username combination is not that relevant in a bootstrap > > scenario where you only use a specific username/password combination > > once, and any repeated use will be blocked. > > > > Henrik > > --Signature=_Wed__11_Feb_2004_22_24_51_+0100_x+TaNmDqZhnfjC4c Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAKp2jeVhrtTJkXCMRAklBAJ9wn0EsOLJBcMZm6w/seEmf3JZUMACfec2s TK8AW07lwCG7b/4Qjw+4O70= =Ziq/ -----END PGP SIGNATURE----- --Signature=_Wed__11_Feb_2004_22_24_51_+0100_x+TaNmDqZhnfjC4c-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 11 17:10: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 RAA02113 for ; Wed, 11 Feb 2004 17:10: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 1Ar2Yj-0005cy-As for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 17:10:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1BMAHdx021626 for mip4-archive@odin.ietf.org; Wed, 11 Feb 2004 17:10:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2Yj-0005cj-5s for mip4-web-archive@optimus.ietf.org; Wed, 11 Feb 2004 17:10: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 RAA02021 for ; Wed, 11 Feb 2004 17:10:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Yg-0000wl-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 17:10:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2Xl-0000kS-00 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 17:09:18 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2WY-0000Wc-01 for mip4-web-archive@ietf.org; Wed, 11 Feb 2004 17: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 1Ar2Ps-0004Xv-7o; Wed, 11 Feb 2004 17:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ar2PR-0004T7-Mu for mip4@optimus.ietf.org; Wed, 11 Feb 2004 17:00: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 RAA01023 for ; Wed, 11 Feb 2004 17:00:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ar2PP-0007DB-00 for mip4@ietf.org; Wed, 11 Feb 2004 17:00:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ar2OV-00076L-00 for mip4@ietf.org; Wed, 11 Feb 2004 16:59:44 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Ar2Nf-0006u5-00 for mip4@ietf.org; Wed, 11 Feb 2004 16:58:51 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1BLwG325736; Wed, 11 Feb 2004 15:58:16 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.171.169]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id i1BLwEd28137; Wed, 11 Feb 2004 15:58:14 -0600 (CST) Message-ID: <402AA576.9060302@lucent.com> Date: Wed, 11 Feb 2004 15:58:14 -0600 From: Tom Hiller Organization: Lucent Technologies 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: mip4@ietf.org, aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys References: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> In-Reply-To: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by auemail2.firewall.lucent.com id i1BLwG325736 Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Jeremy, I'd like to clarify a few things: 1) The MN-AAA shared secret is used more than once 2) It is periodically refreshed 3) It is configured per mobile and is not shared by other mobiles 4) aaa-keys does not say how the key is periodically refreshed. I've acted as the editor, addressing security review comments and other=20 comments from IETF and 3GPP2 folks. Summary: (1) The MN-AAA secret had=20 to be refreshed periodically. That was added to the text. (2) The term=20 "security association" was overloaded; "mobility security association",=20 etc., were added to the text. There was an IANA assignment that did not=20 match earlier text in the draft, and other editorial nits. Those were=20 fixed. - Tom PS In an earlier email, I provided a link to an MN-AAA shared secret=20 provisioning 3GPP2 specification that uses https. A problem with=20 provisioning in cdma2000 is that the mobile may not have an IP address=20 at the time the provisioning server wishes to refresh the shared secret=20 or other data, the phone may have just been purchased, etc., so there=20 are radio network specific scenarios to be specified. Jeremy A. Greene wrote: > I was referring to the offline attacks. Where does it say in the mip-ke= y=20 > or diameter-aaa drafts that username/pw would only be used once? >=20 > =20 >=20 > From section 5 of the mip-key draft: >=20 > =20 >=20 > 1. Using the Key Generation Nonce from the extension, the mobile >=20 > node calculates >=20 > =20 >=20 > key =3D HMAC-MD5 (AAA-key, {Key Generation Nonce || home >=20 > address}) >=20 > ... >=20 > The secret key used within the HMAC-MD5 computation is indicated by >=20 > the AAA Security Association indexed by the AAA SPI, which has been >=20 > previously configured as the basis for the AAA Security Association >=20 > between the mobile node and the AAA server creating the key material. >=20 > =20 >=20 > If I understand what you=92re suggesting, the aaa-key above would be=20 > generated from a username/password on the MN (and HA, somehow). But the= =20 > text above seems to imply it will be used every time the aaah sends a=20 > new nonce to create new =91session=92 keys. >=20 > =20 >=20 > And I still think there=92s a practical issue of using passwords to cre= ate=20 > a hash on the MN since the HA won=92t be able to verify it without the=20 > password clear-text to run through the same hash. >=20 > =20 >=20 > Sorry if I=92m being slow on this, but everything with security is way = too=20 > confusing! >=20 > =20 >=20 > Jeremy >=20 > =20 >=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, February 11, 2004 2:56 PM > To: Jeremy A. Greene > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [Mip4] dynamic keys >=20 > =20 >=20 > Jeremy, >=20 > =20 >=20 > Wednesday 11 February 2004, Jeremy A. Greene wrote: >=20 >> But, more importantly, there's a concern in the 802.11, wpa area that >=20 >> touches on this: >=20 >> http://wifinetnews.com/archives/002452.html >=20 > =20 >=20 > No, there's no real similarity here. The concern in this article is >=20 > that it uses a broken procedure to generate a temporary session key, >=20 > resulting in eavesdropping being possible, and goes on to discusses >=20 > offline attacks on the passphrase. Offline attacks on an authenticatin= g >=20 > password/username combination is not that relevant in a bootstrap >=20 > scenario where you only use a specific username/password combination >=20 > once, and any repeated use will be blocked. >=20 > =20 >=20 > Henrik >=20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 10:56: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 KAA29527 for ; Thu, 12 Feb 2004 10:56: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 1ArJBk-0004I7-0l for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 10:55:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CFtdkr016468 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 10:55:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJBh-0004HH-MV for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 10:55: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 KAA29522 for ; Thu, 12 Feb 2004 10:55:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJBa-0002TE-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 10:55:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJAf-0002NT-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 10:54:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArJA3-0002GC-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 10:53:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJA9-00045P-2G; Thu, 12 Feb 2004 10:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArJ9X-00042e-L0 for mip4@optimus.ietf.org; Thu, 12 Feb 2004 10:53: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 KAA29447 for ; Thu, 12 Feb 2004 10:53:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArJ9R-0002Ew-00 for mip4@ietf.org; Thu, 12 Feb 2004 10:53:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArJ8Z-0002A5-00 for mip4@ietf.org; Thu, 12 Feb 2004 10:52:24 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1ArJ7o-0001xk-00 for mip4@ietf.org; Thu, 12 Feb 2004 10:51:37 -0500 Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id i1CFp79M025303 for ; Thu, 12 Feb 2004 16:51:07 +0100 Message-ID: <402BA0D4.6090709@ipunplugged.com> Date: Thu, 12 Feb 2004 16:50:44 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040209153540.08b06367.henrik@levkowetz.com> In-Reply-To: <20040209153540.08b06367.henrik@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Sorry for being late with my comment, I think the proposal is a good proposal. And so does a few of my customers who has asked for the functionality. To bad that they didn't flag their interest on the list. However, there is one thing that I think is needed to be added to the draft to make the function usable. The extension carries to little information. Normally a router or gateway with HA functionality have several interfaces. The natural setup is that the gateway is accessible to internet on one interface (or address) and have the HA advertising the home network on another network. In many cases the home network have a private address space. The MN needs to know two things, 1) The address which I can reach my home agent from internet (the "external address")., 2) The address which my home agent is advertising on the home network (the "internal address"). In the case with dynamic home agent assignment, the MN is informed about the assigned "external address", but he is totally unaware of the "internal address". Subsequently the MN will never be able to recognise when he has entered his home network. Therefore this information needs to be relayed to him. Preferably in the Redirected HA address extension which then would look something like 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent External Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent Internal Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Home Agent External Address The IP address that the home agent is externally reachable. This might be a IP address on the Home agent or a IP address of an external device that will redirect or map the IP packets to the home agent. Home Agent Internal Address The IP address of the home agent. This might be the same address as the Home Agent External Address or an address on an internal network. This address MUST be the same address that the Home agent uses for the Mobility Agent Advertisements. Best regards /// Hasse Henrik Levkowetz wrote: >SECOND REQUEST - To date, no response to this WG last call has been >received. If enough responses are not received to support the >acceptance of this document, it *will not* be submitted to the IESG for >publication. Please respond to this WG last call. If you support >acceptance of the document without change, respond with a simple >acknowledgment, so that support for the document can be assessed. > >-------- > >This message announces a WG last call on "Mobile IPv4 Dynamic Home Agent >Assignment" . The last call >will conclude at 24:00 UTC on Friday, 13th Feb 2004. > >Please respond to this WG last call. If you support acceptance of the >document without change, respond with a simple acknowledgment, so that >support for the document can be assessed. > >draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechanism >for dynamic home agent assignment and HA redirection. The goal is to >provide a mechanism to assign an optimal HA for a Mobile IP session >while allowing any suitable method for HA selection. > >This draft is available as > > > Regards, > Henrik > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 12:37: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 MAA03848 for ; Thu, 12 Feb 2004 12:37: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 1ArKmI-0007oS-VV for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 12:37:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CHbULD030025 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 12:37:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKmH-0007oC-8m for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 12:37: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 MAA03842 for ; Thu, 12 Feb 2004 12:37:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKmD-0005jK-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 12:37:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKlF-0005d1-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 12:36:26 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArKkp-0005Xd-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 12:35:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKks-0007aa-0a; Thu, 12 Feb 2004 12:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArKkA-0007YE-CB for mip4@optimus.ietf.org; Thu, 12 Feb 2004 12:35: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 MAA03736 for ; Thu, 12 Feb 2004 12:35:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArKk6-0005V2-00 for mip4@ietf.org; Thu, 12 Feb 2004 12:35:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArKj8-0005PG-00 for mip4@ietf.org; Thu, 12 Feb 2004 12:34:15 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArKi9-0005FY-00 for mip4@ietf.org; Thu, 12 Feb 2004 12:33:13 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1CHXCGv022379; Fri, 13 Feb 2004 02:33:12 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1CHXCqs010085; Fri, 13 Feb 2004 02:33:12 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id CAA10082 ; Fri, 13 Feb 2004 02:33:12 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id CAA10949; Fri, 13 Feb 2004 02:33:12 +0900 (JST) Received: by toshiba.co.jp id CAA07238; Fri, 13 Feb 2004 02:17:06 +0900 (JST) Message-Id: <200402121717.CAA07238@toshiba.co.jp> Date: Fri, 13 Feb 2004 02:16:57 +0900 From: Yoshiyuki Tsuda Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) To: Hans =?ISO-8859-1?Q?Sj=F6strand?= Cc: mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <402BA0D4.6090709@ipunplugged.com> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hello Hans, Your comment is interesting, but it isn't directly related to dynamic HA, but rather related to NAT traversal in case of an HA sitting behind NAT, I'm afraid. So, we had better discuss about your issue as an improvement of the current NAT traversal RFC, or a separate draft. I think, if you can describe that your issue has more close relation to dynamic HA, rather than NAT traversal, it will help the authers to answer to you. Cheers. -Yoshi at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: >Sorry for being late with my comment, > >I think the proposal is a good proposal. And so does a few of my=20 >customers who has asked for the functionality. To bad that they didn't=20 >flag their interest on the list. > >However, there is one thing that I think is needed to be added to the=20 >draft to make the function usable. The extension carries to little=20 >information. > >Normally a router or gateway with HA functionality have several=20 >interfaces. The natural setup is that the gateway is accessible to=20 >internet on one interface (or address) and have the HA advertising the=20 >home network on another network. In many cases the home network have a=20 >private address space. > >The MN needs to know two things, >1) The address which I can reach my home agent from internet (the=20 >"external address")., >2) The address which my home agent is advertising on the home network=20 >(the "internal address"). > >In the case with dynamic home agent assignment, the MN is informed about=20= >the assigned "external address", but he is totally unaware of the=20 >"internal address". Subsequently the MN will never be able to recognise=20= >when he has entered his home network. Therefore this information needs=20 >to be relayed to him. Preferably in the Redirected HA address extension=20= >which then would look something like > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Home Agent External Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Home Agent Internal Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Home Agent External Address The IP address that the home agent is=20 >externally > reachable. This might be a IP address on=20 >the Home > agent or a IP address of an external=20 >device that > will redirect or map the IP packets to the=20= >home agent. > > Home Agent Internal Address The IP address of the home agent. This=20 >might be the > same address as the Home Agent External=20 >Address or an > address on an internal network. This=20 >address MUST be > the same address that the Home agent uses=20= >for the > Mobility Agent Advertisements. > > >Best regards >/// Hasse > >Henrik Levkowetz wrote: > >>SECOND REQUEST - To date, no response to this WG last call has been >>received. If enough responses are not received to support the >>acceptance of this document, it *will not* be submitted to the IESG for >>publication. Please respond to this WG last call. If you support >>acceptance of the document without change, respond with a simple >>acknowledgment, so that support for the document can be assessed. >> >>-------- >> >>This message announces a WG last call on "Mobile IPv4 Dynamic Home Agent >>Assignment" . The last call >>will conclude at 24:00 UTC on Friday, 13th Feb 2004. >> >>Please respond to this WG last call. If you support acceptance of the >>document without change, respond with a simple acknowledgment, so that >>support for the document can be assessed. >> >>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechanism >>for dynamic home agent assignment and HA redirection. The goal is to >>provide a mechanism to assign an optimal HA for a Mobile IP session >>while allowing any suitable method for HA selection. =20 >> >>This draft is available as >> >> >>=09Regards, >>=09=09Henrik >> =20 >> > > >--=20 >Mip4 mailing list >Mip4@ietf.org >https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 15:28: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 PAA12916 for ; Thu, 12 Feb 2004 15:28: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 1ArNQo-00062k-TK for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 15:27:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKRUhb023229 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 15:27:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNQo-000623-KU for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:27: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 PAA12890 for ; Thu, 12 Feb 2004 15:27:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNQl-0007fS-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 15:27:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNQ4-0007aj-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 15:26:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNPN-0007Tm-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 15:26:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNPP-0005gq-GZ; Thu, 12 Feb 2004 15:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNOw-0005cw-MQ for mip4@optimus.ietf.org; Thu, 12 Feb 2004 15:25:34 -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 PAA12786 for ; Thu, 12 Feb 2004 15:25:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNOt-0007RO-00 for mip4@ietf.org; Thu, 12 Feb 2004 15:25:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNNj-0007IQ-00 for mip4@ietf.org; Thu, 12 Feb 2004 15:24:20 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1ArNMk-00076a-00 for mip4@ietf.org; Thu, 12 Feb 2004 15:23:18 -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 1ArNLk-0000bo-00; Thu, 12 Feb 2004 21:22:16 +0100 Date: Thu, 12 Feb 2004 21:22:14 +0100 From: Henrik Levkowetz To: Yoshiyuki Tsuda Cc: Hans =?ISO-8859-1?Q?Sj=F6strand?= , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040212212214.4e8c448e.henrik@levkowetz.com> In-Reply-To: <200402121717.CAA07238@toshiba.co.jp> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hello Yoshi, The case Hans describes is not the HA behind NAT case, it is just one where the HA is accessible through more than one interface. You could have this setup: ..... Internet .... ........ Home Link ......... . . . . +----+ +-------+ . . | | | MN | . .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| HA |<---------->|3.4= .5.9| . . 3.4.5.1 | |3.4.5.254 +-------+ . . +----+ . . . . ............................ In this case, there is no NAT, but you would still need to know both the address of the HA on your home link, and the public address of the HA. I know that not all HAs out there is designed to be positioned in this manner, and I also believe that some support other ways of identifying the HA's home link interface, rather than explicitly listing it (or them). But all HAs are definitely not so simple that they can be fully described (assigned) through a single address. =20 I don't know if 2 addresses are enough, or if we need to be able to supply a list of addresses, or even a list of address/mask pairs, though. Henrik Friday 13 February 2004, Yoshiyuki Tsuda wrote: > Hello Hans, >=20 > Your comment is interesting, but it isn't directly related to > dynamic HA, but rather related to NAT traversal in case of > an HA sitting behind NAT, I'm afraid. So, we had better > discuss about your issue as an improvement of the current > NAT traversal RFC, or a separate draft. > I think, if you can describe that your issue has more close > relation to dynamic HA, rather than NAT traversal, it will > help the authers to answer to you. >=20 > Cheers. > -Yoshi >=20 > at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: > >Sorry for being late with my comment, > > > >I think the proposal is a good proposal. And so does a few of my=20 > >customers who has asked for the functionality. To bad that they didn't=20 > >flag their interest on the list. > > > >However, there is one thing that I think is needed to be added to the=20 > >draft to make the function usable. The extension carries to little=20 > >information. > > > >Normally a router or gateway with HA functionality have several=20 > >interfaces. The natural setup is that the gateway is accessible to=20 > >internet on one interface (or address) and have the HA advertising the=20 > >home network on another network. In many cases the home network have a=20 > >private address space. > > > >The MN needs to know two things, > >1) The address which I can reach my home agent from internet (the=20 > >"external address")., > >2) The address which my home agent is advertising on the home network=20 > >(the "internal address"). > > > >In the case with dynamic home agent assignment, the MN is informed about= =20 > >the assigned "external address", but he is totally unaware of the=20 > >"internal address". Subsequently the MN will never be able to recognise= =20 > >when he has entered his home network. Therefore this information needs=20 > >to be relayed to him. Preferably in the Redirected HA address extension= =20 > >which then would look something like > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Length | Reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Home Agent External Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Home Agent Internal Address | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > Home Agent External Address The IP address that the home agent is exte= rnally > > reachable. This might be a IP address on t= he Home > > agent or a IP address of an external devic= e that > > will redirect or map the IP packets to the= home agent. > > > > Home Agent Internal Address The IP address of the home agent. This mig= ht be the > > same address as the Home Agent External Ad= dress or an > > address on an internal network. This addre= ss MUST be > > the same address that the Home agent uses = for the > > Mobility Agent Advertisements. > > > > > >Best regards > >/// Hasse > > > >Henrik Levkowetz wrote: > > > >>SECOND REQUEST - To date, no response to this WG last call has been > >>received. If enough responses are not received to support the > >>acceptance of this document, it *will not* be submitted to the IESG for > >>publication. Please respond to this WG last call. If you support > >>acceptance of the document without change, respond with a simple > >>acknowledgment, so that support for the document can be assessed. > >> > >>-------- > >> > >>This message announces a WG last call on "Mobile IPv4 Dynamic Home Agent > >>Assignment" . The last call > >>will conclude at 24:00 UTC on Friday, 13th Feb 2004. > >> > >>Please respond to this WG last call. If you support acceptance of the > >>document without change, respond with a simple acknowledgment, so that > >>support for the document can be assessed. > >> > >>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechanism > >>for dynamic home agent assignment and HA redirection. The goal is to > >>provide a mechanism to assign an optimal HA for a Mobile IP session > >>while allowing any suitable method for HA selection. =20 > >> > >>This draft is available as > >> > >> > >> Regards, > >> Henrik > >> =20 > >> > > > > > >--=20 > >Mip4 mailing list > >Mip4@ietf.org > >https://www.ietf.org/mailman/listinfo/mip4 >=20 > --=20 > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 15:55: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 PAA14715 for ; Thu, 12 Feb 2004 15:55: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 1ArNqy-0004NA-Ke for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 15:54:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CKsWgV016808 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 15:54:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNqy-0004N1-Ex for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 15:54: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 PAA14690 for ; Thu, 12 Feb 2004 15:54:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNqv-0002pg-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 15:54:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNq3-0002js-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 15:53:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArNpS-0002dy-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 15:52:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNpU-0004Fu-Og; Thu, 12 Feb 2004 15:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArNoh-0003wz-OY for mip4@optimus.ietf.org; Thu, 12 Feb 2004 15:52:12 -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 PAB14357 for ; Thu, 12 Feb 2004 15:52:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArNoe-0002Us-00 for mip4@ietf.org; Thu, 12 Feb 2004 15:52:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArNnS-0002Hd-00 for mip4@ietf.org; Thu, 12 Feb 2004 15:50:55 -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 1ArNmC-0001ui-00 for mip4@ietf.org; Thu, 12 Feb 2004 15:49:36 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 12 Feb 2004 12:56:56 +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 i1CKn54U017440; Thu, 12 Feb 2004 12:49:05 -0800 (PST) Received: from cisco.com (dhcp-128-107-163-52.cisco.com [128.107.163.52]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQG00399; Thu, 12 Feb 2004 12:49:04 -0800 (PST) Message-ID: <402BE6BF.2030307@cisco.com> Date: Thu, 12 Feb 2004 12:49:03 -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: Henrik Levkowetz CC: Yoshiyuki Tsuda , =?ISO-8859-1?Q?Hans_?= =?ISO-8859-1?Q?Sj=F6strand?= , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> Content-Type: multipart/alternative; boundary="------------040208080108000102090105" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 --------------040208080108000102090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA14358 Content-Transfer-Encoding: quoted-printable Henrik - Isn't this issue implementation specific? RFC3344 does not talk about HA=20 with multiple interfaces too. I was wondering if such an implementation can specify one or more=20 private addresses using a VSE? How does the MN currently come to know the private address? -a Henrik Levkowetz wrote: >Hello Yoshi, > > The case Hans describes is not the HA behind NAT case, it is just >one where the HA is accessible through more than one interface. You >could have this setup: > > > ..... Internet .... ........ Home Link ......... > . . . > . +----+ +-------+ . > . | | | MN | . > .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| HA |<---------->|= 3.4.5.9| . > . 3.4.5.1 | |3.4.5.254 +-------+ . > . +----+ . > . . . > ............................ > > >In this case, there is no NAT, but you would still need to know both the >address of the HA on your home link, and the public address of the HA. I >know that not all HAs out there is designed to be positioned in this >manner, and I also believe that some support other ways of identifying >the HA's home link interface, rather than explicitly listing it (or >them). But all HAs are definitely not so simple that they can be fully >described (assigned) through a single address. =20 > >I don't know if 2 addresses are enough, or if we need to be able to >supply a list of addresses, or even a list of address/mask pairs, >though. > > Henrik > > > >Friday 13 February 2004, Yoshiyuki Tsuda wrote: > =20 > >>Hello Hans, >> >> Your comment is interesting, but it isn't directly related to >> dynamic HA, but rather related to NAT traversal in case of >> an HA sitting behind NAT, I'm afraid. So, we had better >> discuss about your issue as an improvement of the current >> NAT traversal RFC, or a separate draft. >> I think, if you can describe that your issue has more close >> relation to dynamic HA, rather than NAT traversal, it will >> help the authers to answer to you. >> >>Cheers. >>-Yoshi >> >>at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: >> =20 >> >>>Sorry for being late with my comment, >>> >>>I think the proposal is a good proposal. And so does a few of my=20 >>>customers who has asked for the functionality. To bad that they didn't= =20 >>>flag their interest on the list. >>> >>>However, there is one thing that I think is needed to be added to the=20 >>>draft to make the function usable. The extension carries to little=20 >>>information. >>> >>>Normally a router or gateway with HA functionality have several=20 >>>interfaces. The natural setup is that the gateway is accessible to=20 >>>internet on one interface (or address) and have the HA advertising the= =20 >>>home network on another network. In many cases the home network have a= =20 >>>private address space. >>> >>>The MN needs to know two things, >>>1) The address which I can reach my home agent from internet (the=20 >>>"external address")., >>>2) The address which my home agent is advertising on the home network=20 >>>(the "internal address"). >>> >>>In the case with dynamic home agent assignment, the MN is informed abo= ut=20 >>>the assigned "external address", but he is totally unaware of the=20 >>>"internal address". Subsequently the MN will never be able to recognis= e=20 >>>when he has entered his home network. Therefore this information needs= =20 >>>to be relayed to him. Preferably in the Redirected HA address extensio= n=20 >>>which then would look something like >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Type | Length | Reserved | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Home Agent External Address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Home Agent Internal Address | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Home Agent External Address The IP address that the home agent is ext= ernally >>> reachable. This might be a IP address on = the Home >>> agent or a IP address of an external devi= ce that >>> will redirect or map the IP packets to th= e home agent. >>> >>> Home Agent Internal Address The IP address of the home agent. This mi= ght be the >>> same address as the Home Agent External A= ddress or an >>> address on an internal network. This addr= ess MUST be >>> the same address that the Home agent uses= for the >>> Mobility Agent Advertisements. >>> >>> >>>Best regards >>>/// Hasse >>> >>>Henrik Levkowetz wrote: >>> >>> =20 >>> >>>>SECOND REQUEST - To date, no response to this WG last call has been >>>>received. If enough responses are not received to support the >>>>acceptance of this document, it *will not* be submitted to the IESG f= or >>>>publication. Please respond to this WG last call. If you support >>>>acceptance of the document without change, respond with a simple >>>>acknowledgment, so that support for the document can be assessed. >>>> >>>>-------- >>>> >>>>This message announces a WG last call on "Mobile IPv4 Dynamic Home Ag= ent >>>>Assignment" . The last ca= ll >>>>will conclude at 24:00 UTC on Friday, 13th Feb 2004. >>>> >>>>Please respond to this WG last call. If you support acceptance of th= e >>>>document without change, respond with a simple acknowledgment, so tha= t >>>>support for the document can be assessed. >>>> >>>>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechan= ism >>>>for dynamic home agent assignment and HA redirection. The goal is to >>>>provide a mechanism to assign an optimal HA for a Mobile IP session >>>>while allowing any suitable method for HA selection. =20 >>>> >>>>This draft is available as >>>> >>>> >>>> Regards, >>>> Henrik >>>>=20 >>>> >>>> =20 >>>> >>>--=20 >>>Mip4 mailing list >>>Mip4@ietf.org >>>https://www.ietf.org/mailman/listinfo/mip4 >>> =20 >>> >>--=20 >>Mip4 mailing list >>Mip4@ietf.org >>https://www.ietf.org/mailman/listinfo/mip4 >> =20 >> > > =20 > --------------040208080108000102090105 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Henrik -

Isn't this issue implementation specific? RFC3344 does not talk about HA with multiple interfaces too.

I was wondering if such an implementation can specify one or more private addresses using a VSE?
How does the MN currently come to know the private address?

-a

Henrik Levkowetz wrote:
Hello Yoshi,

    The case Hans describes is not the HA behind NAT case, it is just
one where the HA is accessible through more than one interface.  You
could have this setup:


     ..... Internet ....             ........ Home Link .........
                       .             .                          .
                       .           +----+            +-------+  .
                       .           |    |            | MN    |  .
                       .<=========>| HA |<---------->|3.4.5.9|  .
                       .   3.4.5.1 |    |3.4.5.254   +-------+  .
                       .           +----+                       .
                       .             .                          .
                                     ............................


In this case, there is no NAT, but you would still need to know both the
address of the HA on your home link, and the public address of the HA. I
know that not all HAs out there is designed to be positioned in this
manner, and I also believe that some support other ways of identifying
the HA's home link interface, rather than explicitly listing it (or
them).  But all HAs are definitely not so simple that they can be fully
described (assigned) through a single address.  

I don't know if 2 addresses are enough, or if we need to be able to
supply a list of addresses, or even a list of address/mask pairs,
though.

	Henrik



Friday 13 February 2004, Yoshiyuki Tsuda wrote:
  
Hello Hans,

 Your comment is interesting, but it isn't directly related to
 dynamic HA, but rather related to NAT traversal in case of
 an HA sitting behind NAT, I'm afraid.  So, we had better
 discuss about your issue as an improvement of the current
 NAT traversal RFC, or a separate draft.
 I think, if you can describe that your issue has more close
 relation to dynamic HA, rather than NAT traversal, it will
 help the authers to answer to you.

Cheers.
-Yoshi

at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sjöstrand wrote:
    
Sorry for being late with my comment,

I think the proposal is a good proposal. And so does a few of my 
customers who has asked for the functionality. To bad that they didn't 
flag their interest on the list.

However, there is one thing that I think is needed to be added to the 
draft to make the function usable. The extension carries to little 
information.

Normally a router or gateway with HA functionality have several 
interfaces. The natural setup is that the gateway is accessible to 
internet on one interface (or address) and have the HA advertising the 
home network on another network. In many cases the home network have a 
private address space.

The MN needs to know two things,
1) The address which I can reach my home agent from internet (the 
"external address").,
2) The address which my home agent is advertising on the home network 
(the "internal address").

In the case with dynamic home agent assignment, the MN is informed about 
the assigned "external address", but he is totally unaware of the 
"internal address". Subsequently the MN will never be able to recognise 
when he has entered his home network. Therefore this information needs 
to be relayed to him. Preferably in the Redirected HA address extension 
which then would look something like

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |               Reserved        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Home Agent External Address                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                   Home Agent Internal Address                 |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Home Agent External Address The IP address that the home agent is externally
                             reachable. This might be a IP address on the Home
                             agent or a IP address of an external device that
                             will redirect or map the IP packets to the home agent.

 Home Agent Internal Address The IP address of the home agent. This might be the
                             same address as the Home Agent External Address or an
                             address on an internal network. This address MUST be
                             the same address that the Home agent uses for the
                             Mobility Agent Advertisements.


Best regards
/// Hasse

Henrik Levkowetz wrote:

      
SECOND REQUEST - To date, no response to this WG last call has been
received.  If enough responses are not received to support the
acceptance of this document, it *will not* be submitted to the IESG for
publication.  Please respond to this WG last call.  If you support
acceptance of the document without change, respond with a simple
acknowledgment, so that support for the document can be assessed.

--------

This message announces a WG last call on "Mobile IPv4 Dynamic Home Agent
Assignment" <draft-ietf-mip4-dynamic-assignment-00.txt>.  The last call
will conclude at 24:00 UTC on Friday, 13th Feb 2004.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.

draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechanism
for dynamic home agent assignment and HA redirection. The goal is to
provide a mechanism to assign an optimal HA for a Mobile IP session
while allowing any suitable method for HA selection.  

This draft is available as
<http://www.ietf.org/internet-drafts/draft-ietf-mip4-dynamic-assignment-00.txt>

	Regards,
		Henrik
 

        
-- 
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4
      
-- 
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4

--------------040208080108000102090105-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 16:28: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 QAA17040 for ; Thu, 12 Feb 2004 16:28:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArONo-0008Vj-VO for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 16:28:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CLSSrK032715 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 16:28:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArONo-0008Va-Oj for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 16:28: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 QAA17028 for ; Thu, 12 Feb 2004 16:28:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArONl-0006cD-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 16:28:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOMs-0006Xi-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 16:27:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArOML-0006Sf-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 16:26:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOMO-0008PJ-LO; Thu, 12 Feb 2004 16:27:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArOLp-0008Ne-RN for mip4@optimus.ietf.org; Thu, 12 Feb 2004 16:26: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 QAA16919 for ; Thu, 12 Feb 2004 16:26:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArOLm-0006QJ-00 for mip4@ietf.org; Thu, 12 Feb 2004 16:26:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArOKo-0006KT-00 for mip4@ietf.org; Thu, 12 Feb 2004 16:25:23 -0500 Received: from mail.gbg.bostream.net ([81.26.226.10]) by ietf-mx with esmtp (Exim 4.12) id 1ArOJt-0006BA-00 for mip4@ietf.org; Thu, 12 Feb 2004 16:24:26 -0500 Received: from ipunplugged.com (as1-3-6.kc01.mael.s.bonet.se [217.215.191.101]) by mail.gbg.bostream.net (8.12.10/8.12.10) with ESMTP id i1CLGbKS019824; Thu, 12 Feb 2004 22:16:37 +0100 Message-ID: <402BEEC6.8080209@ipunplugged.com> Date: Thu, 12 Feb 2004 22:23:18 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: Alpesh CC: Henrik Levkowetz , Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> In-Reply-To: <402BE6BF.2030307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.gbg.bostream.net id i1CLGbKS019824 Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Alpesh, The problem is not implementation specific. The reason 3344 doesn't talk about these things is becasue it doesn't have to. 3344 doesn't at all deal with how the clietn is configured, it's just a pre-requsite. Note that this is specifically normal behaviour and 3344 is written to support it (well, atleast it supports it). The reason why this becomes an issue here is that this is the first time ever (as far as I know) that a MN has been configured with a HA information in a Registration request extension. Thus, this have to support both the case where the MN have a CoA (the external address) and the case where the MN is in the home network (the internal). The meere phrases internal and external address might however be new to some people and at first sight be thought of as oimplementation specific. But still, some mechanism is needed. Using the extension is one. /// Hasse Alpesh wrote: > Henrik - > > Isn't this issue implementation specific? RFC3344 does not talk about=20 > HA with multiple interfaces too. > > I was wondering if such an implementation can specify one or more=20 > private addresses using a VSE? > How does the MN currently come to know the private address? > > -a > > Henrik Levkowetz wrote: > >>Hello Yoshi, >> >> The case Hans describes is not the HA behind NAT case, it is just >>one where the HA is accessible through more than one interface. You >>could have this setup: >> >> >> ..... Internet .... ........ Home Link ......... >> . . . >> . +----+ +-------+ . >> . | | | MN | . >> .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| HA |<---------->= |3.4.5.9| . >> . 3.4.5.1 | |3.4.5.254 +-------+ . >> . +----+ . >> . . . >> ............................ >> >> >>In this case, there is no NAT, but you would still need to know both th= e >>address of the HA on your home link, and the public address of the HA. = I >>know that not all HAs out there is designed to be positioned in this >>manner, and I also believe that some support other ways of identifying >>the HA's home link interface, rather than explicitly listing it (or >>them). But all HAs are definitely not so simple that they can be fully >>described (assigned) through a single address. =20 >> >>I don't know if 2 addresses are enough, or if we need to be able to >>supply a list of addresses, or even a list of address/mask pairs, >>though. >> >> Henrik >> >> >> >>Friday 13 February 2004, Yoshiyuki Tsuda wrote: >> =20 >> >>>Hello Hans, >>> >>> Your comment is interesting, but it isn't directly related to >>> dynamic HA, but rather related to NAT traversal in case of >>> an HA sitting behind NAT, I'm afraid. So, we had better >>> discuss about your issue as an improvement of the current >>> NAT traversal RFC, or a separate draft. >>> I think, if you can describe that your issue has more close >>> relation to dynamic HA, rather than NAT traversal, it will >>> help the authers to answer to you. >>> >>>Cheers. >>>-Yoshi >>> >>>at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: >>> =20 >>> >>>>Sorry for being late with my comment, >>>> >>>>I think the proposal is a good proposal. And so does a few of my=20 >>>>customers who has asked for the functionality. To bad that they didn'= t=20 >>>>flag their interest on the list. >>>> >>>>However, there is one thing that I think is needed to be added to the= =20 >>>>draft to make the function usable. The extension carries to little=20 >>>>information. >>>> >>>>Normally a router or gateway with HA functionality have several=20 >>>>interfaces. The natural setup is that the gateway is accessible to=20 >>>>internet on one interface (or address) and have the HA advertising th= e=20 >>>>home network on another network. In many cases the home network have = a=20 >>>>private address space. >>>> >>>>The MN needs to know two things, >>>>1) The address which I can reach my home agent from internet (the=20 >>>>"external address")., >>>>2) The address which my home agent is advertising on the home network= =20 >>>>(the "internal address"). >>>> >>>>In the case with dynamic home agent assignment, the MN is informed ab= out=20 >>>>the assigned "external address", but he is totally unaware of the=20 >>>>"internal address". Subsequently the MN will never be able to recogni= se=20 >>>>when he has entered his home network. Therefore this information need= s=20 >>>>to be relayed to him. Preferably in the Redirected HA address extensi= on=20 >>>>which then would look something like >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type | Length | Reserved | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Home Agent External Address | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Home Agent Internal Address | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Home Agent External Address The IP address that the home agent is ex= ternally >>>> reachable. This might be a IP address on= the Home >>>> agent or a IP address of an external dev= ice that >>>> will redirect or map the IP packets to t= he home agent. >>>> >>>> Home Agent Internal Address The IP address of the home agent. This m= ight be the >>>> same address as the Home Agent External = Address or an >>>> address on an internal network. This add= ress MUST be >>>> the same address that the Home agent use= s for the >>>> Mobility Agent Advertisements. >>>> >>>> >>>>Best regards >>>>/// Hasse >>>> >>>>Henrik Levkowetz wrote: >>>> >>>> =20 >>>> >>>>>SECOND REQUEST - To date, no response to this WG last call has been >>>>>received. If enough responses are not received to support the >>>>>acceptance of this document, it *will not* be submitted to the IESG = for >>>>>publication. Please respond to this WG last call. If you support >>>>>acceptance of the document without change, respond with a simple >>>>>acknowledgment, so that support for the document can be assessed. >>>>> >>>>>-------- >>>>> >>>>>This message announces a WG last call on "Mobile IPv4 Dynamic Home A= gent >>>>>Assignment" . The last c= all >>>>>will conclude at 24:00 UTC on Friday, 13th Feb 2004. >>>>> >>>>>Please respond to this WG last call. If you support acceptance of t= he >>>>>document without change, respond with a simple acknowledgment, so th= at >>>>>support for the document can be assessed. >>>>> >>>>>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mecha= nism >>>>>for dynamic home agent assignment and HA redirection. The goal is to >>>>>provide a mechanism to assign an optimal HA for a Mobile IP session >>>>>while allowing any suitable method for HA selection. =20 >>>>> >>>>>This draft is available as >>>>> >>>>> >>>>> Regards, >>>>> Henrik >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>--=20 >>>>Mip4 mailing list >>>>Mip4@ietf.org >>>>https://www.ietf.org/mailman/listinfo/mip4 >>>> =20 >>>> >>>--=20 >>>Mip4 mailing list >>>Mip4@ietf.org >>>https://www.ietf.org/mailman/listinfo/mip4 >>> =20 >>> >> >> =20 >> > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 17:53: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 RAA21039 for ; Thu, 12 Feb 2004 17:53: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 1ArPi5-0007P2-IL for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 17:53:29 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CMrTkn028452 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 17:53:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPi5-0007Op-Bk for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 17:53: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 RAA21034 for ; Thu, 12 Feb 2004 17:53:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPi0-0007Bo-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 17:53:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPh5-00077h-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 17:52:28 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArPgb-00073Z-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 17:51:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArPge-0007KD-UR; Thu, 12 Feb 2004 17: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 1ArPgF-0007Jg-9l for mip4@optimus.ietf.org; Thu, 12 Feb 2004 17:51: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 RAA20996 for ; Thu, 12 Feb 2004 17:51:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArPgA-00073E-00 for mip4@ietf.org; Thu, 12 Feb 2004 17:51:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArPfK-0006ya-00 for mip4@ietf.org; Thu, 12 Feb 2004 17:50:39 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1ArPeo-0006sz-00 for mip4@ietf.org; Thu, 12 Feb 2004 17:50:07 -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 1ArPej-0000jl-00; Thu, 12 Feb 2004 23:50:01 +0100 Date: Thu, 12 Feb 2004 23:49:44 +0100 From: Henrik Levkowetz To: Alpesh Cc: Yoshiyuki Tsuda , Hans =?ISO-8859-1?Q?S?= =?ISO-8859-1?Q?j=F6strand?= , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040212234944.3e943921.henrik@levkowetz.com> In-Reply-To: <402BE6BF.2030307@cisco.com> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.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=_Thu__12_Feb_2004_23_49_44_+0100_pyfySW5uxhBfCQJH" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Thu__12_Feb_2004_23_49_44_+0100_pyfySW5uxhBfCQJH Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alpesh, In addition to Hans' comments, it bears mentioning that rfc3344 in several places clearly discusses both FAs and HAs having multiple interfaces. Explicitly limiting the dynamic HA assgnment mechanism to work with only the one-interface case seems wrong. Henrik Thursday 12 February 2004, Alpesh wrote: > Henrik - >=20 > Isn't this issue implementation specific? RFC3344 does not talk about HA= =20 > with multiple interfaces too. >=20 > I was wondering if such an implementation can specify one or more=20 > private addresses using a VSE? > How does the MN currently come to know the private address? >=20 > -a >=20 > Henrik Levkowetz wrote: >=20 > >Hello Yoshi, > > > > The case Hans describes is not the HA behind NAT case, it is just > >one where the HA is accessible through more than one interface. You > >could have this setup: > > > > > > ..... Internet .... ........ Home Link ......... > > . . . > > . +----+ +-------+ . > > . | | | MN | . > > .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| HA |<---------->|= 3.4.5.9| . > > . 3.4.5.1 | |3.4.5.254 +-------+ . > > . +----+ . > > . . . > > ............................ > > > > > >In this case, there is no NAT, but you would still need to know both the > >address of the HA on your home link, and the public address of the HA. I > >know that not all HAs out there is designed to be positioned in this > >manner, and I also believe that some support other ways of identifying > >the HA's home link interface, rather than explicitly listing it (or > >them). But all HAs are definitely not so simple that they can be fully > >described (assigned) through a single address. =20 > > > >I don't know if 2 addresses are enough, or if we need to be able to > >supply a list of addresses, or even a list of address/mask pairs, > >though. > > > > Henrik > > > > > > > >Friday 13 February 2004, Yoshiyuki Tsuda wrote: > > =20 > > > >>Hello Hans, > >> > >> Your comment is interesting, but it isn't directly related to > >> dynamic HA, but rather related to NAT traversal in case of > >> an HA sitting behind NAT, I'm afraid. So, we had better > >> discuss about your issue as an improvement of the current > >> NAT traversal RFC, or a separate draft. > >> I think, if you can describe that your issue has more close > >> relation to dynamic HA, rather than NAT traversal, it will > >> help the authers to answer to you. > >> > >>Cheers. > >>-Yoshi > >> > >>at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: > >> =20 > >> > >>>Sorry for being late with my comment, > >>> > >>>I think the proposal is a good proposal. And so does a few of my=20 > >>>customers who has asked for the functionality. To bad that they didn't= =20 > >>>flag their interest on the list. > >>> > >>>However, there is one thing that I think is needed to be added to the= =20 > >>>draft to make the function usable. The extension carries to little=20 > >>>information. > >>> > >>>Normally a router or gateway with HA functionality have several=20 > >>>interfaces. The natural setup is that the gateway is accessible to=20 > >>>internet on one interface (or address) and have the HA advertising the= =20 > >>>home network on another network. In many cases the home network have a= =20 > >>>private address space. > >>> > >>>The MN needs to know two things, > >>>1) The address which I can reach my home agent from internet (the=20 > >>>"external address")., > >>>2) The address which my home agent is advertising on the home network= =20 > >>>(the "internal address"). > >>> > >>>In the case with dynamic home agent assignment, the MN is informed abo= ut=20 > >>>the assigned "external address", but he is totally unaware of the=20 > >>>"internal address". Subsequently the MN will never be able to recognis= e=20 > >>>when he has entered his home network. Therefore this information needs= =20 > >>>to be relayed to him. Preferably in the Redirected HA address extensio= n=20 > >>>which then would look something like > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Type | Length | Reserved | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Home Agent External Address | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Home Agent Internal Address | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> Home Agent External Address The IP address that the home agent is ext= ernally > >>> reachable. This might be a IP address on = the Home > >>> agent or a IP address of an external devi= ce that > >>> will redirect or map the IP packets to th= e home agent. > >>> > >>> Home Agent Internal Address The IP address of the home agent. This mi= ght be the > >>> same address as the Home Agent External A= ddress or an > >>> address on an internal network. This addr= ess MUST be > >>> the same address that the Home agent uses= for the > >>> Mobility Agent Advertisements. > >>> > >>> > >>>Best regards > >>>/// Hasse > >>> > >>>Henrik Levkowetz wrote: > >>> > >>> =20 > >>> > >>>>SECOND REQUEST - To date, no response to this WG last call has been > >>>>received. If enough responses are not received to support the > >>>>acceptance of this document, it *will not* be submitted to the IESG f= or > >>>>publication. Please respond to this WG last call. If you support > >>>>acceptance of the document without change, respond with a simple > >>>>acknowledgment, so that support for the document can be assessed. > >>>> > >>>>-------- > >>>> > >>>>This message announces a WG last call on "Mobile IPv4 Dynamic Home Ag= ent > >>>>Assignment" . The last ca= ll > >>>>will conclude at 24:00 UTC on Friday, 13th Feb 2004. > >>>> > >>>>Please respond to this WG last call. If you support acceptance of the > >>>>document without change, respond with a simple acknowledgment, so that > >>>>support for the document can be assessed. > >>>> > >>>>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechan= ism > >>>>for dynamic home agent assignment and HA redirection. The goal is to > >>>>provide a mechanism to assign an optimal HA for a Mobile IP session > >>>>while allowing any suitable method for HA selection. =20 > >>>> > >>>>This draft is available as > >>>> > >>>> > >>>> Regards, > >>>> Henrik > >>>>=20 > >>>> > >>>> =20 > >>>> > >>>--=20 > >>>Mip4 mailing list > >>>Mip4@ietf.org > >>>https://www.ietf.org/mailman/listinfo/mip4 > >>> =20 > >>> > >>--=20 > >>Mip4 mailing list > >>Mip4@ietf.org > >>https://www.ietf.org/mailman/listinfo/mip4 > >> =20 > >> > > > > =20 > > >=20 >=20 --Signature=_Thu__12_Feb_2004_23_49_44_+0100_pyfySW5uxhBfCQJH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFALAMUeVhrtTJkXCMRAl5oAJ9kSyTiZjOwLNcptqnXMVoh/oR/IQCfW9YR fVjHDoMSLCvb20q9z2Q7lxU= =TWFl -----END PGP SIGNATURE----- --Signature=_Thu__12_Feb_2004_23_49_44_+0100_pyfySW5uxhBfCQJH-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 18:31: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 SAA23803 for ; Thu, 12 Feb 2004 18:31: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 1ArQI4-0008Lq-4x for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 18:30:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1CNUdjS032075 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 18:30:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQHz-0008IZ-Ic for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 18:30: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 SAA23748 for ; Thu, 12 Feb 2004 18:30:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQHu-0002kb-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 18:30:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQGz-0002f7-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 18:29:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArQGP-0002a2-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 18:28:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQGS-00087X-Rx; Thu, 12 Feb 2004 18:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArQFz-00084Y-2q for mip4@optimus.ietf.org; Thu, 12 Feb 2004 18:28: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 SAA23632 for ; Thu, 12 Feb 2004 18:28:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArQFu-0002Xs-00 for mip4@ietf.org; Thu, 12 Feb 2004 18:28:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArQEv-0002SG-00 for mip4@ietf.org; Thu, 12 Feb 2004 18:27:26 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1ArQE1-0002Kb-00 for mip4@ietf.org; Thu, 12 Feb 2004 18:26:29 -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 1ArQDo-0000m6-00; Fri, 13 Feb 2004 00:26:16 +0100 Date: Fri, 13 Feb 2004 00:26:16 +0100 From: Henrik Levkowetz To: mip4@ietf.org Cc: Alpesh , Hans =?ISO-8859-1?Q?Sj=F6strand?= Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040213002616.29c4ec9c.henrik@levkowetz.com> In-Reply-To: <402BE6BF.2030307@cisco.com> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.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=_Fri__13_Feb_2004_00_26_16_+0100_hh+GVJviZCOykcxq" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Fri__13_Feb_2004_00_26_16_+0100_hh+GVJviZCOykcxq Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Alpesh, I've been thinking more about this, and I'm firmly convinced that I'm still unclear about what would be the optimal solution ,:-) My latest thoughts have been moving along like this (brainstorming warning!): Assuming that the general case is that a HA has one or more publicly accessible interfaces, and one or more private interfaces, shouldn't we provide for this? That would mean that full information to the mobile would consist of two lists: one giving N public interface addresses, the other giving M private interfaces (address + mask). Thoughts? Henrik Thursday 12 February 2004, Alpesh wrote: > Henrik - >=20 > Isn't this issue implementation specific? RFC3344 does not talk about HA= =20 > with multiple interfaces too. >=20 > I was wondering if such an implementation can specify one or more=20 > private addresses using a VSE? > How does the MN currently come to know the private address? >=20 > -a >=20 > Henrik Levkowetz wrote: >=20 > >Hello Yoshi, > > > > The case Hans describes is not the HA behind NAT case, it is just > >one where the HA is accessible through more than one interface. You > >could have this setup: > > > > > > ..... Internet .... ........ Home Link ......... > > . . . > > . +----+ +-------+ . > > . | | | MN | . > > .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| HA |<---------->|= 3.4.5.9| . > > . 3.4.5.1 | |3.4.5.254 +-------+ . > > . +----+ . > > . . . > > ............................ > > > > > >In this case, there is no NAT, but you would still need to know both the > >address of the HA on your home link, and the public address of the HA. I > >know that not all HAs out there is designed to be positioned in this > >manner, and I also believe that some support other ways of identifying > >the HA's home link interface, rather than explicitly listing it (or > >them). But all HAs are definitely not so simple that they can be fully > >described (assigned) through a single address. =20 > > > >I don't know if 2 addresses are enough, or if we need to be able to > >supply a list of addresses, or even a list of address/mask pairs, > >though. > > > > Henrik > > > > > > > >Friday 13 February 2004, Yoshiyuki Tsuda wrote: > > =20 > > > >>Hello Hans, > >> > >> Your comment is interesting, but it isn't directly related to > >> dynamic HA, but rather related to NAT traversal in case of > >> an HA sitting behind NAT, I'm afraid. So, we had better > >> discuss about your issue as an improvement of the current > >> NAT traversal RFC, or a separate draft. > >> I think, if you can describe that your issue has more close > >> relation to dynamic HA, rather than NAT traversal, it will > >> help the authers to answer to you. > >> > >>Cheers. > >>-Yoshi > >> > >>at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: > >> =20 > >> > >>>Sorry for being late with my comment, > >>> > >>>I think the proposal is a good proposal. And so does a few of my=20 > >>>customers who has asked for the functionality. To bad that they didn't= =20 > >>>flag their interest on the list. > >>> > >>>However, there is one thing that I think is needed to be added to the= =20 > >>>draft to make the function usable. The extension carries to little=20 > >>>information. > >>> > >>>Normally a router or gateway with HA functionality have several=20 > >>>interfaces. The natural setup is that the gateway is accessible to=20 > >>>internet on one interface (or address) and have the HA advertising the= =20 > >>>home network on another network. In many cases the home network have a= =20 > >>>private address space. > >>> > >>>The MN needs to know two things, > >>>1) The address which I can reach my home agent from internet (the=20 > >>>"external address")., > >>>2) The address which my home agent is advertising on the home network= =20 > >>>(the "internal address"). > >>> > >>>In the case with dynamic home agent assignment, the MN is informed abo= ut=20 > >>>the assigned "external address", but he is totally unaware of the=20 > >>>"internal address". Subsequently the MN will never be able to recognis= e=20 > >>>when he has entered his home network. Therefore this information needs= =20 > >>>to be relayed to him. Preferably in the Redirected HA address extensio= n=20 > >>>which then would look something like > >>> > >>> 0 1 2 3 > >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Type | Length | Reserved | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Home Agent External Address | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> | Home Agent Internal Address | > >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>> > >>> Home Agent External Address The IP address that the home agent is ext= ernally > >>> reachable. This might be a IP address on = the Home > >>> agent or a IP address of an external devi= ce that > >>> will redirect or map the IP packets to th= e home agent. > >>> > >>> Home Agent Internal Address The IP address of the home agent. This mi= ght be the > >>> same address as the Home Agent External A= ddress or an > >>> address on an internal network. This addr= ess MUST be > >>> the same address that the Home agent uses= for the > >>> Mobility Agent Advertisements. > >>> > >>> > >>>Best regards > >>>/// Hasse > >>> > >>>Henrik Levkowetz wrote: > >>> > >>> =20 > >>> > >>>>SECOND REQUEST - To date, no response to this WG last call has been > >>>>received. If enough responses are not received to support the > >>>>acceptance of this document, it *will not* be submitted to the IESG f= or > >>>>publication. Please respond to this WG last call. If you support > >>>>acceptance of the document without change, respond with a simple > >>>>acknowledgment, so that support for the document can be assessed. > >>>> > >>>>-------- > >>>> > >>>>This message announces a WG last call on "Mobile IPv4 Dynamic Home Ag= ent > >>>>Assignment" . The last ca= ll > >>>>will conclude at 24:00 UTC on Friday, 13th Feb 2004. > >>>> > >>>>Please respond to this WG last call. If you support acceptance of the > >>>>document without change, respond with a simple acknowledgment, so that > >>>>support for the document can be assessed. > >>>> > >>>>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechan= ism > >>>>for dynamic home agent assignment and HA redirection. The goal is to > >>>>provide a mechanism to assign an optimal HA for a Mobile IP session > >>>>while allowing any suitable method for HA selection. =20 > >>>> > >>>>This draft is available as > >>>> > >>>> > >>>> Regards, > >>>> Henrik > >>>>=20 > >>>> > >>>> =20 > >>>> > >>>--=20 > >>>Mip4 mailing list > >>>Mip4@ietf.org > >>>https://www.ietf.org/mailman/listinfo/mip4 > >>> =20 > >>> > >>--=20 > >>Mip4 mailing list > >>Mip4@ietf.org > >>https://www.ietf.org/mailman/listinfo/mip4 > >> =20 > >> > > > > =20 > > >=20 >=20 --Signature=_Fri__13_Feb_2004_00_26_16_+0100_hh+GVJviZCOykcxq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFALAuYeVhrtTJkXCMRAousAJ43AGZCABSLr+sL4LoLI6aGw6D7XACg7dP0 TrKIoVzzCgVwugZMBVXXkkc= =QUdr -----END PGP SIGNATURE----- --Signature=_Fri__13_Feb_2004_00_26_16_+0100_hh+GVJviZCOykcxq-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 20:40: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 UAA01343 for ; Thu, 12 Feb 2004 20:40: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 1ArSIw-0002H0-4v for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 20:39:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D1dgXF008734 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 20:39:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSIv-0002Gn-Vv for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 20:39: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 UAA01324 for ; Thu, 12 Feb 2004 20:39:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArSIr-000233-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 20:39:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArSIP-0001xJ-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 20:39:10 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1ArSHK-0001js-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 20:38:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1ArSHO-0006kx-TS for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 20:38:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSHL-0001zy-Vl; Thu, 12 Feb 2004 20:38:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSGt-0001q2-Jf for mip4@optimus.ietf.org; Thu, 12 Feb 2004 20:37: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 UAA00997 for ; Thu, 12 Feb 2004 20:37:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArSGp-0001dl-00 for mip4@ietf.org; Thu, 12 Feb 2004 20:37:31 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArSFI-0001Ir-00 for mip4@ietf.org; Thu, 12 Feb 2004 20:35:57 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1ArSDv-0000ze-00 for mip4@ietf.org; Thu, 12 Feb 2004 20:34:31 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1D1YSGv005044; Fri, 13 Feb 2004 10:34:28 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1D1YSqT021577; Fri, 13 Feb 2004 10:34:28 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA21570 ; Fri, 13 Feb 2004 10:34:28 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id KAA15268; Fri, 13 Feb 2004 10:34:28 +0900 (JST) Received: by toshiba.co.jp id KAA29722; Fri, 13 Feb 2004 10:34:27 +0900 (JST) Message-Id: <200402130134.KAA29722@toshiba.co.jp> Date: Fri, 13 Feb 2004 10:34:19 +0900 From: Yoshiyuki Tsuda Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) To: Henrik Levkowetz Cc: Alpesh , Hans S =?ISO-8859-1?Q?j=F6strand?= , mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <20040212234944.3e943921.henrik@levkowetz.com> References: <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <20040212234944.3e943921.henrik@levkowetz.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hello Henrik, Thank you for your explanation. My understanding was getting better. I have one more question: Do you think an MN needs to know both an external and an internal HA addresses at the first registration ? Here is another solution: - I think, while an MN is roaming in external subnets, the MN needs not know the internal HA address, but the external HA address. - When the MN moves to one of the internal subnets, the external HA may be able to redirect the registration request to the internal HA address by, say, Redirected HA address extension in the dynamic HA I-D. This kind of solutions can be extended to multiple interfaces. As an MN implementer, I hope MN configuration would not become too complicated... Thanks. -Yoshi at Thu, 12 Feb 2004 23:49:44 +0100 Henrik Levkowetz wrote: >Alpesh, > > In addition to Hans' comments, it bears mentioning that rfc3344 in >several places clearly discusses both FAs and HAs having multiple >interfaces. Explicitly limiting the dynamic HA assgnment mechanism >to work with only the one-interface case seems wrong. > >=09Henrik > >Thursday 12 February 2004, Alpesh wrote: >> Henrik - >>=20 >> Isn't this issue implementation specific? RFC3344 does not talk about HA= =20 >> with multiple interfaces too. >>=20 >> I was wondering if such an implementation can specify one or more=20 >> private addresses using a VSE? >> How does the MN currently come to know the private address? >>=20 >> -a >>=20 >> Henrik Levkowetz wrote: >>=20 >> >Hello Yoshi, >> > >> > The case Hans describes is not the HA behind NAT case, it is just >> >one where the HA is accessible through more than one interface. You >> >could have this setup: >> > >> > >> > ..... Internet .... ........ Home Link ......... >> > . . . >> > . +----+ +-------+ . >> > . | | | MN | . >> > .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| HA |<---------->= |3.4.5.9| . >> > . 3.4.5.1 | |3.4.5.254 +-------+ . >> > . +----+ . >> > . . . >> > ............................ >> > >> > >> >In this case, there is no NAT, but you would still need to know both th= e >> >address of the HA on your home link, and the public address of the HA. = I >> >know that not all HAs out there is designed to be positioned in this >> >manner, and I also believe that some support other ways of identifying >> >the HA's home link interface, rather than explicitly listing it (or >> >them). But all HAs are definitely not so simple that they can be fully= >> >described (assigned) through a single address. =20 >> > >> >I don't know if 2 addresses are enough, or if we need to be able to >> >supply a list of addresses, or even a list of address/mask pairs, >> >though. >> > >> >=09Henrik >> > >> > >> > >> >Friday 13 February 2004, Yoshiyuki Tsuda wrote: >> > =20 >> > >> >>Hello Hans, >> >> >> >> Your comment is interesting, but it isn't directly related to >> >> dynamic HA, but rather related to NAT traversal in case of >> >> an HA sitting behind NAT, I'm afraid. So, we had better >> >> discuss about your issue as an improvement of the current >> >> NAT traversal RFC, or a separate draft. >> >> I think, if you can describe that your issue has more close >> >> relation to dynamic HA, rather than NAT traversal, it will >> >> help the authers to answer to you. >> >> >> >>Cheers. >> >>-Yoshi >> >> >> >>at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: >> >> =20 >> >> >> >>>Sorry for being late with my comment, >> >>> >> >>>I think the proposal is a good proposal. And so does a few of my=20 >> >>>customers who has asked for the functionality. To bad that they didn'= t=20 >> >>>flag their interest on the list. >> >>> >> >>>However, there is one thing that I think is needed to be added to the= =20 >> >>>draft to make the function usable. The extension carries to little=20= >> >>>information. >> >>> >> >>>Normally a router or gateway with HA functionality have several=20 >> >>>interfaces. The natural setup is that the gateway is accessible to=20= >> >>>internet on one interface (or address) and have the HA advertising th= e=20 >> >>>home network on another network. In many cases the home network have = a=20 >> >>>private address space. >> >>> >> >>>The MN needs to know two things, >> >>>1) The address which I can reach my home agent from internet (the=20 >> >>>"external address")., >> >>>2) The address which my home agent is advertising on the home network= =20 >> >>>(the "internal address"). >> >>> >> >>>In the case with dynamic home agent assignment, the MN is informed ab= out=20 >> >>>the assigned "external address", but he is totally unaware of the=20 >> >>>"internal address". Subsequently the MN will never be able to recogni= se=20 >> >>>when he has entered his home network. Therefore this information need= s=20 >> >>>to be relayed to him. Preferably in the Redirected HA address extensi= on=20 >> >>>which then would look something like >> >>> >> >>> 0 1 2 3 >> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> | Type | Length | Reserved | >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> | Home Agent External Address | >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> | Home Agent Internal Address | >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>> >> >>> Home Agent External Address The IP address that the home agent is ex= ternally >> >>> reachable. This might be a IP address on= the Home >> >>> agent or a IP address of an external dev= ice that >> >>> will redirect or map the IP packets to t= he home agent. >> >>> >> >>> Home Agent Internal Address The IP address of the home agent. This m= ight be the >> >>> same address as the Home Agent External = Address or an >> >>> address on an internal network. This add= ress MUST be >> >>> the same address that the Home agent use= s for the >> >>> Mobility Agent Advertisements. >> >>> >> >>> >> >>>Best regards >> >>>/// Hasse >> >>> >> >>>Henrik Levkowetz wrote: >> >>> >> >>> =20 >> >>> >> >>>>SECOND REQUEST - To date, no response to this WG last call has been >> >>>>received. If enough responses are not received to support the >> >>>>acceptance of this document, it *will not* be submitted to the IESG = for >> >>>>publication. Please respond to this WG last call. If you support >> >>>>acceptance of the document without change, respond with a simple >> >>>>acknowledgment, so that support for the document can be assessed. >> >>>> >> >>>>-------- >> >>>> >> >>>>This message announces a WG last call on "Mobile IPv4 Dynamic Home A= gent >> >>>>Assignment" . The last c= all >> >>>>will conclude at 24:00 UTC on Friday, 13th Feb 2004. >> >>>> >> >>>>Please respond to this WG last call. If you support acceptance of t= he >> >>>>document without change, respond with a simple acknowledgment, so th= at >> >>>>support for the document can be assessed. >> >>>> >> >>>>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mecha= nism >> >>>>for dynamic home agent assignment and HA redirection. The goal is to= >> >>>>provide a mechanism to assign an optimal HA for a Mobile IP session >> >>>>while allowing any suitable method for HA selection. =20 >> >>>> >> >>>>This draft is available as >> >>>> >> >>>> >> >>>>=09Regards, >> >>>>=09=09Henrik >> >>>>=20 >> >>>> >> >>>> =20 >> >>>> >> >>>--=20 >> >>>Mip4 mailing list >> >>>Mip4@ietf.org >> >>>https://www.ietf.org/mailman/listinfo/mip4 >> >>> =20 >> >>> >> >>--=20 >> >>Mip4 mailing list >> >>Mip4@ietf.org >> >>https://www.ietf.org/mailman/listinfo/mip4 >> >> =20 >> >> >> > >> > =20 >> > >>=20 >>=20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 20:52: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 UAA01666 for ; Thu, 12 Feb 2004 20:52: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 1ArSUk-0002oo-Sr for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 20:51:54 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D1psXF010828 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 20:51:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSUk-0002oZ-MM for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 20:51: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 UAA01652 for ; Thu, 12 Feb 2004 20:51:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArSUg-000336-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 20:51:50 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArSTu-0002wM-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 20:51:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArSSu-0002nl-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 20:50:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSSx-0002hM-LB; Thu, 12 Feb 2004 20:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArSSZ-0002ff-7L for mip4@optimus.ietf.org; Thu, 12 Feb 2004 20:49: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 UAA01540 for ; Thu, 12 Feb 2004 20:49:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArSSU-0002nF-00 for mip4@ietf.org; Thu, 12 Feb 2004 20:49:34 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArSRY-0002il-00 for mip4@ietf.org; Thu, 12 Feb 2004 20:48:37 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1ArSRO-0002e4-00 for mip4@ietf.org; Thu, 12 Feb 2004 20:48:26 -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 1ArSRF-00010E-00; Fri, 13 Feb 2004 02:48:17 +0100 Date: Fri, 13 Feb 2004 02:48:17 +0100 From: Henrik Levkowetz To: Yoshiyuki Tsuda Cc: Alpesh , Hans S =?ISO-8859-1?Q?j=F6strand?= , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040213024817.692a5fbc.henrik@levkowetz.com> In-Reply-To: <200402130134.KAA29722@toshiba.co.jp> References: <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <20040212234944.3e943921.henrik@levkowetz.com> <200402130134.KAA29722@toshiba.co.jp> 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=_Fri__13_Feb_2004_02_48_17_+0100_Q77XrrmvSDQkeVgy" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Fri__13_Feb_2004_02_48_17_+0100_Q77XrrmvSDQkeVgy Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Yoshi, Friday 13 February 2004, Yoshiyuki Tsuda wrote: > Thank you for your explanation. My understanding was getting > better. I have one more question: > Do you think an MN needs to know both an external and an > internal HA addresses at the first registration ? That depends if it's in its home network or not at the time. If the HA does in fact have different addresses on its public interface(s) and its home link interface(s), the MN will need to know the internal address when it is at home, in order to know that it can and should de-register. =20 > Here is another solution: > - I think, while an MN is roaming in external subnets, the MN > needs not know the internal HA address, but the external HA > address. True. > - When the MN moves to one of the internal subnets, the > external HA may be able to redirect the registration request > to the internal HA address by, say, Redirected HA address > extension in the dynamic HA I-D. Yes, but the MN needs to understand that this is it's home network, too; otherwise it won't deregister and stop the HA from proxy arping on its behalf. > This kind of solutions can be extended to multiple interfaces. > As an MN implementer, I hope MN configuration would not > become too complicated... Right, I understand. Regards, Henrik >=20 > at Thu, 12 Feb 2004 23:49:44 +0100 Henrik Levkowetz wrote: > >Alpesh, > > > > In addition to Hans' comments, it bears mentioning that rfc3344 in > >several places clearly discusses both FAs and HAs having multiple > >interfaces. Explicitly limiting the dynamic HA assgnment mechanism > >to work with only the one-interface case seems wrong. > > > > Henrik > > > >Thursday 12 February 2004, Alpesh wrote: > >> Henrik - > >>=20 > >> Isn't this issue implementation specific? RFC3344 does not talk about = HA=20 > >> with multiple interfaces too. > >>=20 > >> I was wondering if such an implementation can specify one or more=20 > >> private addresses using a VSE? > >> How does the MN currently come to know the private address? > >>=20 > >> -a > >>=20 > >> Henrik Levkowetz wrote: > >>=20 > >> >Hello Yoshi, > >> > > >> > The case Hans describes is not the HA behind NAT case, it is just > >> >one where the HA is accessible through more than one interface. You > >> >could have this setup: > >> > > >> > > >> > ..... Internet .... ........ Home Link ......... > >> > . . . > >> > . +----+ +-------+ . > >> > . | | | MN | . > >> > .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| HA |<---------= ->|3.4.5.9| . > >> > . 3.4.5.1 | |3.4.5.254 +-------+ . > >> > . +----+ . > >> > . . . > >> > ............................ > >> > > >> > > >> >In this case, there is no NAT, but you would still need to know both = the > >> >address of the HA on your home link, and the public address of the HA= . I > >> >know that not all HAs out there is designed to be positioned in this > >> >manner, and I also believe that some support other ways of identifying > >> >the HA's home link interface, rather than explicitly listing it (or > >> >them). But all HAs are definitely not so simple that they can be ful= ly > >> >described (assigned) through a single address. =20 > >> > > >> >I don't know if 2 addresses are enough, or if we need to be able to > >> >supply a list of addresses, or even a list of address/mask pairs, > >> >though. > >> > > >> > Henrik > >> > > >> > > >> > > >> >Friday 13 February 2004, Yoshiyuki Tsuda wrote: > >> > =20 > >> > > >> >>Hello Hans, > >> >> > >> >> Your comment is interesting, but it isn't directly related to > >> >> dynamic HA, but rather related to NAT traversal in case of > >> >> an HA sitting behind NAT, I'm afraid. So, we had better > >> >> discuss about your issue as an improvement of the current > >> >> NAT traversal RFC, or a separate draft. > >> >> I think, if you can describe that your issue has more close > >> >> relation to dynamic HA, rather than NAT traversal, it will > >> >> help the authers to answer to you. > >> >> > >> >>Cheers. > >> >>-Yoshi > >> >> > >> >>at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: > >> >> =20 > >> >> > >> >>>Sorry for being late with my comment, > >> >>> > >> >>>I think the proposal is a good proposal. And so does a few of my=20 > >> >>>customers who has asked for the functionality. To bad that they did= n't=20 > >> >>>flag their interest on the list. > >> >>> > >> >>>However, there is one thing that I think is needed to be added to t= he=20 > >> >>>draft to make the function usable. The extension carries to little= =20 > >> >>>information. > >> >>> > >> >>>Normally a router or gateway with HA functionality have several=20 > >> >>>interfaces. The natural setup is that the gateway is accessible to= =20 > >> >>>internet on one interface (or address) and have the HA advertising = the=20 > >> >>>home network on another network. In many cases the home network hav= e a=20 > >> >>>private address space. > >> >>> > >> >>>The MN needs to know two things, > >> >>>1) The address which I can reach my home agent from internet (the=20 > >> >>>"external address")., > >> >>>2) The address which my home agent is advertising on the home netwo= rk=20 > >> >>>(the "internal address"). > >> >>> > >> >>>In the case with dynamic home agent assignment, the MN is informed = about=20 > >> >>>the assigned "external address", but he is totally unaware of the=20 > >> >>>"internal address". Subsequently the MN will never be able to recog= nise=20 > >> >>>when he has entered his home network. Therefore this information ne= eds=20 > >> >>>to be relayed to him. Preferably in the Redirected HA address exten= sion=20 > >> >>>which then would look something like > >> >>> > >> >>> 0 1 2 3 > >> >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> | Type | Length | Reserved | > >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> | Home Agent External Address | > >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> | Home Agent Internal Address | > >> >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> >>> > >> >>> Home Agent External Address The IP address that the home agent is = externally > >> >>> reachable. This might be a IP address = on the Home > >> >>> agent or a IP address of an external d= evice that > >> >>> will redirect or map the IP packets to= the home agent. > >> >>> > >> >>> Home Agent Internal Address The IP address of the home agent. This= might be the > >> >>> same address as the Home Agent Externa= l Address or an > >> >>> address on an internal network. This a= ddress MUST be > >> >>> the same address that the Home agent u= ses for the > >> >>> Mobility Agent Advertisements. > >> >>> > >> >>> > >> >>>Best regards > >> >>>/// Hasse > >> >>> > >> >>>Henrik Levkowetz wrote: > >> >>> > >> >>> =20 > >> >>> > >> >>>>SECOND REQUEST - To date, no response to this WG last call has been > >> >>>>received. If enough responses are not received to support the > >> >>>>acceptance of this document, it *will not* be submitted to the IES= G for > >> >>>>publication. Please respond to this WG last call. If you support > >> >>>>acceptance of the document without change, respond with a simple > >> >>>>acknowledgment, so that support for the document can be assessed. > >> >>>> > >> >>>>-------- > >> >>>> > >> >>>>This message announces a WG last call on "Mobile IPv4 Dynamic Home= Agent > >> >>>>Assignment" . The last= call > >> >>>>will conclude at 24:00 UTC on Friday, 13th Feb 2004. > >> >>>> > >> >>>>Please respond to this WG last call. If you support acceptance of= the > >> >>>>document without change, respond with a simple acknowledgment, so = that > >> >>>>support for the document can be assessed. > >> >>>> > >> >>>>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mec= hanism > >> >>>>for dynamic home agent assignment and HA redirection. The goal is = to > >> >>>>provide a mechanism to assign an optimal HA for a Mobile IP session > >> >>>>while allowing any suitable method for HA selection. =20 > >> >>>> > >> >>>>This draft is available as > >> >>>> > >> >>>> > >> >>>> Regards, > >> >>>> Henrik > >> >>>>=20 > >> >>>> > >> >>>> =20 > >> >>>> > >> >>>--=20 > >> >>>Mip4 mailing list > >> >>>Mip4@ietf.org > >> >>>https://www.ietf.org/mailman/listinfo/mip4 > >> >>> =20 > >> >>> > >> >>--=20 > >> >>Mip4 mailing list > >> >>Mip4@ietf.org > >> >>https://www.ietf.org/mailman/listinfo/mip4 > >> >> =20 > >> >> > >> > > >> > =20 > >> > > >>=20 > >>=20 --Signature=_Fri__13_Feb_2004_02_48_17_+0100_Q77XrrmvSDQkeVgy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFALCzheVhrtTJkXCMRAgyEAJ9qcxdInJK8n19AKAn89vZz8k0hAQCfbeYs hYlZiwP6fBuPf7ERYqrE/p0= =mwun -----END PGP SIGNATURE----- --Signature=_Fri__13_Feb_2004_02_48_17_+0100_Q77XrrmvSDQkeVgy-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 12 21:31: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 VAA03161 for ; Thu, 12 Feb 2004 21:31: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 1ArT6J-0005SC-Ir for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 21:30:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D2UheF020964 for mip4-archive@odin.ietf.org; Thu, 12 Feb 2004 21:30:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArT6J-0005S3-D3 for mip4-web-archive@optimus.ietf.org; Thu, 12 Feb 2004 21:30: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 VAA03157 for ; Thu, 12 Feb 2004 21:30:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArT6E-0006hx-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 21:30:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArT5K-0006cy-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 21:29:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArT4c-0006Xo-00 for mip4-web-archive@ietf.org; Thu, 12 Feb 2004 21:28:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArT4f-0005KD-Kb; Thu, 12 Feb 2004 21: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 1ArT4R-0005Js-RN for mip4@optimus.ietf.org; Thu, 12 Feb 2004 21:28: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 VAA03092 for ; Thu, 12 Feb 2004 21:28:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArT4N-0006We-00 for mip4@ietf.org; Thu, 12 Feb 2004 21:28:43 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArT3L-0006RA-00 for mip4@ietf.org; Thu, 12 Feb 2004 21:27:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ArT2t-0006Ll-00 for mip4@ietf.org; Thu, 12 Feb 2004 21:27:11 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 12 Feb 2004 18:27:43 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i1D2Qf1m002801; Thu, 12 Feb 2004 18:26:42 -0800 (PST) Received: from kleung-w2k01.cisco.com (dhcp-128-107-163-78.cisco.com [128.107.163.78]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQG35936; Thu, 12 Feb 2004 18:26:40 -0800 (PST) Message-Id: <4.3.2.7.2.20040212143259.0269bc98@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Feb 2004 18:26:40 -0800 To: Hans =?iso-8859-1?Q?Sj=F6strand?= From: Kent Leung Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Cc: mip4@ietf.org In-Reply-To: <402BA0D4.6090709@ipunplugged.com> References: <20040209153540.08b06367.henrik@levkowetz.com> <20040209153540.08b06367.henrik@levkowetz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hans. Doesn't this scheme assume a specific home/foreign domain network detection mechanism? This would allow the MN to use the HA IP addresses to find out if it is on its home domain network or not. So this is one possible=20 solution to a problem statement of "MN needs to be able to detect when it is at home domain or foreign domain network", right? Seems to me that this problem statement needs to be addressed and the solution be agreed upon. And at that point, also ensure that dynamic HA assignment can still be achieved. Other possible (and I do mean just possibilities) solutions to the home domain detection issue could be DHCP Domain Name Option, FA advertising domain name, HA logic to detect based on CoA address, etc. Since we haven't decided on a solution yet for that problem, it doesn't seem to make sense to embed it into the Dynamic HA Assignment function. However, this does bring out the issue of HA address changing while the HoA remains the same. Since the HA box may have multiple interfaces, it shouldn't matter which IP address is used for tunnel endpoint as long as the HoA is reachable. When MN is outside, it uses public HA. And when MN is inside, it can use private HA. Dynamic HA assignment happens when MN first registers. And the draft's method of redirecting can be applied to notify MN when it moves to the other side of the network. Kent At 04:50 PM 2/12/2004 +0100, Hans Sj=F6strand wrote: >Sorry for being late with my comment, > >I think the proposal is a good proposal. And so does a few of my customers= =20 >who has asked for the functionality. To bad that they didn't flag their=20 >interest on the list. > >However, there is one thing that I think is needed to be added to the=20 >draft to make the function usable. The extension carries to little= information. > >Normally a router or gateway with HA functionality have several=20 >interfaces. The natural setup is that the gateway is accessible to=20 >internet on one interface (or address) and have the HA advertising the=20 >home network on another network. In many cases the home network have a=20 >private address space. > >The MN needs to know two things, >1) The address which I can reach my home agent from internet (the=20 >"external address")., >2) The address which my home agent is advertising on the home network (the= =20 >"internal address"). > >In the case with dynamic home agent assignment, the MN is informed about=20 >the assigned "external address", but he is totally unaware of the=20 >"internal address". Subsequently the MN will never be able to recognise=20 >when he has entered his home network. Therefore this information needs to= =20 >be relayed to him. Preferably in the Redirected HA address extension which= =20 >then would look something like > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Home Agent External Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Home Agent Internal Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Home Agent External Address The IP address that the home agent is= externally > reachable. This might be a IP address on the= =20 > Home > agent or a IP address of an external device= that > will redirect or map the IP packets to the=20 > home agent. > > Home Agent Internal Address The IP address of the home agent. This might= =20 > be the > same address as the Home Agent External=20 > Address or an > address on an internal network. This address= =20 > MUST be > the same address that the Home agent uses=20 > for the > Mobility Agent Advertisements. > > >Best regards >/// Hasse > >Henrik Levkowetz wrote: > >>SECOND REQUEST - To date, no response to this WG last call has been >>received. If enough responses are not received to support the >>acceptance of this document, it *will not* be submitted to the IESG for >>publication. Please respond to this WG last call. If you support >>acceptance of the document without change, respond with a simple >>acknowledgment, so that support for the document can be assessed. >> >>-------- >> >>This message announces a WG last call on "Mobile IPv4 Dynamic Home Agent >>Assignment" . The last call >>will conclude at 24:00 UTC on Friday, 13th Feb 2004. >> >>Please respond to this WG last call. If you support acceptance of the >>document without change, respond with a simple acknowledgment, so that >>support for the document can be assessed. >> >>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mechanism >>for dynamic home agent assignment and HA redirection. The goal is to >>provide a mechanism to assign an optimal HA for a Mobile IP session >>while allowing any suitable method for HA selection. >> >>This draft is available as >> >> >> Regards, >> Henrik >> > > >-- >Mip4 mailing list >Mip4@ietf.org >https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 13 02:55: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 CAA27197 for ; Fri, 13 Feb 2004 02:55: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 1ArYA6-0002DU-0Y for mip4-archive@odin.ietf.org; Fri, 13 Feb 2004 02:54:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1D7sv2T008514 for mip4-archive@odin.ietf.org; Fri, 13 Feb 2004 02:54:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArYA4-0002DF-O8 for mip4-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 02:54: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 CAA27165 for ; Fri, 13 Feb 2004 02:54:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY9x-0004L8-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 02:54:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY94-0004Ea-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 02:53:55 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArY89-00047c-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 02:52:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY8F-0001oO-9C; Fri, 13 Feb 2004 02:53:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArY7M-0001ly-1Z for mip4@optimus.ietf.org; Fri, 13 Feb 2004 02:52: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 CAA27081 for ; Fri, 13 Feb 2004 02:52:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArY7E-00040u-00 for mip4@ietf.org; Fri, 13 Feb 2004 02:52:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArY6D-0003uj-00 for mip4@ietf.org; Fri, 13 Feb 2004 02:50:58 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1ArY5d-0003of-00 for mip4@ietf.org; Fri, 13 Feb 2004 02:50: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 1ArY5f-00016o-00; Fri, 13 Feb 2004 08:50:23 +0100 Date: Fri, 13 Feb 2004 08:50:17 +0100 From: Henrik Levkowetz To: mip4@ietf.org Cc: Alpesh Subject: Re: [Mip4] Re: [issue43] draft-ietf-mip4-experimental-messages Message-Id: <20040213085017.7a3cda3f.henrik@levkowetz.com> In-Reply-To: <402920E6.9040002@cisco.com> References: <20040126224932.6dd9a0f5.henrik@levkowetz.com> <402920E6.9040002@cisco.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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.0 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alpesh, Tuesday 10 February 2004, Alpesh wrote: > Regarding this issue if we should define experimental subtypes for > existing option types, > our position is that this is not needed. Yes, I know :-) However, I believe they may be needed .. > The definition of experimental options permits the usage of experimental > subtypes. For new extensions, yes, but not in a straightforward manner for existing extensions. .. > Also, reserving experimental subtypes for existing options may not be a > good idea as some > implementations may already be using unallocated numbers (past > experience). Do you have evidence of unallocated subtypes being used currently? We made a strong effort to clean up this area last year. > Our opinion is that we should move forward by closing this issue. I don't quite understand why you resist the idea of allocate an experimental subtype number - on my part I see it as beneficial, and I would like to understand why you see it as harmful; then we should be able to make forward progress on this issue :-) Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 13 10:43: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 KAA15608 for ; Fri, 13 Feb 2004 10:43: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 1ArfT5-0005kM-AX for mip4-archive@odin.ietf.org; Fri, 13 Feb 2004 10:43:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFh3pu022086 for mip4-archive@odin.ietf.org; Fri, 13 Feb 2004 10:43:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfT5-0005k9-4u for mip4-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 10:43: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 KAA15560 for ; Fri, 13 Feb 2004 10:42:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfT2-0003kx-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 10:43:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfS3-0003fS-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 10:42:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1ArfR5-0003b1-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 10:40:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfR6-0005O0-Ma; Fri, 13 Feb 2004 10:41:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfQ9-0005Ko-Lo for mip4@optimus.ietf.org; Fri, 13 Feb 2004 10:40: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 KAA15413 for ; Fri, 13 Feb 2004 10:39:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfQ7-0003X2-00 for mip4@ietf.org; Fri, 13 Feb 2004 10:39:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfP8-0003TN-00 for mip4@ietf.org; Fri, 13 Feb 2004 10:38:59 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1ArfOJ-0003KZ-00 for mip4@ietf.org; Fri, 13 Feb 2004 10:38:07 -0500 Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id i1DFbDjv011936; Fri, 13 Feb 2004 16:37:13 +0100 Message-ID: <402CEF0F.7050003@ipunplugged.com> Date: Fri, 13 Feb 2004 16:36:47 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: Alpesh CC: Henrik Levkowetz , Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> In-Reply-To: <402BE6BF.2030307@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailgw.local.ipunplugged.com id i1DFbDjv011936 Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Alpesh, After thinking about your proposal I start to lean towards your proposal=20 using a VSE for this purpose. There are several advantages in not incorporating anything else than the=20 redirected HA address in the extension exactly as you originally proposed. Because what I really, really want is not an address, it's a way to=20 identify my home agent. and when the NAI draft is published, I can do=20 that a lot better with a NAI in the HA adverticement rather than a=20 internal address. It woulds be bad in this case if we lock in the=20 dynamic HA assignment in an old-school limited solution. With a separate configuration extension we also get the freedom that the=20 additional configuration very well might take place in the registration=20 withe the assigned HA, not neccesarily in the first routndtrip with teh=20 requested HA. Also, there are more goodies that I would like to transfer to the MN,=20 which indeed are implementation specific, so maybe I'll use a VSE anyway. Thanks for the comments and sorry for stirring up dust. A few smaller comments though 1. The extension is a little odd. In most other IETF protocools (atleast=20 the ones I've been in) tries to maintain 4 byte alignment. It would be=20 nice if the extension looked like this instead. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Redirected-HA-Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. I'm not terribly happy about the described behavior for the unicast ad= dress case. In the proposed scheme it's impossible for the HA (or HA clus= ter or whatever) to actually know if the MN will accept and/or support a = redirect. This may very well result in that a client without support for = dynamic HA assignments gets unneccassary rejects from the HA's even thoug= h it's perfectly ok to register.=20 To solve this, one way would be to mandate the MN always to send the exte= nsion if the dynamic HA assignment is supported and configured. Another w= ay is to remove the option to have a unicast address in the HA field. I d= idn't quite understand the advantage over just always use ALL-ZERO-ONE-AD= DR.=20 Alpesh wrote: > Henrik - > > Isn't this issue implementation specific? RFC3344 does not talk about=20 > HA with multiple interfaces too. > > I was wondering if such an implementation can specify one or more=20 > private addresses using a VSE? > How does the MN currently come to know the private address? > > -a > > Henrik Levkowetz wrote: > >>Hello Yoshi, >> >> The case Hans describes is not the HA behind NAT case, it is just >>one where the HA is accessible through more than one interface. You >>could have this setup: >> >> >> ..... Internet .... ........ Home Link ......... >> . . . >> . +----+ +-------+ . >> . | | | MN | . >> .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| HA |<---------->= |3.4.5.9| . >> . 3.4.5.1 | |3.4.5.254 +-------+ . >> . +----+ . >> . . . >> ............................ >> >> >>In this case, there is no NAT, but you would still need to know both th= e >>address of the HA on your home link, and the public address of the HA. = I >>know that not all HAs out there is designed to be positioned in this >>manner, and I also believe that some support other ways of identifying >>the HA's home link interface, rather than explicitly listing it (or >>them). But all HAs are definitely not so simple that they can be fully >>described (assigned) through a single address. =20 >> >>I don't know if 2 addresses are enough, or if we need to be able to >>supply a list of addresses, or even a list of address/mask pairs, >>though. >> >> Henrik >> >> >> >>Friday 13 February 2004, Yoshiyuki Tsuda wrote: >> =20 >> >>>Hello Hans, >>> >>> Your comment is interesting, but it isn't directly related to >>> dynamic HA, but rather related to NAT traversal in case of >>> an HA sitting behind NAT, I'm afraid. So, we had better >>> discuss about your issue as an improvement of the current >>> NAT traversal RFC, or a separate draft. >>> I think, if you can describe that your issue has more close >>> relation to dynamic HA, rather than NAT traversal, it will >>> help the authers to answer to you. >>> >>>Cheers. >>>-Yoshi >>> >>>at Thu, 12 Feb 2004 16:50:44 +0100 Hans Sj=F6strand wrote: >>> =20 >>> >>>>Sorry for being late with my comment, >>>> >>>>I think the proposal is a good proposal. And so does a few of my=20 >>>>customers who has asked for the functionality. To bad that they didn'= t=20 >>>>flag their interest on the list. >>>> >>>>However, there is one thing that I think is needed to be added to the= =20 >>>>draft to make the function usable. The extension carries to little=20 >>>>information. >>>> >>>>Normally a router or gateway with HA functionality have several=20 >>>>interfaces. The natural setup is that the gateway is accessible to=20 >>>>internet on one interface (or address) and have the HA advertising th= e=20 >>>>home network on another network. In many cases the home network have = a=20 >>>>private address space. >>>> >>>>The MN needs to know two things, >>>>1) The address which I can reach my home agent from internet (the=20 >>>>"external address")., >>>>2) The address which my home agent is advertising on the home network= =20 >>>>(the "internal address"). >>>> >>>>In the case with dynamic home agent assignment, the MN is informed ab= out=20 >>>>the assigned "external address", but he is totally unaware of the=20 >>>>"internal address". Subsequently the MN will never be able to recogni= se=20 >>>>when he has entered his home network. Therefore this information need= s=20 >>>>to be relayed to him. Preferably in the Redirected HA address extensi= on=20 >>>>which then would look something like >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Type | Length | Reserved | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Home Agent External Address | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Home Agent Internal Address | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Home Agent External Address The IP address that the home agent is ex= ternally >>>> reachable. This might be a IP address on= the Home >>>> agent or a IP address of an external dev= ice that >>>> will redirect or map the IP packets to t= he home agent. >>>> >>>> Home Agent Internal Address The IP address of the home agent. This m= ight be the >>>> same address as the Home Agent External = Address or an >>>> address on an internal network. This add= ress MUST be >>>> the same address that the Home agent use= s for the >>>> Mobility Agent Advertisements. >>>> >>>> >>>>Best regards >>>>/// Hasse >>>> >>>>Henrik Levkowetz wrote: >>>> >>>> =20 >>>> >>>>>SECOND REQUEST - To date, no response to this WG last call has been >>>>>received. If enough responses are not received to support the >>>>>acceptance of this document, it *will not* be submitted to the IESG = for >>>>>publication. Please respond to this WG last call. If you support >>>>>acceptance of the document without change, respond with a simple >>>>>acknowledgment, so that support for the document can be assessed. >>>>> >>>>>-------- >>>>> >>>>>This message announces a WG last call on "Mobile IPv4 Dynamic Home A= gent >>>>>Assignment" . The last c= all >>>>>will conclude at 24:00 UTC on Friday, 13th Feb 2004. >>>>> >>>>>Please respond to this WG last call. If you support acceptance of t= he >>>>>document without change, respond with a simple acknowledgment, so th= at >>>>>support for the document can be assessed. >>>>> >>>>>draft-ietf-mip4-dynamic-assignment-00.txt proposes a messaging mecha= nism >>>>>for dynamic home agent assignment and HA redirection. The goal is to >>>>>provide a mechanism to assign an optimal HA for a Mobile IP session >>>>>while allowing any suitable method for HA selection. =20 >>>>> >>>>>This draft is available as >>>>> >>>>> >>>>> Regards, >>>>> Henrik >>>>>=20 >>>>> >>>>> =20 >>>>> >>>>--=20 >>>>Mip4 mailing list >>>>Mip4@ietf.org >>>>https://www.ietf.org/mailman/listinfo/mip4 >>>> =20 >>>> >>>--=20 >>>Mip4 mailing list >>>Mip4@ietf.org >>>https://www.ietf.org/mailman/listinfo/mip4 >>> =20 >>> >> >> =20 >> > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 13 10:53: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 KAA15972 for ; Fri, 13 Feb 2004 10:53: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 1Arfck-00072k-G5 for mip4-archive@odin.ietf.org; Fri, 13 Feb 2004 10:53:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DFr2ZH027068 for mip4-archive@odin.ietf.org; Fri, 13 Feb 2004 10:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfck-00072V-Bs for mip4-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 10:53: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 KAA15959 for ; Fri, 13 Feb 2004 10:52:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Arfch-0004T7-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 10:52:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Arfbj-0004PJ-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 10:51:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Arfal-0004Lj-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 10:50:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Arfam-0006tu-RB; Fri, 13 Feb 2004 10:51:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ArfZp-0006rG-96 for mip4@optimus.ietf.org; Fri, 13 Feb 2004 10:50: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 KAA15904 for ; Fri, 13 Feb 2004 10:49:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ArfZm-0004IU-00 for mip4@ietf.org; Fri, 13 Feb 2004 10:49:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1ArfYu-0004F8-00 for mip4@ietf.org; Fri, 13 Feb 2004 10:49:04 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ArfY3-00046q-00 for mip4@ietf.org; Fri, 13 Feb 2004 10:48:11 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i1DFlbvV010658; Fri, 13 Feb 2004 07:47:37 -0800 (PST) Received: from kleung-w2k01.cisco.com (sjc-vpn2-1114.cisco.com [10.21.116.90]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQG68586; Fri, 13 Feb 2004 07:47:36 -0800 (PST) Message-Id: <4.3.2.7.2.20040213073455.02601b88@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 13 Feb 2004 07:47:36 -0800 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] Re: [issue43] draft-ietf-mip4-experimental-messages Cc: mip4@ietf.org, Alpesh In-Reply-To: <20040213085017.7a3cda3f.henrik@levkowetz.com> References: <402920E6.9040002@cisco.com> <20040126224932.6dd9a0f5.henrik@levkowetz.com> <402920E6.9040002@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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.2 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 I guess we're trying to draw the line between functional purpose such as experimental types vs. ease of coding purpose such as experimental subtypes. Seems like the experimental type provides the capability needed for any research and development experiments. Not sure if there's a need to go beyond functional capability? We're open to subtype support if there's more consensus in the WG. So far, we haven't seen a clear functional need. Others can chime in? I think we can get quick resolution on this issue when others feel one way or the other and voice their opinions. Thanks. Kent At 08:50 AM 2/13/2004 +0100, Henrik Levkowetz wrote: >Hi Alpesh, > >Tuesday 10 February 2004, Alpesh wrote: > > Regarding this issue if we should define experimental subtypes for > > existing option types, > > our position is that this is not needed. > >Yes, I know :-) However, I believe they may be needed >.. > > The definition of experimental options permits the usage of experimental > > subtypes. > >For new extensions, yes, but not in a straightforward manner for existing >extensions. >.. > > Also, reserving experimental subtypes for existing options may not be a > > good idea as some > > implementations may already be using unallocated numbers (past > > experience). > >Do you have evidence of unallocated subtypes being used currently? We >made a strong effort to clean up this area last year. > > > Our opinion is that we should move forward by closing this issue. > >I don't quite understand why you resist the idea of allocate an >experimental subtype number - on my part I see it as beneficial, and I >would like to understand why you see it as harmful; then we should be >able to make forward progress on this issue :-) > > Henrik > >-- >Mip4 mailing list >Mip4@ietf.org >https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 13 13:40:38 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 NAA24693 for ; Fri, 13 Feb 2004 13:40:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriET-0005b4-Il for mip4-archive@odin.ietf.org; Fri, 13 Feb 2004 13:40:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1DIe96j021508 for mip4-archive@odin.ietf.org; Fri, 13 Feb 2004 13:40:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriER-0005X5-2G for mip4-web-archive@optimus.ietf.org; Fri, 13 Feb 2004 13:40: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 NAA24653 for ; Fri, 13 Feb 2004 13:40:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriEO-0004gt-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 13:40:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriDP-0004ck-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 13:39:04 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AriCT-0004Yt-00 for mip4-web-archive@ietf.org; Fri, 13 Feb 2004 13:38:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriCT-0005Ge-4f; Fri, 13 Feb 2004 13:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AriBe-00056H-B4 for mip4@optimus.ietf.org; Fri, 13 Feb 2004 13:37: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 NAA24600 for ; Fri, 13 Feb 2004 13:37:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AriBc-0004Vs-00 for mip4@ietf.org; Fri, 13 Feb 2004 13:37:12 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AriAp-0004SI-00 for mip4@ietf.org; Fri, 13 Feb 2004 13:36:24 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AriAS-0004Ly-00 for mip4@ietf.org; Fri, 13 Feb 2004 13:36:00 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1DIZAjv014258; Fri, 13 Feb 2004 19:35:10 +0100 Date: Fri, 13 Feb 2004 19:35:09 +0100 From: Henrik Levkowetz To: Hans =?ISO-8859-1?Q?Sj=F6strand?= Cc: Alpesh , Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040213193509.16ac6bd4.henrik@levkowetz.com> In-Reply-To: <402CEF0F.7050003@ipunplugged.com> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <402CEF0F.7050003@ipunplugged.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=_Fri__13_Feb_2004_19_35_09_+0100_TPQiimDJ5Ag/lG==" X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Fri__13_Feb_2004_19_35_09_+0100_TPQiimDJ5Ag/lG== Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Friday, 13 Feb 2004, Hans Sj=F6strand wrote: > After thinking about your proposal I start to lean towards your > proposal using a VSE for this purpose. >=20 > There are several advantages in not incorporating anything else than > the redirected HA address in the extension exactly as you originally > proposed. >=20 > Because what I really, really want is not an address, it's a way to=20 > identify my home agent. and when the NAI draft is published, I can do=20 > that a lot better with a NAI in the HA adverticement rather than a=20 > internal address. It woulds be bad in this case if we lock in the=20 > dynamic HA assignment in an old-school limited solution. >=20 > With a separate configuration extension we also get the freedom that > the additional configuration very well might take place in the > registration withe the assigned HA, not neccesarily in the first > routndtrip with teh requested HA. This is a very good point. Only the assigned HA should have to know anything about it's detailed setup, all others should only have to know about the addresses of alternative HAs. > Also, there are more goodies that I would like to transfer to the MN,=20 > which indeed are implementation specific, so maybe I'll use a VSE > anyway. >=20 > Thanks for the comments and sorry for stirring up dust. >=20 > A few smaller comments though >=20 > 1. The extension is a little odd. In most other IETF protocools > (atleast the ones I've been in) tries to maintain 4 byte alignment. It > would be nice if the extension looked like this instead. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Reserved | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Redirected-HA-Address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Actually, there's also another consideration, which is that we probably want to include a subtype here, to avoid unnecessary depletion of the extension number space. I think that possible future extensions to be sent from the Assigned HA to give more details about itself might have the same type, and different subtypes compared to this. We then also have the advantage of following the recommendation in 3344 section 1.9 :-) > 2. I'm not terribly happy about the described behavior for the unicast > address case. In the proposed scheme it's impossible for the HA (or HA > cluster or whatever) to actually know if the MN will accept and/or > support a redirect. This may very well result in that a client without > support for dynamic HA assignments gets unneccassary rejects from the > HA's even though it's perfectly ok to register.=20 >From my reading of Section 4.2 of the draft, it seems that a redirect when there is an unicast address in the HA field may only be done when the unicast address doesn't match any of the HA's interfaces. So a properly formed request would never be in danger of rejection. However, see more below. > To solve this, one way would be to mandate the MN always to send the > extension if the dynamic HA assignment is supported and configured. > Another way is to remove the option to have a unicast address in the > HA field. I didn't quite understand the advantage over just always use > ALL-ZERO-ONE-ADDR.=20 It seems to me that there are two ways the HA may receive a request with a unicast address which does not match its own address: 1) The MN places different HA addresses in the request HA field and in the IP header destination address. I don't see that this gives any extra functionality over using the ALL-ZERO-ONE-ADDR. 2) The FA decides to forward the registration request to a different HA than the one requested by the MN. In this case, the draft suggests that the discrepancy be observed by the HA, which may respond with a REDIRECT-HA-REQ error value. =20 Now, I don't have any great issue with the HA side of this, but I'm quite doubtful as to permitting a FA to make the decision of forwarding a registration to another HA than the one requested by the MN. And what is the the advantage here? Henrik --=20 If you lend someone $20 and never see that person again, it was probably worth it. --Signature=_Fri__13_Feb_2004_19_35_09_+0100_TPQiimDJ5Ag/lG== Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFALRjdeVhrtTJkXCMRAjmcAJ46pOn9mtkVqCF4aOKJvB5MrDRXiwCfT7Q+ b9t0ORXauLV0z9UR1PivRD8= =/SbP -----END PGP SIGNATURE----- --Signature=_Fri__13_Feb_2004_19_35_09_+0100_TPQiimDJ5Ag/lG==-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 16 15:43: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 PAA20584 for ; Mon, 16 Feb 2004 15:43: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 1AspZm-0003Me-L0 for mip4-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GKgklZ012928 for mip4-archive@odin.ietf.org; Mon, 16 Feb 2004 15:42:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspZm-0003MR-Gl for mip4-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 15:42: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 PAA20497 for ; Mon, 16 Feb 2004 15:42:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AspZl-0002fb-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 15:42:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AspYs-0002Xi-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 15:41:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AspY5-0002Rj-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 15: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 1AspY5-0002VZ-M9; Mon, 16 Feb 2004 15:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AspXB-00026G-RL for mip4@optimus.ietf.org; Mon, 16 Feb 2004 15:40:05 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19899; Mon, 16 Feb 2004 15:40:03 -0500 (EST) Message-Id: <200402162040.PAA19899@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 16 Feb 2004 15:40:03 -0500 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-vpn-problem-statement-02.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 IPv4 Working Group of the IETF. Title : Problem Statement: Mobile IPv4 Traversal of VPN Gateways Author(s) : F. Adrangi, H. Levkowetz Filename : draft-ietf-mip4-vpn-problem-statement-02.txt Pages : 21 Date : 2004-2-16 Deploying Mobile-IP v4 in networks which are connected to the Internet through a VPN (Virtual Private Network) gateway presents some problems which do not currently have well-described solutions. This document aims to describe and illustrate these problems, and propose some guidelines for possible solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-vpn-problem-statement-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-vpn-problem-statement-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-vpn-problem-statement-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-2-16123115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-vpn-problem-statement-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-vpn-problem-statement-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-2-16123115.I-D@ietf.org> --OtherAccess-- --NextPart-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 16 17:55: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 RAA05981 for ; Mon, 16 Feb 2004 17:55: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 1AsrdO-0006iO-Gn for mip4-archive@odin.ietf.org; Mon, 16 Feb 2004 17:54:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GMsccn025808 for mip4-archive@odin.ietf.org; Mon, 16 Feb 2004 17:54:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrdO-0006iB-8h for mip4-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 17:54: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 RAA05948 for ; Mon, 16 Feb 2004 17:54:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsrdL-0005Z8-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 17:54:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsrcO-0005Wc-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 17:53:37 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asrbn-0005UB-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 17:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asrbp-0006fK-CA; Mon, 16 Feb 2004 17: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 1AsrbP-0006eO-PI for mip4@optimus.ietf.org; Mon, 16 Feb 2004 17:52: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 RAA05914 for ; Mon, 16 Feb 2004 17:52:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsrbN-0005TT-00 for mip4@ietf.org; Mon, 16 Feb 2004 17:52:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsraS-0005RR-00 for mip4@ietf.org; Mon, 16 Feb 2004 17:51:37 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AsrZn-0005ME-00 for mip4@ietf.org; Mon, 16 Feb 2004 17:50:55 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1GMo4r01919; Mon, 16 Feb 2004 16:50:04 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1GMo2m25939; Mon, 16 Feb 2004 16:50:02 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HT78RB-0001IO-00; Mon, 16 Feb 2004 17:49:59 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16433.18709.548019.259179@gargle.gargle.HOWL> Date: Mon, 16 Feb 2004 16:49:57 -0600 From: Pete McCann To: Henrik Levkowetz Cc: Hans =?ISO-8859-1?Q?Sj=F6strand?= , Alpesh , Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) In-Reply-To: <20040213193509.16ac6bd4.henrik@levkowetz.com> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <402CEF0F.7050003@ipunplugged.com> <20040213193509.16ac6bd4.henrik@levkowetz.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hi, Henrik Levkowetz writes: > On Friday, 13 Feb 2004, Hans Sj=F6strand wrote: >=20 > > After thinking about your proposal I start to lean towards your > > proposal using a VSE for this purpose. > >=20 > > There are several advantages in not incorporating anything else th= an > > the redirected HA address in the extension exactly as you original= ly > > proposed. > >=20 > > Because what I really, really want is not an address, it's a way t= o=20 > > identify my home agent. and when the NAI draft is published, I can= do=20 > > that a lot better with a NAI in the HA adverticement rather than a= =20 > > internal address. It woulds be bad in this case if we lock in the=20= > > dynamic HA assignment in an old-school limited solution. > >=20 > > With a separate configuration extension we also get the freedom th= at > > the additional configuration very well might take place in the > > registration withe the assigned HA, not neccesarily in the first > > routndtrip with teh requested HA. >=20 > This is a very good point. Only the assigned HA should have to know= > anything about it's detailed setup, all others should only have to > know about the addresses of alternative HAs. Even if the information comes from the assigned HA, I am a little bit confused about the model here. When up and running, a mobile node knows the following: 1) its home address 2) its home subnet prefix (length) 3) its home agent address, and a security association with that home agent. Now, we don't really need to know the home agent's address in order to do home link detection; we just need to see a router advertisement that says we have returned to the home prefix, right? Are we saying there will be cases where the home agent address is not on the home subnet prefix? I suppose that is possible, and it presents no big problem: the HA could still be reachable at its "external" IP address even from within the "internal" subnet, modulo firewall configuration, so the MN could send a de-registration from anywhere. Moreover, is it true that the data structures inside Mobile IP clients can remember more than one IP address for a given mobility security association? Or would it be more proper to think of these as separate security associations with separate entities, even though they might have some keys/SPIs in common? It seems to me that configuring information about alternative HA addresses is isomorphic to the problem of configuring alternative HAs, period, and it should stay that way. > > Also, there are more goodies that I would like to transfer to the = MN,=20 > > which indeed are implementation specific, so maybe I'll use a VSE > > anyway. > >=20 > > Thanks for the comments and sorry for stirring up dust. > >=20 > > A few smaller comments though > >=20 > > 1. The extension is a little odd. In most other IETF protocools > > (atleast the ones I've been in) tries to maintain 4 byte alignment= . It > > would be nice if the extension looked like this instead. > >=20 > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= > > | Type | Length | Reserved |= > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= > > | Redirected-HA-Address |= > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= >=20 > Actually, there's also another consideration, which is that we proba= bly > want to include a subtype here, to avoid unnecessary depletion of th= e > extension number space. I think that possible future extensions to = be > sent from the Assigned HA to give more details about itself might ha= ve > the same type, and different subtypes compared to this. We then als= o > have the advantage of following the recommendation in 3344 section 1= .9 > :-) >=20 > > 2. I'm not terribly happy about the described behavior for the uni= cast > > address case. In the proposed scheme it's impossible for the HA (o= r HA > > cluster or whatever) to actually know if the MN will accept and/or= > > support a redirect. This may very well result in that a client wit= hout > > support for dynamic HA assignments gets unneccassary rejects from = the > > HA's even though it's perfectly ok to register.=20 >=20 > From my reading of Section 4.2 of the draft, it seems that a redirec= t > when there is an unicast address in the HA field may only be done wh= en > the unicast address doesn't match any of the HA's interfaces. So a > properly formed request would never be in danger of rejection. Howe= ver, > see more below. > > > To solve this, one way would be to mandate the MN always to send t= he > > extension if the dynamic HA assignment is supported and configured= . > > Another way is to remove the option to have a unicast address in t= he > > HA field. I didn't quite understand the advantage over just always= use > > ALL-ZERO-ONE-ADDR.=20 >=20 > It seems to me that there are two ways the HA may receive a request = with > a unicast address which does not match its own address: >=20 > 1) The MN places different HA addresses in the request HA field and = in > the IP header destination address. I don't see that this gives any > extra functionality over using the ALL-ZERO-ONE-ADDR. I agree. Maybe we should adopt this convention as an indication of support for the rejection code. > 2) The FA decides to forward the registration request to a different= HA > than the one requested by the MN. In this case, the draft suggests = that > the discrepancy be observed by the HA, which may respond with a > REDIRECT-HA-REQ error value. =20 > > Now, I don't have any great issue with the HA side of this, but I'm > quite doubtful as to permitting a FA to make the decision of forward= ing > a registration to another HA than the one requested by the MN. And = what > is the the advantage here? I agree the FA should not be forwarding the request willy-nilly when the MN did in fact specify a valid unicast HA address. However, there may be some sort of policy in place at the FA to only allow a certain set of HAs. So, maybe we should allow the FA to insert a rejection code to inform the MN that it should try again with the ALL-ZERO-ONE-ADDR, even though we have no indication that the MN supports the extension, because the only other alternative might be to silently deny service to the MN. This would be a good use for Charlie's new FA rejection code procedure. -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 16 18:01:18 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 SAA06552 for ; Mon, 16 Feb 2004 18:01:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrjO-00071X-OD for mip4-archive@odin.ietf.org; Mon, 16 Feb 2004 18:00:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1GN0n4G026986 for mip4-archive@odin.ietf.org; Mon, 16 Feb 2004 18:00:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AsrjN-000719-3y for mip4-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 18:00: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 SAA06426 for ; Mon, 16 Feb 2004 18:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsrjK-0006N2-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 18:00:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Asrhv-00066J-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 17:59:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Asrgd-0005vG-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 17:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Asrgf-0006pL-80; Mon, 16 Feb 2004 17: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 1AsrgV-0006oe-0u for mip4@optimus.ietf.org; Mon, 16 Feb 2004 17:57: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 RAA06234 for ; Mon, 16 Feb 2004 17:57:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AsrgS-0005tK-00 for mip4@ietf.org; Mon, 16 Feb 2004 17:57:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AsrfZ-0005nt-00 for mip4@ietf.org; Mon, 16 Feb 2004 17:56:54 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Asreg-0005dn-00 for mip4@ietf.org; Mon, 16 Feb 2004 17:55:58 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1GMtOr05126; Mon, 16 Feb 2004 16:55:25 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1GMtNm25282; Mon, 16 Feb 2004 16:55:23 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HT7909-00012K-00; Mon, 16 Feb 2004 17:55:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16433.19032.245019.948545@gargle.gargle.HOWL> Date: Mon, 16 Feb 2004 16:55:20 -0600 From: Pete McCann To: Tom Hiller Cc: mip4@ietf.org, aaa-wg@merit.edu Subject: Re: [Mip4] dynamic keys In-Reply-To: <402AA576.9060302@lucent.com> References: <87ED4812394BA14980CC352C3A7483CC816740@tatara.tatarasystems.com> <402AA576.9060302@lucent.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 think it's also important that the MN-AAA secret be generated according to sound random number principles ala RFC 1750. If a plain text password is used, it may be vulnerable to offline dictionary attacks because all the other input parameters to the HMACs are potentially public knowledge. Note that making the MN-AAA out of a one-way function from a plain text password is not good enough, because it just adds one additional step to the dictionary attack. -Pete Tom Hiller writes: > Jeremy, > > I'd like to clarify a few things: > > 1) The MN-AAA shared secret is used more than once > 2) It is periodically refreshed > 3) It is configured per mobile and is not shared by other mobiles > 4) aaa-keys does not say how the key is periodically refreshed. > > I've acted as the editor, addressing security review comments and other=20 > comments from IETF and 3GPP2 folks. Summary: (1) The MN-AAA secret had=20 > to be refreshed periodically. That was added to the text. (2) The term=20 > "security association" was overloaded; "mobility security association",=20 > etc., were added to the text. There was an IANA assignment that did not=20 > match earlier text in the draft, and other editorial nits. Those were=20 > fixed. > > > - Tom > > PS In an earlier email, I provided a link to an MN-AAA shared secret=20 > provisioning 3GPP2 specification that uses https. A problem with=20 > provisioning in cdma2000 is that the mobile may not have an IP address=20 > at the time the provisioning server wishes to refresh the shared secret=20 > or other data, the phone may have just been purchased, etc., so there=20 > are radio network specific scenarios to be specified. > Jeremy A. Greene wrote: > I was referring to the offline attacks. Where does it say in the mip-ke= y=20 > or diameter-aaa drafts that username/pw would only be used once? >=20 > =20 >=20 > From section 5 of the mip-key draft: >=20 > =20 >=20 > 1. Using the Key Generation Nonce from the extension, the mobile >=20 > node calculates >=20 > =20 >=20 > key =3D HMAC-MD5 (AAA-key, {Key Generation Nonce || home >=20 > address}) >=20 > ... >=20 > The secret key used within the HMAC-MD5 computation is indicated by >=20 > the AAA Security Association indexed by the AAA SPI, which has been >=20 > previously configured as the basis for the AAA Security Association >=20 > between the mobile node and the AAA server creating the key material. >=20 > =20 >=20 > If I understand what you=92re suggesting, the aaa-key above would be=20 > generated from a username/password on the MN (and HA, somehow). But the= =20 > text above seems to imply it will be used every time the aaah sends a=20 > new nonce to create new =91session=92 keys. >=20 > =20 >=20 > And I still think there=92s a practical issue of using passwords to cre= ate=20 > a hash on the MN since the HA won=92t be able to verify it without the=20 > password clear-text to run through the same hash. >=20 > =20 >=20 > Sorry if I=92m being slow on this, but everything with security is way = too=20 > confusing! >=20 > =20 >=20 > Jeremy >=20 > =20 >=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, February 11, 2004 2:56 PM > To: Jeremy A. Greene > Cc: mip4@ietf.org; aaa-wg@merit.edu > Subject: Re: [Mip4] dynamic keys >=20 > =20 >=20 > Jeremy, >=20 > =20 >=20 > Wednesday 11 February 2004, Jeremy A. Greene wrote: >=20 >> But, more importantly, there's a concern in the 802.11, wpa area that >=20 >> touches on this: >=20 >> http://wifinetnews.com/archives/002452.html >=20 > =20 >=20 > No, there's no real similarity here. The concern in this article is >=20 > that it uses a broken procedure to generate a temporary session key, >=20 > resulting in eavesdropping being possible, and goes on to discusses >=20 > offline attacks on the passphrase. Offline attacks on an authenticatin= g >=20 > password/username combination is not that relevant in a bootstrap >=20 > scenario where you only use a specific username/password combination >=20 > once, and any repeated use will be blocked. >=20 > =20 >=20 > Henrik >=20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 16 19:56: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 TAA16950 for ; Mon, 16 Feb 2004 19:56: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 1AstWX-0004OY-T5 for mip4-archive@odin.ietf.org; Mon, 16 Feb 2004 19:55:42 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1H0tfrN016888 for mip4-archive@odin.ietf.org; Mon, 16 Feb 2004 19:55:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AstWX-0004OJ-MQ for mip4-web-archive@optimus.ietf.org; Mon, 16 Feb 2004 19:55: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 TAA16940 for ; Mon, 16 Feb 2004 19:55:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AstWV-0003Ar-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 19:55:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AstVa-000384-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 19:54:43 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AstUu-00035F-00 for mip4-web-archive@ietf.org; Mon, 16 Feb 2004 19:54:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AstUv-0004I4-Eb; Mon, 16 Feb 2004 19:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AstUZ-0004HF-KZ for mip4@optimus.ietf.org; Mon, 16 Feb 2004 19:53: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 TAA16871 for ; Mon, 16 Feb 2004 19:53:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AstUX-00034H-00 for mip4@ietf.org; Mon, 16 Feb 2004 19:53:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AstTf-00031m-00 for mip4@ietf.org; Mon, 16 Feb 2004 19:52:44 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AstT4-0002z0-00 for mip4@ietf.org; Mon, 16 Feb 2004 19:52:06 -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 1AstSl-0005u6-00; Tue, 17 Feb 2004 01:51:47 +0100 Date: Tue, 17 Feb 2004 01:51:37 +0100 From: Henrik Levkowetz To: Pete McCann Cc: Hans =?ISO-8859-1?Q?Sj=F6strand?= , Alpesh , Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040217015137.0eb79e44.henrik@levkowetz.com> In-Reply-To: <16433.18709.548019.259179@gargle.gargle.HOWL> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <402CEF0F.7050003@ipunplugged.com> <20040213193509.16ac6bd4.henrik@levkowetz.com> <16433.18709.548019.259179@gargle.gargle.HOWL> 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__17_Feb_2004_01_51_37_+0100_zyB_qeXFWhn0YTWf" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Tue__17_Feb_2004_01_51_37_+0100_zyB_qeXFWhn0YTWf Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Pete, Monday 16 February 2004, Pete McCann wrote: > Henrik Levkowetz writes: ... > > > > This is a very good point. Only the assigned HA should have to know > > anything about it's detailed setup, all others should only have to > > know about the addresses of alternative HAs. > > Even if the information comes from the assigned HA, I am a little bit > confused about the model here. When up and running, a mobile node > knows the following: > > 1) its home address > 2) its home subnet prefix (length) > 3) its home agent address, and a security association with that home > agent. > > Now, we don't really need to know the home agent's address in order to > do home link detection; we just need to see a router advertisement > that says we have returned to the home prefix, right? Well... in the basic 3344 scenario yes, but it isn't particularly good if you go to private (rfc1918) address home networks. (Too many of the primate networks turn out to be 192.168.0.x and 192.168.1.x ...) Now, knowing the exact address of the HA on the home network reduces the error frequency (believing you're home when you're not) by in practice maybe a factor on the order of 100 - but is really not particularly good, either... We really need a nai in the advertisements. The general NAI extension has been defined for advertisements too, so it's basically just a matter of using it with a HA NAI in the advertisements. That may need either assignment of a subtype number for the generalized NAI, or declaring that the currently defined HA identity NAI subtype may be used in advertisements. Mmh, I think I'll write a very short draft on this. A remaining question then is - if we assign HA address dynamically, should we also provide additional extension subtypes to carry additional information about the assigned HA? (For the NAI case this isn't needed though, as it's covered by the NAI carrying extension.) > Are we saying there will be cases where the home agent address is not > on the home subnet prefix? I suppose that is possible, and it > presents no big problem: the HA could still be reachable at its > "external" IP address even from within the "internal" subnet, modulo > firewall configuration, so the MN could send a de-registration from > anywhere. No, this wasn't the scenario I was thinking of. > Moreover, is it true that the data structures inside Mobile IP clients > can remember more than one IP address for a given mobility security > association? Or would it be more proper to think of these as separate > security associations with separate entities, even though they might > have some keys/SPIs in common? Mmm, the latter, I think. ... > > > > > To solve this, one way would be to mandate the MN always to send the > > > extension if the dynamic HA assignment is supported and configured. > > > Another way is to remove the option to have a unicast address in the > > > HA field. I didn't quite understand the advantage over just always use > > > ALL-ZERO-ONE-ADDR. > > > > It seems to me that there are two ways the HA may receive a request with > > a unicast address which does not match its own address: > > > > 1) The MN places different HA addresses in the request HA field and in > > the IP header destination address. I don't see that this gives any > > extra functionality over using the ALL-ZERO-ONE-ADDR. > > I agree. Maybe we should adopt this convention as an indication of > support for the rejection code. Not sure I follow - could you elaborate? > > 2) The FA decides to forward the registration request to a different HA > > than the one requested by the MN. In this case, the draft suggests that > > the discrepancy be observed by the HA, which may respond with a > > REDIRECT-HA-REQ error value. > > > > Now, I don't have any great issue with the HA side of this, but I'm > > quite doubtful as to permitting a FA to make the decision of forwarding > > a registration to another HA than the one requested by the MN. And what > > is the the advantage here? > > I agree the FA should not be forwarding the request willy-nilly when > the MN did in fact specify a valid unicast HA address. However, there > may be some sort of policy in place at the FA to only allow a certain > set of HAs. So, maybe we should allow the FA to insert a rejection > code to inform the MN that it should try again with the > ALL-ZERO-ONE-ADDR, even though we have no indication that the MN > supports the extension, because the only other alternative might be to > silently deny service to the MN. This would be a good use for > Charlie's new FA rejection code procedure. Sounds like a possibility. Alternatively, we could use an extension from the MN to indicate support. Henrik --Signature=_Tue__17_Feb_2004_01_51_37_+0100_zyB_qeXFWhn0YTWf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAMWWZeVhrtTJkXCMRAvJ/AJ9AQHOtEFiHynjKt7UX97XJFZZFFQCg5pts 41i2gYQ8FTMbyLsDEjwQIe4= =+wFF -----END PGP SIGNATURE----- --Signature=_Tue__17_Feb_2004_01_51_37_+0100_zyB_qeXFWhn0YTWf-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 17 12:24: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 MAA19302 for ; Tue, 17 Feb 2004 12:24: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 1At8wp-0006k0-2d for mip4-archive@odin.ietf.org; Tue, 17 Feb 2004 12:23:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HHNpJm025906 for mip4-archive@odin.ietf.org; Tue, 17 Feb 2004 12:23:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8wo-0006jl-QH for mip4-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 12:23: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 MAA19277 for ; Tue, 17 Feb 2004 12:23:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8wn-0000wn-00 for mip4-web-archive@ietf.org; Tue, 17 Feb 2004 12:23:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8vv-0000pA-00 for mip4-web-archive@ietf.org; Tue, 17 Feb 2004 12:22:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1At8v4-0000ip-00 for mip4-web-archive@ietf.org; Tue, 17 Feb 2004 12:22:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8v3-0006ZM-Qd; Tue, 17 Feb 2004 12:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1At8uN-0006Wj-4j for mip4@optimus.ietf.org; Tue, 17 Feb 2004 12:21: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 MAA19121 for ; Tue, 17 Feb 2004 12:21:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1At8uL-0000fm-00 for mip4@ietf.org; Tue, 17 Feb 2004 12:21:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1At8tP-0000aJ-00 for mip4@ietf.org; Tue, 17 Feb 2004 12:20:20 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1At8sg-0000T6-00 for mip4@ietf.org; Tue, 17 Feb 2004 12:19:34 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1HHHNr14770; Tue, 17 Feb 2004 11:17:25 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1HHHA129077; Tue, 17 Feb 2004 11:17:10 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HT8O0L-0000ZC-00; Tue, 17 Feb 2004 12:17:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16434.19604.320288.837012@gargle.gargle.HOWL> Date: Tue, 17 Feb 2004 11:17:08 -0600 From: Pete McCann To: Henrik Levkowetz Cc: Hans =?ISO-8859-1?Q?Sj=F6strand?= , Alpesh , Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) In-Reply-To: <20040217015137.0eb79e44.henrik@levkowetz.com> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <402CEF0F.7050003@ipunplugged.com> <20040213193509.16ac6bd4.henrik@levkowetz.com> <16433.18709.548019.259179@gargle.gargle.HOWL> <20040217015137.0eb79e44.henrik@levkowetz.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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, Henrik Levkowetz writes: > Hi Pete, > > Monday 16 February 2004, Pete McCann wrote: > > Henrik Levkowetz writes: > ... > > > > > > This is a very good point. Only the assigned HA should have to know > > > anything about it's detailed setup, all others should only have to > > > know about the addresses of alternative HAs. > > > > Even if the information comes from the assigned HA, I am a little bit > > confused about the model here. When up and running, a mobile node > > knows the following: > > > > 1) its home address > > 2) its home subnet prefix (length) > > 3) its home agent address, and a security association with that home > > agent. > > > > Now, we don't really need to know the home agent's address in order to > > do home link detection; we just need to see a router advertisement > > that says we have returned to the home prefix, right? > > Well... in the basic 3344 scenario yes, but it isn't particularly good > if you go to private (rfc1918) address home networks. (Too many of the > primate networks turn out to be 192.168.0.x and 192.168.1.x ...) Now, > knowing the exact address of the HA on the home network reduces the > error frequency (believing you're home when you're not) by in practice > maybe a factor on the order of 100 - but is really not particularly > good, either... Yes, this seems to be an unreliable heuristic. > We really need a nai in the advertisements. The general NAI extension > has been defined for advertisements too, so it's basically just a matter > of using it with a HA NAI in the advertisements. That may need either > assignment of a subtype number for the generalized NAI, or declaring > that the currently defined HA identity NAI subtype may be used in > advertisements. Mmh, I think I'll write a very short draft on this. I agree it would be highly useful to put NAIs in agent advertisements, both foreign and home. > A remaining question then is - if we assign HA address dynamically, > should we also provide additional extension subtypes to carry additional > information about the assigned HA? (For the NAI case this isn't needed > though, as it's covered by the NAI carrying extension.) Quite possibly; although, it's not clear to me that "alternative IP addresses" are really useful for movement detection. There might be other reasons to put them in, though. A mobile node should de-register if and only if it is on its home subnet, which means that the home IP address has become topologically correct. If it is not possible to determine that based on prefix alone (such as in the private address case) then it's not clear to me why adding additional HA IP addresses would help matters. Usually, private IP addressed networks are set up in a way that makes them look transparent to client nodes, i.e., the nodes don't actually need to know the private address ranges or that there is anything special about the address that they have obtained. Putting all this special-case code into Mobile IP clients makes me a bit uncomfortable, but I suppose this is the whole point of the Mobile IP/VPN effort. > > Are we saying there will be cases where the home agent address is not > > on the home subnet prefix? I suppose that is possible, and it > > presents no big problem: the HA could still be reachable at its > > "external" IP address even from within the "internal" subnet, modulo > > firewall configuration, so the MN could send a de-registration from > > anywhere. > > No, this wasn't the scenario I was thinking of. Ok. > > Moreover, is it true that the data structures inside Mobile IP clients > > can remember more than one IP address for a given mobility security > > association? Or would it be more proper to think of these as separate > > security associations with separate entities, even though they might > > have some keys/SPIs in common? > > Mmm, the latter, I think. > ... > > > > > > > > To solve this, one way would be to mandate the MN always to send the > > > > extension if the dynamic HA assignment is supported and configured. > > > > Another way is to remove the option to have a unicast address in the > > > > HA field. I didn't quite understand the advantage over just always use > > > > ALL-ZERO-ONE-ADDR. > > > > > > It seems to me that there are two ways the HA may receive a request with > > > a unicast address which does not match its own address: > > > > > > 1) The MN places different HA addresses in the request HA field and in > > > the IP header destination address. I don't see that this gives any > > > extra functionality over using the ALL-ZERO-ONE-ADDR. > > > > I agree. Maybe we should adopt this convention as an indication of > > support for the rejection code. > > Not sure I follow - could you elaborate? I meant use the ALL-ZERO-ONE-ADDR in the HA field as an indication of support for HA redirection. I thought this was what you were suggesting. In that case maybe we wouldn't need a separate extension to indicate support. However, we'd lose the ability to redirect MNs that put a unicast HA address in that field, in an attempt to register with one round-trip. > > > 2) The FA decides to forward the registration request to a different HA > > > than the one requested by the MN. In this case, the draft suggests that > > > the discrepancy be observed by the HA, which may respond with a > > > REDIRECT-HA-REQ error value. > > > > > > Now, I don't have any great issue with the HA side of this, but I'm > > > quite doubtful as to permitting a FA to make the decision of forwarding > > > a registration to another HA than the one requested by the MN. And what > > > is the the advantage here? > > > > I agree the FA should not be forwarding the request willy-nilly when > > the MN did in fact specify a valid unicast HA address. However, there > > may be some sort of policy in place at the FA to only allow a certain > > set of HAs. So, maybe we should allow the FA to insert a rejection > > code to inform the MN that it should try again with the > > ALL-ZERO-ONE-ADDR, even though we have no indication that the MN > > supports the extension, because the only other alternative might be to > > silently deny service to the MN. This would be a good use for > > Charlie's new FA rejection code procedure. > > Sounds like a possibility. > > Alternatively, we could use an extension from the MN to indicate support. Yes, this might be best. -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 17 17:05:04 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 RAA10732 for ; Tue, 17 Feb 2004 17:05: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 1AtDKW-0004ox-HU for mip4-archive@odin.ietf.org; Tue, 17 Feb 2004 17:04:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1HM4aXe018511 for mip4-archive@odin.ietf.org; Tue, 17 Feb 2004 17:04:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDKV-0004oU-Nv for mip4-web-archive@optimus.ietf.org; Tue, 17 Feb 2004 17:04: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 RAA10611 for ; Tue, 17 Feb 2004 17:04:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDKT-0003d3-00 for mip4-web-archive@ietf.org; Tue, 17 Feb 2004 17:04:33 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDJI-0003Pi-00 for mip4-web-archive@ietf.org; Tue, 17 Feb 2004 17:03:20 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtDI1-0003BA-00 for mip4-web-archive@ietf.org; Tue, 17 Feb 2004 17:02:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtDI2-0004FP-4p; Tue, 17 Feb 2004 17: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 1AtDHw-0004Dt-9W for mip4@optimus.ietf.org; Tue, 17 Feb 2004 17:01: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 RAA10248 for ; Tue, 17 Feb 2004 17:01:53 -0500 (EST) From: Ali.Akgun@utstar.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtDHu-00039m-00 for mip4@ietf.org; Tue, 17 Feb 2004 17:01:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtDGn-0002y0-00 for mip4@ietf.org; Tue, 17 Feb 2004 17:00:46 -0500 Received: from quartz.utstar.com ([216.37.120.24]) by ietf-mx with esmtp (Exim 4.12) id 1AtDFe-0002dm-00 for mip4@ietf.org; Tue, 17 Feb 2004 16:59:34 -0500 Received: from gypsum.mw.3com.com ([216.37.120.50]) by quartz.utstar.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id i1HM5Tcl013709 for ; Tue, 17 Feb 2004 14:05:29 -0800 (PST) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1HLxpAM021648 for ; Tue, 17 Feb 2004 13:59:51 -0800 (PST) To: mip4@ietf.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: Date: Tue, 17 Feb 2004 15:58:55 -0600 X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 02/17/2004 03:58:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [Mip4] 3012bis Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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=NO_REAL_NAME autolearn=no version=2.60 Hi Everyone, Can anyone update us on the status of the 3012bis draft? thanks much, ali -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 18 00:46:06 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 AAA00150 for ; Wed, 18 Feb 2004 00:46: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 1AtKWh-0005Rl-9W for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 00:45:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I5jdYe020933 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 00:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtKWh-0005RY-2y for mip4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 00:45: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 AAA00145 for ; Wed, 18 Feb 2004 00:45:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtKWe-0004Kl-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 00:45:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtKVi-0004IP-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 00:44:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtKV6-0004Fm-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 00:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtKV7-0005Nh-Lr; Wed, 18 Feb 2004 00:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtKUj-0005MR-Vx for mip4@optimus.ietf.org; Wed, 18 Feb 2004 00:43: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 AAA00059 for ; Wed, 18 Feb 2004 00:43:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtKUh-0004Eu-00 for mip4@ietf.org; Wed, 18 Feb 2004 00:43:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtKTj-0004Cm-00 for mip4@ietf.org; Wed, 18 Feb 2004 00:42:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AtKTH-0004AX-00 for mip4@ietf.org; Wed, 18 Feb 2004 00:42:07 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2004 21:51:10 +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 i1I5fa4U006549; Tue, 17 Feb 2004 21:41:36 -0800 (PST) Received: from cisco.com (sjc-vpn2-725.cisco.com [10.21.114.213]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AQJ44593; Tue, 17 Feb 2004 21:41:30 -0800 (PST) Message-ID: <4032FB09.9030907@cisco.com> Date: Tue, 17 Feb 2004 21:41:29 -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: Henrik Levkowetz CC: =?ISO-8859-1?Q?Hans_Sj=F6strand?= , Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <402CEF0F.7050003@ipunplugged.com> <20040213193509.16ac6bd4.henrik@levkowetz.com> Content-Type: multipart/alternative; boundary="------------030106050306010605010602" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,HTML_MESSAGE, HTML_TITLE_EMPTY autolearn=no version=2.60 --------------030106050306010605010602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Henrik - Clarifying on two issues, under ALPESH>> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type | Length | Reserved | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Redirected-HA-Address | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> > >Actually, there's also another consideration, which is that we probably >want to include a subtype here, to avoid unnecessary depletion of the >extension number space. I think that possible future extensions to be >sent from the Assigned HA to give more details about itself might have >the same type, and different subtypes compared to this. We then also >have the advantage of following the recommendation in 3344 section 1.9 >:-) > ALPESH >> I see your point regarding subtype field. I will discuss with the co-authors this issue. >2) The FA decides to forward the registration request to a different HA >than the one requested by the MN. In this case, the draft suggests that >the discrepancy be observed by the HA, which may respond with a >REDIRECT-HA-REQ error value. > >Now, I don't have any great issue with the HA side of this, but I'm >quite doubtful as to permitting a FA to make the decision of forwarding >a registration to another HA than the one requested by the MN. And what >is the the advantage here? > ALPESH>> One possible scenario is where FA authentication happens and AAA server returns an IP address to use. In that case FA forwards RRQ to the AAA suggested HA. Alpesh > > > Henrik > > > --------------030106050306010605010602 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Henrik -

Clarifying on two issues, under ALPESH>>
<snip>

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |           Reserved            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                    Redirected-HA-Address                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

Actually, there's also another consideration, which is that we probably
want to include a subtype here, to avoid unnecessary depletion of the
extension number space.  I think that possible future extensions to be
sent from the Assigned HA to give more details about itself might have
the same type, and different subtypes compared to this.  We then also
have the advantage of following the recommendation in 3344 section 1.9
:-)

ALPESH >> I see your point regarding subtype field. I will discuss with the co-authors this issue.
2) The FA decides to forward the registration request to a different HA
than the one requested by the MN.  In this case, the draft suggests that
the discrepancy be observed by the HA, which may respond with a
REDIRECT-HA-REQ error value.  

Now, I don't have any great issue with the HA side of this, but I'm
quite doubtful as to permitting a FA to make the decision of forwarding
a registration to another HA than the one requested by the MN.  And what
is the the advantage here?
ALPESH>> One possible scenario is where FA authentication happens and AAA server returns an
IP address to use. In that case FA forwards RRQ to the AAA suggested HA.

Alpesh


	Henrik

--------------030106050306010605010602-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 18 04:12: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 EAA02968 for ; Wed, 18 Feb 2004 04:12: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 1AtNk6-0004OV-SD for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 04:11:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1I9BgMK016887 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 04:11:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtNk5-0004OI-K6 for mip4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 04:11: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 EAA02940 for ; Wed, 18 Feb 2004 04:11:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtNk3-0000BB-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 04:11:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtNjB-00008c-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 04:10:46 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtNiT-00005w-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 04:10:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtNiT-0004Ea-DW; Wed, 18 Feb 2004 04:10:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtNiA-0004Dv-OI for mip4@optimus.ietf.org; Wed, 18 Feb 2004 04:09: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 EAA02903 for ; Wed, 18 Feb 2004 04:09:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtNi8-00004k-00 for mip4@ietf.org; Wed, 18 Feb 2004 04:09:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtNhP-00002R-00 for mip4@ietf.org; Wed, 18 Feb 2004 04:08:56 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AtNga-0007mH-00 for mip4@ietf.org; Wed, 18 Feb 2004 04:08:04 -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 1AtNgV-0006Ug-00; Wed, 18 Feb 2004 10:07:59 +0100 Date: Wed, 18 Feb 2004 10:07:54 +0100 From: Henrik Levkowetz To: Alpesh Cc: mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040218100754.30f310e8.henrik@levkowetz.com> In-Reply-To: <4032FB09.9030907@cisco.com> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <402CEF0F.7050003@ipunplugged.com> <20040213193509.16ac6bd4.henrik@levkowetz.com> <4032FB09.9030907@cisco.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=_Wed__18_Feb_2004_10_07_54_+0100_+K7emlU0JJAjc+Cy" Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__18_Feb_2004_10_07_54_+0100_+K7emlU0JJAjc+Cy Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Tuesday 17 February 2004, Alpesh wrote: [Henrik] > >Actually, there's also another consideration, which is that we probably > >want to include a subtype here, to avoid unnecessary depletion of the > >extension number space. I think that possible future extensions to be > >sent from the Assigned HA to give more details about itself might have > >the same type, and different subtypes compared to this. We then also > >have the advantage of following the recommendation in 3344 section 1.9 > >:-) > > > > ALPESH >> I see your point regarding subtype field. I will discuss with > the co-authors this issue. Ok, good. > >2) The FA decides to forward the registration request to a different HA > >than the one requested by the MN. In this case, the draft suggests that > >the discrepancy be observed by the HA, which may respond with a > >REDIRECT-HA-REQ error value. > > > >Now, I don't have any great issue with the HA side of this, but I'm > >quite doubtful as to permitting a FA to make the decision of forwarding > >a registration to another HA than the one requested by the MN. And what > >is the the advantage here? > > > ALPESH>> One possible scenario is where FA authentication happens and > AAA server returns an > IP address to use. In that case FA forwards RRQ to the AAA suggested HA. Ok. But I think that (at least in my mind) there is still a question about dynamic assignment without the ALL-ZERO-ONE-ADDR. I'd say that the rule should rather be that if the Mobile permits dynamic HA assignment in this case, it sends ALL-ZERO-ONE-ADDRESS and a MN-AAA authentication-enabling extension and the FA sends the request on to the AAA suggested HA, but if the MN sends a unicast address and MN-AAA auth. ext., the FA may NOT direct the request to a different HA. I think this should have been covered in the aaa-nai draft, but wasn't :-( Maybe this discussion shows some weaknesses with using the ALL-ZERO-ONE-ADDRESS, which could more easily be resolved if we requested a dynamically assigned address through the use of an extension instead. In the unicast-addr/aaa-suggested-ha case discussed above, for instance, the extension could carry a flag indicating whether or not it would permit the FA to redirect the RRQ to a different initial HA. Henrik --Signature=_Wed__18_Feb_2004_10_07_54_+0100_+K7emlU0JJAjc+Cy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAMytqeVhrtTJkXCMRAie9AKCn0MaRhqW1wp3zt4suGqoJmTkYewCgxrrs yUmziON8jG/r0HbeS+6ZKYc= =7/pM -----END PGP SIGNATURE----- --Signature=_Wed__18_Feb_2004_10_07_54_+0100_+K7emlU0JJAjc+Cy-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 18 08:55: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 IAA10990 for ; Wed, 18 Feb 2004 08:55: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 1AtSAB-0008OJ-L1 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 08:54:55 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IDst9b032253 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 08:54:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtSAB-0008O8-DA for mip4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 08:54: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 IAA10931 for ; Wed, 18 Feb 2004 08:54:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtSAA-0007c1-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 08:54:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtS9I-0007Xw-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 08:54:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtS8L-0007Th-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 08:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS8M-0008En-AS; Wed, 18 Feb 2004 08:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtS8E-0008E4-3P for mip4@optimus.ietf.org; Wed, 18 Feb 2004 08:52: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 IAA10850 for ; Wed, 18 Feb 2004 08:52:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtS8C-0007S8-00 for mip4@ietf.org; Wed, 18 Feb 2004 08:52:52 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtS7P-0007P2-00 for mip4@ietf.org; Wed, 18 Feb 2004 08:52:03 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AtS6w-0007L8-00 for mip4@ietf.org; Wed, 18 Feb 2004 08:51:34 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1IDoZjv001737; Wed, 18 Feb 2004 14:50:35 +0100 Date: Wed, 18 Feb 2004 14:50:35 +0100 From: Henrik Levkowetz To: Pete McCann Cc: Alpesh , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040218145035.38e8c877.henrik@levkowetz.com> In-Reply-To: <16434.19604.320288.837012@gargle.gargle.HOWL> References: <20040209153540.08b06367.henrik@levkowetz.com> <402BA0D4.6090709@ipunplugged.com> <200402121717.CAA07238@toshiba.co.jp> <20040212212214.4e8c448e.henrik@levkowetz.com> <402BE6BF.2030307@cisco.com> <402CEF0F.7050003@ipunplugged.com> <20040213193509.16ac6bd4.henrik@levkowetz.com> <16433.18709.548019.259179@gargle.gargle.HOWL> <20040217015137.0eb79e44.henrik@levkowetz.com> <16434.19604.320288.837012@gargle.gargle.HOWL> 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=_Wed__18_Feb_2004_14_50_35_+0100_dZ8GcAU_uLhryGH+" X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__18_Feb_2004_14_50_35_+0100_dZ8GcAU_uLhryGH+ Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Tuesday, 17 Feb 2004, Pete McCann wrote: > > We really need a nai in the advertisements. The general NAI extension > > has been defined for advertisements too, so it's basically just a matter > > of using it with a HA NAI in the advertisements. That may need either > > assignment of a subtype number for the generalized NAI, or declaring > > that the currently defined HA identity NAI subtype may be used in > > advertisements. Mmh, I think I'll write a very short draft on this. > > I agree it would be highly useful to put NAIs in agent advertisements, > both foreign and home. Ok. > > A remaining question then is - if we assign HA address dynamically, > > should we also provide additional extension subtypes to carry additional > > information about the assigned HA? (For the NAI case this isn't needed > > though, as it's covered by the NAI carrying extension.) > > Quite possibly; although, it's not clear to me that "alternative IP > addresses" are really useful for movement detection. There might be > other reasons to put them in, though. Yes. What with the NAI having its own extension, I don't have any example right now which I'd want to promote ... unless maybe the home network prefix. That really belongs with dynamic home address assignment rather than dynamic ha assignment, but it's part of the same area of functionality; and we don't have a way today to inform the MN of the appropriate netmask - or alternatively the private-side HA interface address - or whatever other way of identifying the home network people have implemented. > A mobile node should de-register if and only if it is on its home > subnet, which means that the home IP address has become topologically > correct. Yes. > If it is not possible to determine that based on prefix > alone (such as in the private address case) then it's not clear to me > why adding additional HA IP addresses would help matters. It's not really about prefix vs. prefix + extra addresses, but rather that you need prefix _or_ some equivalent information - like HA address in the home net, or NAI, or whatever you have designed your home network identification heuristics around. 3344 is not really helpful on this point. > Usually, private IP addressed networks are set up in a way that makes > them look transparent to client nodes, i.e., the nodes don't actually > need to know the private address ranges or that there is anything > special about the address that they have obtained. Right. > Putting all this > special-case code into Mobile IP clients makes me a bit uncomfortable, > but I suppose this is the whole point of the Mobile IP/VPN effort. In the ipUnplugged case, we don't (as far as I know) have any special case code based on the home network being private address or not - what we have is the choice of preconfiguring with HA home address rather than Home network prefix as home network detection characteristic; but that has in itself nothing to do with private vs. publicly routable addresses. With regards to the Mobile IP/VPN effort, that _does_ complicate the MN code quite a bit :-( > ... ... > > > > 1) The MN places different HA addresses in the request HA field and in > > > > the IP header destination address. I don't see that this gives any > > > > extra functionality over using the ALL-ZERO-ONE-ADDR. > > > > > > I agree. Maybe we should adopt this convention as an indication of > > > support for the rejection code. > > > > Not sure I follow - could you elaborate? > > I meant use the ALL-ZERO-ONE-ADDR in the HA field as an indication of > support for HA redirection. I thought this was what you were > suggesting. In that case maybe we wouldn't need a separate extension > to indicate support. However, we'd lose the ability to redirect MNs > that put a unicast HA address in that field, in an attempt to register > with one round-trip. Ah, OK. Right. I guess I'd prefer using an extension to signal the capability, both for the greater flexibility and to have the whole mechanism conform more to the basic model of using extensions to extend MIP functionality ,:-) Henrik --Signature=_Wed__18_Feb_2004_14_50_35_+0100_dZ8GcAU_uLhryGH+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD4DBQFAM22reVhrtTJkXCMRAq9YAJj2IcHBIn0aiBTFV1hXF8cdB7gjAKCwcbKa SmJmqF5WpDnaUNPwnbkX/g== =6QiJ -----END PGP SIGNATURE----- --Signature=_Wed__18_Feb_2004_14_50_35_+0100_dZ8GcAU_uLhryGH+-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 18 10:51: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 KAA23452 for ; Wed, 18 Feb 2004 10:51: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 1AtTye-0007Gz-Bj for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 10:51:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IFp85H027956 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 10: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 1AtTyd-0007Gp-GL for mip4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 10:51: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 KAA23428 for ; Wed, 18 Feb 2004 10:51:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTyb-0004gu-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 10:51:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTxp-0004bo-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 10:50:17 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AtTwu-0004WN-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 10:49:32 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AtTwu-0006KC-0R for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 10:49:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTwp-0006t1-TO; Wed, 18 Feb 2004 10:49:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtTvn-0006px-PZ for mip4@optimus.ietf.org; Wed, 18 Feb 2004 10:48: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 KAA23289 for ; Wed, 18 Feb 2004 10:47:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtTvb-0004Pl-00 for mip4@ietf.org; Wed, 18 Feb 2004 10:47:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtTuf-0004ME-00 for mip4@ietf.org; Wed, 18 Feb 2004 10:47:02 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AtTtr-0004E6-00 for mip4@ietf.org; Wed, 18 Feb 2004 10:46:11 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1IFjNjv004354; Wed, 18 Feb 2004 16:45:23 +0100 Date: Wed, 18 Feb 2004 16:45:23 +0100 From: Henrik Levkowetz To: Yoshiyuki Tsuda Cc: Pete McCann , Alpesh , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) Message-Id: <20040218164523.1975baa2.henrik@levkowetz.com> In-Reply-To: <200402181522.AAA28994@toshiba.co.jp> References: <20040213193509.16ac6bd4.henrik@levkowetz.com> <16433.18709.548019.259179@gargle.gargle.HOWL> <20040217015137.0eb79e44.henrik@levkowetz.com> <16434.19604.320288.837012@gargle.gargle.HOWL> <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> 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=_Wed__18_Feb_2004_16_45_23_+0100_Zf.w+7/MIg9PNi1K" X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__18_Feb_2004_16_45_23_+0100_Zf.w+7/MIg9PNi1K Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hello Yoshi, On Thursday, 19 Feb 2004, Yoshiyuki Tsuda wrote: > at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote: > >Yes. What with the NAI having its own extension, I don't have any > >example right now which I'd want to promote ... unless maybe the > >home network prefix. That really belongs with dynamic home address > >assignment rather than dynamic ha assignment, but it's part of the > >same area of functionality; and we don't have a way today to inform > >the MN of the appropriate netmask - or alternatively the private-side > >HA interface address - or whatever other way of identifying the home > >network people have implemented. > > About the netmask, an MN can extract the home subnet prefix by > the following way: > - Mobility Agents are assumed to advertise correct subnet prefix > to their connected subnets. > - An MN with dynamic home address compares it with the current > subnet address and prefix. If the home address is within the > current subnet, the MN can extract that the home prefix is the > current prefix. > - Before the MN encounters its home subnet, the MN should assume > its home prefix is 32. > > Our MN has the above function, and is working. :) Yes, you're quite right, this is absolutely fine, and we don't need to know the home subnet mask in advance. Thanks for the correction :-) Henrik --Signature=_Wed__18_Feb_2004_16_45_23_+0100_Zf.w+7/MIg9PNi1K Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAM4iTeVhrtTJkXCMRApekAKCLFd9lrfxv9arZNpx/X1dgA/+5wgCfVjJi 95IbJtFa/Hdk5EoouaqDrqQ= =b1xS -----END PGP SIGNATURE----- --Signature=_Wed__18_Feb_2004_16_45_23_+0100_Zf.w+7/MIg9PNi1K-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 18 12:19: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 MAA00105 for ; Wed, 18 Feb 2004 12:19: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 1AtVLh-0007Lq-Jx for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 12:19:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IHJ15k028257 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 12: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 1AtVLh-0007Le-Eb for mip4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 12:19: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 MAA29977 for ; Wed, 18 Feb 2004 12:18:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVLg-0005MX-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 12:19:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVKi-0005Cs-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 12:18:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtVJk-00055v-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 12:17:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVJk-0006rN-JP; Wed, 18 Feb 2004 12:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVIy-0006dA-18 for mip4@optimus.ietf.org; Wed, 18 Feb 2004 12:16:12 -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 MAA29674 for ; Wed, 18 Feb 2004 12:16:08 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVIw-0004zI-00 for mip4@ietf.org; Wed, 18 Feb 2004 12:16:10 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVHz-0004s6-00 for mip4@ietf.org; Wed, 18 Feb 2004 12:15:12 -0500 Received: from [47.81.138.65] (helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AtVH7-0004kZ-00 for mip4@ietf.org; Wed, 18 Feb 2004 12:14:17 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i1IHDhr10243; Wed, 18 Feb 2004 09:13:43 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1FMV9L3Z>; Wed, 18 Feb 2004 11:13:43 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF746D15@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Ali.Akgun@utstar.com'" Cc: mip4@ietf.org Subject: RE: [Mip4] 3012bis Date: Wed, 18 Feb 2004 11:13:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hi Ali, We had couple of issues related to RFC3012bis draft. These issues and solutions were discussed in last IETF meeting. As per the outcome, we don't need any explicit text in RFC3012bis document. There is one typo in "Change history" section of draft-ietf-mip4-rfc3012bis-00.txt. Apart from this, the draft is pretty much completed now unless I hear otherwise. Thanks, Jayshree > -----Original Message----- > From: Ali.Akgun@utstar.com [mailto:Ali.Akgun@utstar.com] > Sent: Tuesday, February 17, 2004 3:59 PM > To: mip4@ietf.org > Subject: [Mip4] 3012bis > > > Hi Everyone, > > Can anyone update us on the status of the 3012bis draft? > > thanks much, > ali > > > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 18 12:31: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 MAA01077 for ; Wed, 18 Feb 2004 12:31: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 1AtVXH-0008Dt-UI for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 12:31:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IHUxTW031603 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 12:30:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVXH-0008De-QJ for mip4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 12:30: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 MAA01047 for ; Wed, 18 Feb 2004 12:30:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVXG-0006VO-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 12:30:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVWJ-0006RS-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 12:29:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtVVM-0006Mt-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 12:29:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVVM-00086D-Em; Wed, 18 Feb 2004 12:29:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtVUV-00084j-A2 for mip4@optimus.ietf.org; Wed, 18 Feb 2004 12:28: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 MAA00871 for ; Wed, 18 Feb 2004 12:28:03 -0500 (EST) From: Ali.Akgun@utstar.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtVUT-0006JA-00 for mip4@ietf.org; Wed, 18 Feb 2004 12:28:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtVTa-0006FT-00 for mip4@ietf.org; Wed, 18 Feb 2004 12:27:11 -0500 Received: from quartz.utstar.com ([216.37.120.24]) by ietf-mx with esmtp (Exim 4.12) id 1AtVTE-0006BR-00 for mip4@ietf.org; Wed, 18 Feb 2004 12:26:48 -0500 Received: from gypsum.mw.3com.com ([216.37.120.50]) by quartz.utstar.com (Switch-3.0.4/Switch-3.0.0) with ESMTP id i1IHWkcl010161; Wed, 18 Feb 2004 09:32:46 -0800 (PST) Received: from utstarchi01.mw.3com.com (uschi001.mw.3com.com [149.112.142.9]) by gypsum.mw.3com.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id i1IHR8AM024629; Wed, 18 Feb 2004 09:27:08 -0800 (PST) Subject: RE: [Mip4] 3012bis To: "Jayshree Bharatia" Cc: mip4@ietf.org X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: Date: Wed, 18 Feb 2004 11:26:12 -0600 X-MIMETrack: Serialize by Router on UTSTARCHI01/UTStarcom(Release 5.0.12 |February 13, 2003) at 02/18/2004 11:26:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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=NO_REAL_NAME autolearn=no version=2.60 thanks very much for the update, Jayshree. ali "Jayshree Bharatia" @ietf.org on 02/18/2004 11:13:35 AM Sent by: mip4-admin@ietf.org To: Ali Akgun/UTStarcom@UTStarcom cc: mip4@ietf.org Subject: RE: [Mip4] 3012bis Hi Ali, We had couple of issues related to RFC3012bis draft. These issues and solutions were discussed in last IETF meeting. As per the outcome, we don't need any explicit text in RFC3012bis document. There is one typo in "Change history" section of draft-ietf-mip4-rfc3012bis-00.txt. Apart from this, the draft is pretty much completed now unless I hear otherwise. Thanks, Jayshree > -----Original Message----- > From: Ali.Akgun@utstar.com [mailto:Ali.Akgun@utstar.com] > Sent: Tuesday, February 17, 2004 3:59 PM > To: mip4@ietf.org > Subject: [Mip4] 3012bis > > > Hi Everyone, > > Can anyone update us on the status of the 3012bis draft? > > thanks much, > ali > > > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 18 15:03: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 PAA15116 for ; Wed, 18 Feb 2004 15:03: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 1AtXuX-0007QR-Cy for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 15:03:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1IK39Vc028541 for mip4-archive@odin.ietf.org; Wed, 18 Feb 2004 15:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXuX-0007QC-73 for mip4-web-archive@optimus.ietf.org; Wed, 18 Feb 2004 15:03: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 PAA15090 for ; Wed, 18 Feb 2004 15:03:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXuU-0001wg-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 15:03:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXtV-0001uS-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 15:02:06 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtXtP-0001sF-00 for mip4-web-archive@ietf.org; Wed, 18 Feb 2004 15:01:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtXtR-0006RX-6e; Wed, 18 Feb 2004 15: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 1AtXsV-0005xG-PG for mip4@optimus.ietf.org; Wed, 18 Feb 2004 15:01: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 PAA15039 for ; Wed, 18 Feb 2004 15:01:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtXsS-0001rS-00 for mip4@ietf.org; Wed, 18 Feb 2004 15:01:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AtXrU-0001oE-00 for mip4@ietf.org; Wed, 18 Feb 2004 15:00:01 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AtXqX-0001i1-00 for mip4@ietf.org; Wed, 18 Feb 2004 14:59:01 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1IJwBr17234; Wed, 18 Feb 2004 13:58:11 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1IJw8d05392; Wed, 18 Feb 2004 13:58:08 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HTAQ4T-0000ZS-00; Wed, 18 Feb 2004 14:58:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16435.50124.851288.46989@gargle.gargle.HOWL> Date: Wed, 18 Feb 2004 13:58:04 -0600 From: Pete McCann To: Ali.Akgun@utstar.com Cc: "Jayshree Bharatia" , henrik@levkowetz.com, mip4@ietf.org Subject: RE: [Mip4] 3012bis In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Yes, thanks, Jayshree - I think we are ready to send this to the IESG, but I just noticed that there is no IPR or copyright statement in the current version that is in the drafts directory. This issue has come up several times before, so I'm copying the whole list to make sure we can get it right from now on. All editors, please make sure that you have two sections like the following in all drafts that you expect to progress within the working group: Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." These come from RFC 2026, Section 10.4 (A), (B), and (C). Drafts will not be submitted to the IESG without this text. When you know of IPR that pertains to a draft, you should also insert the text from section (D) in the IPR statement: "The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights." You can also add whatever details about the IPR (patent numbers, etc) you feel are appropriate in the IPR statement or put in other text that may be required by your company, but the above IPR statement must be present in its entirety. Jayshree, I think you can update the one typo you found at the same time that you add these; please also remember to upload your source to http://www.mip4.org/drafts/rfc3012bis/ At the same time that you submit the text to internet-drafts. Unfortunately, the submission won't be processed until after the upcoming IETF, so we are stuck until then, but hopefully we can take care of this immediately following the meeting. Thanks, -Pete Ali.Akgun@utstar.com writes: > > thanks very much for the update, Jayshree. > > ali > > > > > "Jayshree Bharatia" @ietf.org on 02/18/2004 > 11:13:35 AM > > Sent by: mip4-admin@ietf.org > > > To: Ali Akgun/UTStarcom@UTStarcom > cc: mip4@ietf.org > Subject: RE: [Mip4] 3012bis > > > Hi Ali, > > We had couple of issues related to RFC3012bis draft. These issues and > solutions were discussed in last IETF meeting. As per the outcome, we don't > need any explicit text in RFC3012bis document. There is one typo in "Change > history" section of draft-ietf-mip4-rfc3012bis-00.txt. Apart from this, the > draft is pretty much completed now unless I hear otherwise. > > Thanks, > Jayshree > > -----Original Message----- > > From: Ali.Akgun@utstar.com [mailto:Ali.Akgun@utstar.com] > > Sent: Tuesday, February 17, 2004 3:59 PM > > To: mip4@ietf.org > > Subject: [Mip4] 3012bis > > > > > > Hi Everyone, > > > > Can anyone update us on the status of the 3012bis draft? > > > > thanks much, > > ali -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 19 15:25: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 PAA24471 for ; Thu, 19 Feb 2004 15:25:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atuje-00062f-68 for mip4-archive@odin.ietf.org; Thu, 19 Feb 2004 15:25:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JKPQ0m023216 for mip4-archive@odin.ietf.org; Thu, 19 Feb 2004 15:25:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atuje-00062L-1L for mip4-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 15:25: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 PAA24097 for ; Thu, 19 Feb 2004 15:25:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atujc-0005oq-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 15:25:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atuif-0005m8-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 15:24:25 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AtuiH-0005jV-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 15:24:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AtuiH-0005lV-Cj; Thu, 19 Feb 2004 15: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 1Atuhb-0005d3-9z for mip4@optimus.ietf.org; Thu, 19 Feb 2004 15:23: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 PAA22536 for ; Thu, 19 Feb 2004 15:23:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AtuhZ-0005hw-00 for mip4@ietf.org; Thu, 19 Feb 2004 15:23:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atugb-0005fZ-00 for mip4@ietf.org; Thu, 19 Feb 2004 15:22:17 -0500 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx with esmtp (Exim 4.12) id 1Atufd-0005cO-00 for mip4@ietf.org; Thu, 19 Feb 2004 15:21:17 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate3) with ESMTP id i1JKLFUg026077 for ; Thu, 19 Feb 2004 13:21:15 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id i1JKJxPW025057 for ; Thu, 19 Feb 2004 14:19:59 -0600 Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.2) id <182PXTFB>; Thu, 19 Feb 2004 14:21:15 -0600 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: Nakhjiri Madjid-MNAKHJI1 , "'mip4@ietf.org'" Date: Thu, 19 Feb 2004 14:21:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="iso-8859-1" Subject: [Mip4] questions on Mobile IP Challenge/ response Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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.2 required=5.0 tests=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 > Hi, > > I am looking at the RFC 3012bis draft and aaa-key drafts and have the following questions. > I was hoping somebody on this list would be nice and clear my confusion! > > It seems that the RFC 3344 defines 3 registration authentication extensions (MN-FA, MN-HA and FA-HA), but > calculation of the authenticator within these extensions do not require any keys. At the same time you, it seems that you can only add an authentication extension, > when you have an SA between the two nodes, e.g. you only add an Mobile-Foreign Auth. extension if Mobile and FA share an SA, while any node can verify the extensions destined for other nodes > , since no keys are used in calculation of RFC 3344 authenticators, right? > > Now the RFC3012bis defines a new generalized extension for Mobile-any entity authentication and adds AAA > server as the first example. It is odd that the generalized extension is not backward compatible with the > specific ones defined in RFC 3344 (namely for MN-FA and MN-HA), but that is another issue. > My question is, > > 1- It seems that the new Mobile-AAA auth. extension uses the keys for calculation of authenticator, true? > The explanation is section 6 is not clear: it says authenticator is computed on the following > > (preceding MIP data || type|| subtype, length, SPI) * > > but then there is a function call is as follows > > hmac_md5(data, datalen, key, keylength, authenticator) ** > > And it is not clear what "data" is? and what is inserted in authenticator field of the extension? > Is it **? or is it *? or do we add both * and ** to the message? Reading the draft it seems that we would add just the authenticator * to the message, but from the formulation above it makes sense to add ** to the message. > 2-Section 3.2 on FA's processing of registration requests, it says the FA checks on the registration > request to see Mobile-Foreign Authentication extension includes a challenge. However, that extension > as defined in RFC 3344 does not include a challenge, so how is this possible? > > > 3-In section 3.2 on , it says that the FA checks the authenticator > within the Mobile-AAA auth. extension for validity. > If the authenticator data is hashed with a key that only Mobile and AAA server share, how can the FA do that? > 4-Finally, I saw on the archive there has been some discussions on what Mobile-AAA shared secret is? and people suggested passwords or hashes of passwords, anybody has any experience on how this is done? Thanks, Madjid -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 19 16:56: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 QAA21101 for ; Thu, 19 Feb 2004 16:56: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 1Atw8p-0004pH-Um for mip4-archive@odin.ietf.org; Thu, 19 Feb 2004 16:55:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JLtVCZ018551 for mip4-archive@odin.ietf.org; Thu, 19 Feb 2004 16:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atw8p-0004p8-Ps for mip4-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 16:55: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 QAA20833 for ; Thu, 19 Feb 2004 16:55:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atw8n-0003Ar-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 16:55:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atw81-00036M-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 16:54:42 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atw7N-0002zm-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 16:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atw7N-0004k7-8X; Thu, 19 Feb 2004 16:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atw6q-0004jV-7Q for mip4@optimus.ietf.org; Thu, 19 Feb 2004 16:53: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 QAA18917 for ; Thu, 19 Feb 2004 16:53:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atw6o-0002uR-00 for mip4@ietf.org; Thu, 19 Feb 2004 16:53:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atw5n-0002mn-00 for mip4@ietf.org; Thu, 19 Feb 2004 16:52:24 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1Atw4o-0002fE-00 for mip4@ietf.org; Thu, 19 Feb 2004 16:51:23 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1JLohA02373; Thu, 19 Feb 2004 15:50:44 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1JLofR26401; Thu, 19 Feb 2004 15:50:41 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HTCQ0B-0001TO-00; Thu, 19 Feb 2004 16:50:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16437.12204.575288.375582@gargle.gargle.HOWL> Date: Thu, 19 Feb 2004 15:50:36 -0600 From: Pete McCann To: Nakhjiri Madjid-MNAKHJI1 Cc: "'mip4@ietf.org'" Subject: [Mip4] questions on Mobile IP Challenge/ response In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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=AWL,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Madjid, Nakhjiri Madjid-MNAKHJI1 writes: > Hi, > I am looking at the RFC 3012bis draft and aaa-key drafts and have > the following questions. I was hoping somebody on this list would > be nice and clear my confusion! > It seems that the RFC 3344 defines 3 registration authentication > extensions (MN-FA, MN-HA and FA-HA), but calculation of the > authenticator within these extensions do not require any keys. At > the same time you, it seems that you can only add an authentication > extension, when you have an SA between the two nodes, e.g. you only > add an Mobile-Foreign Auth. extension if Mobile and FA share an SA, > while any node can verify the extensions destined for other nodes , > since no keys are used in calculation of RFC 3344 authenticators, > right? This is not correct, keys are most definitely needed between all pairs of nodes sharing security associations. See sections 3.5.1 and 5.1 of RFC 3344. > Now the RFC3012bis defines a new generalized extension for > Mobile-any entity authentication and adds AAA server as the first > example. It is odd that the generalized extension is not backward > compatible with the specific ones defined in RFC 3344 (namely for > MN-FA and MN-HA), but that is another issue. The format change was done in an attempt to be more frugal with the extension number space, so that we only need to allocate a new subtype within the authentication extension if we want to create new ones in the future. > My question is, > 1- It seems that the new Mobile-AAA auth. extension uses the keys > for calculation of authenticator, true? The explanation is section > 6 is not clear: it says authenticator is computed on the following > (preceding MIP data || type|| subtype, length, SPI) * > but then there is a function call is as follows > hmac_md5(data, datalen, key, keylength, authenticator) ** > And it is not clear what "data" is? and what is inserted in > authenticator field of the extension? Is it **? or is it *? or do > we add both * and ** to the message? Reading the draft it seems > that we would add just the authenticator * to the message, but from > the formulation above it makes sense to add ** to the message. If you read RFC 2104, this should become more clear: that document defines the interface to the HMAC function, and if you look closely at the sample code the "authentictor" is actually the return value of the function. So "data" should be set to * and the "authenticator", returned from the HMAC function, should be filled in to the MN-AAA authentication extension. > 2-Section 3.2 on FA's processing of registration requests, it says > the FA checks on the registration request to see Mobile-Foreign > Authentication extension includes a challenge. However, that > extension as defined in RFC 3344 does not include a challenge, so > how is this possible? That's not quite what the draft says: the challenge value is carried in an extension separate from the MN-AAA or MN-FA authentication extension: Upon receipt of the Registration Request, if the foreign agent has issued a Challenge as part of its Agent Advertisements, and it does not have a security association with the mobile node, then the Foreign Agent SHOULD check that the Mobile-Foreign Challenge extension exists, and that it contains a challenge value previously unused by the Mobile Node. The FA is required to check that the included challenge comes before (i.e., is covered by (i.e., included in the HMAC calculation)) an MN-AAA or MN-FA authentication extension: Furthermore, the foreign agent MUST check that there is either a Mobile-Foreign, or a Mobile-AAA Authentication extension after the Challenge extension. > 3-In section 3.2 on , it says that the FA checks the authenticator > within the Mobile-AAA auth. extension for validity. If the > authenticator data is hashed with a key that only Mobile and AAA > server share, how can the FA do that? It is outside the scope of the document, but a high-level example is given in Appendix B and C. Basically, you need to outsource the validity check to some other entity that does have the key. > 4-Finally, I saw on the archive there has been some discussions on > what Mobile-AAA shared secret is? and people suggested passwords > or hashes of passwords, anybody has any experience on how this is > done? You need to set it to a random number of sufficient length. For example, passwords that might be found in an english dictionary are unacceptable. Configuring the key into the MN and AAA servers is outside the scope of 3012bis. It is possible that some future work might address this, but for now you need to do it manually or by some out-of-band, secure channel. -Pete > Thanks, > > Madjid -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 19 17:55: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 RAA00128 for ; Thu, 19 Feb 2004 17:55:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atx4s-0000YG-9a for mip4-archive@odin.ietf.org; Thu, 19 Feb 2004 17:55:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1JMtU04002114 for mip4-archive@odin.ietf.org; Thu, 19 Feb 2004 17:55:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atx4s-0000Y1-2T for mip4-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 17:55: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 RAA00121 for ; Thu, 19 Feb 2004 17:55:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atx4p-0007L3-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 17:55:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atx3v-0007Iq-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 17:54:31 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Atx3P-0007GD-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 17:53:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atx3R-0000EK-00; Thu, 19 Feb 2004 17:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Atx2w-0000Cr-OA for mip4@optimus.ietf.org; Thu, 19 Feb 2004 17:53: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 RAA00019 for ; Thu, 19 Feb 2004 17:53:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Atx2u-0007FL-00 for mip4@ietf.org; Thu, 19 Feb 2004 17:53:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Atx1z-0007D3-00 for mip4@ietf.org; Thu, 19 Feb 2004 17:52:32 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1Atx1Z-0007AH-00 for mip4@ietf.org; Thu, 19 Feb 2004 17:52:05 -0500 Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id i1JMpXjv030100; Thu, 19 Feb 2004 23:51:34 +0100 Message-ID: <40353DD3.4050703@ipunplugged.com> Date: Thu, 19 Feb 2004 23:50:59 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: Yoshiyuki Tsuda CC: mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040213193509.16ac6bd4.henrik@levkowetz.com> <16433.18709.548019.259179@gargle.gargle.HOWL> <20040217015137.0eb79e44.henrik@levkowetz.com> <16434.19604.320288.837012@gargle.gargle.HOWL> <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> In-Reply-To: <200402181522.AAA28994@toshiba.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Yoshi-san, I might be misunderstanding the subject here and not that it's anything impossible to solve. But the important thing must be to identify the home agent, not the home network. Don't you need to amend your algorithm a little bit. The prime example is that you have two home agents on the same network segment. This could be for load sharing or for redundancy or for a bit of both. When you enter the network from internet, you hear a advertisement and notices that it's a home agent advertisement with the correct network mask. The MN deregister with that one and starts to grat arp. But if it infact was the other HA that you had a binding to, you have two devises arping for the same address until you deregister with the other HA aswell or the binding times out. Regards /// Hasse Yoshiyuki Tsuda wrote: >Hello Henrik, > > Here, I have just one comment: > >at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote: > > >>Yes. What with the NAI having its own extension, I don't have any >>example right now which I'd want to promote ... unless maybe the >>home network prefix. That really belongs with dynamic home address >>assignment rather than dynamic ha assignment, but it's part of the >>same area of functionality; and we don't have a way today to inform >>the MN of the appropriate netmask - or alternatively the private-side >>HA interface address - or whatever other way of identifying the home >>network people have implemented. >> >> > > About the netmask, an MN can extract the home subnet prefix by > the following way: > - Mobility Agents are assumed to advertise correct subnet prefix > to their connected subnets. > - An MN with dynamic home address compares it with the current > subnet address and prefix. If the home address is within the > current subnet, the MN can extract that the home prefix is the > current prefix. > - Before the MN encounters its home subnet, the MN should assume > its home prefix is 32. > > Our MN has the above function, and is working. :) > >Thanks. >-Yoshi > > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Feb 19 22:52: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 WAA15115 for ; Thu, 19 Feb 2004 22:52: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 1Au1hc-0004zA-Rs for mip4-archive@odin.ietf.org; Thu, 19 Feb 2004 22:51:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K3pm8K019159 for mip4-archive@odin.ietf.org; Thu, 19 Feb 2004 22:51:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au1hc-0004yu-L0 for mip4-web-archive@optimus.ietf.org; Thu, 19 Feb 2004 22:51: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 WAA15095 for ; Thu, 19 Feb 2004 22:51:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au1hZ-0005Bs-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 22:51:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au1gd-000585-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 22:50:48 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au1fx-00054D-00 for mip4-web-archive@ietf.org; Thu, 19 Feb 2004 22:50:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au1fz-0004uL-3V; Thu, 19 Feb 2004 22:50:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au1fl-0004qJ-3B for mip4@optimus.ietf.org; Thu, 19 Feb 2004 22:49: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 WAA15033 for ; Thu, 19 Feb 2004 22:49:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au1fh-00053K-00 for mip4@ietf.org; Thu, 19 Feb 2004 22:49:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au1ew-0004wD-00 for mip4@ietf.org; Thu, 19 Feb 2004 22:49:03 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1Au1e2-0004l4-00 for mip4@ietf.org; Thu, 19 Feb 2004 22:48:06 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1K3lxMH020588; Fri, 20 Feb 2004 12:47:59 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1K3lwnl008540; Fri, 20 Feb 2004 12:47:58 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id NAA08532 ; Fri, 20 Feb 2004 12:47:58 +0900 Received: from mx2.toshiba.co.jp by tis2.tis.toshiba.co.jp id MAA17152; Fri, 20 Feb 2004 12:47:57 +0900 (JST) Received: by toshiba.co.jp id MAA11519; Fri, 20 Feb 2004 12:47:56 +0900 (JST) Message-Id: <200402200347.MAA11519@toshiba.co.jp> Date: Fri, 20 Feb 2004 12:47:47 +0900 From: Yoshiyuki Tsuda Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) To: Hans =?ISO-8859-1?Q?Sj=F6strand?= Cc: mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <40353DD3.4050703@ipunplugged.com> References: <20040217015137.0eb79e44.henrik@levkowetz.com> <16434.19604.320288.837012@gargle.gargle.HOWL> <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> <40353DD3.4050703@ipunplugged.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hello Hans, My comments are inlined: at Thu, 19 Feb 2004 23:50:59 +0100 Hans Sj=F6strand wrote: >Yoshi-san, > >I might be misunderstanding the subject here and not that it's anything=20= >impossible to solve. But the important thing must be to identify the=20 >home agent, not the home network. Don't you need to amend your algorithm=20= >a little bit. Ah, yes, I agree that home netmask info doesn't solve your original example. I'm sorry that I went to a bit different example. >The prime example is that you have two home agents on the same network=20 >segment. This could be for load sharing or for redundancy or for a bit=20 >of both. When you enter the network from internet, you hear a=20 >advertisement and notices that it's a home agent advertisement with the=20= >correct network mask. The MN deregister with that one and starts to grat=20= >arp. But if it infact was the other HA that you had a binding to, you=20 >have two devises arping for the same address until you deregister with=20 >the other HA aswell or the binding times out. In case of your original example, VSE or including NAI in advertisements might solve your example, as some other persons have proposed to you. According to your above configuration, if the MN can identify its private home network, the MN should send a deregistration request to the external(public) HA address, I think. By this way, the MN succeeds in deregistration to the HA whihch really has a binding to the MN. Here, I assume: - the MN has a configured private home address and prefix, - the MN gets an public(external) HA address by dynamic HA, before returning to private home network. Am I still missing anything about your concerning ? Have a nice weekend. Thanks. -Yoshi >Regards >/// Hasse > >Yoshiyuki Tsuda wrote: > >>Hello Henrik, >> >> Here, I have just one comment: >> >>at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote: >> =20 >> >>>Yes. What with the NAI having its own extension, I don't have any >>>example right now which I'd want to promote ... unless maybe the >>>home network prefix. That really belongs with dynamic home address >>>assignment rather than dynamic ha assignment, but it's part of the >>>same area of functionality; and we don't have a way today to inform >>>the MN of the appropriate netmask - or alternatively the private-side >>>HA interface address - or whatever other way of identifying the home >>>network people have implemented. >>> =20 >>> >> >> About the netmask, an MN can extract the home subnet prefix by >> the following way: >> - Mobility Agents are assumed to advertise correct subnet prefix >> to their connected subnets. >> - An MN with dynamic home address compares it with the current >> subnet address and prefix. If the home address is within the >> current subnet, the MN can extract that the home prefix is the >> current prefix. >> - Before the MN encounters its home subnet, the MN should assume >> its home prefix is 32. >> >> Our MN has the above function, and is working. :) >> >>Thanks. >>-Yoshi >> >> =20 >> -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 20 04:53: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 EAA12659 for ; Fri, 20 Feb 2004 04:53: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 1Au7L9-0008EW-Tb for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 04:53:00 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1K9qxdu031642 for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 04:52:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au7L4-0008EH-AU for mip4-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 04:52: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 EAA12652 for ; Fri, 20 Feb 2004 04:52:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au7L1-00079q-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 04:52:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au7K2-000776-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 04:51:50 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Au7JL-00074I-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 04: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 1Au7JM-0007yx-Bq; Fri, 20 Feb 2004 04: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 1Au7J1-0007xQ-Uz for mip4@optimus.ietf.org; Fri, 20 Feb 2004 04:50: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 EAA12592 for ; Fri, 20 Feb 2004 04:50:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au7Iy-00073K-00 for mip4@ietf.org; Fri, 20 Feb 2004 04:50:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au7I6-00070o-00 for mip4@ietf.org; Fri, 20 Feb 2004 04:49:51 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1Au7HI-0006tw-00 for mip4@ietf.org; Fri, 20 Feb 2004 04:49:01 -0500 Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id i1K9mTjv005677; Fri, 20 Feb 2004 10:48:30 +0100 Message-ID: <4035D7CF.4010606@ipunplugged.com> Date: Fri, 20 Feb 2004 10:47:59 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: Yoshiyuki Tsuda CC: mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040217015137.0eb79e44.henrik@levkowetz.com> <16434.19604.320288.837012@gargle.gargle.HOWL> <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> <40353DD3.4050703@ipunplugged.com> <200402200347.MAA11519@toshiba.co.jp> In-Reply-To: <200402200347.MAA11519@toshiba.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailgw.local.ipunplugged.com id i1K9mTjv005677 Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Yoshi-san, Comments inline Yoshiyuki Tsuda wrote: >Hello Hans, > > My comments are inlined: > >at Thu, 19 Feb 2004 23:50:59 +0100 Hans Sj=F6strand wrote: > =20 > >>Yoshi-san, >> >>I might be misunderstanding the subject here and not that it's anything= =20 >>impossible to solve. But the important thing must be to identify the=20 >>home agent, not the home network. Don't you need to amend your algorith= m=20 >>a little bit. >> =20 >> > > Ah, yes, I agree that home netmask info doesn't solve your original > example. I'm sorry that I went to a bit different example. > > =20 > >>The prime example is that you have two home agents on the same network=20 >>segment. This could be for load sharing or for redundancy or for a bit=20 >>of both. When you enter the network from internet, you hear a=20 >>advertisement and notices that it's a home agent advertisement with the= =20 >>correct network mask. The MN deregister with that one and starts to gra= t=20 >>arp. But if it infact was the other HA that you had a binding to, you=20 >>have two devises arping for the same address until you deregister with=20 >>the other HA aswell or the binding times out. >> =20 >> > > In case of your original example, VSE or including NAI in > advertisements might solve your example, as some other persons > have proposed to you. > According to your above configuration, if the MN can identify its > private home network, the MN should send a deregistration request > to the external(public) HA address, I think. By this way, the MN > succeeds in deregistration to the HA whihch really has a binding to > the MN. Here, I assume: > - the MN has a configured private home address and prefix, > - the MN gets an public(external) HA address by dynamic HA, > before returning to private home network. > Am I still missing anything about your concerning ? > Have a nice weekend. > =20 > Pretty clever. But there are a security aspect about this. Deregistrations are a little=20 bit sensitive since it makes the client sent the traffic untunneled and=20 also in most cases turns off the IPsec client on the MN to get=20 seamlessness. Therefore, local deregistrations (Home address=3DCoA) are=20 sent with TTL =3D1. In many cases the computer with the HA isn't the=20 default gateway of the network. Since the deregistrations in your=20 proposal is sent to a non-local address, this is delivered to the=20 default gateway and dropped there because of TTL. This is not mandated by some spec, just our assessment and implementation. Regards /// Hasse >Thanks. >-Yoshi > > =20 > >>Regards >>/// Hasse >> >>Yoshiyuki Tsuda wrote: >> >> =20 >> >>>Hello Henrik, >>> >>>Here, I have just one comment: >>> >>>at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote: >>>=20 >>> >>> =20 >>> >>>>Yes. What with the NAI having its own extension, I don't have any >>>>example right now which I'd want to promote ... unless maybe the >>>>home network prefix. That really belongs with dynamic home address >>>>assignment rather than dynamic ha assignment, but it's part of the >>>>same area of functionality; and we don't have a way today to inform >>>>the MN of the appropriate netmask - or alternatively the private-side >>>>HA interface address - or whatever other way of identifying the home >>>>network people have implemented. >>>> =20 >>>> >>>> =20 >>>> >>>About the netmask, an MN can extract the home subnet prefix by >>>the following way: >>>- Mobility Agents are assumed to advertise correct subnet prefix >>> to their connected subnets. >>>- An MN with dynamic home address compares it with the current >>> subnet address and prefix. If the home address is within the >>> current subnet, the MN can extract that the home prefix is the >>> current prefix. >>>- Before the MN encounters its home subnet, the MN should assume >>> its home prefix is 32. >>> >>>Our MN has the above function, and is working. :) >>> >>>Thanks. >>>-Yoshi >>> >>>=20 >>> >>> =20 >>> > > =20 > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 20 09:55: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 JAA24596 for ; Fri, 20 Feb 2004 09:55: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 1AuC3O-0007in-86 for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 09:54:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KEswx0029681 for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 09:54:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuC3O-0007ie-2E for mip4-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 09:54: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 JAA24575 for ; Fri, 20 Feb 2004 09:54:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuC3M-0005cP-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 09:54:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuC2N-0005ZL-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 09:53:56 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuC1T-0005X0-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 09:52:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuC1U-0007Zi-Ju; Fri, 20 Feb 2004 09:53:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuC1S-0007ZU-ME for mip4@optimus.ietf.org; Fri, 20 Feb 2004 09:52: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 JAA24528 for ; Fri, 20 Feb 2004 09:52:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuC1Q-0005Wa-00 for mip4@ietf.org; Fri, 20 Feb 2004 09:52:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuC0V-0005TI-00 for mip4@ietf.org; Fri, 20 Feb 2004 09:52:00 -0500 Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx with esmtp (Exim 4.12) id 1AuBza-0005Pj-00 for mip4@ietf.org; Fri, 20 Feb 2004 09:51:03 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id i1KEp0MH013352; Fri, 20 Feb 2004 23:51:00 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id i1KEp0Sa008368; Fri, 20 Feb 2004 23:51:00 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id ZAA08367 ; Fri, 20 Feb 2004 23:50:59 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp id XAA00353; Fri, 20 Feb 2004 23:50:59 +0900 (JST) Received: by toshiba.co.jp id XAA18925; Fri, 20 Feb 2004 23:50:59 +0900 (JST) Message-Id: <200402201450.XAA18925@toshiba.co.jp> Date: Fri, 20 Feb 2004 23:50:49 +0900 From: Yoshiyuki Tsuda Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) To: Hans =?ISO-8859-1?Q?Sj=F6strand?= Cc: mip4@ietf.org Organization: Corporate R&D Center, Toshiba Corporation In-Reply-To: <4035D7CF.4010606@ipunplugged.com> References: <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> <40353DD3.4050703@ipunplugged.com> <200402200347.MAA11519@toshiba.co.jp> <4035D7CF.4010606@ipunplugged.com> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hans, I see, there are some issues according to VPN configuration. About the TTL issue, I believe the current rfc doesn't mandate TTL=3D1 in case of unicast deregistaration. But I can understand your security concern. We cannot set TTL=3D1 in deregistration packets from our MNs, because some vendor's HAs can be configured HA IP addresses apart from MNs' home subnets. Thus, we need to set TTL more than one. I'd like to try to find any other alternative way to this security issue. Have a nice weekend! Thanks. -Yoshi at Fri, 20 Feb 2004 10:47:59 +0100 Hans Sj=F6strand wrote: >Yoshi-san, > >Comments inline > >Yoshiyuki Tsuda wrote: > >>Hello Hans, >> >> My comments are inlined: >> >>at Thu, 19 Feb 2004 23:50:59 +0100 Hans Sj=F6strand wrote: >> =20 >> >>>Yoshi-san, >>> >>>I might be misunderstanding the subject here and not that it's anything=20= >>>impossible to solve. But the important thing must be to identify the=20 >>>home agent, not the home network. Don't you need to amend your algorithm= =20 >>>a little bit. >>> =20 >>> >> >> Ah, yes, I agree that home netmask info doesn't solve your original >> example. I'm sorry that I went to a bit different example. >> >> =20 >> >>>The prime example is that you have two home agents on the same network=20= >>>segment. This could be for load sharing or for redundancy or for a bit=20= >>>of both. When you enter the network from internet, you hear a=20 >>>advertisement and notices that it's a home agent advertisement with the=20= >>>correct network mask. The MN deregister with that one and starts to grat= =20 >>>arp. But if it infact was the other HA that you had a binding to, you=20= >>>have two devises arping for the same address until you deregister with=20= >>>the other HA aswell or the binding times out. >>> =20 >>> >> >> In case of your original example, VSE or including NAI in >> advertisements might solve your example, as some other persons >> have proposed to you. >> According to your above configuration, if the MN can identify its >> private home network, the MN should send a deregistration request >> to the external(public) HA address, I think. By this way, the MN >> succeeds in deregistration to the HA whihch really has a binding to >> the MN. Here, I assume: >> - the MN has a configured private home address and prefix, >> - the MN gets an public(external) HA address by dynamic HA, >> before returning to private home network. >> Am I still missing anything about your concerning ? >> Have a nice weekend. >> =20 >> > >Pretty clever. > >But there are a security aspect about this. Deregistrations are a little=20= >bit sensitive since it makes the client sent the traffic untunneled and=20= >also in most cases turns off the IPsec client on the MN to get=20 >seamlessness. Therefore, local deregistrations (Home address=3DCoA) are=20= >sent with TTL =3D1. In many cases the computer with the HA isn't the=20 >default gateway of the network. Since the deregistrations in your=20 >proposal is sent to a non-local address, this is delivered to the=20 >default gateway and dropped there because of TTL. > >This is not mandated by some spec, just our assessment and implementation.= > >Regards >/// Hasse > >>Thanks. >>-Yoshi >> >> =20 >> >>>Regards >>>/// Hasse >>> >>>Yoshiyuki Tsuda wrote: >>> >>> =20 >>> >>>>Hello Henrik, >>>> >>>>Here, I have just one comment: >>>> >>>>at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote: >>>>=20 >>>> >>>> =20 >>>> >>>>>Yes. What with the NAI having its own extension, I don't have any >>>>>example right now which I'd want to promote ... unless maybe the >>>>>home network prefix. That really belongs with dynamic home address >>>>>assignment rather than dynamic ha assignment, but it's part of the >>>>>same area of functionality; and we don't have a way today to inform >>>>>the MN of the appropriate netmask - or alternatively the private-side >>>>>HA interface address - or whatever other way of identifying the home >>>>>network people have implemented. >>>>> =20 >>>>> >>>>> =20 >>>>> >>>>About the netmask, an MN can extract the home subnet prefix by >>>>the following way: >>>>- Mobility Agents are assumed to advertise correct subnet prefix >>>> to their connected subnets. >>>>- An MN with dynamic home address compares it with the current >>>> subnet address and prefix. If the home address is within the >>>> current subnet, the MN can extract that the home prefix is the >>>> current prefix. >>>>- Before the MN encounters its home subnet, the MN should assume >>>> its home prefix is 32. >>>> >>>>Our MN has the above function, and is working. :) >>>> >>>>Thanks. >>>>-Yoshi >>>> >>>>=20 >>>> >>>> =20 >>>> >> >> =20 >> -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 20 12:10: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 MAA02270 for ; Fri, 20 Feb 2004 12:10: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 1AuEA8-0002uT-Ua for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 12:10:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KHA4pG011179 for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 12: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 1AuEA8-0002uE-Im for mip4-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 12:10: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 MAA02198 for ; Fri, 20 Feb 2004 12:10:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuEA7-0000Yn-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 12:10:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuE97-0000U7-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 12:09:01 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuE88-0000PP-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 12:08:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuE89-0002hY-5F; Fri, 20 Feb 2004 12:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuE7K-0002Tu-H3 for mip4@optimus.ietf.org; Fri, 20 Feb 2004 12:07: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 MAA02136 for ; Fri, 20 Feb 2004 12:07:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuE7I-0000Mc-00 for mip4@ietf.org; Fri, 20 Feb 2004 12:07:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuE6O-0000JC-00 for mip4@ietf.org; Fri, 20 Feb 2004 12:06:12 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AuE66-0000Dc-00 for mip4@ietf.org; Fri, 20 Feb 2004 12:05:54 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1KH4Xr11165; Fri, 20 Feb 2004 11:04:38 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1KH4Wf21440; Fri, 20 Feb 2004 11:04:32 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HTE7FG-00018K-00; Fri, 20 Feb 2004 12:04:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16438.15899.451321.755356@gargle.gargle.HOWL> Date: Fri, 20 Feb 2004 11:04:27 -0600 From: Pete McCann To: Ali.Akgun@utstar.com, "Jayshree Bharatia" , henrik@levkowetz.com, mip4@ietf.org Subject: RE: [Mip4] CORRECTED: Copyright and IPR (was 3012bis) In-Reply-To: <16435.50124.851288.46989@gargle.gargle.HOWL> References: <16435.50124.851288.46989@gargle.gargle.HOWL> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Ok, correction: the required Copyright and IPR boilerplate has changed (as of this past week). Everyone please use the text available at: ftp://ftp.rfc-editor.org/in-notes/rfc-editor/boilerplate.txt This is as a result of the recent publication of RFC 3667, 3668, and 3669. Also, please note that it is NOT proper to reference specific IPR claims or patent numbers in your document. This was done in some documents in the past but now the proper thing is to submit the information to ietf-ipr@ietf.org for inclusion in the online directory at http://www.ietf.org/ipr. I understand that an updated version of xml2rfc will be out next week that will handle this new boilerplate. -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 20 12:17: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 MAA02504 for ; Fri, 20 Feb 2004 12:17: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 1AuEGt-0003ND-68 for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 12:17:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KHH34o012961 for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 12:17:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEGt-0003My-0E for mip4-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 12:17: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 MAA02489 for ; Fri, 20 Feb 2004 12:16:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuEGr-0000zP-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 12:17:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuEFv-0000vu-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 12:16:05 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuEEy-0000t3-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 12:15:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEEy-0003C3-Gy; Fri, 20 Feb 2004 12:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuEE1-0003AD-UU for mip4@optimus.ietf.org; Fri, 20 Feb 2004 12:14: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 MAA02444 for ; Fri, 20 Feb 2004 12:14:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuEE0-0000pc-00 for mip4@ietf.org; Fri, 20 Feb 2004 12:14:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuED3-0000mS-00 for mip4@ietf.org; Fri, 20 Feb 2004 12:13:06 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AuECD-0000g8-00 for mip4@ietf.org; Fri, 20 Feb 2004 12:12:13 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1KHBHr16991; Fri, 20 Feb 2004 11:11:20 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1KHBGf06983; Fri, 20 Feb 2004 11:11:16 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HTE7QO-00013K-00; Fri, 20 Feb 2004 12:11:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16438.16303.251321.866852@gargle.gargle.HOWL> Date: Fri, 20 Feb 2004 11:11:11 -0600 From: Pete McCann To: Yoshiyuki Tsuda Cc: Hans =?ISO-8859-1?Q?Sj=F6strand?= , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) In-Reply-To: <200402201450.XAA18925@toshiba.co.jp> References: <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> <40353DD3.4050703@ipunplugged.com> <200402200347.MAA11519@toshiba.co.jp> <4035D7CF.4010606@ipunplugged.com> <200402201450.XAA18925@toshiba.co.jp> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Also, isn't it always possible to deregister remotely, i.e., when you are nicely shutting down a mobile node, even though you never returned home? Requiring TTL=3D1 in deregistrations doesn't seem proper. -Pete Yoshiyuki Tsuda writes: > Hans, >=20 > I see, there are some issues according to VPN configuration. > About the TTL issue, I believe the current rfc doesn't mandate > TTL=3D1 in case of unicast deregistaration. But I can understand > your security concern. > We cannot set TTL=3D1 in deregistration packets from our MNs, > because some vendor's HAs can be configured HA IP addresses > apart from MNs' home subnets. Thus, we need to set TTL > more than one. I'd like to try to find any other alternative way > to this security issue. Have a nice weekend! >=20 > Thanks. > -Yoshi >=20 > at Fri, 20 Feb 2004 10:47:59 +0100 Hans Sj=F6strand wrote: > >Yoshi-san, > > > >Comments inline > > > >Yoshiyuki Tsuda wrote: > > > >>Hello Hans, > >> > >> My comments are inlined: > >> > >>at Thu, 19 Feb 2004 23:50:59 +0100 Hans Sj=F6strand wrote: > >> =20 > >> > >>>Yoshi-san, > >>> > >>>I might be misunderstanding the subject here and not that it's an= ything=20 > >>>impossible to solve. But the important thing must be to identify = the=20 > >>>home agent, not the home network. Don't you need to amend your al= gorithm=20 > >>>a little bit. > >>> =20 > >>> > >> > >> Ah, yes, I agree that home netmask info doesn't solve your origin= al > >> example. I'm sorry that I went to a bit different example. > >> > >> =20 > >> > >>>The prime example is that you have two home agents on the same ne= twork=20 > >>>segment. This could be for load sharing or for redundancy or for = a bit=20 > >>>of both. When you enter the network from internet, you hear a=20 > >>>advertisement and notices that it's a home agent advertisement wi= th the=20 > >>>correct network mask. The MN deregister with that one and starts = to grat=20 > >>>arp. But if it infact was the other HA that you had a binding to,= you=20 > >>>have two devises arping for the same address until you deregister= with=20 > >>>the other HA aswell or the binding times out. > >>> =20 > >>> > >> > >> In case of your original example, VSE or including NAI in > >> advertisements might solve your example, as some other persons > >> have proposed to you. > >> According to your above configuration, if the MN can identify its= > >> private home network, the MN should send a deregistration request= > >> to the external(public) HA address, I think. By this way, the MN= > >> succeeds in deregistration to the HA whihch really has a binding = to > >> the MN. Here, I assume: > >> - the MN has a configured private home address and prefix, > >> - the MN gets an public(external) HA address by dynamic HA, > >> before returning to private home network. > >> Am I still missing anything about your concerning ? > >> Have a nice weekend. > >> =20 > >> > > > >Pretty clever. > > > >But there are a security aspect about this. Deregistrations are a l= ittle=20 > >bit sensitive since it makes the client sent the traffic untunneled= and=20 > >also in most cases turns off the IPsec client on the MN to get=20 > >seamlessness. Therefore, local deregistrations (Home address=3DCoA= ) are=20 > >sent with TTL =3D1. In many cases the computer with the HA isn't th= e=20 > >default gateway of the network. Since the deregistrations in your=20= > >proposal is sent to a non-local address, this is delivered to the=20= > >default gateway and dropped there because of TTL. > > > >This is not mandated by some spec, just our assessment and implemen= tation. > > > >Regards > >/// Hasse > > > >>Thanks. > >>-Yoshi > >> > >> =20 > >> > >>>Regards > >>>/// Hasse > >>> > >>>Yoshiyuki Tsuda wrote: > >>> > >>> =20 > >>> > >>>>Hello Henrik, > >>>> > >>>>Here, I have just one comment: > >>>> > >>>>at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote: > >>>>=20 > >>>> > >>>> =20 > >>>> > >>>>>Yes. What with the NAI having its own extension, I don't have = any > >>>>>example right now which I'd want to promote ... unless maybe th= e > >>>>>home network prefix. That really belongs with dynamic home addr= ess > >>>>>assignment rather than dynamic ha assignment, but it's part of = the > >>>>>same area of functionality; and we don't have a way today to in= form > >>>>>the MN of the appropriate netmask - or alternatively the privat= e-side > >>>>>HA interface address - or whatever other way of identifying the= home > >>>>>network people have implemented. > >>>>> =20 > >>>>> > >>>>> =20 > >>>>> > >>>>About the netmask, an MN can extract the home subnet prefix by > >>>>the following way: > >>>>- Mobility Agents are assumed to advertise correct subnet prefix= > >>>> to their connected subnets. > >>>>- An MN with dynamic home address compares it with the current > >>>> subnet address and prefix. If the home address is within the > >>>> current subnet, the MN can extract that the home prefix is the= > >>>> current prefix. > >>>>- Before the MN encounters its home subnet, the MN should assume= > >>>> its home prefix is 32. > >>>> > >>>>Our MN has the above function, and is working. :) > >>>> > >>>>Thanks. > >>>>-Yoshi -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Feb 20 13:48: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 NAA06374 for ; Fri, 20 Feb 2004 13:48:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFgy-0003Dj-1U for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 13:48:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KIm4jD012373 for mip4-archive@odin.ietf.org; Fri, 20 Feb 2004 13:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFgx-0003DU-My for mip4-web-archive@optimus.ietf.org; Fri, 20 Feb 2004 13:48: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 NAA06334 for ; Fri, 20 Feb 2004 13:48:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFgv-0007GU-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 13:48:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFfx-0007CW-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 13:47:02 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuFez-00078F-00 for mip4-web-archive@ietf.org; Fri, 20 Feb 2004 13: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 1AuFez-00032l-UO; Fri, 20 Feb 2004 13:46:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuFe6-000300-SW for mip4@optimus.ietf.org; Fri, 20 Feb 2004 13:45: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 NAA06252 for ; Fri, 20 Feb 2004 13:45:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuFe4-00074T-00 for mip4@ietf.org; Fri, 20 Feb 2004 13:45:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuFd5-00070g-00 for mip4@ietf.org; Fri, 20 Feb 2004 13:44:04 -0500 Received: from motgate.mot.com ([129.188.136.100]) by ietf-mx with esmtp (Exim 4.12) id 1AuFcH-0006xp-00 for mip4@ietf.org; Fri, 20 Feb 2004 13:43:13 -0500 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate.mot.com (Motorola/Motgate) with ESMTP id i1KIhB1q021153 for ; Fri, 20 Feb 2004 11:43:13 -0700 (MST) Received: from il27exm03.cig.mot.com (il27exm03.cig.mot.com [10.17.193.4]) by az33exr02.mot.com (Motorola/az33exr02) with ESMTP id i1KIa79D015622 for ; Fri, 20 Feb 2004 12:36:08 -0600 Received: by il27exm03.cig.mot.com with Internet Mail Service (5.5.2657.2) id <182PYDNB>; Fri, 20 Feb 2004 12:36:48 -0600 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Pete McCann'" Cc: mip4@ietf.org Subject: RE: [Mip4] questions on Mobile IP Challenge/ response Date: Fri, 20 Feb 2004 12:36:44 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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,NEW_DOMAIN_EXTENSIONS autolearn=no version=2.60 Hi Pete, Thank you very much for your quick answers. Please see inline comments. Regards, Madjid -----Original Message----- From: Pete McCann [mailto:mccap@lucent.com] Sent: Thursday, February 19, 2004 3:51 PM To: Nakhjiri Madjid-MNAKHJI1 Cc: mip4@ietf.org Subject: [Mip4] questions on Mobile IP Challenge/ response Hi, Madjid, Nakhjiri Madjid-MNAKHJI1 writes: > Hi, > I am looking at the RFC 3012bis draft and aaa-key drafts and have > the following questions. I was hoping somebody on this list would > be nice and clear my confusion! > It seems that the RFC 3344 defines 3 registration authentication > extensions (MN-FA, MN-HA and FA-HA), but calculation of the > authenticator within these extensions do not require any keys. At > the same time you, it seems that you can only add an authentication > extension, when you have an SA between the two nodes, e.g. you only > add an Mobile-Foreign Auth. extension if Mobile and FA share an SA, > while any node can verify the extensions destined for other nodes , > since no keys are used in calculation of RFC 3344 authenticators, > right? This is not correct, keys are most definitely needed between all pairs of nodes sharing security associations. See sections 3.5.1 and 5.1 of RFC 3344. Madjid>>Yes, I agree that, if a pair shares an SA, then you need keys for that SA. However, what I meant (as I understand from the aaa-key draft) is that originally the MN may only have a pre-shared secret with the AAA server, and may or may not have an SA with the HA or FA. So if it shares an SA with FA, then it will add a Mobile-Foreign Auth. extension to its registration request (after the Mobile-Foreign Challenge). If it does not share any SAs, it cannot add the Mobile-Foreign Authentication in its original registration request, right? (the MN needs to authenticate to the AAA server) > Now the RFC3012bis defines a new generalized extension for > Mobile-any entity authentication and adds AAA server as the first > example. It is odd that the generalized extension is not backward > compatible with the specific ones defined in RFC 3344 (namely for > MN-FA and MN-HA), but that is another issue. The format change was done in an attempt to be more frugal with the extension number space, so that we only need to allocate a new subtype within the authentication extension if we want to create new ones in the future. Madjid>>Sure, the draft explains the reason. However, we have types for 32, 33, 34 for MN-FA, MN-HA, FA-HA auth. extensions in RFC 3344. but type 36 for generalized auth. extension, with subtype for MN-AAA, so for historical reason it is messy. It would be nice WHENEVER the RFC 3344 is revised, we could get this fixed... > My question is, > 1- It seems that the new Mobile-AAA auth. extension uses the keys > for calculation of authenticator, true? The explanation is section > 6 is not clear: it says authenticator is computed on the following > (preceding MIP data || type|| subtype, length, SPI) * > but then there is a function call is as follows > hmac_md5(data, datalen, key, keylength, authenticator) ** > And it is not clear what "data" is? and what is inserted in > authenticator field of the extension? Is it **? or is it *? or do > we add both * and ** to the message? Reading the draft it seems > that we would add just the authenticator * to the message, but from > the formulation above it makes sense to add ** to the message. If you read RFC 2104, this should become more clear: that document defines the interface to the HMAC function, and if you look closely at the sample code the "authentictor" is actually the return value of the function. So "data" should be set to * and the "authenticator", returned from the HMAC function, should be filled in to the MN-AAA authentication extension. Madjid>> Thank you, I found the hmac_md5(text, text_len, key, key_len, digest) in the RFC 2104. It makes sense now! Just nitpicking suggestion, if the draft had denoted * and ** as follows data=(preceding MIP data || type|| subtype, length, SPI) * hmac_md5(data, datalen, key, keylength, authenticator) ** with a reference to RFC 2104, it would become easier to follow for people like me :) > 2-Section 3.2 on FA's processing of registration requests, it says > the FA checks on the registration request to see Mobile-Foreign > Authentication extension includes a challenge. However, that > extension as defined in RFC 3344 does not include a challenge, so > how is this possible? That's not quite what the draft says: the challenge value is carried in an extension separate from the MN-AAA or MN-FA authentication extension: Upon receipt of the Registration Request, if the foreign agent has issued a Challenge as part of its Agent Advertisements, and it does not have a security association with the mobile node, then the Foreign Agent SHOULD check that the Mobile-Foreign Challenge extension exists, and that it contains a challenge value previously unused by the Mobile Node. The FA is required to check that the included challenge comes before (i.e., is covered by (i.e., included in the HMAC calculation)) an MN-AAA or MN-FA authentication extension: Furthermore, the foreign agent MUST check that there is either a Mobile-Foreign, or a Mobile-AAA Authentication extension after the Challenge extension. Madjid>>Ok, I guess when reading this last part, I mistook the "Mobile-Foreign" above as "Mobile-Foreign Challenge extension" rather than "Mobile-Foreign Authentication extension" And I missed that The "challenge extension" means the "Mobile-Foreign Challenge extension", which must exist regardless or whether you have a Mobile-Foreign Auth. extension (if SA exists) or a Mobile-AAA auth. ext. (if SA does not exist), right? Too many things to keep straight in the beginning. clear now, thank you. > 3-In section 3.2 on , it says that the FA checks the authenticator > within the Mobile-AAA auth. extension for validity. If the > authenticator data is hashed with a key that only Mobile and AAA > server share, how can the FA do that? It is outside the scope of the document, but a high-level example is given in Appendix B and C. Basically, you need to outsource the validity check to some other entity that does have the key. Madjid>>I looked at the App. B, the way I see it, it is important to protect the FA from the rouge nodes, before the MN-AAA shared secret is verified by the AAA and the SAs are distributed. However, if it wasn't for distributing the keys, and you only needed to verify the MN's credentials and could do that at FA (by outsourcing) then why go all the why the AAA server to do this? This creates some confusion in the Mobile IP-AAA model (not the key mangement one), which says you go from FA to AAAH because AAAH is the only AAA server that can verify mobile's credentials and profiles, no? I don't see why having the FA to check the MN-AAA auth. extension is necessary (it is not very modular design). If the foreign domain policy requires authentication to the FA in absence of SAs, that is a separate issue (that is actually solved by verification infrastructure as stated in App B). Say presenting certs to the FA and then FA contacting a CA to verify the cert, is more natural to me than having to use the same MN-AAA key for this? > 4-Finally, I saw on the archive there has been some discussions on > what Mobile-AAA shared secret is? and people suggested passwords > or hashes of passwords, anybody has any experience on how this is > done? You need to set it to a random number of sufficient length. For example, passwords that might be found in an english dictionary are unacceptable. Configuring the key into the MN and AAA servers is outside the scope of 3012bis. It is possible that some future work might address this, but for now you need to do it manually or by some out-of-band, secure channel. Madjid>>Agree on the scope, I was just trying the gauge what it is done in practice. I guess I need to look at some of the new IETF security groups for that :) -Pete > Thanks, > > Madjid -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Feb 21 09:18: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 JAA01129 for ; Sat, 21 Feb 2004 09:18: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 1AuXws-00056c-HD for mip4-archive@odin.ietf.org; Sat, 21 Feb 2004 09:17:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1LEHgi6019620 for mip4-archive@odin.ietf.org; Sat, 21 Feb 2004 09:17:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuXws-00056N-5B for mip4-web-archive@optimus.ietf.org; Sat, 21 Feb 2004 09:17: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 JAA01077 for ; Sat, 21 Feb 2004 09:17:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuXwq-0005U4-00 for mip4-web-archive@ietf.org; Sat, 21 Feb 2004 09:17:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuXvw-0005Rp-00 for mip4-web-archive@ietf.org; Sat, 21 Feb 2004 09:16:45 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AuXvF-0005PT-00 for mip4-web-archive@ietf.org; Sat, 21 Feb 2004 09:16:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuXvE-0004vG-Vt; Sat, 21 Feb 2004 09:16:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuXuu-0004tj-Ef for mip4@optimus.ietf.org; Sat, 21 Feb 2004 09:15: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 JAA01026 for ; Sat, 21 Feb 2004 09:15:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuXus-0005Ne-00 for mip4@ietf.org; Sat, 21 Feb 2004 09:15:38 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuXtv-0005J5-00 for mip4@ietf.org; Sat, 21 Feb 2004 09:14:40 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AuXt1-0005BP-00 for mip4@ietf.org; Sat, 21 Feb 2004 09:13:43 -0500 Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id i1LED9jv024279; Sat, 21 Feb 2004 15:13:09 +0100 Message-ID: <40376756.3040007@ipunplugged.com> Date: Sat, 21 Feb 2004 15:12:38 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: Pete McCann CC: Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> <40353DD3.4050703@ipunplugged.com> <200402200347.MAA11519@toshiba.co.jp> <4035D7CF.4010606@ipunplugged.com> <200402201450.XAA18925@toshiba.co.jp> <16438.16303.251321.866852@gargle.gargle.HOWL> In-Reply-To: <16438.16303.251321.866852@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailgw.local.ipunplugged.com id i1LED9jv024279 Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Pete, You are quite correct, but note that I wrote > > >seamlessness. Therefore, local deregistrations (Home address=3DCoA)= are=20 > > >sent with TTL =3D1. =20 I have never commented on remote deregistrations. Also note =20 > > >This is not mandated by some spec, just our assessment and implement= ation. I have no intention to require anything. What I wanted to explain is that= it's not entirely a good idea to deregister against the public(external)= HA address obtained in the dynamic HA function.=20 /// Hasse Pete McCann wrote: >Also, isn't it always possible to deregister remotely, i.e., when you >are nicely shutting down a mobile node, even though you never returned >home? > >Requiring TTL=3D1 in deregistrations doesn't seem proper. > >-Pete > >Yoshiyuki Tsuda writes: > > Hans, > >=20 > > I see, there are some issues according to VPN configuration. > > About the TTL issue, I believe the current rfc doesn't mandate > > TTL=3D1 in case of unicast deregistaration. But I can understand > > your security concern. > > We cannot set TTL=3D1 in deregistration packets from our MNs, > > because some vendor's HAs can be configured HA IP addresses > > apart from MNs' home subnets. Thus, we need to set TTL > > more than one. I'd like to try to find any other alternative way > > to this security issue. Have a nice weekend! > >=20 > > Thanks. > > -Yoshi > >=20 > > at Fri, 20 Feb 2004 10:47:59 +0100 Hans Sj=F6strand wrote: > > >Yoshi-san, > > > > > >Comments inline > > > > > >Yoshiyuki Tsuda wrote: > > > > > >>Hello Hans, > > >> > > >> My comments are inlined: > > >> > > >>at Thu, 19 Feb 2004 23:50:59 +0100 Hans Sj=F6strand wrote: > > >> =20 > > >> > > >>>Yoshi-san, > > >>> > > >>>I might be misunderstanding the subject here and not that it's any= thing=20 > > >>>impossible to solve. But the important thing must be to identify t= he=20 > > >>>home agent, not the home network. Don't you need to amend your alg= orithm=20 > > >>>a little bit. > > >>> =20 > > >>> > > >> > > >> Ah, yes, I agree that home netmask info doesn't solve your origina= l > > >> example. I'm sorry that I went to a bit different example. > > >> > > >> =20 > > >> > > >>>The prime example is that you have two home agents on the same net= work=20 > > >>>segment. This could be for load sharing or for redundancy or for a= bit=20 > > >>>of both. When you enter the network from internet, you hear a=20 > > >>>advertisement and notices that it's a home agent advertisement wit= h the=20 > > >>>correct network mask. The MN deregister with that one and starts t= o grat=20 > > >>>arp. But if it infact was the other HA that you had a binding to, = you=20 > > >>>have two devises arping for the same address until you deregister = with=20 > > >>>the other HA aswell or the binding times out. > > >>> =20 > > >>> > > >> > > >> In case of your original example, VSE or including NAI in > > >> advertisements might solve your example, as some other persons > > >> have proposed to you. > > >> According to your above configuration, if the MN can identify its > > >> private home network, the MN should send a deregistration request > > >> to the external(public) HA address, I think. By this way, the MN > > >> succeeds in deregistration to the HA whihch really has a binding t= o > > >> the MN. Here, I assume: > > >> - the MN has a configured private home address and prefix, > > >> - the MN gets an public(external) HA address by dynamic HA, > > >> before returning to private home network. > > >> Am I still missing anything about your concerning ? > > >> Have a nice weekend. > > >> =20 > > >> > > > > > >Pretty clever. > > > > > >But there are a security aspect about this. Deregistrations are a li= ttle=20 > > >bit sensitive since it makes the client sent the traffic untunneled = and=20 > > >also in most cases turns off the IPsec client on the MN to get=20 > > >seamlessness. Therefore, local deregistrations (Home address=3DCoA)= are=20 > > >sent with TTL =3D1. In many cases the computer with the HA isn't the= =20 > > >default gateway of the network. Since the deregistrations in your=20 > > >proposal is sent to a non-local address, this is delivered to the=20 > > >default gateway and dropped there because of TTL. > > > > > >This is not mandated by some spec, just our assessment and implement= ation. > > > > > >Regards > > >/// Hasse > > > > > >>Thanks. > > >>-Yoshi > > >> > > >> =20 > > >> > > >>>Regards > > >>>/// Hasse > > >>> > > >>>Yoshiyuki Tsuda wrote: > > >>> > > >>> =20 > > >>> > > >>>>Hello Henrik, > > >>>> > > >>>>Here, I have just one comment: > > >>>> > > >>>>at Wed, 18 Feb 2004 14:50:35 +0100 Henrik Levkowetz wrote: > > >>>>=20 > > >>>> > > >>>> =20 > > >>>> > > >>>>>Yes. What with the NAI having its own extension, I don't have a= ny > > >>>>>example right now which I'd want to promote ... unless maybe the > > >>>>>home network prefix. That really belongs with dynamic home addre= ss > > >>>>>assignment rather than dynamic ha assignment, but it's part of t= he > > >>>>>same area of functionality; and we don't have a way today to inf= orm > > >>>>>the MN of the appropriate netmask - or alternatively the private= -side > > >>>>>HA interface address - or whatever other way of identifying the = home > > >>>>>network people have implemented. > > >>>>> =20 > > >>>>> > > >>>>> =20 > > >>>>> > > >>>>About the netmask, an MN can extract the home subnet prefix by > > >>>>the following way: > > >>>>- Mobility Agents are assumed to advertise correct subnet prefix > > >>>> to their connected subnets. > > >>>>- An MN with dynamic home address compares it with the current > > >>>> subnet address and prefix. If the home address is within the > > >>>> current subnet, the MN can extract that the home prefix is the > > >>>> current prefix. > > >>>>- Before the MN encounters its home subnet, the MN should assume > > >>>> its home prefix is 32. > > >>>> > > >>>>Our MN has the above function, and is working. :) > > >>>> > > >>>>Thanks. > > >>>>-Yoshi > > > =20 > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Feb 22 06:34:48 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 GAA24235 for ; Sun, 22 Feb 2004 06:34: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 1AursM-00022C-4R for mip4-archive@odin.ietf.org; Sun, 22 Feb 2004 06:34:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MBYMqN007814 for mip4-archive@odin.ietf.org; Sun, 22 Feb 2004 06:34:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AursL-00021x-VA for mip4-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 06:34: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 GAA24228 for ; Sun, 22 Feb 2004 06:34:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AursI-0003Gv-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 06:34:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AurrO-0003FA-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 06:33:23 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aurr0-0003D8-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 06:32:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aurr3-0001xM-8g; Sun, 22 Feb 2004 06: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 1AurqU-0001x5-DP for mip4@optimus.ietf.org; Sun, 22 Feb 2004 06:32: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 GAA24195 for ; Sun, 22 Feb 2004 06:32:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AurqQ-0003CR-00 for mip4@ietf.org; Sun, 22 Feb 2004 06:32:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aurpb-0003A5-00 for mip4@ietf.org; Sun, 22 Feb 2004 06:31:32 -0500 Received: from [203.177.23.162] (helo=eazix-win2ks0.eazix.com) by ietf-mx with esmtp (Exim 4.12) id 1AurpG-00036r-00 for mip4@ietf.org; Sun, 22 Feb 2004 06:31:10 -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: Sun, 22 Feb 2004 19:37:10 +0800 Message-ID: Thread-Topic: low latency handoff query Thread-Index: AcP5ODUw4vNRE9UJROK48+XtKOi8Tw== From: "Rodel Miguel" To: Content-Transfer-Encoding: quoted-printable Subject: [Mip4] low latency handoff query Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hello, I would like to know if the mobileIP lowlatency handoffs draft provide = support for multiple FA that could be a candidate nFA in the handoff = process? Or should this issue be addressed on L2 trigger functions? Thanks, Rodel -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Feb 22 11:28: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 LAA01265 for ; Sun, 22 Feb 2004 11:28: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 1AuwSD-0005zL-2a for mip4-archive@odin.ietf.org; Sun, 22 Feb 2004 11:27:41 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MGRfqi023019 for mip4-archive@odin.ietf.org; Sun, 22 Feb 2004 11:27:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuwSC-0005zC-UI for mip4-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 11:27: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 LAA01245 for ; Sun, 22 Feb 2004 11:27:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuwSB-0002ok-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 11:27:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuwRT-0002kn-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 11:26:56 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AuwQc-0002fH-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 11:26:03 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AuwQe-0007kc-CF for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 11:26:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuwQc-0005nn-7L; Sun, 22 Feb 2004 11:26:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuwPz-0005kL-2c for mip4@optimus.ietf.org; Sun, 22 Feb 2004 11:25: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 LAA01120 for ; Sun, 22 Feb 2004 11:25:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuwPy-0002XZ-00 for mip4@ietf.org; Sun, 22 Feb 2004 11:25:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuwMS-0002NF-00 for mip4@ietf.org; Sun, 22 Feb 2004 11:21:45 -0500 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AuwK5-0002CX-00 for mip4@ietf.org; Sun, 22 Feb 2004 11:19:17 -0500 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i1MGIB321428; Sun, 22 Feb 2004 10:18:11 -0600 (CST) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id i1MGI9l18023; Sun, 22 Feb 2004 10:18:09 -0600 (CST) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HTHULX-00010G-00; Sun, 22 Feb 2004 11:17:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <16440.54838.436321.308630@gargle.gargle.HOWL> Date: Sun, 22 Feb 2004 10:17:58 -0600 From: Pete McCann To: =?ISO-8859-1?Q?Hans_Sj=F6strand?= Cc: Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) In-Reply-To: <40376756.3040007@ipunplugged.com> References: <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> <40353DD3.4050703@ipunplugged.com> <200402200347.MAA11519@toshiba.co.jp> <4035D7CF.4010606@ipunplugged.com> <200402201450.XAA18925@toshiba.co.jp> <16438.16303.251321.866852@gargle.gargle.HOWL> <40376756.3040007@ipunplugged.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Hi, Hans, Hans Sj=F6strand writes: > Pete, >=20 > You are quite correct, but note that I wrote >=20 > > > >seamlessness. Therefore, local deregistrations (Home address=3D= CoA) are=20 > > > >sent with TTL =3D1. =20 >=20 > I have never commented on remote deregistrations. Also note =20 >=20 > > > >This is not mandated by some spec, just our assessment and impl= ementation. >=20 > I have no intention to require anything. What I wanted to explain is= > that it's not entirely a good idea to deregister against the > public(external) HA address obtained in the dynamic HA function. I guess I don't understand why not. This is a case where the HA address happens not to be on the home subnet, but it should be no different from any other remote de-registration. Are you concerned there will be no route to the external HA address from the home subnet? -Pete > /// Hasse >=20 >=20 > Pete McCann wrote: >=20 > >Also, isn't it always possible to deregister remotely, i.e., when y= ou > >are nicely shutting down a mobile node, even though you never retur= ned > >home? > > > >Requiring TTL=3D1 in deregistrations doesn't seem proper. > > > >-Pete > > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Feb 22 12:51:04 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 MAA02674 for ; Sun, 22 Feb 2004 12:51: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 1AuxkT-0004Af-9E for mip4-archive@odin.ietf.org; Sun, 22 Feb 2004 12:50:37 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1MHob8Z016027 for mip4-archive@odin.ietf.org; Sun, 22 Feb 2004 12:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuxkT-0004AQ-07 for mip4-web-archive@optimus.ietf.org; Sun, 22 Feb 2004 12:50: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 MAA02662 for ; Sun, 22 Feb 2004 12:50:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuxkR-0006qg-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 12:50:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AuxjW-0006oE-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 12:49:39 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Auxiw-0006lU-00 for mip4-web-archive@ietf.org; Sun, 22 Feb 2004 12:49:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Auxiv-00046c-56; Sun, 22 Feb 2004 12:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AuxiX-00045s-PJ for mip4@optimus.ietf.org; Sun, 22 Feb 2004 12:48: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 MAA02632 for ; Sun, 22 Feb 2004 12:48:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AuxiW-0006kk-00 for mip4@ietf.org; Sun, 22 Feb 2004 12:48:36 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Auxhb-0006iR-00 for mip4@ietf.org; Sun, 22 Feb 2004 12:47:40 -0500 Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Auxgy-0006fg-00 for mip4@ietf.org; Sun, 22 Feb 2004 12:47:00 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1MHkrqY011313 for ; Sun, 22 Feb 2004 18:46:53 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Sun, 22 Feb 2004 18:46:53 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Sun, 22 Feb 2004 18:46:53 +0100 Message-ID: <37FB7AA6F5F9814FB634A7BF4C35A6F5639A49@ESEALNT442.al.sw.ericsson.se> From: "Karim El-Malki (HF/EAB)" To: "'Rodel Miguel'" , mip4@ietf.org Subject: RE: [Mip4] low latency handoff query Date: Sun, 22 Feb 2004 18:46:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 22 Feb 2004 17:46:53.0026 (UTC) FILETIME=[DB299C20:01C3F96B] Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 If I understood your question correctly then it depends on the case you are in. If the MN is the one taking the L3 mobility decision (i.e. PRE-REG) then it depends on the L2 trigger. If it is an L2 trigger in the MN (e.g. scan for BSSID/SNR) then the MN would decide on the target AP and send a ProxyRtSol with that info. That could mean that the MN receives one or more ProxyRtAdvs for the FAs connected to that AP and has to make a choice according to the movement detection algorithm and eventual other policies. If the L2 trigger is in the oFA then the decision on the target FA to be advertised to the MN may be taken by the oFA or alternatively the set of FA targets may be advertised to the MN. In POST-REG the target is chosen by the FA based on the L2 trigger. Different methods may be used to determine the candidate target FA based on the L2 trigger info. /Karim > -----Original Message----- > From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On > Behalf Of Rodel > Miguel > Sent: den 22 februari 2004 12:37 > To: mip4@ietf.org > Subject: [Mip4] low latency handoff query > > > Hello, > > I would like to know if the mobileIP lowlatency handoffs > draft provide support for multiple FA that could be a > candidate nFA in the handoff process? Or should this issue > be addressed on L2 trigger functions? > > Thanks, > > Rodel > > -- > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > 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. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 23 02:33: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 CAA11676 for ; Mon, 23 Feb 2004 02:33: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 1AvAaP-0006Cm-Ks for mip4-archive@odin.ietf.org; Mon, 23 Feb 2004 02:33:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N7X5CN023849 for mip4-archive@odin.ietf.org; Mon, 23 Feb 2004 02:33:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvAaM-0006Ca-QL for mip4-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 02:33: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 CAA11655 for ; Mon, 23 Feb 2004 02:32:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvAaJ-0001Gp-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 02:32:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvAZK-0001CN-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 02:31:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvAYT-00019V-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 02:31:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvAYU-0005yq-Id; Mon, 23 Feb 2004 02:31:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvAXZ-0005tS-KK for mip4@optimus.ietf.org; Mon, 23 Feb 2004 02:30: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 CAA11552 for ; Mon, 23 Feb 2004 02:30:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvAXW-00010N-00 for mip4@ietf.org; Mon, 23 Feb 2004 02:30:06 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvAWa-0000tf-00 for mip4@ietf.org; Mon, 23 Feb 2004 02:29:09 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AvAW3-0000qA-00 for mip4@ietf.org; Mon, 23 Feb 2004 02:28:35 -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 1AvAVy-0001kJ-00; Mon, 23 Feb 2004 08:28:30 +0100 Date: Mon, 23 Feb 2004 08:28:17 +0100 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann Message-Id: <20040223082817.2f9c7590.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__23_Feb_2004_08_28_17_+0100_C+WCcZEAtT1Pj15S" Subject: [Mip4] Mip4 agenda items for IETF-59, Seoul Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Mon__23_Feb_2004_08_28_17_+0100_C+WCcZEAtT1Pj15S Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit The Mip4 WG will meet during IETF59 in Seoul. Included below is a preliminary draft agenda for the WG meeting. Please respond with requests for additional agenda items or other comments directly to the WG chairs, Pete (mccap@lucent.com), Henrik(henrik@levkowetz.com) and the mip4@ietf.org mailing list. - Henrik MIP4 (Mobility for IPv4 WG) Agenda ---------------------------------------- MONDAY, March 1, 2004 1930-2200 Evening Sessions CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 15 min Chairs - Minutes - Agenda bashing - WG status web page update (http://www.mip4.org/) 2. Document Status 15 min Chairs draft-ietf-mip4-aaa-key-03 Publication Requested draft-ietf-mip4-aaa-nai-02 RFC Ed Queue draft-ietf-mip4-dynamic-assignment-00 Last call held 28 Jan to 13 Feb 2004 draft-ietf-mip4-experimental-messages-00 1 issue to be resolved, then last call draft-ietf-mobileip-lowlatency-handoffs-v4-08 Publication Requested draft-ietf-mip4-rfc2006bis-01 Review needed draft-ietf-mip4-rfc3012bis-00 Readyto be sent for publication draft-ietf-mip4-rfc3344bis Issues resolved (-00 draft not yet published) draft-ietf-mobileip-vpn-problem-solution-03 Review needed draft-ietf-mip4-vpn-problem-statement-02 IESG Evaluation - Defer draft-ietf-mip4-rfc3344bis (not yet published) 4. Experimental messages issue 5 min ? draft-ietf-mip4-experimental-messages-00.txt * Discussion of one small issue unsolved before new draft version submission, to be followed by workgroup last call. 5. Dynamic assignment last call issues 15 min ? draft-ietf-mip4-dynamic-assignment-00 * Review and discussion of issues raised during workgroup last call. 6. New possible workgroup draft: 5 min Chairs draft-perkins-faerr (not yet published) * A short background summary. The question of workgroup adoption will be sent to the list when the draft has been published --Signature=_Mon__23_Feb_2004_08_28_17_+0100_C+WCcZEAtT1Pj15S Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAOauReVhrtTJkXCMRAhSNAKC2N4fjACJaHOEjhSNhbaNiIfcoQQCgid+J rkIjwPOA6/bGP8xHKZqXdgM= =AqMO -----END PGP SIGNATURE----- --Signature=_Mon__23_Feb_2004_08_28_17_+0100_C+WCcZEAtT1Pj15S-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 23 02:49: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 CAA12116 for ; Mon, 23 Feb 2004 02:49: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 1AvApq-0007F6-6I for mip4-archive@odin.ietf.org; Mon, 23 Feb 2004 02:49:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N7n1Nb027839 for mip4-archive@odin.ietf.org; Mon, 23 Feb 2004 02:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvApo-0007Ew-MF for mip4-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 02:49: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 CAA12093 for ; Mon, 23 Feb 2004 02:48:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvApk-0002BY-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 02:48:56 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvAon-000284-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 02:47:57 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvAnq-00024a-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 02:46:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvAns-00079f-Ts; Mon, 23 Feb 2004 02: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 1AvAmz-00078O-HA for mip4@optimus.ietf.org; Mon, 23 Feb 2004 02:46: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 CAA12038 for ; Mon, 23 Feb 2004 02:46:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvAmv-00021M-00 for mip4@ietf.org; Mon, 23 Feb 2004 02:46:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvAlz-0001yf-00 for mip4@ietf.org; Mon, 23 Feb 2004 02:45:04 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AvAlf-0001vq-00 for mip4@ietf.org; Mon, 23 Feb 2004 02:44:43 -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 1AvAlf-0001lP-00; Mon, 23 Feb 2004 08:44:43 +0100 Date: Mon, 23 Feb 2004 08:44:43 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20040223084443.0bacaeff.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Mip4 agenda items for IETF-59, Seoul Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 The Mip4 WG will meet during IETF59 in Seoul. Included below is a preliminary draft agenda for the WG meeting. Please respond with requests for additional agenda items or other comments directly to the WG chairs, Pete (mccap@lucent.com), Henrik(henrik@levkowetz.com) and the mip4@ietf.org mailing list. - Henrik MIP4 (Mobility for IPv4 WG) Agenda ---------------------------------------- MONDAY, March 1, 2004 1930-2200 Evening Sessions CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 15 min Chairs - Minutes - Agenda bashing - WG status web page update (http://www.mip4.org/) 2. Document Status 15 min Chairs draft-ietf-mip4-aaa-key-03 Publication Requested draft-ietf-mip4-aaa-nai-02 RFC Ed Queue draft-ietf-mip4-dynamic-assignment-00 Last call held 28 Jan to 13 Feb 2004 draft-ietf-mip4-experimental-messages-00 1 issue to be resolved, then last call draft-ietf-mobileip-lowlatency-handoffs-v4-08 Publication Requested draft-ietf-mip4-rfc2006bis-01 Review needed draft-ietf-mip4-rfc3012bis-00 Readyto be sent for publication draft-ietf-mip4-rfc3344bis Issues resolved (-00 draft not yet published) draft-ietf-mobileip-vpn-problem-solution-03 Review needed draft-ietf-mip4-vpn-problem-statement-02 IESG Evaluation - Defer draft-ietf-mip4-rfc3344bis (not yet published) 4. Experimental messages issue 5 min ? draft-ietf-mip4-experimental-messages-00.txt * Discussion of one small issue unsolved before new draft version submission, to be followed by workgroup last call. 5. Dynamic assignment last call issues 15 min ? draft-ietf-mip4-dynamic-assignment-00 * Review and discussion of issues raised during workgroup last call. 6. New possible workgroup draft: 5 min Chairs draft-perkins-faerr (not yet published) * A short background summary. The question of workgroup adoption will be sent to the list when the draft has been published -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Feb 23 04:15: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 EAA14700 for ; Mon, 23 Feb 2004 04:15: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 1AvCBE-0004sS-KL for mip4-archive@odin.ietf.org; Mon, 23 Feb 2004 04:15:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1N9FCbf018726 for mip4-archive@odin.ietf.org; Mon, 23 Feb 2004 04:15:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvCBC-0004rm-Ef for mip4-web-archive@optimus.ietf.org; Mon, 23 Feb 2004 04:15: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 EAA14690 for ; Mon, 23 Feb 2004 04:15:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvCB9-0007cf-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 04:15:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvCAM-0007Yy-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 04:14:19 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AvC9k-0007UH-00 for mip4-web-archive@ietf.org; Mon, 23 Feb 2004 04:13:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvC97-0004ZJ-AN; Mon, 23 Feb 2004 04:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvC8I-0004Xj-HQ for mip4@optimus.ietf.org; Mon, 23 Feb 2004 04:12: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 EAA14548 for ; Mon, 23 Feb 2004 04:12:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvC8F-0007Nh-00 for mip4@ietf.org; Mon, 23 Feb 2004 04:12:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvC7S-0007JM-00 for mip4@ietf.org; Mon, 23 Feb 2004 04:11:19 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AvC6f-00079q-00 for mip4@ietf.org; Mon, 23 Feb 2004 04:10:29 -0500 Received: from ipunplugged.com (echo.local.ipunplugged.com [192.168.4.74]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id i1N99fjv018693; Mon, 23 Feb 2004 10:09:57 +0100 Message-ID: <4039C336.8060109@ipunplugged.com> Date: Mon, 23 Feb 2004 10:09:10 +0100 From: =?ISO-8859-1?Q?Hans_Sj=F6strand?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: sv, en-us, en, ja MIME-Version: 1.0 To: Pete McCann CC: Yoshiyuki Tsuda , mip4@ietf.org Subject: Re: [Mip4] WG Last call on draft-ietf-mip4-dynamic-assignment-00.txt (SECOND REQUEST) References: <20040218145035.38e8c877.henrik@levkowetz.com> <200402181522.AAA28994@toshiba.co.jp> <40353DD3.4050703@ipunplugged.com> <200402200347.MAA11519@toshiba.co.jp> <4035D7CF.4010606@ipunplugged.com> <200402201450.XAA18925@toshiba.co.jp> <16438.16303.251321.866852@gargle.gargle.HOWL> <40376756.3040007@ipunplugged.com> <16440.54838.436321.308630@gargle.gargle.HOWL> In-Reply-To: <16440.54838.436321.308630@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mailgw.local.ipunplugged.com id i1N99fjv018693 Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Pete, Pete McCann wrote: >Hi, Hans, > >Hans Sj=F6strand writes: > > Pete, > >=20 > > You are quite correct, but note that I wrote > >=20 > > > > >seamlessness. Therefore, local deregistrations (Home address=3D= CoA) are=20 > > > > >sent with TTL =3D1. =20 > >=20 > > I have never commented on remote deregistrations. Also note =20 > >=20 > > > > >This is not mandated by some spec, just our assessment and imple= mentation. > >=20 > > I have no intention to require anything. What I wanted to explain is > > that it's not entirely a good idea to deregister against the > > public(external) HA address obtained in the dynamic HA function. > >I guess I don't understand why not. This is a case where the HA >address happens not to be on the home subnet, but it should be no >different from any other remote de-registration. Are you concerned >there will be no route to the external HA address from the home >subnet? > =20 > As from previous e-mail, the concern I have is a security concern. The=20 scenario described was that if a MN gets an adverticement that matches=20 his home address, the MN could deregister against the public(external)=20 HA address. If thats the case he must use a TTL>1 since the route towards that=20 address may involve router hops. The HA will reply with an=20 acknowledgement to that deregistration and the mobile node will consider=20 itself deregistered. Several commercial MN implementations, then turns=20 off the IPsec client to get seamslessness. But this means that Eve, meerly by sending out a adverticement with=20 appropriate address and mask can make a MN to deregister against it's HA=20 and start communicate in clear. Therefore, I think that it's a better=20 idea to deregister with the TTL=3D1 and directly to the internal (private= )=20 HA address. But in that case, this must be known. Another possibility=20 might be to deregister against the "All Mobility Agents" multicast=20 address. I think it's a good thing to keep the local deregistrations=20 local, and having them separate from the remote deregistrations. Regarding the reachability I have lesser of a concern. Although it might=20 very well be so that the public(external) HA address isn't routable from=20 the home network in the real world, it's a specific case. But if someone=20 makes an implementation when this is one of the scenarious, then I hope=20 that they also make a implementation to deal with it. For example to=20 deregister against the local HA address. No need to discuss that further=20 since it's implemntation specific. And just to be extra clear. I have no issue with the dynamic HA draft=20 regarding this. It does what it's suppose to do. This came up as a=20 separate thread although the e-mail subject may be misleading. Regards /// Hasse -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 24 08:46: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 IAA19898 for ; Tue, 24 Feb 2004 08:46: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 1Avcsq-0006LU-Vn for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 08:46:01 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ODk0Zn024372 for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 08: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 1Avcsp-0006Ky-J7 for mip4-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 08:45: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 IAA19864 for ; Tue, 24 Feb 2004 08:45:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avcso-0006Tw-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 08:45:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avcrq-0006PI-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 08:44:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avcqu-0006KM-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 08:44:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avcqt-0006Eh-Ub; Tue, 24 Feb 2004 08:43:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avcqt-0006EW-9O for mip4@optimus.ietf.org; Tue, 24 Feb 2004 08:43: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 IAA19778 for ; Tue, 24 Feb 2004 08:43:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avcqr-0006K8-00 for mip4@ietf.org; Tue, 24 Feb 2004 08:43:58 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avcpt-0006Fi-00 for mip4@ietf.org; Tue, 24 Feb 2004 08:42:57 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1Avcow-00069F-00; Tue, 24 Feb 2004 08:41:58 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1ODfCjv008728; Tue, 24 Feb 2004 14:41:24 +0100 Date: Tue, 24 Feb 2004 14:41:11 +0100 From: Henrik Levkowetz To: mip4@ietf.org, agenda@ietf.org Cc: Pete McCann Message-Id: <20040224144111.298fd5de.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=_Tue__24_Feb_2004_14_41_11_+0100_=Fps/_3RtX_r0X/A" X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Subject: [Mip4] Mip4 agenda items for IETF-59, Seoul - updated Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Tue__24_Feb_2004_14_41_11_+0100_=Fps/_3RtX_r0X/A Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit The Mip4 WG will meet during IETF59 in Seoul. Included below is the agenda for the WG meeting. Please respond with requests for additional agenda items or other comments directly to the WG chairs, Pete (mccap@lucent.com), Henrik(henrik@levkowetz.com) and the mip4@ietf.org mailing list. The latest version of the agenda will at all times be available at http://www.mip4.org/ietf59/agenda.html http://www.mip4.org/ietf59/agenda.txt - Henrik MIP4 (Mobility for IPv4 WG) Agenda ---------------------------------------- MONDAY, March 1, 2004 1930-2200 Evening Sessions CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 15 min Chairs - Minutes - Agenda bashing - WG status web page update (http://www.mip4.org/) 2. Document Status 15 min Chairs draft-ietf-mip4-aaa-key-03 Publication Requested draft-ietf-mip4-aaa-nai-02 RFC Ed Queue draft-ietf-mip4-dynamic-assignment-00 Last call held 28 Jan to 13 Feb 2004 draft-ietf-mip4-experimental-messages-00 1 issue to be resolved, then last call draft-ietf-mobileip-lowlatency-handoffs-v4-08 Publication Requested draft-ietf-mip4-rfc2006bis-01 Review needed draft-ietf-mip4-rfc3012bis-00 Readyto be sent for publication draft-ietf-mip4-rfc3344bis Issues resolved (-00 draft not yet published) draft-ietf-mobileip-vpn-problem-solution-03 Review needed draft-ietf-mip4-vpn-problem-statement-02 IESG Evaluation - Defer draft-ietf-mip4-rfc3344bis (not yet published) 4. Experimental messages issue 5 min Alpesh Patel draft-ietf-mip4-experimental-messages-00.txt * Discussion of one small issue unsolved before new draft version submission, to be followed by workgroup last call. 5. Dynamic assignment last call issues 15 min Alpesh Patel draft-ietf-mip4-dynamic-assignment-00 * Review and discussion of issues raised during workgroup last call. 6. New possible workgroup draft: 5 min Chairs draft-perkins-faerr (not yet published) * A short background summary. The question of workgroup adoption will be sent to the list when the draft has been published 7. MIPv4/MIPv6 IPv4/IPv6 bar-bof announcement 5 min Chairs ------ Total: 60 min --Signature=_Tue__24_Feb_2004_14_41_11_+0100_=Fps/_3RtX_r0X/A Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAO1R3eVhrtTJkXCMRAtDxAKCOghcD7paGY1ZTEdj7qux6U+N8XgCfZXTV glpGxr+YczF5+Y8CciYqpiI= =nrjs -----END PGP SIGNATURE----- --Signature=_Tue__24_Feb_2004_14_41_11_+0100_=Fps/_3RtX_r0X/A-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 24 08: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 IAA19983 for ; Tue, 24 Feb 2004 08:48: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 1Avcuk-0006Sr-W5 for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 08:47:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ODlw4Q024843 for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 08:47:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avcuk-0006Sc-SQ for mip4-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 08:47: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 IAA19966 for ; Tue, 24 Feb 2004 08:47:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avcuj-0006do-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 08:47:57 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avctm-0006ZI-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 08:46:59 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avcsq-0006UL-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 08:46:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avcsq-0006LT-VR; Tue, 24 Feb 2004 08: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 1Avcry-0006J8-Af for mip4@optimus.ietf.org; Tue, 24 Feb 2004 08:45: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 IAA19833 for ; Tue, 24 Feb 2004 08:45:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avcrx-0006QI-00 for mip4@ietf.org; Tue, 24 Feb 2004 08:45:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avcr3-0006Ls-00 for mip4@ietf.org; Tue, 24 Feb 2004 08:44:10 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1AvcqP-0006Fz-00 for mip4@ietf.org; Tue, 24 Feb 2004 08:43:30 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1ODgYjv008779 for ; Tue, 24 Feb 2004 14:42:45 +0100 Date: Tue, 24 Feb 2004 14:42:33 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20040224144233.72f6424a.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Content-Transfer-Encoding: 7bit Subject: [Mip4] Mip4 agenda items for IETF-59, Seoul - updated Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 The Mip4 WG will meet during IETF59 in Seoul. Included below is the agenda for the WG meeting. Please respond with requests for additional agenda items or other comments directly to the WG chairs, Pete (mccap@lucent.com), Henrik(henrik@levkowetz.com) and the mip4@ietf.org mailing list. The latest version of the agenda will at all times be available at http://www.mip4.org/ietf59/agenda.html http://www.mip4.org/ietf59/agenda.txt - Henrik MIP4 (Mobility for IPv4 WG) Agenda ---------------------------------------- MONDAY, March 1, 2004 1930-2200 Evening Sessions CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 15 min Chairs - Minutes - Agenda bashing - WG status web page update (http://www.mip4.org/) 2. Document Status 15 min Chairs draft-ietf-mip4-aaa-key-03 Publication Requested draft-ietf-mip4-aaa-nai-02 RFC Ed Queue draft-ietf-mip4-dynamic-assignment-00 Last call held 28 Jan to 13 Feb 2004 draft-ietf-mip4-experimental-messages-00 1 issue to be resolved, then last call draft-ietf-mobileip-lowlatency-handoffs-v4-08 Publication Requested draft-ietf-mip4-rfc2006bis-01 Review needed draft-ietf-mip4-rfc3012bis-00 Readyto be sent for publication draft-ietf-mip4-rfc3344bis Issues resolved (-00 draft not yet published) draft-ietf-mobileip-vpn-problem-solution-03 Review needed draft-ietf-mip4-vpn-problem-statement-02 IESG Evaluation - Defer draft-ietf-mip4-rfc3344bis (not yet published) 4. Experimental messages issue 5 min Alpesh Patel draft-ietf-mip4-experimental-messages-00.txt * Discussion of one small issue unsolved before new draft version submission, to be followed by workgroup last call. 5. Dynamic assignment last call issues 15 min Alpesh Patel draft-ietf-mip4-dynamic-assignment-00 * Review and discussion of issues raised during workgroup last call. 6. New possible workgroup draft: 5 min Chairs draft-perkins-faerr (not yet published) * A short background summary. The question of workgroup adoption will be sent to the list when the draft has been published 7. MIPv4/MIPv6 IPv4/IPv6 bar-bof announcement 5 min Chairs ------ Total: 60 min -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 24 14:48: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 OAA06418 for ; Tue, 24 Feb 2004 14:48: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 1AviXZ-0003CJ-Lz for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 14:48:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1OJmPk9012287 for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 14:48:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviXZ-0003C6-Ht for mip4-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 14:48: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 OAA06414 for ; Tue, 24 Feb 2004 14:48:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AviXW-0002k4-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 14:48:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AviWj-0002f3-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 14:47:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AviWD-0002Y9-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 14:47:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviWF-0002wr-EZ; Tue, 24 Feb 2004 14:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AviVd-0002tv-JV for mip4@optimus.ietf.org; Tue, 24 Feb 2004 14: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 OAA06173 for ; Tue, 24 Feb 2004 14:46:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AviVa-0002V8-00 for mip4@ietf.org; Tue, 24 Feb 2004 14:46:22 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AviUu-0002NL-00 for mip4@ietf.org; Tue, 24 Feb 2004 14:45:41 -0500 Received: from smtp-4.hut.fi ([130.233.228.94] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AviTs-0002BW-00 for mip4@ietf.org; Tue, 24 Feb 2004 14:44:36 -0500 Received: from maldini.hut.fi (maldini-m.hut.fi [130.233.228.122]) by smtp-4.hut.fi (8.12.10/8.12.10) with ESMTP id i1OJiZRU001360; Tue, 24 Feb 2004 21:44:35 +0200 Received: (from apache@localhost) by maldini.hut.fi (8.12.10/8.12.6/Submit) id i1OJiY93020339; Tue, 24 Feb 2004 21:44:34 +0200 To: mip4@ietf.org Message-ID: <1077651874.403ba9a2c18fc@webmail2.hut.fi> Date: Tue, 24 Feb 2004 21:44:34 +0200 (EET) From: sami.vaarala@iki.fi MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: HUT webmail, IMP 2.2.6 X-Authenticated-Sender: svaarala@cc.hut.fi X-Originating-IP: 82.133.140.89 X-RAVMilter-Version: 8.4.3(snapshot 20030212) (smtp-4.hut.fi) Content-Transfer-Encoding: 8bit Subject: [Mip4] Negotiating maximum packet size (draft-vaarala-mip4-fragmtu-00) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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.7 required=5.0 tests=AWL,NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Hi, Here's a short draft on how the MN and the HA can negotiate the maximum packet size used for IP-IP or IP-over-UDP encapsulation. http://www.ietf.org/internet-drafts/draft-vaarala-mip4-fragmtu-00.txt Although RFC 3519 already specifies that you first fragment and then encapsulate, the maximum size of encapsulated UDP packets is implementation specific (most likely link MTU). We've run into some configurations where a box is configured to drop packets larger than a certain size even when DF is unset. Limiting packet size helped, but cannot be controlled using a policy in the HA (for instance). The intent of the mechanism in the draft is to make this possible. Has anyone else run into similar issues in practice? Any feedback is appreciated. Best, -Sami -- Sami Vaarala http://www.hut.fi/~svaarala -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 24 18:14: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 SAA16286 for ; Tue, 24 Feb 2004 18:14: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 1Avlkr-0005qW-M5 for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 18:14:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1ONELkD022468 for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 18:14:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avlkr-0005qJ-6v for mip4-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 18:14: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 SAA16239 for ; Tue, 24 Feb 2004 18:14:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avlko-0005XL-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 18:14:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avljs-0005TY-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 18:13:21 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avlja-0005PU-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 18:13:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvljY-0005Vt-Nf; Tue, 24 Feb 2004 18: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 1Avliu-0005NA-If for mip4@optimus.ietf.org; Tue, 24 Feb 2004 18:12: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 SAA16061 for ; Tue, 24 Feb 2004 18:12:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avlir-0005OY-00 for mip4@ietf.org; Tue, 24 Feb 2004 18:12:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avlhv-0005KH-00 for mip4@ietf.org; Tue, 24 Feb 2004 18:11:20 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AvlhD-0005G6-00 for mip4@ietf.org; Tue, 24 Feb 2004 18:10:35 -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 1AvlhC-0000IH-00; Wed, 25 Feb 2004 00:10:34 +0100 Date: Wed, 25 Feb 2004 00:10:32 +0100 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann Message-Id: <20040225001032.77659c3b.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Mip4 agenda for IETF-59, Seoul - take three Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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, We've received a request from Sami Vaarala to allocate two spots for presentation of two new drafts: http://www.ietf.org/internet-drafts/draft-vaarala-mip4-optudp-00.txt http://www.ietf.org/internet-drafts/draft-vaarala-mip4-fragmtu-00.txt We've updated the agenda accordingly. Included below is the latest version. Please respond with requests for additional agenda items or other comments directly to the WG chairs, Pete (mccap@lucent.com), Henrik(henrik@levkowetz.com) and the mip4@ietf.org mailing list. The latest version of the agenda will at all times be available at http://www.mip4.org/ietf59/agenda.html http://www.mip4.org/ietf59/agenda.txt - Henrik MIP4 (Mobility for IPv4 WG) Agenda ---------------------------------------- MONDAY, March 1, 2004 1930-2200 Evening Sessions CHAIRS: Henrik Levkowetz Pete McCann Agenda: 1. Preliminaries 15 min Chairs - Minutes - Agenda bashing - WG status web page update ( http://www.mip4.org/ ) 2. Document Status 15 min Chairs draft-ietf-mip4-aaa-key-03 Publication Requested draft-ietf-mip4-aaa-nai-02 RFC Ed Queue draft-ietf-mip4-dynamic-assignment-00 Last call held 28 Jan to 13 Feb 2004 draft-ietf-mip4-experimental-messages-00 1 issue to be resolved, then last call draft-ietf-mobileip-lowlatency-handoffs-v4-08 Publication Requested draft-ietf-mip4-rfc2006bis-01 Review needed draft-ietf-mip4-rfc3012bis-00 Readyto be sent for publication draft-ietf-mip4-rfc3344bis Issues resolved (-00 draft not yet published) draft-ietf-mobileip-vpn-problem-solution-03 Review needed draft-ietf-mip4-vpn-problem-statement-02 IESG Evaluation - Defer draft-ietf-mip4-rfc3344bis (not yet published) 4. Experimental messages issue 5 min Alpesh Patel draft-ietf-mip4-experimental-messages-00.txt * Discussion of one small issue unsolved before new draft version submission. Ready for WG last call? 5. Dynamic assignment last call issues 15 min Alpesh Patel draft-ietf-mip4-dynamic-assignment-00 * Review and discussion of issues raised during workgroup last call. 6. New possible workgroup draft: 5 min (standin for draft-vaarala-mip4-udpopt-00 Sami Vaarala) * This draft addresses MIP overhead issues and may be beneficial for MIP/VPN and VoIP. Accept as WG item? 7. New possible workgroup draft: 5 min (standin for draft-vaarala-mip4-fragmtu Sami Vaarala) * This draft proposes a fix for a practical "black hole" issue related to IP-IP or IP-over-UDP encapsulation and misconfigured or broken routers which drop packages above a certain size. Accept as WG item? 8. New possible workgroup draft: 5 min Chairs draft-perkins-faerr (not yet published) * A short background summary. The question of workgroup adoption will be sent to the list when the draft has been published. 7. MIPv4/MIPv6 interaction bar-bof announcement 5 min Chairs ------ Total: 70 min -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 24 20:37: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 UAA21325 for ; Tue, 24 Feb 2004 20:37: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 1AvnyR-000798-BB for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 20:36:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P1aVAh027458 for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 20:36:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvnyR-00078I-2X for mip4-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 20:36: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 UAA21312 for ; Tue, 24 Feb 2004 20:36:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvnyO-0001ZM-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 20:36:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvnxR-0001US-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 20:35:30 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avnwz-0001PK-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 20: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 1Avnwz-0006zg-UC; Tue, 24 Feb 2004 20:35:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvnwU-0006xx-Lm for mip4@optimus.ietf.org; Tue, 24 Feb 2004 20:34: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 UAA21226 for ; Tue, 24 Feb 2004 20:34:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvnwS-0001OZ-00 for mip4@ietf.org; Tue, 24 Feb 2004 20:34:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvnvY-0001JZ-00 for mip4@ietf.org; Tue, 24 Feb 2004 20:33:32 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Avnuz-0001EK-00; Tue, 24 Feb 2004 20:32:57 -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 1Avnul-0000Wt-00; Wed, 25 Feb 2004 02:32:43 +0100 Date: Wed, 25 Feb 2004 02:32:33 +0100 From: Henrik Levkowetz To: mip4@ietf.org, mip6@ietf.org Cc: Pete McCann , Pekka Savola , Jonne Soininen , Basavaraj Patil , Gopal Dommety Message-Id: <20040225023233.12c02fed.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=_Wed__25_Feb_2004_02_32_33_+0100_P_4CIJTgUJhjW3oK" Subject: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__25_Feb_2004_02_32_33_+0100_P_4CIJTgUJhjW3oK Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit 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=_Wed__25_Feb_2004_02_32_33_+0100_P_4CIJTgUJhjW3oK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAO/sxeVhrtTJkXCMRAvr4AJ4+PL5qlNO7VgOs2a/DR0vPFo89UACfSxgD sYaIOMNBOcN2NCeCFzlL/qc= =nX5b -----END PGP SIGNATURE----- --Signature=_Wed__25_Feb_2004_02_32_33_+0100_P_4CIJTgUJhjW3oK-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Feb 24 20:40: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 UAA21492 for ; Tue, 24 Feb 2004 20:40: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 1Avo2A-0007ss-Ro for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 20:40:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1P1eMwt030300 for mip4-archive@odin.ietf.org; Tue, 24 Feb 2004 20:40:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avo2A-0007sd-L6 for mip4-web-archive@optimus.ietf.org; Tue, 24 Feb 2004 20:40: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 UAA21479 for ; Tue, 24 Feb 2004 20:40:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avo28-0001rp-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 20:40:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avo1B-0001nj-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 20:39:22 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avo0q-0001jy-00 for mip4-web-archive@ietf.org; Tue, 24 Feb 2004 20:39:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avo0r-0007VT-Hc; Tue, 24 Feb 2004 20: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 1Avo0F-0007UG-JO for mip4@optimus.ietf.org; Tue, 24 Feb 2004 20: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 UAA21415 for ; Tue, 24 Feb 2004 20:38:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Avo0D-0001jE-00 for mip4@ietf.org; Tue, 24 Feb 2004 20:38:21 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AvnzL-0001ek-00 for mip4@ietf.org; Tue, 24 Feb 2004 20:37:28 -0500 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1Avnyt-0001aJ-00; Tue, 24 Feb 2004 20:36:59 -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 1Avnyr-0000XV-00; Wed, 25 Feb 2004 02:36:57 +0100 Date: Wed, 25 Feb 2004 02:36:57 +0100 From: Henrik Levkowetz To: mip4@ietf.org, mip6@ietf.org Message-Id: <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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 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 -- Henrik -- Outside of a dog a book is man's best friend. Inside of a dog it's too dark to read. -- Groucho Marx -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 25 09:06: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 JAA17008 for ; Wed, 25 Feb 2004 09:06: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 1AvzfY-00036t-P1 for mip4-archive@odin.ietf.org; Wed, 25 Feb 2004 09:05:49 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PE5mp0011955 for mip4-archive@odin.ietf.org; Wed, 25 Feb 2004 09:05:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AvzfY-00036h-IS for mip4-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:05: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 JAA16993 for ; Wed, 25 Feb 2004 09:05:46 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvzfX-0002pM-00 for mip4-web-archive@ietf.org; Wed, 25 Feb 2004 09:05:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avzec-0002jT-00 for mip4-web-archive@ietf.org; Wed, 25 Feb 2004 09:04:51 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Avzdo-0002ef-00 for mip4-web-archive@ietf.org; Wed, 25 Feb 2004 09:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Avzdo-0002yQ-Qe; Wed, 25 Feb 2004 09: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 1Avzda-0002xs-6X for mip4@optimus.ietf.org; Wed, 25 Feb 2004 09:03: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 JAA16943 for ; Wed, 25 Feb 2004 09:03:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AvzdY-0002dN-00 for mip4@ietf.org; Wed, 25 Feb 2004 09:03:44 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Avzcd-0002YY-00 for mip4@ietf.org; Wed, 25 Feb 2004 09:02:48 -0500 Received: from fw.flarion.com ([63.103.94.24] helo=ftmail2000.HQ.Flarion.com) by ietf-mx with esmtp (Exim 4.12) id 1Avzbm-0002PJ-00; Wed, 25 Feb 2004 09:01:54 -0500 content-class: urn:content-classes:message Subject: RE: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Date: Wed, 25 Feb 2004 09:01:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Thread-Topic: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Thread-Index: AcP7P6eNgyNdLZsyQZa+iK217qbrvQAYzOJg From: "Tsirtsis George" To: "Henrik Levkowetz" , , Cc: "Pete McCann" , "Pekka Savola" , "Jonne Soininen" , "Basavaraj Patil" , "Gopal Dommety" Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Henrik, I am not entirely sure what some of the combinations implied below = mean... like "IPv4 only node with MIPv6 and v6HA". Such combinations do not work = and *do not need* to work. So, I either misunderstood your e-mail or the = scope of the discussion is smaller than you imply. If you are an IPv4 ONLY mobile then you have to use MIPv4 and a v4HA = ...no choice really. If you are an IPv6 ONLY mobile then you have to use MIPv6 and a v6HA = ...no choice really. The question is what you use if you are Dual-Stack. The IESG asked us a while ago to write a problem statement on this, = which we did (recently resubmitted), see http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-02.txt. = I would suggest people have a look at that and try to think if we have = missed something in the problem statement.=20 The BAR-BOF should as a minimum examine the problem statement and = suggest additions/changes if required. Now, if we also figure out how much = interest there is in the subject and which WG(s) is(are) going to take up any = work that is required, that would be a result! George > -----Original Message----- > From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of > Henrik Levkowetz > Sent: Wednesday, February 25, 2004 1:33 AM > To: mip4@ietf.org; mip6@ietf.org > Cc: Pete McCann; Pekka Savola; Jonne Soininen; Basavaraj Patil; Gopal > Dommety > Subject: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof >=20 >=20 >=20 > Proposal of a bar-bof > --------------------- >=20 > With the coming (we hope) of heterogenous deployment of IPv4 and IPv6 > access and transport networks, and Mobile Nodes with MIPv4=20 > 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. =20 >=20 > 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=20 > 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. >=20 > Some cases may be handled without any additional MIP work if other > transition mechanisms such as e.g. ISATAP is available, but=20 > 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. >=20 > 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. >=20 > Which solutions will be needed? Which should we work on? How much > interest does this have currently? =20 >=20 > 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. >=20 > Henrik >=20 >=20 >=20 > Table of MIP4/6-IP4/6 combinations: > = =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 >=20 > # MN's MIP Access Transpt Short=20 > description > IP-stack Client Net & HA if.=09 > --- -------- ------ ------ -------=09 > ----------------- > 1 IPv4 MIP v4 IP v4 v4 "native MIPv4"=09 > 2 IPv6 " " v4 "IPv6 in MIPv4"=09 >=20 > 3 IPv4 MIP v6 " v4 "IPv4=20 > in MIPv6 over IPv4" > 4 IPv6 " " v4 "MIPv6=20 > over IPv4" >=20 > 5 IPv4 MIP v4 IP v6 v6 "MIPv4=20 > over IPv6" > 6 IPv6 " " v6 "IPv6=20 > in MIPv4 over IPv6" >=20 > 7 IPv4 MIP v6 " v6 "IPv4 in MIPv6" > 8 IPv6 " " v6 "native MIPv6" > --- -------- ------ ------ -------=09 > ----------------- >=20 > Variant 1 is the native IP/MIP combination for v4 >=20 > Variant 2 would be supported by the MIPv4 signalling=20 > extensions proposed in > draft-tsirtsis-v4v6-mipv4-00.txt >=20 > Variant 5 is known to be supported by an experimental=20 > thesis implementation > and is fairly simple >=20 > Variant 6 is known to be supported by an experimental=20 > thesis implementation > and is fairly simple >=20 > Variant 7 would be supported by the MIPv6 signalling=20 > extensions proposed in > draft-soliman-v4v6-mipv4-00.txt >=20 > Variant 8 is the native IP/MIP combination for v6 >=20 >=20 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Feb 25 09:40:18 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 JAA18438 for ; Wed, 25 Feb 2004 09:40:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0CV-0006lN-1x for mip4-archive@odin.ietf.org; Wed, 25 Feb 2004 09:39:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1PEdpYk025996 for mip4-archive@odin.ietf.org; Wed, 25 Feb 2004 09:39:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0CU-0006lD-GH for mip4-web-archive@optimus.ietf.org; Wed, 25 Feb 2004 09:39: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 JAA18389 for ; Wed, 25 Feb 2004 09:39:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0CS-0006VG-00 for mip4-web-archive@ietf.org; Wed, 25 Feb 2004 09:39:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw0BX-0006PG-00 for mip4-web-archive@ietf.org; Wed, 25 Feb 2004 09:38:52 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0Aj-0006KV-00 for mip4-web-archive@ietf.org; Wed, 25 Feb 2004 09:38:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0Ak-0006NM-CU; Wed, 25 Feb 2004 09:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Aw0Ab-0006M1-Or for mip4@optimus.ietf.org; Wed, 25 Feb 2004 09:37: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 JAA18351 for ; Wed, 25 Feb 2004 09:37:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Aw0AZ-0006JH-00 for mip4@ietf.org; Wed, 25 Feb 2004 09:37:51 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Aw09i-0006DJ-00 for mip4@ietf.org; Wed, 25 Feb 2004 09:36:59 -0500 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1Aw092-00061l-00; Wed, 25 Feb 2004 09:36:17 -0500 Received: from zinfandel.local.ipunplugged.com (chardonnay.local.ipunplugged.com [192.168.4.44]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with SMTP id i1PEZTjv029729; Wed, 25 Feb 2004 15:35:29 +0100 Date: Wed, 25 Feb 2004 15:35:29 +0100 From: Henrik Levkowetz To: "Tsirtsis George" Cc: , , "Pete McCann" , "Pekka Savola" , "Jonne Soininen" , "Basavaraj Patil" , "Gopal Dommety" Subject: Re: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Message-Id: <20040225153529.7c8fd8d3.henrik@levkowetz.com> In-Reply-To: References: 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=_Wed__25_Feb_2004_15_35_29_+0100_TNzf0iVIo7lbmIBr" X-Virus-Scanned: ClamAV version 'clamd / ClamAV version 0.66', clamav-milter version '0.66m' Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 --Signature=_Wed__25_Feb_2004_15_35_29_+0100_TNzf0iVIo7lbmIBr Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi George, On Wednesday, 25 Feb 2004, Tsirtsis George wrote: > Henrik, > > I am not entirely sure what some of the combinations implied below > mean... like "IPv4 only node with MIPv6 and v6HA". Such combinations > do not work and*do not need* to work. So, I either misunderstood your > e-mail or the scope of the discussion is smaller than you imply. You've misunderstood a bit. There's no implied "... only node" for the first column in the table. Turn it around, and suppose you have an application in your dual-stack MN which will only talk IPv4, and what you have is a MIP6 client and HA. That's the "IPv4 with MIPv6 and v6HA" case. Sorry if the table was insufficiently clear. [snip] > The IESG asked us a while ago to write a problem statement on this, > which we did (recently resubmitted), see > http://www.ietf.org/internet-drafts/draft-tsirtsis-dsmip-problem-02.txt. > I would suggest people have a look at that and try to think if we have > missed something in the problem statement. Yes, I saw that just recently but haven't had time to read it. Was it announced on the mip4 list? I didn't notice it there... (I also flag all drafts with -mip-, -mobileip-, -mip4-, -mip6- in the name for reading, but this draft fell through there too... ,:) Should be able to read it during the next couple of days. > The BAR-BOF should as a minimum examine the problem statement and > suggest additions/changes if required. Now, if we also figure out how > much interest there is in the subject and which WG(s) is(are) going to > take up any work that is required, that would be a result! Yes. The minimum result I would expect is that we mutually understand the problem area and what needs different people have better after the bar-bof. Henrik > > > -----Original Message----- > > From: mip4-admin@ietf.org [mailto:mip4-admin@ietf.org]On Behalf Of > > Henrik Levkowetz > > Sent: Wednesday, February 25, 2004 1:33 AM > > To: mip4@ietf.org; mip6@ietf.org > > Cc: Pete McCann; Pekka Savola; Jonne Soininen; Basavaraj Patil; > > Gopal Dommety > > Subject: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof > > > > > > > > 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=_Wed__25_Feb_2004_15_35_29_+0100_TNzf0iVIo7lbmIBr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAPLKxeVhrtTJkXCMRAmiTAJ0UG8IRs8fHCiQVsEyjBRptdKkVLQCgiKkp 4u/nithfA0FHo8QHl2uD+TY= =KHi9 -----END PGP SIGNATURE----- --Signature=_Wed__25_Feb_2004_15_35_29_+0100_TNzf0iVIo7lbmIBr-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Feb 29 07:13: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 HAA18354 for ; Sun, 29 Feb 2004 07:13:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPoy-0003uq-KF for mip4-archive@odin.ietf.org; Sun, 29 Feb 2004 07:13:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1TCDOKo015048 for mip4-archive@odin.ietf.org; Sun, 29 Feb 2004 07:13:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPoy-0003ud-G4 for mip4-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 07:13: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 HAA18160 for ; Sun, 29 Feb 2004 07:13:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxPoy-0002B3-00 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 07:13:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxPmV-0001Zf-00 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 07:10:52 -0500 Received: from [65.246.255.50] (helo=mx2.foretec.com) by ietf-mx with esmtp (Exim 4.12) id 1AxPki-0001Jl-02 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 07:09:00 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by mx2.foretec.com with esmtp (Exim 4.24) id 1AxPdw-0001aB-K4 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 07:02:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPdw-0001mS-Kx; Sun, 29 Feb 2004 07:02:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxPdm-0001m9-3n for mip4@optimus.ietf.org; Sun, 29 Feb 2004 07:01: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 HAA17944 for ; Sun, 29 Feb 2004 07:01:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxPdh-0000m3-00 for mip4@ietf.org; Sun, 29 Feb 2004 07:01:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxPcl-0000iS-00 for mip4@ietf.org; Sun, 29 Feb 2004 07:00:48 -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 1AxPcJ-0000em-00 for mip4@ietf.org; Sun, 29 Feb 2004 07:00:19 -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 1AxPcE-0002vK-00 for ; Sun, 29 Feb 2004 13:00:14 +0100 Date: Sun, 29 Feb 2004 13:00:13 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20040229130013.17e42986.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.6claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Review of draft-ietf-mip4-dynamic-assignment-00.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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, In parallel with the last call period, I made a review of draft-ietf-mip4-dynamic-assignment-00.txt . A number of the comments in the review was also made during last call. The full review is available here: and a summary is enclosed below. Henrik --------- This draft is on the right track but has open issues, described below and in the full review. Technical: * The use of ALL-ZERO-ONE-ADDR instead of a MIPv4 extension to trigger dynamic HA allocation has limitations - it does not permit the use of flags or additional information to distinguish different cases of dynamic HA allocation. Suggest using an extension in addition to ALL-ZERO-ONE-ADDR. * The format of the extension carrying the address of the redirected HA does not follow the format recommended in RFC 3344; it would be advantageous to define it so as to support subtypes; and it would be better if the HA address was aligned on a 4-octet boundary. * As currently written, the mechanism seems to be broken at this point: In the case of registering through an FA and being re-directed to a second HA, it seems the FA has no way to know that the second registration should be sent to the second HA, while still signalling to the second HA that dynamic HA assignment is active. This could be resolved by using an extension in addition to the ALL-ZERO-ONE-ADDR. * There is insufficiently clear motivation for permitting the case where HA reassingment is to be done althogh a HA unicast address is given in the RRQ, rather than the ALL-ZERO-ONE-ADDR address. The unicast address case makes me uncomfortable, and I'd rather see it go. Eliminating the unicast address case may be made easier by using an extension in addition to the ALL-ZERO-ONE-ADDR. * The circumstances when an FA may send a registration request to an HA different from the one explicitly indicated needs to be strongly limited and clearly described (if not outright eliminated.) Editorial: * The organisation of the subject matter could be improved somewhat. Possibly a schema similar to the following could be good: I. Intro & terminology II. Problem statement III. Protocol overview IV. Extension format V. Protocol details VI. Security considerations, IANA etc. * One more detailed observation is that it might be clearer if the 4.1 section was removed or moved after the 4.2 section, as the main case is the redirection case. * The illustrations of the MIP4 registration requests in sections 4.1.1 and 4.2.1 omits some fields, without making that clear; they could do with some re-work. There's a suggestion in the full review. * There are numerous minor language fixes needed; in the first half of the review such has been marked explicitly. * There are a number of too long lines and non-ascii characters in the draft. These are listed at the end of the review, under [idnits-output]. There are also many instances of weird spacing in the document, has it been typeset with justification rather than ragged-right? * You should upgrade the boilerplate to match RFC 3667 instead of RFC 2026. (RFC 3667 was announced 18 Feb 2004, so this is fairly recent.) -------- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sun Feb 29 20:15: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 UAA20164 for ; Sun, 29 Feb 2004 20:15: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 1Axc1f-0005gf-CW for mip4-archive@odin.ietf.org; Sun, 29 Feb 2004 20:15:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211FJbP021861 for mip4-archive@odin.ietf.org; Sun, 29 Feb 2004 20:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc1e-0005gW-VR for mip4-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:15: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 UAA20153 for ; Sun, 29 Feb 2004 20:15:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axc1c-0006uY-00 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 20:15:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axc0u-0006q9-00 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 20:14:33 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Axc0O-0006lx-00 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 20:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axc0P-0005Ok-5e; Sun, 29 Feb 2004 20:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Axbzg-0005KV-9Z for mip4@optimus.ietf.org; Sun, 29 Feb 2004 20:13: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 UAA20104 for ; Sun, 29 Feb 2004 20:13:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Axbze-0006l3-00 for mip4@ietf.org; Sun, 29 Feb 2004 20:13:14 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Axbyx-0006h8-00 for mip4@ietf.org; Sun, 29 Feb 2004 20:12:32 -0500 Received: from mac-0-40-96-34-df-d2.dhcp.ietf59.or.kr ([218.37.230.226] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AxbyM-0006bk-00; Sun, 29 Feb 2004 20:11:54 -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 1AxbyB-0004VM-00; Mon, 01 Mar 2004 02:11:43 +0100 Date: Mon, 1 Mar 2004 02:11:42 +0100 From: Henrik Levkowetz To: Henrik Levkowetz Cc: mip4@ietf.org, mip6@ietf.org Subject: Re: [Mip4] MIPv4/MIPv6-IPv4/IPv6 interaction bar-bof Message-Id: <20040301021142.243d8a67.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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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 Bar-bof details: We have a proposed time and place for this bar-bof: Tuesday morning 7:00 - in the seating area outside Emerald. Possibly we can use Emerald if more people turn up than the area can hold. The first idea of having it Monday night at 10:00 has been scrapped as some key persons who are newly arrived from the states will be dead on their feet at that time. 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 > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From exim@www1.ietf.org Sun Feb 29 20:32: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 UAA20841 for ; Sun, 29 Feb 2004 20:32: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 1AxcHS-0007Jt-Ik for mip4-archive@odin.ietf.org; Sun, 29 Feb 2004 20:31:38 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i211VcvL028136 for mip4-archive@odin.ietf.org; Sun, 29 Feb 2004 20:31:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcHR-0007Jj-Tv for mip4-web-archive@optimus.ietf.org; Sun, 29 Feb 2004 20:31: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 UAA20827 for ; Sun, 29 Feb 2004 20:31:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcHP-0000Y5-00 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 20:31:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcGP-0000Re-00 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 20:30:34 -0500 Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AxcFs-0000Ks-00 for mip4-web-archive@ietf.org; Sun, 29 Feb 2004 20:30:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcFt-00079V-Ua; Sun, 29 Feb 2004 20:30:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AxcFE-00077W-JL for mip4@optimus.ietf.org; Sun, 29 Feb 2004 20:29: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 UAA20659 for ; Sun, 29 Feb 2004 20:29:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AxcFC-0000IT-00 for mip4@ietf.org; Sun, 29 Feb 2004 20:29:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AxcEI-0000Df-00 for mip4@ietf.org; Sun, 29 Feb 2004 20:28:22 -0500 Received: from mac-0-40-96-34-df-d2.dhcp.ietf59.or.kr ([218.37.230.226] helo=chardonnay.local.levkowetz.com) by ietf-mx with esmtp (Exim 4.12) id 1AxcE0-00008l-00 for mip4@ietf.org; Sun, 29 Feb 2004 20:28:04 -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 1AxcDt-0004XC-00; Mon, 01 Mar 2004 02:27:57 +0100 Date: Mon, 1 Mar 2004 02:27:57 +0100 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20040301022757.4ec2b192.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_02_27_57_+0100_Dzk8F2dHXkLtx5C2" Subject: [Mip4] Summary of last call comments on the dynamic HA assignment draft Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 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_02_27_57_+0100_Dzk8F2dHXkLtx5C2 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, The Workgroup last last call period for draft-ietf-mip4-dynamic-assignment-00.txt ended on February 13th. There was only one commenter which explicitly said that he supported the advancement of this draft, which is very meager. However, the comments sparked of a bit of discussion, which indicated at least some more people having interest in this draft. It's till hard to count one explicit comment as Consensus. The comments made on the draft was as follows: * The extension which carries the address of the assigned HA should not only carry the public but also possibly the private address of the HA, to make it possible (under some premises) to identify the home network. This received a fair amount of response on the list, and the originator changed his point of view. This issue does not require further resolution. * The extension which carries the address of the assigned HA should be defined to have a subtype, and conform to the format recommended in RFC 3344, section 1.9 . It is also good to align the HA address on a 4-octet boundary. * Should an FA be permitted to forward a registration request to a _different_ unicast address than the one specified by the MN in the request? It was suggested that this not be done, or strict conditions specified on when it may be done. * It was suggested that using the HA ALL-ZERO-ONE-ADDR as a sole indicator of dynamic HA assignment is maybe too blunt; the use of an extension to indicate this capability, and possibly additional flags, was mentioned. In view of the low level of explicitly expressed support and the presence of unresolved last call issues as well as some issues raised in the wg chair review, we will do another iteration on the document in the workgroup and then hold a new workgroup last call. As the authors have indicated that they already have proposed solutions to the issues raised, this should hopefully be a fast cycle. Henrik --Signature=_Mon__1_Mar_2004_02_27_57_+0100_Dzk8F2dHXkLtx5C2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAQpGdeVhrtTJkXCMRAnx8AKDsWiu/YWl4GzMO0f+JUB8vzLHd/QCeLQQ8 8COwAFatBuqB0U8pdXsvFtE= =IZQD -----END PGP SIGNATURE----- --Signature=_Mon__1_Mar_2004_02_27_57_+0100_Dzk8F2dHXkLtx5C2-- -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/