RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS

From exim@www1.ietf.org Wed Oct 1 14:40:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27021 for ; Wed, 1 Oct 2003 14:40:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ltS-0003E8-Qs for mip4-archive@odin.ietf.org; Wed, 01 Oct 2003 14:40:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h91IeA6a012401 for mip4-archive@odin.ietf.org; Wed, 1 Oct 2003 14:40:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ltS-0003Dw-LQ for mip4-web-archive@optimus.ietf.org; Wed, 01 Oct 2003 14:40:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26981 for ; Wed, 1 Oct 2003 14:40:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4ltP-0003FL-00 for mip4-web-archive@ietf.org; Wed, 01 Oct 2003 14:40:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4ltP-0003FI-00 for mip4-web-archive@ietf.org; Wed, 01 Oct 2003 14:40:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4ltL-0003DQ-4r; Wed, 01 Oct 2003 14:40:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4lso-0003Cl-QX for mip4@optimus.ietf.org; Wed, 01 Oct 2003 14:39:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26970 for ; Wed, 1 Oct 2003 14:39:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4lsm-0003F3-00 for mip4@ietf.org; Wed, 01 Oct 2003 14:39:28 -0400 Received: from h53s130a234n47.user.nortelnetworks.com ([47.234.130.53] helo=zrc2s0jx.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A4lsl-0003EW-00 for mip4@ietf.org; Wed, 01 Oct 2003 14:39:27 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h91IcYR07777 for ; Wed, 1 Oct 2003 13:38:34 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Oct 2003 13:38:35 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746BDE@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 1 Oct 2003 13:38:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Mip4] RFC3012bis - Issue2-Change1 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: , Hello all, Currently, we have a proposal to add new guideline on when to omit a Mobile-Foreign Challenge Extension in a Registration Reply. Please let me know if you have any opinion/suggestion. It will be good if we can finalize this in couple of weeks. Regards, Jayshree (Change 1) Section 3.3 From: The Foreign Agent SHOULD include a new Mobile-Foreign Challenge Extension in any Registration Reply, successful or not. If the foreign agent includes this extension in a successful Registration Reply, the extension SHOULD precede a Mobile-Foreign authentication extension. Suppose the Registration Reply includes a Challenge extension from the Home Agent, and the foreign agent wishes to include another Challenge extension with the Registration Reply for use by the mobile node. In that case, the foreign agent MUST delete the Challenge extension from the Home Agent from the Registration Reply, along with any Foreign-Home authentication extension, before appending the new Challenge extension to the Registration Reply. To: The Foreign Agent SHOULD include a previously unused challenge Mobile-Foreign Challenge Extension in any Registration Reply, successful or not. If the foreign agent includes this extension in a successful Registration Reply, the extension SHOULD precede a Mobile-Foreign authentication extension. Suppose the Registration Reply includes a Challenge extension from the Home Agent, and the foreign agent wishes to include another Challenge extension with the Registration Reply for use by the mobile node. In that case, the foreign agent MUST delete the Challenge extension from the Home Agent from the Registration Reply, along with any Foreign-Home authentication extension, before appending the new Challenge extension to the Registration Reply. One example of a situation where the Foreign Agent MAY omit the inclusion of a Mobile-Foreign Challenge Extension in the Registration Reply would be when a new challenge has been multicast recently. If a foreign agent has conditions in which it omits the inclusion of a Mobile-Foreign Challenge Extension in the Registration Reply, it still MUST respond with an agent advertisement containing a previously unused challenge in response to a subsequent agent solicitation from the same mobile node. Otherwise (when the said conditions are not met) the foreign agent MUST include a previously unused challenge in any Registration Reply, successful or not. A mobile node MUST be prepared to use a challenge from a unicast or multicast Agent Advertisement in lieu of one returned in a Registration Reply, and MUST solicit for one if it has not already received one in a Registration Reply. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Oct 2 10:51:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23312 for ; Thu, 2 Oct 2003 10:51:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54nK-0003hN-4B for mip4-archive@odin.ietf.org; Thu, 02 Oct 2003 10:51:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92Ep68D014213 for mip4-archive@odin.ietf.org; Thu, 2 Oct 2003 10:51:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54nJ-0003hA-Td for mip4-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 10:51:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23262 for ; Thu, 2 Oct 2003 10:50:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A54nH-0001VA-00 for mip4-web-archive@ietf.org; Thu, 02 Oct 2003 10:51:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A54nH-0001V6-00 for mip4-web-archive@ietf.org; Thu, 02 Oct 2003 10:51:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54nG-0003gK-K5; Thu, 02 Oct 2003 10:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A54n9-0003f0-1o for mip4@optimus.ietf.org; Thu, 02 Oct 2003 10:50:55 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23212; Thu, 2 Oct 2003 10:50:43 -0400 (EDT) Message-Id: <200310021450.KAA23212@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, 02 Oct 2003 10:50:43 -0400 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-rfc2006bis-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: , --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 : The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised Author(s) : R. Rathi, K. Leung Filename : draft-ietf-mip4-rfc2006bis-01.txt Pages : 86 Date : 2003-10-2 This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. This memo is intended to update and possibly obsolete RFC 2006, however, it is designed to be backward compatible. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-rfc2006bis-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-rfc2006bis-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-rfc2006bis-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: <2003-10-2105923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-rfc2006bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-rfc2006bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-2105923.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Oct 2 14:22:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18311 for ; Thu, 2 Oct 2003 14:22:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A585W-0001Uo-Hd for mip4-archive@odin.ietf.org; Thu, 02 Oct 2003 14:22:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h92IM6g0005743 for mip4-archive@odin.ietf.org; Thu, 2 Oct 2003 14:22:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A585W-0001UY-9E for mip4-web-archive@optimus.ietf.org; Thu, 02 Oct 2003 14:22:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18283 for ; Thu, 2 Oct 2003 14:21:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A585T-0004oR-00 for mip4-web-archive@ietf.org; Thu, 02 Oct 2003 14:22:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A585T-0004oO-00 for mip4-web-archive@ietf.org; Thu, 02 Oct 2003 14:22:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A585Q-0001To-By; Thu, 02 Oct 2003 14:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A584s-0001OF-A8 for mip4@optimus.ietf.org; Thu, 02 Oct 2003 14:21:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18223 for ; Thu, 2 Oct 2003 14:21:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A584p-0004nd-00 for mip4@ietf.org; Thu, 02 Oct 2003 14:21:23 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A584o-0004nS-00 for mip4@ietf.org; Thu, 02 Oct 2003 14:21:23 -0400 Received: (qmail 25789 invoked from network); 2 Oct 2003 18:21:20 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 2 Oct 2003 18:21:20 -0000 Date: Thu, 2 Oct 2003 20:21:20 +0200 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann Message-Id: <20031002202120.38f84de0.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Multipart_Thu__2_Oct_2003_20_21_20_+0200_=.hkp)?PRbgN1S3G" Subject: [Mip4] Mip4 workgroup meeting in Minneapolia 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: , --Multipart_Thu__2_Oct_2003_20_21_20_+0200_=.hkp)?PRbgN1S3G Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit The mip4 WG meeting is now on the agenda: MONDAY, November 10, 2003 1300-1500 Afternoon Sessions I APP lemonade Enhancements to Internet email to support diverse service environments WG INT mip4 Mobility for IPv4 WG OPS mboned MBONE Deployment WG RTG forces Forwarding and Control Element Separation WG RTG ospf Open Shortest Path First IGP WG SEC pkix Public-Key Infrastructure (X.509) WG TSV enum Telephone Number Mapping WG Henrik --Multipart_Thu__2_Oct_2003_20_21_20_+0200_=.hkp)?PRbgN1S3G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fGygeVhrtTJkXCMRAuD3AJ43ZJVF4eQYdMBc0OL1WtAKnKiwogCfbPza fIEfx4bUpWcIcw81C7fon6w= =6FZm -----END PGP SIGNATURE----- --Multipart_Thu__2_Oct_2003_20_21_20_+0200_=.hkp)?PRbgN1S3G-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Oct 3 07:45:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01907 for ; Fri, 3 Oct 2003 07:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OMq-0001bg-8r for mip4-archive@odin.ietf.org; Fri, 03 Oct 2003 07:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Bj4Bs006156 for mip4-archive@odin.ietf.org; Fri, 3 Oct 2003 07:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OMq-0001bC-1Q for mip4-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 07:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01883 for ; Fri, 3 Oct 2003 07:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5OMp-0007Ac-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5OMo-0007AY-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OMo-0001aT-4x; Fri, 03 Oct 2003 07:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OMH-0001Zg-24 for mip4@optimus.ietf.org; Fri, 03 Oct 2003 07:44:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01875 for ; Fri, 3 Oct 2003 07:44:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5OMG-00079q-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:44:28 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A5OMF-00079M-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:44:27 -0400 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 h93BhpRU002263 for ; Fri, 3 Oct 2003 13:43:51 +0200 Date: Fri, 3 Oct 2003 13:43:50 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031003134350.41ae3771.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws28 (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__3_Oct_2003_13_43_50_+0200_b3uXipTaX1KLEyKq" X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mailgw.local.ipunplugged.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] [issue17] Enhanced Registration Request processing at the Home Agent. 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: , --Signature=_Fri__3_Oct_2003_13_43_50_+0200_b3uXipTaX1KLEyKq Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit This has been entered in the issue tracker as issue 17. owner: Ahmad Muhanna/Kuntal Chowdhury category: Technical draft: draft-ietf-mip4-rfc3344bis priority: May fix status: No discussion title: Enhanced Registration Request processing at the Home Agent. Section 3.8.3.2 Existing Text: ------------- If the Home Address field of the Registration Request is nonzero, it MUST be copied into the Home Address field of the Registration Reply message. Otherwise, if the Home Address field of the Registration Request is zero as specified in section 3.6, the home agent SHOULD arrange for the selection of a home address for the mobile node, and insert the selected address into the Home Address field of the Registration Reply message. See [6] for further relevant details in the case where mobile nodes identify themselves using an NAI instead of their IP home address. If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, the home agent MUST reject the registration with a suitable code (e.g., Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more home agents. New Text: --------- If the Home Address field of the Registration Request is nonzero, it MUST be copied into the Home Address field of the Registration Reply message. If the Home Agent cannot support the specified nonzero unicast address in the Home Address field of the Registration Request, then the Home Agent MUST reject the registration with an error code of 129. Otherwise, if the Home Address field of the Registration Request is zero as specified in section 3.6, the home agent SHOULD arrange for the selection of a home address for the mobile node, and insert the selected address into the Home Address field of the Registration Reply message. See [6] for further relevant details in the case where mobile nodes identify themselves using an NAI instead of their IP home address. If the Home Agent field in the Registration Request contains a unicast address of this home agent, then that field MUST be copied into the Home Agent field of the Registration Reply. Otherwise, the home agent MUST set the Home Agent field in the Registration Reply to its unicast address. In this latter case, if the destination IP address of the Registration Request is the unicast IP address of this Home Agent, the Home Agent MAY accept the Registration Request. If the destination IP address of the Registration Request is not the unicast IP address of this Home Agent, the home agent MUST reject the Registration Request with a suitable code(e.g., Code 136) to prevent the mobile node from possibly being simultaneously registered with two or more Home Agents. ____________________________________________________________ Mip4 issue tracker ____________________________________________________________ --Signature=_Fri__3_Oct_2003_13_43_50_+0200_b3uXipTaX1KLEyKq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/fWD3eVhrtTJkXCMRAinmAKD7ghkY/YKQwKgwg///72FGDPxqKwCdGW0l uWL+aTNhpLJfVlIUh3S3zkU= =scV0 -----END PGP SIGNATURE----- --Signature=_Fri__3_Oct_2003_13_43_50_+0200_b3uXipTaX1KLEyKq-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Oct 3 07:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01992 for ; Fri, 3 Oct 2003 07:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ONp-0001lc-5a for mip4-archive@odin.ietf.org; Fri, 03 Oct 2003 07:46:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Bk5NM006786 for mip4-archive@odin.ietf.org; Fri, 3 Oct 2003 07:46:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ONp-0001lN-0x for mip4-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 07:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01977 for ; Fri, 3 Oct 2003 07:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ONo-0007CL-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5ONn-0007CF-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ONm-0001jE-4L; Fri, 03 Oct 2003 07:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ONZ-0001gb-IF for mip4@optimus.ietf.org; Fri, 03 Oct 2003 07:45:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01950 for ; Fri, 3 Oct 2003 07:45:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ONY-0007Ba-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:45:48 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A5ONX-0007Ao-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:45:48 -0400 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 h93BjARU002389 for ; Fri, 3 Oct 2003 13:45:10 +0200 Date: Fri, 3 Oct 2003 13:45:10 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031003134510.5497e220.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mailgw.local.ipunplugged.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 7bit Subject: [Mip4] Fw: [issue20] Missing description - Fa rejection code when MN-HA auth.ext. invalid 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This has been entered in the issue tracker as issue 20. Submitted by Pete McCann category: Technical draft: draft-ietf-mip4-rfc3344bis priority: May fix status: No discussion title: Missing description - Fa rejection code when MN-HA auth.ext. invalid The current RFC doesn't describe what to do when the FA generates a rejection code in the Registration Reply for a registration request whose MN-HA authentication extension is invalid. ____________________________________________________________ Mip4 issue tracker ____________________________________________________________ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Oct 3 07:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02010 for ; Fri, 3 Oct 2003 07:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ONq-0001lv-HR for mip4-archive@odin.ietf.org; Fri, 03 Oct 2003 07:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Bk6aw006805 for mip4-archive@odin.ietf.org; Fri, 3 Oct 2003 07:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ONp-0001lM-0S for mip4-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 07:46:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01976 for ; Fri, 3 Oct 2003 07:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ONo-0007CI-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:46:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5ONn-0007CE-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:46:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ONl-0001gw-3j; Fri, 03 Oct 2003 07:46:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ON9-0001fd-Sk for mip4@optimus.ietf.org; Fri, 03 Oct 2003 07:45:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01891 for ; Fri, 3 Oct 2003 07:45:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ON9-0007Av-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:45:23 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A5ON8-0007AR-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:45:22 -0400 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 h93BidRU002312 for ; Fri, 3 Oct 2003 13:44:39 +0200 Date: Fri, 3 Oct 2003 13:44:39 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031003134439.5a752848.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mailgw.local.ipunplugged.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 7bit Subject: [Mip4] [issue19] Multiple authorization-enabling extensions should be permitted 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This has been entered in the issue tracker as issue 19. Submitted by Ahmad Muhanna/Pete McCann category: Technical draft: draft-ietf-mip4-rfc3344bis priority: Should fix status: No discussion title: Multiple authorization-enabling extensions should be permitted Section 3.5.2 says that "Exactly one authorization-enabling extension MUST be present in all Registration Requests". This disallows both the MN-FA and the MN-HA authentication extensions in the same Registration Request. Proposed Solution: Section 3.5.2 Existing Text: -------------- Exactly one authorization-enabling extension MUST be present in all Registration Requests. New Text: --------- At least one authorization-enabling extension MUST be present in all Registration Requests. section 3.6.1.3 Existing Text: -------------- This section describes the ordering of any mandatory and any optional Extensions that a mobile node appends to a Registration Request. This following ordering MUST be followed: a) The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by b) If present, any non-authentication Extensions expected to be used by the home agent (which may or may not also be useful to the foreign agent), followed by c) An authorization-enabling extension, followed by d) If present, any non-authentication Extensions used only by the foreign agent, followed by e) The Mobile-Foreign Authentication Extension, if present. Note that items (a) and (c) MUST appear in every Registration Request sent by the mobile node. Items (b), (d), and (e) are optional. However, item (e) MUST be included when the mobile node and the foreign agent share a mobility security association. New Text: (Proposed by Pete McCain/Ahmad) --------- This section describes the ordering of any mandatory and any optional Extensions that a mobile node appends to a Registration Request. This following ordering MUST be followed: a) The IP header, followed by the UDP header, followed by the fixed-length portion of the Registration Request, followed by b) If present, any non-authentication Extensions expected to be used by the home agent (which may or may not also be useful to the foreign agent), followed by c) A mobile-home authentication extension, if present, followed by d) If present, any non-authentication Extensions used only by the foreign agent, followed by e) An authorization-enabling extension other than Mobile-Home authentication, if present, followed by f) The Mobile-Foreign Authentication Extension, if present. Note that item (a) and at least one of (c) or (e) MUST appear in every Registration Request sent by the mobile node. Items (b), (d), and (f) are optional. However, item (f) MUST be included when the mobile node and the foreign agent share a mobility security association. section 3.8.2.1 Existing Text: -------------- Registration Requests with an invalid, non-zero UDP checksum MUST be silently discarded by the home agent. The authentication in the Registration Request MUST be checked. This involves the following operations: a) The home agent MUST check for the presence of an authorization-enabling extension, and perform the indicated authentication. Exactly 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 more than one 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. 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. 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. New Text: (Proposed by: Ahmad Muhanna/Pete McCain) --------- a) The home agent MUST check for the presence of at least one authorization-enabling extension, and perform at least one of the indicated authentication(s). At least one authorization-enabling extension MUST be present in the Registration Request; and the home agent MUST either check the Authenticator value in the extension or verify that the authenticator value has been checked by another agent with which it has a security association. If no authorization-enabling extension is found, or if the Authenticator is invalid, the home agent MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 131. The home agent MUST then discard the Request and SHOULD log the error as a security exception. If the home agent receives a Registration Request without a Mobile-Home Authentication extension from a Mobile Node that does not have a security association with this home agent, the home agent MAY discard the Mobile Node's Registration Request. b) The home agent MUST check that the registration Identification field is correct using the context selected by the SPI within the authorization-enabling extension that the home agent used to authenticate the Mobile Node's Registration Request. See Section 5.7 for a description of how this is performed. If incorrect, the home agent MUST reject the Request and SHOULD send a Registration Reply to the mobile node with Code 133, including an Identification field computed in accordance with the rules specified in Section 5.7. The home agent MUST do no further processing with such a Request, though it SHOULD log the error as a security exception. section 3.8.2.3 Existing Text: -------------- "If the Registration Reply does not satisfy all of the validity checks in Section 3.8.2.1,... New Text: --------- "If the Registration Request does not satisfy all of the validity checks in Section 3.8.2.1,..." ____________________________________________________________ Mip4 issue tracker ____________________________________________________________ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Oct 3 07:47:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02058 for ; Fri, 3 Oct 2003 07:47:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OOk-0001qc-9M for mip4-archive@odin.ietf.org; Fri, 03 Oct 2003 07:47:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Bl2u2007096 for mip4-archive@odin.ietf.org; Fri, 3 Oct 2003 07:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OOk-0001qN-1I for mip4-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 07:47:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02036 for ; Fri, 3 Oct 2003 07:46:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5OOj-0007D3-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:47:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5OOi-0007Cy-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:47:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OOi-0001mw-Ui; Fri, 03 Oct 2003 07:47:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5ONt-0001ly-4d for mip4@optimus.ietf.org; Fri, 03 Oct 2003 07:46:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01983 for ; Fri, 3 Oct 2003 07:46:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5ONs-0007CS-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:46:08 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A5ONr-0007BD-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:46:07 -0400 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 h93BjYRU002459 for ; Fri, 3 Oct 2003 13:45:34 +0200 Date: Fri, 3 Oct 2003 13:45:34 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031003134534.6be33406.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mailgw.local.ipunplugged.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 7bit Subject: [Mip4] [issue21] MN-AAA extension not considered in FA to HA forwarding rules 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This has been entered in the issue tracker as issue 21. Submitted by Pete McCann category: Technical draft: draft-ietf-mip4-rfc3344bis priority: Should fix status: No discussion title: MN-AAA extension not considered in FA to HA forwarding rules Section 3.7.2.2 says that "It MUST process and remove any Extensions following the Mobile-Home Authentication Extension". This doesn't hold true if MN-AAA Authentication is also present in the Registration Request along with the MN-HA Authentication extension. ____________________________________________________________ Mip4 issue tracker ____________________________________________________________ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Oct 3 07:47:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02065 for ; Fri, 3 Oct 2003 07:47:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OOk-0001qu-P5 for mip4-archive@odin.ietf.org; Fri, 03 Oct 2003 07:47:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Bl2MK007114 for mip4-archive@odin.ietf.org; Fri, 3 Oct 2003 07:47:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OOk-0001qf-JM for mip4-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 07:47:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02040 for ; Fri, 3 Oct 2003 07:46:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5OOj-0007D9-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:47:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5OOj-0007D4-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:47:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OOj-0001pC-G5; Fri, 03 Oct 2003 07:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OOT-0001mE-05 for mip4@optimus.ietf.org; Fri, 03 Oct 2003 07:46:45 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02027 for ; Fri, 3 Oct 2003 07:46:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5OOS-0007Ci-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:46:44 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A5OOR-0007CW-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:46:43 -0400 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 h93BjsRU002489 for ; Fri, 3 Oct 2003 13:45:54 +0200 Date: Fri, 3 Oct 2003 13:45:54 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031003134554.010ae66a.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mailgw.local.ipunplugged.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 7bit Subject: [Mip4] [issue22] Section 3.4 para 1 is too simplified 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This has been entered in the issue tracker as issue 22. Submitted by Pete McCann category: Editorial draft: draft-ietf-mip4-rfc3344bis priority: May fix status: No discussion title: Section 3.4 para 1 is too simplified Rewording of paragraph 1 in section 3.4 is needed since it implies that all registration requests are forwarded on to the HA, and that all replies generated there will be relayed on to the MN, which is not true. ____________________________________________________________ Mip4 issue tracker ____________________________________________________________ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Oct 3 08:34:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01908 for ; Fri, 3 Oct 2003 07:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OMq-0001bh-9E for mip4-archive@odin.ietf.org; Fri, 03 Oct 2003 07:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93Bj4Ag006168 for mip4-archive@odin.ietf.org; Fri, 3 Oct 2003 07:45:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OMq-0001bG-3g for mip4-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 07:45:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01885 for ; Fri, 3 Oct 2003 07:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5OMp-0007Af-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:45:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5OMo-0007AZ-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 07:45:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OMo-0001ae-CV; Fri, 03 Oct 2003 07:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5OMg-0001Zs-MZ for mip4@optimus.ietf.org; Fri, 03 Oct 2003 07:44:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01879 for ; Fri, 3 Oct 2003 07:44:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5OMf-0007AU-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:44:53 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A5OMf-00079m-00 for mip4@ietf.org; Fri, 03 Oct 2003 07:44:53 -0400 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 h93BiLRU002299 for ; Fri, 3 Oct 2003 13:44:21 +0200 Date: Fri, 3 Oct 2003 13:44:21 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20031003134421.0ae323b7.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws28 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on mailgw.local.ipunplugged.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 7bit Subject: [Mip4] [issue18] The FA is rejecting with Error Code 136 which is meant for the home agent 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This has been entered in the issue tracker as issue 18. Submitted by Ahmad Muhanna category: Technical draft: draft-ietf-mip4-rfc3344bis priority: Should fix status: No discussion title: The FA is rejecting with Error Code 136 which is meant for the home agent section 3.7.2: Proposed Solution: New error code (Invalid Home Agent Address) is required for FA. This should solve the issue but requires additional IANA dependency. Existing Text: -------------- If the foreign agent has configured one of its network interfaces with the IP address specified by the mobile node as its home agent address, the foreign agent MUST NOT forward the request again. If the foreign agent serves the mobile node as a home agent, the foreign agent follows the procedures specified in section 3.8.2. Otherwise, if the foreign agent does not serve the mobile node as a home agent, the foreign agent rejects the Registration Request with code 136 (unknown home agent address). New Text: (Require input from design team) -------- If the foreign agent has configured one of its network interfaces with the IP address specified by the mobile node as its home agent address, the foreign agent MUST NOT forward the request again. If the foreign agent serves the mobile node as a home agent, the foreign agent follows the procedures specified in section 3.8.2. Otherwise, if the foreign agent does not serve the mobile node as a home agent, the foreign agent rejects the Registration Request with code Invalid Home Agent Address. ____________________________________________________________ Mip4 issue tracker ____________________________________________________________ -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Oct 3 16:03:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24315 for ; Fri, 3 Oct 2003 16:03:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5W8l-0000P8-7F for mip4-archive@odin.ietf.org; Fri, 03 Oct 2003 16:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h93K33tn001548 for mip4-archive@odin.ietf.org; Fri, 3 Oct 2003 16:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5W8l-0000Ot-1G for mip4-web-archive@optimus.ietf.org; Fri, 03 Oct 2003 16:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24178 for ; Fri, 3 Oct 2003 16:02:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5W8j-0005cf-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 16:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A5W8j-0005cb-00 for mip4-web-archive@ietf.org; Fri, 03 Oct 2003 16:03:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5W8i-0000OW-Uv; Fri, 03 Oct 2003 16:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A5W8E-0000NH-QX for mip4@optimus.ietf.org; Fri, 03 Oct 2003 16:02:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24143 for ; Fri, 3 Oct 2003 16:02:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A5W8C-0005cW-00 for mip4@ietf.org; Fri, 03 Oct 2003 16:02:29 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A5W8C-0005cE-00 for mip4@ietf.org; Fri, 03 Oct 2003 16:02:28 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id h93K1Hn14854; Fri, 3 Oct 2003 15:01:18 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h93K1EQ10625; Fri, 3 Oct 2003 15:01:14 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HM769W-000140-00; Fri, 03 Oct 2003 16:01:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16253.54659.78422.601130@gargle.gargle.HOWL> Date: Fri, 3 Oct 2003 15:01:07 -0500 From: Pete McCann To: Henrik Levkowetz Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: Re: [Mip4] [issue10] Changes for RFC3012bis - Issue 1 In-Reply-To: <20031001012307.5047cc9d.henrik@levkowetz.com> References: <870397D7C140C84DB081B88396458DAF746BD7@zrc2c000.us.nortel.com> <20031001012307.5047cc9d.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One more nit, noted below... Henrik Levkowetz writes: > Small nit: > > Tuesday 30 September 2003, Jayshree wrote: > > If the agent advertisement is unicast back to the soliciting mobile node > > MUST be handled as follows: If the challenge most recently unicast to the > > soliciting mobile node has not been previously used (as defined in Section > > 1.1), in SHOULD be repeated in the newly issued unicast agent advertisement, ^^ "it" > > otherwise a new challenge MUST be generated and remembered as the most > > recent challenge issued to the mobile node. (For further discussion of this, > > see Section 12.) > > In the first line of the last paragraph, change "mobile node" to "mobile node, it" > > Othewise, this looks fine to me. > > Henrik -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 03:57:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05553 for ; Wed, 8 Oct 2003 03:57:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79Bw-0005er-Mr for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 03:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h987v4Un021748 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 03:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79Bw-0005eh-2q for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 03:57:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05532 for ; Wed, 8 Oct 2003 03:56:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A79Bt-0001sZ-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 03:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A79Bt-0001sV-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 03:57:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79Bt-0005dv-Bv; Wed, 08 Oct 2003 03:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79B7-0005X9-CK for mip4@optimus.ietf.org; Wed, 08 Oct 2003 03:56:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05481 for ; Wed, 8 Oct 2003 03:56:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A79B4-0001qq-00 for mip4@ietf.org; Wed, 08 Oct 2003 03:56:10 -0400 Received: from fep21-0.kolumbus.fi ([193.229.0.48] helo=fep21-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1A79B4-0001qi-00 for mip4@ietf.org; Wed, 08 Oct 2003 03:56:10 -0400 Received: from yin.bjorns.net ([62.248.140.69]) by fep21-app.kolumbus.fi with ESMTP id <20031008075610.NUOM29573.fep21-app.kolumbus.fi@yin.bjorns.net> for ; Wed, 8 Oct 2003 10:56:10 +0300 Received: from bjorn by yin.bjorns.net with local (Exim 3.35 #1 (Debian)) id 1A79B3-0004Nm-00 for ; Wed, 08 Oct 2003 10:56:09 +0300 Date: Wed, 8 Oct 2003 10:56:09 +0300 From: Bjorn Andersson To: mip4@ietf.org Message-ID: <20031008075609.GA16710@yin.bjorns.net> References: <200309221845.OAA29925@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200309221845.OAA29925@ietf.org> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA05482 Subject: [Mip4] draft-ietf-mip4-aaa-nai-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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Regarding draft-ietf-mip4-aaa-nai-00.txt: I would rather like to see a "Generalized NAI" spec (for both advertisements and registration messages) and then have this draft refer to that. Is there any reason not to write a generalized NAI draft, or resurrect the old one? E.g. the route optimization and hierarchy drafts use some other NAI extensions. A FA NAI extension in registraion requests also solves an authentication problem with MIP NAT traversal. I think it would be clearer if we have a document describing just the GNAI extension, instead of specifing a general extension in a document describing a solution to a specific problem. Anyway, idenpendently of where it is specified, I think it is clear that we need, or will need, NAI extensions for various purposes. It would be nice if we could nail down a generalized NAI extension number and some subtype numbers for e.g. the HA, AAAH and FA (and maybe a "Previous FA" NAI). Bj=F6rn --=20 Bj=F6rn Andersson PGP id 5AFC144B -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 04:19:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06105 for ; Wed, 8 Oct 2003 04:19:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79XC-0006oJ-MM for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 04:19:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h988J2V3026173 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 04:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79XC-0006nW-5S for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 04:19:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06098 for ; Wed, 8 Oct 2003 04:18:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A79X9-000264-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 04:18:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A79X8-000261-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 04:18:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79XA-0006lz-Ge; Wed, 08 Oct 2003 04:19:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79WE-0006kp-SX for mip4@optimus.ietf.org; Wed, 08 Oct 2003 04:18:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06075 for ; Wed, 8 Oct 2003 04:17:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A79WB-00025l-00 for mip4@ietf.org; Wed, 08 Oct 2003 04:17:59 -0400 Received: from fep21-0.kolumbus.fi ([193.229.0.48] helo=fep21-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1A79WB-00025e-00 for mip4@ietf.org; Wed, 08 Oct 2003 04:17:59 -0400 Received: from yin.bjorns.net ([62.248.140.69]) by fep21-app.kolumbus.fi with ESMTP id <20031008081800.OCOJ29573.fep21-app.kolumbus.fi@yin.bjorns.net> for ; Wed, 8 Oct 2003 11:18:00 +0300 Received: from bjorn by yin.bjorns.net with local (Exim 3.35 #1 (Debian)) id 1A79WB-0004Pl-00 for ; Wed, 08 Oct 2003 11:17:59 +0300 Date: Wed, 8 Oct 2003 11:17:59 +0300 From: Bjorn Andersson To: mip4@ietf.org Message-ID: <20031008081759.GB16710@yin.bjorns.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline Subject: [Mip4] Editorial fix to RFC3024 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: , --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA06076 Content-Transfer-Encoding: quoted-printable Hi, there is a minor typo in RFC3024 section 4.3.1, last paragraph: "Upon receipt of a Registration Reply", should be "...Request". Bj=F6rn --=20 Bj=F6rn Andersson PGP id 5AFC144B Mobile +358 40 7723074 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rfc3024.txt.patch" --- rfc3024.txt Mon Oct 8 13:50:31 2001 +++ rfc3024.txt.new Wed Oct 8 11:13:53 2003 @@ -639,7 +639,7 @@ it cannot, it MUST send back a registration denial with code 137 (requested reverse tunnel unavailable). - Upon receipt of a Registration Reply that satisfies validity checks, + Upon receipt of a Registration Request that satisfies validity checks, the home agent MUST update its mobility bindings list to indicate that this mobile node has been granted a reverse tunnel and the type of encapsulation expected. --vkogqOf2sHV7VnPd-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 04:29:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06319 for ; Wed, 8 Oct 2003 04:29:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79gu-0007BQ-2B for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 04:29:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h988T4SQ027609 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 04:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79gt-0007BE-Fw for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 04:29:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06312 for ; Wed, 8 Oct 2003 04:28:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A79gq-0002Ah-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 04:29:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A79gq-0002Ae-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 04:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79gr-0007Au-TW; Wed, 08 Oct 2003 04:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79gJ-0007Ag-MU for mip4@optimus.ietf.org; Wed, 08 Oct 2003 04:28:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06295 for ; Wed, 8 Oct 2003 04:28:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A79gG-0002AL-00 for mip4@ietf.org; Wed, 08 Oct 2003 04:28:24 -0400 Received: from fep21-0.kolumbus.fi ([193.229.0.48] helo=fep21-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1A79gG-0002AH-00 for mip4@ietf.org; Wed, 08 Oct 2003 04:28:24 -0400 Received: from yin.bjorns.net ([62.248.140.69]) by fep21-app.kolumbus.fi with ESMTP id <20031008082824.OGIZ29573.fep21-app.kolumbus.fi@yin.bjorns.net> for ; Wed, 8 Oct 2003 11:28:24 +0300 Received: from bjorn by yin.bjorns.net with local (Exim 3.35 #1 (Debian)) id 1A79gG-0004QX-00 for ; Wed, 08 Oct 2003 11:28:24 +0300 Date: Wed, 8 Oct 2003 11:28:24 +0300 From: Bjorn Andersson To: mip4@ietf.org Message-ID: <20031008082824.GC16710@yin.bjorns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA06296 Subject: [Mip4] Suggestion: authorization failure code 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable It would be nice to have an authorization failure code in registration replies, as opposed to the authentication failure code. It would be informative for the MN to know if authorization has failed rather than authentication. Or what error code should one use if authentication succeeds but authorization does not? Bj=F6rn --=20 Bj=F6rn Andersson PGP id 5AFC144B Mobile +358 40 7723074 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 04:42:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06567 for ; Wed, 8 Oct 2003 04:42:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79tU-0007pU-51 for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 04:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h988g3pu030090 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 04:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79tT-0007pD-3W for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 04:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06551 for ; Wed, 8 Oct 2003 04:41:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A79tP-0002FT-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 04:42:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A79tP-0002FQ-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 04:41:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79tR-0007oq-1g; Wed, 08 Oct 2003 04:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A79t1-0007ny-6d for mip4@optimus.ietf.org; Wed, 08 Oct 2003 04:41:35 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06534 for ; Wed, 8 Oct 2003 04:41:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A79sy-0002Ew-00 for mip4@ietf.org; Wed, 08 Oct 2003 04:41:32 -0400 Received: from fep21-0.kolumbus.fi ([193.229.0.48] helo=fep21-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 1A79sx-0002Et-00 for mip4@ietf.org; Wed, 08 Oct 2003 04:41:31 -0400 Received: from yin.bjorns.net ([62.248.140.69]) by fep21-app.kolumbus.fi with ESMTP id <20031008084132.OLDZ29573.fep21-app.kolumbus.fi@yin.bjorns.net> for ; Wed, 8 Oct 2003 11:41:32 +0300 Received: from bjorn by yin.bjorns.net with local (Exim 3.35 #1 (Debian)) id 1A79sx-0004RV-00 for ; Wed, 08 Oct 2003 11:41:31 +0300 Date: Wed, 8 Oct 2003 11:41:31 +0300 From: Bjorn Andersson To: mip4@ietf.org Subject: Re: [Mip4] Suggestion: authorization failure code Message-ID: <20031008084131.GD16710@yin.bjorns.net> References: <20031008082824.GC16710@yin.bjorns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20031008082824.GC16710@yin.bjorns.net> Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA06535 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: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable On Wed, Oct 08 2003, at 11:28:24 +0300, Bjorn Andersson wrote: > It would be nice to have an authorization failure code in registration > replies, as opposed to the authentication failure code. It would be > informative for the MN to know if authorization has failed rather than > authentication. Or what error code should one use if authentication > succeeds but authorization does not? To answer myself: Codes 65 and 129 "administratively prohibited" are probably suitable for this purpose? Bj=F6rn --=20 Bj=F6rn Andersson PGP id 5AFC144B Mobile +358 40 7723074 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 06:03:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08321 for ; Wed, 8 Oct 2003 06:03:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7B9s-0003Zm-S0 for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 06:03:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98A34d4013745 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 06:03:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7B9s-0003Zc-Mj for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 06:03:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08301 for ; Wed, 8 Oct 2003 06:02:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7B9o-0002yE-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 06:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7B9o-0002yB-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 06:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7B9p-0003Yj-2i; Wed, 08 Oct 2003 06:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7B99-0003YC-GQ for mip4@optimus.ietf.org; Wed, 08 Oct 2003 06:02:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08272 for ; Wed, 8 Oct 2003 06:02:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7B95-0002xx-00 for mip4@ietf.org; Wed, 08 Oct 2003 06:02:15 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A7B94-0002xt-00 for mip4@ietf.org; Wed, 08 Oct 2003 06:02:15 -0400 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 h98A1dfJ010981; Wed, 8 Oct 2003 12:01:39 +0200 Date: Wed, 8 Oct 2003 12:01:37 +0200 From: Henrik Levkowetz To: Bjorn Andersson Cc: mip4@ietf.org Subject: Re: [Mip4] Editorial fix to RFC3024 Message-Id: <20031008120137.7c903a34.henrik@levkowetz.com> In-Reply-To: <20031008081759.GB16710@yin.bjorns.net> References: <20031008081759.GB16710@yin.bjorns.net> X-Mailer: Sylpheed version 0.9.5claws28 (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__8_Oct_2003_12_01_37_+0200_5NyEkPZnMVvSAtz9" 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: , --Signature=_Wed__8_Oct_2003_12_01_37_+0200_5NyEkPZnMVvSAtz9 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Wednesday, 8 Oct 2003, Bjorn wrote: > Hi, there is a minor typo in RFC3024 section 4.3.1, last paragraph: > "Upon receipt of a Registration Reply", should be "...Request". Right. I've added rfc3024 as a document in the mip4 issue tracker at http://ietf.levkowetz.com/ietf/issues/tracker/mip4/ . Would you care to add this as an issue for 3024 there please? (You'll have to add yourself as a user first, but that's a rather simple procedure) Thanks, Henrik --Signature=_Wed__8_Oct_2003_12_01_37_+0200_5NyEkPZnMVvSAtz9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/g+CBeVhrtTJkXCMRAgKJAKCJIZejdtJlcoI6876DtKZIoyaYawCfQVAT JTchpoSew+6k30RoOe2xr5s= =AOkH -----END PGP SIGNATURE----- --Signature=_Wed__8_Oct_2003_12_01_37_+0200_5NyEkPZnMVvSAtz9-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 06:05:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08395 for ; Wed, 8 Oct 2003 06:05:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7BBn-0003qg-NL for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 06:05:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98A53ih014794 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 06:05:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7BBm-0003qX-Ac for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 06:05:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08382 for ; Wed, 8 Oct 2003 06:04:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7BBi-0002zu-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 06:04:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7BBi-0002zr-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 06:04:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7BBl-0003oy-Eb; Wed, 08 Oct 2003 06:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7BBW-0003mT-1a for mip4@optimus.ietf.org; Wed, 08 Oct 2003 06:04:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08379 for ; Wed, 8 Oct 2003 06:04:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7BBS-0002zn-00 for mip4@ietf.org; Wed, 08 Oct 2003 06:04:42 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A7BBR-0002zZ-00 for mip4@ietf.org; Wed, 08 Oct 2003 06:04:41 -0400 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 h98A3tfJ011025; Wed, 8 Oct 2003 12:03:55 +0200 Date: Wed, 8 Oct 2003 12:03:55 +0200 From: Henrik Levkowetz To: Bjorn Andersson Cc: mip4@ietf.org Subject: Re: [Mip4] Suggestion: authorization failure code Message-Id: <20031008120355.5709428c.henrik@levkowetz.com> In-Reply-To: <20031008084131.GD16710@yin.bjorns.net> References: <20031008082824.GC16710@yin.bjorns.net> <20031008084131.GD16710@yin.bjorns.net> X-Mailer: Sylpheed version 0.9.5claws28 (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__8_Oct_2003_12_03_55_+0200_9COv7mZRflLP_IJv" 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: , --Signature=_Wed__8_Oct_2003_12_03_55_+0200_9COv7mZRflLP_IJv Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Wednesday, 8 Oct 2003, Bjorn wrote: > > It would be nice to have an authorization failure code in registration > > replies, as opposed to the authentication failure code. It would be > > informative for the MN to know if authorization has failed rather than > > authentication. Or what error code should one use if authentication > > succeeds but authorization does not? > > To answer myself: > Codes 65 and 129 "administratively prohibited" are probably suitable for > this purpose? That agrees with my understanding. Henrik --Signature=_Wed__8_Oct_2003_12_03_55_+0200_9COv7mZRflLP_IJv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/g+ELeVhrtTJkXCMRAp04AJ9A6XEsMtKiaeOqtxfCHunHVJilDQCeLhKy 7Xu1VA2vLtBNnF24p5wg9m0= =y3aV -----END PGP SIGNATURE----- --Signature=_Wed__8_Oct_2003_12_03_55_+0200_9COv7mZRflLP_IJv-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 12:06:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25120 for ; Wed, 8 Oct 2003 12:06:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7GpB-00073A-5p for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 12:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98G65Wd027100 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 12:06:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7GpB-000731-1t for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 12:06:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25100 for ; Wed, 8 Oct 2003 12:05:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Gp9-0000KU-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 12:06:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Gp9-0000KR-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 12:06:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Gp7-00072E-WD; Wed, 08 Oct 2003 12:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7GTE-0005GK-4T for mip4@optimus.ietf.org; Wed, 08 Oct 2003 11:43:24 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23584; Wed, 8 Oct 2003 11:42:29 -0400 (EDT) Message-Id: <200310081542.LAA23584@ietf.org> From: The IESG To: IETF-Announce: ; Cc: Henrik Levkowetz , Pete McCann , mip4@ietf.org Date: Wed, 08 Oct 2003 11:42:29 -0400 Subject: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) 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: , The charter of the Mobility for IPv4 (mip4) working group in the Internet Area of the IETF has been updated. For additional information, please contact the Area Directors or the working group Chairs. Note: the only substantative change to this charter relative to the existing charter is the addition of the following item: > 7. Experimental message types and extensions for Mobile IPv4 in > accordance with draft-narten-iana-experimental-allocations-03.txt > have been proposed in > draft-patel-mobileip-experimental-messages-01.txt. The work group > will take on and complete this specification. Mobility for IPv4 (mip4) ------------------------ Current Status: Active Working Group Chair(s): Henrik Levkowetz Pete McCann Internet Area Director(s): Thomas Narten Margaret Wasserman Mailing list: mip4@ietf.org To Subscribe: mip4-request@ietf.org In Body or Subject: subscribe Archive: https://www1.ietf.org/mail-archive/working-groups/mip4/current/ DESCRIPTION: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. Mobile IPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when Mobile IPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be progressed towards DS. 2. Key exchange using AAA infrastructures for setting up security associations defined in RFC3344 will be completed. 3. The AAA WG, which is currently dealing with the Diameter Mobile IP application, requires the AAA NAI for Mobile IPv4. This work will be completed by the WG. The MIP4 WG will also work with the AAA WG to ensure that the Diameter Mobile IP application is aligned with WG requirements. 4. Home agent assignment at the time of mobile-ip registration, rather than preconfigured for the mobile node, has been proposed in draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will take on the task of completing this. The ability to switch the home agent assigned to a mobile node while registered will also be considered as part of this task. 5. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are RFC3012bis (Challenge-response mechanism), low-latency handover draft to experimental status and the completion of the MIB for the revised base Mobile IP specification (2006bis). 6. The MIP4 WG will also complete the work on Mobile IPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for Mobile IPv4 operation in the presence of IPsec VPN's. 7. Experimental message types and extensions for Mobile IPv4 in accordance with draft-narten-iana-experimental-allocations-03.txt has been proposed in draft-patel-mobileip-experimental-messages-01.txt. The work group will take on and complete this specification. Other potential work items may be identified in the future but will require an appropriate recharter. Goals and Milestones: Aug 03 AAA Keys for MIPv4 to IESG Sep 03 MIPv4 VPN interaction problem statement to IESG Sep 03 Low latency handover to experimental Oct 03 Revised MIPv4 Challenge/Response (3012bis) to IESG Oct 03 Advance RFC 2794 (NAI Extension specification) to IESG for Draft Standard Nov 03 Revised MIB for MIPv4 to IESG Dec 03 Revised MIPv4 specification to IESG for Draft Standard Jan 04 Dynamic Home Agent assignment protocol solution to IESG Jan 04 MIPv4 experimental extensions and message draft to IESG Feb 04 MIPv4 VPN Solution to IESG -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 12:24:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26015 for ; Wed, 8 Oct 2003 12:24:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H6X-0008Qe-Qd for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 12:24:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98GO1RV032401 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 12:24:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H6X-0008QW-IZ for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 12:24:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25994 for ; Wed, 8 Oct 2003 12:23:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7H6W-0000eD-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 12:24:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7H6V-0000eA-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 12:23:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H6W-0008Q6-4s; Wed, 08 Oct 2003 12:24:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H60-0008Nz-P0 for mip4@optimus.ietf.org; Wed, 08 Oct 2003 12:23:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25957 for ; Wed, 8 Oct 2003 12:23:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7H5y-0000db-00 for mip4@ietf.org; Wed, 08 Oct 2003 12:23:26 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1A7H5x-0000dI-00 for mip4@ietf.org; Wed, 08 Oct 2003 12:23:25 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98GMq412876 for ; Wed, 8 Oct 2003 11:22:52 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 11:22:53 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746C01@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 8 Oct 2003 11:22:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Mip4] [Issue] Protection against bogus Registration Requests/Agent Soli citations 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: , Hello all, This email is regarding the current status of issue 2 based on the email discussion on this mailing list. All agreed changes for this issue will soon be included in the next version of RFC3012bis. Regards, Jayshree ---------------------------- Change 1 Status: Agreed Section 3.3 From: The Foreign Agent SHOULD include a new Mobile-Foreign Challenge Extension in any Registration Reply, successful or not. If the foreign agent includes this extension in a successful Registration Reply, the extension SHOULD precede a Mobile-Foreign authentication extension. Suppose the Registration Reply includes a Challenge extension from the Home Agent, and the foreign agent wishes to include another Challenge extension with the Registration Reply for use by the mobile node. In that case, the foreign agent MUST delete the Challenge extension from the Home Agent from the Registration Reply, along with any Foreign-Home authentication extension, before appending the new Challenge extension to the Registration Reply. To: The Foreign Agent SHOULD include a previously unused challenge Mobile-Foreign challenge Extension in any Registration Reply, successful or not. If the foreign agent includes this extension in a successful Registration Reply, the extension SHOULD precede a Mobile-Foreign authentication extension. Suppose the Registration Reply includes a Challenge extension from the Home Agent, and the foreign agent wishes to include another Challenge extension with the Registration Reply for use by the mobile node. In that case, the foreign agent MUST delete the Challenge extension from the Home Agent from the Registration Reply, along with any Foreign-Home authentication extension, before appending the new Challenge extension to the Registration Reply. One example of a situation where the Foreign Agent MAY omit the inclusion of a Mobile-Foreign Challenge Extension in the Registration Reply would be when a new challenge has been multicast recently. If a foreign agent has conditions in which it omits the inclusion of a Mobile-Foreign Challenge Extension in the Registration Reply, it still MUST respond with an agent advertisement containing a previously unused challenge in response to a subsequent agent solicitation from the same mobile node. Otherwise (when the said conditions are not met) the foreign agent MUST include a previously unused challenge in any Registration Reply, successful or not. A mobile node MUST be prepared to use a challenge from a unicast or multicast Agent Advertisement in lieu of one returned in a Registration Reply, and MUST solicit for one if it has not already received one in a Registration Reply. ------------------------------------------------ Change 2 Status: Rejected (change 2.1-Section 3.2) From: If the registration message contains a Mobile-Foreign Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AUTHENTICATION (see Section 10). To: (Added last statement) If the registration message contains a Mobile-Foreign Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AUTHENTICATION (see Section 10). In this case, if the Mobile Node is currently registered, the challenge included in the Registration Reply by the Foreign Agent MUST be the same as the one received in the Registration Request. (change 2.2-Section 3.2) From: If the registration message contains a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AAA_AUTHENTICATION_SET_BY_FA. To: (Added last statement) If the registration message contains a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, if the Mobile Node is currently registered, the challenge included in the Registration Reply by the Foreign Agent MUST be the same as the one received in the Registration Request. (change 2.3-Section 3.5) From: BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if the Registration Request contains a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification. A Mobile Node that receives a BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new Challenge value in any new registration, obtained either from an Agent Advertisement, or from a Challenge extension to the Registration Reply containing the error. To: (Replaced "new Challenge" to "Challenge") BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if the Registration Request contains a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification. A Mobile Node that receives a BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a Challenge value in any new registration, obtained either from an Agent Advertisement, or from a Challenge extension to the Registration Reply containing the error. ------------------------------------------------ Change 3 Status: Rejected Section 3.3 (New text) When responding to an unregistered MN with an unsuccessful Registration Reply, the FA SHOULD include the same challenge that was last included in a multicast Agent Advertisement. When responding to a registered MN with a successful or unsuccessful Registration Reply, the FA SHOULD include the same challenge that was last included in a multicast Agent Advertisement, when that challenge is previously unused by the MN. Otherwise, the FA SHOULD include the same challenge that was previously unicast to the MN in a Registration Reply or Agent Advertisement, unless that challenge was previously used. In that case, the FA SHOULD create a new challenge and return it to the MN, storing a copy of it with the visitor list entry for that MN. ------------------------------------------------ Change 4 Status: Accepted Section 12 (New text) Note that an active attacker may try to prevent successful registrations by sending a large number of Agent Solicitations or bogus Registration Requests, each of which could cause the FA to respond with a fresh challenge, invalidating the challenge that the MN is currently trying to use. To prevent such attacks, the FA MUST NOT invalidate previously unused challenges when responding to unauthenticated Registration Requests or Agent Solicitations. In addition, the FA MUST NOT allocate new storage when responding to such messages, because this would also create the possibility of denial of service. ------------------------------------------------ Change 5 Status: Accepted (change 5.1-Section 3.2) From: The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last Registration Reply issued to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. To: The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in the last Registration Reply or unicast Agent Advertisement sent to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. (change 5.2-Appendix E) From: In the program fragment, it is presumed that the foreign agent keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the last advertised challenge used by a mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply. To: In the program fragment, it is presumed that the foreign agent keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the last advertised challenge used by a mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply or unicast Agent Advertisement. To meet the security obligations outlined in Section 12, the FA SHOULD use one of the already stored, previously unused challenges when responding to an unauthenticated Registration Request or Agent Solicitation. If none of the already stored challenges are previously unused, the FA SHOULD generate a new challenge, include it in the response, and store it in the per-MN data structure. -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 12:27:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26170 for ; Wed, 8 Oct 2003 12:27:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H9S-0000Ia-PE for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 12:27:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98GR2K1001142 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 12:27:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H9S-0000IL-GY for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 12:27:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26161 for ; Wed, 8 Oct 2003 12:26:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7H9Q-0000hg-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 12:27:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7H9Q-0000hd-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 12:27:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H9R-0000HC-GY; Wed, 08 Oct 2003 12:27:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7H8n-0000D5-CC for mip4@optimus.ietf.org; Wed, 08 Oct 2003 12:26:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26100 for ; Wed, 8 Oct 2003 12:26:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7H8l-0000gS-00 for mip4@ietf.org; Wed, 08 Oct 2003 12:26:19 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A7H8k-0000fM-00 for mip4@ietf.org; Wed, 08 Oct 2003 12:26:19 -0400 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 h98GPmfJ019566; Wed, 8 Oct 2003 18:25:48 +0200 Date: Wed, 8 Oct 2003 18:25:47 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: Re: [Mip4] RFC3012bis - Issue2-Change1 Message-Id: <20031008182547.7c409d54.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746BDE@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746BDE@zrc2c000.us.nortel.com> X-Mailer: Sylpheed version 0.9.5claws28 (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__8_Oct_2003_18_25_47_+0200_+81o3q1hPPLLqa.C" 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: , --Signature=_Wed__8_Oct_2003_18_25_47_+0200_+81o3q1hPPLLqa.C Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi Jayshree, This looks pretty good, some minor proposed changes inline: On Wednesday, 1 Oct 2003, Jayshree wrote: > To: > The Foreign Agent SHOULD include a previously unused challenge "unused challenge" ==> "unused" > Mobile-Foreign Challenge Extension in any Registration Reply, successful or > not. If the foreign agent includes this extension in a successful > Registration Reply, the extension SHOULD precede a Mobile-Foreign > authentication extension. Suppose the Registration Reply includes a > Challenge extension from the Home Agent, and the foreign agent wishes to > include another Challenge extension with the Registration Reply for use by > the mobile node. In that case, the foreign agent MUST delete the Challenge > extension from the Home Agent from the Registration Reply, along with any > Foreign-Home authentication extension, before appending the new Challenge > extension to the Registration Reply. > > One example of a situation where the Foreign Agent MAY omit the inclusion of > a Mobile-Foreign Challenge Extension in the Registration Reply would be when > a new challenge has been multicast recently. In the original text proposal on the list, this paragraph continued with: "The Foreign Agent could then assume that the mobile node with high likelihood has received and can use the multicast challenge." Unless there was some specific objection to this, I think it'd be good to keep this text, too. > If a foreign agent has conditions in which it omits the inclusion of a > Mobile-Foreign Challenge Extension in the Registration Reply, it still MUST > respond with an agent advertisement containing a previously unused challenge > in response to a subsequent agent solicitation from the same mobile node. > Otherwise (when the said conditions are not met) the foreign agent MUST > include a previously unused challenge in any Registration Reply, successful > or not. > > A mobile node MUST be prepared to use a challenge from a unicast or > multicast Agent Advertisement in lieu of one returned in a Registration > Reply, and MUST solicit for one if it has not already received one in a > Registration Reply. Right. --Signature=_Wed__8_Oct_2003_18_25_47_+0200_+81o3q1hPPLLqa.C Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/hDqLeVhrtTJkXCMRAuQtAKDqfOaTNXXrkbADZ1nLA2i44taofQCg8vzT Jr2dv83O7gplp31kK9VXIKk= =Q2Wo -----END PGP SIGNATURE----- --Signature=_Wed__8_Oct_2003_18_25_47_+0200_+81o3q1hPPLLqa.C-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 14:17:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00798 for ; Wed, 8 Oct 2003 14:17:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Iru-0007vB-N6 for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 14:17:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98IH2sT030443 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 14:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Iru-0007uw-JK for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 14:17:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00712 for ; Wed, 8 Oct 2003 14:16:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7Irs-0002Eu-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 14:17:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7Irr-0002Ep-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 14:16:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7Irs-0007uJ-UQ; Wed, 08 Oct 2003 14:17:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7IrD-0007rZ-Lp for mip4@optimus.ietf.org; Wed, 08 Oct 2003 14:16:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00622 for ; Wed, 8 Oct 2003 14:16:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7IrA-0002Da-00 for mip4@ietf.org; Wed, 08 Oct 2003 14:16:16 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1A7IrA-0002Cs-00 for mip4@ietf.org; Wed, 08 Oct 2003 14:16:16 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h98IF8427991; Wed, 8 Oct 2003 13:15:08 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Oct 2003 13:15:09 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746C04@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Henrik Levkowetz'" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis - Issue2-Change1 Date: Wed, 8 Oct 2003 13:15:09 -0500 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: , My response inline... > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, October 08, 2003 11:26 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'mip4@ietf.org' > Subject: Re: [Mip4] RFC3012bis - Issue2-Change1 > > > Hi Jayshree, > > This looks pretty good, some minor proposed changes inline: > > On Wednesday, 1 Oct 2003, Jayshree wrote: > > > To: > > The Foreign Agent SHOULD include a previously unused challenge > "unused challenge" ==> "unused" > > > Mobile-Foreign Challenge Extension in any Registration > Reply, successful or > > not. If the foreign agent includes this extension in a successful > > Registration Reply, the extension SHOULD precede a Mobile-Foreign > > authentication extension. Suppose the Registration Reply includes a > > Challenge extension from the Home Agent, and the foreign > agent wishes to > > include another Challenge extension with the Registration > Reply for use by > > the mobile node. In that case, the foreign agent MUST > delete the Challenge > > extension from the Home Agent from the Registration Reply, > along with any > > Foreign-Home authentication extension, before appending the > new Challenge > > extension to the Registration Reply. > > > > One example of a situation where the Foreign Agent MAY omit > the inclusion of > > a Mobile-Foreign Challenge Extension in the Registration > Reply would be when > > a new challenge has been multicast recently. > > In the original text proposal on the list, this paragraph > continued with: > "The Foreign Agent could then assume that the mobile node with high > likelihood has received and can use the multicast challenge." > Unless there was some specific objection to this, I think it'd be good > to keep this text, too. [JB] According to email conversation I had with Pete on the mailing list (Sept 03), we agreed that the above text doesn't provide any additional normative information and hence agreed to remove it. > > > If a foreign agent has conditions in which it omits the > inclusion of a > > Mobile-Foreign Challenge Extension in the Registration > Reply, it still MUST > > respond with an agent advertisement containing a previously > unused challenge > > in response to a subsequent agent solicitation from the > same mobile node. > > Otherwise (when the said conditions are not met) the > foreign agent MUST > > include a previously unused challenge in any Registration > Reply, successful > > or not. > > > > A mobile node MUST be prepared to use a challenge from a unicast or > > multicast Agent Advertisement in lieu of one returned in a > Registration > > Reply, and MUST solicit for one if it has not already > received one in a > > Registration Reply. > > Right. > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 14:59:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02857 for ; Wed, 8 Oct 2003 14:59:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JWd-0002E8-99 for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 14:59:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h98Ix7Jo008560 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 14:59:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JWd-0002Dz-3i for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 14:59:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02846 for ; Wed, 8 Oct 2003 14:58:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JWa-0002r5-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 14:59:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7JWZ-0002r2-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 14:59:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JWX-0002CT-R3; Wed, 08 Oct 2003 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7JW3-0002BT-8v for mip4@optimus.ietf.org; Wed, 08 Oct 2003 14:58:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02817 for ; Wed, 8 Oct 2003 14:58:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7JW0-0002qR-00 for mip4@ietf.org; Wed, 08 Oct 2003 14:58:28 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A7JVz-0002p7-00 for mip4@ietf.org; Wed, 08 Oct 2003 14:58:27 -0400 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 h98IvvfJ021722; Wed, 8 Oct 2003 20:57:57 +0200 Date: Wed, 8 Oct 2003 20:57:56 +0200 From: Henrik Levkowetz To: mip4@ietf.org Cc: Jayshree Bharatia Subject: Re: [Mip4] RFC3012bis - Issue2-Change1 Message-Id: <20031008205756.77d94e74.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746C04@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746C04@zrc2c000.us.nortel.com> X-Mailer: Sylpheed version 0.9.5claws28 (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__8_Oct_2003_20_57_56_+0200_SfxsjXgVMEbPhfEv" 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: , --Signature=_Wed__8_Oct_2003_20_57_56_+0200_SfxsjXgVMEbPhfEv Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit On Wednesday, 8 Oct 2003, Jayshree wrote in reply to my comment: > > In the original text proposal on the list, this paragraph > > continued with: > > "The Foreign Agent could then assume that the mobile node with high > > likelihood has received and can use the multicast challenge." > > Unless there was some specific objection to this, I think it'd be good > > to keep this text, too. > [JB] According to email conversation I had with Pete on the mailing list > (Sept 03), we agreed that the above text doesn't provide any additional > normative information and hence agreed to remove it. Youre right, it doesn't provede normative information; but I think it does make the section more understandable. But if you and Pete both find the text better without it, go ahead. Henrik --Signature=_Wed__8_Oct_2003_20_57_56_+0200_SfxsjXgVMEbPhfEv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/hF40eVhrtTJkXCMRAurDAKDYbm11m9v0HCpz313NcJ6MmvwBdQCgzv2A DQyBsjV2pue0LYlBcflW5/Q= =ZI+2 -----END PGP SIGNATURE----- --Signature=_Wed__8_Oct_2003_20_57_56_+0200_SfxsjXgVMEbPhfEv-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Oct 8 21:01:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17636 for ; Wed, 8 Oct 2003 21:01:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7PAs-0005c2-Tv for mip4-archive@odin.ietf.org; Wed, 08 Oct 2003 21:01:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99112St021574 for mip4-archive@odin.ietf.org; Wed, 8 Oct 2003 21:01:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7PAs-0005bt-Qb for mip4-web-archive@optimus.ietf.org; Wed, 08 Oct 2003 21:01:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17610 for ; Wed, 8 Oct 2003 21:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7PAq-0006u8-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 21:01:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7PAp-0006u5-00 for mip4-web-archive@ietf.org; Wed, 08 Oct 2003 21:00:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7PAr-0005az-1g; Wed, 08 Oct 2003 21:01:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7P9v-0005YV-IT for mip4@optimus.ietf.org; Wed, 08 Oct 2003 21:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17589 for ; Wed, 8 Oct 2003 20:59:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7P9s-0006tw-00 for mip4@ietf.org; Wed, 08 Oct 2003 21:00:00 -0400 Received: from pec.etri.re.kr ([129.254.114.50]) by ietf-mx with esmtp (Exim 4.12) id 1A7P9s-0006tX-00 for mip4@ietf.org; Wed, 08 Oct 2003 21:00:00 -0400 Received: from LocalHost (sjkoh.etri.re.kr [129.254.112.15]) by pec.etri.re.kr (8.12.9/8.12.9) with SMTP id h991E0U3026734 for ; Thu, 9 Oct 2003 10:14:00 +0900 (KST) Message-ID: <00c101c38e00$96d17740$0f70fe81@LocalHost> From: "Seok J. Koh" To: References: <200310081542.LAA23584@ietf.org> Subject: Status of Regional MIPv4 (Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4)) Date: Thu, 9 Oct 2003 09:59:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dear all, In the MIP4 WG charter, I cannot see the item "Regional Registration (draft-ietf-mobileip-reg-tunnel-07.txt)". Is it determined that the regional MIPv4 issue will not be considered as a work item ? Sorry for not following the WG discussion on that. Seok J. Koh ----- Original Message ----- From: "The IESG" To: Cc: "Henrik Levkowetz" ; "Pete McCann" ; Sent: Thursday, October 09, 2003 12:42 AM Subject: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4) > The charter of the Mobility for IPv4 (mip4) working group in the > Internet Area of the IETF has been updated. For additional information, > please contact the Area Directors or the working group Chairs. > > Note: the only substantative change to this charter relative to the > existing charter is the addition of the following item: > > > 7. Experimental message types and extensions for Mobile IPv4 in > > accordance with draft-narten-iana-experimental-allocations-03.txt > > have been proposed in > > draft-patel-mobileip-experimental-messages-01.txt. The work group > > will take on and complete this specification. > > > Mobility for IPv4 (mip4) > ------------------------ > > Current Status: Active Working Group > > Chair(s): > > Henrik Levkowetz > Pete McCann > > Internet Area Director(s): > > Thomas Narten > Margaret Wasserman > > Mailing list: mip4@ietf.org > To Subscribe: mip4-request@ietf.org > In Body or Subject: subscribe > Archive: https://www1.ietf.org/mail-archive/working-groups/mip4/current/ > > DESCRIPTION: > > IP mobility support for IPv4 nodes (hosts and routers) is specified in > RFC3344. RFC 3344 mobility allows a node to continue using its > "permanent" home address as it moves around the internet. The Mobile IP > protocols support transparency above the IP layer, including maintenance > of active TCP connections and UDP port bindings. Besides the basic > Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns > such as optimization, security, extensions, AAA support, and deployment > issues. > > Mobile IPv4 is currently being deployed on a wide basis (e.g., in > cdma2000 networks). The scope of the deployment is on a fairly large > scale and accordingly, the MIP4 WG will focus on deployment issues and > on addressing known deficiencies and shortcomings in the protocol that > have come up as a result of deployment experience. Specifically, the > working group will complete the work items to facilitate interactions > with AAA environments, interactions with enterprise environments when > Mobile IPv4 is used therein, and updating existing protocol > specifications in accordance with deployment needs and advancing those > protocols that are on the standards track. > > Work expected to be done by the MIP4 WG as proposed by this charter is > as follows: > > 1. MIPv4 has been a proposed standard for several years. It has been > adopted by other standard development organizations and has been > deployed commercially. One of the next steps for the WG is to advance > the protocol to draft standard status. As part of advancing base > Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be > progressed towards DS. > > 2. Key exchange using AAA infrastructures for setting up security > associations defined in RFC3344 will be completed. > > 3. The AAA WG, which is currently dealing with the Diameter Mobile IP > application, requires the AAA NAI for Mobile IPv4. This work will > be completed by the WG. The MIP4 WG will also work with the AAA WG > to ensure that the Diameter Mobile IP application is aligned with > WG requirements. > > 4. Home agent assignment at the time of mobile-ip registration, rather > than preconfigured for the mobile node, has been proposed in > draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will > take on the task of completing this. The ability to switch the home > agent assigned to a mobile node while registered will also be > considered as part of this task. > > 5. Work items that are pending from the previous Mobile IP WG, which will be > completed by the MIP4 WG, are RFC3012bis (Challenge-response mechanism), > low-latency handover draft to experimental status and the completion > of the MIB for the revised base Mobile IP specification (2006bis). > > 6. The MIP4 WG will also complete the work on Mobile IPv4 interactions > in VPN scenarios. This work will involve identifying the requirements > and a solution development for Mobile IPv4 operation in the presence > of IPsec VPN's. > > 7. Experimental message types and extensions for Mobile IPv4 in accordance > with draft-narten-iana-experimental-allocations-03.txt has been > proposed in draft-patel-mobileip-experimental-messages-01.txt. > The work group will take on and complete this specification. > > Other potential work items may be identified in the future but will > require an appropriate recharter. > > Goals and Milestones: > > Aug 03 AAA Keys for MIPv4 to IESG > Sep 03 MIPv4 VPN interaction problem statement to IESG > Sep 03 Low latency handover to experimental > Oct 03 Revised MIPv4 Challenge/Response (3012bis) to IESG > Oct 03 Advance RFC 2794 (NAI Extension specification) to IESG for Draft > Standard > Nov 03 Revised MIB for MIPv4 to IESG > Dec 03 Revised MIPv4 specification to IESG for Draft Standard > Jan 04 Dynamic Home Agent assignment protocol solution to IESG > Jan 04 MIPv4 experimental extensions and message draft to IESG > Feb 04 MIPv4 VPN Solution to IESG > > > > -- > 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 Oct 9 02:46:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08930 for ; Thu, 9 Oct 2003 02:46:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7UYp-00069y-0W for mip4-archive@odin.ietf.org; Thu, 09 Oct 2003 02:46:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h996k6Qo023672 for mip4-archive@odin.ietf.org; Thu, 9 Oct 2003 02:46:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7UYo-00069j-Cd for mip4-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 02:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08911 for ; Thu, 9 Oct 2003 02:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7UYk-0002U4-00 for mip4-web-archive@ietf.org; Thu, 09 Oct 2003 02:46:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7UYk-0002U1-00 for mip4-web-archive@ietf.org; Thu, 09 Oct 2003 02:46:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7UYk-00068C-EC; Thu, 09 Oct 2003 02:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7UXr-00066u-9K for mip4@optimus.ietf.org; Thu, 09 Oct 2003 02:45:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08872 for ; Thu, 9 Oct 2003 02:44:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7UXn-0002TU-00 for mip4@ietf.org; Thu, 09 Oct 2003 02:45:03 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A7UXm-0002TJ-00 for mip4@ietf.org; Thu, 09 Oct 2003 02:45:02 -0400 Received: (qmail 17173 invoked from network); 9 Oct 2003 06:44:56 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 9 Oct 2003 06:44:56 -0000 Date: Thu, 9 Oct 2003 08:44:47 +0200 From: Henrik Levkowetz To: "Seok J. Koh" Cc: Subject: Re: Status of Regional MIPv4 (Re: [Mip4] WG Action: RECHARTER: Mobility for IPv4 (mip4)) Message-Id: <20031009084447.10206e8e.henrik@levkowetz.com> In-Reply-To: <00c101c38e00$96d17740$0f70fe81@LocalHost> References: <200310081542.LAA23584@ietf.org> <00c101c38e00$96d17740$0f70fe81@LocalHost> X-Mailer: Sylpheed version 0.9.5claws (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="Multipart_Thu__9_Oct_2003_08_44_47_+0200_=.?2(Xvk)Q9TG0w=" 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: , --Multipart_Thu__9_Oct_2003_08_44_47_+0200_=.?2(Xvk)Q9TG0w= Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit Thursday 9 October 2003, Seok wrote: > In the MIP4 WG charter, I cannot see the item > "Regional Registration (draft-ietf-mobileip-reg-tunnel-07.txt)". > > Is it determined that the regional MIPv4 issue > will not be considered as a work item ? > > Sorry for not following the WG discussion on that. In the mail archives we find: http://www1.ietf.org/mail-archive/working-groups/mip4/current/msg00199.html There is also the supplementary workgroup page which says: http://www.levkowetz.com/ietf/wg/mip4/#old-drafts Henrik --Multipart_Thu__9_Oct_2003_08_44_47_+0200_=.?2(Xvk)Q9TG0w= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/hQPoeVhrtTJkXCMRAvNDAJ9BN7qReFd7Dav14EbdFX7n5he6CgCeJhOY gJcKHaCjlVBRW+n9TGtmRLI= =B/sS -----END PGP SIGNATURE----- --Multipart_Thu__9_Oct_2003_08_44_47_+0200_=.?2(Xvk)Q9TG0w=-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Oct 9 15:39:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06681 for ; Thu, 9 Oct 2003 15:39:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gcp-0002k1-Db for mip4-archive@odin.ietf.org; Thu, 09 Oct 2003 15:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h99Jd3x1010533 for mip4-archive@odin.ietf.org; Thu, 9 Oct 2003 15:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gcp-0002jo-65 for mip4-web-archive@optimus.ietf.org; Thu, 09 Oct 2003 15:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06664 for ; Thu, 9 Oct 2003 15:38:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A7gcn-0003Iy-00 for mip4-web-archive@ietf.org; Thu, 09 Oct 2003 15:39:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A7gcn-0003Iu-00 for mip4-web-archive@ietf.org; Thu, 09 Oct 2003 15:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gcn-0002jR-3h; Thu, 09 Oct 2003 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A7gcT-0002is-GP for mip4@optimus.ietf.org; Thu, 09 Oct 2003 15:38:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06648; Thu, 9 Oct 2003 15:38:29 -0400 (EDT) Message-Id: <200310091938.PAA06648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Cc: ipsec@lists.tislabs.com, multi6@ops.ietf.org, mip6@ietf.org, mip4@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 09 Oct 2003 15:38:28 -0400 Subject: [Mip4] I-D ACTION:draft-nikander-esp-beet-mode-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: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Bound End-to-End Tunnel (BEET) mode for ESP Author(s) : P. Nikander Filename : draft-nikander-esp-beet-mode-00.txt Pages : 28 Date : 2003-10-9 This document specifies a new mode, called Bound End-to-End Tunnel (BEET) mode, for IPsec ESP. The new mode augments the existing ESP tunnel and transport modes. For end-to-end tunnels, the new mode provides limited tunnel mode semantics without the regular tunnel mode overhead. The mode is intended to support new uses of ESP, including mobility and multi-address multi-homing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nikander-esp-beet-mode-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nikander-esp-beet-mode-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nikander-esp-beet-mode-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-10-9142307.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nikander-esp-beet-mode-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-nikander-esp-beet-mode-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-10-9142307.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 Oct 10 19:25:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29604 for ; Fri, 10 Oct 2003 19:25:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86d6-0004fX-Gu for mip4-archive@odin.ietf.org; Fri, 10 Oct 2003 19:25:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9ANP4wO017941 for mip4-archive@odin.ietf.org; Fri, 10 Oct 2003 19:25:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86d6-0004fI-9p for mip4-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 19:25:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29583 for ; Fri, 10 Oct 2003 19:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86d4-0004cw-00 for mip4-web-archive@ietf.org; Fri, 10 Oct 2003 19:25:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A86d3-0004cs-00 for mip4-web-archive@ietf.org; Fri, 10 Oct 2003 19:25:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86d4-0004ek-2q; Fri, 10 Oct 2003 19:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A86cH-0004av-Hb for mip4@optimus.ietf.org; Fri, 10 Oct 2003 19:24:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29572 for ; Fri, 10 Oct 2003 19:24:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A86cF-0004cZ-00 for mip4@ietf.org; Fri, 10 Oct 2003 19:24:11 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1A86cE-0004cO-00 for mip4@ietf.org; Fri, 10 Oct 2003 19:24:10 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9ANNT014843; Fri, 10 Oct 2003 18:23:29 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Oct 2003 18:23:30 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "'mip4@ietf.org'" , "Jayshree Bharatia" Subject: RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS Date: Fri, 10 Oct 2003 18:23:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38F85.836B1EE6" 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: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C38F85.836B1EE6 Content-Type: text/plain Hi, Pete, Is there any update on the security concern you mentioned in regard to this issue. " Maybe not. I'd still like a review by security folks before we do something like this. " Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Tuesday, September 16, 2003 1:00 PM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: 'mip4@ietf.org'; Bharatia, Jayshree [RICH1:2H13:EXCH] > Subject: RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS > > > > Hi, Ahmad, > > Some comments below... > > Ahmad Muhanna writes: > > [snip] > > > So, you are saying that whether or not the FA has received a > > > response to the original RRQ from the HA, it forwards the new > > > registration request to the HA, not a copy of the old > one, right? > > > > [AM] > > YES. > > > You used the words "forwards the Registration Request to the > > > Home Agent again" but you didn't specify what you mean by > > > "the Registration Request". The new one is not identical to > > > the old one, as it differs in both the Challenge and > > > Identification fields. > > > > > > > [AM] > > Let us read the following in RFC3012-bis under section > 3.2: > " If a mobile node retransmits a Registration > Request with the same > > Challenge extension, and the Foreign Agent still has a pending > > Registration Request record in effect for the mobile node, then > > the Foreign Agent forwards the Registration Request to the Home > > Agent again. > > " > > Is there any concern about that? Retransmitted RRQ always > contain a new ID > when timestamp is used. > > Good point; I guess I am ok with the wording, if this is > something we want to do. > > [snip] > > > > So we have to be careful here - we are (slightly) weakening > > > the strength of the Challenge mechanism if we allow a whole > > > range of consecutive challenges to be valid at the FA > instead > > of just one. How do we choose the proper window > size? Is it > > > possible to characterize the resulting strength/weakness of > > > the challenge mechanism? > > > > [AM] > > If that is TRUE, I believe the Timestamp replay protection > mechanism between > MN and HA suffers the same weakness. I > do not think that we are weakening > the strength of > challenge mechanism here. > I think we either use a window > of challenges or always previous challenge > +/- 1. > I do > not think defining the window is a big problem. > > Maybe not. I'd still like a review by security folks before > we do something like this. > > > > > > If, as you point out, the forward channel towards the MN is > > > > > congested, and it is impossible to guarantee timely > delivery > > > > > of the RRP, the MN may not receive the RRP before it > > > > > increments the ID field (note that only the Timestamp based > > > > > replay protection causes the ID field to increment on a > > > > > retransmission) and retransmits the request. > > > > > However, I fail to see how your changes fix this > problem. It > > > > > seems like even if we had a way to indicate the > presence of a > > > > > retransmission to the FA, the circumstances that > you outline > > > > > could still take place. In fact, RRPs may be > dropped entirely > > > > > on the reverse link due to congestion, not just > arrive late. > > > > > It is true that the challenge response mechanism > introduces a > > > > > new failure case (STALE_CHALLENGE), but this seems > > > incidental to me. > > > > > [AM] > > > > You are highlighting two issues here. > > > > 1. The channel is totally blocked (???) and all RRPs will > > > be dropped in the > way to the MN. This scenario no one has > > > a solution for and we should not > worry about fixing it. > > > > > 2. The second issue is the one I am trying to solve. The > > > incidental case > when the channel is congested and the RRP > > > taking more time than expected to > arrive at the MN or the > > > channel is congested that some of the RRP is dropped > BUT > > > NOT every RRP is dropped. > > > > > My solution to this problem is to prevent Stale-Challenge > > > DOS by allowing > the MN to indicate to the FA that it is a > > > retransmit and the FA will accept > the RRQ and relay it to > > > the HA. By NOT blocking the retransmit RRQ at the FA > due > > > to STALE_CHALLENGE, a successful RRP with code (00) is always > > > sent to > the MN. This gives the MN a chance to receive one > > > successful RRP message > before MN hits its retry timer > > > (retransmit timer). > > i.e. In the example I outlined > > > earlier, MN will receive RRP (ID4) > "successful" while it > > > is tracking ID4. This makes the MN happy and > > > > Re-Registration will complete successfully. > > > > > > But, what if the RRP (ID4) is delayed until the MN > > > retransmits again? Really, the root cause of this problem is > > > that the MN didn't wait long enough for the first response. > > > [AM] > > Eventually, the MN will receive a successful RRP message > with an ID that the > MN is tracking. > > Why is that? Couldn't the response to ID4 be delayed > arbitrarily until the MN decides to retransmit? > > > > > > Rather, I think we can only fall back on this text which is > > > > > in RFC 3344: > > > > > > > > > > The maximum time until a new Registration Request is > > > sent SHOULD be > > > > > no greater than the requested Lifetime of the > > > Registration Request. > > > > > The minimum value SHOULD be large enough to account > > > for the size of > > > > > the messages, twice the round trip time for > > > transmission to the home > > > > > agent, and at least an additional 100 milliseconds to > > > allow for > > > > > processing the messages before responding. The round > > > trip time for > > > > > transmission to the home agent will be at least as > > > large as the time > > > > > required to transmit the messages at the link speed > > > of the mobile > > > > > node's current point of attachment. Some circuits > > > add another 200 > > > > > milliseconds of satellite delay in the total round > > > trip time to the > > > > > home agent. The minimum time between Registration > > > Requests MUST NOT > > > > > be less than 1 second. Each successive > > > retransmission timeout period > > > > > SHOULD be at least twice the previous period, as long > > > as that is less > > > > > than the maximum as specified above. > > > > > > > > > > So, if you know you are on a link with a lot of buffering, > > > > > you should increase the minimum interval between > > > > > retransmissions to take into account the worst-case round > > > > > trip time. This will ensure that, if there is any response > > > > > to your request in the queue, you will get it prior to > > > retransmitting. > > > > > [AM] > > > > I think the process you just highlighted is to provide the > > > MN with a dynamic > mechanism to detect the state of the > > > link. I believe it is very difficult to > statically predict > > > the sate of the link that the MN is attached to, > > > > especially with inter-technology handoff, etc... > > > > > > Well, I think you have to have some estimate of the RTT of > > > the link when choosing this parameter. If you are running > > > over a cdma2000 link you probably should not set the initial > > > retransmit interval smaller than 4 seconds. > > > > > [AM] > > I do not think that this will solve the problem. > > RFC3344 offers this mechanism which I think is a valid one > and MNs already > use this mechanism in the field. > > What do you mean here by "this mechanism"? Are you talking > about the choice of a timer value to use before retransmission? > > I think choosing a value of 4 seconds, when running over a > cdma2000 link, will allow a queued RRQ time to arrive at the MN. > > If the RRQ is lost, then yes, we will need to go through the > STALE_CHALLENGE error to get a new challenge. This may > extend the time to complete the registration. However, as > long as one round trip > (MN-FA-HA-FA-MN) eventually completes successfully, the MN > will get registered. > > > The issue here is that this DOS happens > > while customer doing serious activity. I understand that > this issue becomes > minor if it happens during initial registration. > > I'm not sure I see the difference in seriousness, but I'll > take your word for it. Anyway, it seems to me that choosing > a longer timer fixes the deadlock problem you have pointed out. > > > > > > > The basic Mobile IP message flow requires a complete > > > > > round-trip between MN & HA, where no link along the path > > > > > drops the message. Retransmission is performed > end-to-end. I > > > > > don't see how or why we should change this. > > > > > > > > > [AM] > > > > Unfortunately, RFC3012bis broke the mechanism outlined > > > above in section > 3.6.3 (RFC3344) by the stale-challenge > > > mechanism. > This solution is needed to enable the MN to > > > make use of the above mechanism. > > > > > > I don't think the retransmit mechanism is broken, you just > > > need to choose the right interval for the type of link > you are on. > > > > [AM] > > I disagree. Are you suggesting that the mechanism offered > in RRC3344 is not > needed. > Only specifying the right > interval will solve the problem! > > What "mechanism offered in RFC3344" are you referring to? > > > > You have also pointed out that receipt of a STALE_CHALLENGE > > > is really at best an ambiguous indicator to the MN of whether > > > or not it is registered. In the situation you outlined, the > > > FA has a valid registration renewal for the MN but the MN > > > doesn't know it. Perhaps we should state that the MN should > > > not disconnect itself merely because its old Lifetime > > > expired, when it receives one or more STALE_CHALLENGE results > > > from its attempts to register in the meantime. That is, if > > > the MN can continue to send and receive packets on the link, > > > it is possible to keep going even though the MN's local > > > estimate of the Lifetime has expired. > > > > > > > Are you serious here? > > Absolutely - I didn't see anything in RFC 3344 that would > require the MN to stop sending/receiving packets when its > local estimate of the Lifetime expires. Do you see something > there that would require this? Could you point it out? > > Can anyone else speak up if there is really a known deadlock > problem here that we need to address? > > -Pete > > > > ------_=_NextPart_001_01C38F85.836B1EE6 Content-Type: text/html RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS

Hi, Pete,
Is there any update on the security concern you mentioned in regard to this issue.

"
Maybe not. I'd still like a review by security folks before we do something like this.
"

Regards,
Ahmad

> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Tuesday, September 16, 2003 1:00 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: 'mip4@ietf.org'; Bharatia, Jayshree [RICH1:2H13:EXCH]
> Subject: RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS
>
>
>
> Hi, Ahmad,
>
> Some comments below...
>
> Ahmad Muhanna writes:
>
> [snip]
> > > So, you are saying that whether or not the FA has received a
> > > response to the original RRQ from the HA, it forwards the new
> > > registration request to the HA, not a copy of the old
> one, right? > >
> > [AM]
> > YES.
> > > You used the words "forwards the Registration Request to the
> > > Home Agent again" but you didn't specify what you mean by
> > > "the Registration Request". The new one is not identical to
> > > the old one, as it differs in both the Challenge and
> > > Identification fields.
> > >
> >
> > [AM]
> > Let us read the following in RFC3012-bis under section
> 3.2: > " If a mobile node retransmits a Registration
> Request with the same
> >    Challenge extension, and the Foreign Agent still has a pending
> >    Registration Request record in effect for the mobile node, then
> >    the Foreign Agent forwards the Registration Request to the Home
> >    Agent again.
> > "
> > Is there any concern about that? Retransmitted RRQ always
> contain a new ID > when timestamp is used.
>
> Good point; I guess I am ok with the wording, if this is
> something we want to do.
>
> [snip]
>
> > > So we have to be careful here - we are (slightly) weakening
> > > the strength of the Challenge mechanism if we allow a whole
> > > range of consecutive challenges to be valid at the FA
> instead > > of just one. How do we choose the proper window
> size? Is it
> > > possible to characterize the resulting strength/weakness of
> > > the challenge mechanism?
> >
> > [AM]
> > If that is TRUE, I believe the Timestamp replay protection
> mechanism between > MN and HA suffers the same weakness. I
> do not think that we are weakening > the strength of
> challenge mechanism here. > I think we either use a window
> of challenges or always previous challenge > +/- 1. > I do
> not think defining the window is a big problem.
>
> Maybe not. I'd still like a review by security folks before
> we do something like this.
>
> > > > > If, as you point out, the forward channel towards the MN is
> > > > > congested, and it is impossible to guarantee timely
> delivery
> > > > > of the RRP, the MN may not receive the RRP before it
> > > > > increments the ID field (note that only the Timestamp based
> > > > > replay protection causes the ID field to increment on a
> > > > > retransmission) and retransmits the request.
> > > > > However, I fail to see how your changes fix this
> problem. It
> > > > > seems like even if we had a way to indicate the
> presence of a
> > > > > retransmission to the FA, the circumstances that
> you outline
> > > > > could still take place. In fact, RRPs may be
> dropped entirely
> > > > > on the reverse link due to congestion, not just
> arrive late.
> > > > > It is true that the challenge response mechanism
> introduces a
> > > > > new failure case (STALE_CHALLENGE), but this seems
> > > incidental to me. >
> > > > [AM]
> > > > You are highlighting two issues here.
> > > > 1. The channel is totally blocked (???) and all RRPs will
> > > be dropped in the > way to the MN. This scenario no one has
> > > a solution for and we should not > worry about fixing it. >
> > > > 2. The second issue is the one I am trying to solve. The
> > > incidental case > when the channel is congested and the RRP
> > > taking more time than expected to > arrive at the MN or the
> > > channel is congested that some of the RRP is dropped > BUT
> > > NOT every RRP is dropped. >
> > > > My solution to this problem is to prevent Stale-Challenge
> > > DOS by allowing > the MN to indicate to the FA that it is a
> > > retransmit and the FA will accept > the RRQ and relay it to
> > > the HA. By NOT blocking the retransmit RRQ at the FA > due
> > > to STALE_CHALLENGE, a successful RRP with code (00) is always
> > > sent to > the MN. This gives the MN a chance to receive one
> > > successful RRP message > before MN hits its retry timer
> > > (retransmit timer). > > i.e. In the example I outlined
> > > earlier, MN will receive RRP (ID4) > "successful" while it
> > > is tracking ID4. This makes the MN happy and >
> > > Re-Registration will complete successfully.
> > >
> > > But, what if the RRP (ID4) is delayed until the MN
> > > retransmits again? Really, the root cause of this problem is
> > > that the MN didn't wait long enough for the first response. >
> > [AM]
> > Eventually, the MN will receive a successful RRP message
> with an ID that the > MN is tracking.
>
> Why is that? Couldn't the response to ID4 be delayed
> arbitrarily until the MN decides to retransmit?
>
> > > > > Rather, I think we can only fall back on this text which is
> > > > > in RFC 3344:
> > > > >
> > > > >    The maximum time until a new Registration Request is
> > > sent SHOULD be
> > > > >    no greater than the requested Lifetime of the
> > > Registration Request.
> > > > >    The minimum value SHOULD be large enough to account
> > > for the size of
> > > > >    the messages, twice the round trip time for
> > > transmission to the home
> > > > >    agent, and at least an additional 100 milliseconds to
> > > allow for
> > > > >    processing the messages before responding. The round
> > > trip time for
> > > > >    transmission to the home agent will be at least as
> > > large as the time
> > > > >    required to transmit the messages at the link speed
> > > of the mobile
> > > > >    node's current point of attachment. Some circuits
> > > add another 200
> > > > >    milliseconds of satellite delay in the total round
> > > trip time to the
> > > > >    home agent. The minimum time between Registration
> > > Requests MUST NOT
> > > > >    be less than 1 second. Each successive
> > > retransmission timeout period
> > > > >    SHOULD be at least twice the previous period, as long
> > > as that is less
> > > > >    than the maximum as specified above.
> > > > >
> > > > > So, if you know you are on a link with a lot of buffering,
> > > > > you should increase the minimum interval between
> > > > > retransmissions to take into account the worst-case round
> > > > > trip time. This will ensure that, if there is any response
> > > > > to your request in the queue, you will get it prior to
> > > retransmitting. >
> > > > [AM]
> > > > I think the process you just highlighted is to provide the
> > > MN with a dynamic > mechanism to detect the state of the
> > > link. I believe it is very difficult to > statically predict
> > > the sate of the link that the MN is attached to, >
> > > especially with inter-technology handoff, etc...
> > >
> > > Well, I think you have to have some estimate of the RTT of
> > > the link when choosing this parameter. If you are running
> > > over a cdma2000 link you probably should not set the initial
> > > retransmit interval smaller than 4 seconds.
> > >
> > [AM]
> > I do not think that this will solve the problem.
> > RFC3344 offers this mechanism which I think is a valid one
> and MNs already > use this mechanism in the field.
>
> What do you mean here by "this mechanism"? Are you talking
> about the choice of a timer value to use before retransmission?
>
> I think choosing a value of 4 seconds, when running over a
> cdma2000 link, will allow a queued RRQ time to arrive at the MN.
>
> If the RRQ is lost, then yes, we will need to go through the
> STALE_CHALLENGE error to get a new challenge. This may
> extend the time to complete the registration. However, as
> long as one round trip
> (MN-FA-HA-FA-MN) eventually completes successfully, the MN
> will get registered.
>
> > The issue here is that this DOS happens
> > while customer doing serious activity. I understand that
> this issue becomes > minor if it happens during initial registration.
>
> I'm not sure I see the difference in seriousness, but I'll
> take your word for it. Anyway, it seems to me that choosing
> a longer timer fixes the deadlock problem you have pointed out.
>
>
> > > > > The basic Mobile IP message flow requires a complete
> > > > > round-trip between MN & HA, where no link along the path
> > > > > drops the message. Retransmission is performed
> end-to-end. I
> > > > > don't see how or why we should change this.
> > > > >
> > > > [AM]
> > > > Unfortunately, RFC3012bis broke the mechanism outlined
> > > above in section > 3.6.3 (RFC3344) by the stale-challenge
> > > mechanism. > This solution is needed to enable the MN to
> > > make use of the above mechanism.
> > >
> > > I don't think the retransmit mechanism is broken, you just
> > > need to choose the right interval for the type of link
> you are on. > >
> > [AM]
> > I disagree. Are you suggesting that the mechanism offered
> in RRC3344 is not > needed. > Only specifying the right
> interval will solve the problem!
>
> What "mechanism offered in RFC3344" are you referring to?
>
> > > You have also pointed out that receipt of a STALE_CHALLENGE
> > > is really at best an ambiguous indicator to the MN of whether
> > > or not it is registered. In the situation you outlined, the
> > > FA has a valid registration renewal for the MN but the MN
> > > doesn't know it. Perhaps we should state that the MN should
> > > not disconnect itself merely because its old Lifetime
> > > expired, when it receives one or more STALE_CHALLENGE results
> > > from its attempts to register in the meantime. That is, if
> > > the MN can continue to send and receive packets on the link,
> > > it is possible to keep going even though the MN's local
> > > estimate of the Lifetime has expired.
> > >
> >
> > Are you serious here?
>
> Absolutely - I didn't see anything in RFC 3344 that would
> require the MN to stop sending/receiving packets when its
> local estimate of the Lifetime expires. Do you see something
> there that would require this? Could you point it out?
>
> Can anyone else speak up if there is really a known deadlock
> problem here that we need to address?
>
> -Pete
>
>
>
>

------_=_NextPart_001_01C38F85.836B1EE6-- -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Oct 10 23:57:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06804 for ; Fri, 10 Oct 2003 23:57:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AsP-0001f7-Ot for mip4-archive@odin.ietf.org; Fri, 10 Oct 2003 23:57:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9B3v8qw006390 for mip4-archive@odin.ietf.org; Fri, 10 Oct 2003 23:57:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AsO-0001ez-3R for mip4-web-archive@optimus.ietf.org; Fri, 10 Oct 2003 23:57:08 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06800 for ; Fri, 10 Oct 2003 23:56:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8AsL-0007Ih-00 for mip4-web-archive@ietf.org; Fri, 10 Oct 2003 23:57:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8AsK-0007Ie-00 for mip4-web-archive@ietf.org; Fri, 10 Oct 2003 23:57:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8AsH-0001ed-Gr; Fri, 10 Oct 2003 23:57:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8ArN-0001d3-HV for mip4@optimus.ietf.org; Fri, 10 Oct 2003 23:56:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06764 for ; Fri, 10 Oct 2003 23:55:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8ArK-0007I3-00 for mip4@ietf.org; Fri, 10 Oct 2003 23:56:02 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1A8ArJ-0007Hi-00 for mip4@ietf.org; Fri, 10 Oct 2003 23:56:01 -0400 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 h9B3tMN08995; Fri, 10 Oct 2003 22:55:23 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h9B3tJW18061; Fri, 10 Oct 2003 22:55:20 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HMKQVV-0001XO-00; Fri, 10 Oct 2003 23:55:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16263.32538.783814.139364@gargle.gargle.HOWL> Date: Fri, 10 Oct 2003 22:55:06 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "'mip4@ietf.org'" , "Jayshree Bharatia" Subject: RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Ahmad, No, I haven't gone out seeking security review on this, if that's what you mean. To be honest, I think it will introduce a lot of delay into the process to make a change like this. We should understand the costs and benefits of other potential solutions (such as increasing the retransmission timeout in the implementations that have experienced problems) before wasting the time of a security expert. -Pete Ahmad Muhanna writes: > Hi, Pete, > Is there any update on the security concern you mentioned in regard to this > issue. > > " > Maybe not. I'd still like a review by security folks before we do something > like this. > " > > Regards, > Ahmad > > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Tuesday, September 16, 2003 1:00 PM > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > Cc: 'mip4@ietf.org'; Bharatia, Jayshree [RICH1:2H13:EXCH] > > Subject: RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS > > > > > > > > Hi, Ahmad, > > > > Some comments below... > > > > Ahmad Muhanna writes: > > > > [snip] > > > > So, you are saying that whether or not the FA has received a > > > > response to the original RRQ from the HA, it forwards the new > > > > registration request to the HA, not a copy of the old > > one, right? > > > > > [AM] > > > YES. > > > > You used the words "forwards the Registration Request to the > > > > Home Agent again" but you didn't specify what you mean by > > > > "the Registration Request". The new one is not identical to > > > > the old one, as it differs in both the Challenge and > > > > Identification fields. > > > > > > > > > > [AM] > > > Let us read the following in RFC3012-bis under section > > 3.2: > " If a mobile node retransmits a Registration > > Request with the same > > > Challenge extension, and the Foreign Agent still has a pending > > > Registration Request record in effect for the mobile node, then > > > the Foreign Agent forwards the Registration Request to the Home > > > Agent again. > > > " > > > Is there any concern about that? Retransmitted RRQ always > > contain a new ID > when timestamp is used. > > > > Good point; I guess I am ok with the wording, if this is > > something we want to do. > > > > [snip] > > > > > > So we have to be careful here - we are (slightly) weakening > > > > the strength of the Challenge mechanism if we allow a whole > > > > range of consecutive challenges to be valid at the FA > > instead > > of just one. How do we choose the proper window > > size? Is it > > > > possible to characterize the resulting strength/weakness of > > > > the challenge mechanism? > > > > > > [AM] > > > If that is TRUE, I believe the Timestamp replay protection > > mechanism between > MN and HA suffers the same weakness. I > > do not think that we are weakening > the strength of > > challenge mechanism here. > I think we either use a window > > of challenges or always previous challenge > +/- 1. > I do > > not think defining the window is a big problem. > > > > Maybe not. I'd still like a review by security folks before > > we do something like this. > > > > > > > > If, as you point out, the forward channel towards the MN is > > > > > > congested, and it is impossible to guarantee timely > > delivery > > > > > > of the RRP, the MN may not receive the RRP before it > > > > > > increments the ID field (note that only the Timestamp based > > > > > > replay protection causes the ID field to increment on a > > > > > > retransmission) and retransmits the request. > > > > > > However, I fail to see how your changes fix this > > problem. It > > > > > > seems like even if we had a way to indicate the > > presence of a > > > > > > retransmission to the FA, the circumstances that > > you outline > > > > > > could still take place. In fact, RRPs may be > > dropped entirely > > > > > > on the reverse link due to congestion, not just > > arrive late. > > > > > > It is true that the challenge response mechanism > > introduces a > > > > > > new failure case (STALE_CHALLENGE), but this seems > > > > incidental to me. > > > > > > [AM] > > > > > You are highlighting two issues here. > > > > > 1. The channel is totally blocked (???) and all RRPs will > > > > be dropped in the > way to the MN. This scenario no one has > > > > a solution for and we should not > worry about fixing it. > > > > > > 2. The second issue is the one I am trying to solve. The > > > > incidental case > when the channel is congested and the RRP > > > > taking more time than expected to > arrive at the MN or the > > > > channel is congested that some of the RRP is dropped > BUT > > > > NOT every RRP is dropped. > > > > > > My solution to this problem is to prevent Stale-Challenge > > > > DOS by allowing > the MN to indicate to the FA that it is a > > > > retransmit and the FA will accept > the RRQ and relay it to > > > > the HA. By NOT blocking the retransmit RRQ at the FA > due > > > > to STALE_CHALLENGE, a successful RRP with code (00) is always > > > > sent to > the MN. This gives the MN a chance to receive one > > > > successful RRP message > before MN hits its retry timer > > > > (retransmit timer). > > i.e. In the example I outlined > > > > earlier, MN will receive RRP (ID4) > "successful" while it > > > > is tracking ID4. This makes the MN happy and > > > > > Re-Registration will complete successfully. > > > > > > > > But, what if the RRP (ID4) is delayed until the MN > > > > retransmits again? Really, the root cause of this problem is > > > > that the MN didn't wait long enough for the first response. > > > > [AM] > > > Eventually, the MN will receive a successful RRP message > > with an ID that the > MN is tracking. > > > > Why is that? Couldn't the response to ID4 be delayed > > arbitrarily until the MN decides to retransmit? > > > > > > > > Rather, I think we can only fall back on this text which is > > > > > > in RFC 3344: > > > > > > > > > > > > The maximum time until a new Registration Request is > > > > sent SHOULD be > > > > > > no greater than the requested Lifetime of the > > > > Registration Request. > > > > > > The minimum value SHOULD be large enough to account > > > > for the size of > > > > > > the messages, twice the round trip time for > > > > transmission to the home > > > > > > agent, and at least an additional 100 milliseconds to > > > > allow for > > > > > > processing the messages before responding. The round > > > > trip time for > > > > > > transmission to the home agent will be at least as > > > > large as the time > > > > > > required to transmit the messages at the link speed > > > > of the mobile > > > > > > node's current point of attachment. Some circuits > > > > add another 200 > > > > > > milliseconds of satellite delay in the total round > > > > trip time to the > > > > > > home agent. The minimum time between Registration > > > > Requests MUST NOT > > > > > > be less than 1 second. Each successive > > > > retransmission timeout period > > > > > > SHOULD be at least twice the previous period, as long > > > > as that is less > > > > > > than the maximum as specified above. > > > > > > > > > > > > So, if you know you are on a link with a lot of buffering, > > > > > > you should increase the minimum interval between > > > > > > retransmissions to take into account the worst-case round > > > > > > trip time. This will ensure that, if there is any response > > > > > > to your request in the queue, you will get it prior to > > > > retransmitting. > > > > > > [AM] > > > > > I think the process you just highlighted is to provide the > > > > MN with a dynamic > mechanism to detect the state of the > > > > link. I believe it is very difficult to > statically predict > > > > the sate of the link that the MN is attached to, > > > > > especially with inter-technology handoff, etc... > > > > > > > > Well, I think you have to have some estimate of the RTT of > > > > the link when choosing this parameter. If you are running > > > > over a cdma2000 link you probably should not set the initial > > > > retransmit interval smaller than 4 seconds. > > > > > > > [AM] > > > I do not think that this will solve the problem. > > > RFC3344 offers this mechanism which I think is a valid one > > and MNs already > use this mechanism in the field. > > > > What do you mean here by "this mechanism"? Are you talking > > about the choice of a timer value to use before retransmission? > > > > I think choosing a value of 4 seconds, when running over a > > cdma2000 link, will allow a queued RRQ time to arrive at the MN. > > > > If the RRQ is lost, then yes, we will need to go through the > > STALE_CHALLENGE error to get a new challenge. This may > > extend the time to complete the registration. However, as > > long as one round trip > > (MN-FA-HA-FA-MN) eventually completes successfully, the MN > > will get registered. > > > > > The issue here is that this DOS happens > > > while customer doing serious activity. I understand that > > this issue becomes > minor if it happens during initial registration. > > > > I'm not sure I see the difference in seriousness, but I'll > > take your word for it. Anyway, it seems to me that choosing > > a longer timer fixes the deadlock problem you have pointed out. > > > > > > > > > > The basic Mobile IP message flow requires a complete > > > > > > round-trip between MN & HA, where no link along the path > > > > > > drops the message. Retransmission is performed > > end-to-end. I > > > > > > don't see how or why we should change this. > > > > > > > > > > > [AM] > > > > > Unfortunately, RFC3012bis broke the mechanism outlined > > > > above in section > 3.6.3 (RFC3344) by the stale-challenge > > > > mechanism. > This solution is needed to enable the MN to > > > > make use of the above mechanism. > > > > > > > > I don't think the retransmit mechanism is broken, you just > > > > need to choose the right interval for the type of link > > you are on. > > > > > [AM] > > > I disagree. Are you suggesting that the mechanism offered > > in RRC3344 is not > needed. > Only specifying the right > > interval will solve the problem! > > > > What "mechanism offered in RFC3344" are you referring to? > > > > > > You have also pointed out that receipt of a STALE_CHALLENGE > > > > is really at best an ambiguous indicator to the MN of whether > > > > or not it is registered. In the situation you outlined, the > > > > FA has a valid registration renewal for the MN but the MN > > > > doesn't know it. Perhaps we should state that the MN should > > > > not disconnect itself merely because its old Lifetime > > > > expired, when it receives one or more STALE_CHALLENGE results > > > > from its attempts to register in the meantime. That is, if > > > > the MN can continue to send and receive packets on the link, > > > > it is possible to keep going even though the MN's local > > > > estimate of the Lifetime has expired. > > > > > > > > > > Are you serious here? > > > > Absolutely - I didn't see anything in RFC 3344 that would > > require the MN to stop sending/receiving packets when its > > local estimate of the Lifetime expires. Do you see something > > there that would require this? Could you point it out? > > > > Can anyone else speak up if there is really a known deadlock > > problem here that we need to address? > > > > -Pete -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Oct 12 20:39:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04420 for ; Sun, 12 Oct 2003 20:39:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8qjr-0003Ug-Nk for mip4-archive@odin.ietf.org; Sun, 12 Oct 2003 20:39:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D0d7qN013431 for mip4-archive@odin.ietf.org; Sun, 12 Oct 2003 20:39:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8qjr-0003UY-FF for mip4-web-archive@optimus.ietf.org; Sun, 12 Oct 2003 20:39:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04409 for ; Sun, 12 Oct 2003 20:38:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8qjp-0004U4-00 for mip4-web-archive@ietf.org; Sun, 12 Oct 2003 20:39:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8qjo-0004Ty-00 for mip4-web-archive@ietf.org; Sun, 12 Oct 2003 20:39:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8qjk-0003Sz-Q5; Sun, 12 Oct 2003 20:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8qj0-0003Rl-1h for mip4@optimus.ietf.org; Sun, 12 Oct 2003 20:38:18 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04352 for ; Sun, 12 Oct 2003 20:38:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8qix-0004SI-00 for mip4@ietf.org; Sun, 12 Oct 2003 20:38:11 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1A8qix-0004S9-00 for mip4@ietf.org; Sun, 12 Oct 2003 20:38:11 -0400 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h9D0bZUP029448; Sun, 12 Oct 2003 17:37:36 -0700 (PDT) Received: from sun.com (vpn-129-156-96-99.EMEA.Sun.COM [129.156.96.99]) by bebop.France.Sun.COM (8.11.7+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id h9D0bXS24352; Mon, 13 Oct 2003 02:37:34 +0200 (MEST) Message-ID: <3F89F1BE.8020607@sun.com> Date: Mon, 13 Oct 2003 02:28:46 +0200 From: gabriel montenegro Reply-To: gab@sun.com User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: Bjorn Andersson , mip4@ietf.org Subject: Re: [Mip4] Editorial fix to RFC3024 References: <20031008081759.GB16710@yin.bjorns.net> <20031008120137.7c903a34.henrik@levkowetz.com> In-Reply-To: <20031008120137.7c903a34.henrik@levkowetz.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This was reported before and is already listed in the errata page (available from the rfc editor site) under the entry for rfc3024: http://www.rfc-editor.org/errata.html -gabriel Henrik Levkowetz wrote: > On Wednesday, 8 Oct 2003, Bjorn wrote: > > >>Hi, there is a minor typo in RFC3024 section 4.3.1, last paragraph: >>"Upon receipt of a Registration Reply", should be "...Request". > > > Right. I've added rfc3024 as a document in the mip4 issue tracker > at > http://ietf.levkowetz.com/ietf/issues/tracker/mip4/ . > > Would you care to add this as an issue for 3024 there please? > > (You'll have to add yourself as a user first, but that's a rather > simple procedure) > > Thanks, > Henrik > -- Gabriel Montenegro (Sun Microsystems Laboratories, Europe) 180, Avenue de l'Europe Email: gab@sun.com ZIRST de Montbonnot Mobile: +33 673 99 56 62 38334 Saint Ismier CEDEX, France Office: +33 476 18 80 45 (sun internal: x38045) Fax: +33 476 18 88 88 -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Oct 13 03:29:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25511 for ; Mon, 13 Oct 2003 03:29:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8x8b-0002f2-56 for mip4-archive@odin.ietf.org; Mon, 13 Oct 2003 03:29:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D7T4ov010228 for mip4-archive@odin.ietf.org; Mon, 13 Oct 2003 03:29:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8x8a-0002et-Jq for mip4-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 03:29:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25508 for ; Mon, 13 Oct 2003 03:28:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8x8Y-0007k0-00 for mip4-web-archive@ietf.org; Mon, 13 Oct 2003 03:29:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8x8X-0007jx-00 for mip4-web-archive@ietf.org; Mon, 13 Oct 2003 03:29:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8x8X-0002eB-AD; Mon, 13 Oct 2003 03:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8x8B-0002di-Si for mip4@optimus.ietf.org; Mon, 13 Oct 2003 03:28:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25495 for ; Mon, 13 Oct 2003 03:28:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8x89-0007jY-00 for mip4@ietf.org; Mon, 13 Oct 2003 03:28:37 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A8x88-0007jT-00 for mip4@ietf.org; Mon, 13 Oct 2003 03:28:36 -0400 Received: (qmail 1122 invoked from network); 13 Oct 2003 07:28:35 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 13 Oct 2003 07:28:35 -0000 Date: Mon, 13 Oct 2003 09:28:34 +0200 From: Henrik Levkowetz To: mip4@ietf.org Cc: Ralph Droms Message-Id: <20031013092834.14db8925.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.5claws (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] Fw: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit The message below (hereby forwarded from the dhcwg list to the mip4 list) announces a dhc WG last call on "DHCP Option for Mobile IP Mobility Agents", . Although this is a dhc WG work item, is highly relevant to the Mip4 working group. Please respond to this WG last call, on the dhcwg mailing list (dhcwg@ietf.org), with copies to the mip4 list. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. Henrik ---- Begin forwarded message: ---- > Date: Sun, 12 Oct 2003 11:17:00 -0400 > From: Ralph Droms > To: dhcwg@ietf.org > Subject: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt > > > This message announces a WG last call on "DHCP Option for Mobile IP Mobility > Agents" . The last call will conclude > at 5PM ET on Friday, 10/24/2003. > > 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-dhc-mipadvert-opt-01.txt defines a new DHCP Option called the > Mobility Agent Option, and two sub-options of the Mobility Agent Option: the > Network Access Identifier Sub-Option, which provides > identifying information about a DHCP client to the DHCP server and the > Mobility Agent Announcement sub-option, which announces the address of one > or more mobility agents available to a host. This draft is available as > http://www.ietf.org/internet-drafts/draft-ietf-dhc-mipadvert-opt-01.txt > > - Ralph Droms > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Oct 13 05:19:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27794 for ; Mon, 13 Oct 2003 05:19:32 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8yr4-0007AR-Vn for mip4-archive@odin.ietf.org; Mon, 13 Oct 2003 05:19:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9D9J6H8027541 for mip4-archive@odin.ietf.org; Mon, 13 Oct 2003 05:19:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8yr2-0007A8-T2 for mip4-web-archive@optimus.ietf.org; Mon, 13 Oct 2003 05:19:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27766 for ; Mon, 13 Oct 2003 05:18:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8yqz-0000ic-00 for mip4-web-archive@ietf.org; Mon, 13 Oct 2003 05:19:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A8yqy-0000iW-00 for mip4-web-archive@ietf.org; Mon, 13 Oct 2003 05:19:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8yqz-000795-Lk; Mon, 13 Oct 2003 05:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A8yq9-000787-Hy for mip4@optimus.ietf.org; Mon, 13 Oct 2003 05:18:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27731 for ; Mon, 13 Oct 2003 05:17:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A8yq5-0000hk-00 for mip4@ietf.org; Mon, 13 Oct 2003 05:18:06 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A8yq5-0000hU-00 for mip4@ietf.org; Mon, 13 Oct 2003 05:18:05 -0400 Received: from zrc2c010.us.nortel.com (zrc2c010.us.nortel.com [47.103.120.50]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h9D9Gpa10496; Mon, 13 Oct 2003 02:16:51 -0700 (PDT) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c010.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TBYJZBBX; Mon, 13 Oct 2003 04:16:52 -0500 Received: from iqmail.net (acpzt036.asiapac.nortel.com [47.152.187.46]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TBY8H132; Mon, 13 Oct 2003 04:16:51 -0500 Message-ID: <3F8A6D3F.6000505@iqmail.net> Date: Mon, 13 Oct 2003 04:15:43 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Kuntal Chowdhury 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: Henrik Levkowetz CC: mip4@ietf.org, Ralph Droms Subject: Re: [Mip4] Fw: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt References: <20031013092834.14db8925.henrik@levkowetz.com> In-Reply-To: <20031013092834.14db8925.henrik@levkowetz.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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit An high level comment: The draft talks about load sharing among Agents with this DHCP option. It is not apparent how the DHCP server comes to know about the actual load each Agent has at the time of sending a response to a client. The draft replicates the Agent Advertisement fields in the Mobility Agent Announcements. This may be too static i.e. requires pre-configuration in the DHCP server. I don't think it is a wise idea to proactively set some or all of the fields on behalf of the Mobility Agents e.g. The Agent may be busy and would like to set the B bit in AA. IMHO, the DHCP server should only include the Agent's IP address in the response. Let the client send an AS unicast to the Agent and let the Agent respond with an appropriate AA. Let Mobile IPv4 procedure take it's normal course. -Kuntal Henrik Levkowetz wrote: > The message below (hereby forwarded from the dhcwg list to the mip4 > list) announces a dhc WG last call on "DHCP Option for Mobile IP > Mobility Agents", . Although this > is a dhc WG work item, is highly relevant to the Mip4 working group. > > Please respond to this WG last call, on the dhcwg mailing list > (dhcwg@ietf.org), with copies to the mip4 list. If you support > acceptance of the document without change, respond with a simple > acknowledgment, so that support for the document can be assessed. > > Henrik > > ---- Begin forwarded message: ---- > > >>Date: Sun, 12 Oct 2003 11:17:00 -0400 >>From: Ralph Droms