From exim@www1.ietf.org Tue Sep 2 09:38:56 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 JAA24276 for ; Tue, 2 Sep 2003 09:38:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBMc-0002B4-Bb for mip4-archive@odin.ietf.org; Tue, 02 Sep 2003 09:38:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DcTkB008358 for mip4-archive@odin.ietf.org; Tue, 2 Sep 2003 09:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u8N6-0000O6-CQ for mip4-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 06:26:48 -0400 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 GAA07907 for ; Tue, 2 Sep 2003 06:26:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4uo-0003wQ-9T; Tue, 02 Sep 2003 02:45:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1MZ-00039X-Ja for mip4@optimus.ietf.org; Mon, 01 Sep 2003 22:57:47 -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 WAA04092 for ; Mon, 1 Sep 2003 22:57:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1MU-0004nk-00 for mip4@ietf.org; Mon, 01 Sep 2003 22:57:42 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 19tlp6-0002o0-00 for mip4@ietf.org; Mon, 01 Sep 2003 06:22:12 -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 h81ALgj0020831; Mon, 1 Sep 2003 12:21:42 +0200 Date: Mon, 1 Sep 2003 12:21:34 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20030901122134.7bb8fab2.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.O644uswtfz(SH+" X-Spam-Status: No, hits=-2.5 required=5.0 tests=PGP_SIGNATURE_2 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] [Issue] draft-kulkarni-mobileip-dynamic-assignment: Missing information 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: , --=.O644uswtfz(SH+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, The mechanism outlined in this draft is in many cases a little bit too simple, in this respect: A HA deployed in a network of public addresses, serving a home network with public addresses, may be able to make do with one single identifying address, a public address by which it is known by a MN both when the MN is at home and when it is away, roaming. However, many (most?) deployments today sports HAs with two interfaces; one towards the public internet and one towards the home network. The MN has to know both of these, in order to identify when it is on the home network (home link) and direct it's (de) registration to the HA when coming home. The mechanism propsed in -01 of this drafts only communicates one addresss (the public one) to the MN; there is no provision for communicating the HA address on the home network when that is different from the public address. The simplest way of addressing this concern would be to provide the HA home network interface address in an extension. Furthermore, in that case, one might raise the question of maybe providing both public and private address in the extension (but this point is not particularly important). Regards, Henrik --=.O644uswtfz(SH+ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD4DBQE/Ux22eVhrtTJkXCMRAox9AJiywOyheLCwN6HWFx4O40WJkbnlAKCLF/Pm Q/8ZrxTI1ChjfexRqfN1Ow== =mG0g -----END PGP SIGNATURE----- --=.O644uswtfz(SH+-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 2 09:39:59 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 JAA24745 for ; Tue, 2 Sep 2003 09:39:59 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBNd-0002XL-V3 for mip4-archive@odin.ietf.org; Tue, 02 Sep 2003 09:39:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DdXw0009736 for mip4-archive@odin.ietf.org; Tue, 2 Sep 2003 09:39:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u8K1-0008UH-85 for mip4-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 06:23:37 -0400 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 GAA07729 for ; Tue, 2 Sep 2003 06:23:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u4uy-0003ym-Ll; Tue, 02 Sep 2003 02:45:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u1G2-0002TJ-Eu for mip4@optimus.ietf.org; Mon, 01 Sep 2003 22:51: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 WAA02027 for ; Mon, 1 Sep 2003 22:50:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u1Fx-0002ez-00 for mip4@ietf.org; Mon, 01 Sep 2003 22:50:57 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19toxt-00078b-00 for mip4@ietf.org; Mon, 01 Sep 2003 09:43:29 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h81DhNK30234 for ; Mon, 1 Sep 2003 15:43:23 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F534CEE.4090000@comnets.uni-bremen.de> Date: Mon, 01 Sep 2003 15:43:10 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mip4@ietf.org'" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] regional registration draft Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi all, I have a question on the regional registrations draft (draft-ietf-mobileip-reg-tunnel-07.txt). According to Appendix Section "B.1. Registration with Home Agent" (p.32-33), a foreign agent may have to include in its agent advertisements the addresses of all mobility agents (RFAs, GFAs) in its hierarchy branch. I would like to know what the reason is behind this action, because considering a MIP hierarchy with several levels then agent advertisements may acquire a significant size. Moreover, considering that foreign agents may have to increase their advertisement period in order to accelrate MIP hand-offs, then the transmission of agent advertisements of some size may result in a significant overhead with an effect to network efficiency. Thanks in advance niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 2 09:44:48 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 JAA25567 for ; Tue, 2 Sep 2003 09:44:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBSJ-0003eK-43 for mip4-archive@odin.ietf.org; Tue, 02 Sep 2003 09:44:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82DiMTQ014017 for mip4-archive@odin.ietf.org; Tue, 2 Sep 2003 09:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBSI-0003dz-Pp for mip4-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 09:44:22 -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 JAA25394 for ; Tue, 2 Sep 2003 09:44:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uBSG-00009P-00 for mip4-web-archive@ietf.org; Tue, 02 Sep 2003 09:44:20 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uBOa-00003S-00 for mip4-web-archive@ietf.org; Tue, 02 Sep 2003 09:40:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uBOR-0002lJ-6L; Tue, 02 Sep 2003 09:40:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19u88X-0006td-5r for mip4@optimus.ietf.org; Tue, 02 Sep 2003 06:11: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 GAA06735 for ; Tue, 2 Sep 2003 06:11:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19u88S-0001lc-00 for mip4@ietf.org; Tue, 02 Sep 2003 06:11:40 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19u88R-0001lP-00 for mip4@ietf.org; Tue, 02 Sep 2003 06:11:39 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h82ABeK22459 for ; Tue, 2 Sep 2003 12:11:40 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F546CF0.1090605@comnets.uni-bremen.de> Date: Tue, 02 Sep 2003 12:12:00 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mip4@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] route optimisation 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 all, section "4.3 Binding Update Message" in pages 8-9 of document draft-ietf-mobileip-optim-10.txt defines the structure of the binding update extension. However, I have noticed that the 'S' bit is missing that is otherwise avaible in the Registration Request message format. Does that mean that it is assumed that CNs may only maintain a single binding for a mobile node? If so, then what is the reason? Is anybody aware of any existing implementations of routing optimisation for MIPv4? Thanks in advance niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 2 14:03:08 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 OAA21971 for ; Tue, 2 Sep 2003 14:03:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uFUJ-0006J0-98 for mip4-archive@odin.ietf.org; Tue, 02 Sep 2003 14:02:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h82I2ha0024238 for mip4-archive@odin.ietf.org; Tue, 2 Sep 2003 14:02:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uFUJ-0006Ir-4a for mip4-web-archive@optimus.ietf.org; Tue, 02 Sep 2003 14:02:43 -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 OAA21949 for ; Tue, 2 Sep 2003 14:02:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uFUG-0002Hz-00 for mip4-web-archive@ietf.org; Tue, 02 Sep 2003 14:02:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uFUG-0002Hv-00 for mip4-web-archive@ietf.org; Tue, 02 Sep 2003 14:02:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uFTd-0006Gw-6E; Tue, 02 Sep 2003 14:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uFSh-0006EH-VK for mip4@optimus.ietf.org; Tue, 02 Sep 2003 14:01: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 OAA21854 for ; Tue, 2 Sep 2003 14:00:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uFSf-0002Fd-00 for mip4@ietf.org; Tue, 02 Sep 2003 14:01:01 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19uFSe-0002Ec-00 for mip4@ietf.org; Tue, 02 Sep 2003 14:01:00 -0400 Received: (qmail 8250 invoked from network); 2 Sep 2003 18:00:28 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 2 Sep 2003 18:00:28 -0000 Date: Tue, 2 Sep 2003 20:00:26 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20030902200026.13883dea.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.0CmhBJYGhsu2ID" Subject: [Mip4] I-D ACTION:draft-ietf-mobileip-aaa-nai-06.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: , --=.0CmhBJYGhsu2ID Content-Type: multipart/mixed; boundary="Multipart_Tue__2_Sep_2003_20:00:26_+0200_093e33c8" --Multipart_Tue__2_Sep_2003_20:00:26_+0200_093e33c8 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Routing for Wireless/Mobile Hosts Working Group of the IETF. Title : AAA NAI for Mobile IPv4 Extension Author(s) : F. Johansson, T. Johansson Filename : draft-ietf-mobileip-aaa-nai-06.txt Pages : 9 Date : 2003-9-2 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple AAA servers the reauthentication request may not be received by the same AAAH as previous authentication requests. In order for the new AAAH to be able to forward the request to the correct HA it has to know the identity of the HA. This document defines an extension that enables the HA to pass its identity to the mobile node which can in turn pass it to the AAA server when changing point of attachment. This document specifies a NAI extension that can carry these NAIs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-nai-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobileip-aaa-nai-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobileip-aaa-nai-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --Multipart_Tue__2_Sep_2003_20:00:26_+0200_093e33c8 Content-Type: Message/External-body; name="00000002.mimetmp" Content-Disposition: attachment; filename="00000002.mimetmp" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6CTwyMDAzLTktMjEwMDMwMy5JLURA aWV0Zi5vcmc+CgpFTkNPRElORyBtaW1lCkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRm LW1vYmlsZWlwLWFhYS1uYWktMDYudHh0Cgo= --Multipart_Tue__2_Sep_2003_20:00:26_+0200_093e33c8 Content-Type: Message/External-body; name="draft-ietf-mobileip-aaa-nai-06.txt" Content-Disposition: attachment; filename="draft-ietf-mobileip-aaa-nai-06.txt" Content-Transfer-Encoding: base64 Q29udGVudC1UeXBlOiB0ZXh0L3BsYWluCkNvbnRlbnQtSUQ6CTwyMDAzLTktMjEwMDMwMy5JLURA aWV0Zi5vcmc+Cgo= --Multipart_Tue__2_Sep_2003_20:00:26_+0200_093e33c8-- --=.0CmhBJYGhsu2ID Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/VNq7eVhrtTJkXCMRArVcAJ4zp+rGiuWoKLfdz56thMGPjkrjNgCgkCU2 +kO48vEB0z2h/CWbYLgAesA= =hb9h -----END PGP SIGNATURE----- --=.0CmhBJYGhsu2ID-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 3 04:50:35 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 EAA15258 for ; Wed, 3 Sep 2003 04:50:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uTL8-0001sN-3Q for mip4-archive@odin.ietf.org; Wed, 03 Sep 2003 04:50:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h838oAvf007204 for mip4-archive@odin.ietf.org; Wed, 3 Sep 2003 04:50:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uTL6-0001qo-84 for mip4-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 04:50: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 EAA15223 for ; Wed, 3 Sep 2003 04:49:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uTL1-00049v-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 04:50:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uTKz-00049r-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 04:50:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uTL1-0001qU-NG; Wed, 03 Sep 2003 04:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uTKC-0001mK-17 for mip4@optimus.ietf.org; Wed, 03 Sep 2003 04:49:12 -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 EAA15161 for ; Wed, 3 Sep 2003 04:49:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uTK8-00048U-00 for mip4@ietf.org; Wed, 03 Sep 2003 04:49:08 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19uTK7-00048R-00 for mip4@ietf.org; Wed, 03 Sep 2003 04:49:07 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h838n7K14211 for ; Wed, 3 Sep 2003 10:49:07 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F55AB7C.4070903@comnets.uni-bremen.de> Date: Wed, 03 Sep 2003 10:51:08 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'mip4@ietf.org'" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] accelerating smooth hand-over in regional tunnel 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 all, I have been reading through the draft-ietf-mobileip-reg-tunnel-04.txt. I would like to know whether there has been any contemplation on enabling two plain low-level FAs (of the same or other hierarchy) to be directly connected. This would be a violation of hierarchical routing but may accelerate smooth hand-overs. Furthermore, this would not have to be a standard thing rather then only initiated by admins between FAs with lots of hand-offs between each other. Would that have any other protocol implications? have a nice day niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 3 07:12: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 HAA24735 for ; Wed, 3 Sep 2003 07:12: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 19uVYP-0001db-0p for mip4-archive@odin.ietf.org; Wed, 03 Sep 2003 07:12:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83BC0ca006291 for mip4-archive@odin.ietf.org; Wed, 3 Sep 2003 07:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uVYO-0001dO-TC for mip4-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 07:12:00 -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 HAA24709 for ; Wed, 3 Sep 2003 07:11:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uVYM-0005f9-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 07:11:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uVYL-0005f6-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 07:11:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uVYO-0001d2-Vj; Wed, 03 Sep 2003 07:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uVXr-0001cD-Dx for mip4@optimus.ietf.org; Wed, 03 Sep 2003 07:11: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 HAA24679 for ; Wed, 3 Sep 2003 07:11:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uVXm-0005e7-00 for mip4@ietf.org; Wed, 03 Sep 2003 07:11:22 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19uVXl-0005dM-00 for mip4@ietf.org; Wed, 03 Sep 2003 07:11:21 -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 h83BAlF00839; Wed, 3 Sep 2003 06:10:47 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 06:10:48 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" , "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Wed, 3 Sep 2003 06:10:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3720C.054D197E" 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_01C3720C.054D197E Content-Type: text/plain Hi, Pete, Please see comments inline. Regards, Ahmad > > Based on subsequent comments from Ahmad, maybe we can make > the requirement more generic here, and give a specific > example in Appendix E. For here, how about: > > 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. > I would like to propose the following: " 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 Agent Solicitations. " The reason I need to eliminate the unauthenticated RRQ is that we are intentionally allowing the violation of replay protection between the MN and FA. It is possible that the MN uses an old MN-AAA secret key (expired MN-AAA key) which may generate MN-AAA authentication failure. The real MN is allowed to correct itself in a way or another and try again for successful registration. The drawback in the case of an attacker, the MN may generate Stale Challenge at the FA. At that point, MN may solicit and receive an unused challenge. In the case of the MN being registered; it is still possible that the MN would have the MN-AAA key lifetime expired while still registered. The bottom line, an attacker with unauthenticated RRQ would not cause denial of Service as we may think. The process of generating a new challenge is very small in comparison with the whole process of RRQ, building a new RRP and send it back to the MN. > > > > > > -Pete > > > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > ------_=_NextPart_001_01C3720C.054D197E Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,
Please see comments inline.

Regards,
Ahmad


>
> Based on subsequent comments from Ahmad, maybe = we can make
> the requirement more generic here, and give a = specific
> example in Appendix E.  For here, how = about:
>
> 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.
>

I would like to propose the following:
"
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 = Agent Solicitations.
"

The reason I need to eliminate the unauthenticated = RRQ is that we are intentionally allowing the violation of replay = protection between the MN and FA. It is possible that the MN uses an = old MN-AAA secret key (expired MN-AAA key) which may generate MN-AAA = authentication failure. The real MN is allowed to correct itself in a = way or another and try again for successful registration. The drawback = in the case of an attacker, the MN may generate Stale Challenge at the = FA. At that point, MN may solicit and receive an unused challenge. In = the case of the MN being registered; it is still possible that the MN = would have the MN-AAA key lifetime expired while still registered. The = bottom line, an attacker with unauthenticated RRQ would not cause = denial of Service as we may think. The process of generating a new = challenge is very small in comparison with the whole process of RRQ, = building a new RRP and send it back to the MN.

>
>
>
>
>
> -Pete
>
>
> = _______________________________________________
> Mip4 mailing list
> Mip4@ietf.org
> https://www.ietf.org/mailman/listinfo/mip4
>

------_=_NextPart_001_01C3720C.054D197E-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 3 11:21: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 LAA14983 for ; Wed, 3 Sep 2003 11:21: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 19uZRQ-0006We-C0 for mip4-archive@odin.ietf.org; Wed, 03 Sep 2003 11:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83FL4fX025080 for mip4-archive@odin.ietf.org; Wed, 3 Sep 2003 11:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZRQ-0006WR-7g for mip4-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 11:21: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 LAA14944 for ; Wed, 3 Sep 2003 11:20:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uZRP-0001fR-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 11:21:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uZRO-0001fO-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 11:21:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZRM-0006Vb-V6; Wed, 03 Sep 2003 11:21:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uZQq-0006Th-73 for mip4@optimus.ietf.org; Wed, 03 Sep 2003 11:20: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 LAA14902 for ; Wed, 3 Sep 2003 11:20:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uZQp-0001eV-00 for mip4@ietf.org; Wed, 03 Sep 2003 11:20:27 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19uZQo-0001d2-00 for mip4@ietf.org; Wed, 03 Sep 2003 11:20:26 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h83FIBU24063; Wed, 3 Sep 2003 10:18:11 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h83FI9610313; Wed, 3 Sep 2003 10:18:09 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16214.1500.240227.972010@gargle.gargle.HOWL> Date: Wed, 3 Sep 2003 10:16:44 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Ahmad Muhanna writes: > Hi, Pete, > Please see comments inline. > > Regards, > Ahmad > > > > > > Based on subsequent comments from Ahmad, maybe we can make > > the requirement more generic here, and give a specific > > example in Appendix E. For here, how about: > > > > 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. > > > > I would like to propose the following: > " > 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 Agent Solicitations. > " > > The reason I need to eliminate the unauthenticated RRQ is that we are > intentionally allowing the violation of replay protection between the MN and > FA. It is possible that the MN uses an old MN-AAA secret key (expired MN-AAA > key) which may generate MN-AAA authentication failure. The real MN is > allowed to correct itself in a way or another and try again for successful > registration. The drawback in the case of an attacker, the MN may generate > Stale Challenge at the FA. At that point, MN may solicit and receive an > unused challenge. But then the attacker could immediately send another RRQ, invalidating the new challenge. > In the case of the MN being registered; it is still > possible that the MN would have the MN-AAA key lifetime expired while still > registered. Sure, but in this case the FA validation will fail and the challenge will not become "previously used." I am not quite sure I understand your point about "intentionally allowing the violation of replay protection". Could you explain this a bit more? It seems to me that as long as we do not accept as *valid* any message that re-uses a challenge that was used in a previous *valid* message, then we are secure. It is ok to reject as many *invalid* attempts as you want, there is no need to expire the challenge values contained therein. > The bottom line, an attacker with unauthenticated RRQ would not > cause denial of Service as we may think. The process of generating a new > challenge is very small in comparison with the whole process of RRQ, > building a new RRP and send it back to the MN. I still see a possible denial of service attack if we allow the FA to invalidate challenges based on unauthenticated RRQs. I note that your proposal also deleted the text that prohibits allocation of additional storage. Do you have an argument against this restriction? -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 3 11: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 LAA17980 for ; Wed, 3 Sep 2003 11: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 19ua2B-0008Aa-P8 for mip4-archive@odin.ietf.org; Wed, 03 Sep 2003 11:59:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83Fx3OZ031399 for mip4-archive@odin.ietf.org; Wed, 3 Sep 2003 11:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ua2B-00089k-5F for mip4-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 11:59: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 LAA17953 for ; Wed, 3 Sep 2003 11:58:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ua29-0002jo-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 11:59:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ua29-0002jl-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 11:59:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ua29-00089I-Mf; Wed, 03 Sep 2003 11: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 19uZWv-0006d7-64 for mip4@optimus.ietf.org; Wed, 03 Sep 2003 11:26: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 LAA15458 for ; Wed, 3 Sep 2003 11:26:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uZWu-0001pj-00 for mip4@ietf.org; Wed, 03 Sep 2003 11:26:44 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19uZWs-0001p1-00 for mip4@ietf.org; Wed, 03 Sep 2003 11:26:43 -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 h83FQ6F23704; Wed, 3 Sep 2003 10:26:06 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 10:26:06 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B46@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Pete McCann'" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Wed, 3 Sep 2003 10:26:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3722F.B15D27CC" 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_01C3722F.B15D27CC Content-Type: text/plain Hi Pete, Please see my comments inline. Regards, Jayshree > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Friday, August 29, 2003 11:56 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'mip4@ietf.org' > Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Jayshree, > > I am reorganizing all the text proposals into this one note > for easier reference. See comments below, and let me know if > I missed one of your notes. > > > [note chair hat is off for the remainder of this message] > > > > The current proposal for issue 1 is to use "previously > unused challenge" in > section 2 for all multicast and > unicast Agent Advertisements. > > I am not sure what you mean by this. Can you give a specific > text proposal, and a location for it in the draft? > [JB] Proposed text for section 2. From: The Challenge extension, illustrated in figure 1, is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate the latest challenge value that can be used by the mobile node to compute an authentication for its next registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. To: The Challenge extension, illustrated in figure 1, is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate a previously unused challenge value that can be used by the mobile node to compute an authentication for its next registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. > > In addition to this, Henrik proposed a new text for a new > subsection 2.1. > > > > 2.1 Handling of Solicited Agent Advertisements > > > > When a foreign agent generates an Agent Advertisement in > response to a > Router Solicitation [4], some additional > considerations come into play. > According to the Mobile IP > base specification [7], the resulting Agent > Advertisement > may be either multicast or unicast. > > > If the solicited Agent Advertisement is multicast, it MUST > NOT generate a > new Challenge value and update its window > of remembered advertised > Challenges. It must instead > re-use the most recent of the CHALLENGE_WINDOW > > Advertisement Challenge values. > > > 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 > ^ insert the word "it" > > > 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, 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.) > > I agree with this so far. > > > A foreign agent SHOULD NOT respond arbitrarily often to > agent solicitations, > in order to limit processing load, > especially in the face of hostile nodes > soliciting at a > very high rate. The rate of solicited agent advertisement > > responses SHOULD at most be 50 per second. > > I am not sure we need the last paragraph. Overload control, > especially the choice of which solicitations to discard, is a > tricky subject. I don't know that we will come to any > agreement on a maximum rate (cf. previous discussions on the > Mobile IP list regarding multicast agent advertisement rates). > > > > The original proposal from Henrik was to mandate a > challenge in a > Registration Reply. After few email > exchanges, it was decided that the > current text in section > 3.3 (RFC3012bis (version 05) ) is ok. In addition to > the > current text, Henrik proposed the following text to be used > as a > guidance/background: > > > (section 3.3) > > 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. The Foreign Agent could then > > assume that the mobile node with high likelihood has received > and can use > the multicast challenge. A mobile node MUST be > prepared to use a multicast > challenge 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 or > Agent > Advertisement. > > This is good, but it doesn't seem quite strong enough, i.e., > we still have a SHOULD on the inclusion of the previously > unused challenge. It seems to me we should require (with a > MUST) the inclusion of a challenge in the registration reply > if something like the condition above isn't met, and > similarly should require (with a MUST) the inclusion of a > challenge in responses to Agent Solicitations if the > condition isn't met. This is the only way to guarantee > progress on a link where advertisements may be lost and where > there is a long interval between unsolicited advertisements. > > [JB] This is the mechanism where the FA provides an unused challenge to the MN so that the MN can use this challenge in the subsequent request. If advertisements are lost or their interval is long enough, the MN can always request a challenge by sending Agent Solicitation. I would think that this type of guideline adds more confusion. By the way, the current text in section 3.3 is: "The Foreign Agent SHOULD include a new Mobile-Foreign Challenge Extension in any Registration Reply, successful or not. " I like to see use of term "previously unused challenge" instead of "new". > > > The current proposal from Pete is to reuse the challenge > in the Registration > Reply of the Registration Request for > which the authentication fails at the > FA. This challenge > sent in the Registration reply will be same as the > > challenge received in the Registration Request for which the > reply is sent. > > > To reflect this point, the following changes are proposed > by Jayshree: > > > (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. > > I don't support the text changes above, although I may have > proposed the principle of "repeating challenges." Perhaps we > don't need to make any text changes in this section, but can > confine the new text to the security considerations (see my > proposal below). > > [JB] I don't have any problem removing these changes. The proposed text does what was intended and that is, allowing repetition of challenges when authentication fails. > > This change further extends point mentioned in change 1 > for issue 2. The > proposal from Henrik was to clarify the > use of challenge. This text is > intended as a new paragraph > in section 3.3. > > > > "If the challenge most recently issued to the soliciting > mobile node has not > been previously used (as defined in > Section 1.1), the most recent challenge > unicast to the > mobile node through a registration reply or a unicast agent > > advertisement SHOULD be repeated in the registration reply." > > > This proposal was further modified by Pete differentiating > the processing at > the FA for the registered and > unregistered users: > > > "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." > > Based on the subsequent discussion, I don't think we need the > text changes above. See the security considerations: > > [JB]OK > > The following text was proposed to be added in section 12. > This is a > modified version of the text proposed by Henrik > on the mailing list earlier. > > > (section 12) > > 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 > SHOULD repeat the same challenge value > in successive > unicast responses to Agent Solicitations or in Registration > > Replies to Requests that did not contain valid MN-AAA or > MN-FA > authentication extensions. Note that each challenge > returned to an MN MUST > be previously unused by that MN. > > Based on subsequent comments from Ahmad, maybe we can make > the requirement more generic here, and give a specific > example in Appendix E. For here, how about: > > 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. > [JB] Can we explicitly write "new challenge" instead of "new storage"? > > > > > It was decided that challenges sent in unicast Agent > Advertisements and sent > in Registration Reply messages > should be treated same at the FA. For this, > the following > text is proposed by Henrik and Pete: > > > (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. > > After that, we could add, "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." > [JB] I would think that "already stored" is redundant here. > > -Pete > > ------_=_NextPart_001_01C3722F.B15D27CC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi Pete,

Please see my comments inline.

Regards,
Jayshree

> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Friday, August 29, 2003 11:56 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'mip4@ietf.org'
> Subject: [Mip4] RFC3012bis: Proposal for = Issue2-Change5
>
>
>
> Hi, Jayshree,
>
> I am reorganizing all the text proposals into = this one note
> for easier reference.  See comments below, = and let me know if
> I missed one of your notes.
>
>
> [note chair hat is off for the remainder of = this message]
>
>
>  > The current proposal for issue 1 is = to use "previously
> unused challenge" in  > section 2 = for all multicast and
> unicast Agent Advertisements.
>
> I am not sure what you mean by this.  Can = you give a specific
> text proposal, and a location for it in the = draft?
>
[JB] Proposed text for section 2.
From:
The Challenge extension, illustrated in figure 1, is = inserted in the Agent Advertisements by the Foreign Agent, in order to = communicate the latest challenge value that can be used by the mobile = node to compute an authentication for its next registration request = message.  The challenge is selected by the foreign agent to = provide local assurance that the mobile node is not replaying any = earlier registration request. 

To:
The Challenge extension, illustrated in figure 1, is = inserted in the Agent Advertisements by the Foreign Agent, in order to = communicate a previously unused challenge value that can be used by the = mobile node to compute an authentication for its next registration = request message.  The challenge is selected by the foreign agent = to provide local assurance that the mobile node is not replaying any = earlier registration request. 

>  > In addition to this, Henrik proposed = a new text for a new
> subsection 2.1.
>  >
>  > 2.1 Handling of Solicited Agent = Advertisements
>  >
>  > When a foreign agent generates an = Agent Advertisement in
> response to a  > Router Solicitation = [4], some additional
> considerations come into play.  > = According to the Mobile IP
> base specification [7], the resulting = Agent  > Advertisement
> may be either multicast or unicast.  > =
>  > If the solicited Agent Advertisement = is multicast, it MUST
> NOT generate a  > new Challenge value = and update its window
> of remembered advertised  > Challenges. = It must instead
> re-use the most recent of the = CHALLENGE_WINDOW  >
> Advertisement Challenge values.  > =
>  > 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
>   ^ insert the word = "it"
>
>  > 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, = 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.)
>
> I agree with this so far.
>
>  > A foreign agent SHOULD NOT respond = arbitrarily often to
> agent solicitations,  > in order to = limit processing load,
> especially in the face of hostile nodes  = > soliciting at a
> very high rate. The rate of solicited agent = advertisement  >
> responses SHOULD at most be 50 per = second.
>
> I am not sure we need the last paragraph.  = Overload control,
> especially the choice of which solicitations to = discard, is a
> tricky subject.  I don't know that we will = come to any
> agreement on a maximum rate (cf. previous = discussions on the
> Mobile IP list regarding multicast agent = advertisement rates).
>
>
>  > The original proposal from Henrik = was to mandate a
> challenge in a  > Registration Reply. = After few email
> exchanges, it was decided that the  > = current text in section
> 3.3 (RFC3012bis (version 05) ) is ok. In = addition to  > the
> current text, Henrik proposed the following = text to be used
> as a  > guidance/background:  > =
>  > (section 3.3)
>  > 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. The Foreign Agent = could then  >
> assume that the mobile node with high = likelihood has received
> and can use  > the multicast challenge. = A mobile node MUST be
> prepared to use a multicast  > = challenge 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 or
> Agent  > Advertisement.
>
> This is good, but it doesn't seem quite strong = enough, i.e.,
> we still have a SHOULD on the inclusion of the = previously
> unused challenge.  It seems to me we = should require (with a
> MUST) the inclusion of a challenge in the = registration reply
> if something like the condition above isn't = met, and
> similarly should require (with a MUST) the = inclusion of a
> challenge in responses to Agent Solicitations = if the
> condition isn't met.  This is the only way = to guarantee
> progress on a link where advertisements may be = lost and where
> there is a long interval between unsolicited = advertisements.
>
>
[JB] This is the mechanism where the FA provides an = unused challenge to the MN so that the MN can use this challenge in the = subsequent request. If advertisements are lost or their interval is = long enough, the MN can always request a challenge by sending Agent = Solicitation. I would think that this type of guideline adds more = confusion. By the way, the current text in section 3.3 is: "The = Foreign Agent SHOULD include a new Mobile-Foreign Challenge Extension = in any Registration Reply, successful or not. "

I like to see use of term "previously unused = challenge" instead of "new".
>
>  > The current proposal from Pete is to = reuse the challenge
> in the Registration  > Reply of the = Registration Request for
> which the authentication fails at the  = > FA. This challenge
> sent in the Registration reply will be same as = the  >
> challenge received in the Registration Request = for which the
> reply is sent.  >
>  > To reflect this point, the following = changes are proposed
> by Jayshree:  >
>  > (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.
>
> I don't support the text changes above, = although I may have
> proposed the principle of "repeating = challenges."  Perhaps we
> don't need to make any text changes in this = section, but can
> confine the new text to the security = considerations (see my
> proposal below).
>
>
[JB] I don't have any problem removing these = changes. The proposed text does what was intended and that is, allowing = repetition of challenges when authentication fails.

>  > This change further extends point = mentioned in change 1
> for issue 2. The  > proposal from = Henrik was to clarify the
> use of challenge. This text is  > = intended as a new paragraph
> in section 3.3.
>  >
>  > "If the challenge most recently = issued to the soliciting
> mobile node has not  > been previously = used (as defined in
> Section 1.1), the most recent challenge  = > unicast to the
> mobile node through a registration reply or a = unicast agent 
> > advertisement SHOULD be repeated in the = registration reply."  >
>  > This proposal was further modified = by Pete differentiating
> the processing at  > the FA for the = registered and
> unregistered users:  >
>  > "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."
>
> Based on the subsequent discussion, I don't = think we need the
> text changes above.  See the security = considerations:
>
>
[JB]OK

>  > The following text was proposed to be = added in section 12.
> This is a  > modified version of the = text proposed by Henrik
> on the mailing list earlier.  >
>  > (section 12)
>  > 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
> SHOULD repeat the same challenge value  = > in successive
> unicast responses to Agent Solicitations or in = Registration 
> > Replies to Requests that did not contain = valid MN-AAA or
> MN-FA  > authentication = extensions.  Note that each challenge
> returned to an MN MUST  > be previously = unused by that MN.
>
> Based on subsequent comments from Ahmad, maybe = we can make
> the requirement more generic here, and give a = specific
> example in Appendix E.  For here, how = about:
>
> 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.
>
[JB] Can we explicitly write "new = challenge" instead of "new storage"?
>
>
>
>  > It was decided that challenges sent = in unicast Agent
> Advertisements and sent  > in = Registration Reply messages
> should be treated same at the FA. For = this,  > the following
> text is proposed by Henrik and Pete:  > =
>  > (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.
>
> After that, we could add, "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."
>
[JB] I would think that "already stored" = is redundant here.
>
> -Pete
>
>

------_=_NextPart_001_01C3722F.B15D27CC-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 3 12:37:30 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 MAA20144 for ; Wed, 3 Sep 2003 12:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uad0-0001gM-23 for mip4-archive@odin.ietf.org; Wed, 03 Sep 2003 12:37:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83Gb5OU006460 for mip4-archive@odin.ietf.org; Wed, 3 Sep 2003 12:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uacz-0001fr-8r for mip4-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 12:37: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 MAA20120 for ; Wed, 3 Sep 2003 12:36:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uacx-0003eT-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 12:37:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uacw-0003eQ-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 12:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uacw-0001f5-LF; Wed, 03 Sep 2003 12:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uacd-0001e0-6G for mip4@optimus.ietf.org; Wed, 03 Sep 2003 12:36:43 -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 MAA20091 for ; Wed, 3 Sep 2003 12:36:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uacb-0003e2-00 for mip4@ietf.org; Wed, 03 Sep 2003 12:36:41 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19uaca-0003dK-00 for mip4@ietf.org; Wed, 03 Sep 2003 12:36:40 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h83GM3u06972; Wed, 3 Sep 2003 11:22:04 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h83GM2603964; Wed, 3 Sep 2003 11:22:02 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16214.5332.529227.224857@gargle.gargle.HOWL> Date: Wed, 3 Sep 2003 11:20:36 -0500 From: Pete McCann To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 In-Reply-To: <870397D7C140C84DB081B88396458DAF746B46@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746B46@zrc2c000.us.nortel.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 Hi, Jayshree, Jayshree Bharatia writes: [...] > [JB] Proposed text for section 2. > From: > The Challenge extension, illustrated in figure 1, is inserted in the Agent > Advertisements by the Foreign Agent, in order to communicate the latest > challenge value that can be used by the mobile node to compute an > authentication for its next registration request message. The challenge is > selected by the foreign agent to provide local assurance that the mobile > node is not replaying any earlier registration request. > > To: > The Challenge extension, illustrated in figure 1, is inserted in the Agent > Advertisements by the Foreign Agent, in order to communicate a previously > unused challenge value that can be used by the mobile node to compute an > authentication for its next registration request message. The challenge is > selected by the foreign agent to provide local assurance that the mobile > node is not replaying any earlier registration request. Ok, looks good. > > > In addition to this, Henrik proposed a new text for a new > > subsection 2.1. > > > > > > 2.1 Handling of Solicited Agent Advertisements > > > > > > When a foreign agent generates an Agent Advertisement in > > response to a > Router Solicitation [4], some additional > > considerations come into play. > According to the Mobile IP > > base specification [7], the resulting Agent > Advertisement > > may be either multicast or unicast. > > > > If the solicited Agent Advertisement is multicast, it MUST > > NOT generate a > new Challenge value and update its window > > of remembered advertised > Challenges. It must instead > > re-use the most recent of the CHALLENGE_WINDOW > > > Advertisement Challenge values. > > > > 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 > > ^ insert the word "it" > > > > > 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, 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.) > > > > I agree with this so far. > > > > > A foreign agent SHOULD NOT respond arbitrarily often to > > agent solicitations, > in order to limit processing load, > > especially in the face of hostile nodes > soliciting at a > > very high rate. The rate of solicited agent advertisement > > > responses SHOULD at most be 50 per second. > > > > I am not sure we need the last paragraph. Overload control, > > especially the choice of which solicitations to discard, is a > > tricky subject. I don't know that we will come to any > > agreement on a maximum rate (cf. previous discussions on the > > Mobile IP list regarding multicast agent advertisement rates). > > > > > > > The original proposal from Henrik was to mandate a > > challenge in a > Registration Reply. After few email > > exchanges, it was decided that the > current text in section > > 3.3 (RFC3012bis (version 05) ) is ok. In addition to > the > > current text, Henrik proposed the following text to be used > > as a > guidance/background: > > > > (section 3.3) > > > 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. The Foreign Agent could then > > > assume that the mobile node with high likelihood has received > > and can use > the multicast challenge. A mobile node MUST be > > prepared to use a multicast > challenge 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 or > > Agent > Advertisement. > > > > This is good, but it doesn't seem quite strong enough, i.e., > > we still have a SHOULD on the inclusion of the previously > > unused challenge. It seems to me we should require (with a > > MUST) the inclusion of a challenge in the registration reply > > if something like the condition above isn't met, and > > similarly should require (with a MUST) the inclusion of a > > challenge in responses to Agent Solicitations if the > > condition isn't met. This is the only way to guarantee > > progress on a link where advertisements may be lost and where > > there is a long interval between unsolicited advertisements. > > > > > [JB] This is the mechanism where the FA provides an unused challenge to the > MN so that the MN can use this challenge in the subsequent request. If > advertisements are lost or their interval is long enough, the MN can always > request a challenge by sending Agent Solicitation. But then we need to mandate that a previously unused challenge will appear in the solicited Agent Advertisement, unless an unsolicited advertisement with a challenge is sent immediately before or after. This is the only way to guarantee progress. How about this for a specific text proposal: The FA MUST include a previously unused challenge in each Registration Reply or solicited Agent Advertisement, unless an unsolicited multicast advertisement containing a previously unused challenge is sent immediately before or after (e.g., within 1 second of) the Reply or solicited Advertisement. The Foreign Agent could then assume that the mobile node with high likelihood has received and can use the multicast challenge. A mobile node MUST be prepared to use a multicast challenge 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 or Agent Advertisement. [Henrik, I also saw your text proposal on this, but I think it may be a bit too wordy.] > I would think that this > type of guideline adds more confusion. What do you think of the text above? > By the way, the current text in > section 3.3 is: "The Foreign Agent SHOULD include a new Mobile-Foreign > Challenge Extension in any Registration Reply, successful or not. " > > I like to see use of term "previously unused challenge" instead of "new". Makes sense. [...] > > I don't support the text changes above, although I may have > > proposed the principle of "repeating challenges." Perhaps we > > don't need to make any text changes in this section, but can > > confine the new text to the security considerations (see my > > proposal below). > > > > > [JB] I don't have any problem removing these changes. The proposed text does > what was intended and that is, allowing repetition of challenges when > authentication fails. Agreed. [...] > > Based on the subsequent discussion, I don't think we need the > > text changes above. See the security considerations: > > > > > [JB]OK > > > > The following text was proposed to be added in section 12. > > This is a > modified version of the text proposed by Henrik > > on the mailing list earlier. > > > > (section 12) > > > 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 > > SHOULD repeat the same challenge value > in successive > > unicast responses to Agent Solicitations or in Registration > > > Replies to Requests that did not contain valid MN-AAA or > > MN-FA > authentication extensions. Note that each challenge > > returned to an MN MUST > be previously unused by that MN. > > > > Based on subsequent comments from Ahmad, maybe we can make > > the requirement more generic here, and give a specific > > example in Appendix E. For here, how about: > > > > 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. > > > [JB] Can we explicitly write "new challenge" instead of "new storage"? Well, it is really the storage allocation that leads to a depletion of resources at the FA. I was trying to allow for super-smart implementations that perhaps could figure out some way to allocate new challenges without allocating new storage (perhaps some sort of embedded cookie mechanism). I thought this was the implementation flexibility that you and Ahmad were asking for. > > > It was decided that challenges sent in unicast Agent > > Advertisements and sent > in Registration Reply messages > > should be treated same at the FA. For this, > the following > > text is proposed by Henrik and Pete: > > > > (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. > > > > After that, we could add, "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." > > > [JB] I would think that "already stored" is redundant here. I think it is important to emphasize that the FA is not allocating additional storage. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 3 17:31:31 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 RAA09034 for ; Wed, 3 Sep 2003 17:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ufDY-00066e-2v for mip4-archive@odin.ietf.org; Wed, 03 Sep 2003 17:31:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83LV67N023460 for mip4-archive@odin.ietf.org; Wed, 3 Sep 2003 17:31:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ufDW-00066J-7r for mip4-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 17:31: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 RAA08994 for ; Wed, 3 Sep 2003 17:30:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ufDT-0002Pe-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 17:31:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ufDS-0002PX-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 17:31:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ufDS-00065j-Jw; Wed, 03 Sep 2003 17:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ufDF-00064U-8O for mip4@optimus.ietf.org; Wed, 03 Sep 2003 17:30: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 RAA08980 for ; Wed, 3 Sep 2003 17:30:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ufDC-0002Ot-00 for mip4@ietf.org; Wed, 03 Sep 2003 17:30:46 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19ufDB-0002OD-00 for mip4@ietf.org; Wed, 03 Sep 2003 17:30:45 -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 h83LU9F14633; Wed, 3 Sep 2003 16:30:10 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 3 Sep 2003 16:30:11 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B4C@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Pete McCann'" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Wed, 3 Sep 2003 16:30:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37262.8CE3E876" 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_01C37262.8CE3E876 Content-Type: text/plain Hello Pete, More responses inline... Thanks, Jayshree > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Wednesday, September 03, 2003 11:21 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > [...] > > > > > In addition to this, Henrik proposed a new text for a new > > > subsection 2.1. > > > > > > > > 2.1 Handling of Solicited Agent Advertisements > > > > > > > > When a foreign agent generates an Agent Advertisement in > > > response to a > Router Solicitation [4], some additional > > > considerations come into play. > According to the Mobile IP > > > base specification [7], the resulting Agent > Advertisement > > > may be either multicast or unicast. > > > > > If the solicited Agent Advertisement is multicast, it MUST > > > NOT generate a > new Challenge value and update its window > > > of remembered advertised > Challenges. It must instead > > > re-use the most recent of the CHALLENGE_WINDOW > > > > Advertisement Challenge values. > > > > > 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 > > > ^ insert the word "it" > > > > > > > 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, 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.) > > > > > > I agree with this so far. > > > > > > > A foreign agent SHOULD NOT respond arbitrarily often to > > > agent solicitations, > in order to limit processing load, > > > especially in the face of hostile nodes > soliciting at a > > > very high rate. The rate of solicited agent advertisement > > > > responses SHOULD at most be 50 per second. > > > > > > I am not sure we need the last paragraph. Overload control, > > > especially the choice of which solicitations to discard, is a > > > tricky subject. I don't know that we will come to any > > > agreement on a maximum rate (cf. previous discussions on the > > > Mobile IP list regarding multicast agent advertisement > rates). > > > > > > > > > The original proposal from Henrik was to mandate a > > > challenge in a > Registration Reply. After few email > > > exchanges, it was decided that the > current text in section > > > 3.3 (RFC3012bis (version 05) ) is ok. In addition to > the > > > current text, Henrik proposed the following text to be used > > > as a > guidance/background: > > > > > (section 3.3) > > > > 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. The Foreign Agent could then > > > > assume that the mobile node with high likelihood has received > > > and can use > the multicast challenge. A mobile node MUST be > > > prepared to use a multicast > challenge 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 or > > > Agent > Advertisement. > > > > > > This is good, but it doesn't seem quite strong enough, i.e., > > > we still have a SHOULD on the inclusion of the previously > > > unused challenge. It seems to me we should require (with a > > > MUST) the inclusion of a challenge in the registration reply > > > if something like the condition above isn't met, and > > > similarly should require (with a MUST) the inclusion of a > > > challenge in responses to Agent Solicitations if the > > > condition isn't met. This is the only way to guarantee > > > progress on a link where advertisements may be lost and where > > > there is a long interval between unsolicited > advertisements. > > > > > > > [JB] This is the mechanism where the FA provides an unused > challenge to the > MN so that the MN can use this challenge > in the subsequent request. If > advertisements are lost or > their interval is long enough, the MN can always > request a > challenge by sending Agent Solicitation. > > But then we need to mandate that a previously unused > challenge will appear in the solicited Agent Advertisement, > unless an unsolicited advertisement with a challenge is sent > immediately before or after. This is the only way to > guarantee progress. > > How about this for a specific text proposal: > > The FA MUST include a previously unused challenge in each > Registration Reply or solicited Agent Advertisement, unless an > unsolicited multicast advertisement containing a previously unused > challenge is sent immediately before or after (e.g., within 1 > second of) the Reply or solicited Advertisement. The Foreign Agent > could then assume that the mobile node with high likelihood has > received and can use the multicast challenge. A mobile > node MUST be > prepared to use a multicast challenge 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 or Agent Advertisement. > > [Henrik, I also saw your text proposal on this, but I think > it may be a bit too wordy.] > > > I would think that this > > type of guideline adds more confusion. > > What do you think of the text above? [JB] Not sure how much we can rely on the assumption of FA regarding receiving the challenge at the mobile node since there is no guarantee on the timing on when the MN may receive unsolicited multicast advertisement. [...] > > > > > > The following text was proposed to be added in section 12. > > > This is a > modified version of the text proposed by Henrik > > > on the mailing list earlier. > > > > > (section 12) > > > > 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 > > > SHOULD repeat the same challenge value > in successive > > > unicast responses to Agent Solicitations or in Registration > > > > Replies to Requests that did not contain valid MN-AAA or > > > MN-FA > authentication extensions. Note that each challenge > > > returned to an MN MUST > be previously unused by that MN. > > > > > Based on subsequent comments from Ahmad, maybe we can make > > > the requirement more generic here, and give a specific > > > example in Appendix E. For here, how about: > > > > > > 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. > > > > > [JB] Can we explicitly write "new challenge" instead of > "new storage"? > > Well, it is really the storage allocation that leads to a > depletion of resources at the FA. I was trying to allow for > super-smart implementations that perhaps could figure out > some way to allocate new challenges without allocating new > storage (perhaps some sort of embedded cookie mechanism). I > thought this was the implementation flexibility that you and > Ahmad were asking for. > [JB] I would think that this is specific to how implementation is done. For the purpose of this draft, we can avoid any implementation specific details. > > > > It was decided that challenges sent in unicast Agent > > > Advertisements and sent > in Registration Reply messages > > > should be treated same at the FA. For this, > the following > > > text is proposed by Henrik and Pete: > > > > > (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. > > > > > > After that, we could add, "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." > > > > [JB] I would think that "already stored" is redundant here. > > I think it is important to emphasize that the FA is not > allocating additional storage. [JB] My point is, if the challenge is "previously unused challenge", it is implicit that the storage is already existed. Anyway, this is implementation specific also. > > -Pete > > ------_=_NextPart_001_01C37262.8CE3E876 Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hello Pete,

More responses inline...

Thanks,
Jayshree

> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Wednesday, September 03, 2003 11:21 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
[...]
>
>  > >  > In addition to this, Henrik proposed a new text for a new
>  > > subsection 2.1.
>  > >  >
>  > >  > 2.1 Handling of Solicited Agent Advertisements
>  > >  >
>  > >  > When a foreign agent generates an Agent Advertisement in
>  > > response to a  > Router Solicitation [4], some additional
>  > > considerations come into play.  > According to the Mobile IP
>  > > base specification [7], the resulting Agent  > Advertisement
>  > > may be either multicast or unicast.  >
>  > >  > If the solicited Agent Advertisement is multicast, it MUST
>  > > NOT generate a  > new Challenge value and update its window
>  > > of remembered advertised  > Challenges. It must instead
>  > > re-use the most recent of the CHALLENGE_WINDOW  >
>  > > Advertisement Challenge values.  >
>  > >  > 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
>  > >   ^ insert the word "it"
>  > >
>  > >  > 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, 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.)
>  > >
>  > > I agree with this so far.
>  > >
>  > >  > A foreign agent SHOULD NOT respond arbitrarily often to
>  > > agent solicitations,  > in order to limit processing load,
>  > > especially in the face of hostile nodes  > soliciting at a
>  > > very high rate. The rate of solicited agent advertisement  >
>  > > responses SHOULD at most be 50 per second.
>  > >
>  > > I am not sure we need the last paragraph.  Overload control,
>  > > especially the choice of which solicitations to discard, is a
>  > > tricky subject.  I don't know that we will come to any
>  > > agreement on a maximum rate (cf. previous discussions on the
>  > > Mobile IP list regarding multicast agent advertisement
> rates).  > >
>  > >
>  > >  > The original proposal from Henrik was to mandate a
>  > > challenge in a  > Registration Reply. After few email
>  > > exchanges, it was decided that the  > current text in section
>  > > 3.3 (RFC3012bis (version 05) ) is ok. In addition to  > the
>  > > current text, Henrik proposed the following text to be used
>  > > as a  > guidance/background:  >
>  > >  > (section 3.3)
>  > >  > 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. The Foreign Agent could then  >
>  > > assume that the mobile node with high likelihood has received
>  > > and can use  > the multicast challenge. A mobile node MUST be
>  > > prepared to use a multicast  > challenge 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 or
>  > > Agent  > Advertisement.
>  > >
>  > > This is good, but it doesn't seem quite strong enough, i.e.,
>  > > we still have a SHOULD on the inclusion of the previously
>  > > unused challenge.  It seems to me we should require (with a
>  > > MUST) the inclusion of a challenge in the registration reply
>  > > if something like the condition above isn't met, and
>  > > similarly should require (with a MUST) the inclusion of a
>  > > challenge in responses to Agent Solicitations if the
>  > > condition isn't met.  This is the only way to guarantee
>  > > progress on a link where advertisements may be lost and where
>  > > there is a long interval between unsolicited
> advertisements.  > >
>  > >
>  > [JB] This is the mechanism where the FA provides an unused
> challenge to the  > MN so that the MN can use this challenge
> in the subsequent request. If  > advertisements are lost or
> their interval is long enough, the MN can always  > request a
> challenge by sending Agent Solicitation.
>
> But then we need to mandate that a previously unused
> challenge will appear in the solicited Agent Advertisement,
> unless an unsolicited advertisement with a challenge is sent
> immediately before or after. This is the only way to
> guarantee progress.
>
> How about this for a specific text proposal:
>
>    The FA MUST include a previously unused challenge in each
>    Registration Reply or solicited Agent Advertisement, unless an
>    unsolicited multicast advertisement containing a previously unused
>    challenge is sent immediately before or after (e.g., within 1
>    second of) the Reply or solicited Advertisement.  The Foreign Agent
>    could then assume that the mobile node with high likelihood has
>    received and can use the multicast challenge.  A mobile
> node MUST be
>    prepared to use a multicast challenge 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 or Agent Advertisement.
>
> [Henrik, I also saw your text proposal on this, but I think
> it may be a bit too wordy.]
>
>  > I would think that this
>  > type of guideline adds more confusion.
>
> What do you think of the text above?
[JB] Not sure how much we can rely on the assumption of FA regarding receiving the challenge at the mobile node since there is no guarantee on the timing on when the MN may receive unsolicited multicast advertisement.

[...]
>  >
>  > >  > The following text was proposed to be added in section 12.
>  > > This is a  > modified version of the text proposed by Henrik
>  > > on the mailing list earlier.  >
>  > >  > (section 12)
>  > >  > 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
>  > > SHOULD repeat the same challenge value  > in successive
>  > > unicast responses to Agent Solicitations or in Registration 
>  > > > Replies to Requests that did not contain valid MN-AAA or
>  > > MN-FA  > authentication extensions.  Note that each challenge
>  > > returned to an MN MUST  > be previously unused by that MN.  > >
>  > > Based on subsequent comments from Ahmad, maybe we can make
>  > > the requirement more generic here, and give a specific
>  > > example in Appendix E.  For here, how about:
>  > >
>  > > 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.
>  > >
>  > [JB] Can we explicitly write "new challenge" instead of
> "new storage"?
>
> Well, it is really the storage allocation that leads to a
> depletion of resources at the FA.  I was trying to allow for
> super-smart implementations that perhaps could figure out
> some way to allocate new challenges without allocating new
> storage (perhaps some sort of embedded cookie mechanism).  I
> thought this was the implementation flexibility that you and
> Ahmad were asking for.
>
[JB] I would think that this is specific to how implementation is done. For the purpose of this draft, we can avoid any implementation specific details.

 
>  > >  > It was decided that challenges sent in unicast Agent
>  > > Advertisements and sent  > in Registration Reply messages
>  > > should be treated same at the FA. For this,  > the following
>  > > text is proposed by Henrik and Pete:  >
>  > >  > (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.
>  > >
>  > > After that, we could add, "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."  > >
>  > [JB] I would think that "already stored" is redundant here.
>
> I think it is important to emphasize that the FA is not
> allocating additional storage.
[JB] My point is, if the challenge is "previously unused challenge", it is implicit that the storage is already existed. Anyway, this is implementation specific also.

>
> -Pete
>
>

------_=_NextPart_001_01C37262.8CE3E876-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 3 18:06: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 SAA11330 for ; Wed, 3 Sep 2003 18:06: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 19uflL-0007io-5L for mip4-archive@odin.ietf.org; Wed, 03 Sep 2003 18:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h83M63c5029676 for mip4-archive@odin.ietf.org; Wed, 3 Sep 2003 18:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uflL-0007iZ-15 for mip4-web-archive@optimus.ietf.org; Wed, 03 Sep 2003 18:06: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 SAA11272 for ; Wed, 3 Sep 2003 18:05:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uflI-0003G7-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 18:06:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uflH-0003G4-00 for mip4-web-archive@ietf.org; Wed, 03 Sep 2003 18:05:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uflJ-0007iK-Ng; Wed, 03 Sep 2003 18:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ufkm-0007hh-W3 for mip4@optimus.ietf.org; Wed, 03 Sep 2003 18:05: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 SAA11206 for ; Wed, 3 Sep 2003 18:05:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ufkk-0003Fd-00 for mip4@ietf.org; Wed, 03 Sep 2003 18:05:26 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19ufkj-0003FG-00 for mip4@ietf.org; Wed, 03 Sep 2003 18:05:25 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h83M4kC29721; Wed, 3 Sep 2003 17:04:46 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h83M4i604412; Wed, 3 Sep 2003 17:04:45 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16214.25893.835468.590383@gargle.gargle.HOWL> Date: Wed, 3 Sep 2003 17:03:17 -0500 From: Pete McCann To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 In-Reply-To: <870397D7C140C84DB081B88396458DAF746B4C@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746B4C@zrc2c000.us.nortel.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 Hi, Jayshree, Jayshree Bharatia writes: [...] > > > [JB] This is the mechanism where the FA provides an unused > > challenge to the > MN so that the MN can use this challenge > > in the subsequent request. If > advertisements are lost or > > their interval is long enough, the MN can always > request a > > challenge by sending Agent Solicitation. > > > > But then we need to mandate that a previously unused > > challenge will appear in the solicited Agent Advertisement, > > unless an unsolicited advertisement with a challenge is sent > > immediately before or after. This is the only way to > > guarantee progress. > > > > How about this for a specific text proposal: > > > > The FA MUST include a previously unused challenge in each > > Registration Reply or solicited Agent Advertisement, unless an > > unsolicited multicast advertisement containing a previously unused > > challenge is sent immediately before or after (e.g., within 1 > > second of) the Reply or solicited Advertisement. The Foreign Agent > > could then assume that the mobile node with high likelihood has > > received and can use the multicast challenge. A mobile > > node MUST be > > prepared to use a multicast challenge 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 or Agent Advertisement. > > > > [Henrik, I also saw your text proposal on this, but I think > > it may be a bit too wordy.] > > > > > I would think that this > > > type of guideline adds more confusion. > > > > What do you think of the text above? > [JB] Not sure how much we can rely on the assumption of FA regarding > receiving the challenge at the mobile node since there is no guarantee on > the timing on when the MN may receive unsolicited multicast advertisement. I would be fine if we deleted the one sentence "The Foreign Agent could then assume..." from the above (it has no normative value anyway). [...] > > > > 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. > > > > > > > [JB] Can we explicitly write "new challenge" instead of > > "new storage"? > > > > Well, it is really the storage allocation that leads to a > > depletion of resources at the FA. I was trying to allow for > > super-smart implementations that perhaps could figure out > > some way to allocate new challenges without allocating new > > storage (perhaps some sort of embedded cookie mechanism). I > > thought this was the implementation flexibility that you and > > Ahmad were asking for. > > > [JB] I would think that this is specific to how implementation is done. For > the purpose of this draft, we can avoid any implementation specific details. It might be ok to generate new challenges, as long as you don't invalidate old ones and don't allocate new storage (deplete resources). I was trying to state the requirement in as broad a fashion as possible so as not to restrict implementations unnecessarily. > > > > > It was decided that challenges sent in unicast Agent > > > > Advertisements and sent > in Registration Reply messages > > > > should be treated same at the FA. For this, > the following > > > > text is proposed by Henrik and Pete: > > > > > > (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. > > > > > > > > After that, we could add, "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." > > > > > [JB] I would think that "already stored" is redundant here. > > > > I think it is important to emphasize that the FA is not > > allocating additional storage. > [JB] My point is, if the challenge is "previously unused challenge", it is > implicit that the storage is already existed. Not necessarily - one possible interpretation of your suggested text is for a new "previously unused" challenge to be created. > Anyway, this is implementation specific also. Yes, as is all of Appendix E, which is an example of what kind of data structures/pseudocode might be used. Handing out an "already stored, previously unused" challenge is a way to meet the security requirements. If we change the text to say only "previously unused" then we open the door to the creation of new challenges, with the possibility of invalidating old ones given the data structure and pseudocode in Appendix E. For that reason, it is important to say explicitly that the "previously used" challenge is also "already stored." -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 04:09:53 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 EAA00072 for ; Thu, 4 Sep 2003 04:09:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19upBE-0001lV-Ad for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 04:09:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8489NQg006732 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 04:09:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19upB8-0001kM-Oi for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 04:09: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 EAA00013 for ; Thu, 4 Sep 2003 04:09:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19upB5-0000H8-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 04:09:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19upB4-0000H5-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 04:09:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19upAv-0001iI-0f; Thu, 04 Sep 2003 04:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19up9y-0001c9-N6 for mip4@optimus.ietf.org; Thu, 04 Sep 2003 04:08: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 EAA29907 for ; Thu, 4 Sep 2003 04:08:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19up9v-0000Dz-00 for mip4@ietf.org; Thu, 04 Sep 2003 04:08:03 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19up9u-0000Dl-00 for mip4@ietf.org; Thu, 04 Sep 2003 04:08:02 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h8487lK06926; Thu, 4 Sep 2003 10:07:47 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F56F34A.6080007@comnets.uni-bremen.de> Date: Thu, 04 Sep 2003 10:09:46 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jee J.Z." , mip4@ietf.org Subject: Re: [Mip4] accelerating smooth hand-over in regional tunnel References: <3F55AB7C.4070903@comnets.uni-bremen.de> <008a01c37236$b6d1a960$b7882090@ohm.york.ac.uk> In-Reply-To: <008a01c37236$b6d1a960$b7882090@ohm.york.ac.uk> Content-Type: multipart/alternative; boundary="------------080106050907010708080108" 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 is a multi-part message in MIME format. --------------080106050907010708080108 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hello Jee, in that sense would it be possible to connect two FAs between two hierarchies or even an FA with two GFAs (shared FA)? In the latter case, what GFA would the FA advertise in its advertisements? Best Regards niko Jee J.Z. wrote: >Hi Niko, > >I think this is a routing issue rathen than a Mobile IP issue. Direct >connection may accelerate packets redirection from the old FA to the new FA, >but registration process may not benefit from it. The architecture does not >have to be purely tree-like I think. > >Regards, >Jee > >----- Original Message ----- >From: "Niko A. Fikouras" >To: >Sent: Wednesday, September 03, 2003 9:51 AM >Subject: [Mip4] accelerating smooth hand-over in regional tunnel > > > > >>Hi all, >> >>I have been reading through the draft-ietf-mobileip-reg-tunnel-04.txt. I >>would like to know whether there has been any contemplation on enabling >>two plain low-level FAs (of the same or other hierarchy) to be directly >>connected. This would be a violation of hierarchical routing but may >>accelerate smooth hand-overs. Furthermore, this would not have to be a >>standard thing rather then only initiated by admins between FAs with >>lots of hand-offs between each other. Would that have any other protocol >>implications? >> >>have a nice day >>niko >> >> >>_______________________________________________ >>Mip4 mailing list >>Mip4@ietf.org >>https://www.ietf.org/mailman/listinfo/mip4 >> >> >> > > > > --------------080106050907010708080108 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Jee,

in that sense would it be possible to connect two FAs between two hierarchies or even an FA with two GFAs (shared FA)?
In the latter case, what GFA would the FA advertise in its advertisements?

Best Regards
niko

Jee J.Z. wrote:
Hi Niko,

I think this is a routing issue rathen than a Mobile IP issue. Direct
connection may accelerate packets redirection from the old FA to the new FA,
but registration process may not benefit from it. The architecture does not
have to be purely tree-like I think.

Regards,
Jee

----- Original Message -----
From: "Niko A. Fikouras" <niko@comnets.uni-bremen.de>
To: <mip4@ietf.org>
Sent: Wednesday, September 03, 2003 9:51 AM
Subject: [Mip4] accelerating smooth hand-over in regional tunnel


  
Hi all,

I have been reading through the draft-ietf-mobileip-reg-tunnel-04.txt. I
would like to know whether there has been any contemplation on enabling
two plain low-level FAs (of the same or other hierarchy) to be directly
connected. This would be a violation of hierarchical routing but may
accelerate smooth hand-overs. Furthermore, this would not have to be a
standard thing rather then only initiated by admins between FAs with
lots of hand-offs between each other. Would that have any other protocol
implications?

have a nice day
niko


_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4
--------------080106050907010708080108-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 09:57: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 JAA23111 for ; Thu, 4 Sep 2003 09:57: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 19uubf-00038M-Gr for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 09:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Dv35A012042 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 09:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uubf-000389-D4 for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 09:57: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 JAA23067 for ; Thu, 4 Sep 2003 09:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uubd-0003Lg-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 09:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uubc-0003Lb-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 09:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uubd-00037f-01; Thu, 04 Sep 2003 09: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 19uubV-00036w-Bh for mip4@optimus.ietf.org; Thu, 04 Sep 2003 09:56:53 -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 JAA23057 for ; Thu, 4 Sep 2003 09:56:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uubT-0003L9-00 for mip4@ietf.org; Thu, 04 Sep 2003 09:56:51 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19uubS-0003Jg-00 for mip4@ietf.org; Thu, 04 Sep 2003 09:56:50 -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 h84Du7C21459; Thu, 4 Sep 2003 08:56:07 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 08:56:07 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 08:56:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C372EC.48E369DC" 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_01C372EC.48E369DC Content-Type: text/plain Hi, Pete, The scenario I was concerned about does not use the bad-authenticator in its response and therefore it is no issue. I agree with your text below: > 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. With respect to the following text. I do not think that it is necessary. It is probably redandfant information. > 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. Regards, Ahmad ------_=_NextPart_001_01C372EC.48E369DC Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

The scenario I was concerned about does not use the bad-authenticator in its response and therefore it is no issue.
I agree with your text below:

>  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.

With respect to the following text. I do not think that it is necessary.
It is probably redandfant information.
>  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.

Regards,
Ahmad

------_=_NextPart_001_01C372EC.48E369DC-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 12:38: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 MAA06235 for ; Thu, 4 Sep 2003 12:38: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 19ux7V-00048S-13 for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 12:38:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Gc4WX015890 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 12:38:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux7U-00048D-Sq for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 12:38: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 MAA06221 for ; Thu, 4 Sep 2003 12:37:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ux7R-0007PQ-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 12:38:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ux7Q-0007PN-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 12:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux7Q-00047T-O1; Thu, 04 Sep 2003 12:38:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ux6l-0003xX-QD for mip4@optimus.ietf.org; Thu, 04 Sep 2003 12:37:20 -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 MAA06179 for ; Thu, 4 Sep 2003 12:37:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ux6k-0007Ox-00 for mip4@ietf.org; Thu, 04 Sep 2003 12:37:18 -0400 Received: from mail-efg1.york.ac.uk ([144.32.128.244]) by ietf-mx with esmtp (Exim 4.12) id 19ux6j-0007O4-00 for mip4@ietf.org; Thu, 04 Sep 2003 12:37:17 -0400 Received: from jz105 (jz105.ohm.york.ac.uk [144.32.136.183]) by mail-efg1.york.ac.uk (8.12.9/8.12.9) with SMTP id h84Gafdg025757; Thu, 4 Sep 2003 17:36:42 +0100 (BST) Message-ID: <00ea01c37303$249449e0$b7882090@ohm.york.ac.uk> From: "Jee J.Z." To: "Niko A. Fikouras" , "Mobile IP v4" References: <3F55AB7C.4070903@comnets.uni-bremen.de> <008a01c37236$b6d1a960$b7882090@ohm.york.ac.uk> <3F56F34A.6080007@comnets.uni-bremen.de> Subject: Re: [Mip4] accelerating smooth hand-over in regional tunnel Date: Thu, 4 Sep 2003 17:39:42 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E7_01C3730B.860C66A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-York-MailScanner: Found to be clean 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 is a multi-part message in MIME format. ------=_NextPart_000_00E7_01C3730B.860C66A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Niko, As far as I think, it is possible. TeleMIP proposes such a kind of = architecture. It uses multiple TMAs (similar role as GFA) to share the = network load. However, I am not sure of the benefit of producing more = cross connections than this. Otherwise it finally creats a mesh like = network, which may need much more information to choose a proper route = for Mobile IP messages. Regards, Jee ----- Original Message -----=20 From: Niko A. Fikouras=20 To: Jee J.Z. ; mip4@ietf.org=20 Sent: Thursday, September 04, 2003 9:09 AM Subject: Re: [Mip4] accelerating smooth hand-over in regional tunnel Hello Jee, in that sense would it be possible to connect two FAs between two = hierarchies or even an FA with two GFAs (shared FA)? In the latter case, what GFA would the FA advertise in its = advertisements? Best Regards niko Jee J.Z. wrote: Hi Niko, I think this is a routing issue rathen than a Mobile IP issue. Direct connection may accelerate packets redirection from the old FA to the new = FA, but registration process may not benefit from it. The architecture does = not have to be purely tree-like I think. Regards, Jee ----- Original Message ----- From: "Niko A. Fikouras" To: Sent: Wednesday, September 03, 2003 9:51 AM Subject: [Mip4] accelerating smooth hand-over in regional tunnel =20 Hi all, I have been reading through the draft-ietf-mobileip-reg-tunnel-04.txt. I would like to know whether there has been any contemplation on enabling two plain low-level FAs (of the same or other hierarchy) to be directly connected. This would be a violation of hierarchical routing but may accelerate smooth hand-overs. Furthermore, this would not have to be a standard thing rather then only initiated by admins between FAs with lots of hand-offs between each other. Would that have any other protocol implications? have a nice day niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 =20 =20 ------=_NextPart_000_00E7_01C3730B.860C66A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Niko,
 
As far as I think, it is = possible. TeleMIP proposes=20 such a kind of architecture. It uses multiple TMAs (similar role as GFA) = to=20 share the network load. However, I am not sure of the benefit of = producing more=20 cross connections than this. Otherwise it finally creats a mesh like = network,=20 which may need much more information to choose a proper route for Mobile = IP=20 messages.
 
Regards,
Jee
 
----- Original Message ----- =
Sent: Thursday, = September 04, 2003 9:09=20 AM
Subject: Re: [Mip4] = accelerating smooth=20 hand-over in regional tunnel

Hello Jee,

in that sense would it be possible to = connect=20 two FAs between two hierarchies or even an FA with two GFAs (shared = FA)?
In=20 the latter case, what GFA would the FA advertise in its=20 advertisements?

Best Regards
niko

Jee J.Z. wrote:
Hi Niko,

I think this is a routing issue rathen than a Mobile IP issue. Direct
connection may accelerate packets redirection from the old FA to the new =
FA,
but registration process may not benefit from it. The architecture does =
not
have to be purely tree-like I think.

Regards,
Jee

----- Original Message -----
From: "Niko A. Fikouras" <niko@comnets.uni-bremen.de=
>
To: <mip4@ietf.org>
Sent: Wednesday, September 03, 2003 9:51 AM
Subject: [Mip4] accelerating smooth hand-over in regional tunnel


  
Hi all,

I have been reading through the draft-ietf-mobileip-reg-tunnel-04.txt. I
would like to know whether there has been any contemplation on enabling
two plain low-level FAs (of the same or other hierarchy) to be directly
connected. This would be a violation of hierarchical routing but may
accelerate smooth hand-overs. Furthermore, this would not have to be a
standard thing rather then only initiated by admins between FAs with
lots of hand-offs between each other. Would that have any other protocol
implications?

have a nice day
niko


_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/=
mailman/listinfo/mip4
------=_NextPart_000_00E7_01C3730B.860C66A0-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 12:45: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 MAA06563 for ; Thu, 4 Sep 2003 12:45: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 19uxEF-0004X3-Jx for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 12:45:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Gj3vV017415 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 12:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uxEF-0004Wo-En for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 12:45: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 MAA06544 for ; Thu, 4 Sep 2003 12:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uxED-0007W8-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 12:45:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uxEC-0007W5-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 12:45:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uxED-0004Vo-NP; Thu, 04 Sep 2003 12:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uxDu-0004V6-Rq for mip4@optimus.ietf.org; Thu, 04 Sep 2003 12:44:42 -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 MAA06516 for ; Thu, 4 Sep 2003 12:44:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uxDt-0007Vj-00 for mip4@ietf.org; Thu, 04 Sep 2003 12:44:41 -0400 Received: from mail-efg1.york.ac.uk ([144.32.128.244]) by ietf-mx with esmtp (Exim 4.12) id 19uxDs-0007VA-00 for mip4@ietf.org; Thu, 04 Sep 2003 12:44:40 -0400 Received: from jz105 (jz105.ohm.york.ac.uk [144.32.136.183]) by mail-efg1.york.ac.uk (8.12.9/8.12.9) with SMTP id h84Gi5dg026689; Thu, 4 Sep 2003 17:44:05 +0100 (BST) Message-ID: <010201c37304$2cacee60$b7882090@ohm.york.ac.uk> From: "Jee J.Z." To: "Niko A. Fikouras" , "Mobile IP v4" References: <3F534CEE.4090000@comnets.uni-bremen.de> Subject: Re: [Mip4] regional registration draft Date: Thu, 4 Sep 2003 17:47:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-York-MailScanner: Found to be clean 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 Niko, I think this is for the MN to choose a closest anchor point to send a regional registration request next time. Cheers, Jee ----- Original Message ----- From: "Niko A. Fikouras" To: Sent: Monday, September 01, 2003 2:43 PM Subject: [Mip4] regional registration draft > Hi all, > > I have a question on the regional registrations draft > (draft-ietf-mobileip-reg-tunnel-07.txt). According to Appendix Section > "B.1. Registration with Home Agent" (p.32-33), a foreign agent may have > to include in its agent advertisements the addresses of all mobility > agents (RFAs, GFAs) in its hierarchy branch. I would like to know what > the reason is behind this action, because considering a MIP hierarchy > with several levels then agent advertisements may acquire a significant > size. Moreover, considering that foreign agents may have to increase > their advertisement period in order to accelrate MIP hand-offs, then the > transmission of agent advertisements of some size may result in a > significant overhead with an effect to network efficiency. > > Thanks in advance > niko > > > _______________________________________________ > 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 Sep 4 13:24: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 NAA08809 for ; Thu, 4 Sep 2003 13:24: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 19uxpy-000613-Gi for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 13:24:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84HO24m023124 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 13:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uxpy-00060t-Bw for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 13:24: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 NAA08764 for ; Thu, 4 Sep 2003 13:23:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uxpw-0000Vn-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 13:24:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uxpv-0000Vk-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 13: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 19uxpw-00060Z-MI; Thu, 04 Sep 2003 13: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 19uxoz-0005xC-LS for mip4@optimus.ietf.org; Thu, 04 Sep 2003 13:23: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 NAA08658 for ; Thu, 4 Sep 2003 13:22:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uxox-0000U2-00 for mip4@ietf.org; Thu, 04 Sep 2003 13:22:59 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19uxow-0000T3-00 for mip4@ietf.org; Thu, 04 Sep 2003 13:22:58 -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 h84HMLC00623; Thu, 4 Sep 2003 12:22:21 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 12:22:21 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" , "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 12:22:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37309.1923FE38" 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_01C37309.1923FE38 Content-Type: text/plain Hi, Pete, Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Wednesday, September 03, 2003 5:03 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > > > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT INVALIDATING the challenge received in RRQ, why not sending that challenge (still valid) back in RRP. Is there a problem with that? Ahmad > > -Pete ------_=_NextPart_001_01C37309.1923FE38 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Wednesday, September 03, 2003 5:03 = PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for = Issue2-Change5
>
>  > >  > >
>  > >  > > After that, we = could add, "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 we are trying to prevent such DOS attack by NOT = INVALIDATING the challenge received in RRQ, why not sending that = challenge (still valid) back in RRP. Is there a problem with = that?

Ahmad
 
>
> -Pete

------_=_NextPart_001_01C37309.1923FE38-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 13:45: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 NAA09806 for ; Thu, 4 Sep 2003 13:45: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 19uyAJ-0006rt-RK for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 13:45:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Hj3FK026395 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 13:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyAJ-0006re-LG for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 13:45: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 NAA09777 for ; Thu, 4 Sep 2003 13:44:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uyAH-0000sP-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 13:45:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uyAG-0000sM-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 13:45:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyAH-0006r4-6P; Thu, 04 Sep 2003 13:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uy9g-0006pR-Ih for mip4@optimus.ietf.org; Thu, 04 Sep 2003 13:44:24 -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 NAA09750 for ; Thu, 4 Sep 2003 13:44:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uy9e-0000rP-00 for mip4@ietf.org; Thu, 04 Sep 2003 13:44:22 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 19uy9d-0000q5-00 for mip4@ietf.org; Thu, 04 Sep 2003 13:44:21 -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 h84Hhmsu010997; Thu, 4 Sep 2003 19:43:48 +0200 Date: Thu, 4 Sep 2003 19:43:47 +0200 From: Henrik Levkowetz To: "'mip4@ietf.org'" Cc: "Ahmad Muhanna" , "'Pete McCann'" , "Jayshree Bharatia" Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Message-Id: <20030904194347.1f366e5c.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.(g67?i_sTOAK8O" X-Spam-Status: No, hits=-5.0 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT,REFERENCES,REPLY_WITH_QUOTES version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) 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: , --=.(g67?i_sTOAK8O Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thursday, 4 Sep 2003, Ahmad wrote: > Hi, Pete, ... > > > > > > > > > > > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT INVALIDATING the > challenge received in RRQ, why not sending that challenge (still valid) back > in RRP. Is there a problem with that? I guess there is a rather large conceptual difference in expressing that a challenge is copied from a received request, and to say that it is taken from an internally generated, stored value. In the first case, if this wording is followed by the implementers, it may open up for buffer overrun attacks, which would be unfortunate. (There may be other issues with this too, but I'll leave that to Pete) Henrik --=.(g67?i_sTOAK8O Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/V3nUeVhrtTJkXCMRAgF1AJ9776P2WGCFRjyJYbc4gvCiUVU+5QCfYmp0 /xh2kQ2q4k5Ic15AJfJDGM8= =TSEu -----END PGP SIGNATURE----- --=.(g67?i_sTOAK8O-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 13: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 NAA09881 for ; Thu, 4 Sep 2003 13: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 19uyBG-0006w9-Vq for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 13:46:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Hk2Do026659 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 13: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 19uyBG-0006vt-Rc for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 13:46: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 NAA09858 for ; Thu, 4 Sep 2003 13:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uyBE-0000tb-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 13:46:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uyBD-0000tX-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 13:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyBF-0006ui-4p; Thu, 04 Sep 2003 13: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 19uyAI-0006rQ-Fo for mip4@optimus.ietf.org; Thu, 04 Sep 2003 13:45: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 NAA09774 for ; Thu, 4 Sep 2003 13:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uyAG-0000sC-00 for mip4@ietf.org; Thu, 04 Sep 2003 13:45:00 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19uyAF-0000rd-00 for mip4@ietf.org; Thu, 04 Sep 2003 13:44:59 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h84Hfau10213; Thu, 4 Sep 2003 12:41:36 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h84HfWf11533; Thu, 4 Sep 2003 12:41:35 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16215.31050.24561.640115@gargle.gargle.HOWL> Date: Thu, 4 Sep 2003 12:41:30 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Ahmad Muhanna writes: > Hi, Pete, > > The scenario I was concerned about does not use the bad-authenticator in its > response and therefore it is no issue. > I agree with your text below: > > > 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. > > With respect to the following text. I do not think that it is necessary. > It is probably redandfant information. > > 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. Are you saying that if the FA doesn't invalidate previously unused challenges, then it will not allocate more storage? That doesn't necessarily follow. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 13:52: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 NAA10315 for ; Thu, 4 Sep 2003 13:52: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 19uyH5-00076g-7k for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 13:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Hq38c027312 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 13:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyH4-00076R-Vk for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 13:52: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 NAA10282 for ; Thu, 4 Sep 2003 13:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uyH2-00013H-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 13:52:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uyH1-00013D-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 13:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyH3-00074m-8w; Thu, 04 Sep 2003 13:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyGS-000746-Lt for mip4@optimus.ietf.org; Thu, 04 Sep 2003 13:51:24 -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 NAA10233 for ; Thu, 4 Sep 2003 13:51:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uyGN-00011x-00 for mip4@ietf.org; Thu, 04 Sep 2003 13:51:19 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19uyGM-00010l-00 for mip4@ietf.org; Thu, 04 Sep 2003 13:51:18 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h84HnQu15459; Thu, 4 Sep 2003 12:49:27 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h84HnOf27679; Thu, 4 Sep 2003 12:49:25 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16215.31522.510561.864356@gargle.gargle.HOWL> Date: Thu, 4 Sep 2003 12:49:22 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Ahmad Muhanna writes: > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Wednesday, September 03, 2003 5:03 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > > > > > > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT INVALIDATING the > challenge received in RRQ, why not sending that challenge (still valid) back > in RRP. Is there a problem with that? That behavior is allowed by the text above, assuming that the challenge received in the RRQ is stored in the data structures given in Appendix E. If not, then what you describe would not be ok, because you would be forcing the FA to use a challenge that it didn't necessarily generate. My view is that it should also be legal to return any of the other previously unused challenges from the data structure. This allows for maximum implementation flexibility. The DoS attack is prevented as long as you don't invalidate existing previously unused challenges. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 14:01:35 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 OAA10844 for ; Thu, 4 Sep 2003 14:01:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyPt-0007OH-L0 for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 14:01:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84I19bI028397 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 14:01:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyPq-0007Mh-43 for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 14:01: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 OAA10784 for ; Thu, 4 Sep 2003 14:00:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uyPn-0001Dn-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 14:01:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19uyPl-0001Di-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 14:01:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyPn-0007M5-9k; Thu, 04 Sep 2003 14:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uyPI-0007KN-QF for mip4@optimus.ietf.org; Thu, 04 Sep 2003 14:00:32 -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 OAA10709 for ; Thu, 4 Sep 2003 14:00:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uyP2-0001Bj-00 for mip4@ietf.org; Thu, 04 Sep 2003 14:00:16 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19uyP1-0001An-00 for mip4@ietf.org; Thu, 04 Sep 2003 14:00:15 -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 h84HxcC08619; Thu, 4 Sep 2003 12:59:38 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 12:59:38 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B53@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Pete McCann'" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 12:59:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3730E.4EC0B798" 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_01C3730E.4EC0B798 Content-Type: text/plain Hi Pete, Please see the response inline. Thanks, Jayshree > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Wednesday, September 03, 2003 5:03 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Jayshree, > > Jayshree Bharatia writes: > [...] > > > > [JB] This is the mechanism where the FA provides an unused > > > challenge to the > MN so that the MN can use this challenge > > > in the subsequent request. If > advertisements are lost or > > > their interval is long enough, the MN can always > request a > > > challenge by sending Agent Solicitation. > > > > > > But then we need to mandate that a previously unused > > > challenge will appear in the solicited Agent Advertisement, > > > unless an unsolicited advertisement with a challenge is sent > > > immediately before or after. This is the only way to > > > guarantee progress. > > > > > > How about this for a specific text proposal: > > > > > > The FA MUST include a previously unused challenge in each > > > Registration Reply or solicited Agent Advertisement, unless an > > > unsolicited multicast advertisement containing a > previously unused > > > challenge is sent immediately before or after (e.g., within 1 > > > second of) the Reply or solicited Advertisement. The > Foreign Agent > > > could then assume that the mobile node with high > likelihood has > > > received and can use the multicast challenge. A mobile > > > node MUST be > > > prepared to use a multicast challenge 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 or Agent Advertisement. > > > > > > [Henrik, I also saw your text proposal on this, but I think > > > it may be a bit too wordy.] > > > > > > > I would think that this > > > > type of guideline adds more confusion. > > > > > > What do you think of the text above? > > [JB] Not sure how much we can rely on the assumption of FA > regarding > receiving the challenge at the mobile node since > there is no guarantee on > the timing on when the MN may > receive unsolicited multicast advertisement. > > I would be fine if we deleted the one sentence "The Foreign > Agent could then assume..." from the above (it has no > normative value anyway). > [JB] I rather have just "MUST" instead of "SHOULD" in the current text without any further conditional text if it solves all your concerns. [...] > > > > > > > It was decided that challenges sent in unicast Agent > > > > > Advertisements and sent > in Registration Reply messages > > > > > should be treated same at the FA. For this, > the > following > > > > > text is proposed by Henrik and Pete: > > > > > > > (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. > > > > > > > > > > After that, we could add, "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." > > > > > > [JB] I would think that "already stored" is redundant > here. > > > > > I think it is important to emphasize that the FA is not > > > allocating additional storage. > > [JB] My point is, if the challenge is "previously unused > challenge", it is > implicit that the storage is already existed. > > Not necessarily - one possible interpretation of your > suggested text is for a new "previously unused" challenge to > be created. > [JB] In the current context, I would think that repeating the challenge (used in the Registration Request which failed authentication) is more appropriate since this challenge is still "previously unused challenge". Hence, it is safe to assume that storage already exists in this case. I think we need to clarify "repetition of challenge" more clearly in the proposed text. > > Anyway, this is implementation specific also. > > Yes, as is all of Appendix E, which is an example of what > kind of data structures/pseudocode might be used. Handing > out an "already stored, previously unused" challenge is a way > to meet the security requirements. If we change the text to > say only "previously unused" then we open the door to the > creation of new challenges, with the possibility of > invalidating old ones given the data structure and pseudocode > in Appendix E. For that reason, it is important to say > explicitly that the "previously used" challenge is also > "already stored." > > -Pete > > ------_=_NextPart_001_01C3730E.4EC0B798 Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi Pete,

Please see the response inline.

Thanks,
Jayshree

> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Wednesday, September 03, 2003 5:03 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
>
> Hi, Jayshree,
>
> Jayshree Bharatia writes:
> [...]
>  > >  > [JB] This is the mechanism where the FA provides an unused
>  > > challenge to the  > MN so that the MN can use this challenge
>  > > in the subsequent request. If  > advertisements are lost or
>  > > their interval is long enough, the MN can always  > request a
>  > > challenge by sending Agent Solicitation.
>  > >
>  > > But then we need to mandate that a previously unused
>  > > challenge will appear in the solicited Agent Advertisement,
>  > > unless an unsolicited advertisement with a challenge is sent
>  > > immediately before or after. This is the only way to
>  > > guarantee progress.
>  > >
>  > > How about this for a specific text proposal:
>  > >
>  > >    The FA MUST include a previously unused challenge in each
>  > >    Registration Reply or solicited Agent Advertisement, unless an
>  > >    unsolicited multicast advertisement containing a
> previously unused
>  > >    challenge is sent immediately before or after (e.g., within 1
>  > >    second of) the Reply or solicited Advertisement.  The
> Foreign Agent
>  > >    could then assume that the mobile node with high
> likelihood has
>  > >    received and can use the multicast challenge.  A mobile
>  > > node MUST be
>  > >    prepared to use a multicast challenge 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 or Agent Advertisement.
>  > >
>  > > [Henrik, I also saw your text proposal on this, but I think
>  > > it may be a bit too wordy.]
>  > >
>  > >  > I would think that this
>  > >  > type of guideline adds more confusion.
>  > >
>  > > What do you think of the text above?
>  > [JB] Not sure how much we can rely on the assumption of FA
> regarding  > receiving the challenge at the mobile node since
> there is no guarantee on  > the timing on when the MN may
> receive unsolicited multicast advertisement.
>
> I would be fine if we deleted the one sentence "The Foreign
> Agent could then assume..." from the above (it has no
> normative value anyway).
>
[JB] I rather have just "MUST" instead of "SHOULD" in the current text without any further conditional text if it solves all your concerns.

[...]
>
>  > >  > >  > It was decided that challenges sent in unicast Agent
>  > >  > > Advertisements and sent  > in Registration Reply messages
>  > >  > > should be treated same at the FA. For this,  > the
> following
>  > >  > > text is proposed by Henrik and Pete:  >
>  > >  > >  > (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.
>  > >  > >
>  > >  > > After that, we could add, "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."  > >
>  > >  > [JB] I would think that "already stored" is redundant
> here.  > >
>  > > I think it is important to emphasize that the FA is not
>  > > allocating additional storage.
>  > [JB] My point is, if the challenge is "previously unused
> challenge", it is  > implicit that the storage is already existed.
>
> Not necessarily - one possible interpretation of your
> suggested text is for a new "previously unused" challenge to
> be created.
>
[JB] In the current context, I would think that repeating the challenge (used in the Registration Request which failed authentication) is more appropriate since this challenge is still "previously unused challenge". Hence, it is safe to assume that storage already exists in this case. I think we need to clarify "repetition of challenge" more clearly in the proposed text.

>  > Anyway, this is implementation specific also.
>
> Yes, as is all of Appendix E, which is an example of what
> kind of data structures/pseudocode might be used.  Handing
> out an "already stored, previously unused" challenge is a way
> to meet the security requirements.  If we change the text to
> say only "previously unused" then we open the door to the
> creation of new challenges, with the possibility of
> invalidating old ones given the data structure and pseudocode
> in Appendix E.  For that reason, it is important to say
> explicitly that the "previously used" challenge is also
> "already stored."
>
> -Pete
>
>

------_=_NextPart_001_01C3730E.4EC0B798-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 15:54: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 PAA18866 for ; Thu, 4 Sep 2003 15:54: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 19v0B9-0003f9-VN for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 15:54:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Js3rk014073 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 15:54:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v0B9-0003eu-Q8 for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 15:54: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 PAA18848 for ; Thu, 4 Sep 2003 15:53:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v0B8-0003aL-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 15:54:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v0B7-0003aI-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 15:54:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v0B7-0003eO-NA; Thu, 04 Sep 2003 15:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v0AU-0003dZ-4L for mip4@optimus.ietf.org; Thu, 04 Sep 2003 15:53:22 -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 PAA18835 for ; Thu, 4 Sep 2003 15:53:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v0AS-0003Zw-00 for mip4@ietf.org; Thu, 04 Sep 2003 15:53:20 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19v0AR-0003ZY-00 for mip4@ietf.org; Thu, 04 Sep 2003 15:53:19 -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.0/Switch-2.2.0) with ESMTP id h84JYlJ24424; Thu, 4 Sep 2003 14:34:47 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h84JYjf16866; Thu, 4 Sep 2003 14:34:46 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16215.37842.963561.771624@gargle.gargle.HOWL> Date: Thu, 4 Sep 2003 14:34:42 -0500 From: Pete McCann To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 In-Reply-To: <870397D7C140C84DB081B88396458DAF746B53@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746B53@zrc2c000.us.nortel.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 Hi, Jayshree, Jayshree Bharatia writes: > > I would be fine if we deleted the one sentence "The Foreign > > Agent could then assume..." from the above (it has no > > normative value anyway). > > > [JB] I rather have just "MUST" instead of "SHOULD" in the current text > without any further conditional text if it solves all your concerns. Are you saying to include a challenge in every registration reply or agent advertisement? Well, that would be ok with me, but we got pushback from Charlie on this. I don't want to put words in his mouth, so go back and re-read his posts from the archive. I think he felt that an always MUST was too strong, as there were conditions where it could be left out. We were trying to pin down those conditions, which I think my suggested text does. > > > > I think it is important to emphasize that the FA is not > > > > allocating additional storage. > > > [JB] My point is, if the challenge is "previously unused > > challenge", it is > implicit that the storage is already existed. > > > > Not necessarily - one possible interpretation of your > > suggested text is for a new "previously unused" challenge to > > be created. > > > [JB] In the current context, I would think that repeating the challenge > (used in the Registration Request which failed authentication) is more > appropriate since this challenge is still "previously unused challenge". > Hence, it is safe to assume that storage already exists in this case. I > think we need to clarify "repetition of challenge" more clearly in the > proposed text. There is no way to guarantee that the challenge in the registration request has anything to do with the stored state at the FA, unless your clarification includes checking it against that stored state. And why would you restrict the FA from sending other challenges in the stored state, as long as they are previously unused? Doesn't that restrict implementation choice? > > > Anyway, this is implementation specific also. > > > > Yes, as is all of Appendix E, which is an example of what > > kind of data structures/pseudocode might be used. Handing > > out an "already stored, previously unused" challenge is a way > > to meet the security requirements. If we change the text to > > say only "previously unused" then we open the door to the > > creation of new challenges, with the possibility of > > invalidating old ones given the data structure and pseudocode > > in Appendix E. For that reason, it is important to say > > explicitly that the "previously used" challenge is also > > "already stored." > > > > -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 16:22: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 QAA20165 for ; Thu, 4 Sep 2003 16:22: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 19v0cE-0004nw-UQ for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 16:22:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84KM2Pl018462 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 16:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v0cE-0004nf-3C for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 16:22: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 QAA20140 for ; Thu, 4 Sep 2003 16:21:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v0cC-00042K-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 16:22:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v0cB-00042H-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 16:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v0cC-0004mm-Tl; Thu, 04 Sep 2003 16: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 19v0bU-0004mD-5Z for mip4@optimus.ietf.org; Thu, 04 Sep 2003 16:21:16 -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 QAA20128 for ; Thu, 4 Sep 2003 16:21:09 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v0bS-00041n-00 for mip4@ietf.org; Thu, 04 Sep 2003 16:21:14 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19v0bQ-00041k-00 for mip4@ietf.org; Thu, 04 Sep 2003 16:21:13 -0400 Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h84KLCG26356 for ; Thu, 4 Sep 2003 15:21:12 -0500 (CDT) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 4 Sep 2003 15:21:11 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 4 Sep 2003 13:21:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 4 Sep 2003 15:21:10 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB671@daebe007.americas.nokia.com> Thread-Topic: [mobile-ip] Last Call: 'AAA NAI for Mobile IPv4 Extension' to Proposed Standard Thread-Index: AcNyKhKJxOPhf4iXSTqu/H9vfDUzKwA98XEQ To: X-OriginalArrivalTime: 04 Sep 2003 20:21:10.0771 (UTC) FILETIME=[14922430:01C37322] Content-Transfer-Encoding: quoted-printable Subject: [Mip4] FW: [mobile-ip] Last Call: 'AAA NAI for Mobile IPv4 Extension' to Proposed Standard 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 FYI, -----Original Message----- From: ext The IESG [mailto:iesg-secretary@ietf.org] Sent: 03 September, 2003 09:39 AM To: IETF-Announce=20 Cc: mobile-ip@sunroof.eng.sun.com Subject: [mobile-ip] Last Call: 'AAA NAI for Mobile IPv4 Extension' to Proposed Standard=20 The IESG has received a request from the IP Routing for Wireless/Mobile=20 Hosts WG to consider 'AAA NAI for Mobile IPv4 Extension'=20 as a Proposed Standard.=20 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-09-17. = =20 File(s) can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mobileip-aaa-nai-06.txt _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 16:58: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 QAA21846 for ; Thu, 4 Sep 2003 16:58: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 19v1B5-0006KA-5I for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 16:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Kw3Nq024303 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 16:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1B4-0006Jr-Vn for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 16:58: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 QAA21820 for ; Thu, 4 Sep 2003 16:57:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v1B2-0004bX-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 16:58:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v1B2-0004bU-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 16:58:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1B2-0006JW-Gb; Thu, 04 Sep 2003 16:58:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1A5-0006IT-FA for mip4@optimus.ietf.org; Thu, 04 Sep 2003 16:57: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 QAA21772 for ; Thu, 4 Sep 2003 16:56:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v1A3-0004aR-00 for mip4@ietf.org; Thu, 04 Sep 2003 16:56:59 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19v1A1-0004Zn-00 for mip4@ietf.org; Thu, 04 Sep 2003 16:56:58 -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 h84KuMC24641; Thu, 4 Sep 2003 15:56:22 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 15:56:23 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 15:56:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37326.DB906C14" 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_01C37326.DB906C14 Content-Type: text/plain Hi, Pete, Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Thursday, September 04, 2003 12:42 PM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > Hi, Pete, > > > > The scenario I was concerned about does not use the > bad-authenticator in its > response and therefore it is no > issue. > I agree with your text below: > > > > 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. > > > With respect to the following text. I do not think that it > is necessary. > It is probably redandfant information. > > > 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. > > Are you saying that if the FA doesn't invalidate previously > unused challenges, then it will not allocate more storage? > That doesn't necessarily follow. Then, can you elaborate more on how this does not necessarily follow. > > -Pete > > > ------_=_NextPart_001_01C37326.DB906C14 Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Thursday, September 04, 2003 12:42 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > Hi, Pete,
>  >
>  > The scenario I was concerned about does not use the
> bad-authenticator in its  > response and therefore it is no
> issue.  > I agree with your text below:  >
>  > >  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.  >
>  > With respect to the following text. I do not think that it
> is necessary.  > It is probably redandfant information.  > > 
> 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.
>
> Are you saying that if the FA doesn't invalidate previously
> unused challenges, then it will not allocate more storage? 
> That doesn't necessarily follow.

Then, can you elaborate more on how this does not necessarily follow.
>
> -Pete
>
>
>

------_=_NextPart_001_01C37326.DB906C14-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 17:02:56 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 RAA22270 for ; Thu, 4 Sep 2003 17:02:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1FQ-0006dc-M1 for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 17:02:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84L2WbM025510 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 17:02:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1FQ-0006dN-Hc for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 17:02:32 -0400 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 RAA22254 for ; Thu, 4 Sep 2003 17:02: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 19v1Ew-0006bp-6C; Thu, 04 Sep 2003 17:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1Es-0006b7-24 for mip4@optimus.ietf.org; Thu, 04 Sep 2003 17:01:58 -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 RAA22196 for ; Thu, 4 Sep 2003 17:01:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v1Ep-0004j0-00 for mip4@ietf.org; Thu, 04 Sep 2003 17:01:55 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19v1Eo-0004iE-00 for mip4@ietf.org; Thu, 04 Sep 2003 17:01:54 -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 h84L0qC03490; Thu, 4 Sep 2003 16:00:52 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 16:00:53 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Henrik Levkowetz'" , "'mip4@ietf.org'" Cc: "'Pete McCann'" , "Jayshree Bharatia" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 16:00:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37327.9021042C" 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_01C37327.9021042C Content-Type: text/plain > > > On Thursday, 4 Sep 2003, Ahmad wrote: > > > Hi, Pete, > ... > > > > > > > > > > > > > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT INVALIDATING the > > challenge received in RRQ, why not sending that challenge (still > > valid) back in RRP. Is there a problem with that? > > I guess there is a rather large conceptual difference in > expressing that a challenge is copied from a received > request, and to say that it is taken from an internally > generated, stored value. In the first case, if this wording > is followed by the implementers, it may open up for buffer > overrun attacks, which would be unfortunate. > > (There may be other issues with this too, but I'll leave that to Pete) > I agree. Since we are talking about MN-AAA authentication RRQ; challenge is verified later. > Henrik > ------_=_NextPart_001_01C37327.9021042C Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

>
>
> On Thursday,  4 Sep 2003, Ahmad wrote:
>
> > Hi, Pete,
> ...
> > >  > >  > >
> > >  > >  > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT INVALIDATING the
> > challenge received in RRQ, why not sending that challenge (still
> > valid) back in RRP. Is there a problem with that?
>
> I guess there is a rather large conceptual difference in
> expressing that a challenge is copied from a received
> request, and to say that it is taken from an internally
> generated, stored value. In the first case, if this wording
> is followed by the implementers, it may open up for buffer
> overrun attacks, which would be unfortunate.
>
> (There may be other issues with this too, but I'll leave that to Pete)
>

I agree. Since we are talking about MN-AAA authentication RRQ; challenge is verified later.

>       Henrik
>

------_=_NextPart_001_01C37327.9021042C-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 17:04: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 RAA22381 for ; Thu, 4 Sep 2003 17:04: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 19v1Gr-0006ld-Oy for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 17:04:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84L41mK026007 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 17:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1Gr-0006lO-Kk for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 17:04: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 RAA22341 for ; Thu, 4 Sep 2003 17:03:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v1Gp-0004lG-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 17:03:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v1Go-0004lD-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 17:03:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1Gq-0006kC-GN; Thu, 04 Sep 2003 17:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1GR-0006hR-Ou for mip4@optimus.ietf.org; Thu, 04 Sep 2003 17:03: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 RAA22329 for ; Thu, 4 Sep 2003 17:03:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v1GP-0004kt-00 for mip4@ietf.org; Thu, 04 Sep 2003 17:03:33 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19v1GO-0004kA-00 for mip4@ietf.org; Thu, 04 Sep 2003 17:03:32 -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 h84L2vC03792; Thu, 4 Sep 2003 16:02:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 16:02:58 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 16:02:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37327.DA300FCC" 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_01C37327.DA300FCC Content-Type: text/plain Hi, Pete, Regards, Ahmad > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Wednesday, September 03, 2003 5:03 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: 'mip4@ietf.org' > > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > > > > > > > > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT > INVALIDATING the > challenge received in RRQ, why not > sending that challenge (still valid) back > in RRP. Is there > a problem with that? > > That behavior is allowed by the text above, assuming that the > challenge received in the RRQ is stored in the data > structures given in Appendix E. If not, then what you > describe would not be ok, because you would be forcing the FA > to use a challenge that it didn't necessarily generate. > Is there any scenario that we may be missing and FA may no longer having a valid unused challenges for a certain MN? > My view is that it should also be legal to return any of the > other previously unused challenges from the data structure. > This allows for maximum implementation flexibility. The DoS > attack is prevented as long as you don't invalidate existing > previously unused challenges. > > -Pete > > ------_=_NextPart_001_01C37327.DA300FCC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

Regards,
Ahmad


>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > > -----Original = Message-----
>  > > From: Pete McCann [mailto:mccap@lucent.com]
>  > > Sent: Wednesday, September 03, = 2003 5:03 PM
>  > > To: Bharatia, Jayshree = [RICH1:2H13:EXCH]
>  > > Cc: 'mip4@ietf.org'
>  > > Subject: RE: [Mip4] RFC3012bis: = Proposal for Issue2-Change5  > >
>  > >  > >  > > =
>  > >  > >  > > = After that, we could add, "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 we are trying to prevent such DOS = attack by NOT
> INVALIDATING the  > challenge received = in RRQ, why not
> sending that challenge (still valid) back  = > in RRP. Is there
> a problem with that?
>
> That behavior is allowed by the text above, = assuming that the
> challenge received in the RRQ is stored in the = data
> structures given in Appendix E.  If not, = then what you
> describe would not be ok, because you would be = forcing the FA
> to use a challenge that it didn't necessarily = generate.
>

Is there any scenario that we may be missing and FA = may no longer having a valid unused challenges for a certain MN?

> My view is that it should also be legal to = return any of the
> other previously unused challenges from the = data structure. 
> This allows for maximum implementation = flexibility.  The DoS
> attack is prevented as long as you don't = invalidate existing
> previously unused challenges.
>
> -Pete
>
>

------_=_NextPart_001_01C37327.DA300FCC-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 17:05: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 RAA22464 for ; Thu, 4 Sep 2003 17:05: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 19v1Hr-0006o6-Bc for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 17:05:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84L53eh026160 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 17: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 19v1Hr-0006nr-7V for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 17:05: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 RAA22448 for ; Thu, 4 Sep 2003 17:04:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v1Ho-0004lt-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 17:05:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v1Ho-0004lq-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 17:05:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v1Hp-0006mU-WA; Thu, 04 Sep 2003 17: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 19v1HO-0006lz-3Z for mip4@optimus.ietf.org; Thu, 04 Sep 2003 17:04:34 -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 RAA22397 for ; Thu, 4 Sep 2003 17:04:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v1HL-0004le-00 for mip4@ietf.org; Thu, 04 Sep 2003 17:04:31 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19v1HK-0004lJ-00 for mip4@ietf.org; Thu, 04 Sep 2003 17:04:30 -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 h84L3sC03896; Thu, 4 Sep 2003 16:03:54 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 16:03:55 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B57@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Pete McCann'" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 16:03:46 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , Hi Pete, My response below... Thanks, Jayshree > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Thursday, September 04, 2003 2:35 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Jayshree, > > Jayshree Bharatia writes: > > > I would be fine if we deleted the one sentence "The Foreign > > > Agent could then assume..." from the above (it has no > > > normative value anyway). > > > > > [JB] I rather have just "MUST" instead of "SHOULD" in the > current text > without any further conditional text if it > solves all your concerns. > > Are you saying to include a challenge in every registration > reply or agent advertisement? Well, that would be ok with > me, but we got pushback from Charlie on this. I don't want > to put words in his mouth, so go back and re-read his posts > from the archive. I think he felt that an always MUST was > too strong, as there were conditions where it could be left > out. We were trying to pin down those conditions, which I > think my suggested text does. [JB] I am very well aware of Charlie's email on this subject (quoted below): "The foreign agent "should" be allowed to rely on letting the mobile nodes use the advertised values when it is likely that will be successful. Good systems could be built that way." Since you are still suggesting having conditional text with the use of "MUST", I assume that in your opinion having "SHOULD" is not appropriate and hence you disagree with Charlie's reply. My point here is, if I have to choose from using "MUST" with your conditional text or "MUST" without the conditional text, I rather use just "MUST" without any condition. Anyway, I would let Charlie reply on this. I am fine with either using "SHOULD" as suggested by Charlie or using "MUST" without any condition. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 19:11: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 TAA00428 for ; Thu, 4 Sep 2003 19:11: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 19v3Fn-0003iy-Q9 for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 19:11:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84NB3Kd014312 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 19:11:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3Fn-0003il-MC for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 19:11: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 TAA00383 for ; Thu, 4 Sep 2003 19:10:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3Fj-0007S9-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:11:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v3Fj-0007S5-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:10:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3Fl-0003iX-KN; Thu, 04 Sep 2003 19:11:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3F9-0003hU-BF for mip4@optimus.ietf.org; Thu, 04 Sep 2003 19:10: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 TAA00357 for ; Thu, 4 Sep 2003 19:10:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3F5-0007R4-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:10:20 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19v3F5-0007QH-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:10:19 -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.0/Switch-2.2.0) with ESMTP id h84N6xJ20617; Thu, 4 Sep 2003 18:06:59 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h84N6uf01951; Thu, 4 Sep 2003 18:06:57 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16215.50575.349347.689426@gargle.gargle.HOWL> Date: Thu, 4 Sep 2003 18:06:55 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Ahmad Muhanna writes: > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Thursday, September 04, 2003 12:42 PM > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > Hi, Ahmad, > > > > Ahmad Muhanna writes: > > > Hi, Pete, > > > > > > The scenario I was concerned about does not use the > > bad-authenticator in its > response and therefore it is no > > issue. > I agree with your text below: > > > > > 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. > > > > With respect to the following text. I do not think that it > > is necessary. > It is probably redandfant information. > > > > 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. > > > > Are you saying that if the FA doesn't invalidate previously > > unused challenges, then it will not allocate more storage? > > That doesn't necessarily follow. > > Then, can you elaborate more on how this does not necessarily follow. If we remove the restriction, then it would be legal to implement an FA that created a new challenge whenever it received an un-authenticated RRQ or Agent Solicitation, and that allocated new storage for each challenge. This would have the property of not invalidating old challenges (because they would still be kept in storage) but would allow unauthenticated messages to exhaust the resources of the FA, which would be bad. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 19:14: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 TAA00601 for ; Thu, 4 Sep 2003 19:14: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 19v3Ih-0003r3-FA for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 19:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84NE3hm014811 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 19:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3Ih-0003qk-7N for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 19:14: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 TAA00560 for ; Thu, 4 Sep 2003 19:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3If-0007VC-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:14:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v3Ie-0007V9-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3If-0003no-57; Thu, 04 Sep 2003 19:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3IK-0003mm-LM for mip4@optimus.ietf.org; Thu, 04 Sep 2003 19:13:40 -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 TAA00515 for ; Thu, 4 Sep 2003 19:13:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3IJ-0007Ub-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:13:39 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19v3II-0007To-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:13:38 -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.0/Switch-2.2.0) with ESMTP id h84N4CJ19451; Thu, 4 Sep 2003 18:04:13 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h84N4Af16967; Thu, 4 Sep 2003 18:04:11 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16215.50408.231347.632353@gargle.gargle.HOWL> Date: Thu, 4 Sep 2003 18:04:08 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "'Pete McCann'" , "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Ahmad Muhanna writes: > > Ahmad Muhanna writes: > > > > -----Original Message----- > > > > From: Pete McCann [mailto:mccap@lucent.com] > > > > Sent: Wednesday, September 03, 2003 5:03 PM > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: 'mip4@ietf.org' > > > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > > > > > > > > > > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT > > INVALIDATING the > challenge received in RRQ, why not > > sending that challenge (still valid) back > in RRP. Is there > > a problem with that? > > > > That behavior is allowed by the text above, assuming that the > > challenge received in the RRQ is stored in the data > > structures given in Appendix E. If not, then what you > > describe would not be ok, because you would be forcing the FA > > to use a challenge that it didn't necessarily generate. > > > > Is there any scenario that we may be missing and FA may no longer having a > valid unused challenges for a certain MN? Ah, very good question. I think we had some text to cover this case in one of the proposals, but I subsequently deleted it. How about: 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. -Pete > > My view is that it should also be legal to return any of the > > other previously unused challenges from the data structure. > > This allows for maximum implementation flexibility. The DoS > > attack is prevented as long as you don't invalidate existing > > previously unused challenges. > > > > -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 19:14: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 TAA00618 for ; Thu, 4 Sep 2003 19:14: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 19v3Ih-0003rL-Pu for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 19:14:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84NE37p014829 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 19:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3Ih-0003r6-LW for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 19:14: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 TAA00564 for ; Thu, 4 Sep 2003 19:13:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3Ig-0007VM-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:14:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v3Ie-0007VD-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3If-0003po-Nh; Thu, 04 Sep 2003 19:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3IT-0003mu-Kj for mip4@optimus.ietf.org; Thu, 04 Sep 2003 19:13: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 TAA00530 for ; Thu, 4 Sep 2003 19:13:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3IS-0007Us-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:13:48 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19v3IR-0007UD-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:13:47 -0400 Received: (qmail 9541 invoked from network); 4 Sep 2003 23:13:16 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 4 Sep 2003 23:13:16 -0000 Date: Fri, 5 Sep 2003 01:13:15 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: "'Pete McCann'" , "'mip4@ietf.org'" Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Message-Id: <20030905011315.656d2d34.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746B57@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746B57@zrc2c000.us.nortel.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.qivd74farRo4N6" 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: , --=.qivd74farRo4N6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thursday 4 September 2003, Jayshree wrote: ... > > > > I would be fine if we deleted the one sentence "The Foreign > > > > Agent could then assume..." from the above (it has no > > > > normative value anyway). > > > > > > > [JB] I rather have just "MUST" instead of "SHOULD" in the > > current text > without any further conditional text if it > > solves all your concerns. > > > > Are you saying to include a challenge in every registration > > reply or agent advertisement? Well, that would be ok with > > me, but we got pushback from Charlie on this. I don't want > > to put words in his mouth, so go back and re-read his posts > > from the archive. I think he felt that an always MUST was > > too strong, as there were conditions where it could be left > > out. We were trying to pin down those conditions, which I > > think my suggested text does. > > [JB] I am very well aware of Charlie's email on this subject (quoted below): > "The foreign agent "should" be allowed to rely on letting the mobile nodes > use the advertised values when it is likely that will be successful. Good > systems could be built that way." > Since you are still suggesting having conditional text with the use of > "MUST", I assume that in your opinion having "SHOULD" is not appropriate and > hence you disagree with Charlie's reply. My point here is, if I have to > choose from using "MUST" with your conditional text or "MUST" without the > conditional text, I rather use just "MUST" without any condition. Anyway, I > would let Charlie reply on this. I am fine with either using "SHOULD" as > suggested by Charlie or using "MUST" without any condition. ??? Jayshree, the only one who seems to have advocated MUST instead of SHOULD in the original text recently seems to have been you, above. I think both Pete and myself have assumed that we would let the original paragraph stand as-is, with SHOULD, but explain more closely in following text under which conditions the SHOULD does and doesn't apply. Let me re-iterate my latest proposal, which I still think is good :-) : "3.3. Foreign Agent Processing for Registration Replies 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. 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. The Foreign Agent could then assume that the mobile node with high likelihood has received and can use the multicast challenge. 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. ..." Henrik --=.qivd74farRo4N6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/V8cLeVhrtTJkXCMRAhnfAJ98h+2h+dTgP9fLW5ifRqbR3cktjACg4oEz ZDF8HG6v3nBehg0GtOlRPNQ= =9f+n -----END PGP SIGNATURE----- --=.qivd74farRo4N6-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 19:16: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 TAA00889 for ; Thu, 4 Sep 2003 19:16: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 19v3Kc-0003yx-W0 for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 19:16:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84NG2HZ015301 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 19:16:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3Kc-0003yi-Rc for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 19:16: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 TAA00810 for ; Thu, 4 Sep 2003 19:15:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3Kb-0007Zf-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:16:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v3Ka-0007Zc-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:16:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3Kb-0003xK-Om; Thu, 04 Sep 2003 19:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3K1-0003wM-W7 for mip4@optimus.ietf.org; Thu, 04 Sep 2003 19:15: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 TAA00723 for ; Thu, 4 Sep 2003 19:15:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3K0-0007Xy-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:15:24 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19v3Jy-0007WZ-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:15:22 -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.0/Switch-2.2.0) with ESMTP id h84NBSJ22467; Thu, 4 Sep 2003 18:11:29 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h84NBQf25011; Thu, 4 Sep 2003 18:11:27 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16215.50845.55347.377430@gargle.gargle.HOWL> Date: Thu, 4 Sep 2003 18:11:25 -0500 From: Pete McCann To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 In-Reply-To: <870397D7C140C84DB081B88396458DAF746B57@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746B57@zrc2c000.us.nortel.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 Hi, Jayshree, Jayshree Bharatia writes: > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Thursday, September 04, 2003 2:35 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > Hi, Jayshree, > > > > Jayshree Bharatia writes: > > > > I would be fine if we deleted the one sentence "The Foreign > > > > Agent could then assume..." from the above (it has no > > > > normative value anyway). > > > > > > > [JB] I rather have just "MUST" instead of "SHOULD" in the > > current text > without any further conditional text if it > > solves all your concerns. > > > > Are you saying to include a challenge in every registration > > reply or agent advertisement? Well, that would be ok with > > me, but we got pushback from Charlie on this. I don't want > > to put words in his mouth, so go back and re-read his posts > > from the archive. I think he felt that an always MUST was > > too strong, as there were conditions where it could be left > > out. We were trying to pin down those conditions, which I > > think my suggested text does. > > [JB] I am very well aware of Charlie's email on this subject (quoted below): > "The foreign agent "should" be allowed to rely on letting the mobile nodes > use the advertised values when it is likely that will be successful. Good > systems could be built that way." > Since you are still suggesting having conditional text with the use of > "MUST", I assume that in your opinion having "SHOULD" is not appropriate and > hence you disagree with Charlie's reply. My point here is, if I have to > choose from using "MUST" with your conditional text or "MUST" without the > conditional text, I rather use just "MUST" without any condition. Anyway, I > would let Charlie reply on this. I am fine with either using "SHOULD" as > suggested by Charlie or using "MUST" without any condition. The MUST with an "unless" condition is a little weaker than a strict MUST, while being stronger than a SHOULD, so I was hoping it would make everyone happy. Can you tell me why you don't like the "unless" condition? -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 19:33: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 TAA01828 for ; Thu, 4 Sep 2003 19:33: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 19v3b4-0004SF-CW for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 19:33:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84NX2Fu017076 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 19:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3b4-0004RK-4E for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 19:33: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 TAA01784 for ; Thu, 4 Sep 2003 19:32:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3b2-0000DR-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:33:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v3b1-0000DN-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3b2-0004Qx-Ts; Thu, 04 Sep 2003 19:33:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3ar-0004QW-C5 for mip4@optimus.ietf.org; Thu, 04 Sep 2003 19:32: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 TAA01764 for ; Thu, 4 Sep 2003 19:32:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3ap-0000Ct-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:32:47 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19v3ao-0000CZ-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:32:47 -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 h84NWCC29968; Thu, 4 Sep 2003 18:32:12 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 18:32:12 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 18:32:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3733C.B2DB5DFE" 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_01C3733C.B2DB5DFE Content-Type: text/plain Hi, Pete, Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Thursday, September 04, 2003 6:07 PM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Thursday, September 04, 2003 12:42 PM > > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; > 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal > for Issue2-Change5 > > > > > > > > > > > Hi, Ahmad, > > > > > > Ahmad Muhanna writes: > > > > Hi, Pete, > > > > > > > > The scenario I was concerned about does not use the > > > bad-authenticator in its > response and therefore it is no > > > issue. > I agree with your text below: > > > > > > 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. > > > > > With respect to the following text. I do not think that it > > > is necessary. > It is probably redandfant information. > > > > > 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. > > > > > > Are you saying that if the FA doesn't invalidate previously > > > unused challenges, then it will not allocate more storage? > > > That doesn't necessarily follow. > > > > Then, can you elaborate more on how this does not > necessarily follow. > > If we remove the restriction, then it would be legal to > implement an FA that created a new challenge whenever it > received an un-authenticated RRQ or Agent Solicitation, and > that allocated new storage for each challenge. This would > have the property of not invalidating old challenges (because > they would still be kept in > storage) but would allow unauthenticated messages to exhaust > the resources of the FA, which would be bad. > Well, what is the problem with that. Are we here proposing an HLD for FA or a standard. Those things MUST be left out for implementations. If some one have a super jet machine and an unlimited memory, why we need to restrict them. I feel that we need to keep this out of the standard. It is not related to the protocol we are proposing here. > -Pete > > ------_=_NextPart_001_01C3733C.B2DB5DFE Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Thursday, September 04, 2003 6:07 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > > -----Original Message-----
>  > > From: Pete McCann [mailto:mccap@lucent.com]
>  > > Sent: Thursday, September 04, 2003 12:42 PM
>  > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
>  > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH];
> 'mip4@ietf.org'  > > Subject: RE: [Mip4] RFC3012bis: Proposal
> for Issue2-Change5  > >
>  > >
>  > >
>  > > Hi, Ahmad,
>  > >
>  > > Ahmad Muhanna writes:
>  > >  > Hi, Pete,
>  > >  >
>  > >  > The scenario I was concerned about does not use the
>  > > bad-authenticator in its  > response and therefore it is no
>  > > issue.  > I agree with your text below:  >
>  > >  > >  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.  >
>  > >  > With respect to the following text. I do not think that it
>  > > is necessary.  > It is probably redandfant information.  > > 
>  > > 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.
>  > >
>  > > Are you saying that if the FA doesn't invalidate previously
>  > > unused challenges, then it will not allocate more storage? 
>  > > That doesn't necessarily follow.
>  >
>  > Then, can you elaborate more on how this does not
> necessarily follow.
>
> If we remove the restriction, then it would be legal to
> implement an FA that created a new challenge whenever it
> received an un-authenticated RRQ or Agent Solicitation, and
> that allocated new storage for each challenge.  This would
> have the property of not invalidating old challenges (because
> they would still be kept in
> storage) but would allow unauthenticated messages to exhaust
> the resources of the FA, which would be bad.
>

Well, what is the problem with that.
Are we here proposing an HLD for FA or a standard.
Those things MUST be left out for implementations. If some one have a super jet machine and an unlimited memory, why we need to restrict them.

I feel that we need to keep this out of the standard. It is not related to the protocol we are proposing here.

> -Pete
>
>

------_=_NextPart_001_01C3733C.B2DB5DFE-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 19:42: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 TAA02261 for ; Thu, 4 Sep 2003 19:42: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 19v3jm-0004wG-Lb for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 19:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Ng2Ne018978 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 19:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3jm-0004w1-Fw for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 19:42: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 TAA02242 for ; Thu, 4 Sep 2003 19:41:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3jk-0000O9-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:42:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v3jk-0000O6-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3jl-0004uc-7f; Thu, 04 Sep 2003 19: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 19v3jQ-0004u7-C4 for mip4@optimus.ietf.org; Thu, 04 Sep 2003 19:41:40 -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 TAA02226 for ; Thu, 4 Sep 2003 19:41:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3jO-0000Nk-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:41:38 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19v3jN-0000NU-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:41:37 -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 h84NeUC00454; Thu, 4 Sep 2003 18:40:30 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 18:40:30 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Henrik Levkowetz'" , "Jayshree Bharatia" Cc: "'Pete McCann'" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 18:40:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3733D.5CD9E910" 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_01C3733D.5CD9E910 Content-Type: text/plain > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Thursday, September 04, 2003 6:13 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'Pete McCann'; 'mip4@ietf.org' > Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > Thursday 4 September 2003, Jayshree wrote: > ... > > > > > I would be fine if we deleted the one sentence "The Foreign > > > > > Agent could then assume..." from the above (it has no > > > > > normative value anyway). > > > > > > > > > [JB] I rather have just "MUST" instead of "SHOULD" in the > > > current text > without any further conditional text if it > > > solves all your concerns. > > > > > > Are you saying to include a challenge in every registration > > > reply or agent advertisement? Well, that would be ok with > > > me, but we got pushback from Charlie on this. I don't want > > > to put words in his mouth, so go back and re-read his posts > > > from the archive. I think he felt that an always MUST was > > > too strong, as there were conditions where it could be left > > > out. We were trying to pin down those conditions, which I > > > think my suggested text does. > > > > [JB] I am very well aware of Charlie's email on this > subject (quoted > > below): "The foreign agent "should" be allowed to rely on > letting the > > mobile nodes use the advertised values when it is likely > that will be > > successful. Good systems could be built that way." Since > you are still > > suggesting having conditional text with the use of "MUST", I assume > > that in your opinion having "SHOULD" is not appropriate and > hence you > > disagree with Charlie's reply. My point here is, if I have > to choose > > from using "MUST" with your conditional text or "MUST" > without the > > conditional text, I rather use just "MUST" without any condition. > > Anyway, I would let Charlie reply on this. I am fine with > either using > > "SHOULD" as suggested by Charlie or using "MUST" without any > > condition. > > ??? Jayshree, the only one who seems to have advocated MUST > instead of SHOULD in the original text recently seems to have > been you, above. I think both Pete and myself have assumed This is NOT true. The first one who suggested that is you and then followed BY Pete during our conference call. As a matter of fact Jayshree and myself made it clear that changing SHOULD to MUST does not maintain backward compatibility; but it seems that was not a concern! Please check earlier threads if you would like. > that we would let the original paragraph stand as-is, with > SHOULD, but explain more closely in following text under > which conditions the SHOULD does and doesn't apply. Let me > re-iterate my latest proposal, which I still think is good :-) : > > "3.3. Foreign Agent Processing for Registration Replies > > 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. > > 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. The > Foreign Agent could then assume that the mobile node with high > likelihood has received and can use the multicast challenge. > > 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. > > ..." > > Henrik > > ------_=_NextPart_001_01C3733D.5CD9E910 Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: Thursday, September 04, 2003 6:13 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'Pete McCann'; 'mip4@ietf.org'
> Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
> Thursday  4 September 2003, Jayshree wrote:
> ...
> > >  > > I would be fine if we deleted the one sentence "The Foreign
> > >  > > Agent could then assume..." from the above (it has no
> > >  > > normative value anyway).
> > >  > >
> > >  > [JB] I rather have just "MUST" instead of "SHOULD" in the
> > > current text  > without any further conditional text if it
> > > solves all your concerns.
> > >
> > > Are you saying to include a challenge in every registration
> > > reply or agent advertisement?  Well, that would be ok with
> > > me, but we got pushback from Charlie on this.  I don't want
> > > to put words in his mouth, so go back and re-read his posts
> > > from the archive.  I think he felt that an always MUST was
> > > too strong, as there were conditions where it could be left
> > > out.  We were trying to pin down those conditions, which I
> > > think my suggested text does.
> >
> > [JB] I am very well aware of Charlie's email on this
> subject (quoted
> > below): "The foreign agent "should" be allowed to rely on
> letting the
> > mobile nodes use the advertised values when it is likely
> that will be
> > successful. Good systems could be built that way." Since
> you are still
> > suggesting having conditional text with the use of "MUST", I assume
> > that in your opinion having "SHOULD" is not appropriate and
> hence you
> > disagree with Charlie's reply. My point here is, if I have
> to choose
> > from using  "MUST" with your conditional text or  "MUST"
> without the
> > conditional text, I rather use just "MUST" without any condition.
> > Anyway, I would let Charlie reply on this. I am fine with
> either using
> > "SHOULD" as suggested by Charlie or using "MUST" without any
> > condition.
>
> ??? Jayshree, the only one who seems to have advocated MUST
> instead of SHOULD in the original text recently seems to have
> been you, above. I think both Pete and myself have assumed

This is NOT true.
The first one who suggested that is you and then followed BY Pete during our conference call.
As a matter of fact Jayshree and myself made it clear that changing SHOULD to MUST does not maintain backward compatibility; but it seems that was not a concern!

Please check earlier threads if you would like.


> that we would let the original paragraph stand as-is, with
> SHOULD, but explain more closely in following text under
> which conditions the SHOULD does and doesn't apply. Let me
> re-iterate my latest proposal, which I still think is good :-)  :
>
> "3.3. Foreign Agent Processing for Registration Replies
>
>    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.
>  
>    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. The
>    Foreign Agent could then assume that the mobile node with high
>    likelihood has received and can use the multicast challenge.
>  
>    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.
>
> ..."
>
>       Henrik
>
>

------_=_NextPart_001_01C3733D.5CD9E910-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 4 19:54: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 TAA03042 for ; Thu, 4 Sep 2003 19:54: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 19v3vO-0005IX-Ke for mip4-archive@odin.ietf.org; Thu, 04 Sep 2003 19:54:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h84Ns2sp020359 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 19:54:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3vO-0005II-GS for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 19:54: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 TAA03001 for ; Thu, 4 Sep 2003 19:53:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3vM-0000jS-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:54:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v3vL-0000jO-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 19:53:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3vM-0005Hp-K4; Thu, 04 Sep 2003 19:54:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v3uY-0005Em-SO for mip4@optimus.ietf.org; Thu, 04 Sep 2003 19:53: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 TAA02937 for ; Thu, 4 Sep 2003 19:53:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v3uW-0000iF-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:53:08 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19v3uV-0000gm-00 for mip4@ietf.org; Thu, 04 Sep 2003 19:53:08 -0400 Received: (qmail 10045 invoked from network); 4 Sep 2003 23:52:37 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 4 Sep 2003 23:52:37 -0000 Date: Fri, 5 Sep 2003 01:52:36 +0200 From: Henrik Levkowetz To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'Pete McCann'" , "'mip4@ietf.org'" Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Message-Id: <20030905015236.41bf3aff.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.ei,PQ+_5hXaj+G" 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: , --=.ei,PQ+_5hXaj+G Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Ahmad, I know what's been discussed earlier. Right now I said: > > ??? Jayshree, the only one who seems to have advocated MUST > > instead of SHOULD in the original text recently seems to have -----------------------------------------> ^^^^^^^^ > > been you, above. I think both Pete and myself have assumed > > This is NOT true. > The first one who suggested that is you and then followed BY Pete during our > conference call. > As a matter of fact Jayshree and myself made it clear that changing SHOULD > to MUST does not maintain backward compatibility; but it seems that was not > a concern! > Please check earlier threads if you would like. Please, assume that other people than yourself also have a little bit of sense, intelligence and memory. Henrik --=.ei,PQ+_5hXaj+G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/V9BEeVhrtTJkXCMRAoCrAKDj0QLLO3M0NUEcRuVXVkssArLpewCguUF5 lw2IAyk74mOkLQbgtweo+8U= =jSa4 -----END PGP SIGNATURE----- --=.ei,PQ+_5hXaj+G-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 5 04:05:08 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 EAA08646 for ; Fri, 5 Sep 2003 04:05:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBaE-000187-On for mip4-archive@odin.ietf.org; Fri, 05 Sep 2003 04:04:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8584gCi004344 for mip4-archive@odin.ietf.org; Fri, 5 Sep 2003 04:04:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBaE-00017z-Dq for mip4-web-archive@optimus.ietf.org; Fri, 05 Sep 2003 04:04:42 -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 EAA08624 for ; Fri, 5 Sep 2003 04:04:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vBa6-0005vA-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 04:04:34 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vBZh-0005v1-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 04:04:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBZY-000162-Ra; Fri, 05 Sep 2003 04:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vBYn-00013V-6t for mip4@optimus.ietf.org; Fri, 05 Sep 2003 04:03: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 EAA08516 for ; Fri, 5 Sep 2003 04:03:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vBYY-0005uF-00 for mip4@ietf.org; Fri, 05 Sep 2003 04:02:58 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19vBY7-0005kB-00 for mip4@ietf.org; Fri, 05 Sep 2003 04:02:31 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h85801K01384; Fri, 5 Sep 2003 10:00:01 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F5842F5.1010900@comnets.uni-bremen.de> Date: Fri, 05 Sep 2003 10:01:57 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Jee J.Z." CC: Mobile IP v4 Subject: Re: [Mip4] regional registration draft References: <3F534CEE.4090000@comnets.uni-bremen.de> <010201c37304$2cacee60$b7882090@ohm.york.ac.uk> In-Reply-To: <010201c37304$2cacee60$b7882090@ohm.york.ac.uk> Content-Type: multipart/alternative; boundary="------------090108010902030801080608" 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 is a multi-part message in MIME format. --------------090108010902030801080608 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Jee, I suppose this might be the reason, but IMHO this is not necessary. Assume a three level hierarchy as shown below (hope ASCII graphic is coming through ok) and further assume that the FAs do not include in their advertisements any of hierarchical mobility agents in their hierarchy branch. GFA / \ / \ RFA1 RFA2 / \ / \ FA1 FA2 FA3 FA4 Initially MN enters the hierarchy below FA1. This first RegReq propagates through the hierarchy making a binding at every hierarchical mobility agent it encounters, namely RFA1, GFA, HA. The RegReply is initiated by the HA. In RFA1's binding the MN has as COA the address of the FA1, while in the GFA's binding it has as COA the address of RFA1. As the MN moves to FA2 it initiates a new RegReq that again propagates through the hierarchy. Only this time, when the RFA1 received the RegReq, it goes through its bindings table and determines that it allready maintains a binding for this MN. Then it compares the existing COA with the one in the RegReq. If it they are the same then this is probably a RegReq with the purpose of renewing the lifetime of a binding and should be forwarded, otherwise the MN is trying to establish a new binding. Depending on the status of the 'S' bit, the request is handled locally and a RegReply is locally issued. Finally, should the MN move between FA2 and FA3 then the RegReq would traverse the hierarchy all the way to the GFA who would go through its bindings table and determine that the MN is already known to him. At that point it may decide to terminate the RegReq and issue a RegReply. All of this may happen transparently without increasing complexity at the mobile node or without increasing the size of the agent advertisements. Besides the size and rate of the advertisements may affect the efficiency of the network. This URL (http://www.comnets.uni-bremen.de/~niko/efficiency.eps) leads to a graph acquired with ns-2 that indicates the efficiency of a simulated WLAN with a single FA and MN. Different advertisement sizes and rates where used. Best Regards niko Jee J.Z. wrote: >Hi Niko, > >I think this is for the MN to choose a closest anchor point to send a >regional registration request next time. > >Cheers, >Jee > >----- Original Message ----- >From: "Niko A. Fikouras" >To: >Sent: Monday, September 01, 2003 2:43 PM >Subject: [Mip4] regional registration draft > > > > >>Hi all, >> >>I have a question on the regional registrations draft >>(draft-ietf-mobileip-reg-tunnel-07.txt). According to Appendix Section >>"B.1. Registration with Home Agent" (p.32-33), a foreign agent may have >>to include in its agent advertisements the addresses of all mobility >>agents (RFAs, GFAs) in its hierarchy branch. I would like to know what >>the reason is behind this action, because considering a MIP hierarchy >>with several levels then agent advertisements may acquire a significant >>size. Moreover, considering that foreign agents may have to increase >>their advertisement period in order to accelrate MIP hand-offs, then the >>transmission of agent advertisements of some size may result in a >>significant overhead with an effect to network efficiency. >> >>Thanks in advance >>niko >> >> >>_______________________________________________ >>Mip4 mailing list >>Mip4@ietf.org >>https://www.ietf.org/mailman/listinfo/mip4 >> >> >> > > > > --------------090108010902030801080608 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jee,

I suppose this might be the reason, but IMHO this is not necessary. Assume a three level hierarchy as shown below (hope ASCII graphic is coming through ok) and further assume that the FAs do not include in their advertisements any of hierarchical mobility agents in their hierarchy branch.

             GFA
             /      \
            /         \
          RFA1     RFA2
          /     \        /    \
       FA1  FA2 FA3   FA4

Initially MN enters the hierarchy below FA1. This first RegReq propagates through the hierarchy making a binding at every hierarchical mobility agent it encounters, namely RFA1, GFA, HA. The RegReply is initiated by the HA. In RFA1's binding the MN has as COA the address of the FA1, while in the GFA's binding it has as COA the address of RFA1.
As the MN moves to FA2 it initiates a new RegReq that again propagates through the hierarchy. Only this time, when the RFA1 received the RegReq, it goes through its bindings table and determines that it allready maintains a binding for this MN. Then it compares the existing COA with the one in the RegReq. If it they are the same then this is probably a RegReq with the purpose of renewing the lifetime of a binding and should be forwarded, otherwise the MN is trying to establish a new binding. Depending on the status of the 'S' bit, the request is handled locally and a RegReply is locally issued.
Finally, should the MN move between FA2 and FA3 then the RegReq would traverse the hierarchy all the way to the GFA who would go through its bindings table and determine that the MN is already known to him. At that point it may decide to terminate the RegReq and issue a RegReply.
All of this may happen transparently without increasing complexity at the mobile node or without increasing the size of the agent advertisements. Besides the size and rate of the advertisements may affect the efficiency of the network. This URL (http://www.comnets.uni-bremen.de/~niko/efficiency.eps) leads to a graph acquired with ns-2 that indicates the efficiency of a simulated WLAN with a single FA and MN. Different advertisement sizes and rates where used.

Best Regards
niko

Jee J.Z. wrote:
Hi Niko,

I think this is for the MN to choose a closest anchor point to send a
regional registration request next time.

Cheers,
Jee

----- Original Message -----
From: "Niko A. Fikouras" <niko@comnets.uni-bremen.de>
To: <mip4@ietf.org>
Sent: Monday, September 01, 2003 2:43 PM
Subject: [Mip4] regional registration draft


  
Hi all,

I have a question on the regional registrations draft
(draft-ietf-mobileip-reg-tunnel-07.txt). According to Appendix Section
"B.1. Registration with Home Agent" (p.32-33), a foreign agent may have
to include in its agent advertisements the addresses of all mobility
agents (RFAs, GFAs) in its hierarchy branch.  I would like to know what
the reason is behind this action, because considering a MIP hierarchy
with several levels then agent advertisements may acquire a significant
size. Moreover, considering that foreign agents may have to increase
their advertisement period in order to accelrate MIP hand-offs, then the
transmission of agent advertisements of some size may result in a
significant overhead with an effect to network efficiency.

Thanks in advance
niko


_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/mailman/listinfo/mip4
--------------090108010902030801080608-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 5 10:26: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 KAA26279 for ; Fri, 5 Sep 2003 10:26: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 19vHXI-0005i0-At for mip4-archive@odin.ietf.org; Fri, 05 Sep 2003 10:26:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85EQ4K7021938 for mip4-archive@odin.ietf.org; Fri, 5 Sep 2003 10:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHXI-0005hg-3M for mip4-web-archive@optimus.ietf.org; Fri, 05 Sep 2003 10:26: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 KAA26266 for ; Fri, 5 Sep 2003 10:25:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHXF-00061U-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 10:26:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vHXD-00061R-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 10:25:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHXE-0005gg-Hk; Fri, 05 Sep 2003 10:26:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHWd-0005cg-PU for mip4@optimus.ietf.org; Fri, 05 Sep 2003 10:25: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 KAA26171 for ; Fri, 5 Sep 2003 10:25:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHWb-0005wq-00 for mip4@ietf.org; Fri, 05 Sep 2003 10:25:21 -0400 Received: from mail-efg1.york.ac.uk ([144.32.128.244]) by ietf-mx with esmtp (Exim 4.12) id 19vHWa-0005tQ-00 for mip4@ietf.org; Fri, 05 Sep 2003 10:25:20 -0400 Received: from jz105 (jz105.ohm.york.ac.uk [144.32.136.183]) by mail-efg1.york.ac.uk (8.12.9/8.12.9) with SMTP id h85EOcdg012393; Fri, 5 Sep 2003 15:24:38 +0100 (BST) Message-ID: <00ab01c373b9$dcb68900$b7882090@ohm.york.ac.uk> From: "Jee J.Z." To: "Niko A. Fikouras" , "Mobile IP v4" References: <3F534CEE.4090000@comnets.uni-bremen.de> <010201c37304$2cacee60$b7882090@ohm.york.ac.uk> <3F5842F5.1010900@comnets.uni-bremen.de> Subject: Re: [Mip4] regional registration draft Date: Fri, 5 Sep 2003 15:27:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01C373C2.3E2EA5C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-York-MailScanner: Found to be clean 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 is a multi-part message in MIME format. ------=_NextPart_000_00A8_01C373C2.3E2EA5C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Niko, You are right that including all foreign agents' address in the = hierarchy in agent advertisements is not a necessity. The draft only = states that the foreign agent MAY do so. IMHO by doing so, the choice of = registration anchor point is left to Mobile Nodes, and therefore foreign = agents do not need to go through their visitor list every time they get = a registration request and thus speed up the processing. However, as you = mentioned, large advertisement packets may affect the network = efficiency. There may be a tradeoff involved. Both methods assume keys = have been distributed to the GFA/RFA/FA, and RFA/FA may process = registration requst message addressed to the GFA, if not including all = foreign agents' address in the hierarchy in advertisments. Other comments are very welcome. Regards, Jee ----- Original Message -----=20 From: Niko A. Fikouras=20 To: Jee J.Z.=20 Cc: Mobile IP v4=20 Sent: Friday, September 05, 2003 9:01 AM Subject: Re: [Mip4] regional registration draft Hi Jee, I suppose this might be the reason, but IMHO this is not necessary. = Assume a three level hierarchy as shown below (hope ASCII graphic is = coming through ok) and further assume that the FAs do not include in = their advertisements any of hierarchical mobility agents in their = hierarchy branch. GFA / \ / \ RFA1 RFA2 / \ / \ FA1 FA2 FA3 FA4 Initially MN enters the hierarchy below FA1. This first RegReq = propagates through the hierarchy making a binding at every hierarchical = mobility agent it encounters, namely RFA1, GFA, HA. The RegReply is = initiated by the HA. In RFA1's binding the MN has as COA the address of = the FA1, while in the GFA's binding it has as COA the address of RFA1. As the MN moves to FA2 it initiates a new RegReq that again propagates = through the hierarchy. Only this time, when the RFA1 received the = RegReq, it goes through its bindings table and determines that it = allready maintains a binding for this MN. Then it compares the existing = COA with the one in the RegReq. If it they are the same then this is = probably a RegReq with the purpose of renewing the lifetime of a binding = and should be forwarded, otherwise the MN is trying to establish a new = binding. Depending on the status of the 'S' bit, the request is handled = locally and a RegReply is locally issued. Finally, should the MN move between FA2 and FA3 then the RegReq would = traverse the hierarchy all the way to the GFA who would go through its = bindings table and determine that the MN is already known to him. At = that point it may decide to terminate the RegReq and issue a RegReply.=20 All of this may happen transparently without increasing complexity at = the mobile node or without increasing the size of the agent = advertisements. Besides the size and rate of the advertisements may = affect the efficiency of the network. This URL = (http://www.comnets.uni-bremen.de/~niko/efficiency.eps) leads to a graph = acquired with ns-2 that indicates the efficiency of a simulated WLAN = with a single FA and MN. Different advertisement sizes and rates where = used. Best Regards niko Jee J.Z. wrote: Hi Niko, I think this is for the MN to choose a closest anchor point to send a regional registration request next time. Cheers, Jee ----- Original Message ----- From: "Niko A. Fikouras" To: Sent: Monday, September 01, 2003 2:43 PM Subject: [Mip4] regional registration draft =20 Hi all, I have a question on the regional registrations draft (draft-ietf-mobileip-reg-tunnel-07.txt). According to Appendix Section "B.1. Registration with Home Agent" (p.32-33), a foreign agent may have to include in its agent advertisements the addresses of all mobility agents (RFAs, GFAs) in its hierarchy branch. I would like to know what the reason is behind this action, because considering a MIP hierarchy with several levels then agent advertisements may acquire a significant size. Moreover, considering that foreign agents may have to increase their advertisement period in order to accelrate MIP hand-offs, then the transmission of agent advertisements of some size may result in a significant overhead with an effect to network efficiency. Thanks in advance niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 =20 =20 ------=_NextPart_000_00A8_01C373C2.3E2EA5C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Niko,
 
You are right that including = all foreign agents'=20 address in the hierarchy in agent advertisements is not a necessity. The = draft=20 only states that the foreign agent MAY do so. IMHO by doing so, the = choice of=20 registration anchor point is left to Mobile Nodes, and therefore foreign = agents=20 do not need to go through their visitor list every time they get a = registration=20 request and thus speed up the processing. However, as you mentioned, = large=20 advertisement packets may affect the network efficiency. There may = be a=20 tradeoff involved. Both methods assume keys have been distributed = to the=20 GFA/RFA/FA, and RFA/FA may process registration requst message addressed = to the=20 GFA, if not including all foreign agents' address in the hierarchy in=20 advertisments.
 
Other comments are very = welcome.
 
Regards,
Jee
 
 
----- Original Message -----
Sent: Friday, = September 05, 2003 9:01=20 AM
Subject: Re: [Mip4] = regional registration=20 draft

Hi Jee,

I suppose this might be the reason, but = IMHO=20 this is not necessary. Assume a three level hierarchy as shown below = (hope=20 ASCII graphic is coming through ok) and further assume that the FAs do = not=20 include in their advertisements any of hierarchical mobility agents in = their=20 hierarchy branch.

         =20    GFA
          =   =20 /      \
       =20     /        =20 \
          RFA1  =   =20 RFA2
          / =    =20 \        /   =20 \
       FA1  FA2 FA3  =20 FA4

Initially MN enters the hierarchy below FA1. This first = RegReq=20 propagates through the hierarchy making a binding at every = hierarchical=20 mobility agent it encounters, namely RFA1, GFA, HA. The RegReply is = initiated=20 by the HA. In RFA1's binding the MN has as COA the address of the FA1, = while=20 in the GFA's binding it has as COA the address of RFA1.
As the MN = moves to=20 FA2 it initiates a new RegReq that again propagates through the = hierarchy.=20 Only this time, when the RFA1 received the RegReq, it goes through its = bindings table and determines that it allready maintains a binding for = this=20 MN. Then it compares the existing COA with the one in the RegReq. If = it they=20 are the same then this is probably a RegReq with the purpose of = renewing the=20 lifetime of a binding and should be forwarded, otherwise the MN is = trying to=20 establish a new binding. Depending on the status of the 'S' bit, the = request=20 is handled locally and a RegReply is locally issued.
Finally, = should the MN=20 move between FA2 and FA3 then the RegReq would traverse the hierarchy = all the=20 way to the GFA who would go through its bindings table and determine = that the=20 MN is already known to him. At that point it may decide to terminate = the=20 RegReq and issue a RegReply.
All of this may happen transparently = without=20 increasing complexity at the mobile node or without increasing the = size of the=20 agent advertisements. Besides the size and rate of the advertisements = may=20 affect the efficiency of the network. This URL (http://www= .comnets.uni-bremen.de/~niko/efficiency.eps)=20 leads to a graph acquired with ns-2 that indicates the efficiency of a = simulated WLAN with a single FA and MN. Different advertisement sizes = and=20 rates where used.

Best Regards
niko

Jee J.Z. = wrote:
Hi Niko,

I think this is for the MN to choose a closest anchor point to send a
regional registration request next time.

Cheers,
Jee

----- Original Message -----
From: "Niko A. Fikouras" <niko@comnets.uni-bremen.de=
>
To: <mip4@ietf.org>
Sent: Monday, September 01, 2003 2:43 PM
Subject: [Mip4] regional registration draft


  
Hi all,

I have a question on the regional registrations draft
(draft-ietf-mobileip-reg-tunnel-07.txt). According to Appendix Section
"B.1. Registration with Home Agent" (p.32-33), a foreign agent may have
to include in its agent advertisements the addresses of all mobility
agents (RFAs, GFAs) in its hierarchy branch.  I would like to know what
the reason is behind this action, because considering a MIP hierarchy
with several levels then agent advertisements may acquire a significant
size. Moreover, considering that foreign agents may have to increase
their advertisement period in order to accelrate MIP hand-offs, then the
transmission of agent advertisements of some size may result in a
significant overhead with an effect to network efficiency.

Thanks in advance
niko


_______________________________________________
Mip4 mailing list
Mip4@ietf.org
https://www.ietf.org/=
mailman/listinfo/mip4
------=_NextPart_000_00A8_01C373C2.3E2EA5C0-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 5 10:46: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 KAA27680 for ; Fri, 5 Sep 2003 10:46: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 19vHqc-0000OE-HM for mip4-archive@odin.ietf.org; Fri, 05 Sep 2003 10:46:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85Ek2NC001492 for mip4-archive@odin.ietf.org; Fri, 5 Sep 2003 10: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 19vHqc-0000Nz-CI for mip4-web-archive@optimus.ietf.org; Fri, 05 Sep 2003 10:46: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 KAA27652 for ; Fri, 5 Sep 2003 10:45:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHqZ-0000G4-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 10:45:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vHqZ-0000G1-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 10:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHqb-0000Mz-9v; Fri, 05 Sep 2003 10: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 19vHpk-0000Hi-W4 for mip4@optimus.ietf.org; Fri, 05 Sep 2003 10:45: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 KAA27616 for ; Fri, 5 Sep 2003 10:45:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHpi-0000Al-00 for mip4@ietf.org; Fri, 05 Sep 2003 10:45:06 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19vHph-00007E-00 for mip4@ietf.org; Fri, 05 Sep 2003 10:45:05 -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.0/Switch-2.2.0) with ESMTP id h85Egcl25613; Fri, 5 Sep 2003 09:42:38 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h85Egax11171; Fri, 5 Sep 2003 09:42:36 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16216.41177.592609.291768@gargle.gargle.HOWL> Date: Fri, 5 Sep 2003 09:42:33 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Ahmad Muhanna writes: > > If we remove the restriction, then it would be legal to > > implement an FA that created a new challenge whenever it > > received an un-authenticated RRQ or Agent Solicitation, and > > that allocated new storage for each challenge. This would > > have the property of not invalidating old challenges (because > > they would still be kept in > > storage) but would allow unauthenticated messages to exhaust > > the resources of the FA, which would be bad. > > Well, what is the problem with that. > Are we here proposing an HLD for FA or a standard. > Those things MUST be left out for implementations. If some one have a super > jet machine and an unlimited memory, why we need to restrict them. > I feel that we need to keep this out of the standard. It is not related to > the protocol we are proposing here. On the contrary, I think it is quite appropriate to call out such restrictions in a standard. See section 1.7.1 from RFC 2408: 1.7 ISAKMP Protection 1.7.1 Anti-Clogging (Denial of Service) Of the numerous security services available, protection against denial of service always seems to be one of the most difficult to address. A "cookie" or anti-clogging token (ACT) is aimed at protecting the computing resources from attack without spending excessive CPU resources to determine its authenticity. An exchange prior to CPU-intensive public key operations can thwart some denial of service attempts (e.g. simple flooding with bogus IP source addresses). Absolute protection against denial of service is impossible, but this anti-clogging token provides a technique for making it easier to handle. The use of an anti-clogging token was introduced by Karn and Simpson in [Karn]. It should be noted that in the exchanges shown in section 4, the anticlogging mechanism should be used in conjuction with a garbage- state collection mechanism; an attacker can still flood a server using packets with bogus IP addresses and cause state to be created. Such aggressive memory management techniques SHOULD be employed by protocols using ISAKMP that do not go through an initial, anti- clogging only phase, as was done in [Karn]. So, this text calls out some specific requirements for memory management and its impact on security. I think it is important that we do the same in 3012bis, so that we will have implementations that are not vulnerable to state exhaustion attacks. Otherwise, we could end up with an embarassing situation that gives the standard a poor reputation. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 5 10:47: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 KAA27750 for ; Fri, 5 Sep 2003 10: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 19vHra-0000WY-M3 for mip4-archive@odin.ietf.org; Fri, 05 Sep 2003 10:47:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85El2uu002006 for mip4-archive@odin.ietf.org; Fri, 5 Sep 2003 10: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 19vHra-0000WH-Ha for mip4-web-archive@optimus.ietf.org; Fri, 05 Sep 2003 10: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 KAA27728 for ; Fri, 5 Sep 2003 10:46:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHrY-0000SW-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 10:47:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vHrX-0000SS-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 10:46:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vHrZ-0000VM-47; Fri, 05 Sep 2003 10: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 19vHrW-0000Ut-GD for mip4@optimus.ietf.org; Fri, 05 Sep 2003 10:46:58 -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 KAA27721 for ; Fri, 5 Sep 2003 10:46:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vHrU-0000RW-00 for mip4@ietf.org; Fri, 05 Sep 2003 10:46:56 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19vHrT-0000Jk-00 for mip4@ietf.org; Fri, 05 Sep 2003 10:46:55 -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 h85EkDI26355; Fri, 5 Sep 2003 09:46:14 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 09:46:13 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Fri, 5 Sep 2003 09:46:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C373BC.7364B3F2" 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_01C373BC.7364B3F2 Content-Type: text/plain Hi, Pete, Agreed. Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Friday, September 05, 2003 9:43 AM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > > If we remove the restriction, then it would be legal to > > > implement an FA that created a new challenge whenever it > > > received an un-authenticated RRQ or Agent Solicitation, and > > > that allocated new storage for each challenge. This would > > > have the property of not invalidating old challenges (because > > > they would still be kept in > > > storage) but would allow unauthenticated messages to exhaust > > > the resources of the FA, which would be bad. > > > > Well, what is the problem with that. > > Are we here proposing an HLD for FA or a standard. > > Those things MUST be left out for implementations. If some > one have a super > jet machine and an unlimited memory, why > we need to restrict them. > I feel that we need to keep this > out of the standard. It is not related to > the protocol we > are proposing here. > > > On the contrary, I think it is quite appropriate to call out > such restrictions in a standard. See section 1.7.1 from RFC 2408: > > > 1.7 ISAKMP Protection > > 1.7.1 Anti-Clogging (Denial of Service) > > Of the numerous security services available, protection against > denial of service always seems to be one of the most difficult to > address. A "cookie" or anti-clogging token (ACT) is aimed at > protecting the computing resources from attack without spending > excessive CPU resources to determine its authenticity. > An exchange > prior to CPU-intensive public key operations can thwart > some denial > of service attempts (e.g. simple flooding with bogus IP source > addresses). Absolute protection against denial of service is > impossible, but this anti-clogging token provides a technique for > making it easier to handle. The use of an anti-clogging token was > introduced by Karn and Simpson in [Karn]. > > It should be noted that in the exchanges shown in section 4, the > anticlogging mechanism should be used in conjuction with > a garbage- > state collection mechanism; an attacker can still flood a server > using packets with bogus IP addresses and cause state to > be created. > Such aggressive memory management techniques SHOULD be employed by > protocols using ISAKMP that do not go through an initial, anti- > clogging only phase, as was done in [Karn]. > > > So, this text calls out some specific requirements for memory > management and its impact on security. I think it is > important that we do the same in 3012bis, so that we will > have implementations that are not vulnerable to state > exhaustion attacks. Otherwise, we could end up with an > embarassing situation that gives the standard a poor reputation. > > -Pete > > ------_=_NextPart_001_01C373BC.7364B3F2 Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

Agreed.

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Friday, September 05, 2003 9:43 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > > If we remove the restriction, then it would be legal to
>  > > implement an FA that created a new challenge whenever it
>  > > received an un-authenticated RRQ or Agent Solicitation, and
>  > > that allocated new storage for each challenge.  This would
>  > > have the property of not invalidating old challenges (because
>  > > they would still be kept in
>  > > storage) but would allow unauthenticated messages to exhaust
>  > > the resources of the FA, which would be bad.
>  >
>  > Well, what is the problem with that.
>  > Are we here proposing an HLD for FA or a standard.
>  > Those things MUST be left out for implementations. If some
> one have a super  > jet machine and an unlimited memory, why
> we need to restrict them.  > I feel that we need to keep this
> out of the standard. It is not related to  > the protocol we
> are proposing here.
>
>
> On the contrary, I think it is quite appropriate to call out
> such restrictions in a standard.  See section 1.7.1 from RFC 2408:
>
>
>  1.7 ISAKMP Protection
>
>  1.7.1 Anti-Clogging (Denial of Service)
>
>     Of the numerous security services available, protection against
>     denial of service always seems to be one of the most difficult to
>     address.  A "cookie" or anti-clogging token (ACT) is aimed at
>     protecting the computing resources from attack without spending
>     excessive CPU resources to determine its authenticity. 
> An exchange
>     prior to CPU-intensive public key operations can thwart
> some denial
>     of service attempts (e.g.  simple flooding with bogus IP source
>     addresses).  Absolute protection against denial of service is
>     impossible, but this anti-clogging token provides a technique for
>     making it easier to handle.  The use of an anti-clogging token was
>     introduced by Karn and Simpson in [Karn].
>
>     It should be noted that in the exchanges shown in section 4, the
>     anticlogging mechanism should be used in conjuction with
> a garbage-
>     state collection mechanism; an attacker can still flood a server
>     using packets with bogus IP addresses and cause state to
> be created.
>     Such aggressive memory management techniques SHOULD be employed by
>     protocols using ISAKMP that do not go through an initial, anti-
>     clogging only phase, as was done in [Karn].
>
>
> So, this text calls out some specific requirements for memory
> management and its impact on security.  I think it is
> important that we do the same in 3012bis, so that we will
> have implementations that are not vulnerable to state
> exhaustion attacks.  Otherwise, we could end up with an
> embarassing situation that gives the standard a poor reputation.
>
> -Pete
>
>

------_=_NextPart_001_01C373BC.7364B3F2-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 5 11:05: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 LAA28894 for ; Fri, 5 Sep 2003 11:05: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 19vI92-0003A3-GA for mip4-archive@odin.ietf.org; Fri, 05 Sep 2003 11:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85F54g8012145 for mip4-archive@odin.ietf.org; Fri, 5 Sep 2003 11:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vI92-00039o-CA for mip4-web-archive@optimus.ietf.org; Fri, 05 Sep 2003 11:05: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 LAA28885 for ; Fri, 5 Sep 2003 11:04:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vI8z-0004dQ-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 11:05:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vI8z-0004dN-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 11:05:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vI8z-000387-Ve; Fri, 05 Sep 2003 11: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 19vI81-00030s-Hj for mip4@optimus.ietf.org; Fri, 05 Sep 2003 11:04: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 LAA28855 for ; Fri, 5 Sep 2003 11:03:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vI7y-0004PH-00 for mip4@ietf.org; Fri, 05 Sep 2003 11:03:59 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19vI7y-0004IG-00 for mip4@ietf.org; Fri, 05 Sep 2003 11:03:58 -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.0/Switch-2.2.0) with ESMTP id h85Eunl06437; Fri, 5 Sep 2003 09:57:01 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h85Eulx27256; Fri, 5 Sep 2003 09:56:47 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16216.42028.939609.328093@gargle.gargle.HOWL> Date: Fri, 5 Sep 2003 09:56:44 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Ahmad Muhanna writes: > > > Is there any scenario that we may be missing and FA may no > > longer having a > valid unused challenges for a certain MN? > > > > Ah, very good question. I think we had some text to cover > > this case in one of the proposals, but I subsequently deleted it. > > > > How about: > > > > 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. > > > > -Pete > > > > Let me try to understand what we are trying to propose here: > If RRQ generates MN-AAA authentication, FA MUST not invalidate previously > unused challenges > 1. FA SHOULD include a previously unused challenge in RRP, if present; or > 2. FA SHOULD generate a new challenge., or > 3. FA does not send any of the above SHOULD's and send a new challenge > always. > > Is not all of the above is already captured very nicely in section 2 of > RFC3012bis: > " > The Challenge extension, illustrated in figure 1, is inserted in the > Agent Advertisements by the Foreign Agent, in order to communicate > the latest challenge value that can be used by the mobile node > to compute an authentication for its next registration request > message. The challenge is selected by the foreign agent to provide > local assurance that the mobile node is not replaying any earlier > registration request. > " > > I believe there is probably no need for all of these SHOULDs and let us > leave it as generic as it should be with the responsibility of the FA as > explained in the above paragraph. > > Your thoughts, please. No, it is not covered by that text. We are trying to eliminate two denial-of-service attacks. This requires restricting the FA implementation so that un-authenticated messages do not cause (a) invalidation of previously unused challenges, nor (b) creation of state at the FA. The text you quote does not give enough guidance on this. We need the text that has been suggested in the Security Considerations section 12. I think we also need the text in this Appendix E to clarify how the example pseudocode/data storage should be handled to meet these security obligations. I am having trouble understanding your objections to these text suggestions. Are you really so concerned about an existing implementation, that violates this text? Is it really that much effort to make these (very sensible, in my opinion) changes? -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 5 17:12:31 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 RAA19433 for ; Fri, 5 Sep 2003 17:12:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vNsF-0007CU-AX for mip4-archive@odin.ietf.org; Fri, 05 Sep 2003 17:12:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h85LC7hD027671 for mip4-archive@odin.ietf.org; Fri, 5 Sep 2003 17:12:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vNsD-0007CA-I5 for mip4-web-archive@optimus.ietf.org; Fri, 05 Sep 2003 17:12: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 RAA19424 for ; Fri, 5 Sep 2003 17:11:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vNsB-0001ub-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 17:12:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vNsA-0001uY-00 for mip4-web-archive@ietf.org; Fri, 05 Sep 2003 17:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vNs9-0007BU-HF; Fri, 05 Sep 2003 17:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vNrX-00078E-Oi for mip4@optimus.ietf.org; Fri, 05 Sep 2003 17:11: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 RAA19404 for ; Fri, 5 Sep 2003 17:11:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vNrT-0001qn-00 for mip4@ietf.org; Fri, 05 Sep 2003 17:11:19 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19vNrT-0001nt-00 for mip4@ietf.org; Fri, 05 Sep 2003 17:11:19 -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 h85LAcI14256; Fri, 5 Sep 2003 16:10:39 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 16:10:40 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Fri, 5 Sep 2003 16:10:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C373F1.9ABEDA9C" 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_01C373F1.9ABEDA9C Content-Type: text/plain Hi, Pete, Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Friday, September 05, 2003 9:57 AM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > > > Is there any scenario that we may be missing and FA may no > > > longer having a > valid unused challenges for a certain > MN? > > > > > Ah, very good question. I think we had some text to cover > > > this case in one of the proposals, but I subsequently > deleted it. > > > > > How about: > > > > > > 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. > > > > > > -Pete > > > > > > > Let me try to understand what we are trying to propose > here: > If RRQ generates MN-AAA authentication, FA MUST not > invalidate previously > unused challenges > 1. FA SHOULD > include a previously unused challenge in RRP, if present; or > > 2. FA SHOULD generate a new challenge., or > 3. FA does > not send any of the above SHOULD's and send a new challenge > > always. > > > Is not all of the above is already captured very nicely in > section 2 of > RFC3012bis: > " > > The Challenge extension, illustrated in figure 1, is > inserted in the > > Agent Advertisements by the Foreign Agent, in order to > communicate > > the latest challenge value that can be used by the mobile node > > to compute an authentication for its next registration request > > message. The challenge is selected by the foreign > agent to provide > > local assurance that the mobile node is not replaying > any earlier > > registration request. > > " > > > > I believe there is probably no need for all of these > SHOULDs and let us > leave it as generic as it should be > with the responsibility of the FA as > explained in the > above paragraph. > > > Your thoughts, please. > > No, it is not covered by that text. We are trying to > eliminate two denial-of-service attacks. This requires > restricting the FA implementation so that un-authenticated > messages do not cause (a) invalidation of previously unused > challenges, nor (b) creation of state at the FA. The text > you quote does not give enough guidance on this. > > We need the text that has been suggested in the Security > Considerations section 12. I think we also need the text in > this Appendix E to clarify how the example pseudocode/data > storage should be handled to meet these security obligations. > > I am having trouble understanding your objections to these > text suggestions. Are you really so concerned about an > existing implementation, that violates this text? Is it > really that much effort to make these (very sensible, in my > opinion) changes? I absolutely not. To me I feel that it is already covered and any good implementation would not need all of these SHOULDs. However, I don't have an objection against it. If you read my comments: " I believe there is probably no need for all of these .." At the end, No problem. > > -Pete > > ------_=_NextPart_001_01C373F1.9ABEDA9C Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Friday, September 05, 2003 9:57 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > >  > Is there any scenario that we may be missing and FA may no
>  > > longer having a  > valid unused challenges for a certain
> MN?  > >
>  > > Ah, very good question.  I think we had some text to cover
>  > > this case in one of the proposals, but I subsequently
> deleted it.  > >
>  > > How about:
>  > >
>  > >   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.
>  > >
>  > > -Pete
>  > >
>  >
>  > Let me try to understand what we are trying to propose
> here:  > If RRQ generates MN-AAA authentication, FA MUST not
> invalidate previously  > unused challenges  > 1. FA SHOULD
> include a previously unused challenge in RRP, if present; or 
> > 2. FA SHOULD generate a new challenge., or  > 3. FA does
> not send any of the above SHOULD's and send a new challenge 
> > always.  >
>  > Is not all of the above is already captured very nicely in
> section 2 of  > RFC3012bis:  > "
>  >    The Challenge extension, illustrated in figure 1, is
> inserted in the
>  >    Agent Advertisements by the Foreign Agent, in order to
> communicate
>  >    the latest challenge value that can be used by the mobile node
>  >    to compute an authentication for its next registration request
>  >    message.  The challenge is selected by the foreign
> agent to provide
>  >    local assurance that the mobile node is not replaying
> any earlier
>  >    registration request.
>  > "
>  >
>  > I believe there is probably no need for all of these
> SHOULDs and let us  > leave it as generic as it should be
> with the responsibility of the FA as  > explained in the
> above paragraph.  >
>  > Your thoughts, please.
>
> No, it is not covered by that text.  We are trying to
> eliminate two denial-of-service attacks.  This requires
> restricting the FA implementation so that un-authenticated
> messages do not cause (a) invalidation of previously unused
> challenges, nor (b) creation of state at the FA.  The text
> you quote does not give enough guidance on this.
>
> We need the text that has been suggested in the Security
> Considerations section 12.  I think we also need the text in
> this Appendix E to clarify how the example pseudocode/data
> storage should be handled to meet these security obligations.
>
> I am having trouble understanding your objections to these
> text suggestions.  Are you really so concerned about an
> existing implementation, that violates this text?  Is it
> really that much effort to make these (very sensible, in my
> opinion) changes?


I absolutely not. To me I feel that it is already covered and any good implementation would not need all of these SHOULDs.

However, I don't have an objection against it. If you read my comments:
" I believe there is probably no need for all of these .."

At the end, No problem.
>
> -Pete
>
>

------_=_NextPart_001_01C373F1.9ABEDA9C-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Sep 6 05:24: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 FAA01657 for ; Sat, 6 Sep 2003 05:24: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 19vZIZ-0007a3-9s for mip4-archive@odin.ietf.org; Sat, 06 Sep 2003 05:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h869O3EY029140 for mip4-archive@odin.ietf.org; Sat, 6 Sep 2003 05:24:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vZIY-0007Zv-VP for mip4-web-archive@optimus.ietf.org; Sat, 06 Sep 2003 05:24: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 FAA01633 for ; Sat, 6 Sep 2003 05:23:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vZIV-0002mV-00 for mip4-web-archive@ietf.org; Sat, 06 Sep 2003 05:23:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19vZIV-0002mR-00 for mip4-web-archive@ietf.org; Sat, 06 Sep 2003 05: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 19vZIX-0007ZX-AS; Sat, 06 Sep 2003 05: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 19vZHr-0007Yq-Tz for mip4@optimus.ietf.org; Sat, 06 Sep 2003 05:23:20 -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 FAA01600 for ; Sat, 6 Sep 2003 05:23:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vZHo-0002lT-00 for mip4@ietf.org; Sat, 06 Sep 2003 05:23:16 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19vZHn-0002kd-00 for mip4@ietf.org; Sat, 06 Sep 2003 05:23:15 -0400 Received: (qmail 10485 invoked from network); 5 Sep 2003 00:48:51 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 5 Sep 2003 00:48:51 -0000 Date: Fri, 5 Sep 2003 02:48:50 +0200 From: Henrik Levkowetz To: "'mip4@ietf.org'" Cc: Pete McCann , "Ahmad Muhanna" , "Jayshree Bharatia" Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Message-Id: <20030905024850.5c69d4e8.henrik@levkowetz.com> In-Reply-To: <16215.50408.231347.632353@gargle.gargle.HOWL> References: <16215.50408.231347.632353@gargle.gargle.HOWL> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.8?(0BfO_mYk4Q?" 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: , --=.8?(0BfO_mYk4Q? Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Thursday 4 September 2003, Pete wrote: > Ahmad Muhanna writes: > > > Ahmad Muhanna writes: > > > > > -----Original Message----- > > > > > From: Pete McCann [mailto:mccap@lucent.com] > > > > > Sent: Wednesday, September 03, 2003 5:03 PM > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Cc: 'mip4@ietf.org' > > > > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > > > > > > > > > > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT > > > > INVALIDATING the challenge received in RRQ, why not > > > > sending that challenge (still valid) back in RRP. Is there > > > > a problem with that? > > > > > > That behavior is allowed by the text above, assuming that the > > > challenge received in the RRQ is stored in the data > > > structures given in Appendix E. If not, then what you > > > describe would not be ok, because you would be forcing the FA > > > to use a challenge that it didn't necessarily generate. > > > > > > > Is there any scenario that we may be missing and FA may no longer > > having a valid unused challenges for a certain MN? > > Ah, very good question. I think we had some text to cover this case > in one of the proposals, but I subsequently deleted it. > > How about: > > 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. I think this text is clear and correct. I propose we include this in Appendix E, as proposed. Henrik --=.8?(0BfO_mYk4Q? Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/V91yeVhrtTJkXCMRAo18AKDq1N/SrONWSXBW5zK6p+ZsnNybDACgsRdG W+tJ2GIFdKV+oaDPu8XODc4= =fw8I -----END PGP SIGNATURE----- --=.8?(0BfO_mYk4Q?-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 8 11:58:33 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 LAA04285 for ; Mon, 8 Sep 2003 11:58: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 19wOP3-0001ys-MT for mip4-archive@odin.ietf.org; Mon, 08 Sep 2003 11:58:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88Fw968007610 for mip4-archive@odin.ietf.org; Mon, 8 Sep 2003 11:58:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wOP3-0001yD-Hf for mip4-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 11:58: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 LAA04229 for ; Mon, 8 Sep 2003 11:58:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wOP2-0001tM-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 11:58:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wOP1-0001t2-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 11:58:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wOP0-0001wz-C2; Mon, 08 Sep 2003 11:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wOOI-0001vZ-FE for mip4@optimus.ietf.org; Mon, 08 Sep 2003 11:57:22 -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 LAA04141 for ; Mon, 8 Sep 2003 11:57:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wOOF-0001oy-00 for mip4@ietf.org; Mon, 08 Sep 2003 11:57:19 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19wOOF-0001oC-00 for mip4@ietf.org; Mon, 08 Sep 2003 11:57:19 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h88Fudu23273; Mon, 8 Sep 2003 10:56:39 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h88Fubu26089; Mon, 8 Sep 2003 10:56:38 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16220.42676.628233.182147@gargle.gargle.HOWL> Date: Mon, 8 Sep 2003 10:56:36 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Ok, thanks. Can we proceed with the last text that I suggested for the Security Considerations, and for Appendix E? On the topic of mandatory inclusion of a challenge in the RRP or Agent Advertisement, there seem to be separate proposals from Henrik and myself. I would be ok with either one of these. The main difference seems to be that my text would require a challenge in any reply/advertisement that did NOT have a multicast challenge sent around the same time, while Henrik would leave unspecified exactly what condition you can leave out the challenge from the reply, while mandating inclusion of a challenge in subsequent solicited advertisements if you "have conditions" under which the FA would leave out the challenge from a reply. Any preference from other folks among these alternatives? -Pete Ahmad Muhanna writes: > Hi, Pete, > > Regards, > Ahmad > > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Friday, September 05, 2003 9:57 AM > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > Hi, Ahmad, > > > > Ahmad Muhanna writes: > > > > > Is there any scenario that we may be missing and FA may no > > > > longer having a > valid unused challenges for a certain > > MN? > > > > > > Ah, very good question. I think we had some text to cover > > > > this case in one of the proposals, but I subsequently > > deleted it. > > > > > > How about: > > > > > > > > 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. > > > > > > > > -Pete > > > > > > > > > > Let me try to understand what we are trying to propose > > here: > If RRQ generates MN-AAA authentication, FA MUST not > > invalidate previously > unused challenges > 1. FA SHOULD > > include a previously unused challenge in RRP, if present; or > > > 2. FA SHOULD generate a new challenge., or > 3. FA does > > not send any of the above SHOULD's and send a new challenge > > > always. > > > > Is not all of the above is already captured very nicely in > > section 2 of > RFC3012bis: > " > > > The Challenge extension, illustrated in figure 1, is > > inserted in the > > > Agent Advertisements by the Foreign Agent, in order to > > communicate > > > the latest challenge value that can be used by the mobile node > > > to compute an authentication for its next registration request > > > message. The challenge is selected by the foreign > > agent to provide > > > local assurance that the mobile node is not replaying > > any earlier > > > registration request. > > > " > > > > > > I believe there is probably no need for all of these > > SHOULDs and let us > leave it as generic as it should be > > with the responsibility of the FA as > explained in the > > above paragraph. > > > > Your thoughts, please. > > > > No, it is not covered by that text. We are trying to > > eliminate two denial-of-service attacks. This requires > > restricting the FA implementation so that un-authenticated > > messages do not cause (a) invalidation of previously unused > > challenges, nor (b) creation of state at the FA. The text > > you quote does not give enough guidance on this. > > > > We need the text that has been suggested in the Security > > Considerations section 12. I think we also need the text in > > this Appendix E to clarify how the example pseudocode/data > > storage should be handled to meet these security obligations. > > > > I am having trouble understanding your objections to these > > text suggestions. Are you really so concerned about an > > existing implementation, that violates this text? Is it > > really that much effort to make these (very sensible, in my > > opinion) changes? > > > I absolutely not. To me I feel that it is already covered and any good > implementation would not need all of these SHOULDs. > However, I don't have an objection against it. If you read my comments: > " I believe there is probably no need for all of these .." > > At the end, No problem. > > > > -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 8 13:26: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 NAA09437 for ; Mon, 8 Sep 2003 13:26: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 19wPm8-0005hi-MF for mip4-archive@odin.ietf.org; Mon, 08 Sep 2003 13:26:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88HQ4dT021920 for mip4-archive@odin.ietf.org; Mon, 8 Sep 2003 13:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wPm8-0005hT-EW for mip4-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 13:26: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 NAA09411 for ; Mon, 8 Sep 2003 13:25:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wPm6-0003v5-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 13:26:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wPm5-0003v2-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 13:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wPm6-0005gs-9r; Mon, 08 Sep 2003 13:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wPlh-0005gQ-J1 for mip4@optimus.ietf.org; Mon, 08 Sep 2003 13:25:37 -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 NAA09365 for ; Mon, 8 Sep 2003 13:25:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wPlf-0003ub-00 for mip4@ietf.org; Mon, 08 Sep 2003 13:25:35 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19wPle-0003uF-00 for mip4@ietf.org; Mon, 08 Sep 2003 13:25:34 -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 h88HOwv27445; Mon, 8 Sep 2003 12:24:59 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Sep 2003 12:24:59 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Mon, 8 Sep 2003 12:24:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3762E.1E79F2AC" 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_01C3762E.1E79F2AC Content-Type: text/plain Hi, Pete, I thought that there was another proposal by Jayshree to accept mandating FAC in RRP with no conditional text attached. Since I have not seen any one complaining about backward compatibility by mandating this behavior, I would support mandating the inclusion of FAC in RRP without additional text. At the end someone's code is going to change. Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Monday, September 08, 2003 10:57 AM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Ahmad, > > Ok, thanks. > > Can we proceed with the last text that I suggested for the > Security Considerations, and for Appendix E? > > On the topic of mandatory inclusion of a challenge in the RRP > or Agent Advertisement, there seem to be separate proposals > from Henrik and myself. I would be ok with either one of > these. The main difference seems to be that my text would > require a challenge in any reply/advertisement that did NOT > have a multicast challenge sent around the same time, while > Henrik would leave unspecified exactly what condition you can > leave out the challenge from the reply, while mandating > inclusion of a challenge in subsequent solicited > advertisements if you "have conditions" under which the FA > would leave out the challenge from a reply. Any preference > from other folks among these alternatives? > > -Pete > > > Ahmad Muhanna writes: > > Hi, Pete, > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Friday, September 05, 2003 9:57 AM > > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; > 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal > for Issue2-Change5 > > > > > > > > > > > Hi, Ahmad, > > > > > > Ahmad Muhanna writes: > > > > > > Is there any scenario that we may be missing and > FA may no > > > > > longer having a > valid unused challenges for a certain > > > MN? > > > > > > > Ah, very good question. I think we had some text to cover > > > > > this case in one of the proposals, but I subsequently > > > deleted it. > > > > > > > How about: > > > > > > > > > > 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. > > > > > > > > > > -Pete > > > > > > > > > > > > > Let me try to understand what we are trying to propose > > > here: > If RRQ generates MN-AAA authentication, FA MUST not > > > invalidate previously > unused challenges > 1. FA SHOULD > > > include a previously unused challenge in RRP, if present; or > > > > 2. FA SHOULD generate a new challenge., or > 3. FA does > > > not send any of the above SHOULD's and send a new challenge > > > > always. > > > > > Is not all of the above is already captured very nicely in > > > section 2 of > RFC3012bis: > " > > > > The Challenge extension, illustrated in figure 1, is > > > inserted in the > > > > Agent Advertisements by the Foreign Agent, in order to > > > communicate > > > > the latest challenge value that can be used by the > mobile node > > > > to compute an authentication for its next > registration request > > > > message. The challenge is selected by the foreign > > > agent to provide > > > > local assurance that the mobile node is not replaying > > > any earlier > > > > registration request. > > > > " > > > > > > > > I believe there is probably no need for all of these > > > SHOULDs and let us > leave it as generic as it should be > > > with the responsibility of the FA as > explained in the > > > above paragraph. > > > > > Your thoughts, please. > > > > > > No, it is not covered by that text. We are trying to > > > eliminate two denial-of-service attacks. This requires > > > restricting the FA implementation so that un-authenticated > > > messages do not cause (a) invalidation of previously unused > > > challenges, nor (b) creation of state at the FA. The text > > > you quote does not give enough guidance on this. > > > > > > We need the text that has been suggested in the Security > > > Considerations section 12. I think we also need the text in > > > this Appendix E to clarify how the example pseudocode/data > > > storage should be handled to meet these security > obligations. > > > > > I am having trouble understanding your objections to these > > > text suggestions. Are you really so concerned about an > > > existing implementation, that violates this text? Is it > > > really that much effort to make these (very sensible, in my > > > opinion) changes? > > > > > > I absolutely not. To me I feel that it is already covered > and any good > implementation would not need all of these > SHOULDs. > However, I don't have an objection against it. If > you read my comments: > " I believe there is probably no > need for all of these .." > > > At the end, No problem. > > > > > > -Pete > > ------_=_NextPart_001_01C3762E.1E79F2AC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,
I thought that there was another proposal by = Jayshree to accept mandating FAC in RRP with no conditional text = attached. Since I have not seen any one complaining about backward = compatibility by mandating this behavior, I would support mandating the = inclusion of FAC in RRP without additional text. At the end someone's = code is going to change.

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Monday, September 08, 2003 10:57 = AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; = 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for = Issue2-Change5
>
>
>
> Hi, Ahmad,
>
> Ok, thanks.
>
> Can we proceed with the last text that I = suggested for the
> Security Considerations, and for Appendix = E?
>
> On the topic of mandatory inclusion of a = challenge in the RRP
> or Agent Advertisement, there seem to be = separate proposals
> from Henrik and myself.  I would be ok = with either one of
> these.  The main difference seems to be = that my text would
> require a challenge in any reply/advertisement = that did NOT
> have a multicast challenge sent around the same = time, while
> Henrik would leave unspecified exactly what = condition you can
> leave out the challenge from the reply, while = mandating
> inclusion of a challenge in subsequent = solicited
> advertisements if you "have = conditions" under which the FA
> would leave out the challenge from a = reply.  Any preference
> from other folks among these = alternatives?
>
> -Pete
>
>
> Ahmad Muhanna writes:
>  > Hi, Pete,
>  >
>  > Regards,
>  > Ahmad
>  >
>  >
>  > > -----Original = Message-----
>  > > From: Pete McCann [mailto:mccap@lucent.com]
>  > > Sent: Friday, September 05, = 2003 9:57 AM
>  > > To: Muhanna, Ahmad = [RICH2:2Q30:EXCH]
>  > > Cc: Bharatia, Jayshree = [RICH1:2H13:EXCH];
> 'mip4@ietf.org'  > > Subject: RE: = [Mip4] RFC3012bis: Proposal
> for Issue2-Change5  > >
>  > >
>  > >
>  > > Hi, Ahmad,
>  > >
>  > > Ahmad Muhanna writes:
>  > >  > >  > Is = there any scenario that we may be missing and
> FA may no
>  > >  > > longer having = a  > valid unused challenges for a certain
>  > > MN?  > >
>  > >  > > Ah, very good = question.  I think we had some text to cover
>  > >  > > this case in = one of the proposals, but I subsequently
>  > > deleted it.  > > =
>  > >  > > How = about:
>  > >  > >
>  > >  > >   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.
>  > >  > >
>  > >  > > -Pete
>  > >  > >
>  > >  >
>  > >  > Let me try to = understand what we are trying to propose
>  > > here:  > If RRQ = generates MN-AAA authentication, FA MUST not
>  > > invalidate previously  = > unused challenges  > 1. FA SHOULD
>  > > include a previously unused = challenge in RRP, if present; or 
>  > > > 2. FA SHOULD generate a = new challenge., or  > 3. FA does
>  > > not send any of the above = SHOULD's and send a new challenge 
>  > > > always.  >
>  > >  > Is not all of the = above is already captured very nicely in
>  > > section 2 of  > = RFC3012bis:  > "
>  > >  >    = The Challenge extension, illustrated in figure 1, is
>  > > inserted in the
>  > >  >    = Agent Advertisements by the Foreign Agent, in order to
>  > > communicate
>  > >  >    = the latest challenge value that can be used by the
> mobile node
>  > >  >    to = compute an authentication for its next
> registration request
>  > >  >    = message.  The challenge is selected by the foreign
>  > > agent to provide
>  > >  >    = local assurance that the mobile node is not replaying
>  > > any earlier
>  > >  >    = registration request.
>  > >  > "
>  > >  >
>  > >  > I believe there is = probably no need for all of these
>  > > SHOULDs and let us  > = leave it as generic as it should be
>  > > with the responsibility of the = FA as  > explained in the
>  > > above paragraph.  > =
>  > >  > Your thoughts, = please.
>  > >
>  > > No, it is not covered by that = text.  We are trying to
>  > > eliminate two denial-of-service = attacks.  This requires
>  > > restricting the FA = implementation so that un-authenticated
>  > > messages do not cause (a) = invalidation of previously unused
>  > > challenges, nor (b) creation of = state at the FA.  The text
>  > > you quote does not give enough = guidance on this.
>  > >
>  > > We need the text that has been = suggested in the Security
>  > > Considerations section = 12.  I think we also need the text in
>  > > this Appendix E to clarify how = the example pseudocode/data
>  > > storage should be handled to = meet these security
> obligations.  > >
>  > > I am having trouble = understanding your objections to these
>  > > text suggestions.  Are you = really so concerned about an
>  > > existing implementation, that = violates this text?  Is it
>  > > really that much effort to make = these (very sensible, in my
>  > > opinion) changes?
>  >
>  >
>  > I absolutely not. To me I feel that = it is already covered
> and any good  > implementation would = not need all of these
> SHOULDs.  > However, I don't have an = objection against it. If
> you read my comments:  > " I = believe there is probably no
> need for all of these .."  > =
>  > At the end, No problem.
>  > >
>  > > -Pete
>
>

------_=_NextPart_001_01C3762E.1E79F2AC-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 8 13:36: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 NAA10099 for ; Mon, 8 Sep 2003 13:36: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 19wPvs-00067S-Ij for mip4-archive@odin.ietf.org; Mon, 08 Sep 2003 13:36:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88Ha8qn023516 for mip4-archive@odin.ietf.org; Mon, 8 Sep 2003 13:36:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wPvs-00067D-95 for mip4-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 13:36: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 NAA10064 for ; Mon, 8 Sep 2003 13:36:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wPvq-0004Bi-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 13:36:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wPvp-0004BR-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 13:36:05 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wPvn-00065M-5X; Mon, 08 Sep 2003 13:36:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wPvG-00063h-GS for mip4@optimus.ietf.org; Mon, 08 Sep 2003 13:35: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 NAA10024 for ; Mon, 8 Sep 2003 13:35:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wPvE-0004AW-00 for mip4@ietf.org; Mon, 08 Sep 2003 13:35:28 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19wPvD-00049m-00 for mip4@ietf.org; Mon, 08 Sep 2003 13:35:27 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h88HYpQ20207; Mon, 8 Sep 2003 10:34:51 -0700 X-mProtect: <200309081734> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (10.241.51.35, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdv7Sm3Y; Mon, 08 Sep 2003 10:34:48 PDT Message-ID: <3F5CBDAC.6060200@iprg.nokia.com> Date: Mon, 08 Sep 2003 10:34:36 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ahmad Muhanna CC: "'mip4@ietf.org'" Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5 References: 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 Hello Ahmad, In some previous e-mails, I thought it was concluded that no such mandate was required. I haven't read through all the recent and seemingly tangled threads, but I didn't see anything to suddenly make the mandate. And, surely it is the case that not every Mobile IP RRP needs the challenge, so some conditioning text is guaranteed. Why insert more mandates than are neede? Regards, Charlie P. Ahmad Muhanna wrote: > Hi, Pete, > I thought that there was another proposal by Jayshree to accept > mandating FAC in RRP with no conditional text attached. Since I have > not seen any one complaining about backward compatibility by mandating > this behavior, I would support mandating the inclusion of FAC in RRP > without additional text. At the end someone's code is going to change. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Monday, September 08, 2003 10:57 AM > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > Hi, Ahmad, > > > > Ok, thanks. > > > > Can we proceed with the last text that I suggested for the > > Security Considerations, and for Appendix E? > > > > On the topic of mandatory inclusion of a challenge in the RRP > > or Agent Advertisement, there seem to be separate proposals > > from Henrik and myself. I would be ok with either one of > > these. The main difference seems to be that my text would > > require a challenge in any reply/advertisement that did NOT > > have a multicast challenge sent around the same time, while > > Henrik would leave unspecified exactly what condition you can > > leave out the challenge from the reply, while mandating > > inclusion of a challenge in subsequent solicited > > advertisements if you "have conditions" under which the FA > > would leave out the challenge from a reply. Any preference > > from other folks among these alternatives? > > > > -Pete > > > > > > Ahmad Muhanna writes: > > > Hi, Pete, > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Pete McCann [mailto:mccap@lucent.com] > > > > Sent: Friday, September 05, 2003 9:57 AM > > > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; > > 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal > > for Issue2-Change5 > > > > > > > > > > > > > > Hi, Ahmad, > > > > > > > > Ahmad Muhanna writes: > > > > > > > Is there any scenario that we may be missing and > > FA may no > > > > > > longer having a > valid unused challenges for a certain > > > > MN? > > > > > > > > Ah, very good question. I think we had some text to cover > > > > > > this case in one of the proposals, but I subsequently > > > > deleted it. > > > > > > > > How about: > > > > > > > > > > > > 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. > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > > > Let me try to understand what we are trying to propose > > > > here: > If RRQ generates MN-AAA authentication, FA MUST not > > > > invalidate previously > unused challenges > 1. FA SHOULD > > > > include a previously unused challenge in RRP, if present; or > > > > > 2. FA SHOULD generate a new challenge., or > 3. FA does > > > > not send any of the above SHOULD's and send a new challenge > > > > > always. > > > > > > Is not all of the above is already captured very nicely in > > > > section 2 of > RFC3012bis: > " > > > > > The Challenge extension, illustrated in figure 1, is > > > > inserted in the > > > > > Agent Advertisements by the Foreign Agent, in order to > > > > communicate > > > > > the latest challenge value that can be used by the > > mobile node > > > > > to compute an authentication for its next > > registration request > > > > > message. The challenge is selected by the foreign > > > > agent to provide > > > > > local assurance that the mobile node is not replaying > > > > any earlier > > > > > registration request. > > > > > " > > > > > > > > > > I believe there is probably no need for all of these > > > > SHOULDs and let us > leave it as generic as it should be > > > > with the responsibility of the FA as > explained in the > > > > above paragraph. > > > > > > Your thoughts, please. > > > > > > > > No, it is not covered by that text. We are trying to > > > > eliminate two denial-of-service attacks. This requires > > > > restricting the FA implementation so that un-authenticated > > > > messages do not cause (a) invalidation of previously unused > > > > challenges, nor (b) creation of state at the FA. The text > > > > you quote does not give enough guidance on this. > > > > > > > > We need the text that has been suggested in the Security > > > > Considerations section 12. I think we also need the text in > > > > this Appendix E to clarify how the example pseudocode/data > > > > storage should be handled to meet these security > > obligations. > > > > > > I am having trouble understanding your objections to these > > > > text suggestions. Are you really so concerned about an > > > > existing implementation, that violates this text? Is it > > > > really that much effort to make these (very sensible, in my > > > > opinion) changes? > > > > > > > > > I absolutely not. To me I feel that it is already covered > > and any good > implementation would not need all of these > > SHOULDs. > However, I don't have an objection against it. If > > you read my comments: > " I believe there is probably no > > need for all of these .." > > > > At the end, No problem. > > > > > > > > -Pete > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 8 14:22: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 OAA12283 for ; Mon, 8 Sep 2003 14:22: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 19wQeI-00005V-FR for mip4-archive@odin.ietf.org; Mon, 08 Sep 2003 14:22:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88IM2JM000331 for mip4-archive@odin.ietf.org; Mon, 8 Sep 2003 14:22:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQeI-00005G-B0 for mip4-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 14:22: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 OAA12249 for ; Mon, 8 Sep 2003 14:21:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQeF-00052A-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 14:21:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wQeF-000527-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 14:21:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQeH-0008WC-6j; Mon, 08 Sep 2003 14:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wQeE-0008Vy-Mb for mip4@optimus.ietf.org; Mon, 08 Sep 2003 14:21:58 -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 OAA12246 for ; Mon, 8 Sep 2003 14:21:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wQeB-000523-00 for mip4@ietf.org; Mon, 08 Sep 2003 14:21:55 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19wQeB-00051d-00 for mip4@ietf.org; Mon, 08 Sep 2003 14:21:55 -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.0/Switch-2.2.0) with ESMTP id h88IL2910866; Mon, 8 Sep 2003 13:21:09 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h88IKxu09159; Mon, 8 Sep 2003 13:21:00 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16220.51336.242081.596140@gargle.gargle.HOWL> Date: Mon, 8 Sep 2003 13:20:56 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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, Sure, that's also a valid approach. Any comments from others on which of the three we should adopt? -Pete Ahmad Muhanna writes: > Hi, Pete, > I thought that there was another proposal by Jayshree to accept mandating > FAC in RRP with no conditional text attached. Since I have not seen any one > complaining about backward compatibility by mandating this behavior, I would > support mandating the inclusion of FAC in RRP without additional text. At > the end someone's code is going to change. > > Regards, > Ahmad > > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Monday, September 08, 2003 10:57 AM > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > Hi, Ahmad, > > > > Ok, thanks. > > > > Can we proceed with the last text that I suggested for the > > Security Considerations, and for Appendix E? > > > > On the topic of mandatory inclusion of a challenge in the RRP > > or Agent Advertisement, there seem to be separate proposals > > from Henrik and myself. I would be ok with either one of > > these. The main difference seems to be that my text would > > require a challenge in any reply/advertisement that did NOT > > have a multicast challenge sent around the same time, while > > Henrik would leave unspecified exactly what condition you can > > leave out the challenge from the reply, while mandating > > inclusion of a challenge in subsequent solicited > > advertisements if you "have conditions" under which the FA > > would leave out the challenge from a reply. Any preference > > from other folks among these alternatives? > > > > -Pete > > > > > > Ahmad Muhanna writes: > > > Hi, Pete, > > > > > > Regards, > > > Ahmad > > > > > > > > > > -----Original Message----- > > > > From: Pete McCann [mailto:mccap@lucent.com] > > > > Sent: Friday, September 05, 2003 9:57 AM > > > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; > > 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal > > for Issue2-Change5 > > > > > > > > > > > > > > Hi, Ahmad, > > > > > > > > Ahmad Muhanna writes: > > > > > > > Is there any scenario that we may be missing and > > FA may no > > > > > > longer having a > valid unused challenges for a certain > > > > MN? > > > > > > > > Ah, very good question. I think we had some text to cover > > > > > > this case in one of the proposals, but I subsequently > > > > deleted it. > > > > > > > > How about: > > > > > > > > > > > > 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. > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > > > Let me try to understand what we are trying to propose > > > > here: > If RRQ generates MN-AAA authentication, FA MUST not > > > > invalidate previously > unused challenges > 1. FA SHOULD > > > > include a previously unused challenge in RRP, if present; or > > > > > 2. FA SHOULD generate a new challenge., or > 3. FA does > > > > not send any of the above SHOULD's and send a new challenge > > > > > always. > > > > > > Is not all of the above is already captured very nicely in > > > > section 2 of > RFC3012bis: > " > > > > > The Challenge extension, illustrated in figure 1, is > > > > inserted in the > > > > > Agent Advertisements by the Foreign Agent, in order to > > > > communicate > > > > > the latest challenge value that can be used by the > > mobile node > > > > > to compute an authentication for its next > > registration request > > > > > message. The challenge is selected by the foreign > > > > agent to provide > > > > > local assurance that the mobile node is not replaying > > > > any earlier > > > > > registration request. > > > > > " > > > > > > > > > > I believe there is probably no need for all of these > > > > SHOULDs and let us > leave it as generic as it should be > > > > with the responsibility of the FA as > explained in the > > > > above paragraph. > > > > > > Your thoughts, please. > > > > > > > > No, it is not covered by that text. We are trying to > > > > eliminate two denial-of-service attacks. This requires > > > > restricting the FA implementation so that un-authenticated > > > > messages do not cause (a) invalidation of previously unused > > > > challenges, nor (b) creation of state at the FA. The text > > > > you quote does not give enough guidance on this. > > > > > > > > We need the text that has been suggested in the Security > > > > Considerations section 12. I think we also need the text in > > > > this Appendix E to clarify how the example pseudocode/data > > > > storage should be handled to meet these security > > obligations. > > > > > > I am having trouble understanding your objections to these > > > > text suggestions. Are you really so concerned about an > > > > existing implementation, that violates this text? Is it > > > > really that much effort to make these (very sensible, in my > > > > opinion) changes? > > > > > > > > > I absolutely not. To me I feel that it is already covered > > and any good > implementation would not need all of these > > SHOULDs. > However, I don't have an objection against it. If > > you read my comments: > " I believe there is probably no > > need for all of these .." > > > > At the end, No problem. > > > > > > > > -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 8 14: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 OAA13627 for ; Mon, 8 Sep 2003 14:46: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 19wR1Z-000143-Pf for mip4-archive@odin.ietf.org; Mon, 08 Sep 2003 14:46:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88Ik57F004085 for mip4-archive@odin.ietf.org; Mon, 8 Sep 2003 14: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 19wR1Z-00013o-Kt for mip4-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 14: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 OAA13602 for ; Mon, 8 Sep 2003 14:45:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wR1T-0005Y4-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 14:45:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wR1T-0005Y1-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 14:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wR1U-00012i-Mr; Mon, 08 Sep 2003 14:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wR1A-00011v-JY for mip4@optimus.ietf.org; Mon, 08 Sep 2003 14:45:40 -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 OAA13595 for ; Mon, 8 Sep 2003 14:45:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wR17-0005Xr-00 for mip4@ietf.org; Mon, 08 Sep 2003 14:45:37 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19wR16-0005XS-00 for mip4@ietf.org; Mon, 08 Sep 2003 14:45:36 -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 h88Iivv19191; Mon, 8 Sep 2003 13:44:57 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Sep 2003 13:44:58 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Charlie Perkins'" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Mon, 8 Sep 2003 13:44:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37639.46A80BDC" 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_01C37639.46A80BDC Content-Type: text/plain Hello Charlie, No problem, I am fine with the consensus on the mailing list. Regards, Ahmad > -----Original Message----- > From: Charlie Perkins [mailto:charliep@iprg.nokia.com] > Sent: Monday, September 08, 2003 12:35 PM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: 'mip4@ietf.org' > Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hello Ahmad, > > In some previous e-mails, I thought it was concluded that no > such mandate was required. I haven't read through all the > recent and seemingly tangled threads, but I didn't see > anything to suddenly make the mandate. And, surely it is the > case that not every Mobile IP RRP needs the challenge, so > some conditioning text is guaranteed. Why insert more > mandates than are neede? > > Regards, > Charlie P. > > > Ahmad Muhanna wrote: > > > Hi, Pete, > > I thought that there was another proposal by Jayshree to accept > > mandating FAC in RRP with no conditional text attached. > Since I have > > not seen any one complaining about backward compatibility > by mandating > > this behavior, I would support mandating the inclusion of > FAC in RRP > > without additional text. At the end someone's code is going > to change. > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Monday, September 08, 2003 10:57 AM > > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > > > > > Hi, Ahmad, > > > > > > Ok, thanks. > > > > > > Can we proceed with the last text that I suggested for > the Security > > > Considerations, and for Appendix E? > > > > > > On the topic of mandatory inclusion of a challenge in the RRP or > > > Agent Advertisement, there seem to be separate proposals > from Henrik > > > and myself. I would be ok with either one of these. The main > > > difference seems to be that my text would require a > challenge in any > > > reply/advertisement that did NOT have a multicast challenge sent > > > around the same time, while Henrik would leave > unspecified exactly > > > what condition you can leave out the challenge from the > reply, while > > > mandating inclusion of a challenge in subsequent solicited > > > advertisements if you "have conditions" under which the FA > > > would leave out the challenge from a reply. Any preference > > > from other folks among these alternatives? > > > > > > -Pete > > > > > > > > > Ahmad Muhanna writes: > > > > Hi, Pete, > > > > > > > > Regards, > > > > Ahmad > > > > > > > > > > > > > -----Original Message----- > > > > > From: Pete McCann [mailto:mccap@lucent.com] > > > > > Sent: Friday, September 05, 2003 9:57 AM > > > > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; > 'mip4@ietf.org' > > > > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > > > > > > > > > > > > > > Hi, Ahmad, > > > > > > > > > > Ahmad Muhanna writes: > > > > > > > > Is there any scenario that we may be missing and > > > FA may no > > > > > > > longer having a > valid unused challenges for a certain > > > > > MN? > > > > > > > > > Ah, very good question. I think we had some > text to cover > > > > > > > this case in one of the proposals, but I subsequently > > > > > deleted it. > > > > > > > > > How about: > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > -Pete > > > > > > > > > > > > > > > > > > > Let me try to understand what we are trying to propose > > > > > here: > If RRQ generates MN-AAA authentication, FA MUST not > > > > > invalidate previously > unused challenges > 1. FA SHOULD > > > > > include a previously unused challenge in RRP, if present; or > > > > > > 2. FA SHOULD generate a new challenge., or > 3. FA does > > > > > not send any of the above SHOULD's and send a new challenge > > > > > > always. > > > > > > > Is not all of the above is already captured very nicely in > > > > > section 2 of > RFC3012bis: > " > > > > > > The Challenge extension, illustrated in figure 1, is > > > > > inserted in the > > > > > > Agent Advertisements by the Foreign Agent, in order to > > > > > communicate > > > > > > the latest challenge value that can be used by the > > > mobile node > > > > > > to compute an authentication for its next > > > registration request > > > > > > message. The challenge is selected by the foreign > > > > > agent to provide > > > > > > local assurance that the mobile node is not replaying > > > > > any earlier > > > > > > registration request. > > > > > > " > > > > > > > > > > > > I believe there is probably no need for all of these > > > > > SHOULDs and let us > leave it as generic as it should be > > > > > with the responsibility of the FA as > explained in the > > > > > above paragraph. > > > > > > > Your thoughts, please. > > > > > > > > > > No, it is not covered by that text. We are trying to > > > > > eliminate two denial-of-service attacks. This requires > > > > > restricting the FA implementation so that un-authenticated > > > > > messages do not cause (a) invalidation of previously unused > > > > > challenges, nor (b) creation of state at the FA. The text > > > > > you quote does not give enough guidance on this. > > > > > > > > > > We need the text that has been suggested in the Security > > > > > Considerations section 12. I think we also need the text in > > > > > this Appendix E to clarify how the example pseudocode/data > > > > > storage should be handled to meet these security > > > obligations. > > > > > > > I am having trouble understanding your objections to these > > > > > text suggestions. Are you really so concerned about an > > > > > existing implementation, that violates this text? Is it > > > > > really that much effort to make these (very sensible, in my > > > > > opinion) changes? > > > > > > > > > > > > I absolutely not. To me I feel that it is already covered > > > and any good > implementation would not need all of these > > > SHOULDs. > However, I don't have an objection against it. If > > > you read my comments: > " I believe there is probably no > > > need for all of these .." > > > > > At the end, No problem. > > > > > > > > > > -Pete > > > > > > > > > > > ------_=_NextPart_001_01C37639.46A80BDC Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hello Charlie,

No problem, I am fine with the consensus on the mailing list.

Regards,
Ahmad


> -----Original Message-----
> From: Charlie Perkins [mailto:charliep@iprg.nokia.com]
> Sent: Monday, September 08, 2003 12:35 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: 'mip4@ietf.org'
> Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
>
> Hello Ahmad,
>
> In some previous e-mails, I thought it was concluded that no
> such mandate was required.  I haven't read through all the
> recent and seemingly tangled threads, but I didn't see
> anything to suddenly make the mandate.  And, surely it is the
> case that not every Mobile IP RRP needs the challenge, so
> some conditioning text is guaranteed.  Why insert more
> mandates than are neede?
>
> Regards,
> Charlie P.
>
>
> Ahmad Muhanna wrote:
>
> > Hi, Pete,
> > I thought that there was another proposal by Jayshree to accept
> > mandating FAC in RRP with no conditional text attached.
> Since I have
> > not seen any one complaining about backward compatibility
> by mandating
> > this behavior, I would support mandating the inclusion of
> FAC in RRP
> > without additional text. At the end someone's code is going
> to change.
> >
> > Regards,
> > Ahmad
> >
> >
> > > -----Original Message-----
> > > From: Pete McCann [mailto:mccap@lucent.com]
> > > Sent: Monday, September 08, 2003 10:57 AM
> > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org'
> > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
> > >
> > >
> > >
> > > Hi, Ahmad,
> > >
> > > Ok, thanks.
> > >
> > > Can we proceed with the last text that I suggested for
> the Security
> > > Considerations, and for Appendix E?
> > >
> > > On the topic of mandatory inclusion of a challenge in the RRP or
> > > Agent Advertisement, there seem to be separate proposals
> from Henrik
> > > and myself.  I would be ok with either one of these.  The main
> > > difference seems to be that my text would require a
> challenge in any
> > > reply/advertisement that did NOT have a multicast challenge sent
> > > around the same time, while Henrik would leave
> unspecified exactly
> > > what condition you can leave out the challenge from the
> reply, while
> > > mandating inclusion of a challenge in subsequent solicited
> > > advertisements if you "have conditions" under which the FA
> > > would leave out the challenge from a reply.  Any preference
> > > from other folks among these alternatives?
> > >
> > > -Pete
> > >
> > >
> > > Ahmad Muhanna writes:
> > >  > Hi, Pete,
> > >  >
> > >  > Regards,
> > >  > Ahmad
> > >  >
> > >  >
> > >  > > -----Original Message-----
> > >  > > From: Pete McCann [mailto:mccap@lucent.com]
> > >  > > Sent: Friday, September 05, 2003 9:57 AM
> > >  > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> > >  > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH];
> 'mip4@ietf.org'  > >
> > > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5  > >
> > >  > >
> > >  > >
> > >  > > Hi, Ahmad,
> > >  > >
> > >  > > Ahmad Muhanna writes:
> > >  > >  > >  > Is there any scenario that we may be missing and
> > > FA may no
> > >  > >  > > longer having a  > valid unused challenges for a certain
> > >  > > MN?  > >
> > >  > >  > > Ah, very good question.  I think we had some
> text to cover
> > >  > >  > > this case in one of the proposals, but I subsequently
> > >  > > deleted it.  > >
> > >  > >  > > How about:
> > >  > >  > >
> > >  > >  > >   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.
> > >  > >  > >
> > >  > >  > > -Pete
> > >  > >  > >
> > >  > >  >
> > >  > >  > Let me try to understand what we are trying to propose
> > >  > > here:  > If RRQ generates MN-AAA authentication, FA MUST not
> > >  > > invalidate previously  > unused challenges  > 1. FA SHOULD
> > >  > > include a previously unused challenge in RRP, if present; or
> > >  > > > 2. FA SHOULD generate a new challenge., or  > 3. FA does
> > >  > > not send any of the above SHOULD's and send a new challenge
> > >  > > > always.  >
> > >  > >  > Is not all of the above is already captured very nicely in
> > >  > > section 2 of  > RFC3012bis:  > "
> > >  > >  >    The Challenge extension, illustrated in figure 1, is
> > >  > > inserted in the
> > >  > >  >    Agent Advertisements by the Foreign Agent, in order to
> > >  > > communicate
> > >  > >  >    the latest challenge value that can be used by the
> > > mobile node
> > >  > >  >    to compute an authentication for its next
> > > registration request
> > >  > >  >    message.  The challenge is selected by the foreign
> > >  > > agent to provide
> > >  > >  >    local assurance that the mobile node is not replaying
> > >  > > any earlier
> > >  > >  >    registration request.
> > >  > >  > "
> > >  > >  >
> > >  > >  > I believe there is probably no need for all of these
> > >  > > SHOULDs and let us  > leave it as generic as it should be
> > >  > > with the responsibility of the FA as  > explained in the
> > >  > > above paragraph.  >
> > >  > >  > Your thoughts, please.
> > >  > >
> > >  > > No, it is not covered by that text.  We are trying to
> > >  > > eliminate two denial-of-service attacks.  This requires
> > >  > > restricting the FA implementation so that un-authenticated
> > >  > > messages do not cause (a) invalidation of previously unused
> > >  > > challenges, nor (b) creation of state at the FA.  The text
> > >  > > you quote does not give enough guidance on this.
> > >  > >
> > >  > > We need the text that has been suggested in the Security
> > >  > > Considerations section 12.  I think we also need the text in
> > >  > > this Appendix E to clarify how the example pseudocode/data
> > >  > > storage should be handled to meet these security
> > > obligations.  > >
> > >  > > I am having trouble understanding your objections to these
> > >  > > text suggestions.  Are you really so concerned about an
> > >  > > existing implementation, that violates this text?  Is it
> > >  > > really that much effort to make these (very sensible, in my
> > >  > > opinion) changes?
> > >  >
> > >  >
> > >  > I absolutely not. To me I feel that it is already covered
> > > and any good  > implementation would not need all of these
> > > SHOULDs.  > However, I don't have an objection against it. If
> > > you read my comments:  > " I believe there is probably no
> > > need for all of these .."  >
> > >  > At the end, No problem.
> > >  > >
> > >  > > -Pete
> > >
> > >
> >
>
>
>

------_=_NextPart_001_01C37639.46A80BDC-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 8 16:25:41 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 QAA19265 for ; Mon, 8 Sep 2003 16:25:40 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSZZ-0004uz-4d for mip4-archive@odin.ietf.org; Mon, 08 Sep 2003 16:25:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88KPHDk018901 for mip4-archive@odin.ietf.org; Mon, 8 Sep 2003 16:25:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSZY-0004ul-NO for mip4-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 16:25:17 -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 QAA18962 for ; Mon, 8 Sep 2003 16:24:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wSZJ-0007Je-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 16:25:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19wSYr-0007GI-00 for mip4-web-archive@ietf.org; Mon, 08 Sep 2003 16:24:33 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSYT-0004Lu-Rv; Mon, 08 Sep 2003 16:24:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wRsR-0003O0-HW for mip4@optimus.ietf.org; Mon, 08 Sep 2003 15:40:43 -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 PAA17478 for ; Mon, 8 Sep 2003 15:40:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wRsP-0006fY-00 for mip4@ietf.org; Mon, 08 Sep 2003 15:40:41 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19wRsO-0006ez-00 for mip4@ietf.org; Mon, 08 Sep 2003 15:40:40 -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 h88Je4v08389; Mon, 8 Sep 2003 14:40:04 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Sep 2003 14:40:05 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Mon, 8 Sep 2003 14:39:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37640.FCD636AC" 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_01C37640.FCD636AC Content-Type: text/plain Hi, Pete, Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Monday, September 08, 2003 10:57 AM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Ahmad, > > Ok, thanks. > > Can we proceed with the last text that I suggested for the > Security Considerations, and for Appendix E? > I probably missed this one. I am OK with this one. > On the topic of mandatory inclusion of a challenge in the RRP > or Agent Advertisement, there seem to be separate proposals > from Henrik and myself. I would be ok with either one of > these. The main difference seems to be that my text would > require a challenge in any reply/advertisement that did NOT > have a multicast challenge sent around the same time, while > Henrik would leave unspecified exactly what condition you can > leave out the challenge from the reply, while mandating > inclusion of a challenge in subsequent solicited > advertisements if you "have conditions" under which the FA > would leave out the challenge from a reply. Any preference > from other folks among these alternatives? > > -Pete > > > Ahmad Muhanna writes: > > Hi, Pete, > > > > Regards, > > Ahmad > > > > > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Friday, September 05, 2003 9:57 AM > > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; > 'mip4@ietf.org' > > Subject: RE: [Mip4] RFC3012bis: Proposal > for Issue2-Change5 > > > > > > > > > > > Hi, Ahmad, > > > > > > Ahmad Muhanna writes: > > > > > > Is there any scenario that we may be missing and > FA may no > > > > > longer having a > valid unused challenges for a certain > > > MN? > > > > > > > Ah, very good question. I think we had some text to cover > > > > > this case in one of the proposals, but I subsequently > > > deleted it. > > > > > > > How about: > > > > > > > > > > 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. > > > > > > > > > > -Pete > > > > > > > > > > > > > Let me try to understand what we are trying to propose > > > here: > If RRQ generates MN-AAA authentication, FA MUST not > > > invalidate previously > unused challenges > 1. FA SHOULD > > > include a previously unused challenge in RRP, if present; or > > > > 2. FA SHOULD generate a new challenge., or > 3. FA does > > > not send any of the above SHOULD's and send a new challenge > > > > always. > > > > > Is not all of the above is already captured very nicely in > > > section 2 of > RFC3012bis: > " > > > > The Challenge extension, illustrated in figure 1, is > > > inserted in the > > > > Agent Advertisements by the Foreign Agent, in order to > > > communicate > > > > the latest challenge value that can be used by the > mobile node > > > > to compute an authentication for its next > registration request > > > > message. The challenge is selected by the foreign > > > agent to provide > > > > local assurance that the mobile node is not replaying > > > any earlier > > > > registration request. > > > > " > > > > > > > > I believe there is probably no need for all of these > > > SHOULDs and let us > leave it as generic as it should be > > > with the responsibility of the FA as > explained in the > > > above paragraph. > > > > > Your thoughts, please. > > > > > > No, it is not covered by that text. We are trying to > > > eliminate two denial-of-service attacks. This requires > > > restricting the FA implementation so that un-authenticated > > > messages do not cause (a) invalidation of previously unused > > > challenges, nor (b) creation of state at the FA. The text > > > you quote does not give enough guidance on this. > > > > > > We need the text that has been suggested in the Security > > > Considerations section 12. I think we also need the text in > > > this Appendix E to clarify how the example pseudocode/data > > > storage should be handled to meet these security > obligations. > > > > > I am having trouble understanding your objections to these > > > text suggestions. Are you really so concerned about an > > > existing implementation, that violates this text? Is it > > > really that much effort to make these (very sensible, in my > > > opinion) changes? > > > > > > I absolutely not. To me I feel that it is already covered > and any good > implementation would not need all of these > SHOULDs. > However, I don't have an objection against it. If > you read my comments: > " I believe there is probably no > need for all of these .." > > > At the end, No problem. > > > > > > -Pete > > ------_=_NextPart_001_01C37640.FCD636AC Content-Type: text/html RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Monday, September 08, 2003 10:57 AM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Bharatia, Jayshree [RICH1:2H13:EXCH]; 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5
>
>
>
> Hi, Ahmad,
>
> Ok, thanks.
>
> Can we proceed with the last text that I suggested for the
> Security Considerations, and for Appendix E?
>

I probably missed this one. I am OK with this one.
 
> On the topic of mandatory inclusion of a challenge in the RRP
> or Agent Advertisement, there seem to be separate proposals
> from Henrik and myself.  I would be ok with either one of
> these.  The main difference seems to be that my text would
> require a challenge in any reply/advertisement that did NOT
> have a multicast challenge sent around the same time, while
> Henrik would leave unspecified exactly what condition you can
> leave out the challenge from the reply, while mandating
> inclusion of a challenge in subsequent solicited
> advertisements if you "have conditions" under which the FA
> would leave out the challenge from a reply.  Any preference
> from other folks among these alternatives?
>
> -Pete
>
>
> Ahmad Muhanna writes:
>  > Hi, Pete,
>  >
>  > Regards,
>  > Ahmad
>  >
>  >
>  > > -----Original Message-----
>  > > From: Pete McCann [mailto:mccap@lucent.com]
>  > > Sent: Friday, September 05, 2003 9:57 AM
>  > > To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
>  > > Cc: Bharatia, Jayshree [RICH1:2H13:EXCH];
> 'mip4@ietf.org'  > > Subject: RE: [Mip4] RFC3012bis: Proposal
> for Issue2-Change5  > >
>  > >
>  > >
>  > > Hi, Ahmad,
>  > >
>  > > Ahmad Muhanna writes:
>  > >  > >  > Is there any scenario that we may be missing and
> FA may no
>  > >  > > longer having a  > valid unused challenges for a certain
>  > > MN?  > >
>  > >  > > Ah, very good question.  I think we had some text to cover
>  > >  > > this case in one of the proposals, but I subsequently
>  > > deleted it.  > >
>  > >  > > How about:
>  > >  > >
>  > >  > >   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.
>  > >  > >
>  > >  > > -Pete
>  > >  > >
>  > >  >
>  > >  > Let me try to understand what we are trying to propose
>  > > here:  > If RRQ generates MN-AAA authentication, FA MUST not
>  > > invalidate previously  > unused challenges  > 1. FA SHOULD
>  > > include a previously unused challenge in RRP, if present; or 
>  > > > 2. FA SHOULD generate a new challenge., or  > 3. FA does
>  > > not send any of the above SHOULD's and send a new challenge 
>  > > > always.  >
>  > >  > Is not all of the above is already captured very nicely in
>  > > section 2 of  > RFC3012bis:  > "
>  > >  >    The Challenge extension, illustrated in figure 1, is
>  > > inserted in the
>  > >  >    Agent Advertisements by the Foreign Agent, in order to
>  > > communicate
>  > >  >    the latest challenge value that can be used by the
> mobile node
>  > >  >    to compute an authentication for its next
> registration request
>  > >  >    message.  The challenge is selected by the foreign
>  > > agent to provide
>  > >  >    local assurance that the mobile node is not replaying
>  > > any earlier
>  > >  >    registration request.
>  > >  > "
>  > >  >
>  > >  > I believe there is probably no need for all of these
>  > > SHOULDs and let us  > leave it as generic as it should be
>  > > with the responsibility of the FA as  > explained in the
>  > > above paragraph.  >
>  > >  > Your thoughts, please.
>  > >
>  > > No, it is not covered by that text.  We are trying to
>  > > eliminate two denial-of-service attacks.  This requires
>  > > restricting the FA implementation so that un-authenticated
>  > > messages do not cause (a) invalidation of previously unused
>  > > challenges, nor (b) creation of state at the FA.  The text
>  > > you quote does not give enough guidance on this.
>  > >
>  > > We need the text that has been suggested in the Security
>  > > Considerations section 12.  I think we also need the text in
>  > > this Appendix E to clarify how the example pseudocode/data
>  > > storage should be handled to meet these security
> obligations.  > >
>  > > I am having trouble understanding your objections to these
>  > > text suggestions.  Are you really so concerned about an
>  > > existing implementation, that violates this text?  Is it
>  > > really that much effort to make these (very sensible, in my
>  > > opinion) changes?
>  >
>  >
>  > I absolutely not. To me I feel that it is already covered
> and any good  > implementation would not need all of these
> SHOULDs.  > However, I don't have an objection against it. If
> you read my comments:  > " I believe there is probably no
> need for all of these .."  >
>  > At the end, No problem.
>  > >
>  > > -Pete
>
>

------_=_NextPart_001_01C37640.FCD636AC-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 11 06:01: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 GAA16819 for ; Thu, 11 Sep 2003 06:01: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 19xOG6-00085f-Hr for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 06:01:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BA12QJ031093 for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 06: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 19xOG6-00085Q-Dl for mip4-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 06: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 GAA16791 for ; Thu, 11 Sep 2003 06:00:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xOG2-0007VD-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 06:00:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xOG2-0007V9-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 06:00:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xOG4-00084o-QG; Thu, 11 Sep 2003 06:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xOFL-000846-5l for mip4@optimus.ietf.org; Thu, 11 Sep 2003 06:00:15 -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 GAA16781 for ; Thu, 11 Sep 2003 06:00:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xOFH-0007Uu-00 for mip4@ietf.org; Thu, 11 Sep 2003 06:00:11 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19xOFG-0007Ur-00 for mip4@ietf.org; Thu, 11 Sep 2003 06:00:10 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h8BA0BK26245 for ; Thu, 11 Sep 2003 12:00:11 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F6047A7.4090206@comnets.uni-bremen.de> Date: Thu, 11 Sep 2003 12:00:07 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] home registrations and regional registrations question Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit It seems that I am having a problem telling the difference between home and regional registrations and whose IP address goes in the COA field of the registration request. I have taken a couple of paragraphs from the "draft-ietf-mobileip-reg-tunnel-04.txt" document to explain the reason for my confusion. I would be very grateful if one would clear this one out for me. In section "5. Regional Registration", page 11 we find: ... "Then, the mobile node can perform a regional registration with this foreign agent and GFA. The mobile node issues a Regional Registration Request message to the GFA via the new foreign agent." ... ... and below that: ... "The care-of address should be set to the address of the local foreign agent, or else zero if the local foreign agent is not advertising its own care-of address." ... I am under the impression that the aforementioned segment refers to regional registrations, if so then should perhaps the last paragraph read as stated in section "4.1. Mobile Node Considerations", page 8, that: " If the mobile node determines that it is in a visited domain, it SHOULD either use the advertised GFA address in the care-of address field in the Registration Request message, or set this field to zero to request to be assigned a GFA" Otherwise, how is the FA supposed to figure out what GFA to relay the registration request to? From what I gather, if the mobile node wants to do a home registration, then it places the FA's address in the COA field of the RegReq. On receipt by the FA, the RegReq is forwarded to the HA avoiding the GFA. If the mobile node wishes to make a regional registration it places the selected GFA's address in the COA field of the RegReq. This forces the FA to relay the RegReq to the GFA, who in turn terminates it and issues a RegReply. If that is correct, and assuming that all RegReqs with the purpose of renewing the lifetime of a binding are home registrations then a GFA would never come across such a registration and expire bindings. If that model of operations is not correct, then all RegReqs (home registrations or not) must go through the GFA. But then two questions arise, how does the FA know what GFA to forward the RegReq to and how does the GFA know which RegReqs to forward to the HA and which not? The first question is based on information given in a paragraph of section "5. Regional registration", page 12 that states: "If the advertised GFA is not the same as the one the mobile node has registered as its care-of address, and if the mobile node is still within the same domain as it was when it registered that care-of address, the mobile node MAY try to perform a regional registration with its registered GFA." From this it is derived that a hierarchy may host multiple GFAs. As such, on receipt of RegReq a FA would not explicitly know what GFA to forward it to. Best Regards niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 11 08:42: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 IAA20297 for ; Thu, 11 Sep 2003 08:42: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 19xQlw-0004ok-PM for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 08:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BCg4Jv018508 for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 08:42:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQlw-0004oQ-IK for mip4-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 08:42: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 IAA20288 for ; Thu, 11 Sep 2003 08:41:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xQlv-0000r4-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 08:42:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xQlu-0000r1-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 08:42:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQlt-0004o7-29; Thu, 11 Sep 2003 08: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 19xQlY-0004nj-7J for mip4@optimus.ietf.org; Thu, 11 Sep 2003 08:41:40 -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 IAA20282 for ; Thu, 11 Sep 2003 08:41:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xQlW-0000qt-00 for mip4@ietf.org; Thu, 11 Sep 2003 08:41:38 -0400 Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx with esmtp (Exim 4.12) id 19xQlW-0000qd-00 for mip4@ietf.org; Thu, 11 Sep 2003 08:41:38 -0400 Received: from sgowanD2.bbn.com (dhcp89-069-097.bbn.com [128.89.69.97]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8BCf70w027428; Thu, 11 Sep 2003 08:41:07 -0400 (EDT) Message-Id: <5.1.0.14.2.20030911083507.03b53850@po2.bbn.com> X-Sender: sgowan@po2.bbn.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Sep 2003 08:35:19 -0400 To: mip4@ietf.org From: Sharon Gowan Cc: sharon Gowan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Subject: [Mip4] How widely deployed is MIPv4? 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: , Hi: I am new to this mailing list and am interested in learning how widely MIPv4 has been deployed in commercial networks. The home page for this working group claims that MIPv4 is being deployed on a wide basis. Does anyone have any details on the basis of this statement? Many thanks, Sharon _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 11 15:58: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 PAA11514 for ; Thu, 11 Sep 2003 15:58: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 19xXZr-0005Qb-ML for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 15:58:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BJw3Tp020861 for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 15:58:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xXZr-0005QO-GU for mip4-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 15:58: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 PAA11503 for ; Thu, 11 Sep 2003 15:57:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xXZp-0005mZ-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 15:58:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xXZp-0005mV-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 15:58:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xXZp-0005Q9-2r; Thu, 11 Sep 2003 15:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xXYw-0005PL-B1 for mip4@optimus.ietf.org; Thu, 11 Sep 2003 15: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 PAA11472 for ; Thu, 11 Sep 2003 15:57:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xXYu-0005m5-00 for mip4@ietf.org; Thu, 11 Sep 2003 15:57:04 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19xXYt-0005lj-00 for mip4@ietf.org; Thu, 11 Sep 2003 15:57:04 -0400 Received: from gdommety-w2k01.cisco.com (dhcp-128-107-163-214.cisco.com [128.107.163.214]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8BJuVS5004404; Thu, 11 Sep 2003 12:56:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20030911125033.02a64ee8@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Sep 2003 12:51:09 -0700 To: "Jayshree Bharatia" , "'Adrangi, Farid'" From: Gopal Dommety Cc: mccap@lucent.com, henrik@levkowetz.com, mip4@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Mip4] RE: Request for text proposal for your scenario 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 Farid, Henrick and Jayashree, the scenario I was referring to is as followis: MN---------|VPN/FA|-----------------[VPN2]---------HA VPN1 Provides Encryption/decryption for the link and access to the visiting domain. VPN 2 is optional for remote access. In fact, I would say let us omit this VPN2. Thanks Gopal At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: >Hello Farid, > >I would think that there may or may not be IPSec tunnel between the MN and >the FA/VPN. If there is, than it will have similar issue as discussed in >the proposed text. If there is no IPSec, the traffic will be unprotected >between these two entities. > >Regards, >Jayshree > > -----Original Message----- > > From: Adrangi, Farid > [mailto:farid.adrangi@intel.com] > > Sent: Wednesday, September 10, 2003 4:32 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > > Subject: RE: Request for text proposal for your scenario > > > > > > Thanks Jayshree. Couple of clarifications: > > > > From your description, it is my understanding that there is > > only one IPsec tunnel, and that is between the FA/VPN in the > > foreign and the VPN GW in the VPN domain. In other words, No > > IPsec tunnel between the MN and the VPN GW in VPN domain and > > hence data traffic between the MN and the FA is not > > protected. Is my understanding correct? I will have more > > questions/comments based on your answers. Thanks for the > > text and hopefully we can wrap this up this week. BR, Farid > > > > > > -----Original Message----- > > From: Jayshree Bharatia > [mailto:jayshree@nortelnetworks.com] > > Sent: Wednesday, September 10, 2003 12:15 PM > > To: Adrangi, Farid > > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > > Subject: RE: Request for text proposal for your scenario > > > > Hi Farid, > > > > The following is my proposed text for the co-located FA-VPN > > GW scenario. > > > > > > Reagrds, > > Jayshree > > --------------------- > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > ..Foreign Network... .....VPN Domain..(Intranet).... > > . . . . > > . +----+ +-----+ . +----+ +-------+ +-------+ . > > . |MNs | | FA | . | VPN| | Router| | HAs | . > > . |away| | + | .<=========>| GW | | 1..n | | | . > > . | | | VPN | . | | +-------+ +-------+ . > > . | | | GW | . | | . > > . +----+ +-----+ . +----+ +-------+ +-------+ . > > . . . | CN | | MNs | . > > .................... . | 1..n | | home | . > > . +-------+ +-------+ . > > . . > > ............................... > > > > > > In this scenario, two VPN gateways are involved where the FA > > is considered to be the trusted entity. The mipv4 tunnel is > > running inside the IPSec-ESP. For end-to-end security model, > > the VPN Gateway within the VPN Domain must protect the IP > > traffic originating at the MN. Since the point of attachment > > changes corresponding to the movement of the MN, it is > > essential that the VPN tunnel security association must be > > refreshed after each IP subnet handoff. Hence, this scenario > > is not practical where the mobility is involved due to performance > > implications for the real-time applications. > > > > > -----Original Message----- > > > From: Adrangi, Farid > [mailto:farid.adrangi@intel.com] > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > Hello Jayshree, > > > Could you please propose a text for the scenario that you > > > want to be added to the problem-statement draft? > > > BR, > > > Farid > > > > > > -----Original Message----- > > > From: Jayshree Bharatia > [mailto:jayshree@nortelnetworks.com] > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > To: Adrangi, Farid > > > Cc: mip4@ietf.org > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > > > > Please see my reply below. > > > > > > Thanks, > > > Jayshree > > > -----Original Message----- > > > From: Adrangi, Farid > [mailto:farid.adrangi@intel.com] > > > Sent: Sunday, August 03, 2003 11:50 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: mip4@ietf.org > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > Hello Jayshree, > > > Thanks for following up on this. You, Gopal, and I had a > > > very brief conversation on this during IETF-57 - but I am not > > > sure if we derived any conclusion on whether or not we should > > > include this scenario. To be frank, I don't quite understand > > > the point behind adding this scenario because, > > > - It seems to present a solution to a specific > > > deployment model > > > rather than a deployment scenario > > > [JB] My understanding is different from yours so please > > > elaborate what you mean by deployment model vs deployment > > > scenario in this particular context. > > > > > > - I don't quite see the advantages of a combined > > > VPN+FA if it > > > does > > > not support FA traversal and it does not avoid IPsec > > > renegotiation when MN moves from one subnet to another - > > > perhaps you can elaborate on this? [JB] I think regardless > > > this scenario has any advantages or not, it is one of the > > > probable scenario which has potential issues (as you have > > > indicated earlier). > > > > > > - Furthermore, Scenarios in section 2 of the problem > > > statement > > > draft represents combinations of MIPv4 HA and VPN gateway > > > placement - adding this scenario is going to change semantics > > > of the section 2. [JB] I am not sure what you mean by > > > semantics change here. Do you think documenting this in new > > > subsection (2.6) is a problem? > > > > > > I have no problem adding this scenario to the draft - I just > > > wanted to make sure that we clearly understand the reasons > > > for adding this scenario to the problem statement draft. > > > Design team members and interested individuals are welcome to > > > express their opinion on this. > > > > > > Best regards, > > > Farid > > > > > > > > > > > > > > > > > > The following sub-sections introduce five representative > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > -----Original Message----- > > > From: Jayshree Bharatia > [mailto:jayshree@nortelnetworks.com] > > > Sent: Thursday, July 31, 2003 1:44 PM > > > To: Adrangi, Farid > > > Cc: 'mip4@ietf.org' > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > > > > As per our earlier discussion during IETF-57, my > > > understanding is that you will include the scenario of > > > co-existed FA with the VPN gateway in the VPN Problem > > Statement draft. > > > > > > I agree that this particular scenario has problems and it > > > won't work if the MN is behind an FA in the foreign subnet. > > > But again, this is a problem statement draft. Hence, I > > > believe that this is the appropriate document for mentioning > > > this scenario. > > > > > > Thanks, > > > Jayshree > > > > > > -----Original Message----- > > > From: Adrangi, Farid > [mailto:farid.adrangi@intel.com] > > > Sent: Monday, April 07, 2003 2:58 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: Comments on VPN Problem Statement Draft > > > Hello Jayshree > > > This is a good point - I knew someone was to bring this up! > > > At the time of writing these scenarios, we (the design team) > > > actually discussed this and concluded this scenario would > > > fall into a solution space. Maybe we did not make the right > > > decision and we should rethink this. But, before we take > > > this discussion further please allow me to ask you a few > > > questions about the details of the scenario (VPN+FA) that you > > > have in mind . Are you thinking to broadcast FA > > > advertisements through the IPsec tunnel to the MN? If so, > > > how will this work if MN is already behind an FA in the > > > foreign subnet? Or, If you had something different in mind, > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > -----Original Message----- > > > From: Jayshree Bharatia > [mailto:jayshree@nortelnetworks.com], > > > Sent: Friday, April 04, 2003 3:14 PM > > > To: 'farid.adrangi@intel.com' > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > currently misses one scenario were the FA is co-existed with > > > the VPN Gateway. I would think that there are no technical > > > issues supporting this scenario. It will be good if you can > > > add this scenario in the draft (perhaps as section > > > 2.6?) > > > for completeness. > > > Thanks, > > > Jayshree > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 11 16:51:33 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 QAA13334 for ; Thu, 11 Sep 2003 16:51: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 19xYPA-0007bC-6i for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 16:51:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BKp4SM029210 for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 16:51:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYP9-0007b3-DD for mip4-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 16:51: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 QAA13305 for ; Thu, 11 Sep 2003 16:50:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xYP7-0006Bs-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 16:51:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xYP6-0006Bp-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 16:51:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYP7-0007aj-OT; Thu, 11 Sep 2003 16:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYP4-0007aM-56 for mip4@optimus.ietf.org; Thu, 11 Sep 2003 16:50:58 -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 QAA13299 for ; Thu, 11 Sep 2003 16:50:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xYP2-0006Bg-00 for mip4@ietf.org; Thu, 11 Sep 2003 16:50:56 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 19xYP0-0006BO-00 for mip4@ietf.org; Thu, 11 Sep 2003 16:50:55 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8BKjdh25737 for ; Thu, 11 Sep 2003 20:45:39 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8BKo6s29365 for ; Thu, 11 Sep 2003 20:50:06 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091113502229948 for ; Thu, 11 Sep 2003 13:50:22 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Sep 2003 13:50:22 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 11 Sep 2003 13:50:22 -0700 Message-ID: Thread-Topic: Re: Request for text proposal for your scenario Thread-Index: AcN4jk87uftoppHyQhuKg7lW0GEybAABKYJwAARM+PA= From: "Adrangi, Farid" To: X-OriginalArrivalTime: 11 Sep 2003 20:50:22.0549 (UTC) FILETIME=[519A8050:01C378A6] Content-Transfer-Encoding: quoted-printable Subject: [Mip4] Re: Request for text proposal for your scenario 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 Hi Gopal, Ok. As per my understanding of your scenario, I infer a few things from it: 1) MN may be several hops away from the VPN/FA 2) FA advertisement is done inside the IPsec tunnel established between the MN and VPN/FA. 3) MN roaming in a foreign network cannot be place behind a FA. For example, the following picture is not possible: MN ---FA----one or hops----FA/VPN1 4) VPN1/FA could also be your remote access VPN. So, the picture can be simplified as follows MN ----one or more hops -----FA/VPN ---Intranet Note: I get frighten when I see nested IPsec tunnels, in particular established by different IPsec client software running on the client device!!! So, since the scenario does not support #3 above, then the only problem that we have is with SA refreshes when the MN changes its point of attachment. Do I have a correct understanding of your scenario? BR, FArid -----Original Message----- From: Gopal Dommety [mailto:gdommety@cisco.com]=20 Sent: Thursday, September 11, 2003 10:58 AM To: Jayshree Bharatia; Adrangi, Farid Cc: mccap@lucent.com; henrik@levkowetz.com Subject: RE: Request for text proposal for your scenario Hello Farid, Henrick and Jayashree, the scenario I was referring to is as followis: MN---------|VPN/FA|-----------------[VPN2]---------HA VPN1 Provides Encryption/decryption for the link and access to the visiting=20 domain. VPN 2 is optional for remote access. Thanks Gopal At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: >Hello Farid, > >I would think that there may or may not be IPSec tunnel between the MN and=20 >the FA/VPN. If there is, than it will have similar issue as discussed in=20 >the proposed text. If there is no IPSec, the traffic will be unprotected=20 >between these two entities. > >Regards, >Jayshree > > -----Original Message----- > > From: Adrangi, Farid=20 > [mailto:farid.adrangi@intel.com] > > Sent: Wednesday, September 10, 2003 4:32 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > > Subject: RE: Request for text proposal for your scenario > > > > > > Thanks Jayshree. Couple of clarifications: > > > > From your description, it is my understanding that there is > > only one IPsec tunnel, and that is between the FA/VPN in the > > foreign and the VPN GW in the VPN domain. In other words, No > > IPsec tunnel between the MN and the VPN GW in VPN domain and > > hence data traffic between the MN and the FA is not > > protected. Is my understanding correct? I will have more > > questions/comments based on your answers. Thanks for the > > text and hopefully we can wrap this up this week. BR, Farid > > > > > > -----Original Message----- > > From: Jayshree Bharatia=20 > [mailto:jayshree@nortelnetworks.com] > > Sent: Wednesday, September 10, 2003 12:15 PM > > To: Adrangi, Farid > > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > > Subject: RE: Request for text proposal for your scenario > > > > Hi Farid, > > > > The following is my proposed text for the co-located FA-VPN > > GW scenario. > > > > > > Reagrds, > > Jayshree > > --------------------- > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > ..Foreign Network... .....VPN Domain..(Intranet).... > > . . . . > > . +----+ +-----+ . +----+ +-------+ +-------+ . > > . |MNs | | FA | . | VPN| | Router| | HAs | . > > . |away| | + | .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| GW | | = 1..n | | | . > > . | | | VPN | . | | +-------+ +-------+ . > > . | | | GW | . | | . > > . +----+ +-----+ . +----+ +-------+ +-------+ . > > . . . | CN | | MNs | . > > .................... . | 1..n | | home | . > > . +-------+ +-------+ . > > . . > > ............................... > > > > > > In this scenario, two VPN gateways are involved where the FA > > is considered to be the trusted entity. The mipv4 tunnel is > > running inside the IPSec-ESP. For end-to-end security model, > > the VPN Gateway within the VPN Domain must protect the IP > > traffic originating at the MN. Since the point of attachment > > changes corresponding to the movement of the MN, it is > > essential that the VPN tunnel security association must be > > refreshed after each IP subnet handoff. Hence, this scenario > > is not practical where the mobility is involved due to performance > > implications for the real-time applications. > > > > > -----Original Message----- > > > From: Adrangi, Farid=20 > [mailto:farid.adrangi@intel.com] > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > Hello Jayshree, > > > Could you please propose a text for the scenario that you > > > want to be added to the problem-statement draft? > > > BR, > > > Farid > > > > > > -----Original Message----- > > > From: Jayshree Bharatia=20 > [mailto:jayshree@nortelnetworks.com] > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > To: Adrangi, Farid > > > Cc: mip4@ietf.org > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > > > > Please see my reply below. > > > > > > Thanks, > > > Jayshree > > > -----Original Message----- > > > From: Adrangi, Farid=20 > [mailto:farid.adrangi@intel.com] > > > Sent: Sunday, August 03, 2003 11:50 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: mip4@ietf.org > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > Hello Jayshree, > > > Thanks for following up on this. You, Gopal, and I had a > > > very brief conversation on this during IETF-57 - but I am not > > > sure if we derived any conclusion on whether or not we should > > > include this scenario. To be frank, I don't quite understand > > > the point behind adding this scenario because, > > > - It seems to present a solution to a specific > > > deployment model > > > rather than a deployment scenario > > > [JB] My understanding is different from yours so please > > > elaborate what you mean by deployment model vs deployment > > > scenario in this particular context. > > > > > > - I don't quite see the advantages of a combined > > > VPN+FA if it > > > does > > > not support FA traversal and it does not avoid IPsec > > > renegotiation when MN moves from one subnet to another - > > > perhaps you can elaborate on this? [JB] I think regardless > > > this scenario has any advantages or not, it is one of the > > > probable scenario which has potential issues (as you have > > > indicated earlier). > > > > > > - Furthermore, Scenarios in section 2 of the problem > > > statement > > > draft represents combinations of MIPv4 HA and VPN gateway > > > placement - adding this scenario is going to change semantics > > > of the section 2. [JB] I am not sure what you mean by > > > semantics change here. Do you think documenting this in new > > > subsection (2.6) is a problem? > > > > > > I have no problem adding this scenario to the draft - I just > > > wanted to make sure that we clearly understand the reasons > > > for adding this scenario to the problem statement draft. > > > Design team members and interested individuals are welcome to > > > express their opinion on this. > > > > > > Best regards, > > > Farid > > > > > > > > > > > > > > > > > > The following sub-sections introduce five representative > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > -----Original Message----- > > > From: Jayshree Bharatia=20 > [mailto:jayshree@nortelnetworks.com] > > > Sent: Thursday, July 31, 2003 1:44 PM > > > To: Adrangi, Farid > > > Cc: 'mip4@ietf.org' > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > > > > As per our earlier discussion during IETF-57, my > > > understanding is that you will include the scenario of > > > co-existed FA with the VPN gateway in the VPN Problem > > Statement draft. > > > > > > I agree that this particular scenario has problems and it > > > won't work if the MN is behind an FA in the foreign subnet. > > > But again, this is a problem statement draft. Hence, I > > > believe that this is the appropriate document for mentioning > > > this scenario. > > > > > > Thanks, > > > Jayshree > > > > > > -----Original Message----- > > > From: Adrangi, Farid=20 > [mailto:farid.adrangi@intel.com] > > > Sent: Monday, April 07, 2003 2:58 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: Comments on VPN Problem Statement Draft > > > Hello Jayshree > > > This is a good point - I knew someone was to bring this up! > > > At the time of writing these scenarios, we (the design team) > > > actually discussed this and concluded this scenario would > > > fall into a solution space. Maybe we did not make the right > > > decision and we should rethink this. But, before we take > > > this discussion further please allow me to ask you a few > > > questions about the details of the scenario (VPN+FA) that you > > > have in mind . Are you thinking to broadcast FA > > > advertisements through the IPsec tunnel to the MN? If so, > > > how will this work if MN is already behind an FA in the > > > foreign subnet? Or, If you had something different in mind, > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > -----Original Message----- > > > From: Jayshree Bharatia=20 > [mailto:jayshree@nortelnetworks.com] , > > > Sent: Friday, April 04, 2003 3:14 PM > > > To: 'farid.adrangi@intel.com' > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > currently misses one scenario were the FA is co-existed with > > > the VPN Gateway. I would think that there are no technical > > > issues supporting this scenario. It will be good if you can > > > add this scenario in the draft (perhaps as section > > > 2.6?) > > > for completeness. > > > Thanks, > > > Jayshree > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 11 17:10:58 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 RAA14059 for ; Thu, 11 Sep 2003 17:10:57 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYi1-0008Ne-TI for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 17:10:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BLAXlZ032208 for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 17:10:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYi1-0008NP-En for mip4-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 17:10:33 -0400 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 RAA14039 for ; Thu, 11 Sep 2003 17:10: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 19xYhV-0008LB-RU; Thu, 11 Sep 2003 17:10:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xYQS-0007eP-Gc for mip4@optimus.ietf.org; Thu, 11 Sep 2003 16:52:24 -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 QAA13385 for ; Thu, 11 Sep 2003 16:52:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xYQP-0006D6-00 for mip4@ietf.org; Thu, 11 Sep 2003 16:52:21 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 19xYQL-0006CI-00 for mip4@ietf.org; Thu, 11 Sep 2003 16:52:17 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8BKkxh26761 for ; Thu, 11 Sep 2003 20:46:59 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.py.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8BKpQs00414 for ; Thu, 11 Sep 2003 20:51:26 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003091113514218882 for ; Thu, 11 Sep 2003 13:51:42 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Thu, 11 Sep 2003 13:51:42 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C378A6.80D28634" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Thu, 11 Sep 2003 13:51:41 -0700 Message-ID: Thread-Topic: Re: Request for text proposal for your scenario Thread-Index: AcN4fLFZI7PZJJlUREy/QBYpSsH/ngADEMAgAAdaX/A= From: "Adrangi, Farid" To: X-OriginalArrivalTime: 11 Sep 2003 20:51:42.0253 (UTC) FILETIME=[811C5DD0:01C378A6] Subject: [Mip4] Re: Request for text proposal for your scenario 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C378A6.80D28634 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 =20 -----Original Message----- From: Adrangi, Farid=20 Sent: Thursday, September 11, 2003 10:38 AM To: 'Jayshree Bharatia' Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com Subject: RE: Request for text proposal for your scenario =20 Thanks Jayshree. Ok, let me be more specific by putting inline comments in your text below. Thanks. BR, Farid =20 Jayshree wrote: "In this scenario, two VPN gateways are involved where the FA is considered to be the trusted entity. The mipv4 tunnel is running inside the IPSec-ESP (Farid> established between the two VPN gateways). For end-to-end security model, the VPN Gateway within the VPN Domain must protect the IP traffic originating at the MN (Farid> currently your scenario does not provide end-2-end security as the traffic between the MN and the FA is in clear - so are you implying that there should be another IPsec tunnel between the MN and the VPN GW protecting the Intranet?), . Since the point of attachment changes corresponding to the movement of the MN, it is essential that the VPN tunnel security association must be refreshed after each IP subnet handoff (Farid> in your scenario, the MN is not the IPsec tunnel end-point. So, when the changes its point of attachment, it does not have to worry about refreshing SAs!). Hence, this scenario is not practical where the mobility is involved due to performance implications for the real-time applications." =20 =20 =20 -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]=20 Sent: Thursday, September 11, 2003 8:52 AM To: Adrangi, Farid Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com Subject: RE: Request for text proposal for your scenario =20 Hello Farid,=20 I would think that there may or may not be IPSec tunnel between the MN and the FA/VPN. If there is, than it will have similar issue as discussed in the proposed text. If there is no IPSec, the traffic will be unprotected between these two entities. Regards,=20 Jayshree=20 > -----Original Message-----=20 > From: Adrangi, Farid [mailto:farid.adrangi@intel.com]=20 > Sent: Wednesday, September 10, 2003 4:32 PM=20 > To: Bharatia, Jayshree [RICH1:2H13:EXCH]=20 > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com=20 > Subject: RE: Request for text proposal for your scenario=20 >=20 >=20 > Thanks Jayshree. Couple of clarifications:=20 >=20 > From your description, it is my understanding that there is=20 > only one IPsec tunnel, and that is between the FA/VPN in the=20 > foreign and the VPN GW in the VPN domain. In other words, No=20 > IPsec tunnel between the MN and the VPN GW in VPN domain and=20 > hence data traffic between the MN and the FA is not=20 > protected. Is my understanding correct? I will have more=20 > questions/comments based on your answers. Thanks for the=20 > text and hopefully we can wrap this up this week. BR, Farid=20 >=20 >=20 > -----Original Message-----=20 > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]=20 > Sent: Wednesday, September 10, 2003 12:15 PM=20 > To: Adrangi, Farid=20 > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com=20 > Subject: RE: Request for text proposal for your scenario=20 >=20 > Hi Farid,=20 >=20 > The following is my proposed text for the co-located FA-VPN=20 > GW scenario.=20 >=20 >=20 > Reagrds,=20 > Jayshree=20 > ---------------------=20 >=20 > 2.6 Combined VPN Gateway and MIPv4 FA=20 >=20 > MIPv4 FA and the VPN Gateway are running on the same physical machine. >=20 >=20 > ..Foreign Network... .....VPN Domain..(Intranet)....=20 > . . . .=20 > . +----+ +-----+ . +----+ +-------+ +-------+ .=20 > . |MNs | | FA | . | VPN| | Router| | HAs | .=20 > . |away| | + | .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| GW | | = 1..n | | | .=20 > . | | | VPN | . | | +-------+ +-------+ .=20 > . | | | GW | . | | .=20 > . +----+ +-----+ . +----+ +-------+ +-------+ .=20 > . . . | CN | | MNs | .=20 > .................... . | 1..n | | home | .=20 > . +-------+ +-------+ .=20 > . .=20 > ...............................=20 >=20 >=20 > In this scenario, two VPN gateways are involved where the FA=20 > is considered to be the trusted entity. The mipv4 tunnel is=20 > running inside the IPSec-ESP. For end-to-end security model,=20 > the VPN Gateway within the VPN Domain must protect the IP=20 > traffic originating at the MN. Since the point of attachment=20 > changes corresponding to the movement of the MN, it is=20 > essential that the VPN tunnel security association must be=20 > refreshed after each IP subnet handoff. Hence, this scenario=20 > is not practical where the mobility is involved due to performance=20 > implications for the real-time applications.=20 >=20 > > -----Original Message-----=20 > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com]=20 > > Sent: Wednesday, September 03, 2003 7:54 PM=20 > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]=20 > > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com=20 > > Subject: Request for text proposal for your scenario=20 > >=20 > >=20 > >=20 > > Hello Jayshree,=20 > > Could you please propose a text for the scenario that you=20 > > want to be added to the problem-statement draft?=20 > > BR,=20 > > Farid=20 > >=20 > > -----Original Message-----=20 > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]=20 > > Sent: Wednesday, August 06, 2003 12:13 PM=20 > > To: Adrangi, Farid=20 > > Cc: mip4@ietf.org=20 > > Subject: RE: Comments on VPN Problem Statement Draft=20 > >=20 > > Hello Farid,=20 > >=20 > > Please see my reply below.=20 > >=20 > > Thanks,=20 > > Jayshree=20 > > -----Original Message-----=20 > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com]=20 > > Sent: Sunday, August 03, 2003 11:50 PM=20 > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]=20 > > Cc: mip4@ietf.org=20 > > Subject: RE: Comments on VPN Problem Statement Draft=20 > >=20 > >=20 > > Hello Jayshree,=20 > > Thanks for following up on this. You, Gopal, and I had a=20 > > very brief conversation on this during IETF-57 - but I am not=20 > > sure if we derived any conclusion on whether or not we should=20 > > include this scenario. To be frank, I don't quite understand=20 > > the point behind adding this scenario because,=20 > > - It seems to present a solution to a specific=20 > > deployment model=20 > > rather than a deployment scenario=20 > > [JB] My understanding is different from yours so please=20 > > elaborate what you mean by deployment model vs deployment=20 > > scenario in this particular context.=20 > >=20 > > - I don't quite see the advantages of a combined=20 > > VPN+FA if it=20 > > does=20 > > not support FA traversal and it does not avoid IPsec=20 > > renegotiation when MN moves from one subnet to another -=20 > > perhaps you can elaborate on this? [JB] I think regardless=20 > > this scenario has any advantages or not, it is one of the=20 > > probable scenario which has potential issues (as you have=20 > > indicated earlier).=20 > >=20 > > - Furthermore, Scenarios in section 2 of the problem=20 > > statement=20 > > draft represents combinations of MIPv4 HA and VPN gateway=20 > > placement - adding this scenario is going to change semantics=20 > > of the section 2. [JB] I am not sure what you mean by=20 > > semantics change here. Do you think documenting this in new=20 > > subsection (2.6) is a problem?=20 > >=20 > > I have no problem adding this scenario to the draft - I just=20 > > wanted to make sure that we clearly understand the reasons=20 > > for adding this scenario to the problem statement draft. =20 > > Design team members and interested individuals are welcome to=20 > > express their opinion on this. =20 > >=20 > > Best regards,=20 > > Farid=20 > >=20 > >=20 > >=20 > > =20 > > =20 > > The following sub-sections introduce five representative=20 > > combinations of MIPv4 HA and VPN gateway placement.=20 > >=20 > > -----Original Message-----=20 > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]=20 > > Sent: Thursday, July 31, 2003 1:44 PM=20 > > To: Adrangi, Farid=20 > > Cc: 'mip4@ietf.org'=20 > > Subject: RE: Comments on VPN Problem Statement Draft=20 > >=20 > > Hello Farid,=20 > >=20 > > As per our earlier discussion during IETF-57, my=20 > > understanding is that you will include the scenario of=20 > > co-existed FA with the VPN gateway in the VPN Problem=20 > Statement draft.=20 > >=20 > > I agree that this particular scenario has problems and it=20 > > won't work if the MN is behind an FA in the foreign subnet.=20 > > But again, this is a problem statement draft. Hence, I=20 > > believe that this is the appropriate document for mentioning=20 > > this scenario.=20 > >=20 > > Thanks,=20 > > Jayshree=20 > >=20 > > -----Original Message-----=20 > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com]=20 > > Sent: Monday, April 07, 2003 2:58 PM=20 > > To: Bharatia, Jayshree [RICH1:2H13:EXCH]=20 > > Cc: 'mobile-ip@sunroof.eng.sun.com'=20 > > Subject: RE: Comments on VPN Problem Statement Draft=20 > > Hello Jayshree=20 > > This is a good point - I knew someone was to bring this up! =20 > > At the time of writing these scenarios, we (the design team)=20 > > actually discussed this and concluded this scenario would=20 > > fall into a solution space. Maybe we did not make the right=20 > > decision and we should rethink this. But, before we take=20 > > this discussion further please allow me to ask you a few=20 > > questions about the details of the scenario (VPN+FA) that you=20 > > have in mind . Are you thinking to broadcast FA=20 > > advertisements through the IPsec tunnel to the MN? If so,=20 > > how will this work if MN is already behind an FA in the=20 > > foreign subnet? Or, If you had something different in mind,=20 > > perhaps you can elaborate on that. Best regards, Farid=20 > >=20 > >=20 > > -----Original Message-----=20 > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com],=20 > > Sent: Friday, April 04, 2003 3:14 PM=20 > > To: 'farid.adrangi@intel.com'=20 > > Cc: 'mobile-ip@sunroof.eng.sun.com'=20 > > Subject: Comments on VPN Problem Statement Draft=20 > >=20 > > Hello Farid,=20 > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01)=20 > > currently misses one scenario were the FA is co-existed with=20 > > the VPN Gateway. I would think that there are no technical=20 > > issues supporting this scenario. It will be good if you can=20 > > add this scenario in the draft (perhaps as section=20 > > 2.6?)=20 > > for completeness.=20 > > Thanks,=20 > > Jayshree=20 > >=20 > >=20 >=20 ------_=_NextPart_001_01C378A6.80D28634 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Request for text proposal for your scenario

 

 

-----Original Message-----
From: Adrangi, Farid
Sent: Thursday, September = 11, 2003 10:38 AM
To: 'Jayshree = Bharatia'
Cc: mccap@lucent.com; = henrik@levkowetz.com; gdommety@cisco.com
Subject: RE: Request for = text proposal for your scenario

 

Thanks Jayshree.  Ok, let me = be more specific by putting inline comments in your text below.  = Thanks.

BR,

Farid

 

Jayshree wrote:

“In this scenario, two VPN gateways are involved where the = FA is considered to be the trusted entity. The mipv4 tunnel is running inside = the IPSec-ESP (Farid> established between the two VPN gateways). For end-to-end security model, the VPN Gateway within the VPN Domain must protect the = IP traffic originating at the MN (Farid> currently your scenario does not provide end-2-end security as the = traffic between the MN and the FA is in clear – so are you implying that = there should be another IPsec tunnel between the MN and the VPN GW protecting = the Intranet?), . Since the point of attachment changes = corresponding to the movement of the MN, it is essential that the VPN tunnel security association must be refreshed after each IP subnet handoff (Farid> in your scenario, the MN is not the = IPsec tunnel end-point.  So, when the changes its point of attachment, it = does not have to worry about refreshing SAs!). Hence, this = scenario is not practical where the mobility is involved due to performance = implications for the real-time applications.” 

 

 

-----Original = Message-----
From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]
Sent: Thursday, September = 11, 2003 8:52 AM
To: Adrangi, Farid
Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
Subject: RE: Request for = text proposal for your scenario

 

Hello Farid,

I would think that there may or may not be = IPSec tunnel between the MN and the FA/VPN. If there is, than it will have = similar issue as discussed in the proposed text. If there is no IPSec, the = traffic will be unprotected between these two entities.

Regards,
Jayshree =
> -----Original = Message-----
> From: Adrangi, = Farid [mailto:farid.adrangi@intel.com]
> Sent: Wednesday, = September 10, 2003 4:32 PM
> To: Bharatia, = Jayshree [RICH1:2H13:EXCH]
> Cc: = mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
> Subject: RE: = Request for text proposal for your scenario
>
>
> Thanks = Jayshree.  Couple of clarifications:
>
> From your = description, it is my understanding that there is
> only one IPsec = tunnel, and that is between the FA/VPN in the
> foreign and the VPN = GW in the VPN domain.  In other words, No
> IPsec tunnel = between the MN and the VPN GW in VPN domain and
> hence data traffic = between the MN and the FA is not
> protected.  Is = my understanding correct?  I will have more
> questions/comments = based on your answers.  Thanks for the
> text and hopefully = we can wrap this up this week. BR, Farid
>
>
> -----Original = Message-----
> From: Jayshree = Bharatia [mailto:jayshree@nortelnetwork= s.com]
> Sent: Wednesday, = September 10, 2003 12:15 PM
> To: Adrangi, = Farid
> Cc: = mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
> Subject: RE: = Request for text proposal for your scenario
>
> Hi = Farid,
>
> The following is my = proposed text for the co-located FA-VPN
> GW = scenario.
>
>
> = Reagrds,
> = Jayshree
> = ---------------------
>
> 2.6 Combined VPN = Gateway and MIPv4 FA
>
> MIPv4 FA and the = VPN Gateway are running on the same physical machine.
>
>
>      ..Foreign Network...          &nb= sp;  .....VPN Domain..(Intranet)....
>      .            =       .            = .            =             &= nbsp;    .
>      .  +----+  +-----+ .           +----+     +-------+  +-------+ . =
>      .  |MNs |  | FA  | .           | VPN|     | Router|  | HAs   | = .
>      .  |away|  | +   | = .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| GW |     | 1..n  |  |       | .
>      .  |    |  | VPN | .           |    |     +-------+  +-------+ = .
>      .  |    |  | GW  | .           |    |            =             &= nbsp; .
>      .  +----+  +-----+ .           +----+     +-------+  +-------+ . =
>      .            =       .            = .        |  CN   = |  | MNs   | .
>      ....................         = ;    .        | 1..n  |  | = home  | .
>       =             &= nbsp;           &n= bsp;       .        +-------+  +-------+ = .
>       =             &= nbsp;           &n= bsp;       .            =             &= nbsp;    .
>       =             &= nbsp;           &n= bsp;       ...............................
>
>
> In this scenario, = two VPN gateways are involved where the FA
> is considered to be = the trusted entity. The mipv4 tunnel is
> running inside the = IPSec-ESP. For end-to-end security model,
> the VPN Gateway = within the VPN Domain must protect the IP
> traffic originating = at the MN. Since the point of attachment
> changes = corresponding to the movement of the MN, it is
> essential that the = VPN tunnel security association must be
> refreshed after = each IP subnet handoff. Hence, this scenario
> is not practical = where the mobility is involved due to performance
> implications for = the real-time applications.
>
> > -----Original Message-----
> > From: Adrangi, = Farid [mailto:farid.adrangi@intel.com]
> > Sent: = Wednesday, September 03, 2003 7:54 PM
> > To: Bharatia, = Jayshree [RICH1:2H13:EXCH]
> > Cc: = mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
> > Subject: = Request for text proposal for your scenario
> > =
> > =
> > =
> > Hello = Jayshree,
> > Could you = please propose a text for the scenario that you
> > want to be = added to the problem-statement draft?
> > = BR,
> > = Farid
> > =
> > -----Original Message-----
> > From: Jayshree = Bharatia [mailto:jayshree@nortelnetwork= s.com]
> > Sent: = Wednesday, August 06, 2003 12:13 PM
> > To: Adrangi, = Farid
> > Cc: = mip4@ietf.org
> > Subject: RE: = Comments on VPN Problem Statement Draft
> > =
> > Hello = Farid,
> > =
> > Please see my = reply below.
> > =
> > = Thanks,
> > = Jayshree
> > -----Original Message-----
> > From: Adrangi, = Farid [mailto:farid.adrangi@intel.com]
> > Sent: Sunday, = August 03, 2003 11:50 PM
> > To: Bharatia, = Jayshree [RICH1:2H13:EXCH]
> > Cc: = mip4@ietf.org
> > Subject: RE: = Comments on VPN Problem Statement Draft
> > =
> > =
> > Hello = Jayshree,
> > Thanks for = following up on this.  You, Gopal, and I had a
> > very brief = conversation on this during IETF-57 - but I am not
> > sure if we = derived any conclusion on whether or not we should
> > include this scenario.  To be frank, I don't quite understand
> > the point = behind adding this scenario because,
> > -          It seems to = present a solution to a specific
> > deployment = model
> > rather than a = deployment scenario
> > [JB] My = understanding is different from yours so please
> > elaborate what = you mean by deployment model vs deployment
> > scenario in = this particular context.
> > =
> > -          I don't quite = see the advantages of  a combined
> > VPN+FA if = it
> > = does
> > not support FA = traversal and it does not avoid IPsec
> > renegotiation = when MN moves from one subnet to another -
> > perhaps you = can elaborate on this? [JB] I think regardless
> > this scenario = has any advantages or not, it is one of the
> > probable = scenario which has potential issues (as you have
> > indicated = earlier).
> > =
> > -          Furthermore, = Scenarios in section 2 of the problem
> > = statement
> > draft = represents combinations of MIPv4 HA and VPN gateway
> > placement - = adding this scenario is going to change semantics
> > of the section = 2. [JB] I am not sure what you mean by
> > semantics = change here. Do you think documenting this in new
> > subsection = (2.6) is a problem?
> > =
> > I have no = problem adding this scenario to the draft - I just
> > wanted to make = sure that we clearly understand the reasons
> > for adding = this scenario to the problem statement draft. 
> > Design team = members and interested individuals are welcome to
> > express their = opinion on this. 
> > =
> > Best = regards,
> > = Farid
> > =
> > =
> > =
> >  =
> >  =
> >  = The   following   sub-sections   introduce   five   representative
> = >    combinations of MIPv4 HA and VPN gateway placement.
> > =
> > -----Original Message-----
> > From: Jayshree = Bharatia [mailto:jayshree@nortelnetwork= s.com]
> > Sent: = Thursday, July 31, 2003 1:44 PM
> > To: Adrangi, = Farid
> > Cc: = 'mip4@ietf.org'
> > Subject: RE: = Comments on VPN Problem Statement Draft
> > =
> > Hello = Farid,
> > =
> > As per our = earlier discussion during IETF-57, my
> > understanding = is that you will include the scenario of
> > co-existed FA = with the VPN gateway in the VPN Problem
> Statement = draft.
> > =
> > I agree that = this particular scenario has problems and it
> > won't work if = the MN is behind an FA in the foreign subnet.
> > But again, = this is a problem statement draft. Hence, I
> > believe that = this is the appropriate document for mentioning
> > this = scenario.
> > =
> > = Thanks,
> > = Jayshree
> > =
> > -----Original Message-----
> > From: Adrangi, = Farid [mailto:farid.adrangi@intel.com]
> > Sent: Monday, = April 07, 2003 2:58 PM
> > To: Bharatia, = Jayshree [RICH1:2H13:EXCH]
> > Cc: 'mobile-ip@sunroof.eng.sun.com'
> > Subject: RE: = Comments on VPN Problem Statement Draft
> > Hello = Jayshree
> > This is a good = point - I knew someone was to bring this up! 
> > At the time of = writing these scenarios, we (the design team)
> > actually = discussed this and concluded this scenario would
> > fall into a = solution space.  Maybe we did not make the right
> > decision and = we should rethink this.  But, before we take
> > this = discussion further please allow me to ask you a few
> > questions = about the details of the scenario (VPN+FA) that you
> > have in mind = .  Are you thinking to broadcast FA
> > advertisements = through the IPsec tunnel to the MN?  If so,
> > how will this = work if MN is already behind an FA in the
> > foreign = subnet? Or, If you had something different in mind,
> > perhaps you = can elaborate on that. Best regards, Farid
> > =
> > =
> > -----Original Message-----
> > From: Jayshree = Bharatia [mailto:jayshree@nortelnetwork= s.com],
> > Sent: Friday, = April 04, 2003 3:14 PM
> > To: 'farid.adrangi@intel.com'
> > Cc: 'mobile-ip@sunroof.eng.sun.com'
> > Subject: = Comments on VPN Problem Statement Draft
> > =
> > Hello = Farid,
> > This draft = (draft-ietf-mobileip-vpn-problem-statement-req-01)
> > currently = misses one scenario were the FA is co-existed with
> > the VPN = Gateway. I would think that there are no technical
> > issues = supporting this scenario. It will be good if you can
> > add this = scenario in the draft (perhaps as section
> > = 2.6?)
> > for = completeness.
> > Thanks, =
> > Jayshree =
> > =
> > =
>

=00 ------_=_NextPart_001_01C378A6.80D28634-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 11 18: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 SAA17363 for ; Thu, 11 Sep 2003 18: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 19xaDP-0002bV-1v for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 18:47:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8BMl3Gw010005 for mip4-archive@odin.ietf.org; Thu, 11 Sep 2003 18:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xaDO-0002bI-Gr for mip4-web-archive@optimus.ietf.org; Thu, 11 Sep 2003 18: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 SAA17340 for ; Thu, 11 Sep 2003 18:46:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xaDL-0006zl-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 18:46:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xaDK-0006zi-00 for mip4-web-archive@ietf.org; Thu, 11 Sep 2003 18:46:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xaDM-0002b3-R3; Thu, 11 Sep 2003 18: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 19xZq9-0001lu-4U for mip4@optimus.ietf.org; Thu, 11 Sep 2003 18:23: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 SAA16742 for ; Thu, 11 Sep 2003 18:22:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xZq6-0006r8-00 for mip4@ietf.org; Thu, 11 Sep 2003 18:22:58 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19xZq5-0006qr-00 for mip4@ietf.org; Thu, 11 Sep 2003 18:22:57 -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 h8BMMIY02587; Thu, 11 Sep 2003 17:22:18 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 11 Sep 2003 17:22:18 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B91@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Adrangi, Farid'" Cc: mip4@ietf.org Subject: RE: [Mip4] Re: Request for text proposal for your scenario Date: Thu, 11 Sep 2003 17:22:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C378B3.17796D3E" 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_01C378B3.17796D3E Content-Type: text/plain Farid, As I have mentioned in my earlier email addressed to Gopal, we can focus on the scenario where we have IPSec tunnel between the MN and the VPN gateway. My proposed text was wrt the VPN GW of the VPN domain. My thoughts were that if we have FA in the picture (roaming scenario), it is always safe to assume that it is a remote scenario. We can logically assume one VPN entity (co-existed with the FA) and describe the scenario which is fine with me as well. I am open to the suggestion. So let's look at Gopal's proposal and make changes accordingly in the text for this scenario. Thanks, Jayshree -----Original Message----- From: Adrangi, Farid [mailto:farid.adrangi@intel.com] Sent: Thursday, September 11, 2003 3:52 PM To: mip4@ietf.org Subject: [Mip4] Re: Request for text proposal for your scenario -----Original Message----- From: Adrangi, Farid Sent: Thursday, September 11, 2003 10:38 AM To: 'Jayshree Bharatia' Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com Subject: RE: Request for text proposal for your scenario Thanks Jayshree. Ok, let me be more specific by putting inline comments in your text below. Thanks. BR, Farid Jayshree wrote: "In this scenario, two VPN gateways are involved where the FA is considered to be the trusted entity. The mipv4 tunnel is running inside the IPSec-ESP (Farid> established between the two VPN gateways). For end-to-end security model, the VPN Gateway within the VPN Domain must protect the IP traffic originating at the MN (Farid> currently your scenario does not provide end-2-end security as the traffic between the MN and the FA is in clear - so are you implying that there should be another IPsec tunnel between the MN and the VPN GW protecting the Intranet?), . Since the point of attachment changes corresponding to the movement of the MN, it is essential that the VPN tunnel security association must be refreshed after each IP subnet handoff (Farid> in your scenario, the MN is not the IPsec tunnel end-point. So, when the changes its point of attachment, it does not have to worry about refreshing SAs!). Hence, this scenario is not practical where the mobility is involved due to performance implications for the real-time applications." -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] Sent: Thursday, September 11, 2003 8:52 AM To: Adrangi, Farid Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com Subject: RE: Request for text proposal for your scenario Hello Farid, I would think that there may or may not be IPSec tunnel between the MN and the FA/VPN. If there is, than it will have similar issue as discussed in the proposed text. If there is no IPSec, the traffic will be unprotected between these two entities. Regards, Jayshree > -----Original Message----- > From: Adrangi, Farid [mailto:farid.adrangi@intel.com ] > Sent: Wednesday, September 10, 2003 4:32 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > Subject: RE: Request for text proposal for your scenario > > > Thanks Jayshree. Couple of clarifications: > > From your description, it is my understanding that there is > only one IPsec tunnel, and that is between the FA/VPN in the > foreign and the VPN GW in the VPN domain. In other words, No > IPsec tunnel between the MN and the VPN GW in VPN domain and > hence data traffic between the MN and the FA is not > protected. Is my understanding correct? I will have more > questions/comments based on your answers. Thanks for the > text and hopefully we can wrap this up this week. BR, Farid > > > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com ] > Sent: Wednesday, September 10, 2003 12:15 PM > To: Adrangi, Farid > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > Subject: RE: Request for text proposal for your scenario > > Hi Farid, > > The following is my proposed text for the co-located FA-VPN > GW scenario. > > > Reagrds, > Jayshree > --------------------- > > 2.6 Combined VPN Gateway and MIPv4 FA > > MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > ..Foreign Network... .....VPN Domain..(Intranet).... > . . . . > . +----+ +-----+ . +----+ +-------+ +-------+ . > . |MNs | | FA | . | VPN| | Router| | HAs | . > . |away| | + | .<=========>| GW | | 1..n | | | . > . | | | VPN | . | | +-------+ +-------+ . > . | | | GW | . | | . > . +----+ +-----+ . +----+ +-------+ +-------+ . > . . . | CN | | MNs | . > .................... . | 1..n | | home | . > . +-------+ +-------+ . > . . > ............................... > > > In this scenario, two VPN gateways are involved where the FA > is considered to be the trusted entity. The mipv4 tunnel is > running inside the IPSec-ESP. For end-to-end security model, > the VPN Gateway within the VPN Domain must protect the IP > traffic originating at the MN. Since the point of attachment > changes corresponding to the movement of the MN, it is > essential that the VPN tunnel security association must be > refreshed after each IP subnet handoff. Hence, this scenario > is not practical where the mobility is involved due to performance > implications for the real-time applications. > > > -----Original Message----- > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com ] > > Sent: Wednesday, September 03, 2003 7:54 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com > > Subject: Request for text proposal for your scenario > > > > > > > > Hello Jayshree, > > Could you please propose a text for the scenario that you > > want to be added to the problem-statement draft? > > BR, > > Farid > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com ] > > Sent: Wednesday, August 06, 2003 12:13 PM > > To: Adrangi, Farid > > Cc: mip4@ietf.org > > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > > > Please see my reply below. > > > > Thanks, > > Jayshree > > -----Original Message----- > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com ] > > Sent: Sunday, August 03, 2003 11:50 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: mip4@ietf.org > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Jayshree, > > Thanks for following up on this. You, Gopal, and I had a > > very brief conversation on this during IETF-57 - but I am not > > sure if we derived any conclusion on whether or not we should > > include this scenario. To be frank, I don't quite understand > > the point behind adding this scenario because, > > - It seems to present a solution to a specific > > deployment model > > rather than a deployment scenario > > [JB] My understanding is different from yours so please > > elaborate what you mean by deployment model vs deployment > > scenario in this particular context. > > > > - I don't quite see the advantages of a combined > > VPN+FA if it > > does > > not support FA traversal and it does not avoid IPsec > > renegotiation when MN moves from one subnet to another - > > perhaps you can elaborate on this? [JB] I think regardless > > this scenario has any advantages or not, it is one of the > > probable scenario which has potential issues (as you have > > indicated earlier). > > > > - Furthermore, Scenarios in section 2 of the problem > > statement > > draft represents combinations of MIPv4 HA and VPN gateway > > placement - adding this scenario is going to change semantics > > of the section 2. [JB] I am not sure what you mean by > > semantics change here. Do you think documenting this in new > > subsection (2.6) is a problem? > > > > I have no problem adding this scenario to the draft - I just > > wanted to make sure that we clearly understand the reasons > > for adding this scenario to the problem statement draft. > > Design team members and interested individuals are welcome to > > express their opinion on this. > > > > Best regards, > > Farid > > > > > > > > > > > > The following sub-sections introduce five representative > > combinations of MIPv4 HA and VPN gateway placement. > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com ] > > Sent: Thursday, July 31, 2003 1:44 PM > > To: Adrangi, Farid > > Cc: 'mip4@ietf.org' > > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > > > As per our earlier discussion during IETF-57, my > > understanding is that you will include the scenario of > > co-existed FA with the VPN gateway in the VPN Problem > Statement draft. > > > > I agree that this particular scenario has problems and it > > won't work if the MN is behind an FA in the foreign subnet. > > But again, this is a problem statement draft. Hence, I > > believe that this is the appropriate document for mentioning > > this scenario. > > > > Thanks, > > Jayshree > > > > -----Original Message----- > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com ] > > Sent: Monday, April 07, 2003 2:58 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: Comments on VPN Problem Statement Draft > > Hello Jayshree > > This is a good point - I knew someone was to bring this up! > > At the time of writing these scenarios, we (the design team) > > actually discussed this and concluded this scenario would > > fall into a solution space. Maybe we did not make the right > > decision and we should rethink this. But, before we take > > this discussion further please allow me to ask you a few > > questions about the details of the scenario (VPN+FA) that you > > have in mind . Are you thinking to broadcast FA > > advertisements through the IPsec tunnel to the MN? If so, > > how will this work if MN is already behind an FA in the > > foreign subnet? Or, If you had something different in mind, > > perhaps you can elaborate on that. Best regards, Farid > > > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com ], > > Sent: Friday, April 04, 2003 3:14 PM > > To: 'farid.adrangi@intel.com' > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > Subject: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > currently misses one scenario were the FA is co-existed with > > the VPN Gateway. I would think that there are no technical > > issues supporting this scenario. It will be good if you can > > add this scenario in the draft (perhaps as section > > 2.6?) > > for completeness. > > Thanks, > > Jayshree > > > > > ------_=_NextPart_001_01C378B3.17796D3E Content-Type: text/html Message
Farid,
 
As I have mentioned in my earlier email addressed to Gopal, we can focus on the scenario where we have IPSec tunnel between the MN and the VPN gateway. My proposed text was wrt the VPN GW of the VPN domain. My thoughts were that if we have FA in the picture (roaming scenario), it is always safe to assume that it is a remote scenario.
 
We can logically assume one VPN entity (co-existed with the FA) and describe the scenario which is fine with me as well. I am open to the suggestion. So let's look at Gopal's proposal and make changes accordingly in the text for this scenario.
 
Thanks,
Jayshree
-----Original Message-----
From: Adrangi, Farid [mailto:farid.adrangi@intel.com]
Sent: Thursday, September 11, 2003 3:52 PM
To: mip4@ietf.org
Subject: [Mip4] Re: Request for text proposal for your scenario

 

 

-----Original Message-----
From: Adrangi, Farid
Sent: Thursday, September 11, 2003 10:38 AM
To: 'Jayshree Bharatia'
Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
Subject: RE: Request for text proposal for your scenario

 

Thanks Jayshree.  Ok, let me be more specific by putting inline comments in your text below.  Thanks.

BR,

Farid

 

Jayshree wrote:

"In this scenario, two VPN gateways are involved where the FA is considered to be the trusted entity. The mipv4 tunnel is running inside the IPSec-ESP (Farid> established between the two VPN gateways). For end-to-end security model, the VPN Gateway within the VPN Domain must protect the IP traffic originating at the MN (Farid> currently your scenario does not provide end-2-end security as the traffic between the MN and the FA is in clear - so are you implying that there should be another IPsec tunnel between the MN and the VPN GW protecting the Intranet?), . Since the point of attachment changes corresponding to the movement of the MN, it is essential that the VPN tunnel security association must be refreshed after each IP subnet handoff (Farid> in your scenario, the MN is not the IPsec tunnel end-point.  So, when the changes its point of attachment, it does not have to worry about refreshing SAs!). Hence, this scenario is not practical where the mobility is involved due to performance implications for the real-time applications." 

 

 

-----Original Message-----
From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]
Sent: Thursday, September 11, 2003 8:52 AM
To: Adrangi, Farid
Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
Subject: RE: Request for text proposal for your scenario

 

Hello Farid,

I would think that there may or may not be IPSec tunnel between the MN and the FA/VPN. If there is, than it will have similar issue as discussed in the proposed text. If there is no IPSec, the traffic will be unprotected between these two entities.

Regards,
Jayshree
> -----Original Message-----
> From: Adrangi, Farid [mailto:farid.adrangi@intel.com]
> Sent: Wednesday, September 10, 2003 4:32 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
> Subject: RE: Request for text proposal for your scenario
>
>
> Thanks Jayshree.  Couple of clarifications:
>
> From your description, it is my understanding that there is
> only one IPsec tunnel, and that is between the FA/VPN in the
> foreign and the VPN GW in the VPN domain.  In other words, No
> IPsec tunnel between the MN and the VPN GW in VPN domain and
> hence data traffic between the MN and the FA is not
> protected.  Is my understanding correct?  I will have more
> questions/comments based on your answers.  Thanks for the
> text and hopefully we can wrap this up this week. BR, Farid
>
>
> -----Original Message-----
> From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]
> Sent: Wednesday, September 10, 2003 12:15 PM
> To: Adrangi, Farid
> Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
> Subject: RE: Request for text proposal for your scenario
>
> Hi Farid,
>
> The following is my proposed text for the co-located FA-VPN
> GW scenario.
>
>
> Reagrds,
> Jayshree
> ---------------------
>
> 2.6 Combined VPN Gateway and MIPv4 FA
>
> MIPv4 FA and the VPN Gateway are running on the same physical machine.
>
>
>      ..Foreign Network...             .....VPN Domain..(Intranet)....
>      .                  .             .                             .
>      .  +----+  +-----+ .           +----+     +-------+  +-------+ .
>      .  |MNs |  | FA  | .           | VPN|     | Router|  | HAs   | .
>      .  |away|  | +   | .<=========>| GW |     | 1..n  |  |       | .
>      .  |    |  | VPN | .           |    |     +-------+  +-------+ .
>      .  |    |  | GW  | .           |    |                          .
>      .  +----+  +-----+ .           +----+     +-------+  +-------+ .
>      .                  .             .        |  CN   |  | MNs   | .
>      ....................             .        | 1..n  |  | home  | .
>                                       .        +-------+  +-------+ .
>                                       .                             .
>                                       ...............................
>
>
> In this scenario, two VPN gateways are involved where the FA
> is considered to be the trusted entity. The mipv4 tunnel is
> running inside the IPSec-ESP. For end-to-end security model,
> the VPN Gateway within the VPN Domain must protect the IP
> traffic originating at the MN. Since the point of attachment
> changes corresponding to the movement of the MN, it is
> essential that the VPN tunnel security association must be
> refreshed after each IP subnet handoff. Hence, this scenario
> is not practical where the mobility is involved due to performance
> implications for the real-time applications.
>
> > -----Original Message-----
> > From: Adrangi, Farid [mailto:farid.adrangi@intel.com]
> > Sent: Wednesday, September 03, 2003 7:54 PM
> > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > Cc: mccap@lucent.com; henrik@levkowetz.com; gdommety@cisco.com
> > Subject: Request for text proposal for your scenario
> >
> >
> >
> > Hello Jayshree,
> > Could you please propose a text for the scenario that you
> > want to be added to the problem-statement draft?
> > BR,
> > Farid
> >
> > -----Original Message-----
> > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]
> > Sent: Wednesday, August 06, 2003 12:13 PM
> > To: Adrangi, Farid
> > Cc: mip4@ietf.org
> > Subject: RE: Comments on VPN Problem Statement Draft
> >
> > Hello Farid,
> >
> > Please see my reply below.
> >
> > Thanks,
> > Jayshree
> > -----Original Message-----
> > From: Adrangi, Farid [mailto:farid.adrangi@intel.com]
> > Sent: Sunday, August 03, 2003 11:50 PM
> > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > Cc: mip4@ietf.org
> > Subject: RE: Comments on VPN Problem Statement Draft
> >
> >
> > Hello Jayshree,
> > Thanks for following up on this.  You, Gopal, and I had a
> > very brief conversation on this during IETF-57 - but I am not
> > sure if we derived any conclusion on whether or not we should
> > include this scenario.  To be frank, I don't quite understand
> > the point behind adding this scenario because,
> > -          It seems to present a solution to a specific
> > deployment model
> > rather than a deployment scenario
> > [JB] My understanding is different from yours so please
> > elaborate what you mean by deployment model vs deployment
> > scenario in this particular context.
> >
> > -          I don't quite see the advantages of  a combined
> > VPN+FA if it
> > does
> > not support FA traversal and it does not avoid IPsec
> > renegotiation when MN moves from one subnet to another -
> > perhaps you can elaborate on this? [JB] I think regardless
> > this scenario has any advantages or not, it is one of the
> > probable scenario which has potential issues (as you have
> > indicated earlier).
> >
> > -          Furthermore, Scenarios in section 2 of the problem
> > statement
> > draft represents combinations of MIPv4 HA and VPN gateway
> > placement - adding this scenario is going to change semantics
> > of the section 2. [JB] I am not sure what you mean by
> > semantics change here. Do you think documenting this in new
> > subsection (2.6) is a problem?
> >
> > I have no problem adding this scenario to the draft - I just
> > wanted to make sure that we clearly understand the reasons
> > for adding this scenario to the problem statement draft. 
> > Design team members and interested individuals are welcome to
> > express their opinion on this. 
> >
> > Best regards,
> > Farid
> >
> >
> >
> > 
> > 
> >  The   following   sub-sections   introduce   five   representative
> >    combinations of MIPv4 HA and VPN gateway placement.
> >
> > -----Original Message-----
> > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]
> > Sent: Thursday, July 31, 2003 1:44 PM
> > To: Adrangi, Farid
> > Cc: 'mip4@ietf.org'
> > Subject: RE: Comments on VPN Problem Statement Draft
> >
> > Hello Farid,
> >
> > As per our earlier discussion during IETF-57, my
> > understanding is that you will include the scenario of
> > co-existed FA with the VPN gateway in the VPN Problem
> Statement draft.
> >
> > I agree that this particular scenario has problems and it
> > won't work if the MN is behind an FA in the foreign subnet.
> > But again, this is a problem statement draft. Hence, I
> > believe that this is the appropriate document for mentioning
> > this scenario.
> >
> > Thanks,
> > Jayshree
> >
> > -----Original Message-----
> > From: Adrangi, Farid [mailto:farid.adrangi@intel.com]
> > Sent: Monday, April 07, 2003 2:58 PM
> > To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> > Cc: 'mobile-ip@sunroof.eng.sun.com'
> > Subject: RE: Comments on VPN Problem Statement Draft
> > Hello Jayshree
> > This is a good point - I knew someone was to bring this up! 
> > At the time of writing these scenarios, we (the design team)
> > actually discussed this and concluded this scenario would
> > fall into a solution space.  Maybe we did not make the right
> > decision and we should rethink this.  But, before we take
> > this discussion further please allow me to ask you a few
> > questions about the details of the scenario (VPN+FA) that you
> > have in mind .  Are you thinking to broadcast FA
> > advertisements through the IPsec tunnel to the MN?  If so,
> > how will this work if MN is already behind an FA in the
> > foreign subnet? Or, If you had something different in mind,
> > perhaps you can elaborate on that. Best regards, Farid
> >
> >
> > -----Original Message-----
> > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com],
> > Sent: Friday, April 04, 2003 3:14 PM
> > To: 'farid.adrangi@intel.com'
> > Cc: 'mobile-ip@sunroof.eng.sun.com'
> > Subject: Comments on VPN Problem Statement Draft
> >
> > Hello Farid,
> > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01)
> > currently misses one scenario were the FA is co-existed with
> > the VPN Gateway. I would think that there are no technical
> > issues supporting this scenario. It will be good if you can
> > add this scenario in the draft (perhaps as section
> > 2.6?)
> > for completeness.
> > Thanks,
> > Jayshree
> >
> >
>

------_=_NextPart_001_01C378B3.17796D3E-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 12 07:33: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 HAA16883 for ; Fri, 12 Sep 2003 07:33: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 19xmAh-0000bQ-Eq for mip4-archive@odin.ietf.org; Fri, 12 Sep 2003 07:33:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8CBX3lq002310 for mip4-archive@odin.ietf.org; Fri, 12 Sep 2003 07:33:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmAh-0000bB-7T for mip4-web-archive@optimus.ietf.org; Fri, 12 Sep 2003 07:33: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 HAA16873 for ; Fri, 12 Sep 2003 07:32:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xmAg-0004tJ-00 for mip4-web-archive@ietf.org; Fri, 12 Sep 2003 07:33:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19xmAg-0004tG-00 for mip4-web-archive@ietf.org; Fri, 12 Sep 2003 07:33:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmAf-0000av-6j; Fri, 12 Sep 2003 07:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xmAV-0000ai-3N for mip4@optimus.ietf.org; Fri, 12 Sep 2003 07:32:51 -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 HAA16870 for ; Fri, 12 Sep 2003 07:32:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xmAU-0004t8-00 for mip4@ietf.org; Fri, 12 Sep 2003 07:32:50 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19xmAT-0004t1-00 for mip4@ietf.org; Fri, 12 Sep 2003 07:32:49 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h8CBWmK21027 for ; Fri, 12 Sep 2003 13:32:48 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F61AEDA.3040707@comnets.uni-bremen.de> Date: Fri, 12 Sep 2003 13:32:42 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] route optimisation and user privacy 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 I am looking into some user privacy considerations in the route optimization draft "draft-ietf-mobileip-optim-10.txt" In section "3.1. Binding Caches", page 3 you will find: "When a mobile node's home agent intercepts a datagram from the home network and tunnels it to the mobile node, the home agent may deduce that the original source of the datagram has no binding cache entry for the destination mobile node. The home agent SHOULD then send a Binding Update message to the original source node, informing it of the mobile node's current mobility binding." In that case, I imagine, a malicious CN would be able to periodically or randomly query a home agent on a mobile node's whereabouts. Would it not be better if the HA sent a Binding Warning to the mobile node stating that the particular CN requires a Binding Update? In that case the MN would be in the position to decide to which CNs it wishes to reveal its position. Best Regards niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Sep 14 21:04: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 VAA21151 for ; Sun, 14 Sep 2003 21:04: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 19yhmd-0003WD-Bw for mip4-archive@odin.ietf.org; Sun, 14 Sep 2003 21:04:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F1430l013520 for mip4-archive@odin.ietf.org; Sun, 14 Sep 2003 21:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yhmd-0003Vw-52 for mip4-web-archive@optimus.ietf.org; Sun, 14 Sep 2003 21:04: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 VAA21144 for ; Sun, 14 Sep 2003 21:03:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yhma-0000zL-00 for mip4-web-archive@ietf.org; Sun, 14 Sep 2003 21:04:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yhma-0000zE-00 for mip4-web-archive@ietf.org; Sun, 14 Sep 2003 21:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yhmb-0003VY-6v; Sun, 14 Sep 2003 21:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yhmY-0003V9-Cv for mip4@optimus.ietf.org; Sun, 14 Sep 2003 21:03:58 -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 VAA21139 for ; Sun, 14 Sep 2003 21:03:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yhmV-0000yr-00 for mip4@ietf.org; Sun, 14 Sep 2003 21:03:55 -0400 Received: from mail-efg0.york.ac.uk ([144.32.128.236]) by ietf-mx with esmtp (Exim 4.12) id 19yhmV-0000vz-00 for mip4@ietf.org; Sun, 14 Sep 2003 21:03:55 -0400 Received: from grouse (grouse.ohm.york.ac.uk [144.32.137.104]) by mail-efg0.york.ac.uk (8.12.9/8.12.9) with SMTP id h8F13LSQ011812; Mon, 15 Sep 2003 02:03:21 +0100 (BST) Message-ID: <00e001c37b25$4c07c590$68892090@grouse> From: "Jee J.Z." To: "Niko A. Fikouras" , References: <3F61AEDA.3040707@comnets.uni-bremen.de> Subject: Re: [Mip4] route optimisation and user privacy Date: Mon, 15 Sep 2003 02:04:21 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01C37B2D.AD92F520" 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 X-York-MailScanner: Found to be clean 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 is a multi-part message in MIME format. ------=_NextPart_000_00DD_01C37B2D.AD92F520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Niko, I think it will not introduce more sicurity vulnerabilities than = non-route optimization cases. A MN could set the 'P' bit in the = registration request to the HA to make its care of address secret, but = when the MN does not set the 'P' bit, it means the MN does not care = disclosing its mobility binding. In this case, any node knowing its = current address can reach it, as it is on its home network.=20 Regards, Jee ----- Original Message -----=20 From: Niko A. Fikouras=20 To: mip4@ietf.org=20 Sent: Friday, September 12, 2003 12:32 PM Subject: [Mip4] route optimisation and user privacy I am looking into some user privacy considerations in the route=20 optimization draft "draft-ietf-mobileip-optim-10.txt" In section "3.1. Binding Caches", page 3 you will find: "When a mobile node's home agent intercepts a datagram from the home network and tunnels it to the mobile node, the home agent may deduce that the original source of the datagram has no binding cache entry for the destination mobile node. The home agent SHOULD then send a Binding Update message to the original source node, informing it of the mobile node's current mobility binding." In that case, I imagine, a malicious CN would be able to periodically = or=20 randomly query a home agent on a mobile node's whereabouts. Would it = not=20 be better if the HA sent a Binding Warning to the mobile node stating=20 that the particular CN requires a Binding Update? In that case the MN=20 would be in the position to decide to which CNs it wishes to reveal = its=20 position. Best Regards niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 ------=_NextPart_000_00DD_01C37B2D.AD92F520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Niko,
 
I think it will not introduce=20 more sicurity vulnerabilities than non-route optimization = cases. A MN=20 could set the 'P' bit in the registration request to the HA to make its = care of=20 address secret, but when the MN does not set the 'P' bit, it means the = MN does=20 not care disclosing its mobility binding. In this case, any node knowing = its=20 current address can reach it, as it is on its home network. =
 
Regards,
Jee
----- Original Message -----
From:=20 Niko A. Fikouras
Sent: Friday, September 12, = 2003 12:32=20 PM
Subject: [Mip4] route = optimisation and=20 user privacy

I am looking into some user privacy considerations in = the route=20
optimization draft "draft-ietf-mobileip-optim-10.txt"

In = section=20 "3.1. Binding Caches", page 3 you will find:

"When a mobile = node's home=20 agent intercepts a datagram from the home
network and tunnels it to = the=20 mobile node, the home agent may deduce
that the original source of = the=20 datagram has no binding cache entry
for the destination mobile = node. =20 The home agent SHOULD then send
a Binding Update message to the = original=20 source node, informing it
of the mobile node's current mobility=20 binding."

In that case, I imagine, a malicious CN would be able = to=20 periodically or
randomly query a home agent on a mobile node's=20 whereabouts. Would it not
be better if the HA sent a Binding = Warning to=20 the mobile node stating
that the particular CN requires a Binding = Update?=20 In that case the MN
would be in the position to decide to which = CNs it=20 wishes to reveal its
position.

Best=20 = Regards
niko


______________________________________________= _
Mip4=20 mailing list
Mip4@ietf.org
https://www.ietf.org/= mailman/listinfo/mip4
------=_NextPart_000_00DD_01C37B2D.AD92F520-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 15 05: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 FAA19605 for ; Mon, 15 Sep 2003 05: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 19ypfK-00043D-Ic for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 05:29:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8F9T2N9015562 for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 05:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypfK-00042r-48 for mip4-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 05:29: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 FAA19586 for ; Mon, 15 Sep 2003 05:28:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ypfG-0007Hh-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 05:28:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ypfG-0007He-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 05:28:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypfI-00042Q-Vh; Mon, 15 Sep 2003 05:29:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ypep-0003zV-TS for mip4@optimus.ietf.org; Mon, 15 Sep 2003 05:28: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 FAA19574 for ; Mon, 15 Sep 2003 05:28:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ypem-0007El-00 for mip4@ietf.org; Mon, 15 Sep 2003 05:28:28 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19ypel-0007Eb-00 for mip4@ietf.org; Mon, 15 Sep 2003 05:28:27 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h8F9SSK24518 for ; Mon, 15 Sep 2003 11:28:28 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F65862F.8090800@comnets.uni-bremen.de> Date: Mon, 15 Sep 2003 11:28:15 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] query on status of drafts 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 all, I would like to know what the status of the following drafts is: draft-ietf-mobileip-optim draft-ietf-mobileip-reg-tunnel Best Regards niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 15 09:47: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 JAA29080 for ; Mon, 15 Sep 2003 09:47: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 19yth1-0002cH-5G for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 09:47:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FDl3AP010051 for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 09:47:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yth1-0002c1-09 for mip4-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 09:47: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 JAA29070 for ; Mon, 15 Sep 2003 09:46:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytgz-0000HX-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 09:47:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ytgy-0000HT-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 09: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 19ytgz-0002bX-Eg; Mon, 15 Sep 2003 09: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 19ytgV-0002YF-Hc for mip4@optimus.ietf.org; Mon, 15 Sep 2003 09:46: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 JAA29040 for ; Mon, 15 Sep 2003 09:46:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytgT-0000El-00 for mip4@ietf.org; Mon, 15 Sep 2003 09:46:29 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 19ytgS-0000BD-00 for mip4@ietf.org; Mon, 15 Sep 2003 09:46:29 -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 h8FDjmCj019663; Mon, 15 Sep 2003 15:45:49 +0200 Date: Mon, 15 Sep 2003 15:45:49 +0200 From: Henrik Levkowetz To: "Niko A. Fikouras" Cc: mip4@ietf.org Subject: Re: [Mip4] query on status of drafts Message-Id: <20030915154549.7f2dc8c3.henrik@levkowetz.com> In-Reply-To: <3F65862F.8090800@comnets.uni-bremen.de> References: <3F65862F.8090800@comnets.uni-bremen.de> X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.6cR_1XQSslofpk" X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60-rc4 X-Spam-Checker-Version: SpamAssassin 2.60-rc4 (1.203-2003-08-29-exp) on mailgw.local.ipunplugged.com 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: , --=.6cR_1XQSslofpk Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello Niko, On Monday, 15 Sep 2003, Niko wrote: > I would like to know what the status of the following drafts is: > > draft-ietf-mobileip-optim > draft-ietf-mobileip-reg-tunnel These two drafts are not within the charter of the Mip4 working group, and are not currently being worked on as far as I know. Regards, Henrik -- A closed mouth gathers no foot. --=.6cR_1XQSslofpk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ZcKNeVhrtTJkXCMRAjzAAJ9BBChGYkf++O4iHbGC/ybipG6lzQCdHgh0 puxUTRD4RSrAqfHJBZfoSi4= =k98q -----END PGP SIGNATURE----- --=.6cR_1XQSslofpk-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 15 10:06: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 KAA00565 for ; Mon, 15 Sep 2003 10:06: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 19ytzP-00056i-22 for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 10:06:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FE63Iq019632 for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 10:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytzO-00056X-SO for mip4-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 10:06: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 KAA00449 for ; Mon, 15 Sep 2003 10:05:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytzM-000297-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 10:06:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ytzM-000290-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 10:06:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytzN-000564-NO; Mon, 15 Sep 2003 10:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ytyj-00051P-0V for mip4@optimus.ietf.org; Mon, 15 Sep 2003 10:05: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 KAA00323 for ; Mon, 15 Sep 2003 10:05:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ytyg-00024k-00 for mip4@ietf.org; Mon, 15 Sep 2003 10:05:18 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19ytyf-00024c-00 for mip4@ietf.org; Mon, 15 Sep 2003 10:05:18 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h8FE5FK30141; Mon, 15 Sep 2003 16:05:15 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F65C70D.7050907@comnets.uni-bremen.de> Date: Mon, 15 Sep 2003 16:05:01 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] query on status of drafts References: <3F65862F.8090800@comnets.uni-bremen.de> <20030915154549.7f2dc8c3.henrik@levkowetz.com> In-Reply-To: <20030915154549.7f2dc8c3.henrik@levkowetz.com> Content-Type: multipart/alternative; boundary="------------000301020300040206090604" 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 is a multi-part message in MIME format. --------------000301020300040206090604 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, thanks for the answer. I am currently in the process of preparing the sixth version (05) of the Fitlers for Mobile IPv4 Bindings (NOMAD) draft. My question is, should I include considerations for these two drafts or not? IMHO, I can not imagine that MIPv4 support will not include any support for hierarchical organisations as described in draft-ietf-mobileip-reg-tunnel. What would it take to get these drafts back into the charter? Best Regards niko Henrik Levkowetz wrote: >Hello Niko, > >On Monday, 15 Sep 2003, Niko wrote: > > >>I would like to know what the status of the following drafts is: >> >>draft-ietf-mobileip-optim >>draft-ietf-mobileip-reg-tunnel >> >> > > These two drafts are not within the charter of the Mip4 working >group, and are not currently being worked on as far as I know. > > Regards, > > Henrik > > > --------------000301020300040206090604 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

thanks for the answer.

I am currently in the process of preparing the sixth version (05) of the Fitlers for Mobile IPv4 Bindings (NOMAD) draft. My question is, should I include considerations for these two drafts or not? IMHO, I can not imagine that MIPv4 support will not include any support for hierarchical organisations as described in draft-ietf-mobileip-reg-tunnel. What would it take to get these drafts back into the charter?

Best Regards
niko

Henrik Levkowetz wrote:
Hello Niko,

On Monday, 15 Sep 2003, Niko wrote:
  
I would like to know what the status of the following drafts is:

draft-ietf-mobileip-optim
draft-ietf-mobileip-reg-tunnel
    

    These two drafts are not within the charter of the Mip4 working
group, and are not currently being worked on as far as I know.

	Regards,

		Henrik
--------------000301020300040206090604-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 15 10:40:31 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 KAA05195 for ; Mon, 15 Sep 2003 10:40:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuWP-00014I-4F for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 10:40:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FEe9ps004105 for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 10:40:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuWN-00013u-AL for mip4-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 10:40: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 KAA05169 for ; Mon, 15 Sep 2003 10:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yuWK-00061q-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 10:40:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yuWK-00061m-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 10:40:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuWL-00013Y-Fb; Mon, 15 Sep 2003 10:40:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yuWB-000120-7d for mip4@optimus.ietf.org; Mon, 15 Sep 2003 10:39:55 -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 KAA05163 for ; Mon, 15 Sep 2003 10:39:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yuW8-00060l-00 for mip4@ietf.org; Mon, 15 Sep 2003 10:39:52 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19yuW7-0005wx-00 for mip4@ietf.org; Mon, 15 Sep 2003 10:39:51 -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 h8FEd6a10372; Mon, 15 Sep 2003 09:39:06 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 15 Sep 2003 09:39:06 -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: Mon, 15 Sep 2003 09:39:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37B97.19CEC8EA" 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_01C37B97.19CEC8EA Content-Type: text/plain Hi, Pete, Sorry for the long delay. Hope we can restart discussion on this issue again. Regards, Ahmad > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > > > 3.2. Foreign Agent Processing for Registration Requests > > > > If a mobile node retransmits a Registration > Request with the same > > > > Challenge extension or a Retransmit Challenge, 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. ... > > > > > ^^^^^ > > > If the MN uses a "Retransmit Challenge", then which > > > registration request should be forwarded to the HA here - the > > > old one or the new one? > > > > > > > [AM] > > To be exactly handled the same way a retransmit is > currently done. i.e. it > depends on the state of the call at the FA. > > 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. > > > > Retransmit Challenge: > > > > A challenge used by the MN to indicate to the Foreign > > > > Agent that it is retransmitting its Registration Request. > > > > The value of the Retransmit Challenge MUST equal the > > > > challenge value used in the MN latest Registration > Request plus 1. > > > > > > So the MN should increment the Challenge field with each > > > retransmission? Is that what you mean? > > > > [AM] > > Yes. > > > > > Does this mean the FA must be prepared to accept any of > the currently > valid > > > challenges plus some window N? > > > > [AM] > > YES. > > We may call it a tolerance window. Similar to what the HA > has for the MN > with timesatmp replay protection. > > 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. > > > > 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. > > > > 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. 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. > > > 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! > 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? > -Pete > > ------_=_NextPart_001_01C37B97.19CEC8EA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a = DOS

Hi, Pete,
Sorry for the long delay.
Hope we can restart discussion on this issue = again.

Regards,
Ahmad


>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > >  > 3.2. Foreign Agent = Processing for Registration Requests
>  > >  >    If = a mobile node retransmits a Registration
> Request with the same
>  > >  >    = Challenge extension or a Retransmit Challenge, 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. ...
>  >
>  > = >           &n= bsp;           &n= bsp; ^^^^^
>  > > If the MN uses a = "Retransmit Challenge", then which
>  > > registration request should be = forwarded to the HA here - the
>  > > old one or the new one?
>  > >
>  >
>  > [AM]
>  > To be exactly handled the same way a = retransmit is
> currently done. i.e. it  > depends on = the state of the call at the FA.
>
> 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.
 
>  > >  > Retransmit = Challenge:
>  > >  > A challenge used by = the MN to indicate to the Foreign
>  > >  > Agent that it is = retransmitting its Registration Request.
>  > >  > The value of the = Retransmit Challenge MUST equal the
>  > >  > challenge value used = in the MN latest Registration
> Request plus 1.
>  > >
>  > > So the MN should increment the = Challenge field with each
>  > > retransmission?  Is that = what you mean? 
>  >
>  > [AM]
>  > Yes.
>  >
>  > > Does this mean the FA must be = prepared to accept any of
> the currently  > valid
>  > > challenges plus some window = N?
>  >
>  > [AM]
>  > YES.
>  > We may call it a tolerance window. = Similar to what the HA
> has for the MN  > with timesatmp replay = protection.
>
> 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.
 
>
>  > > 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.

>
>  > > 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. 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.

>  > > 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!

> 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?
> -Pete
>
>

------_=_NextPart_001_01C37B97.19CEC8EA-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 15 15:33:46 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 PAA22232 for ; Mon, 15 Sep 2003 15:33:46 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yz65-0008QN-Bv for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 15:33:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8FJXH3h032382 for mip4-archive@odin.ietf.org; Mon, 15 Sep 2003 15:33:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yz63-0008PL-4s for mip4-web-archive@optimus.ietf.org; Mon, 15 Sep 2003 15:33:17 -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 PAA22167 for ; Mon, 15 Sep 2003 15:32:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yz5p-00057N-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 15:33:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19yz5o-00057J-00 for mip4-web-archive@ietf.org; Mon, 15 Sep 2003 15:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yz5p-0008Mt-13; Mon, 15 Sep 2003 15:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yyjr-0007IP-Ig for mip4@optimus.ietf.org; Mon, 15 Sep 2003 15:10:20 -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 PAA20557 for ; Mon, 15 Sep 2003 15:10:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yyjo-0004jN-00 for Mip4@ietf.org; Mon, 15 Sep 2003 15:10:16 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19yyjn-0004jC-00 for Mip4@ietf.org; Mon, 15 Sep 2003 15:10:15 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h8FJ8FB04917; Mon, 15 Sep 2003 14:08:15 -0500 (CDT) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.173.84]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id h8FJ8Af23618; Mon, 15 Sep 2003 14:08:10 -0500 (CDT) Message-ID: <3F660E17.30706@lucent.com> Date: Mon, 15 Sep 2003 14:08:07 -0500 From: Tom Hiller Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Narten , Mip4@ietf.org CC: Russ Housley , Steven Bellovin , Basavaraj.Patil@nokia.com, Phil Roberts , gabriel montenegro , Gopal Dommety , Henrik Levkowetz , Pete McCann , Radia Perlman , Margaret Wasserman , margaret.wasserman@comcast.net, Bernard Aboba References: <200307301557.h6UFvjp09206@cichlid.adsl.duke.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] Re: FWD: AD review of draft-ietf-mobileip-aaa-key-13.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 Thomas, This email addresses comments on the aaa-keys-13 draft. Except for secur= ity comments regarding AAA key distribution to the HA/FA, I respond to commen= ts inline below. The major comment appears to be the security of AAA key distribution that= operates in conjunction with the aaa-keys extensions. Focussing on RADIU= S, RADIUS exposes the keys to the RADIUS proxies between the AAAH and the FA= or HA, and therefore, fails to meet security director guidelines for key mgt in = AAA. Those guideline state that keys should not be exposed to entities that do= not need to know. RADIUS proxies do not need to know the MN-FA or MN-HA keys= =2E A way forward suggested by Russ is that the aaa-keys draft state the prop= erties to be provided by the AAA system for the transport of keys. The followin= g are Russ's criterion for AAA key distribution from Atlanta: Be algorithm independent protocol Establish strong, fresh session keys Maintain algorithm independence Include replay detection mechanism Authenticate all parties Maintain confidentiality of authenticator NO plaintext passwords Perform client and NAS authorization Maintain confidentiality of session keys Confirm selection of =93best=94 ciphersuite Uniquely name session keys Compromise of a single NAS cannot compromise any other part of the system= , including session keys and long-term keys Bind key to appropriate context (Refer to http://www.drizzle.com/~aboba/IETF56/ietf56-aaa.zip, "AAA-key-mgt.ppt", slides 4-5). Also: "only entities that need to know shall see the key; it is not in th= e ppt file but I assume is included above confidentiality of session keys. I t= hink I saw a file with this explicitly mentioned but cannot locate that file. Would listing these as requirements for an AAA system to distribute keys = be sufficient (substituting "FA/HA" for "NAS")? Should the list be further= summarized; if there is a better list, please advise. If this approach w= ould work, I can find a logical place to include the requirements in the draft= =2E Further comments are appreciated. thanks, Tom > > ------- Forwarded Message > > From: Thomas Narten > To: mip4@ietf.org > Date: Wed, 30 Jul 2003 11:54:59 -0400 > Subject: AD review of draft-ietf-mobileip-aaa-key-13.txt > > Here are my review comments. Overall, I think the document is in > pretty good shape, but some wording clarifications would be > good. Also, more analysis of the security weaknesses is probably > warranted. > > Thomas > > Substantative: > > >> AAA security association >> A security association between a AAA entity >> and another node needing the services of that >> AAA entity. In this document all AAA security >> associations are between a mobile node and its home= >> AAA server (AAAH). A mobile node's AAA security >> association with its home AAA server (AAAH) may be >> based either on the mobile node's IP address or on >> its NAI [1]. > > > Could be more clear. > > In particular (based on later reading), the AAA association appears to > consist of a name for it (i.e, the SPI plus addresses so that peers > can agree on what AAA SA is being referred to) plus a key. The key of > some size (used in Section 5). Is there anything else that is > contained in this SA? It would be good to just state that the it is > simply a shared symetric key. It is not a symmetric key. The AAA-key length is not stated in section 5= =2E I am interested in input on whether the AAA-key's key length belongs in RFC301= 2bis and or in the aaa-keys draft. Proposed edit AAA security association A security association between a AAA enti= ty and another node needing the services of that AAA entity. In this document a= ll AAA security associations are between a mobile node and its home AAA server (= AAAH). A mobile node's AAA security association with its home AAA server (AAAH) = may be based either on the mobile node's IP address or on its NAI [1] along with= its SPI. The key is referred to as "AAA-key" in this specification. > > >> Mobility security association >> A Mobility Security Association is a simplex >> connection that serves to authenticate MIPv4 contro= l >> traffic such as between a MN and HA and/or a MN and= >> FA. A Mobility Security Association is identified >> by the two end points, such as a MN IP address and >> a HA IP address, and a SPI. Two nodes may have one >> or more Mobility Security Associations established >> between each other; however, typically there is >> no reason to have more than one Mobility Security >> Association between two nodes. > > > I.e., suggested rewording (and corrections, if I understand > correctly): > > Mobility security association > > A Mobility Security Association is a bi-directional > connection that applies security services to RFC 3344 > MIPv4 control traffic between a MN and HA (or MN and > FA) using RFC 3344 Authentication Extensions. A > Mobility Security Association is uniquely identified > by the peer source and destination IP addresses and an > SPI. Two nodes may have one or more Mobility Security > Associations established between each other; however, > typically there is no reason to have more than one > Mobility Security Association between two nodes. It is not a bidirectional connection. Proposed edit Mobility security association A Mobility Security Association is a s= implex connection that applies security services to RFC 3344 MIPv4 control traff= ic between a MN and HA (or MN and FA) using RFC 3344 Authentication Extensio= ns. A Mobility Security Association is uniquely identified by the peer source a= nd destination IP addresses and an SPI. Two nodes may have one or more Mobil= ity Security typically there is no reason to have more than one Mobility Secu= rity Association between two nodes. > > > >> Registration Key >> A key used as the basis of a Mobility Security >> Association between a mobile node and a foreign >> agent. A registration key is typically only used >> once or a very few times, and only for the purposes= >> of verifying a small volume of Authentication data.= > > > don't understand first sentence. > > Is Registration Key actually the key in the AAA Security Association? > If so, better to just say so. > > Agreed - proposed: Registration Key A key used in the Mobility Security Association between a mobile node and= a foreign agent. A registration key is typically only used once or a very = few times, and only for the purposes of verifying a small volume of Authentic= ation data. > > >> 2. If the mobile node does not have a Mobility Security Association= >> with the home agent, it MUST add an MN-HA Key Request extension >> (see Section 7.3) as part of its Registration Request that it >> sends to the Foreign Agent. > > > Is there no other way for the MN to set up the MN-HA key other than > via AAA? (Seems like the MUST is a bit strong.) The context of that statement is you have to do this if you're using the = methods of this draft. If you're using some other method then that would be out o= f the scope of this draft. > > >> 1. Using the Key Material from the extension, the mobile node >> calculates >> >> key =3D HMAC-MD5 (AAA-key, {Key Material || home address}) > > > what is AAA-key? Is this the key that is part of the AAA SA? Would be > good to define this better (e.g, define a term, and use the term > consistently). Also, does this key have any particular length or other > properties? See my comment on AAA Security Association above. I added the clarificati= on on AAA-key, and request input whether the AAA-key length should be defined i= n here aaa-keys or in RFC3012bis. > > >> MN-FA Key Request Subtype Data >> Data needed to carry out the creation of the >> registration key on behalf of the mobile node. >> This field is zero in length and carries no data= =2E > > > Would be better to have this field have the same name as is used in > (say) section 5, where "Key Material" is used. Can we define a proper > name for this field? > > Actually, why do you have this field at all, when it is defined to > have zero lengh and carry no data? The aaa-keys extensions have been designed into implementations. I don't = recall the history of the extension. I suggest we not make changes unless the c= hanges are necessary to make aaa-keys work or be more secure. It might be good = to get further input on this from other members of the group, however. > > > Security considerations seems pretty weak. Where is the analysis of > the weaknesses/vulnerabilities in the system? I.e, nothing is said > about how keys are distributed within the AAA and how if that is weak, > how it might result in compromise of the AAA key... Please see my note at beginning of email > > >> One further detail deserves mention. The Mobility Security >> Association to be established between the mobile node and the foreig= n >> agent have to be communicated to the foreign agent as well as to the= >> mobile node. The way that the key is distributed to the foreign >> agent is not relevant to any material in this document, and is >> expected to be handled as part of the AAA protocol processing betwee= n >> the AAAH and AAAL, and the further AAA protocol processing between >> the AAAL and the foreign agent. Any method by which the key can be >> securely transmitted to the AAAL and then relayed (possibly with >> re-encryption) to the foreign agent, is outside the jurisdiction >> of any Mobile IP specification, and thus compatible (by reason of >> non-interference) with the protocol extensions specified in this >> document. > > > Note: the above is not quite true. To understand the weaknesses of the > proposed extensions, one has to make assumptions about the above. I.e, > is the AAA SA key actually communicated to the FA via AAA? If so, > there are huge potential vulnerabilities here (one can't just assume > the AAA protocols are secure enough to not worry about this). I.e, is > there an assumption that the AAA Key itself will be communicated from > the AAAH to AAAL (and the FA?). Ditto, please refer to the top of this email. > > > Nits: > > Could use a TOC (see ID nits, http://www.ietf.org/ID-nits.html) > > >> AAA Registration Keys for Mobile IP > Agreed > > title doesn't satisfy ID nits? (Not sure AAA will be acceptable to rfc > editor). I have no problem with a different title, but there are RFCs with AAA in = the title (RFC2989). Should we spell out AAA in the title, or find a complet= ely new title? > > >> the Authentication Data need by authentication extensions used in > > > s/need/needed/ ? Agreed > > >> It is also assumed that the AAA entities involved (i.e., the AAAH, >> AAAL, and the AAA interface features of the foreign agents and home > > > AAAH and AAAL not defined/expanded in first use. Agreed to expand. > > > >> The key material may be requested by the mobile node in new >> extensions to Mobile IP Registration Request messages, and supplied >> to the mobile node in extensions to the Mobile IP Registration Reply= >> messages. Alternatively, the AAA server MAY provide unsolicited key= > > > s/new extensions/new extensions (defined below)/ Agreed. > > >> messages. Alternatively, the AAA server MAY provide unsolicited key= >> material to mobile nodes; the mobile node MUST then calculate new > > > s/material/material via mobility agents/ Agreed > > >> 8. If a MN-HA Key Material from AAA Key Material extension is >> present in the Registration Reply message, then the mobile node >> MUST create or update its Mobility Security Association with the= >> Home Agent indicated in the Registration Reply, using the key >> computed from the Key Material in the AAA extension. In this >> case, if no Key Material extension is present, the mobile node >> MUST discard the Registration Reply. If the mobile node does >> not already have a Mobility Security Association with the Home >> Agent indicated in the Registration Reply message, and if no Key= >> Material extension is present, the mobile node MUST discard the >> Registration Reply. >> > > > Is this last sentence needed? There is an AND in the if. But one o > the ANDs is already covered bythe previous sentence (I think), in > which case the RR is already supposed to be discarded. Agreed > > >> The following steps are performed on the AAA server: > > > AAAL or AAAH? (I assume the former). > It is the AAAH, not the AAAL. Will fix by making it "AAAH". > > >> 2. The mobile node creates the Mobility Security Association, using= >> the key and the other relevant information in the Key Extension.= >> > > > which MSA? the one to the HA or the one to the FA? It could be either, how about s/"Association/Association(s)/"? > > >> The Generalized MN-FA Key Reply extension supplies a registration ke= y >> requested by using one of the subtypes of the Generalized MN-FA Key > > > not a "registration key", but "keying material" Agreed > > >> MN-FA Key Reply Subtype Data >> An encoded copy of the registration key, along with an= y >> other information needed by the recipient to create th= e >> designated Mobility Security Association. > > > needs better text; this is not a key, its keying material. (do the > same throughout document) Agreed > > >> If the foreign agent receives a Registration Reply that has no MN-FA= >> Key Reply extension, and if it has no existing Mobility Security >> Association with the mobile node, the foreign agent MAY change >> the Code value of the Registration Reply to MISSING_MN_FA (see >> section 8), effectively causing the registration to fail. > > > Is this a typo? I thought the MN would get the RR, not the FA. How is > the FA getting this? In FA CoA mode of MIP, the FA receives the Reply first. > > >>6.1. Generalized MN-FA Key Request Extension > > > Note: It would seem to be better to rename this extension to be "Key > Material" request or something, as this is NOT requesting a Key per > se. Agreed > > IANA Considerations: > > >> The Code value specified for error MISSING_MN_FA, listed in >> section 8, MUST NOT conflict with any other code values listed in >> RFC 3344, RFC 3024 [10], or RFC 2356 [11]. This value is to be >> taken from the space of error values conventionally associated with >> rejection by the foreign agent (i.e., 64-127). > > > Above doesn't quite make sense in IANA considerations. IANA doens't > assign values that have already been assigned for other purposes. Or > rather, they only do so if folks have just used a number for some > purpose without bothering to allocate it properly from IANA. So, the > above paragraph should be reworded to just say IANA assigns a TBD, and > if there is a recommended value, suggest what it is). I.e, does the WG > know more than IANA about the code values that are already in use? Agreed > > >> Section 4 introduces the Replay Method Identifier namespace that >> requires IANA management. This specification makes use of 1-3; >> all other values other than zero (0) or one (1) are available for >> assignment, pending review and approval by a Designated Expert [12].= > > > Better to use words like: IANA will create and maintain namespace for > Replay Method Identifier as defined in Section 4. This > specification... Agreed > > In appendix C, I think you want to use a term other than "IP Security > Association". First, its a term that is not defined. Second, it can be > read to mean IPsec SAs, which I suspect is not actually the case. Those security associations are in fact IPSec associations. I will clari= fy that. > > > ------- End of Forwarded Message > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 16 08:12: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 IAA04982 for ; Tue, 16 Sep 2003 08:12: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 19zEgd-00033a-IJ for mip4-archive@odin.ietf.org; Tue, 16 Sep 2003 08:12:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GCC3AL011746 for mip4-archive@odin.ietf.org; Tue, 16 Sep 2003 08:12:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zEgd-00033N-EQ for mip4-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 08:12: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 IAA04979 for ; Tue, 16 Sep 2003 08:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zEgc-0007YJ-00 for mip4-web-archive@ietf.org; Tue, 16 Sep 2003 08:12:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zEgc-0007YF-00 for mip4-web-archive@ietf.org; Tue, 16 Sep 2003 08:12:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zEgb-000338-FT; Tue, 16 Sep 2003 08:12:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zEgH-00032u-R3 for mip4@optimus.ietf.org; Tue, 16 Sep 2003 08:11:41 -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 IAA04974 for ; Tue, 16 Sep 2003 08:11:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zEgG-0007YB-00 for Mip4@ietf.org; Tue, 16 Sep 2003 08:11:40 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19zEgG-0007Y8-00 for Mip4@ietf.org; Tue, 16 Sep 2003 08:11:40 -0400 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h8GCB6P00047 for ; Tue, 16 Sep 2003 07:11:06 -0500 (CDT) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.157.20]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id h8GCB4f24569; Tue, 16 Sep 2003 07:11:04 -0500 (CDT) Message-ID: <3F66FDD4.8040802@lucent.com> Date: Tue, 16 Sep 2003 07:11:00 -0500 From: Tom Hiller Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mip4@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] Re: FWD: AD review of draft-ietf-mobileip-aaa-key-13.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 (I sent this out yesterday and it bounced, so I am trying again. Sorry i= f it is a duplicate). Thomas, This email addresses comments on the aaa-keys-13 draft. Except for secur= ity comments regarding AAA key distribution to the HA/FA, I respond to commen= ts inline below. The major comment appears to be the security of AAA key distribution that= operates in conjunction with the aaa-keys extensions. Focussing on RADIU= S, RADIUS exposes the keys to the RADIUS proxies between the AAAH and the FA= or HA, and therefore, fails to meet security director guidelines for key mgt in = AAA. Those guideline state that keys should not be exposed to entities that do= not need to know. RADIUS proxies do not need to know the MN-FA or MN-HA keys= =2E A way forward suggested by Russ is that the aaa-keys draft state the prop= erties to be provided by the AAA system for the transport of keys. The followin= g are Russ's criterion for AAA key distribution from Atlanta: Be algorithm independent protocol Establish strong, fresh session keys Maintain algorithm independence Include replay detection mechanism Authenticate all parties Maintain confidentiality of authenticator NO plaintext passwords Perform client and NAS authorization Maintain confidentiality of session keys Confirm selection of =93best=94 ciphersuite Uniquely name session keys Compromise of a single NAS cannot compromise any other part of the system= , including session keys and long-term keys Bind key to appropriate context (Refer to http://www.drizzle.com/~aboba/IETF56/ietf56-aaa.zip, "AAA-key-mgt.ppt", slides 4-5). Also: "only entities that need to know shall see the key; it is not in th= e ppt file but I assume is included above confidentiality of session keys. I t= hink I saw a file with this explicitly mentioned but cannot locate that file. Would listing these as requirements for an AAA system to distribute keys = be sufficient (substituting "FA/HA" for "NAS")? Should the list be further= summarized; if there is a better list, please advise. If this approach w= ould work, I can find a logical place to include the requirements in the draft= =2E Further comments are appreciated. thanks, Tom > > ------- Forwarded Message > > From: Thomas Narten > To: mip4@ietf.org > Date: Wed, 30 Jul 2003 11:54:59 -0400 > Subject: AD review of draft-ietf-mobileip-aaa-key-13.txt > > Here are my review comments. Overall, I think the document is in > pretty good shape, but some wording clarifications would be > good. Also, more analysis of the security weaknesses is probably > warranted. > > Thomas > > Substantative: > > >> AAA security association >> A security association between a AAA entity >> and another node needing the services of that >> AAA entity. In this document all AAA security >> associations are between a mobile node and its home= >> AAA server (AAAH). A mobile node's AAA security >> association with its home AAA server (AAAH) may be >> based either on the mobile node's IP address or on >> its NAI [1]. > > > Could be more clear. > > In particular (based on later reading), the AAA association appears to > consist of a name for it (i.e, the SPI plus addresses so that peers > can agree on what AAA SA is being referred to) plus a key. The key of > some size (used in Section 5). Is there anything else that is > contained in this SA? It would be good to just state that the it is > simply a shared symetric key. It is not a symmetric key. The AAA-key length is not stated in section 5= =2E I am interested in input on whether the AAA-key's key length belongs in RFC301= 2bis and or in the aaa-keys draft. Proposed edit AAA security association A security association between a AAA enti= ty and another node needing the services of that AAA entity. In this document a= ll AAA security associations are between a mobile node and its home AAA server (= AAAH). A mobile node's AAA security association with its home AAA server (AAAH) = may be based either on the mobile node's IP address or on its NAI [1] along with= its SPI. The key is referred to as "AAA-key" in this specification. > > >> Mobility security association >> A Mobility Security Association is a simplex >> connection that serves to authenticate MIPv4 contro= l >> traffic such as between a MN and HA and/or a MN and= >> FA. A Mobility Security Association is identified >> by the two end points, such as a MN IP address and >> a HA IP address, and a SPI. Two nodes may have one >> or more Mobility Security Associations established >> between each other; however, typically there is >> no reason to have more than one Mobility Security >> Association between two nodes. > > > I.e., suggested rewording (and corrections, if I understand > correctly): > > Mobility security association > > A Mobility Security Association is a bi-directional > connection that applies security services to RFC 3344 > MIPv4 control traffic between a MN and HA (or MN and > FA) using RFC 3344 Authentication Extensions. A > Mobility Security Association is uniquely identified > by the peer source and destination IP addresses and an > SPI. Two nodes may have one or more Mobility Security > Associations established between each other; however, > typically there is no reason to have more than one > Mobility Security Association between two nodes. It is not a bidirectional connection. Proposed edit Mobility security association A Mobility Security Association is a s= implex connection that applies security services to RFC 3344 MIPv4 control traff= ic between a MN and HA (or MN and FA) using RFC 3344 Authentication Extensio= ns. A Mobility Security Association is uniquely identified by the peer source a= nd destination IP addresses and an SPI. Two nodes may have one or more Mobil= ity Security typically there is no reason to have more than one Mobility Secu= rity Association between two nodes. > > > >> Registration Key >> A key used as the basis of a Mobility Security >> Association between a mobile node and a foreign >> agent. A registration key is typically only used >> once or a very few times, and only for the purposes= >> of verifying a small volume of Authentication data.= > > > don't understand first sentence. > > Is Registration Key actually the key in the AAA Security Association? > If so, better to just say so. > > Agreed - proposed: Registration Key A key used in the Mobility Security Association between a mobile node and= a foreign agent. A registration key is typically only used once or a very = few times, and only for the purposes of verifying a small volume of Authentic= ation data. > > >> 2. If the mobile node does not have a Mobility Security Association= >> with the home agent, it MUST add an MN-HA Key Request extension >> (see Section 7.3) as part of its Registration Request that it >> sends to the Foreign Agent. > > > Is there no other way for the MN to set up the MN-HA key other than > via AAA? (Seems like the MUST is a bit strong.) The context of that statement is you have to do this if you're using the = methods of this draft. If you're using some other method then that would be out o= f the scope of this draft. > > >> 1. Using the Key Material from the extension, the mobile node >> calculates >> >> key =3D HMAC-MD5 (AAA-key, {Key Material || home address}) > > > what is AAA-key? Is this the key that is part of the AAA SA? Would be > good to define this better (e.g, define a term, and use the term > consistently). Also, does this key have any particular length or other > properties? See my comment on AAA Security Association above. I added the clarificati= on on AAA-key, and request input whether the AAA-key length should be defined i= n here aaa-keys or in RFC3012bis. > > >> MN-FA Key Request Subtype Data >> Data needed to carry out the creation of the >> registration key on behalf of the mobile node. >> This field is zero in length and carries no data= =2E > > > Would be better to have this field have the same name as is used in > (say) section 5, where "Key Material" is used. Can we define a proper > name for this field? > > Actually, why do you have this field at all, when it is defined to > have zero lengh and carry no data? The aaa-keys extensions have been designed into implementations. I don't = recall the history of the extension. I suggest we not make changes unless the c= hanges are necessary to make aaa-keys work or be more secure. It might be good = to get further input on this from other members of the group, however. > > > Security considerations seems pretty weak. Where is the analysis of > the weaknesses/vulnerabilities in the system? I.e, nothing is said > about how keys are distributed within the AAA and how if that is weak, > how it might result in compromise of the AAA key... Please see my note at beginning of email > > >> One further detail deserves mention. The Mobility Security >> Association to be established between the mobile node and the foreig= n >> agent have to be communicated to the foreign agent as well as to the= >> mobile node. The way that the key is distributed to the foreign >> agent is not relevant to any material in this document, and is >> expected to be handled as part of the AAA protocol processing betwee= n >> the AAAH and AAAL, and the further AAA protocol processing between >> the AAAL and the foreign agent. Any method by which the key can be >> securely transmitted to the AAAL and then relayed (possibly with >> re-encryption) to the foreign agent, is outside the jurisdiction >> of any Mobile IP specification, and thus compatible (by reason of >> non-interference) with the protocol extensions specified in this >> document. > > > Note: the above is not quite true. To understand the weaknesses of the > proposed extensions, one has to make assumptions about the above. I.e, > is the AAA SA key actually communicated to the FA via AAA? If so, > there are huge potential vulnerabilities here (one can't just assume > the AAA protocols are secure enough to not worry about this). I.e, is > there an assumption that the AAA Key itself will be communicated from > the AAAH to AAAL (and the FA?). Ditto, please refer to the top of this email. > > > Nits: > > Could use a TOC (see ID nits, http://www.ietf.org/ID-nits.html) > > >> AAA Registration Keys for Mobile IP > Agreed > > title doesn't satisfy ID nits? (Not sure AAA will be acceptable to rfc > editor). I have no problem with a different title, but there are RFCs with AAA in = the title (RFC2989). Should we spell out AAA in the title, or find a complet= ely new title? > > >> the Authentication Data need by authentication extensions used in > > > s/need/needed/ ? Agreed > > >> It is also assumed that the AAA entities involved (i.e., the AAAH, >> AAAL, and the AAA interface features of the foreign agents and home > > > AAAH and AAAL not defined/expanded in first use. Agreed to expand. > > > >> The key material may be requested by the mobile node in new >> extensions to Mobile IP Registration Request messages, and supplied >> to the mobile node in extensions to the Mobile IP Registration Reply= >> messages. Alternatively, the AAA server MAY provide unsolicited key= > > > s/new extensions/new extensions (defined below)/ Agreed. > > >> messages. Alternatively, the AAA server MAY provide unsolicited key= >> material to mobile nodes; the mobile node MUST then calculate new > > > s/material/material via mobility agents/ Agreed > > >> 8. If a MN-HA Key Material from AAA Key Material extension is >> present in the Registration Reply message, then the mobile node >> MUST create or update its Mobility Security Association with the= >> Home Agent indicated in the Registration Reply, using the key >> computed from the Key Material in the AAA extension. In this >> case, if no Key Material extension is present, the mobile node >> MUST discard the Registration Reply. If the mobile node does >> not already have a Mobility Security Association with the Home >> Agent indicated in the Registration Reply message, and if no Key= >> Material extension is present, the mobile node MUST discard the >> Registration Reply. >> > > > Is this last sentence needed? There is an AND in the if. But one o > the ANDs is already covered bythe previous sentence (I think), in > which case the RR is already supposed to be discarded. Agreed > > >> The following steps are performed on the AAA server: > > > AAAL or AAAH? (I assume the former). > It is the AAAH, not the AAAL. Will fix by making it "AAAH". > > >> 2. The mobile node creates the Mobility Security Association, using= >> the key and the other relevant information in the Key Extension.= >> > > > which MSA? the one to the HA or the one to the FA? It could be either, how about s/"Association/Association(s)/"? > > >> The Generalized MN-FA Key Reply extension supplies a registration ke= y >> requested by using one of the subtypes of the Generalized MN-FA Key > > > not a "registration key", but "keying material" Agreed > > >> MN-FA Key Reply Subtype Data >> An encoded copy of the registration key, along with an= y >> other information needed by the recipient to create th= e >> designated Mobility Security Association. > > > needs better text; this is not a key, its keying material. (do the > same throughout document) Agreed > > >> If the foreign agent receives a Registration Reply that has no MN-FA= >> Key Reply extension, and if it has no existing Mobility Security >> Association with the mobile node, the foreign agent MAY change >> the Code value of the Registration Reply to MISSING_MN_FA (see >> section 8), effectively causing the registration to fail. > > > Is this a typo? I thought the MN would get the RR, not the FA. How is > the FA getting this? In FA CoA mode of MIP, the FA receives the Reply first. > > >>6.1. Generalized MN-FA Key Request Extension > > > Note: It would seem to be better to rename this extension to be "Key > Material" request or something, as this is NOT requesting a Key per > se. Agreed > > IANA Considerations: > > >> The Code value specified for error MISSING_MN_FA, listed in >> section 8, MUST NOT conflict with any other code values listed in >> RFC 3344, RFC 3024 [10], or RFC 2356 [11]. This value is to be >> taken from the space of error values conventionally associated with >> rejection by the foreign agent (i.e., 64-127). > > > Above doesn't quite make sense in IANA considerations. IANA doens't > assign values that have already been assigned for other purposes. Or > rather, they only do so if folks have just used a number for some > purpose without bothering to allocate it properly from IANA. So, the > above paragraph should be reworded to just say IANA assigns a TBD, and > if there is a recommended value, suggest what it is). I.e, does the WG > know more than IANA about the code values that are already in use? Agreed > > >> Section 4 introduces the Replay Method Identifier namespace that >> requires IANA management. This specification makes use of 1-3; >> all other values other than zero (0) or one (1) are available for >> assignment, pending review and approval by a Designated Expert [12].= > > > Better to use words like: IANA will create and maintain namespace for > Replay Method Identifier as defined in Section 4. This > specification... Agreed > > In appendix C, I think you want to use a term other than "IP Security > Association". First, its a term that is not defined. Second, it can be > read to mean IPsec SAs, which I suspect is not actually the case. Those security associations are in fact IPSec associations. I will clari= fy that. > > > ------- End of Forwarded Message > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 16 15:27: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 PAA04716 for ; Tue, 16 Sep 2003 15:27: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 19zLTc-0004xl-I5 for mip4-archive@odin.ietf.org; Tue, 16 Sep 2003 15:27:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8GJR4nm019077 for mip4-archive@odin.ietf.org; Tue, 16 Sep 2003 15:27:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLTb-0004xc-Tl for mip4-web-archive@optimus.ietf.org; Tue, 16 Sep 2003 15:27: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 PAA04682 for ; Tue, 16 Sep 2003 15:26:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLTa-0000MA-00 for mip4-web-archive@ietf.org; Tue, 16 Sep 2003 15:27:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zLTa-0000M7-00 for mip4-web-archive@ietf.org; Tue, 16 Sep 2003 15:27:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLTZ-0004xE-LS; Tue, 16 Sep 2003 15: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 19zLT5-0004wm-FA for mip4@optimus.ietf.org; Tue, 16 Sep 2003 15:26: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 PAA04671 for ; Tue, 16 Sep 2003 15:26:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLT3-0000Lu-00 for mip4@ietf.org; Tue, 16 Sep 2003 15:26:29 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19zLT3-0000LZ-00 for mip4@ietf.org; Tue, 16 Sep 2003 15:26:29 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h8GJPl812200; Tue, 16 Sep 2003 14:25:48 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h8GJPiR17734; Tue, 16 Sep 2003 14:25:44 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HLBJBZ-0000Z4-00; Tue, 16 Sep 2003 13:59:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16231.20385.362940.574019@gargle.gargle.HOWL> Date: Tue, 16 Sep 2003 13:00:01 -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, 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 Thu Sep 18 01:24: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 BAA15139 for ; Thu, 18 Sep 2003 01:24: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 19zrGu-0003mF-E7 for mip4-archive@odin.ietf.org; Thu, 18 Sep 2003 01:24:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I5O45G014515 for mip4-archive@odin.ietf.org; Thu, 18 Sep 2003 01:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zrGu-0003m2-8s for mip4-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 01:24: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 BAA15132 for ; Thu, 18 Sep 2003 01:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zrGr-0000vD-00 for mip4-web-archive@ietf.org; Thu, 18 Sep 2003 01:24:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zrGq-0000v9-00 for mip4-web-archive@ietf.org; Thu, 18 Sep 2003 01:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zrGr-0003lf-EV; Thu, 18 Sep 2003 01: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 19zrGR-0003lN-VX for mip4@optimus.ietf.org; Thu, 18 Sep 2003 01:23:36 -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 BAA15125 for ; Thu, 18 Sep 2003 01:23:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zrGO-0000v1-00 for mip4@ietf.org; Thu, 18 Sep 2003 01:23:32 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 19zrGN-0000uv-00 for mip4@ietf.org; Thu, 18 Sep 2003 01:23:32 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8I5Mtp15511; Wed, 17 Sep 2003 22:22:55 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 00:22:55 -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: Thu, 18 Sep 2003 00:22:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37DA4.E8415490" 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_01C37DA4.E8415490 Content-Type: text/plain Hi, Pete, Comments inline. Regards, Ahmad > > 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. [AM] I have no problem with 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? > [AM] I am sorry, I do not understand what you mean. Can you elaborate here. > > > > > 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 mean the simple algorithm that RFC3344 suggested for the MN to use for retransmission. sta > 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. > [AM] Are you saying that you can always predict the delay of the network in general when the running over a cdma2000 link and 4 seconds will always work. > 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. [AM] Eventually is limited here. Because the MN will continue to try until registration lifetime expires. > > > 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. > [AM] I am not sure if that an optimal solution. Let us say MN is running over cdma2000 link and a MN vendor sets the retransmit initial time to 10 seconds (just to make sure that RRP is gauranteed to arrive before retransmit). This may work fine for this scenario. The problem here, we are recommending a standard around an exception. In normal case, service provider do not want the MN to wait for 10 seconds reserving resources to retransmit. Air resources very valuable. > > > > > > 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? [AM] It is the very basic algorith suggested by RFC3344. MN retransmit after t, then, 2t, 4t, ... > > > > 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? > [AM] You are correct; I did not see anything there. But you are recommendiung that the MN to ignore the state that it is using to detect that its no longer has a session with its HA, based on an error scenario > Can anyone else speak up if there is really a known deadlock > problem here that we need to address? > > -Pete > > > > ------_=_NextPart_001_01C37DA4.E8415490 Content-Type: text/html RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS

Hi, Pete,
Comments inline.

Regards,
Ahmad

>
> 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.

[AM]
I have no problem with 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?
>
[AM]
I am sorry, I do not understand what you mean. Can you elaborate here.

>  > >  > > 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 mean the simple algorithm that RFC3344 suggested for the MN to use for retransmission.
sta
> 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.
>

[AM]
Are you saying that you can always predict the delay of the network in general when the running over a cdma2000 link and 4 seconds will always work.

> 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.

[AM]
Eventually is limited here. Because the MN will continue to try until registration lifetime expires.

>
>  > 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.
>

[AM]
I am not sure if that an optimal solution.  Let us say MN is running over cdma2000 link and a MN vendor sets the retransmit initial time to 10 seconds (just to make sure that RRP is gauranteed to arrive before retransmit). This may work fine for this scenario. The problem here, we are recommending a standard around an exception. In normal case, service provider do not want the MN to wait for 10 seconds reserving resources to retransmit. Air resources very valuable.

>
>  > >  > > 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?

[AM]
It is the very basic algorith suggested by RFC3344. MN retransmit after t, then, 2t, 4t, ...

>
>  > > 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?
>

[AM]
You are correct; I did not see anything there. But you are recommendiung that the MN to ignore the state that it is using to detect that its no longer has a session with its HA, based on an error scenario

> Can anyone else speak up if there is really a known deadlock
> problem here that we need to address?
>
> -Pete
>
>
>
>

------_=_NextPart_001_01C37DA4.E8415490-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 18 01:52: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 BAA15834 for ; Thu, 18 Sep 2003 01:52: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 19zrhz-0004Pu-UL for mip4-archive@odin.ietf.org; Thu, 18 Sep 2003 01:52:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8I5q3Ph016972 for mip4-archive@odin.ietf.org; Thu, 18 Sep 2003 01:52:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zrhz-0004Pf-Ob for mip4-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 01:52: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 BAA15810 for ; Thu, 18 Sep 2003 01:51:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zrhw-0001BC-00 for mip4-web-archive@ietf.org; Thu, 18 Sep 2003 01:52:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zrhv-0001B9-00 for mip4-web-archive@ietf.org; Thu, 18 Sep 2003 01:51:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zrhy-0004PQ-1g; Thu, 18 Sep 2003 01:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zrhq-0004PD-IH for mip4@optimus.ietf.org; Thu, 18 Sep 2003 01:51: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 BAA15807 for ; Thu, 18 Sep 2003 01:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zrhn-0001B4-00 for mip4@ietf.org; Thu, 18 Sep 2003 01:51:51 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19zrhm-0001Au-00 for mip4@ietf.org; Thu, 18 Sep 2003 01:51:50 -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 h8I5p6d14218; Thu, 18 Sep 2003 00:51:07 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 18 Sep 2003 00:51:07 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "'mip4@ietf.org'" , "Jayshree Bharatia" Subject: RE: PLEASE ignore previous email, was sent accidently [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS Date: Thu, 18 Sep 2003 00:51:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37DA8.D7D59F68" 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_01C37DA8.D7D59F68 Content-Type: text/plain Hi, Pete, Comments inline. Regards, Ahmad > > 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. [AM] I have no problem with 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? [AM] I am sorry, I do not understand what you mean. Please elaborate. > > > > > > 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? [AM] I mean the simple algorithm that RFC3344 suggested for the MN to use for 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. [AM] Are you saying that you can always predict the delay of the network in general when running over a cdma2000 link and 4 seconds will always work. > > 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. [AM] "Eventually" is limited here. Because the MN will continue to try until registration lifetime expires. > > > 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. > [AM] I am not sure if that an optimal solution. Let us say MN is running over cdma2000 link and a MN vendor sets the retransmit initial time to 10 seconds (just to make sure that RRP is guaranteed to arrive before retransmit). The problem here, we are recommending a standard around an exception. In normal case, service provider do not want the MN to wait for 10 seconds reserving resources before retransmits for the obvious reason of lost RRQ. > > > > > > 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? [AM] It is the very basic algorithm suggested by RFC3344. MN retransmit after t, then 2t, 4t, ... > > > > 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? [AM] You are correct. I did not see anything there. I thought that the MN is authorized to use its data session after successful exchange of authentic control messages. It seems to me that you are suggesting the opposite. Am I reading you correctly here? As long as MN can transmit data, It is guaranteed service with its HA and probably does not need to exchange authentic control messages. Is MN allowed to update its registration lifetime in this case? > > Can anyone else speak up if there is really a known deadlock > problem here that we need to address? > > -Pete > > > > ------_=_NextPart_001_01C37DA8.D7D59F68 Content-Type: text/html RE: PLEASE ignore previous email, was sent accidently [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS

Hi, Pete,
Comments inline.

Regards,
Ahmad

>
> 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.

[AM]
I have no problem with 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?

[AM]
I am sorry, I do not understand what you mean. Please elaborate.
>
>  > >  > > 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?

[AM]
I mean the simple algorithm that RFC3344 suggested for the MN to use for 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.

[AM]
Are you saying that you can always predict the delay of the network in general when running over a cdma2000 link and 4 seconds will always work.

>
> 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.

[AM]
"Eventually" is limited here. Because the MN will continue to try until registration lifetime expires.
>
>  > 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.
>

[AM]
I am not sure if that an optimal solution.  Let us say MN is running over cdma2000 link and a MN vendor sets the retransmit initial time to 10 seconds (just to make sure that RRP is guaranteed to arrive before retransmit). The problem here, we are recommending a standard around an exception. In normal case, service provider do not want the MN to wait for 10 seconds reserving resources before retransmits for the obvious reason of lost RRQ. 

>
>  > >  > > 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?

[AM]
It is the very basic algorithm suggested by RFC3344. MN retransmit after t, then 2t, 4t, ...
>
>  > > 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?

[AM]
You are correct. I did not see anything there.
I thought that the MN is authorized to use its data session after successful exchange of authentic control messages. It seems to me that you are suggesting the opposite.

Am I reading you correctly here? As long as MN can transmit data, It is guaranteed service with its HA and probably does not need to exchange authentic control messages. Is MN allowed to update its registration lifetime in this case?

 

>
> Can anyone else speak up if there is really a known deadlock
> problem here that we need to address?
>
> -Pete
>
>
>
>

------_=_NextPart_001_01C37DA8.D7D59F68-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 18 08:30:33 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 IAA09198 for ; Thu, 18 Sep 2003 08:30: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 19zxvF-0002XV-DO for mip4-archive@odin.ietf.org; Thu, 18 Sep 2003 08:30:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ICU92K009755 for mip4-archive@odin.ietf.org; Thu, 18 Sep 2003 08:30:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zxvF-0002XG-8R for mip4-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 08:30: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 IAA09181 for ; Thu, 18 Sep 2003 08:30:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zxvE-0005Cy-00 for mip4-web-archive@ietf.org; Thu, 18 Sep 2003 08:30:08 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19zxvD-0005Cv-00 for mip4-web-archive@ietf.org; Thu, 18 Sep 2003 08:30:07 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zxv9-0002Wy-En; Thu, 18 Sep 2003 08:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zxuk-0002WM-8M for mip4@optimus.ietf.org; Thu, 18 Sep 2003 08:29:38 -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 IAA09174; Thu, 18 Sep 2003 08:29:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zxuj-0005Ck-00; Thu, 18 Sep 2003 08:29:37 -0400 Received: from seraph3.grc.nasa.gov ([128.156.10.12]) by ietf-mx with esmtp (Exim 4.12) id 19zxui-0005Cc-00; Thu, 18 Sep 2003 08:29:36 -0400 Received: from lombok-fi.lerc.nasa.gov (lombok-fi.grc.nasa.gov [139.88.112.33]) by seraph3.grc.nasa.gov (Postfix) with ESMTP id 22AA76BA7F; Thu, 18 Sep 2003 08:29:06 -0400 (EDT) Received: from apataki-fi.lerc.nasa.gov (apataki-fi.grc.nasa.gov [139.88.112.35]) by lombok-fi.lerc.nasa.gov (NASA GRC TCPD 8.12.9/8.12.9) with ESMTP id h8ICT5op023478; Thu, 18 Sep 2003 08:29:05 -0400 (EDT) Received: from GR7700006462.grc.nasa.gov (gr7700006462.grc.nasa.gov [139.88.111.44]) by apataki-fi.lerc.nasa.gov (NASA GRC 8.12.9/8.12.9) with ESMTP id h8ICT4RT026301; Thu, 18 Sep 2003 08:29:04 -0400 (EDT) X-Info: ODIN / NASA Glenn Research Center Message-Id: <5.1.1.5.2.20030918081421.01822670@popserve.grc.nasa.gov> X-Sender: caivanc@popserve.grc.nasa.gov X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 18 Sep 2003 08:29:03 -0400 To: mip4@ietf.org, nemo@ietf.org From: William D Ivancic Cc: sharon Gowan In-Reply-To: <5.1.0.14.2.20030911083507.03b53850@po2.bbn.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_587616718==.ALT" Subject: [Mip4] Secure Mobile Networking Deployment 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: , --=====================_587616718==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable We recently / currently have secure mobile networking deployed in and=20 "experimental" operational setting onboard a US Coast Guard Cutter. The=20 system is described in the following paper, "Securing Mobile Networks in an= =20 Operational Setting." This may be of interest to mip4 and nemo regarding= =20 multihoming and security issues and actual problems that needed to be=20 solved to deploy this over the Open Internet. http://roland.grc.nasa.gov/~ivancic/papers_presentations/IEEE_PID24402.pdf Abstract=97This paper describes a network demonstration three month field trial of mobile networking using IPv4. The network was implemented as part of the Guard operational network which is a ".mil" network requires stringent levels of security. The initial demonstrations took place in November 2002 and a three month field place from July through September of 2003. The network utilized encryptors capable of NSA-approved algorithms, mobile router from Cisco Systems and 802.11 satellite wireless links. This paper also describes a conceptual architecture for wide-scale deployment of secure networking in operational environments where both and public infrastructure is used. Additional issues include link costs, placement of encryptors and routing protocols over layer-3 encryption devices. We are currently working with T-Mobile and then Verison Wireless in the US= =20 to be able to deploy mobile-IPv4 over GPRS (56 kbps) and CDMA (114=20 kbps). There appears to be a lot of NAT / PAT and administrative=20 filtering issues that we are trying to resolve. Hopefully, what we learn=20 with IPv4 can be applied to IPv6. We will pass whatever useful information= =20 we can on to these groups. Another area we just completed was deploying and IPv4 mobile network that=20 can move between the NASA Private address space and the public address=20 space. This wasn't terribly difficult, but required a lot of coordination= =20 with the security personnel controlling the firewalls. We are trying to=20 understand how the firewall rule impact features like dynamic home agent=20 deployment. Once completed, we will document this and pass the=20 information on. Will --=====================_587616718==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We recently / currently have secure mobile networking deployed in and "experimental" operational setting onboard a US Coast Guard Cutter.  The system is described in the following paper, "Securing Mobile Networks in an Operational Setting."   This may be of interest to mip4 and nemo regarding multihoming and security issues and actual problems that needed to be solved to deploy this over the Open Internet. 

http://roland.grc.nasa.gov/~ivancic/papers_presentations= /IEEE_PID24402.pdf

Abstract=97This paper describes a network demonstration
three month field trial of mobile networking using
IPv4. The network was implemented as part of the
Guard operational network which is a ".mil" network
requires stringent levels of security. The initial demonstrations
took place in November 2002 and a three month field
place from July through September of 2003. The
network utilized encryptors capable of NSA-approved
algorithms, mobile router from Cisco Systems and 802.11
satellite wireless links. This paper also describes a conceptual
architecture for wide-scale deployment of secure
networking in operational environments where both
and public infrastructure is used. Additional issues
include link costs, placement of encryptors and
routing protocols over layer-3 encryption devices.

We are currently working with T-Mobile and then Verison Wireless in the US to be able to deploy mobile-IPv4 over GPRS (56 kbps) and CDMA (114 kbps).   There appears to be a lot of NAT / PAT and administrative filtering issues that we are trying to resolve.  Hopefully, what we learn with IPv4 can be applied to IPv6.  We will pass whatever useful information we can on to these groups.

Another area we just completed was deploying and IPv4 mobile network that can move between the NASA Private address space and the public address space.  This wasn't terribly difficult, but required a lot of coordination with the security personnel controlling the firewalls.  We are trying to understand how the firewall rule impact features like dynamic home agent deployment.   Once completed, we will document this and pass the information on. 


Will
--=====================_587616718==.ALT-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 18 12:03: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 MAA20094 for ; Thu, 18 Sep 2003 12:03: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 1A01FG-0003J3-Ui for mip4-archive@odin.ietf.org; Thu, 18 Sep 2003 12:03:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8IG32rA012709 for mip4-archive@odin.ietf.org; Thu, 18 Sep 2003 12:03:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A01FG-0003Iu-OZ for mip4-web-archive@optimus.ietf.org; Thu, 18 Sep 2003 12:03: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 MAA20020 for ; Thu, 18 Sep 2003 12:02:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01FF-0000Xl-00 for mip4-web-archive@ietf.org; Thu, 18 Sep 2003 12:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A01FF-0000Xi-00 for mip4-web-archive@ietf.org; Thu, 18 Sep 2003 12: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 1A01FF-0003Ia-QG; Thu, 18 Sep 2003 12: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 1A01Ex-0003IG-Tt for mip4@optimus.ietf.org; Thu, 18 Sep 2003 12:02:43 -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 MAA19999 for ; Thu, 18 Sep 2003 12:02:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A01Ew-0000X1-00 for mip4@ietf.org; Thu, 18 Sep 2003 12:02:42 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A01Et-0000UL-00 for mip4@ietf.org; Thu, 18 Sep 2003 12:02:40 -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 h8IG1vCj032641; Thu, 18 Sep 2003 18:01:58 +0200 Date: Thu, 18 Sep 2003 18:01:58 +0200 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann Message-Id: <20030918180158.6eb08930.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.c:.HB,9VGY3gP?" X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60-rc4 X-Spam-Checker-Version: SpamAssassin 2.60-rc4 (1.203-2003-08-29-exp) on mailgw.local.ipunplugged.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] MIP4 Issue Tracker 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: , --=.c:.HB,9VGY3gP? Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I have set up and issue tracker for MIP4 at: http://ietf.levkowetz.com/ietf/issues/tracker/mip4/ It is ment as a service to document editors, to help keep track of draft issues. Currently any list member may add himself as a user, and enter issues or comment on issues. Today only the web interface is active. I expect to have an email interface active within a few days, though, and I also expect to tie it into the mailing list within two weeks, so issue discussions on the mailing list will automatically be added to the issue tracker. Please let me know what you think. Henrik -- Buy Land Now. It's Not Being Made Any More. --=.c:.HB,9VGY3gP? Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD4DBQE/adb3eVhrtTJkXCMRAvyeAJ9A4scLzufTWrIncKAkhr3NuGS1kgCXdRET DWR2e+Mh9NHktizYE6nxog== =NaVU -----END PGP SIGNATURE----- --=.c:.HB,9VGY3gP?-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 19 22:02:59 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01441 for ; Fri, 19 Sep 2003 21:37:20 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhD7020140 for ; Fri, 19 Sep 2003 21:37:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h88E0rJs010320 for mip4-archive@odin.ietf.org; Mon, 8 Sep 2003 10:00:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wMZQ-0002dG-6J for mip4-web-archive@optimus.ietf.org; Mon, 08 Sep 2003 10:00:44 -0400 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 KAA20625 for ; Mon, 8 Sep 2003 10:00:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wMYr-0002RW-7k; Mon, 08 Sep 2003 10:00:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wJ2y-0003vB-5z for mip4@optimus.ietf.org; Mon, 08 Sep 2003 06:15:00 -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 GAA07769 for ; Mon, 8 Sep 2003 06:14:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19wJ2u-0001Fz-00 for mip4@ietf.org; Mon, 08 Sep 2003 06:14:56 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19wJ2t-0001Fn-00 for mip4@ietf.org; Mon, 08 Sep 2003 06:14:55 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h88AEtK14564 for ; Mon, 8 Sep 2003 12:14:55 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F5C570D.9040901@comnets.uni-bremen.de> Date: Mon, 08 Sep 2003 12:16:45 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IP v4 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] introducing 'S' bit in Binding Updates 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 all, I have been looking into (draft-ietf-mobileip-optim-10.txt) which is the latest version of the draft that I am aware of and have not been able to find I way to support multiple simultaneous binding with route optimisation. Would it be possible to introduce the 'S' bit in binding updates? Regards niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 19 22:04:48 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01623 for ; Fri, 19 Sep 2003 21:37:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhDl020140 for ; Fri, 19 Sep 2003 21:37:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7QIrjP6014269 for mip4-archive@odin.ietf.org; Tue, 26 Aug 2003 14:53:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19riwo-0003ea-JY for mip4-web-archive@optimus.ietf.org; Tue, 26 Aug 2003 14:53:43 -0400 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 OAA21200 for ; Tue, 26 Aug 2003 14:53:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19riwG-0003ZW-12; Tue, 26 Aug 2003 14:53:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rcMl-0001Ce-Bh for mip4@optimus.ietf.org; Tue, 26 Aug 2003 07:52: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 HAA00259 for ; Tue, 26 Aug 2003 07:51:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rcMk-0007ju-00 for mip4@ietf.org; Tue, 26 Aug 2003 07:52:02 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 19rcMj-0007jE-00 for mip4@ietf.org; Tue, 26 Aug 2003 07:52:01 -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 h7QBpNwf019980; Tue, 26 Aug 2003 13:51:24 +0200 Date: Tue, 26 Aug 2003 13:51:21 +0200 From: Henrik Levkowetz To: mip4@ietf.org Cc: "Adrangi, Farid" , Sami Vaarala Message-Id: <20030826135121.3d2f4535.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-debian-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 version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Content-Transfer-Encoding: 7bit Subject: [Mip4] WG last call follow-up for vpn traversal problem statement 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 During the WG last call period for draft-ietf-mobileip-vpn-problem-statement-req-03 I received one comment, essentially saying that the choice of the words 'in parallel' in section 2.2 was less than optimal. Accordingly, I'd like to get your comments on the following change (in the section title and first paragraph): FROM: 2.2 VPN Gateway and MIPv4 HA(s) in parallel A MIPv4 HA is deployed in parallel with the VPN gateway, and it is directly reachable by MNs inside or outside the Intranet. ..Foreign Network.. .....VPN Domain..(Intranet)..... . . . . . +----+ +----+ . +----+ +-------+ . . |MNs | | FA | . | VPN| | Router| . . |away| | | .<=========>| | | 1..n | . . +----+ +----+ . | GW | +-------+ . . . +----+ . . . +----+ +-------+ +-------+ . . .<=========>| HA | | CN | | MNs | . ................... | | | 1..n | | home | . +----+ +-------+ +-------+ . . . ................................ Figure 2 TO: 2.2 VPN Gateway and MIPv4 HA(s) on the VPN domain border A MIPv4 HA is deployed on the VPN domain border (e.g. in the DMZ) together with the VPN gateway, and it is directly reachable by MNs inside or outside the Intranet. ..Foreign Network.. .....VPN Domain..(Intranet)..... . . . . . +----+ +----+ . +----+ +-------+ . . |MNs | | FA | . | VPN| | Router| . . |away| | | .<=========>| | | 1..n | . . +----+ +----+ . | GW | +-------+ . . . +----+ . . . +----+ +-------+ +-------+ . . .<=========>| HA | | CN | | MNs | . ................... | | | 1..n | | home | . +----+ +-------+ +-------+ . . . ................................ Figure 2 Comments? Henrik -- If at first you don't succeed, skydiving is not for you. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Sep 19 22:05:09 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01650 for ; Fri, 19 Sep 2003 21:37:42 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8K1VhEd020140 for ; Fri, 19 Sep 2003 21:37:21 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h850VanY025584 for mip4-archive@odin.ietf.org; Thu, 4 Sep 2003 20:31:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v4Vd-0006eX-A9 for mip4-web-archive@optimus.ietf.org; Thu, 04 Sep 2003 20:31: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 UAA05033 for ; Thu, 4 Sep 2003 20:31:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v4Vb-0001jI-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 20:31:27 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19v4Va-0001jF-00 for mip4-web-archive@ietf.org; Thu, 04 Sep 2003 20:31:26 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v4VO-0006cu-4s; Thu, 04 Sep 2003 20:31:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19v4Un-0006bx-DV for mip4@optimus.ietf.org; Thu, 04 Sep 2003 20:30:37 -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 UAA04971 for ; Thu, 4 Sep 2003 20:30:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19v4Ul-0001fd-00 for mip4@ietf.org; Thu, 04 Sep 2003 20:30:35 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19v4Uk-0001ey-00 for mip4@ietf.org; Thu, 04 Sep 2003 20:30:34 -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 h850TwC06041; Thu, 4 Sep 2003 19:29:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Sep 2003 19:29:58 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Thu, 4 Sep 2003 19:29:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37344.D5B8FB8A" 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_01C37344.D5B8FB8A Content-Type: text/plain Hi, Pete, Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Thursday, September 04, 2003 6:04 PM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: 'Pete McCann'; Bharatia, Jayshree [RICH1:2H13:EXCH]; > 'mip4@ietf.org' > Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > > Ahmad Muhanna writes: > > > > > -----Original Message----- > > > > > From: Pete McCann [mailto:mccap@lucent.com] > > > > > Sent: Wednesday, September 03, 2003 5:03 PM > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Cc: 'mip4@ietf.org' > > > > > Subject: RE: [Mip4] RFC3012bis: Proposal for > Issue2-Change5 > > > > > > > > > > > > > > > > > > > > After that, we could add, "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 we are trying to prevent such DOS attack by NOT > > > INVALIDATING the > challenge received in RRQ, why not > > > sending that challenge (still valid) back > in RRP. Is there > > > a problem with that? > > > > > > That behavior is allowed by the text above, assuming that the > > > challenge received in the RRQ is stored in the data > > > structures given in Appendix E. If not, then what you > > > describe would not be ok, because you would be forcing the FA > > > to use a challenge that it didn't necessarily generate. > > > > > > > Is there any scenario that we may be missing and FA may no > longer having a > valid unused challenges for a certain MN? > > Ah, very good question. I think we had some text to cover > this case in one of the proposals, but I subsequently deleted it. > > How about: > > 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. > > -Pete > Let me try to understand what we are trying to propose here: If RRQ generates MN-AAA authentication, FA MUST not invalidate previously unused challenges 1. FA SHOULD include a previously unused challenge in RRP, if present; or 2. FA SHOULD generate a new challenge., or 3. FA does not send any of the above SHOULD's and send a new challenge always. Is not all of the above is already captured very nicely in section 2 of RFC3012bis: " The Challenge extension, illustrated in figure 1, is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate the latest challenge value that can be used by the mobile node to compute an authentication for its next registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. " I believe there is probably no need for all of these SHOULDs and let us leave it as generic as it should be with the responsibility of the FA as explained in the above paragraph. Your thoughts, please. > > ------_=_NextPart_001_01C37344.D5B8FB8A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi, Pete,

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Thursday, September 04, 2003 6:04 = PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: 'Pete McCann'; Bharatia, Jayshree = [RICH1:2H13:EXCH];
> 'mip4@ietf.org'
> Subject: RE: [Mip4] RFC3012bis: Proposal for = Issue2-Change5
>
>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > > Ahmad Muhanna writes:
>  > >  > > -----Original = Message-----
>  > >  > > From: Pete = McCann [mailto:mccap@lucent.com]
>  > >  > > Sent: = Wednesday, September 03, 2003 5:03 PM
>  > >  > > To: Bharatia, = Jayshree [RICH1:2H13:EXCH]
>  > >  > > Cc: = 'mip4@ietf.org'
>  > >  > > Subject: RE: = [Mip4] RFC3012bis: Proposal for
> Issue2-Change5  > >
>  > >  > >  > = >  > >
>  > >  > >  > = >  > > After that, we could add, "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 we are trying to = prevent such DOS attack by NOT
>  > > INVALIDATING the  > = challenge received in RRQ, why not
>  > > sending that challenge (still = valid) back  > in RRP. Is there
>  > > a problem with that?
>  > >
>  > > That behavior is allowed by the = text above, assuming that the
>  > > challenge received in the RRQ = is stored in the data
>  > > structures given in Appendix = E.  If not, then what you
>  > > describe would not be ok, = because you would be forcing the FA
>  > > to use a challenge that it = didn't necessarily generate.
>  > >
>  >
>  > Is there any scenario that we may be = missing and FA may no
> longer having a  > valid unused = challenges for a certain MN?
>
> Ah, very good question.  I think we had = some text to cover
> this case in one of the proposals, but I = subsequently deleted it.
>
> How about:
>
>   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.
>
> -Pete
>

Let me try to understand what we are trying to = propose here:
If RRQ generates MN-AAA authentication, FA MUST not = invalidate previously unused challenges
1. FA SHOULD include a previously unused challenge = in RRP, if present; or
2. FA SHOULD generate a new challenge., or
3. FA does not send any of the above SHOULD's and = send a new challenge always.

Is not all of the above is already captured very = nicely in section 2 of RFC3012bis:
"
   The Challenge extension, illustrated in = figure 1, is inserted in the
   Agent Advertisements by the Foreign = Agent, in order to communicate
   the latest challenge value that can be = used by the mobile node
   to compute an authentication for its = next registration request
   message.  The challenge is = selected by the foreign agent to provide
   local assurance that the mobile node is = not replaying any earlier
   registration request.
"

I believe there is probably no need for all of these = SHOULDs and let us leave it as generic as it should be with the = responsibility of the FA as explained in the above = paragraph.

Your thoughts, please.

>
>

------_=_NextPart_001_01C37344.D5B8FB8A-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Sep 20 09:53:51 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 JAA04363 for ; Sat, 20 Sep 2003 09:53:50 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OmM-0002Vq-3C for mip4-archive@odin.ietf.org; Fri, 19 Sep 2003 13:10:46 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JHAk19009652 for mip4-archive@odin.ietf.org; Fri, 19 Sep 2003 13:10:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OmB-0002TV-UF for mip4-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 13:10: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 NAA15125 for ; Fri, 19 Sep 2003 13:10:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0Om9-0006T5-00 for mip4-web-archive@ietf.org; Fri, 19 Sep 2003 13:10:33 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0Om4-0006Rc-00 for mip4-web-archive@ietf.org; Fri, 19 Sep 2003 13:10:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ORK-0000Nz-5W; Fri, 19 Sep 2003 12:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NnN-0001xh-Jo for mip4@optimus.ietf.org; Fri, 19 Sep 2003 12:07:55 -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 MAA07935 for ; Fri, 19 Sep 2003 12:07:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A06Og-0003ly-00 for mip4@ietf.org; Thu, 18 Sep 2003 17:33:06 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A06CQ-0002Sl-00 for mip4@ietf.org; Thu, 18 Sep 2003 17:20:27 -0400 Received: (qmail 27439 invoked from network); 18 Sep 2003 21:20:24 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 18 Sep 2003 21:20:24 -0000 Date: Thu, 18 Sep 2003 23:20:23 +0200 From: Henrik Levkowetz To: William D Ivancic Cc: mip4@ietf.org Subject: Re: [Mip4] Secure Mobile Networking Deployment Message-Id: <20030918232023.1785289a.henrik@levkowetz.com> In-Reply-To: <5.1.1.5.2.20030918081421.01822670@popserve.grc.nasa.gov> References: <5.1.0.14.2.20030911083507.03b53850@po2.bbn.com> <5.1.1.5.2.20030918081421.01822670@popserve.grc.nasa.gov> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.'HXqtZEYFi6eO2" 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: , --=.'HXqtZEYFi6eO2 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello William, Thursday 18 September 2003, William wrote: > There appears to be a lot of NAT / PAT and administrative > filtering issues that we are trying to resolve. Hopefully, what we learn > with IPv4 can be applied to IPv6. We will pass whatever useful information > we can on to these groups. As I've co-authored the RFC on NAT traversal for MIP, I'd be very intreresting in hearing about your experiences in this area in particular. Have you implemented RFC 3519 NAT traversal mechanisms, or are you trying to work around this in some other manner? Regards, Henrik --=.'HXqtZEYFi6eO2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/aiGYeVhrtTJkXCMRAl8RAKCzHy5fCX2m6tAuDt/45XorA1J7lgCfU5IN VyB4Mm8m8pa8AN97B0sTfdM= =TMFa -----END PGP SIGNATURE----- --=.'HXqtZEYFi6eO2-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Sep 20 09:55:07 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 JAA05141 for ; Sat, 20 Sep 2003 09:55:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NgL-0007ck-AK for mip4-archive@odin.ietf.org; Fri, 19 Sep 2003 12:00:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8JG0Tvr029297 for mip4-archive@odin.ietf.org; Fri, 19 Sep 2003 12:00:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NgL-0007cP-4o for mip4-web-archive@optimus.ietf.org; Fri, 19 Sep 2003 12:00: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 MAA03034 for ; Fri, 19 Sep 2003 12:00:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0NgG-0002Rc-00 for mip4-web-archive@ietf.org; Fri, 19 Sep 2003 12:00:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A0NgA-0002Ow-00 for mip4-web-archive@ietf.org; Fri, 19 Sep 2003 12:00:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ng0-0007U9-JD; Fri, 19 Sep 2003 12:00:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nf1-0007Eu-Am for mip4@optimus.ietf.org; Fri, 19 Sep 2003 11: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 LAA01979 for ; Fri, 19 Sep 2003 11:58:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0N5C-0006pR-00 for mip4@ietf.org; Fri, 19 Sep 2003 11:22:06 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 1A0N4r-0006N2-00 for mip4@ietf.org; Fri, 19 Sep 2003 11:21:45 -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 h8JFKXlG001288; Fri, 19 Sep 2003 17:20:33 +0200 Date: Fri, 19 Sep 2003 17:20:33 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20030919172033.2c5fa85d.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.8.11claws141 (GTK+ 1.2.10; i386-debian-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.jTA1da?tGia,VM" X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60-rc4 X-Spam-Checker-Version: SpamAssassin 2.60-rc4 (1.203-2003-08-29-exp) on mailgw.local.ipunplugged.com X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) Subject: [Mip4] Mip4 workgroup status page 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: , --=.jTA1da?tGia,VM Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I've put together a page where I try to maintain the current status of different drafts relevant to the mip4 workgroup. It's at: http://www.levkowetz.com/ietf/wg/mip4/ Feel free to visit it and comment on usefulness, corrections, missing information and whatnot. Henrik -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth --=.jTA1da?tGia,VM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ax7BeVhrtTJkXCMRAgmEAKC9/knifpCtxZ9DXkjXiQ6lZlkCAQCgs3Jf KFdAJkMODVrjN6lrYhg//qY= =TAWo -----END PGP SIGNATURE----- --=.jTA1da?tGia,VM-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 22 15:07:54 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 PAA01574 for ; Mon, 22 Sep 2003 15:07:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1W21-0000Zb-Mv for mip4-archive@odin.ietf.org; Mon, 22 Sep 2003 15:07:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8MJ7XiU002194 for mip4-archive@odin.ietf.org; Mon, 22 Sep 2003 15:07:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1W21-0000ZJ-EV for mip4-web-archive@optimus.ietf.org; Mon, 22 Sep 2003 15:07:33 -0400 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 PAA01500 for ; Mon, 22 Sep 2003 15:07: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 1A1W1V-0000Oh-5F; Mon, 22 Sep 2003 15:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1VhJ-0006Fz-Bi for mip4@optimus.ietf.org; Mon, 22 Sep 2003 14:46:09 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29925; Mon, 22 Sep 2003 14:45:59 -0400 (EDT) Message-Id: <200309221845.OAA29925@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 22 Sep 2003 14:45:59 -0400 Subject: [Mip4] I-D ACTION: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: , --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 : Mobile IPv4 Extension for AAA Network Access Identifiers Author(s) : F. Johansson, T. Johansson Filename : draft-ietf-mip4-aaa-nai-00.txt Pages : 10 Date : 2003-9-22 When a mobile node moves between two foreign networks it has to be reauthenticated. If the home network has multiple Authentication Authorization and Accounting (AAA) servers the reauthentication request may not be received by the same Home AAA server as previous authentication requests. In order for the new Home AAA server to be able to forward the request to the correct Home Agent it has to know the identity of the Home Agent. This document defines a Mobile IP extension that enables the HA to pass its identity to the mobile node which can then pass it on to the new AAA server when changing point of attachment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-aaa-nai-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-aaa-nai-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-aaa-nai-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-9-22143644.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-aaa-nai-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-aaa-nai-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-22143644.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 23 05:31: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 FAA02129 for ; Tue, 23 Sep 2003 05:31: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 1A1jVf-0006d8-TW for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 05:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N9V3QC025480 for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 05:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jVf-0006ct-ON for mip4-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 05:31: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 FAA02113 for ; Tue, 23 Sep 2003 05:30:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jVc-0001Sk-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 05:31:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1jVc-0001Sf-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 05:31:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jVe-0006cN-Cd; Tue, 23 Sep 2003 05:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jUn-0006Wu-DH for mip4@optimus.ietf.org; Tue, 23 Sep 2003 05:30: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 FAA02079 for ; Tue, 23 Sep 2003 05:30:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jUk-0001Nb-00 for mip4@ietf.org; Tue, 23 Sep 2003 05:30:06 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1A1jUj-0001N8-00 for mip4@ietf.org; Tue, 23 Sep 2003 05:30:05 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h8N9U3O18360 for ; Tue, 23 Sep 2003 11:30:03 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F7012A8.7070805@comnets.uni-bremen.de> Date: Tue, 23 Sep 2003 11:30:16 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Firewall traveral problem 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 all, we are testing the performance of MIP and NOMAD with UMTS. Using PPP our mobile node is allocated a globally routable IP address from the UMTS IP subnet. In turn the MN registers the CCOA issuing a RegReq with source IP address that of the MN. However, a Firewall at the UMTS IP subnet will not let any packets out unless the source address belongs withing its administered subnet. This was resolved with the help of a reverse IPIP tunnel. However, the Firewall will also not let any packets in, unless the mobile node has first initiated the flow. For this, the reverse IPIP tunnel was replaced with an IP+UDP tunnel which was constructed with the help of the OpenVPN software (http://openvpn.sourceforge.net/). We have been coming across several problems with OpenVPN and would like to know whether anyone has any implementation experience that might be willing to share with us. Best Regards niko _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 23 05:39: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 FAA02364 for ; Tue, 23 Sep 2003 05:39: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 1A1jdO-0007i7-Rs for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 05:39:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N9d2TD029627 for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 05:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jdO-0007h9-Kt for mip4-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 05:39: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 FAA02354 for ; Tue, 23 Sep 2003 05:38:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jdL-0002Bl-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 05:38:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1jdK-0002Bh-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 05:38:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jdN-0007gk-JI; Tue, 23 Sep 2003 05: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 1A1jcv-0007dw-EN for mip4@optimus.ietf.org; Tue, 23 Sep 2003 05:38:33 -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 FAA02326 for ; Tue, 23 Sep 2003 05:38:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jcs-00028h-00 for mip4@ietf.org; Tue, 23 Sep 2003 05:38:30 -0400 Received: from smtp1.rslcom.fi ([213.173.131.3]) by ietf-mx with esmtp (Exim 4.12) id 1A1jcq-00027Z-00 for mip4@ietf.org; Tue, 23 Sep 2003 05:38:29 -0400 Received: from populo.vip.fi (populo.vip.fi [213.173.130.25]) by smtp1.rslcom.fi (8.12.8/8.12.8) with ESMTP id h8N9cBV2024030; Tue, 23 Sep 2003 12:38:12 +0300 Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by populo.vip.fi (8.8.8p1/8.8.5) with ESMTP id MAA31575; Tue, 23 Sep 2003 12:38:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Firewall traveral problem Date: Tue, 23 Sep 2003 12:38:06 +0300 Message-ID: Thread-Topic: [Mip4] Firewall traveral problem Thread-Index: AcOBtWtvUye6pfrASkaxJ3Dlo2a5zAARtfvg From: "Sami Vaarala" To: "Niko A. Fikouras" , Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi Niko, > we are testing the performance of MIP and NOMAD with UMTS. Using PPP our > mobile node is allocated a globally routable IP address from the UMTS IP > subnet. In turn the MN registers the CCOA issuing a RegReq with source > IP address that of the MN. However, a Firewall at the UMTS IP subnet > will not let any packets out unless the source address belongs withing > its administered subnet. This was resolved with the help of a reverse > IPIP tunnel. However, the Firewall will also not let any packets in, > unless the mobile node has first initiated the flow. For this, the > reverse IPIP tunnel was replaced with an IP+UDP tunnel which was > constructed with the help of the OpenVPN software > (http://openvpn.sourceforge.net/). We have been coming across several > problems with OpenVPN and would like to know whether anyone has any > implementation experience that might be willing to share with us. I'm not sure if this is a realistic alternative for you, but your scenario can also be solved using the MIP NAT traversal specification (RFC 3519). It allows a MN to force UDP encapsulation even when no NAT devices are detected (the 'F'-bit in the RRQ extension is used for this and was originally added for precisely this purpose). When the MN uses the F-bit, the flow is MN initiated, and uses the RRQ/RRP UDP ports for the data traffic flow that follows registration. Hope this helps, -Sami >=20 > Best Regards > niko >=20 >=20 > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 23 05:57: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 FAA02786 for ; Tue, 23 Sep 2003 05:57: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 1A1juo-0001QG-KZ for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 05:57:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8N9v2Pu005468 for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 05:57:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1juo-0001Q7-F8 for mip4-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 05:57: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 FAA02762 for ; Tue, 23 Sep 2003 05:56:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jul-0003oA-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 05:56:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1juk-0003o6-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 05:56:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jun-0001Pb-CK; Tue, 23 Sep 2003 05: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 1A1jug-0001Og-NU for mip4@optimus.ietf.org; Tue, 23 Sep 2003 05:56:57 -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 FAA02753 for ; Tue, 23 Sep 2003 05:56:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jud-0003n9-00 for mip4@ietf.org; Tue, 23 Sep 2003 05:56:51 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 1A1juc-0003my-00 for mip4@ietf.org; Tue, 23 Sep 2003 05:56:50 -0400 Received: from comnets.uni-bremen.de (sheepdog.comnets.uni-bremen.de [134.102.155.160]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h8N9unO18609; Tue, 23 Sep 2003 11:56:49 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host sheepdog.comnets.uni-bremen.de [134.102.155.160] claimed to be comnets.uni-bremen.de Message-ID: <3F7018F2.9050002@comnets.uni-bremen.de> Date: Tue, 23 Sep 2003 11:57:06 +0200 From: "Niko A. Fikouras" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] Firewall traveral problem References: <3F7012A8.7070805@comnets.uni-bremen.de> <20030923054859.57d0349d.henrik@levkowetz.com> In-Reply-To: <20030923054859.57d0349d.henrik@levkowetz.com> Content-Type: multipart/alternative; boundary="------------010102010308000508040504" 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 is a multi-part message in MIME format. --------------010102010308000508040504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, first of all thanks for the prompt reply. Maybe I was not clear enough in my first mail. I silently assumed that the MN's IP address is its home IP address. As a MIP MN is only allowed to issue packets with its home IP address, hence the RegReq will indicate the home IP address as the source IP address. Eventually, this packet will get dropped by the firewall. Is there to your knowledge any implementation of rfc3519 for Linux? thanx niko Henrik Levkowetz wrote: >Tuesday 23 September 2003, Niko wrote: > > >>we are testing the performance of MIP and NOMAD with UMTS. Using PPP our >>mobile node is allocated a globally routable IP address from the UMTS IP >>subnet. In turn the MN registers the CCOA issuing a RegReq with source >>IP address that of the MN. However, a Firewall at the UMTS IP subnet >>will not let any packets out unless the source address belongs withing >>its administered subnet. This was resolved with the help of a reverse >>IPIP tunnel. However, the Firewall will also not let any packets in, >>unless the mobile node has first initiated the flow. For this, the >>reverse IPIP tunnel was replaced with an IP+UDP tunnel which was >>constructed with the help of the OpenVPN software >>(http://openvpn.sourceforge.net/). We have been coming across several >>problems with OpenVPN and would like to know whether anyone has any >>implementation experience that might be willing to share with us. >> >> > >I assume (since this is the MIP4 list) that we're talking MIPv4. Have >you considered implementing MIP NAT traversal ? It sounds as if your >scenario is a very close match to what NAT traversal was designed to >do. > >Just to check the premises here though, I wonder if you could clarify >which address you're referring to when you say 'In turn the MN registers >the CCOA issuing a RegReq with source IP address that of the MN' above - >is this really the IP address assigned by the UMTS IP subnet? And in that >case, how come the assigned IP address is not topologically correct? >This seems a bit strange to me. > > Henrik > > --------------010102010308000508040504 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi,

first of all thanks for the prompt reply.

Maybe I was not clear enough in my first mail. I silently assumed that the MN's IP address is its home IP address. As a MIP MN is only allowed to issue packets with its home IP address, hence the RegReq will indicate the home IP address as the source IP address. Eventually, this packet will get dropped by the firewall.

Is there to your knowledge any implementation of rfc3519 for Linux?

thanx
niko

Henrik Levkowetz wrote:
Tuesday 23 September 2003, Niko wrote:
  
we are testing the performance of MIP and NOMAD with UMTS. Using PPP our 
mobile node is allocated a globally routable IP address from the UMTS IP 
subnet. In turn the MN registers the CCOA issuing a RegReq with source 
IP address that of the MN. However, a Firewall at the UMTS IP subnet 
will not let any packets out unless the source address belongs withing 
its administered subnet. This was resolved with the help of a reverse 
IPIP tunnel. However, the Firewall will also not let any packets in, 
unless the mobile node has first initiated the flow. For this, the 
reverse IPIP tunnel was replaced with an IP+UDP tunnel which was 
constructed with the help of the OpenVPN software 
(http://openvpn.sourceforge.net/). We have been coming across several 
problems with OpenVPN and would like to know whether anyone has any 
implementation experience that might be willing to share with us.
    

I assume (since this is the MIP4 list) that we're talking MIPv4. Have
you considered implementing MIP NAT traversal ? It sounds as if your
scenario is a very close match to what NAT traversal was designed to
do. 

Just to check the premises here though, I wonder if you could clarify
which address you're referring to when you say 'In turn the MN registers
the CCOA issuing a RegReq with source IP address that of the MN' above -
is this really the IP address assigned by the UMTS IP subnet? And in that
case, how come the assigned IP address is not topologically correct?
This seems a bit strange to me.

	Henrik
--------------010102010308000508040504-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 23 06:02: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 GAA02943 for ; Tue, 23 Sep 2003 06:02: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 1A1jze-0001vf-Fe for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 06:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NA22RF007409 for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 06:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jze-0001vQ-BV for mip4-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 06:02: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 GAA02927 for ; Tue, 23 Sep 2003 06:01:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jza-0004GR-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 06:01:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1jza-0004GN-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 06:01:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jzd-0001v3-Fn; Tue, 23 Sep 2003 06:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1jyr-0001qE-Gi for mip4@optimus.ietf.org; Tue, 23 Sep 2003 06:01: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 GAA02909 for ; Tue, 23 Sep 2003 06:01:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1jyn-0004Bt-00 for mip4@ietf.org; Tue, 23 Sep 2003 06:01:10 -0400 Received: from mta6.algx.net ([67.92.168.235] helo=chimta05.algx.net) by ietf-mx with esmtp (Exim 4.12) id 1A1jyn-00049E-00 for mip4@ietf.org; Tue, 23 Sep 2003 06:01:09 -0400 Received: from riesling.local.levkowetz.com ([66.107.48.117]) by chimmx05.algx.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HLN00H5CVSH47@chimmx05.algx.net> for mip4@ietf.org; Tue, 23 Sep 2003 05:00:18 -0500 (CDT) Received: (qmail 9668 invoked from network); Tue, 23 Sep 2003 10:00:12 +0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; Tue, 23 Sep 2003 10:00:12 +0000 Date: Tue, 23 Sep 2003 06:00:11 -0400 From: Henrik Levkowetz Subject: Re: [Mip4] Firewall traveral problem In-reply-to: To: Sami Vaarala Cc: "Niko A. Fikouras" , mip4@ietf.org Message-id: <20030923060011.15c71104.henrik@levkowetz.com> MIME-version: 1.0 X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Content-type: multipart/signed; boundary="=.LCIgtyH3uZcSso"; micalg=pgp-sha1; protocol="application/pgp-signature" References: 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: , --=.LCIgtyH3uZcSso Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Sami, Tuesday 23 September 2003, Sami wrote: > Hi Niko, > [snip] > I'm not sure if this is a realistic alternative for > you, but your scenario can also be solved using the > MIP NAT traversal specification (RFC 3519). It allows > a MN to force UDP encapsulation even when no NAT devices > are detected (the 'F'-bit in the RRQ extension is > used for this and was originally added for precisely > this purpose). > > When the MN uses the F-bit, the flow is MN initiated, > and uses the RRQ/RRP UDP ports for the data traffic > flow that follows registration. I see we're on the same page here. Your response dropped into my inbox while I was writing mine .. :-) Regards, Henrik --=.LCIgtyH3uZcSso Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/cBmreVhrtTJkXCMRAnwvAJ9pa9891RBMAtSFlsbcIwaufvBYngCfVgfn Yt1qSllEiZIUB5UBedilGvk= =XWNK -----END PGP SIGNATURE----- --=.LCIgtyH3uZcSso-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 23 06:10:55 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 GAA04120 for ; Tue, 23 Sep 2003 06:10:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k7u-0003vr-2o for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 06:10:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NAAYOt015108 for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 06:10:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k7t-0003vV-S5 for mip4-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 06:10:33 -0400 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 GAA04070 for ; Tue, 23 Sep 2003 06:10: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 1A1k7P-0003lW-93; Tue, 23 Sep 2003 06:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1k7B-0003is-Hn for mip4@optimus.ietf.org; Tue, 23 Sep 2003 06:09: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 GAA04027 for ; Tue, 23 Sep 2003 06:09:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1k77-000558-00 for mip4@ietf.org; Tue, 23 Sep 2003 06:09:46 -0400 Received: from mta5.algx.net ([67.92.168.234] helo=chimta04.algx.net) by ietf-mx with esmtp (Exim 4.12) id 1A1k77-000523-00 for mip4@ietf.org; Tue, 23 Sep 2003 06:09:45 -0400 Received: from riesling.local.levkowetz.com ([66.107.48.117]) by chimmx04.algx.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HLN009JCW7GQZ@chimmx04.algx.net> for mip4@ietf.org; Tue, 23 Sep 2003 05:09:16 -0500 (CDT) Received: (qmail 9573 invoked from network); Tue, 23 Sep 2003 09:49:10 +0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; Tue, 23 Sep 2003 09:49:10 +0000 Date: Tue, 23 Sep 2003 05:48:59 -0400 From: Henrik Levkowetz Subject: Re: [Mip4] Firewall traveral problem In-reply-to: <3F7012A8.7070805@comnets.uni-bremen.de> To: "Niko A. Fikouras" Cc: mip4@ietf.org Message-id: <20030923054859.57d0349d.henrik@levkowetz.com> MIME-version: 1.0 X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Content-type: multipart/signed; boundary="=.vQOLQIXaDBj)xU"; micalg=pgp-sha1; protocol="application/pgp-signature" References: <3F7012A8.7070805@comnets.uni-bremen.de> 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: , --=.vQOLQIXaDBj)xU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Tuesday 23 September 2003, Niko wrote: > we are testing the performance of MIP and NOMAD with UMTS. Using PPP our > mobile node is allocated a globally routable IP address from the UMTS IP > subnet. In turn the MN registers the CCOA issuing a RegReq with source > IP address that of the MN. However, a Firewall at the UMTS IP subnet > will not let any packets out unless the source address belongs withing > its administered subnet. This was resolved with the help of a reverse > IPIP tunnel. However, the Firewall will also not let any packets in, > unless the mobile node has first initiated the flow. For this, the > reverse IPIP tunnel was replaced with an IP+UDP tunnel which was > constructed with the help of the OpenVPN software > (http://openvpn.sourceforge.net/). We have been coming across several > problems with OpenVPN and would like to know whether anyone has any > implementation experience that might be willing to share with us. I assume (since this is the MIP4 list) that we're talking MIPv4. Have you considered implementing MIP NAT traversal ? It sounds as if your scenario is a very close match to what NAT traversal was designed to do. Just to check the premises here though, I wonder if you could clarify which address you're referring to when you say 'In turn the MN registers the CCOA issuing a RegReq with source IP address that of the MN' above - is this really the IP address assigned by the UMTS IP subnet? And in that case, how come the assigned IP address is not topologically correct? This seems a bit strange to me. Henrik --=.vQOLQIXaDBj)xU Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/cBcVeVhrtTJkXCMRAnYmAJ49OV1nTEaRRttKSib3FGRe5yq2DQCdHFrT KTGfPnpVYdM5CZ1VafR5nRQ= =P2TM -----END PGP SIGNATURE----- --=.vQOLQIXaDBj)xU-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 23 06:14:53 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 GAA04501 for ; Tue, 23 Sep 2003 06:14:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kBk-0004hZ-5e for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 06:14:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8NAEWQw018066 for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 06:14:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kBj-0004hG-Vz for mip4-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 06:14:32 -0400 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 GAA04460 for ; Tue, 23 Sep 2003 06:14: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 1A1kBF-0004Vj-GY; Tue, 23 Sep 2003 06:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kAP-0004OE-9U for mip4@optimus.ietf.org; Tue, 23 Sep 2003 06:13: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 GAA04362 for ; Tue, 23 Sep 2003 06:13:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1kAL-0005RB-00 for mip4@ietf.org; Tue, 23 Sep 2003 06:13:05 -0400 Received: from mta5.algx.net ([67.92.168.234] helo=chimta04.algx.net) by ietf-mx with esmtp (Exim 4.12) id 1A1kAL-0005NR-00 for mip4@ietf.org; Tue, 23 Sep 2003 06:13:05 -0400 Received: from riesling.local.levkowetz.com ([66.107.48.117]) by chimmx04.algx.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HLN00FFTWD05P@chimmx04.algx.net> for mip4@ietf.org; Tue, 23 Sep 2003 05:12:36 -0500 (CDT) Received: (qmail 9787 invoked from network); Tue, 23 Sep 2003 10:12:30 +0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; Tue, 23 Sep 2003 10:12:30 +0000 Date: Tue, 23 Sep 2003 06:12:30 -0400 From: Henrik Levkowetz Subject: Re: [Mip4] Firewall traveral problem In-reply-to: <3F7018F2.9050002@comnets.uni-bremen.de> To: "Niko A. Fikouras" Cc: mip4@ietf.org Message-id: <20030923061230.4675699d.henrik@levkowetz.com> MIME-version: 1.0 X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Content-type: multipart/signed; boundary="=.p9Mu9S4(2y',v?"; micalg=pgp-sha1; protocol="application/pgp-signature" References: <3F7012A8.7070805@comnets.uni-bremen.de> <20030923054859.57d0349d.henrik@levkowetz.com> <3F7018F2.9050002@comnets.uni-bremen.de> 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: , --=.p9Mu9S4(2y',v? Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Tuesday 23 September 2003, Niko wrote: > first of all thanks for the prompt reply. Glad to oblige. > Maybe I was not clear enough in my first mail. I silently assumed that > the MN's IP address is its home IP address. As a MIP MN is only allowed > to issue packets with its home IP address, hence the RegReq will > indicate the home IP address as the source IP address. Eventually, this > packet will get dropped by the firewall. Mmm, this doesn't sound right to me. Registration requests must be sent by the mobile node with the source ip address set to the locally aquired temporary ip address - how can it hope to get a response routed back to it otherwise? > Is there to your knowledge any implementation of rfc3519 for Linux? I believe that Jim Binkley at Portland State University has had a student doing an rfc 3519 implementation on Linux, but I'm not totally sure about the platform and the state of the code. You might want to drop him a line. Regards, Henrik > > Henrik Levkowetz wrote: > > >Tuesday 23 September 2003, Niko wrote: > > > > > >>we are testing the performance of MIP and NOMAD with UMTS. Using PPP our > >>mobile node is allocated a globally routable IP address from the UMTS IP > >>subnet. In turn the MN registers the CCOA issuing a RegReq with source > >>IP address that of the MN. However, a Firewall at the UMTS IP subnet > >>will not let any packets out unless the source address belongs withing > >>its administered subnet. This was resolved with the help of a reverse > >>IPIP tunnel. However, the Firewall will also not let any packets in, > >>unless the mobile node has first initiated the flow. For this, the > >>reverse IPIP tunnel was replaced with an IP+UDP tunnel which was > >>constructed with the help of the OpenVPN software > >>(http://openvpn.sourceforge.net/). We have been coming across several > >>problems with OpenVPN and would like to know whether anyone has any > >>implementation experience that might be willing to share with us. > >> > >> > > > >I assume (since this is the MIP4 list) that we're talking MIPv4. Have > >you considered implementing MIP NAT traversal ? It sounds as if your > >scenario is a very close match to what NAT traversal was designed to > >do. > > > >Just to check the premises here though, I wonder if you could clarify > >which address you're referring to when you say 'In turn the MN registers > >the CCOA issuing a RegReq with source IP address that of the MN' above - > >is this really the IP address assigned by the UMTS IP subnet? And in that > >case, how come the assigned IP address is not topologically correct? > >This seems a bit strange to me. > > > > Henrik > > > > > --=.p9Mu9S4(2y',v? Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/cByOeVhrtTJkXCMRAm0gAKDNiXxVXRXna1eCj+0AxNPSS5RzWgCgjkrA 8ZuRTZ59/5iM+UgM9oCUkds= =TJ9N -----END PGP SIGNATURE----- --=.p9Mu9S4(2y',v?-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 23 21:04: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 VAA15656 for ; Tue, 23 Sep 2003 21:04: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 1A1y4Z-0001cy-68 for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 21:04:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O143Lc006252 for mip4-archive@odin.ietf.org; Tue, 23 Sep 2003 21:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1y4Y-0001cl-Vy for mip4-web-archive@optimus.ietf.org; Tue, 23 Sep 2003 21:04: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 VAA15648 for ; Tue, 23 Sep 2003 21:03:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1y4W-0001ff-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 21:04:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A1y4W-0001fc-00 for mip4-web-archive@ietf.org; Tue, 23 Sep 2003 21:04:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1y4W-0001cS-Vr; Tue, 23 Sep 2003 21:04:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1y4K-0001cC-5h for mip4@optimus.ietf.org; Tue, 23 Sep 2003 21:03:48 -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 VAA15645 for ; Tue, 23 Sep 2003 21:03:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1y4H-0001fU-00 for mip4@ietf.org; Tue, 23 Sep 2003 21:03:45 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A1y4G-0001fI-00 for mip4@ietf.org; Tue, 23 Sep 2003 21:03:44 -0400 Received: from gdommety-w2k01.cisco.com (dhcp-128-107-163-214.cisco.com [128.107.163.214]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8O11CYc001147; Tue, 23 Sep 2003 18:01:12 -0700 (PDT) Message-Id: <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Sep 2003 18:01:12 -0700 To: "Adrangi, Farid" , "Jayshree Bharatia" From: Gopal Dommety Cc: , , mip4@ietf.org In-Reply-To: <96D13222E704DC4D868F0009F0EE53E10AC321@orsmsx410.jf.intel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [Mip4] RE: Request for text proposal for your scenario 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: , Farid, The text Jayshree sent looks good. I just made minor edits. Here is the text below: 2.6 Combined VPN Gateway and MIPv4 FA MIPv4 FA and the VPN Gateway are running on the same physical machine. ..Foreign Network............VPN Domain..(Intranet)..... . . . . +----+ +-----+ +-------+ +-------+ . . |MNs | | FA | | Router| | HAs | . . |away|<============>| + | | 1..n | | | . . | | | VPN | +-------+ +-------+ . . | | | GW | . . +----+ +-----+ +-------+ +-------+ . . . | CN | | MNs | . . . | 1..n | | home | . . . +-------+ +-------+ . . . . ........................................................ In this scenario, the mipv4 tunnel is running inside the IPSec-ESP between the MN and the FA/VPN Gateway.This scenario IPsec being used to protect the data over the wireless network. For end-to-end security model, the VPN Gateway must protect the IP traffic originating at the MN. Since the point of attachment changes corresponding to the movement of the MN, it is essential that the VPN tunnel security association must be refreshed after each IP subnet handoff. Hence, this scenario is not practical where the mobility is involved for the real-time applications due to the performance implications. Thanks Gopal At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: >Any update on this? What should we do next? >--Farid > >-----Original Message----- >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] >Sent: Tuesday, September 16, 2003 11:02 AM >To: 'Gopal Dommety' >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid >Subject: RE: Request for text proposal for your scenario > >Gopal, > >Appreciate if you can make appropriate changes to the proposed text: > >Thanks, >Jayshree > >------------- >Proposed text: > >2.6 Combined VPN Gateway and MIPv4 FA > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > ..Foreign Network............VPN Domain..(Intranet)..... > . . . > . +----+ +-----+ +-------+ +-------+ . > . |MNs | | FA | | Router| | HAs | . > . |away|<============>| + | | 1..n | | | . > . | | | VPN | +-------+ +-------+ . > . | | | GW | . > . +----+ +-----+ +-------+ +-------+ . > . . | CN | | MNs | . > . . | 1..n | | home | . > . . +-------+ +-------+ . > . . . > ........................................................ > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP >between >the >MN and the FA/VPN Gateway. For end-to-end security model, the VPN >Gateway >must >protect the IP traffic originating at the MN. Since the point of >attachment >changes corresponding to the movement of the MN, it is essential that >the >VPN >tunnel security association must be refreshed after each IP subnet >handoff. >Hence, this scenario is not practical where the mobility is involved for >the >real-time applications due to the performance implications. > > > > -----Original Message----- > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Sent: Monday, September 15, 2003 4:39 PM > > To: 'Gopal Dommety'; Adrangi, Farid > > Cc: mccap@lucent.com; henrik@levkowetz.com > > Subject: RE: Request for text proposal for your scenario > > > > > > Gopal, > > > > I was in the impression that you will modify the text. > > Anyway, I won't able to do much today but let me try tomorrow > > and send you the text... > > > > Regards, > > Jayshree > > > > > -----Original Message----- > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > Sent: Monday, September 15, 2003 2:03 PM > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > Jayshree, > > > > > > Can you massage the text that you sent to fit what I was > > referring to. > > > > > > -Gopal > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > >Hi Gopal, > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > >Maybe the best thing is that you and Jayshree propose a text that > > > >*clearly* articulates the scenario and its problems. > > Would that be > > > >possible? Thanks a bunch. BR, > > > >Farid > > > > > > > >-----Original Message----- > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > >To: Adrangi, Farid; Jayshree Bharatia > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > >Farid, > > > > > > > >I am not suggesting a solution. I am confused by your > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > >I was talking about one hop away. the multiple hops is > > > interesting. The > > > >deployment scenarios of one hop and multiple hop solutions could be > > > >very > > > > > > > >different. > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > >between the MN and VPN/FA. > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > a FA. For > > > > >example, the following picture is not possible: > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > picture can > > > >be > > > > >simplified as follows > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > particular > > > > >established by different IPsec client software running on > > > the client > > > > >device!!! > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > >problem that we have is with SA refreshes when the MN > > changes its > > > > >point of attachment. Is my understanding correct? > > > > > > > > > >BR, > > > > >FArid > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > access to the > > > > >visiting domain. > > > > >VPN 2 is optional for remote access. > > > > > > > > > >Thanks > > > > >Gopal > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > >Hello Farid, > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > between the > > > >MN > > > > >and > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > >discussed > > > > >in > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > >unprotected > > > > > >between these two entities. > > > > > > > > > > > >Regards, > > > > > >Jayshree > > > > > > > -----Original Message----- > > > > > > > From: Adrangi, Farid > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > gdommety@cisco.com > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > From your description, it is my understanding that > > > there is only > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > the foreign > > > > > > > and the VPN GW in the VPN domain. In other words, No IPsec > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > and hence > > > > > > > data traffic between the MN and the FA is not > > > protected. Is my > > > > > > > understanding correct? I will have more questions/comments > > > > > > > based on your answers. Thanks for the text and > > > hopefully we can > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > >om > > > >] > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > To: Adrangi, Farid > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > gdommety@cisco.com > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > FA-VPN GW > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > Jayshree > > > > > > > --------------------- > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > same physical > > > > >machine. > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > >Domain..(Intranet).... > > > > > > > . . . > > > > >. > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > >+-------+ > > > > >. > > > > > > > . |MNs | | FA | . | VPN| | > > > Router| | HAs > > > >| > > > > >. > > > > > > > . |away| | + | .<=========>| GW | | 1..n | | > > > >| > > > > >. > > > > > > > . | | | VPN | . | | +-------+ > > > >+-------+ > > > > >. > > > > > > > . | | | GW | . | | > > > > >. > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > >+-------+ > > > > >. > > > > > > > . . . | CN > > > | | MNs > > > >| > > > > >. > > > > > > > .................... . | 1..n > > > | | home > > > >| > > > > >. > > > > > > > . +-------+ > > > >+-------+ > > > > >. > > > > > > > . > > > > >. > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > the FA is > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > is running > > > > > > > inside the IPSec-ESP. For end-to-end security model, the VPN > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > originating at the MN. Since the point of > > attachment changes > > > > > > > corresponding to the movement of the MN, it is > > essential that > > > > > > > the VPN tunnel security association must be refreshed > > > after each > > > > > > > IP subnet handoff. Hence, this scenario is not > > > practical where > > > > > > > the mobility is involved due to performance > > > implications for the > > > > > > > real-time applications. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > Could you please propose a text for the scenario > > > that you want > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > >om > > > >] > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > To: Adrangi, Farid > > > > > > > > Cc: mip4@ietf.org > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Jayshree > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: mip4@ietf.org > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > had a very > > > > > > > > brief conversation on this during IETF-57 - but I > > > am not sure > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > include this scenario. To be frank, I don't quite > > > understand > > > > > > > > the point behind adding this scenario because, > > > > > > > > - It seems to present a solution to a specific > > > > > > > > deployment model > > > > > > > > rather than a deployment scenario > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > elaborate what you mean by deployment model vs deployment > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > - I don't quite see the advantages of a combined > > > > > > > > VPN+FA if it > > > > > > > > does > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > perhaps you can elaborate on this? [JB] I think > > regardless > > > > > > > > this scenario has any advantages or not, it is one of the > > > > > > > > probable scenario which has potential issues (as you have > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > the problem > > > > > > > > statement > > > > > > > > draft represents combinations of MIPv4 HA and VPN gateway > > > > > > > > placement - adding this scenario is going to change > > > semantics > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > semantics change here. Do you think documenting > > this in new > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > - I just > > > > > > > > wanted to make sure that we clearly understand the > > > reasons for > > > > > > > > adding this scenario to the problem statement > > draft. Design > > > > > > > > team members and interested individuals are welcome > > > to express > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > >representative > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > >om > > > >] > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > To: Adrangi, Farid > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > understanding > > > > > > > > is that you will include the scenario of > > co-existed FA with > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > Statement draft. > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and it > > > > > > > > won't work if the MN is behind an FA in the > > foreign subnet. > > > > > > > > But again, this is a problem statement draft. > > > Hence, I believe > > > > > > > > that this is the appropriate document for mentioning this > > > > > > > > scenario. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Jayshree > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft Hello > > > > > > > > Jayshree This is a good point - I knew someone > > was to bring > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > scenario would fall into a solution space. Maybe > > > we did not > > > > > > > > make the right decision and we should rethink this. But, > > > > > > > > before we take this discussion further please allow > > > me to ask > > > > > > > > you a few questions about the details of the > > > scenario (VPN+FA) > > > > > > > > that you have in mind . Are you thinking to broadcast FA > > > > > > > > advertisements through the IPsec tunnel to the > > MN? If so, > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > foreign subnet? Or, If you had something > > different in mind, > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > >[> > > > >mailto:jayshree@nortelnetworks.c > > > > >om > > > >] > > > > >, > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > This draft > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > currently misses one scenario were the FA is > > > co-existed with > > > > > > > > the VPN Gateway. I would think that there are no technical > > > > > > > > issues supporting this scenario. It will be good > > if you can > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > 2.6?) > > > > > > > > for completeness. > > > > > > > > Thanks, > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 24 02: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 CAA26922 for ; Wed, 24 Sep 2003 02: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 1A23QU-0006XM-D5 for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 02:47:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8O6l26O025121 for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 02: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 1A23QT-0006X6-Sj for mip4-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 02:47: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 CAA26855 for ; Wed, 24 Sep 2003 02:46:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A23QQ-0006OD-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 02:46:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A23QP-0006OA-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 02:46:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A23QS-0006WN-Cu; Wed, 24 Sep 2003 02: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 1A23QF-0006Vg-IS for mip4@optimus.ietf.org; Wed, 24 Sep 2003 02:46:47 -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 CAA26849; Wed, 24 Sep 2003 02:46:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A23QB-0006Nz-00; Wed, 24 Sep 2003 02:46:43 -0400 Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx with esmtp (Exim 4.12) id 1A23QA-0006NO-00; Wed, 24 Sep 2003 02:46:43 -0400 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HLP00D01HGVZ8@mailout3.samsung.com>; Wed, 24 Sep 2003 15:46:07 +0900 (KST) Received: from ep_ms7_bk (localhost [127.0.0.1]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLP0066JHGV8L@mailout3.samsung.com>; Wed, 24 Sep 2003 15:46:07 +0900 (KST) Received: from ep_was25 (ms7.samsung.com [203.254.225.101]) by ms7.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HLP00H5THGUFT@ms7.samsung.com>; Wed, 24 Sep 2003 15:46:07 +0900 (KST) Content-return: prohibited Date: Wed, 24 Sep 2003 15:46:03 +0900 From: =?EUC-KR?B?vK2w5sHW?= To: Mipshop@ietf.org, mip6@ietf.org, mip4@ietf.org Reply-to: joo.suh@samsung.com Message-id: <0HLP00H5UHGVFT@ms7.samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=euc-kr Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20030924154603@joo.suh X-MTR: 20030924154603@joo.suh X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 Content-Transfer-Encoding: 7BIT Subject: [Mip4] question about fast handoff open source 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, all, If you know any open source for fast handoff implementation, please let me know the web site. In advance, thank you very much. sincerely, Kyungjoo Suh -------------------------------------------------------------------- ' spamcontrol ' _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 24 09:26: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 JAA13253 for ; Wed, 24 Sep 2003 09:26: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 1A29ee-00023Y-JW for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 09:26:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ODQ4CT007898 for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 09:26:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A29ee-00023I-0h for mip4-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 09:26: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 JAA13237 for ; Wed, 24 Sep 2003 09:25:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A29ec-0003wp-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 09:26:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A29eb-0003wl-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 09:26:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A29eb-00022w-G9; Wed, 24 Sep 2003 09:26:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A29eL-00022K-9v for mip4@optimus.ietf.org; Wed, 24 Sep 2003 09:25: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 JAA13223 for ; Wed, 24 Sep 2003 09:25:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A29eJ-0003wU-00 for mip4@ietf.org; Wed, 24 Sep 2003 09:25:43 -0400 Received: from fmr09.intel.com ([192.52.57.35] helo=hermes.hd.intel.com) by ietf-mx with esmtp (Exim 4.12) id 1A29eI-0003wB-00 for mip4@ietf.org; Wed, 24 Sep 2003 09:25:42 -0400 Received: from petasus.hd.intel.com (petasus.hd.intel.com [10.127.45.3]) by hermes.hd.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8ODMpw00976 for ; Wed, 24 Sep 2003 13:22:51 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by petasus.hd.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8ODJnF26572 for ; Wed, 24 Sep 2003 13:19:50 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092406250816650 ; Wed, 24 Sep 2003 06:25:08 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Wed, 24 Sep 2003 06:25:08 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Date: Wed, 24 Sep 2003 06:25:07 -0700 Message-ID: <96D13222E704DC4D868F0009F0EE53E10AC0DA@orsmsx410.jf.intel.com> Thread-Topic: Request for text proposal for your scenario Thread-Index: AcOCN1zQMxeSgz26SuempFcTgeIyFQAZQOIA From: "Adrangi, Farid" To: "Gopal Dommety" , "Jayshree Bharatia" Cc: , , X-OriginalArrivalTime: 24 Sep 2003 13:25:08.0151 (UTC) FILETIME=[45F39C70:01C3829F] Content-Transfer-Encoding: quoted-printable Subject: [Mip4] RE: Request for text proposal for your scenario 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 Thanks Gopal. IMO, the scenario lacks some details. For example,=20 1) does this scenario allow MN to work in non-colocated mode? That is, MN ---FA---VPN/FA ---Intranet 2) What is the role of FA on the VPN gateway? In other words, what is the difference between=20 MN -----VPN/FA ------Intranet (your scenario)=20 And MN -------VPN -------Intranet=20 However, if others are okay with the text as it is, then I'll go ahead and add it. BR, Farid=20 -----Original Message----- From: Gopal Dommety [mailto:gdommety@cisco.com]=20 Sent: Tuesday, September 23, 2003 6:01 PM To: Adrangi, Farid; Jayshree Bharatia Cc: mccap@lucent.com; henrik@levkowetz.com; mip4@ietf.org Subject: RE: Request for text proposal for your scenario Farid, The text Jayshree sent looks good. I just made minor edits. Here is the=20 text below: 2.6 Combined VPN Gateway and MIPv4 FA MIPv4 FA and the VPN Gateway are running on the same physical machine. ..Foreign Network............VPN Domain..(Intranet)..... . . . . +----+ +-----+ +-------+ +-------+ . . |MNs | | FA | | Router| | HAs | . . |away|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| + | | 1..n = | | | . . | | | VPN | +-------+ +-------+ . . | | | GW | . . +----+ +-----+ +-------+ +-------+ . . . | CN | | MNs | . . . | 1..n | | home | . . . +-------+ +-------+ . . . . ........................................................ In this scenario, the mipv4 tunnel is running inside the IPSec-ESP between the MN and the FA/VPN Gateway.This scenario IPsec being used to protect the data over the wireless network. For end-to-end security model, the VPN Gateway must protect the IP traffic originating at the MN. Since the point of attachment changes corresponding to the movement of the MN, it is essential that the VPN tunnel security association must be refreshed after each IP subnet handoff. Hence, this scenario is not practical where the mobility is involved for the real-time applications due to the performance implications. Thanks Gopal At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: >Any update on this? What should we do next? >--Farid > >-----Original Message----- >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] >Sent: Tuesday, September 16, 2003 11:02 AM >To: 'Gopal Dommety' >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid >Subject: RE: Request for text proposal for your scenario > >Gopal, > >Appreciate if you can make appropriate changes to the proposed text: > >Thanks, >Jayshree > >------------- >Proposed text: > >2.6 Combined VPN Gateway and MIPv4 FA > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > ..Foreign Network............VPN Domain..(Intranet)..... > . . . > . +----+ +-----+ +-------+ +-------+ . > . |MNs | | FA | | Router| | HAs | . > . |away|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| + | | 1..n = | | | . > . | | | VPN | +-------+ +-------+ . > . | | | GW | . > . +----+ +-----+ +-------+ +-------+ . > . . | CN | | MNs | . > . . | 1..n | | home | . > . . +-------+ +-------+ . > . . . > ........................................................ > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP >between >the >MN and the FA/VPN Gateway. For end-to-end security model, the VPN >Gateway >must >protect the IP traffic originating at the MN. Since the point of >attachment >changes corresponding to the movement of the MN, it is essential that >the >VPN >tunnel security association must be refreshed after each IP subnet >handoff. >Hence, this scenario is not practical where the mobility is involved for >the >real-time applications due to the performance implications. > > > > -----Original Message----- > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Sent: Monday, September 15, 2003 4:39 PM > > To: 'Gopal Dommety'; Adrangi, Farid > > Cc: mccap@lucent.com; henrik@levkowetz.com > > Subject: RE: Request for text proposal for your scenario > > > > > > Gopal, > > > > I was in the impression that you will modify the text. > > Anyway, I won't able to do much today but let me try tomorrow > > and send you the text... > > > > Regards, > > Jayshree > > > > > -----Original Message----- > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > Sent: Monday, September 15, 2003 2:03 PM > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > Jayshree, > > > > > > Can you massage the text that you sent to fit what I was > > referring to. > > > > > > -Gopal > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > >Hi Gopal, > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > >Maybe the best thing is that you and Jayshree propose a text that > > > >*clearly* articulates the scenario and its problems. > > Would that be > > > >possible? Thanks a bunch. BR, > > > >Farid > > > > > > > >-----Original Message----- > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > >To: Adrangi, Farid; Jayshree Bharatia > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > >Farid, > > > > > > > >I am not suggesting a solution. I am confused by your > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > >I was talking about one hop away. the multiple hops is > > > interesting. The > > > >deployment scenarios of one hop and multiple hop solutions could be > > > >very > > > > > > > >different. > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > >between the MN and VPN/FA. > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > a FA. For > > > > >example, the following picture is not possible: > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > picture can > > > >be > > > > >simplified as follows > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > particular > > > > >established by different IPsec client software running on > > > the client > > > > >device!!! > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > >problem that we have is with SA refreshes when the MN > > changes its > > > > >point of attachment. Is my understanding correct? > > > > > > > > > >BR, > > > > >FArid > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > access to the > > > > >visiting domain. > > > > >VPN 2 is optional for remote access. > > > > > > > > > >Thanks > > > > >Gopal > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > >Hello Farid, > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > between the > > > >MN > > > > >and > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > >discussed > > > > >in > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > >unprotected > > > > > >between these two entities. > > > > > > > > > > > >Regards, > > > > > >Jayshree > > > > > > > -----Original Message----- > > > > > > > From: Adrangi, Farid > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > gdommety@cisco.com > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > From your description, it is my understanding that > > > there is only > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > the foreign > > > > > > > and the VPN GW in the VPN domain. In other words, No IPsec > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > and hence > > > > > > > data traffic between the MN and the FA is not > > > protected. Is my > > > > > > > understanding correct? I will have more questions/comments > > > > > > > based on your answers. Thanks for the text and > > > hopefully we can > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > >om > > > >] > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > To: Adrangi, Farid > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > gdommety@cisco.com > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > FA-VPN GW > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > Jayshree > > > > > > > --------------------- > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > same physical > > > > >machine. > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > >Domain..(Intranet).... > > > > > > > . . . > > > > >. > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > >+-------+ > > > > >. > > > > > > > . |MNs | | FA | . | VPN| | > > > Router| | HAs > > > >| > > > > >. > > > > > > > . |away| | + | .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| GW = | | 1..n | | > > > >| > > > > >. > > > > > > > . | | | VPN | . | | +-------+ > > > >+-------+ > > > > >. > > > > > > > . | | | GW | . | | > > > > >. > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > >+-------+ > > > > >. > > > > > > > . . . | CN > > > | | MNs > > > >| > > > > >. > > > > > > > .................... . | 1..n > > > | | home > > > >| > > > > >. > > > > > > > . +-------+ > > > >+-------+ > > > > >. > > > > > > > . > > > > >. > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > the FA is > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > is running > > > > > > > inside the IPSec-ESP. For end-to-end security model, the VPN > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > originating at the MN. Since the point of > > attachment changes > > > > > > > corresponding to the movement of the MN, it is > > essential that > > > > > > > the VPN tunnel security association must be refreshed > > > after each > > > > > > > IP subnet handoff. Hence, this scenario is not > > > practical where > > > > > > > the mobility is involved due to performance > > > implications for the > > > > > > > real-time applications. > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > Could you please propose a text for the scenario > > > that you want > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > >om > > > >] > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > To: Adrangi, Farid > > > > > > > > Cc: mip4@ietf.org > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Jayshree > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: mip4@ietf.org > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > had a very > > > > > > > > brief conversation on this during IETF-57 - but I > > > am not sure > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > include this scenario. To be frank, I don't quite > > > understand > > > > > > > > the point behind adding this scenario because, > > > > > > > > - It seems to present a solution to a specific > > > > > > > > deployment model > > > > > > > > rather than a deployment scenario > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > elaborate what you mean by deployment model vs deployment > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > - I don't quite see the advantages of a combined > > > > > > > > VPN+FA if it > > > > > > > > does > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > perhaps you can elaborate on this? [JB] I think > > regardless > > > > > > > > this scenario has any advantages or not, it is one of the > > > > > > > > probable scenario which has potential issues (as you have > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > the problem > > > > > > > > statement > > > > > > > > draft represents combinations of MIPv4 HA and VPN gateway > > > > > > > > placement - adding this scenario is going to change > > > semantics > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > semantics change here. Do you think documenting > > this in new > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > - I just > > > > > > > > wanted to make sure that we clearly understand the > > > reasons for > > > > > > > > adding this scenario to the problem statement > > draft. Design > > > > > > > > team members and interested individuals are welcome > > > to express > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > Best regards, > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > >representative > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > >om > > > >] > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > To: Adrangi, Farid > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > understanding > > > > > > > > is that you will include the scenario of > > co-existed FA with > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > Statement draft. > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and it > > > > > > > > won't work if the MN is behind an FA in the > > foreign subnet. > > > > > > > > But again, this is a problem statement draft. > > > Hence, I believe > > > > > > > > that this is the appropriate document for mentioning this > > > > > > > > scenario. > > > > > > > > > > > > > > > > Thanks, > > > > > > > > Jayshree > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft Hello > > > > > > > > Jayshree This is a good point - I knew someone > > was to bring > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > scenario would fall into a solution space. Maybe > > > we did not > > > > > > > > make the right decision and we should rethink this. But, > > > > > > > > before we take this discussion further please allow > > > me to ask > > > > > > > > you a few questions about the details of the > > > scenario (VPN+FA) > > > > > > > > that you have in mind . Are you thinking to broadcast FA > > > > > > > > advertisements through the IPsec tunnel to the > > MN? If so, > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > foreign subnet? Or, If you had something > > different in mind, > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > >[> > > > >mailto:jayshree@nortelnetworks.c > > > > >om > > > >] > > > > >, > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > This draft > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > currently misses one scenario were the FA is > > > co-existed with > > > > > > > > the VPN Gateway. I would think that there are no technical > > > > > > > > issues supporting this scenario. It will be good > > if you can > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > 2.6?) > > > > > > > > for completeness. > > > > > > > > Thanks, > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 24 09:52: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 JAA14161 for ; Wed, 24 Sep 2003 09:52: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 1A2A3m-0003nf-Ni for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 09:52:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8ODq2GM014601 for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 09:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2A3m-0003nQ-Hs for mip4-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 09:52: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 JAA14147 for ; Wed, 24 Sep 2003 09:51:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2A3k-0004BD-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 09:52:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2A3k-0004BA-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 09:52:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2A3k-0003n7-VV; Wed, 24 Sep 2003 09:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2A3V-0003mr-Dr for mip4@optimus.ietf.org; Wed, 24 Sep 2003 09:51: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 JAA14138 for ; Wed, 24 Sep 2003 09:51:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2A3T-0004B1-00 for mip4@ietf.org; Wed, 24 Sep 2003 09:51:43 -0400 Received: from mta5.algx.net ([67.92.168.234] helo=chimta04.algx.net) by ietf-mx with esmtp (Exim 4.12) id 1A2A3S-0004Ap-00 for mip4@ietf.org; Wed, 24 Sep 2003 09:51:42 -0400 Received: from riesling.local.levkowetz.com ([66.107.48.117]) by chimmx04.algx.net (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0HLQ00LET15AKQ@chimmx04.algx.net> for mip4@ietf.org; Wed, 24 Sep 2003 08:51:10 -0500 (CDT) Received: (qmail 7146 invoked from network); Wed, 24 Sep 2003 13:30:55 +0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; Wed, 24 Sep 2003 13:30:55 +0000 Date: Wed, 24 Sep 2003 09:30:50 -0400 From: Henrik Levkowetz In-reply-to: <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> To: Gopal Dommety Cc: "Adrangi, Farid" , Jayshree Bharatia , mccap@lucent.com, mip4@ietf.org Message-id: <20030924093050.3a775a1f.henrik@levkowetz.com> MIME-version: 1.0 X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Content-type: multipart/signed; boundary="=.CQgWtTy_X(y5K/"; micalg=pgp-sha1; protocol="application/pgp-signature" References: <96D13222E704DC4D868F0009F0EE53E10AC321@orsmsx410.jf.intel.com> <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> Subject: [Mip4] Re: Request for text proposal for your scenario 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: , --=.CQgWtTy_X(y5K/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Gopal and Jayshree, So, I think we still need some changes in this text, because to be frank I still don't understand this. The figure below shows the VPN domain and the forign network as being adjacent, with no internet in between; is that right? In that case, it seems to me this is a roaming within the corporate network scenario, rather than a general roaming scenario. Second, the handovers referred to, are these between different FA's in the corporate network, or going out to the public internet? Third, this scenario seems very contrieved, (but this is maybe because I dont't really understand it?) - it seems to me we could scare up 20 different unrealistic scenarios of the same sort, so I don't understand why we want to pick and include this particular one at all?? It seems to me that adding this scenario makes the draft more confusing rather than more understandable. Henrik Tuesday 23 September 2003, Gopal wrote: > > Farid, > > The text Jayshree sent looks good. I just made minor edits. Here is the > text below: > > > 2.6 Combined VPN Gateway and MIPv4 FA > > MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > ..Foreign Network............VPN Domain..(Intranet)..... > . . . > . +----+ +-----+ +-------+ +-------+ . > . |MNs | | FA | | Router| | HAs | . > . |away|<============>| + | | 1..n | | | . > . | | | VPN | +-------+ +-------+ . > . | | | GW | . > . +----+ +-----+ +-------+ +-------+ . > . . | CN | | MNs | . > . . | 1..n | | home | . > . . +-------+ +-------+ . > . . . > ........................................................ > > In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > between the > MN and the FA/VPN Gateway.This scenario > IPsec being used to protect the data over the wireless network. > > For end-to-end security model, the VPN > Gateway > must > protect the IP traffic originating at the MN. Since the point of > attachment > changes corresponding to the movement of the MN, it is essential that > the > VPN > tunnel security association must be refreshed after each IP subnet > handoff. > > Hence, this scenario is not practical > where the mobility is involved for > the > real-time applications due to the performance implications. > > > Thanks > Gopal > > > > > > At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > >Any update on this? What should we do next? > >--Farid > > > >-----Original Message----- > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > >Sent: Tuesday, September 16, 2003 11:02 AM > >To: 'Gopal Dommety' > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > >Subject: RE: Request for text proposal for your scenario > > > >Gopal, > > > >Appreciate if you can make appropriate changes to the proposed text: > > > >Thanks, > >Jayshree > > > >------------- > >Proposed text: > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > . . . > > . +----+ +-----+ +-------+ +-------+ . > > . |MNs | | FA | | Router| | HAs | . > > . |away|<============>| + | | 1..n | | | . > > . | | | VPN | +-------+ +-------+ . > > . | | | GW | . > > . +----+ +-----+ +-------+ +-------+ . > > . . | CN | | MNs | . > > . . | 1..n | | home | . > > . . +-------+ +-------+ . > > . . . > > ........................................................ > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > >between > >the > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > >Gateway > >must > >protect the IP traffic originating at the MN. Since the point of > >attachment > >changes corresponding to the movement of the MN, it is essential that > >the > >VPN > >tunnel security association must be refreshed after each IP subnet > >handoff. > >Hence, this scenario is not practical where the mobility is involved for > >the > >real-time applications due to the performance implications. > > > > > > > -----Original Message----- > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Sent: Monday, September 15, 2003 4:39 PM > > > To: 'Gopal Dommety'; Adrangi, Farid > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > Gopal, > > > > > > I was in the impression that you will modify the text. > > > Anyway, I won't able to do much today but let me try tomorrow > > > and send you the text... > > > > > > Regards, > > > Jayshree > > > > > > > -----Original Message----- > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > Jayshree, > > > > > > > > Can you massage the text that you sent to fit what I was > > > referring to. > > > > > > > > -Gopal > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > >Hi Gopal, > > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > > >Maybe the best thing is that you and Jayshree propose a text that > > > > >*clearly* articulates the scenario and its problems. > > > Would that be > > > > >possible? Thanks a bunch. BR, > > > > >Farid > > > > > > > > > >-----Original Message----- > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > >Farid, > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > interesting. The > > > > >deployment scenarios of one hop and multiple hop solutions could be > > > > >very > > > > > > > > > >different. > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > > >between the MN and VPN/FA. > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > a FA. For > > > > > >example, the following picture is not possible: > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > picture can > > > > >be > > > > > >simplified as follows > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > particular > > > > > >established by different IPsec client software running on > > > > the client > > > > > >device!!! > > > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > > >problem that we have is with SA refreshes when the MN > > > changes its > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > >BR, > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > access to the > > > > > >visiting domain. > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > >Thanks > > > > > >Gopal > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > between the > > > > >MN > > > > > >and > > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > > >discussed > > > > > >in > > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > > >unprotected > > > > > > >between these two entities. > > > > > > > > > > > > > >Regards, > > > > > > >Jayshree > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > there is only > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > the foreign > > > > > > > > and the VPN GW in the VPN domain. In other words, No IPsec > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > and hence > > > > > > > > data traffic between the MN and the FA is not > > > > protected. Is my > > > > > > > > understanding correct? I will have more questions/comments > > > > > > > > based on your answers. Thanks for the text and > > > > hopefully we can > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > To: Adrangi, Farid > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > FA-VPN GW > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > Jayshree > > > > > > > > --------------------- > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > same physical > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > >Domain..(Intranet).... > > > > > > > > . . . > > > > > >. > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . |MNs | | FA | . | VPN| | > > > > Router| | HAs > > > > >| > > > > > >. > > > > > > > > . |away| | + | .<=========>| GW | | 1..n | | > > > > >| > > > > > >. > > > > > > > > . | | | VPN | . | | +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . | | | GW | . | | > > > > > >. > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . . . | CN > > > > | | MNs > > > > >| > > > > > >. > > > > > > > > .................... . | 1..n > > > > | | home > > > > >| > > > > > >. > > > > > > > > . +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . > > > > > >. > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > the FA is > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > is running > > > > > > > > inside the IPSec-ESP. For end-to-end security model, the VPN > > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > > originating at the MN. Since the point of > > > attachment changes > > > > > > > > corresponding to the movement of the MN, it is > > > essential that > > > > > > > > the VPN tunnel security association must be refreshed > > > > after each > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > practical where > > > > > > > > the mobility is involved due to performance > > > > implications for the > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > gdommety@cisco.com > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > Could you please propose a text for the scenario > > > > that you want > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > had a very > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > am not sure > > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > > include this scenario. To be frank, I don't quite > > > > understand > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > - It seems to present a solution to a specific > > > > > > > > > deployment model > > > > > > > > > rather than a deployment scenario > > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > > elaborate what you mean by deployment model vs deployment > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a combined > > > > > > > > > VPN+FA if it > > > > > > > > > does > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > regardless > > > > > > > > > this scenario has any advantages or not, it is one of the > > > > > > > > > probable scenario which has potential issues (as you have > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > the problem > > > > > > > > > statement > > > > > > > > > draft represents combinations of MIPv4 HA and VPN gateway > > > > > > > > > placement - adding this scenario is going to change > > > > semantics > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > semantics change here. Do you think documenting > > > this in new > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > - I just > > > > > > > > > wanted to make sure that we clearly understand the > > > > reasons for > > > > > > > > > adding this scenario to the problem statement > > > draft. Design > > > > > > > > > team members and interested individuals are welcome > > > > to express > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > >representative > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > understanding > > > > > > > > > is that you will include the scenario of > > > co-existed FA with > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and it > > > > > > > > > won't work if the MN is behind an FA in the > > > foreign subnet. > > > > > > > > > But again, this is a problem statement draft. > > > > Hence, I believe > > > > > > > > > that this is the appropriate document for mentioning this > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft Hello > > > > > > > > > Jayshree This is a good point - I knew someone > > > was to bring > > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > > scenario would fall into a solution space. Maybe > > > > we did not > > > > > > > > > make the right decision and we should rethink this. But, > > > > > > > > > before we take this discussion further please allow > > > > me to ask > > > > > > > > > you a few questions about the details of the > > > > scenario (VPN+FA) > > > > > > > > > that you have in mind . Are you thinking to broadcast FA > > > > > > > > > advertisements through the IPsec tunnel to the > > > MN? If so, > > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > > foreign subnet? Or, If you had something > > > different in mind, > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > >[> > > > > >mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > >, > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > This draft > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > currently misses one scenario were the FA is > > > > co-existed with > > > > > > > > > the VPN Gateway. I would think that there are no technical > > > > > > > > > issues supporting this scenario. It will be good > > > if you can > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > 2.6?) > > > > > > > > > for completeness. > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --=.CQgWtTy_X(y5K/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/cZyMeVhrtTJkXCMRAgUwAKDzH0GP908UTUPPm6wi7TGvqqmtcwCgswXy eAK7mukCGtBRDR+LclIeOm4= =gb1A -----END PGP SIGNATURE----- --=.CQgWtTy_X(y5K/-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 24 13: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 NAA26670 for ; Wed, 24 Sep 2003 13: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 1A2D5W-0001hK-SX for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 13:06:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OH62CS006505 for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 13: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 1A2D5W-0001g8-F7 for mip4-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 13:06: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 NAA26649 for ; Wed, 24 Sep 2003 13:05:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2D5U-0007VR-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 13:06:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2D5U-0007VO-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 13:06:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2D5V-0001eq-51; Wed, 24 Sep 2003 13:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2D4r-0001V6-FD for mip4@optimus.ietf.org; Wed, 24 Sep 2003 13:05: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 NAA26632 for ; Wed, 24 Sep 2003 13:05:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2D4p-0007Ur-00 for mip4@ietf.org; Wed, 24 Sep 2003 13:05:19 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A2D4o-0007Uc-00 for mip4@ietf.org; Wed, 24 Sep 2003 13:05:18 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8OH3sn29677; Wed, 24 Sep 2003 10:03:54 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 24 Sep 2003 12:03:54 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746BB6@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Adrangi, Farid'" , Gopal Dommety Cc: mccap@lucent.com, henrik@levkowetz.com, mip4@ietf.org Date: Wed, 24 Sep 2003 12:03:52 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Mip4] RE: Request for text proposal for your scenario 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: , Hi Farid, Please see my response inline. Regards, Jayshree > -----Original Message----- > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > Sent: Wednesday, September 24, 2003 8:25 AM > To: Gopal Dommety; Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: mccap@lucent.com; henrik@levkowetz.com; mip4@ietf.org > Subject: RE: Request for text proposal for your scenario > > > Thanks Gopal. IMO, the scenario lacks some details. For example, > > 1) does this scenario allow MN to work in non-colocated mode? That is, > > MN ---FA---VPN/FA ---Intranet [JB] If VPN/FA are co-located, that node can have role of Mobile IP FA as well as VPN. You can configure this node however you like but our interest here is for the case where both these roles are active. > > 2) What is the role of FA on the VPN gateway? In other > words, what is the difference between > > MN -----VPN/FA ------Intranet (your scenario) [JB] Functionality of the VPN and the FA are provided through same physical node. > And > MN -------VPN -------Intranet [JB} Not sure what this scenario is but looks like you have FA somewhere else. > > However, if others are okay with the text as it is, then I'll > go ahead and add it. > > BR, > Farid > > > -----Original Message----- > From: Gopal Dommety [mailto:gdommety@cisco.com] > Sent: Tuesday, September 23, 2003 6:01 PM > To: Adrangi, Farid; Jayshree Bharatia > Cc: mccap@lucent.com; henrik@levkowetz.com; mip4@ietf.org > Subject: RE: Request for text proposal for your scenario > > > Farid, > > The text Jayshree sent looks good. I just made minor edits. > Here is the > text below: > > > 2.6 Combined VPN Gateway and MIPv4 FA > > MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > ..Foreign Network............VPN Domain..(Intranet)..... > . . . > . +----+ +-----+ +-------+ +-------+ . > . |MNs | | FA | | Router| | HAs | . > . |away|<============>| + | | 1..n | | | . > . | | | VPN | +-------+ +-------+ . > . | | | GW | . > . +----+ +-----+ +-------+ +-------+ . > . . | CN | | MNs | . > . . | 1..n | | home | . > . . +-------+ +-------+ . > . . . > ........................................................ > > In this scenario, the mipv4 tunnel is running inside the > IPSec-ESP between the MN and the FA/VPN Gateway.This scenario > IPsec being used to protect the data over the wireless network. > > For end-to-end security model, the VPN > Gateway > must > protect the IP traffic originating at the MN. Since the point > of attachment changes corresponding to the movement of the > MN, it is essential that the VPN tunnel security association > must be refreshed after each IP subnet handoff. > > Hence, this scenario is not practical > where the mobility is involved for > the > real-time applications due to the performance implications. > > > Thanks > Gopal > > > > > > At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > >Any update on this? What should we do next? > >--Farid > > > >-----Original Message----- > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > >Sent: Tuesday, September 16, 2003 11:02 AM > >To: 'Gopal Dommety' > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > >Subject: RE: Request for text proposal for your scenario > > > >Gopal, > > > >Appreciate if you can make appropriate changes to the proposed text: > > > >Thanks, > >Jayshree > > > >------------- > >Proposed text: > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > >MIPv4 FA and the VPN Gateway are running on the same > physical machine. > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > . . . > > . +----+ +-----+ +-------+ +-------+ . > > . |MNs | | FA | | Router| | HAs | . > > . |away|<============>| + | | 1..n | | | . > > . | | | VPN | +-------+ +-------+ . > > . | | | GW | . > > . +----+ +-----+ +-------+ +-------+ . > > . . | CN | | MNs | . > > . . | 1..n | | home | . > > . . +-------+ +-------+ . > > . . . > > ........................................................ > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > >between the > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > >Gateway > >must > >protect the IP traffic originating at the MN. Since the point of > >attachment > >changes corresponding to the movement of the MN, it is essential that > >the > >VPN > >tunnel security association must be refreshed after each IP subnet > >handoff. > >Hence, this scenario is not practical where the mobility is involved > for > >the > >real-time applications due to the performance implications. > > > > > > > -----Original Message----- > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Sent: Monday, September 15, 2003 4:39 PM > > > To: 'Gopal Dommety'; Adrangi, Farid > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > Gopal, > > > > > > I was in the impression that you will modify the text. Anyway, I > > > won't able to do much today but let me try tomorrow and > send you the > > > text... > > > > > > Regards, > > > Jayshree > > > > > > > -----Original Message----- > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > Jayshree, > > > > > > > > Can you massage the text that you sent to fit what I was > > > referring to. > > > > > > > > -Gopal > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > >Hi Gopal, > > > > >Ok. I guess my interpretation of your scenario was > not accurate! > > > > >Maybe the best thing is that you and Jayshree propose > a text that > > > > >*clearly* articulates the scenario and its problems. > > > Would that be > > > > >possible? Thanks a bunch. BR, > > > > >Farid > > > > > > > > > >-----Original Message----- > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > >Farid, > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > interesting. The > > > > >deployment scenarios of one hop and multiple hop > solutions could > be > > > > >very > > > > > > > > > >different. > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel > established > > > > > >between the MN and VPN/FA. > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > a FA. For > > > > > >example, the following picture is not possible: > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > picture can > > > > >be > > > > > >simplified as follows > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > particular > > > > > >established by different IPsec client software running on > > > > the client > > > > > >device!!! > > > > > > > > > > > >So, since the scenario does not support #3 above, > then the only > > > > > >problem that we have is with SA refreshes when the MN > > > changes its > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > >BR, > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > access to the > > > > > >visiting domain. > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > >Thanks > > > > > >Gopal > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > between the > > > > >MN > > > > > >and > > > > > > >the FA/VPN. If there is, than it will have similar > issue as > > > > > > >discussed > > > > > >in > > > > > > >the proposed text. If there is no IPSec, the > traffic will be > > > > > >unprotected > > > > > > >between these two entities. > > > > > > > > > > > > > >Regards, > > > > > > >Jayshree > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > there is only > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > the foreign > > > > > > > > and the VPN GW in the VPN domain. In other words, No > IPsec > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > and hence > > > > > > > > data traffic between the MN and the FA is not > > > > protected. Is my > > > > > > > > understanding correct? I will have more > questions/comments > > > > > > > > based on your answers. Thanks for the text and > > > > hopefully we can > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > To: Adrangi, Farid > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > FA-VPN GW > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > Jayshree > > > > > > > > --------------------- > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > same physical > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > >Domain..(Intranet).... > > > > > > > > . . . > > > > > >. > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . |MNs | | FA | . | VPN| | > > > > Router| | HAs > > > > >| > > > > > >. > > > > > > > > . |away| | + | .<=========>| GW | | 1..n | > | > > > > >| > > > > > >. > > > > > > > > . | | | VPN | . | | +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . | | | GW | . | | > > > > > >. > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . . . | CN > > > > | | MNs > > > > >| > > > > > >. > > > > > > > > .................... . | 1..n > > > > | | home > > > > >| > > > > > >. > > > > > > > > . +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . > > > > > >. > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > the FA is > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > is running > > > > > > > > inside the IPSec-ESP. For end-to-end security model, the > VPN > > > > > > > > Gateway within the VPN Domain must protect the > IP traffic > > > > > > > > originating at the MN. Since the point of > > > attachment changes > > > > > > > > corresponding to the movement of the MN, it is > > > essential that > > > > > > > > the VPN tunnel security association must be refreshed > > > > after each > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > practical where > > > > > > > > the mobility is involved due to performance > > > > implications for the > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > gdommety@cisco.com > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > Could you please propose a text for the scenario > > > > that you want > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > had a very > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > am not sure > > > > > > > > > if we derived any conclusion on whether or > not we should > > > > > > > > > include this scenario. To be frank, I don't quite > > > > understand > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > - It seems to present a solution to > a specific > > > > > > > > > deployment model > > > > > > > > > rather than a deployment scenario > > > > > > > > > [JB] My understanding is different from yours > so please > > > > > > > > > elaborate what you mean by deployment model vs > deployment > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a > combined > > > > > > > > > VPN+FA if it > > > > > > > > > does > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > renegotiation when MN moves from one subnet > to another - > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > regardless > > > > > > > > > this scenario has any advantages or not, it is one of > the > > > > > > > > > probable scenario which has potential issues (as you > have > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > the problem > > > > > > > > > statement > > > > > > > > > draft represents combinations of MIPv4 HA and VPN > gateway > > > > > > > > > placement - adding this scenario is going to change > > > > semantics > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > semantics change here. Do you think documenting > > > this in new > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > - I just > > > > > > > > > wanted to make sure that we clearly understand the > > > > reasons for > > > > > > > > > adding this scenario to the problem statement > > > draft. Design > > > > > > > > > team members and interested individuals are welcome > > > > to express > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > >representative > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > understanding > > > > > > > > > is that you will include the scenario of > > > co-existed FA with > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and > it > > > > > > > > > won't work if the MN is behind an FA in the > > > foreign subnet. > > > > > > > > > But again, this is a problem statement draft. > > > > Hence, I believe > > > > > > > > > that this is the appropriate document for mentioning > this > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > Hello > > > > > > > > > Jayshree This is a good point - I knew someone > > > was to bring > > > > > > > > > this up! At the time of writing these > scenarios, we (the > > > > > > > > > design team) actually discussed this and > concluded this > > > > > > > > > scenario would fall into a solution space. Maybe > > > > we did not > > > > > > > > > make the right decision and we should rethink this. > But, > > > > > > > > > before we take this discussion further please allow > > > > me to ask > > > > > > > > > you a few questions about the details of the > > > > scenario (VPN+FA) > > > > > > > > > that you have in mind . Are you thinking to broadcast > FA > > > > > > > > > advertisements through the IPsec tunnel to the > > > MN? If so, > > > > > > > > > how will this work if MN is already behind an > FA in the > > > > > > > > > foreign subnet? Or, If you had something > > > different in mind, > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > >[> > > > > >mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > >, > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > This draft > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > currently misses one scenario were the FA is > > > > co-existed with > > > > > > > > > the VPN Gateway. I would think that there are no > technical > > > > > > > > > issues supporting this scenario. It will be good > > > if you can > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > 2.6?) > > > > > > > > > for completeness. > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 24 13:58: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 NAA28918 for ; Wed, 24 Sep 2003 13:58: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 1A2Dtq-0005fz-MX for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 13:58:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OHw2AT021816 for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 13:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Dtq-0005fn-GU for mip4-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 13:58: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 NAA28884 for ; Wed, 24 Sep 2003 13:57:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Dto-0000Mi-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 13:58:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Dtn-0000Mf-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 13:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Dtp-0005fA-1j; Wed, 24 Sep 2003 13:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Dt6-0005eS-AI for mip4@optimus.ietf.org; Wed, 24 Sep 2003 13:57:16 -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 NAA28858 for ; Wed, 24 Sep 2003 13:57:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Dt3-0000MG-00 for mip4@ietf.org; Wed, 24 Sep 2003 13:57:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Dt2-0000Lp-00 for mip4@ietf.org; Wed, 24 Sep 2003 13:57:13 -0400 Received: from gdommety-w2k01.cisco.com (sjc-vpn3-807.cisco.com [10.21.67.39]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8OHuJxX029860; Wed, 24 Sep 2003 10:56:22 -0700 (PDT) Message-Id: <4.3.2.7.2.20030924105150.027979b8@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Sep 2003 10:56:15 -0700 To: Henrik Levkowetz From: Gopal Dommety Subject: Re: [Mip4] Re: Request for text proposal for your scenario Cc: "Adrangi, Farid" , Jayshree Bharatia , mccap@lucent.com, mip4@ietf.org In-Reply-To: <20030924093050.3a775a1f.henrik@levkowetz.com> References: <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> <96D13222E704DC4D868F0009F0EE53E10AC321@orsmsx410.jf.intel.com> <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Henrik, I think you are thinking "remote access". Think of it as using IPsec instead of L2 encryption in 802.11 case with IPsec terminating at the edge and FA/HA proving mobility. At 09:30 AM 9/24/2003 -0400, Henrik Levkowetz wrote: >Hi Gopal and Jayshree, > > So, I think we still need some changes in this text, because to >be frank I still don't understand this. The figure below shows the >VPN domain and the forign network as being adjacent, with no internet >in between; is that right? In that case, it seems to me this is a >roaming within the corporate network scenario, rather than a general >roaming scenario. > >Second, the handovers referred to, are these between different FA's >in the corporate network, or going out to the public internet? within the corporate network. when dealing with the public internet it is more involved and yet another layer. >Third, this scenario seems very contrieved, (but this is maybe >because I dont't really understand it?) - it seems to me we could >scare up 20 different unrealistic scenarios of the same sort, so >I don't understand why we want to pick and include this particular >one at all?? It seems to me that adding this scenario makes the >draft more confusing rather than more understandable. Hopefully mis-understanding and less contrived :-) -Gopal > Henrik > >Tuesday 23 September 2003, Gopal wrote: > > > > Farid, > > > > The text Jayshree sent looks good. I just made minor edits. Here is the > > text below: > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > . . . > > . +----+ +-----+ +-------+ +-------+ . > > . |MNs | | FA | | Router| | HAs | . > > . |away|<============>| + | | 1..n | | | . > > . | | | VPN | +-------+ +-------+ . > > . | | | GW | . > > . +----+ +-----+ +-------+ +-------+ . > > . . | CN | | MNs | . > > . . | 1..n | | home | . > > . . +-------+ +-------+ . > > . . . > > ........................................................ > > > > In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > between the > > MN and the FA/VPN Gateway.This scenario > > IPsec being used to protect the data over the wireless network. > > > > For end-to-end security model, the VPN > > Gateway > > must > > protect the IP traffic originating at the MN. Since the point of > > attachment > > changes corresponding to the movement of the MN, it is essential that > > the > > VPN > > tunnel security association must be refreshed after each IP subnet > > handoff. > > > > Hence, this scenario is not practical > > where the mobility is involved for > > the > > real-time applications due to the performance implications. > > > > > > Thanks > > Gopal > > > > > > > > > > > > At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > > >Any update on this? What should we do next? > > >--Farid > > > > > >-----Original Message----- > > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > >Sent: Tuesday, September 16, 2003 11:02 AM > > >To: 'Gopal Dommety' > > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > > >Subject: RE: Request for text proposal for your scenario > > > > > >Gopal, > > > > > >Appreciate if you can make appropriate changes to the proposed text: > > > > > >Thanks, > > >Jayshree > > > > > >------------- > > >Proposed text: > > > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > > . . . > > > . +----+ +-----+ +-------+ +-------+ . > > > . |MNs | | FA | | Router| | HAs | . > > > . |away|<============>| + | | 1..n | | | . > > > . | | | VPN | +-------+ +-------+ . > > > . | | | GW | . > > > . +----+ +-----+ +-------+ +-------+ . > > > . . | CN | | MNs | . > > > . . | 1..n | | home | . > > > . . +-------+ +-------+ . > > > . . . > > > ........................................................ > > > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > >between > > >the > > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > > >Gateway > > >must > > >protect the IP traffic originating at the MN. Since the point of > > >attachment > > >changes corresponding to the movement of the MN, it is essential that > > >the > > >VPN > > >tunnel security association must be refreshed after each IP subnet > > >handoff. > > >Hence, this scenario is not practical where the mobility is involved for > > >the > > >real-time applications due to the performance implications. > > > > > > > > > > -----Original Message----- > > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Sent: Monday, September 15, 2003 4:39 PM > > > > To: 'Gopal Dommety'; Adrangi, Farid > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > Gopal, > > > > > > > > I was in the impression that you will modify the text. > > > > Anyway, I won't able to do much today but let me try tomorrow > > > > and send you the text... > > > > > > > > Regards, > > > > Jayshree > > > > > > > > > -----Original Message----- > > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > Jayshree, > > > > > > > > > > Can you massage the text that you sent to fit what I was > > > > referring to. > > > > > > > > > > -Gopal > > > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > > > >Hi Gopal, > > > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > > > >Maybe the best thing is that you and Jayshree propose a text that > > > > > >*clearly* articulates the scenario and its problems. > > > > Would that be > > > > > >possible? Thanks a bunch. BR, > > > > > >Farid > > > > > > > > > > > >-----Original Message----- > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > >Farid, > > > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > > interesting. The > > > > > >deployment scenarios of one hop and multiple hop solutions could be > > > > > >very > > > > > > > > > > > >different. > > > > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > > > >between the MN and VPN/FA. > > > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > > a FA. For > > > > > > >example, the following picture is not possible: > > > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > > picture can > > > > > >be > > > > > > >simplified as follows > > > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > > particular > > > > > > >established by different IPsec client software running on > > > > > the client > > > > > > >device!!! > > > > > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > > > >problem that we have is with SA refreshes when the MN > > > > changes its > > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > > > >BR, > > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > > access to the > > > > > > >visiting domain. > > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > > > >Thanks > > > > > > >Gopal > > > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > > between the > > > > > >MN > > > > > > >and > > > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > > > >discussed > > > > > > >in > > > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > > > >unprotected > > > > > > > >between these two entities. > > > > > > > > > > > > > > > >Regards, > > > > > > > >Jayshree > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > gdommety@cisco.com > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > > there is only > > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > > the foreign > > > > > > > > > and the VPN GW in the VPN domain. In other words, No IPsec > > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > > and hence > > > > > > > > > data traffic between the MN and the FA is not > > > > > protected. Is my > > > > > > > > > understanding correct? I will have more questions/comments > > > > > > > > > based on your answers. Thanks for the text and > > > > > hopefully we can > > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > >om > > > > > >] > > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > gdommety@cisco.com > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > > FA-VPN GW > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > > Jayshree > > > > > > > > > --------------------- > > > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > > same physical > > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > > >Domain..(Intranet).... > > > > > > > > > . . . > > > > > > >. > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > >+-------+ > > > > > > >. > > > > > > > > > . |MNs | | FA | . | VPN| | > > > > > Router| | HAs > > > > > >| > > > > > > >. > > > > > > > > > . |away| | + | .<=========>| GW | | 1..n | | > > > > > >| > > > > > > >. > > > > > > > > > . | | | VPN | . | | +-------+ > > > > > >+-------+ > > > > > > >. > > > > > > > > > . | | | GW | . | | > > > > > > >. > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > >+-------+ > > > > > > >. > > > > > > > > > . . . | CN > > > > > | | MNs > > > > > >| > > > > > > >. > > > > > > > > > .................... . | 1..n > > > > > | | home > > > > > >| > > > > > > >. > > > > > > > > > . +-------+ > > > > > >+-------+ > > > > > > >. > > > > > > > > > . > > > > > > >. > > > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > > the FA is > > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > > is running > > > > > > > > > inside the IPSec-ESP. For end-to-end security model, the VPN > > > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > > > originating at the MN. Since the point of > > > > attachment changes > > > > > > > > > corresponding to the movement of the MN, it is > > > > essential that > > > > > > > > > the VPN tunnel security association must be refreshed > > > > > after each > > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > > practical where > > > > > > > > > the mobility is involved due to performance > > > > > implications for the > > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > gdommety@cisco.com > > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > Could you please propose a text for the scenario > > > > > that you want > > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > >om > > > > > >] > > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Jayshree > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > > had a very > > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > > am not sure > > > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > > > include this scenario. To be frank, I don't quite > > > > > understand > > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > > - It seems to present a solution to a specific > > > > > > > > > > deployment model > > > > > > > > > > rather than a deployment scenario > > > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > > > elaborate what you mean by deployment model vs deployment > > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a combined > > > > > > > > > > VPN+FA if it > > > > > > > > > > does > > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > > regardless > > > > > > > > > > this scenario has any advantages or not, it is one of the > > > > > > > > > > probable scenario which has potential issues (as you have > > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > > the problem > > > > > > > > > > statement > > > > > > > > > > draft represents combinations of MIPv4 HA and VPN gateway > > > > > > > > > > placement - adding this scenario is going to change > > > > > semantics > > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > > semantics change here. Do you think documenting > > > > this in new > > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > > - I just > > > > > > > > > > wanted to make sure that we clearly understand the > > > > > reasons for > > > > > > > > > > adding this scenario to the problem statement > > > > draft. Design > > > > > > > > > > team members and interested individuals are welcome > > > > > to express > > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > > >representative > > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > >om > > > > > >] > > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > > understanding > > > > > > > > > > is that you will include the scenario of > > > > co-existed FA with > > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and it > > > > > > > > > > won't work if the MN is behind an FA in the > > > > foreign subnet. > > > > > > > > > > But again, this is a problem statement draft. > > > > > Hence, I believe > > > > > > > > > > that this is the appropriate document for mentioning this > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft Hello > > > > > > > > > > Jayshree This is a good point - I knew someone > > > > was to bring > > > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > > > scenario would fall into a solution space. Maybe > > > > > we did not > > > > > > > > > > make the right decision and we should rethink this. But, > > > > > > > > > > before we take this discussion further please allow > > > > > me to ask > > > > > > > > > > you a few questions about the details of the > > > > > scenario (VPN+FA) > > > > > > > > > > that you have in mind . Are you thinking to broadcast FA > > > > > > > > > > advertisements through the IPsec tunnel to the > > > > MN? If so, > > > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > > > foreign subnet? Or, If you had something > > > > different in mind, > > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > >[> > > > > > >mailto:jayshree@nortelnetworks.c > > > > > > >om > > > > > >] > > > > > > >, > > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > This draft > > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > > currently misses one scenario were the FA is > > > > > co-existed with > > > > > > > > > > the VPN Gateway. I would think that there are no technical > > > > > > > > > > issues supporting this scenario. It will be good > > > > if you can > > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > > 2.6?) > > > > > > > > > > for completeness. > > > > > > > > > > Thanks, > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Sep 24 14:00: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 OAA29033 for ; Wed, 24 Sep 2003 14:00: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 1A2Dvo-0005nV-En for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 14:00:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8OI04MK022279 for mip4-archive@odin.ietf.org; Wed, 24 Sep 2003 14:00:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Dvm-0005mu-M5 for mip4-web-archive@optimus.ietf.org; Wed, 24 Sep 2003 14:00: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 NAA29007 for ; Wed, 24 Sep 2003 13:59:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Dvk-0000Ot-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 14:00:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Dvj-0000Oq-00 for mip4-web-archive@ietf.org; Wed, 24 Sep 2003 13:59:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Dvl-0005lQ-D4; Wed, 24 Sep 2003 14:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Duy-0005kG-Of for mip4@optimus.ietf.org; Wed, 24 Sep 2003 13:59:12 -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 NAA28973 for ; Wed, 24 Sep 2003 13:59:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Duw-0000OD-00 for mip4@ietf.org; Wed, 24 Sep 2003 13:59:10 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Duv-0000NX-00 for mip4@ietf.org; Wed, 24 Sep 2003 13:59:09 -0400 Received: from gdommety-w2k01.cisco.com (sjc-vpn3-807.cisco.com [10.21.67.39]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8OHwFxX001510; Wed, 24 Sep 2003 10:58:28 -0700 (PDT) Message-Id: <4.3.2.7.2.20030924105620.027cb7a0@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 24 Sep 2003 10:58:13 -0700 To: "Adrangi, Farid" , "Jayshree Bharatia" From: Gopal Dommety Subject: Re: [Mip4] RE: Request for text proposal for your scenario Cc: , , In-Reply-To: <96D13222E704DC4D868F0009F0EE53E10AC0DA@orsmsx410.jf.intel. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , At 06:25 AM 9/24/2003 -0700, Adrangi, Farid wrote: >Thanks Gopal. IMO, the scenario lacks some details. For example, > >1) does this scenario allow MN to work in non-colocated mode? That is, > >MN ---FA---VPN/FA ---Intranet yes...But the figure you drew is not correct...It could be as follows.. MN -----VPN/FA ---Intranet >2) What is the role of FA on the VPN gateway? In other words, what is >the difference between > >MN -----VPN/FA ------Intranet (your scenario) >And >MN -------VPN -------Intranet FA can be optionally used for Mobility (I think you left out HA in your figure) >However, if others are okay with the text as it is, then I'll go ahead >and add it. > >BR, >Farid > > >-----Original Message----- >From: Gopal Dommety [mailto:gdommety@cisco.com] >Sent: Tuesday, September 23, 2003 6:01 PM >To: Adrangi, Farid; Jayshree Bharatia >Cc: mccap@lucent.com; henrik@levkowetz.com; mip4@ietf.org >Subject: RE: Request for text proposal for your scenario > > >Farid, > >The text Jayshree sent looks good. I just made minor edits. Here is the >text below: > > >2.6 Combined VPN Gateway and MIPv4 FA > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > ..Foreign Network............VPN Domain..(Intranet)..... > . . . > . +----+ +-----+ +-------+ +-------+ . > . |MNs | | FA | | Router| | HAs | . > . |away|<============>| + | | 1..n | | | . > . | | | VPN | +-------+ +-------+ . > . | | | GW | . > . +----+ +-----+ +-------+ +-------+ . > . . | CN | | MNs | . > . . | 1..n | | home | . > . . +-------+ +-------+ . > . . . > ........................................................ > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP >between the >MN and the FA/VPN Gateway.This scenario > IPsec being used to protect the data over the wireless network. > >For end-to-end security model, the VPN >Gateway >must >protect the IP traffic originating at the MN. Since the point of >attachment >changes corresponding to the movement of the MN, it is essential that >the >VPN >tunnel security association must be refreshed after each IP subnet >handoff. > >Hence, this scenario is not practical >where the mobility is involved for >the >real-time applications due to the performance implications. > > >Thanks >Gopal > > > > > >At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > >Any update on this? What should we do next? > >--Farid > > > >-----Original Message----- > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > >Sent: Tuesday, September 16, 2003 11:02 AM > >To: 'Gopal Dommety' > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > >Subject: RE: Request for text proposal for your scenario > > > >Gopal, > > > >Appreciate if you can make appropriate changes to the proposed text: > > > >Thanks, > >Jayshree > > > >------------- > >Proposed text: > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > . . . > > . +----+ +-----+ +-------+ +-------+ . > > . |MNs | | FA | | Router| | HAs | . > > . |away|<============>| + | | 1..n | | | . > > . | | | VPN | +-------+ +-------+ . > > . | | | GW | . > > . +----+ +-----+ +-------+ +-------+ . > > . . | CN | | MNs | . > > . . | 1..n | | home | . > > . . +-------+ +-------+ . > > . . . > > ........................................................ > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > >between > >the > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > >Gateway > >must > >protect the IP traffic originating at the MN. Since the point of > >attachment > >changes corresponding to the movement of the MN, it is essential that > >the > >VPN > >tunnel security association must be refreshed after each IP subnet > >handoff. > >Hence, this scenario is not practical where the mobility is involved >for > >the > >real-time applications due to the performance implications. > > > > > > > -----Original Message----- > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Sent: Monday, September 15, 2003 4:39 PM > > > To: 'Gopal Dommety'; Adrangi, Farid > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > Gopal, > > > > > > I was in the impression that you will modify the text. > > > Anyway, I won't able to do much today but let me try tomorrow > > > and send you the text... > > > > > > Regards, > > > Jayshree > > > > > > > -----Original Message----- > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > Jayshree, > > > > > > > > Can you massage the text that you sent to fit what I was > > > referring to. > > > > > > > > -Gopal > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > >Hi Gopal, > > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > > >Maybe the best thing is that you and Jayshree propose a text that > > > > >*clearly* articulates the scenario and its problems. > > > Would that be > > > > >possible? Thanks a bunch. BR, > > > > >Farid > > > > > > > > > >-----Original Message----- > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > >Farid, > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > interesting. The > > > > >deployment scenarios of one hop and multiple hop solutions could >be > > > > >very > > > > > > > > > >different. > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > > >between the MN and VPN/FA. > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > a FA. For > > > > > >example, the following picture is not possible: > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > picture can > > > > >be > > > > > >simplified as follows > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > particular > > > > > >established by different IPsec client software running on > > > > the client > > > > > >device!!! > > > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > > >problem that we have is with SA refreshes when the MN > > > changes its > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > >BR, > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > access to the > > > > > >visiting domain. > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > >Thanks > > > > > >Gopal > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > between the > > > > >MN > > > > > >and > > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > > >discussed > > > > > >in > > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > > >unprotected > > > > > > >between these two entities. > > > > > > > > > > > > > >Regards, > > > > > > >Jayshree > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > there is only > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > the foreign > > > > > > > > and the VPN GW in the VPN domain. In other words, No >IPsec > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > and hence > > > > > > > > data traffic between the MN and the FA is not > > > > protected. Is my > > > > > > > > understanding correct? I will have more >questions/comments > > > > > > > > based on your answers. Thanks for the text and > > > > hopefully we can > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > To: Adrangi, Farid > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > FA-VPN GW > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > Jayshree > > > > > > > > --------------------- > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > same physical > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > >Domain..(Intranet).... > > > > > > > > . . . > > > > > >. > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . |MNs | | FA | . | VPN| | > > > > Router| | HAs > > > > >| > > > > > >. > > > > > > > > . |away| | + | .<=========>| GW | | 1..n | >| > > > > >| > > > > > >. > > > > > > > > . | | | VPN | . | | +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . | | | GW | . | | > > > > > >. > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . . . | CN > > > > | | MNs > > > > >| > > > > > >. > > > > > > > > .................... . | 1..n > > > > | | home > > > > >| > > > > > >. > > > > > > > > . +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . > > > > > >. > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > the FA is > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > is running > > > > > > > > inside the IPSec-ESP. For end-to-end security model, the >VPN > > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > > originating at the MN. Since the point of > > > attachment changes > > > > > > > > corresponding to the movement of the MN, it is > > > essential that > > > > > > > > the VPN tunnel security association must be refreshed > > > > after each > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > practical where > > > > > > > > the mobility is involved due to performance > > > > implications for the > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > gdommety@cisco.com > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > Could you please propose a text for the scenario > > > > that you want > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > had a very > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > am not sure > > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > > include this scenario. To be frank, I don't quite > > > > understand > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > - It seems to present a solution to a specific > > > > > > > > > deployment model > > > > > > > > > rather than a deployment scenario > > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > > elaborate what you mean by deployment model vs >deployment > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a >combined > > > > > > > > > VPN+FA if it > > > > > > > > > does > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > regardless > > > > > > > > > this scenario has any advantages or not, it is one of >the > > > > > > > > > probable scenario which has potential issues (as you >have > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > the problem > > > > > > > > > statement > > > > > > > > > draft represents combinations of MIPv4 HA and VPN >gateway > > > > > > > > > placement - adding this scenario is going to change > > > > semantics > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > semantics change here. Do you think documenting > > > this in new > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > - I just > > > > > > > > > wanted to make sure that we clearly understand the > > > > reasons for > > > > > > > > > adding this scenario to the problem statement > > > draft. Design > > > > > > > > > team members and interested individuals are welcome > > > > to express > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > >representative > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > understanding > > > > > > > > > is that you will include the scenario of > > > co-existed FA with > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and >it > > > > > > > > > won't work if the MN is behind an FA in the > > > foreign subnet. > > > > > > > > > But again, this is a problem statement draft. > > > > Hence, I believe > > > > > > > > > that this is the appropriate document for mentioning >this > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft >Hello > > > > > > > > > Jayshree This is a good point - I knew someone > > > was to bring > > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > > scenario would fall into a solution space. Maybe > > > > we did not > > > > > > > > > make the right decision and we should rethink this. >But, > > > > > > > > > before we take this discussion further please allow > > > > me to ask > > > > > > > > > you a few questions about the details of the > > > > scenario (VPN+FA) > > > > > > > > > that you have in mind . Are you thinking to broadcast >FA > > > > > > > > > advertisements through the IPsec tunnel to the > > > MN? If so, > > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > > foreign subnet? Or, If you had something > > > different in mind, > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > >[> > > > > >mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > >, > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > This draft > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > currently misses one scenario were the FA is > > > > co-existed with > > > > > > > > > the VPN Gateway. I would think that there are no >technical > > > > > > > > > issues supporting this scenario. It will be good > > > if you can > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > 2.6?) > > > > > > > > > for completeness. > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ >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 Sep 25 08:00:36 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 IAA20341 for ; Thu, 25 Sep 2003 08:00:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Un5-0002EE-3X for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 08:00:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PC0A6i008526 for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 08:00:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Un3-0002Cn-Az for mip4-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 08:00: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 HAA20295 for ; Thu, 25 Sep 2003 07:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Umx-0004so-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 08:00:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Umx-0004sl-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 08:00:03 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Umv-00029u-Vk; Thu, 25 Sep 2003 08:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ulw-00024I-Cv for mip4@optimus.ietf.org; Thu, 25 Sep 2003 07:59:00 -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 HAA20232 for ; Thu, 25 Sep 2003 07:58:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ulv-0004rK-00 for mip4@ietf.org; Thu, 25 Sep 2003 07:58:59 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A2Uls-0004rG-00 for mip4@ietf.org; Thu, 25 Sep 2003 07:58:56 -0400 Received: (qmail 10271 invoked from network); 25 Sep 2003 11:58:53 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 25 Sep 2003 11:58:53 -0000 Date: Thu, 25 Sep 2003 07:58:52 -0400 From: Henrik Levkowetz To: Gopal Dommety Cc: "Adrangi, Farid" , Jayshree Bharatia , mccap@lucent.com, mip4@ietf.org Subject: Re: [Mip4] Re: Request for text proposal for your scenario Message-Id: <20030925075852.65bd94e6.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030924105150.027979b8@mira-sjcm-3.cisco.com> References: <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> <96D13222E704DC4D868F0009F0EE53E10AC321@orsmsx410.jf.intel.com> <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030924105150.027979b8@mira-sjcm-3.cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.q1eNcYWEOWcYfF" 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: , --=.q1eNcYWEOWcYfF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Gopal, Wednesday 24 September 2003, Gopal wrote: > I think you are thinking "remote access". Think of it as using IPsec > instead of L2 encryption in 802.11 > case with IPsec terminating at the edge and FA/HA proving mobility. I only say that there is much more text required to explain this scenario. I'm still not sure I understand it, and I definitely don't have any understanding of what it contributes to the problem statement. More comments below. > At 09:30 AM 9/24/2003 -0400, Henrik Levkowetz wrote: > >Hi Gopal and Jayshree, > > > > So, I think we still need some changes in this text, because to > >be frank I still don't understand this. The figure below shows the > >VPN domain and the forign network as being adjacent, with no internet > >in between; is that right? In that case, it seems to me this is a > >roaming within the corporate network scenario, rather than a general > >roaming scenario. I still miss an answer to above question. > >Second, the handovers referred to, are these between different FA's > >in the corporate network, or going out to the public internet? > > within the corporate network. when dealing with the public internet it is > more involved and yet another layer. Ok, then the text needs to point out that, and also explain why we are looking at this case at all. > >Third, this scenario seems very contrieved, (but this is maybe > >because I dont't really understand it?) - it seems to me we could > >scare up 20 different unrealistic scenarios of the same sort, so > >I don't understand why we want to pick and include this particular > >one at all?? It seems to me that adding this scenario makes the > >draft more confusing rather than more understandable. > > Hopefully mis-understanding and less contrived :-) I'm still not convinced. *Please* provide text which actually communicates what this is all about to the un-initiated reader. Henrik > -Gopal > > > > Henrik > > > >Tuesday 23 September 2003, Gopal wrote: > > > > > > Farid, > > > > > > The text Jayshree sent looks good. I just made minor edits. Here is the > > > text below: > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > > . . . > > > . +----+ +-----+ +-------+ +-------+ . > > > . |MNs | | FA | | Router| | HAs | . > > > . |away|<============>| + | | 1..n | | | . > > > . | | | VPN | +-------+ +-------+ . > > > . | | | GW | . > > > . +----+ +-----+ +-------+ +-------+ . > > > . . | CN | | MNs | . > > > . . | 1..n | | home | . > > > . . +-------+ +-------+ . > > > . . . > > > ........................................................ > > > > > > In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > > between the > > > MN and the FA/VPN Gateway.This scenario > > > IPsec being used to protect the data over the wireless network. > > > > > > For end-to-end security model, the VPN > > > Gateway > > > must > > > protect the IP traffic originating at the MN. Since the point of > > > attachment > > > changes corresponding to the movement of the MN, it is essential that > > > the > > > VPN > > > tunnel security association must be refreshed after each IP subnet > > > handoff. > > > > > > Hence, this scenario is not practical > > > where the mobility is involved for > > > the > > > real-time applications due to the performance implications. > > > > > > > > > Thanks > > > Gopal > > > > > > > > > > > > > > > > > > At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > > > >Any update on this? What should we do next? > > > >--Farid > > > > > > > >-----Original Message----- > > > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > >Sent: Tuesday, September 16, 2003 11:02 AM > > > >To: 'Gopal Dommety' > > > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > >Gopal, > > > > > > > >Appreciate if you can make appropriate changes to the proposed text: > > > > > > > >Thanks, > > > >Jayshree > > > > > > > >------------- > > > >Proposed text: > > > > > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > > > . . . > > > > . +----+ +-----+ +-------+ +-------+ . > > > > . |MNs | | FA | | Router| | HAs | . > > > > . |away|<============>| + | | 1..n | | | . > > > > . | | | VPN | +-------+ +-------+ . > > > > . | | | GW | . > > > > . +----+ +-----+ +-------+ +-------+ . > > > > . . | CN | | MNs | . > > > > . . | 1..n | | home | . > > > > . . +-------+ +-------+ . > > > > . . . > > > > ........................................................ > > > > > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > > >between > > > >the > > > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > > > >Gateway > > > >must > > > >protect the IP traffic originating at the MN. Since the point of > > > >attachment > > > >changes corresponding to the movement of the MN, it is essential that > > > >the > > > >VPN > > > >tunnel security association must be refreshed after each IP subnet > > > >handoff. > > > >Hence, this scenario is not practical where the mobility is involved for > > > >the > > > >real-time applications due to the performance implications. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Sent: Monday, September 15, 2003 4:39 PM > > > > > To: 'Gopal Dommety'; Adrangi, Farid > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > Gopal, > > > > > > > > > > I was in the impression that you will modify the text. > > > > > Anyway, I won't able to do much today but let me try tomorrow > > > > > and send you the text... > > > > > > > > > > Regards, > > > > > Jayshree > > > > > > > > > > > -----Original Message----- > > > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > Jayshree, > > > > > > > > > > > > Can you massage the text that you sent to fit what I was > > > > > referring to. > > > > > > > > > > > > -Gopal > > > > > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > > > > > >Hi Gopal, > > > > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > > > > >Maybe the best thing is that you and Jayshree propose a text that > > > > > > >*clearly* articulates the scenario and its problems. > > > > > Would that be > > > > > > >possible? Thanks a bunch. BR, > > > > > > >Farid > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > >Farid, > > > > > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > > > interesting. The > > > > > > >deployment scenarios of one hop and multiple hop solutions could be > > > > > > >very > > > > > > > > > > > > > >different. > > > > > > > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > > > > >between the MN and VPN/FA. > > > > > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > > > a FA. For > > > > > > > >example, the following picture is not possible: > > > > > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > > > picture can > > > > > > >be > > > > > > > >simplified as follows > > > > > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > > > particular > > > > > > > >established by different IPsec client software running on > > > > > > the client > > > > > > > >device!!! > > > > > > > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > > > > >problem that we have is with SA refreshes when the MN > > > > > changes its > > > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > > > > > >BR, > > > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > > > access to the > > > > > > > >visiting domain. > > > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > > > > > >Thanks > > > > > > > >Gopal > > > > > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > > > between the > > > > > > >MN > > > > > > > >and > > > > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > > > > >discussed > > > > > > > >in > > > > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > > > > >unprotected > > > > > > > > >between these two entities. > > > > > > > > > > > > > > > > > >Regards, > > > > > > > > >Jayshree > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > gdommety@cisco.com > > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > > > there is only > > > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > > > the foreign > > > > > > > > > > and the VPN GW in the VPN domain. In other words, No IPsec > > > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > > > and hence > > > > > > > > > > data traffic between the MN and the FA is not > > > > > > protected. Is my > > > > > > > > > > understanding correct? I will have more questions/comments > > > > > > > > > > based on your answers. Thanks for the text and > > > > > > hopefully we can > > > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > > >om > > > > > > >] > > > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > gdommety@cisco.com > > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > > > FA-VPN GW > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > > > Jayshree > > > > > > > > > > --------------------- > > > > > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > > > same physical > > > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > > > >Domain..(Intranet).... > > > > > > > > > > . . . > > > > > > > >. > > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > > >+-------+ > > > > > > > >. > > > > > > > > > > . |MNs | | FA | . | VPN| | > > > > > > Router| | HAs > > > > > > >| > > > > > > > >. > > > > > > > > > > . |away| | + | .<=========>| GW | | 1..n | | > > > > > > >| > > > > > > > >. > > > > > > > > > > . | | | VPN | . | | +-------+ > > > > > > >+-------+ > > > > > > > >. > > > > > > > > > > . | | | GW | . | | > > > > > > > >. > > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > > >+-------+ > > > > > > > >. > > > > > > > > > > . . . | CN > > > > > > | | MNs > > > > > > >| > > > > > > > >. > > > > > > > > > > .................... . | 1..n > > > > > > | | home > > > > > > >| > > > > > > > >. > > > > > > > > > > . +-------+ > > > > > > >+-------+ > > > > > > > >. > > > > > > > > > > . > > > > > > > >. > > > > > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > > > the FA is > > > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > > > is running > > > > > > > > > > inside the IPSec-ESP. For end-to-end security model, the VPN > > > > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > > > > originating at the MN. Since the point of > > > > > attachment changes > > > > > > > > > > corresponding to the movement of the MN, it is > > > > > essential that > > > > > > > > > > the VPN tunnel security association must be refreshed > > > > > > after each > > > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > > > practical where > > > > > > > > > > the mobility is involved due to performance > > > > > > implications for the > > > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > > gdommety@cisco.com > > > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > > Could you please propose a text for the scenario > > > > > > that you want > > > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > > >om > > > > > > >] > > > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Jayshree > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > > > had a very > > > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > > > am not sure > > > > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > > > > include this scenario. To be frank, I don't quite > > > > > > understand > > > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > > > - It seems to present a solution to a specific > > > > > > > > > > > deployment model > > > > > > > > > > > rather than a deployment scenario > > > > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > > > > elaborate what you mean by deployment model vs deployment > > > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a combined > > > > > > > > > > > VPN+FA if it > > > > > > > > > > > does > > > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > > > regardless > > > > > > > > > > > this scenario has any advantages or not, it is one of the > > > > > > > > > > > probable scenario which has potential issues (as you have > > > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > > > the problem > > > > > > > > > > > statement > > > > > > > > > > > draft represents combinations of MIPv4 HA and VPN gateway > > > > > > > > > > > placement - adding this scenario is going to change > > > > > > semantics > > > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > > > semantics change here. Do you think documenting > > > > > this in new > > > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > > > - I just > > > > > > > > > > > wanted to make sure that we clearly understand the > > > > > > reasons for > > > > > > > > > > > adding this scenario to the problem statement > > > > > draft. Design > > > > > > > > > > > team members and interested individuals are welcome > > > > > > to express > > > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > > > >representative > > > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > > >om > > > > > > >] > > > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > > > understanding > > > > > > > > > > > is that you will include the scenario of > > > > > co-existed FA with > > > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and it > > > > > > > > > > > won't work if the MN is behind an FA in the > > > > > foreign subnet. > > > > > > > > > > > But again, this is a problem statement draft. > > > > > > Hence, I believe > > > > > > > > > > > that this is the appropriate document for mentioning this > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft Hello > > > > > > > > > > > Jayshree This is a good point - I knew someone > > > > > was to bring > > > > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > > > > scenario would fall into a solution space. Maybe > > > > > > we did not > > > > > > > > > > > make the right decision and we should rethink this. But, > > > > > > > > > > > before we take this discussion further please allow > > > > > > me to ask > > > > > > > > > > > you a few questions about the details of the > > > > > > scenario (VPN+FA) > > > > > > > > > > > that you have in mind . Are you thinking to broadcast FA > > > > > > > > > > > advertisements through the IPsec tunnel to the > > > > > MN? If so, > > > > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > > > > foreign subnet? Or, If you had something > > > > > different in mind, > > > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > >[> > > > > > > >mailto:jayshree@nortelnetworks.c > > > > > > > >om > > > > > > >] > > > > > > > >, > > > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > This draft > > > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > > > currently misses one scenario were the FA is > > > > > > co-existed with > > > > > > > > > > > the VPN Gateway. I would think that there are no technical > > > > > > > > > > > issues supporting this scenario. It will be good > > > > > if you can > > > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > > > 2.6?) > > > > > > > > > > > for completeness. > > > > > > > > > > > Thanks, > > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --=.q1eNcYWEOWcYfF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/cth8eVhrtTJkXCMRAhg8AKDhZEHOOz760kZxCAktuC1INTrvNACdHsMZ Q02/S2DIOLURJkgCHba5y+k= =y/8b -----END PGP SIGNATURE----- --=.q1eNcYWEOWcYfF-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 25 08:02: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 IAA20421 for ; Thu, 25 Sep 2003 08:02: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 1A2Uot-0002Lw-Rc for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 08:02:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PC232e009038 for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 08:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Uot-0002Lh-Kk for mip4-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 08:02: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 IAA20409 for ; Thu, 25 Sep 2003 08:01:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Uor-0004uA-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 08:02:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Uoq-0004u7-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 08:02:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Uor-0002KD-3Z; Thu, 25 Sep 2003 08:02:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Unt-0002I4-1c for mip4@optimus.ietf.org; Thu, 25 Sep 2003 08:01: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 IAA20361 for ; Thu, 25 Sep 2003 08:00:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Unr-0004tc-00 for mip4@ietf.org; Thu, 25 Sep 2003 08:00:59 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A2Unq-0004tU-00 for mip4@ietf.org; Thu, 25 Sep 2003 08:00:58 -0400 Received: (qmail 10315 invoked from network); 25 Sep 2003 12:00:57 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 25 Sep 2003 12:00:57 -0000 Date: Thu, 25 Sep 2003 08:00:56 -0400 From: Henrik Levkowetz To: Gopal Dommety Cc: "Adrangi, Farid" , "Jayshree Bharatia" , , Subject: Re: [Mip4] RE: Request for text proposal for your scenario Message-Id: <20030925080056.446e0920.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030924105620.027cb7a0@mira-sjcm-3.cisco.com> References: <96D13222E704DC4D868F0009F0EE53E10AC0DA@orsmsx410.jf.intel.com> <4.3.2.7.2.20030924105620.027cb7a0@mira-sjcm-3.cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.cpq0I._cbIYy3U" 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: , --=.cpq0I._cbIYy3U Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Wednesday 24 September 2003, Gopal wrote: > At 06:25 AM 9/24/2003 -0700, Adrangi, Farid wrote: > >Thanks Gopal. IMO, the scenario lacks some details. For example, > > > >1) does this scenario allow MN to work in non-colocated mode? That is, > > > >MN ---FA---VPN/FA ---Intranet > > > yes...But the figure you drew is not correct...It could be as follows.. > > > MN -----VPN/FA ---Intranet But that makes the MN have a Co-located careof address again. The question was, will it work in FA-registered mode? > > > >2) What is the role of FA on the VPN gateway? In other words, what is > >the difference between > > > >MN -----VPN/FA ------Intranet (your scenario) > >And > >MN -------VPN -------Intranet > > > FA can be optionally used for Mobility (I think you left out HA in your figure) > > >However, if others are okay with the text as it is, then I'll go ahead > >and add it. > > > >BR, > >Farid > > > > > >-----Original Message----- > >From: Gopal Dommety [mailto:gdommety@cisco.com] > >Sent: Tuesday, September 23, 2003 6:01 PM > >To: Adrangi, Farid; Jayshree Bharatia > >Cc: mccap@lucent.com; henrik@levkowetz.com; mip4@ietf.org > >Subject: RE: Request for text proposal for your scenario > > > > > >Farid, > > > >The text Jayshree sent looks good. I just made minor edits. Here is the > >text below: > > > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > . . . > > . +----+ +-----+ +-------+ +-------+ . > > . |MNs | | FA | | Router| | HAs | . > > . |away|<============>| + | | 1..n | | | . > > . | | | VPN | +-------+ +-------+ . > > . | | | GW | . > > . +----+ +-----+ +-------+ +-------+ . > > . . | CN | | MNs | . > > . . | 1..n | | home | . > > . . +-------+ +-------+ . > > . . . > > ........................................................ > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > >between the > >MN and the FA/VPN Gateway.This scenario > > IPsec being used to protect the data over the wireless network. > > > >For end-to-end security model, the VPN > >Gateway > >must > >protect the IP traffic originating at the MN. Since the point of > >attachment > >changes corresponding to the movement of the MN, it is essential that > >the > >VPN > >tunnel security association must be refreshed after each IP subnet > >handoff. > > > >Hence, this scenario is not practical > >where the mobility is involved for > >the > >real-time applications due to the performance implications. > > > > > >Thanks > >Gopal > > > > > > > > > > > >At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > > >Any update on this? What should we do next? > > >--Farid > > > > > >-----Original Message----- > > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > >Sent: Tuesday, September 16, 2003 11:02 AM > > >To: 'Gopal Dommety' > > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > > >Subject: RE: Request for text proposal for your scenario > > > > > >Gopal, > > > > > >Appreciate if you can make appropriate changes to the proposed text: > > > > > >Thanks, > > >Jayshree > > > > > >------------- > > >Proposed text: > > > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > > . . . > > > . +----+ +-----+ +-------+ +-------+ . > > > . |MNs | | FA | | Router| | HAs | . > > > . |away|<============>| + | | 1..n | | | . > > > . | | | VPN | +-------+ +-------+ . > > > . | | | GW | . > > > . +----+ +-----+ +-------+ +-------+ . > > > . . | CN | | MNs | . > > > . . | 1..n | | home | . > > > . . +-------+ +-------+ . > > > . . . > > > ........................................................ > > > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > >between > > >the > > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > > >Gateway > > >must > > >protect the IP traffic originating at the MN. Since the point of > > >attachment > > >changes corresponding to the movement of the MN, it is essential that > > >the > > >VPN > > >tunnel security association must be refreshed after each IP subnet > > >handoff. > > >Hence, this scenario is not practical where the mobility is involved > >for > > >the > > >real-time applications due to the performance implications. > > > > > > > > > > -----Original Message----- > > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Sent: Monday, September 15, 2003 4:39 PM > > > > To: 'Gopal Dommety'; Adrangi, Farid > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > Gopal, > > > > > > > > I was in the impression that you will modify the text. > > > > Anyway, I won't able to do much today but let me try tomorrow > > > > and send you the text... > > > > > > > > Regards, > > > > Jayshree > > > > > > > > > -----Original Message----- > > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > Jayshree, > > > > > > > > > > Can you massage the text that you sent to fit what I was > > > > referring to. > > > > > > > > > > -Gopal > > > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > > > >Hi Gopal, > > > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > > > >Maybe the best thing is that you and Jayshree propose a text that > > > > > >*clearly* articulates the scenario and its problems. > > > > Would that be > > > > > >possible? Thanks a bunch. BR, > > > > > >Farid > > > > > > > > > > > >-----Original Message----- > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > >Farid, > > > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > > interesting. The > > > > > >deployment scenarios of one hop and multiple hop solutions could > >be > > > > > >very > > > > > > > > > > > >different. > > > > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > > > >between the MN and VPN/FA. > > > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > > a FA. For > > > > > > >example, the following picture is not possible: > > > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > > picture can > > > > > >be > > > > > > >simplified as follows > > > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > > particular > > > > > > >established by different IPsec client software running on > > > > > the client > > > > > > >device!!! > > > > > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > > > >problem that we have is with SA refreshes when the MN > > > > changes its > > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > > > >BR, > > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > > access to the > > > > > > >visiting domain. > > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > > > >Thanks > > > > > > >Gopal > > > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > > between the > > > > > >MN > > > > > > >and > > > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > > > >discussed > > > > > > >in > > > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > > > >unprotected > > > > > > > >between these two entities. > > > > > > > > > > > > > > > >Regards, > > > > > > > >Jayshree > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > gdommety@cisco.com > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > > there is only > > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > > the foreign > > > > > > > > > and the VPN GW in the VPN domain. In other words, No > >IPsec > > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > > and hence > > > > > > > > > data traffic between the MN and the FA is not > > > > > protected. Is my > > > > > > > > > understanding correct? I will have more > >questions/comments > > > > > > > > > based on your answers. Thanks for the text and > > > > > hopefully we can > > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > >om > > > > > >] > > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > gdommety@cisco.com > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > > FA-VPN GW > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > > Jayshree > > > > > > > > > --------------------- > > > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > > same physical > > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > > >Domain..(Intranet).... > > > > > > > > > . . . > > > > > > >. > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > >+-------+ > > > > > > >. > > > > > > > > > . |MNs | | FA | . | VPN| | > > > > > Router| | HAs > > > > > >| > > > > > > >. > > > > > > > > > . |away| | + | .<=========>| GW | | 1..n | > >| > > > > > >| > > > > > > >. > > > > > > > > > . | | | VPN | . | | +-------+ > > > > > >+-------+ > > > > > > >. > > > > > > > > > . | | | GW | . | | > > > > > > >. > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > >+-------+ > > > > > > >. > > > > > > > > > . . . | CN > > > > > | | MNs > > > > > >| > > > > > > >. > > > > > > > > > .................... . | 1..n > > > > > | | home > > > > > >| > > > > > > >. > > > > > > > > > . +-------+ > > > > > >+-------+ > > > > > > >. > > > > > > > > > . > > > > > > >. > > > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > > the FA is > > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > > is running > > > > > > > > > inside the IPSec-ESP. For end-to-end security model, the > >VPN > > > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > > > originating at the MN. Since the point of > > > > attachment changes > > > > > > > > > corresponding to the movement of the MN, it is > > > > essential that > > > > > > > > > the VPN tunnel security association must be refreshed > > > > > after each > > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > > practical where > > > > > > > > > the mobility is involved due to performance > > > > > implications for the > > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > gdommety@cisco.com > > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > Could you please propose a text for the scenario > > > > > that you want > > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > >om > > > > > >] > > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Jayshree > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > > had a very > > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > > am not sure > > > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > > > include this scenario. To be frank, I don't quite > > > > > understand > > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > > - It seems to present a solution to a specific > > > > > > > > > > deployment model > > > > > > > > > > rather than a deployment scenario > > > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > > > elaborate what you mean by deployment model vs > >deployment > > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a > >combined > > > > > > > > > > VPN+FA if it > > > > > > > > > > does > > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > > regardless > > > > > > > > > > this scenario has any advantages or not, it is one of > >the > > > > > > > > > > probable scenario which has potential issues (as you > >have > > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > > the problem > > > > > > > > > > statement > > > > > > > > > > draft represents combinations of MIPv4 HA and VPN > >gateway > > > > > > > > > > placement - adding this scenario is going to change > > > > > semantics > > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > > semantics change here. Do you think documenting > > > > this in new > > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > > - I just > > > > > > > > > > wanted to make sure that we clearly understand the > > > > > reasons for > > > > > > > > > > adding this scenario to the problem statement > > > > draft. Design > > > > > > > > > > team members and interested individuals are welcome > > > > > to express > > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > > >representative > > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > >om > > > > > >] > > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > > understanding > > > > > > > > > > is that you will include the scenario of > > > > co-existed FA with > > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and > >it > > > > > > > > > > won't work if the MN is behind an FA in the > > > > foreign subnet. > > > > > > > > > > But again, this is a problem statement draft. > > > > > Hence, I believe > > > > > > > > > > that this is the appropriate document for mentioning > >this > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > >Hello > > > > > > > > > > Jayshree This is a good point - I knew someone > > > > was to bring > > > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > > > scenario would fall into a solution space. Maybe > > > > > we did not > > > > > > > > > > make the right decision and we should rethink this. > >But, > > > > > > > > > > before we take this discussion further please allow > > > > > me to ask > > > > > > > > > > you a few questions about the details of the > > > > > scenario (VPN+FA) > > > > > > > > > > that you have in mind . Are you thinking to broadcast > >FA > > > > > > > > > > advertisements through the IPsec tunnel to the > > > > MN? If so, > > > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > > > foreign subnet? Or, If you had something > > > > different in mind, > > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > >[> > > > > > >mailto:jayshree@nortelnetworks.c > > > > > > >om > > > > > >] > > > > > > >, > > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > This draft > > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > > currently misses one scenario were the FA is > > > > > co-existed with > > > > > > > > > > the VPN Gateway. I would think that there are no > >technical > > > > > > > > > > issues supporting this scenario. It will be good > > > > if you can > > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > > 2.6?) > > > > > > > > > > for completeness. > > > > > > > > > > Thanks, > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > >Mip4 mailing list > >Mip4@ietf.org > >https://www.ietf.org/mailman/listinfo/mip4 --=.cpq0I._cbIYy3U Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/ctj4eVhrtTJkXCMRAhoTAJ9IJMVa+k0DeU+ljBvuGvC8gB9yQwCg5Hsc uklT0ACY7l/8+FAbthWNeVU= =aWZ6 -----END PGP SIGNATURE----- --=.cpq0I._cbIYy3U-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 25 12:08: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 MAA02692 for ; Thu, 25 Sep 2003 12:08: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 1A2Yey-0002rh-MS for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 12:08:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PG84Fu011007 for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 12:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Yey-0002rS-FO for mip4-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 12:08: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 MAA02584 for ; Thu, 25 Sep 2003 12:07:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Yew-0000dt-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 12:08:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Yew-0000dp-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 12:08:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Yew-0002qr-TX; Thu, 25 Sep 2003 12:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2YeJ-0002gk-11 for mip4@optimus.ietf.org; Thu, 25 Sep 2003 12:07: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 MAA02545 for ; Thu, 25 Sep 2003 12:07:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2YeH-0000dL-00 for mip4@ietf.org; Thu, 25 Sep 2003 12:07:21 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2YeF-0000cR-00 for mip4@ietf.org; Thu, 25 Sep 2003 12:07:19 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 25 Sep 2003 09:09:49 -0700 Received: from gdommety-w2k01.cisco.com (sjc-vpn2-88.cisco.com [10.21.112.88]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h8PG6aYc010456; Thu, 25 Sep 2003 09:06:39 -0700 (PDT) Message-Id: <4.3.2.7.2.20030925090040.027f2cd0@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Sep 2003 09:06:33 -0700 To: Henrik Levkowetz From: Gopal Dommety Subject: Re: [Mip4] RE: Request for text proposal for your scenario Cc: "Adrangi, Farid" , "Jayshree Bharatia" , , In-Reply-To: <20030925080056.446e0920.henrik@levkowetz.com> References: <4.3.2.7.2.20030924105620.027cb7a0@mira-sjcm-3.cisco.com> <96D13222E704DC4D868F0009F0EE53E10AC0DA@orsmsx410.jf.intel.com> <4.3.2.7.2.20030924105620.027cb7a0@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , At 08:00 AM 9/25/2003 -0400, Henrik Levkowetz wrote: >Wednesday 24 September 2003, Gopal wrote: > > At 06:25 AM 9/24/2003 -0700, Adrangi, Farid wrote: > > >Thanks Gopal. IMO, the scenario lacks some details. For example, > > > > > >1) does this scenario allow MN to work in non-colocated mode? That is, > > > > > >MN ---FA---VPN/FA ---Intranet > > > > > > yes...But the figure you drew is not correct...It could be as follows.. > > > > > > MN -----VPN/FA ---Intranet > >But that makes the MN have a Co-located careof address again. The >question was, will it work in FA-registered mode? It will work in FA-CoA. MN can have a FA-CoA from a MIP standpoint. Outer most will be IPsec. Inside that is MIP. One way to achieve this is to send MIP advertisements in the IPsec tunnel and treat IPsec tunnel as a L2 Interface. Thanks Gopal > > > > > > >2) What is the role of FA on the VPN gateway? In other words, what is > > >the difference between > > > > > >MN -----VPN/FA ------Intranet (your scenario) > > >And > > >MN -------VPN -------Intranet > > > > > > FA can be optionally used for Mobility (I think you left out HA in your > figure) > > > > >However, if others are okay with the text as it is, then I'll go ahead > > >and add it. > > > > > >BR, > > >Farid > > > > > > > > >-----Original Message----- > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > >Sent: Tuesday, September 23, 2003 6:01 PM > > >To: Adrangi, Farid; Jayshree Bharatia > > >Cc: mccap@lucent.com; henrik@levkowetz.com; mip4@ietf.org > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > >Farid, > > > > > >The text Jayshree sent looks good. I just made minor edits. Here is the > > >text below: > > > > > > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > > . . . > > > . +----+ +-----+ +-------+ +-------+ . > > > . |MNs | | FA | | Router| | HAs | . > > > . |away|<============>| + | | 1..n | | | . > > > . | | | VPN | +-------+ +-------+ . > > > . | | | GW | . > > > . +----+ +-----+ +-------+ +-------+ . > > > . . | CN | | MNs | . > > > . . | 1..n | | home | . > > > . . +-------+ +-------+ . > > > . . . > > > ........................................................ > > > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > >between the > > >MN and the FA/VPN Gateway.This scenario > > > IPsec being used to protect the data over the wireless network. > > > > > >For end-to-end security model, the VPN > > >Gateway > > >must > > >protect the IP traffic originating at the MN. Since the point of > > >attachment > > >changes corresponding to the movement of the MN, it is essential that > > >the > > >VPN > > >tunnel security association must be refreshed after each IP subnet > > >handoff. > > > > > >Hence, this scenario is not practical > > >where the mobility is involved for > > >the > > >real-time applications due to the performance implications. > > > > > > > > >Thanks > > >Gopal > > > > > > > > > > > > > > > > > >At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > > > >Any update on this? What should we do next? > > > >--Farid > > > > > > > >-----Original Message----- > > > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > >Sent: Tuesday, September 16, 2003 11:02 AM > > > >To: 'Gopal Dommety' > > > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > >Gopal, > > > > > > > >Appreciate if you can make appropriate changes to the proposed text: > > > > > > > >Thanks, > > > >Jayshree > > > > > > > >------------- > > > >Proposed text: > > > > > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > > > . . . > > > > . +----+ +-----+ +-------+ +-------+ . > > > > . |MNs | | FA | | Router| | HAs | . > > > > . |away|<============>| + | | 1..n | | | . > > > > . | | | VPN | +-------+ +-------+ . > > > > . | | | GW | . > > > > . +----+ +-----+ +-------+ +-------+ . > > > > . . | CN | | MNs | . > > > > . . | 1..n | | home | . > > > > . . +-------+ +-------+ . > > > > . . . > > > > ........................................................ > > > > > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > > >between > > > >the > > > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > > > >Gateway > > > >must > > > >protect the IP traffic originating at the MN. Since the point of > > > >attachment > > > >changes corresponding to the movement of the MN, it is essential that > > > >the > > > >VPN > > > >tunnel security association must be refreshed after each IP subnet > > > >handoff. > > > >Hence, this scenario is not practical where the mobility is involved > > >for > > > >the > > > >real-time applications due to the performance implications. > > > > > > > > > > > > > -----Original Message----- > > > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Sent: Monday, September 15, 2003 4:39 PM > > > > > To: 'Gopal Dommety'; Adrangi, Farid > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > Gopal, > > > > > > > > > > I was in the impression that you will modify the text. > > > > > Anyway, I won't able to do much today but let me try tomorrow > > > > > and send you the text... > > > > > > > > > > Regards, > > > > > Jayshree > > > > > > > > > > > -----Original Message----- > > > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > Jayshree, > > > > > > > > > > > > Can you massage the text that you sent to fit what I was > > > > > referring to. > > > > > > > > > > > > -Gopal > > > > > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > > > > > >Hi Gopal, > > > > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > > > > >Maybe the best thing is that you and Jayshree propose a text that > > > > > > >*clearly* articulates the scenario and its problems. > > > > > Would that be > > > > > > >possible? Thanks a bunch. BR, > > > > > > >Farid > > > > > > > > > > > > > >-----Original Message----- > > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > >Farid, > > > > > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > > > interesting. The > > > > > > >deployment scenarios of one hop and multiple hop solutions could > > >be > > > > > > >very > > > > > > > > > > > > > >different. > > > > > > > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > > > > >between the MN and VPN/FA. > > > > > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > > > a FA. For > > > > > > > >example, the following picture is not possible: > > > > > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > > > picture can > > > > > > >be > > > > > > > >simplified as follows > > > > > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > > > particular > > > > > > > >established by different IPsec client software running on > > > > > > the client > > > > > > > >device!!! > > > > > > > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > > > > >problem that we have is with SA refreshes when the MN > > > > > changes its > > > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > > > > > >BR, > > > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > > > access to the > > > > > > > >visiting domain. > > > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > > > > > >Thanks > > > > > > > >Gopal > > > > > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > > > between the > > > > > > >MN > > > > > > > >and > > > > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > > > > >discussed > > > > > > > >in > > > > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > > > > >unprotected > > > > > > > > >between these two entities. > > > > > > > > > > > > > > > > > >Regards, > > > > > > > > >Jayshree > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > gdommety@cisco.com > > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > > > there is only > > > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > > > the foreign > > > > > > > > > > and the VPN GW in the VPN domain. In other words, No > > >IPsec > > > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > > > and hence > > > > > > > > > > data traffic between the MN and the FA is not > > > > > > protected. Is my > > > > > > > > > > understanding correct? I will have more > > >questions/comments > > > > > > > > > > based on your answers. Thanks for the text and > > > > > > hopefully we can > > > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > > >om > > > > > > >] > > > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > gdommety@cisco.com > > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > > > FA-VPN GW > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > > > Jayshree > > > > > > > > > > --------------------- > > > > > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > > > same physical > > > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > > > >Domain..(Intranet).... > > > > > > > > > > . . . > > > > > > > >. > > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > > >+-------+ > > > > > > > >. > > > > > > > > > > . |MNs | | FA | . | VPN| | > > > > > > Router| | HAs > > > > > > >| > > > > > > > >. > > > > > > > > > > . |away| | + | .<=========>| GW | | 1..n | > > >| > > > > > > >| > > > > > > > >. > > > > > > > > > > . | | | VPN | . | | +-------+ > > > > > > >+-------+ > > > > > > > >. > > > > > > > > > > . | | | GW | . | | > > > > > > > >. > > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > > >+-------+ > > > > > > > >. > > > > > > > > > > . . . | CN > > > > > > | | MNs > > > > > > >| > > > > > > > >. > > > > > > > > > > .................... . | 1..n > > > > > > | | home > > > > > > >| > > > > > > > >. > > > > > > > > > > . +-------+ > > > > > > >+-------+ > > > > > > > >. > > > > > > > > > > . > > > > > > > >. > > > > > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > > > the FA is > > > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > > > is running > > > > > > > > > > inside the IPSec-ESP. For end-to-end security model, the > > >VPN > > > > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > > > > originating at the MN. Since the point of > > > > > attachment changes > > > > > > > > > > corresponding to the movement of the MN, it is > > > > > essential that > > > > > > > > > > the VPN tunnel security association must be refreshed > > > > > > after each > > > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > > > practical where > > > > > > > > > > the mobility is involved due to performance > > > > > > implications for the > > > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > > gdommety@cisco.com > > > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > > Could you please propose a text for the scenario > > > > > > that you want > > > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > > >om > > > > > > >] > > > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Jayshree > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > > > had a very > > > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > > > am not sure > > > > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > > > > include this scenario. To be frank, I don't quite > > > > > > understand > > > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > > > - It seems to present a solution to a specific > > > > > > > > > > > deployment model > > > > > > > > > > > rather than a deployment scenario > > > > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > > > > elaborate what you mean by deployment model vs > > >deployment > > > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a > > >combined > > > > > > > > > > > VPN+FA if it > > > > > > > > > > > does > > > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > > > regardless > > > > > > > > > > > this scenario has any advantages or not, it is one of > > >the > > > > > > > > > > > probable scenario which has potential issues (as you > > >have > > > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > > > the problem > > > > > > > > > > > statement > > > > > > > > > > > draft represents combinations of MIPv4 HA and VPN > > >gateway > > > > > > > > > > > placement - adding this scenario is going to change > > > > > > semantics > > > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > > > semantics change here. Do you think documenting > > > > > this in new > > > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > > > - I just > > > > > > > > > > > wanted to make sure that we clearly understand the > > > > > > reasons for > > > > > > > > > > > adding this scenario to the problem statement > > > > > draft. Design > > > > > > > > > > > team members and interested individuals are welcome > > > > > > to express > > > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > > > >representative > > > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > > > >om > > > > > > >] > > > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > > > understanding > > > > > > > > > > > is that you will include the scenario of > > > > > co-existed FA with > > > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and > > >it > > > > > > > > > > > won't work if the MN is behind an FA in the > > > > > foreign subnet. > > > > > > > > > > > But again, this is a problem statement draft. > > > > > > Hence, I believe > > > > > > > > > > > that this is the appropriate document for mentioning > > >this > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > >Hello > > > > > > > > > > > Jayshree This is a good point - I knew someone > > > > > was to bring > > > > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > > > > scenario would fall into a solution space. Maybe > > > > > > we did not > > > > > > > > > > > make the right decision and we should rethink this. > > >But, > > > > > > > > > > > before we take this discussion further please allow > > > > > > me to ask > > > > > > > > > > > you a few questions about the details of the > > > > > > scenario (VPN+FA) > > > > > > > > > > > that you have in mind . Are you thinking to broadcast > > >FA > > > > > > > > > > > advertisements through the IPsec tunnel to the > > > > > MN? If so, > > > > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > > > > foreign subnet? Or, If you had something > > > > > different in mind, > > > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > >[> > > > > > > >mailto:jayshree@nortelnetworks.c > > > > > > > >om > > > > > > >] > > > > > > > >, > > > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > This draft > > > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > > > currently misses one scenario were the FA is > > > > > > co-existed with > > > > > > > > > > > the VPN Gateway. I would think that there are no > > >technical > > > > > > > > > > > issues supporting this scenario. It will be good > > > > > if you can > > > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > > > 2.6?) > > > > > > > > > > > for completeness. > > > > > > > > > > > Thanks, > > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > >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 Sep 25 12:16: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 MAA03159 for ; Thu, 25 Sep 2003 12:16: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 1A2Ymh-0003NR-Fw for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 12:16:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PGG3LA012975 for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 12:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ymh-0003Ml-8x for mip4-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 12:16: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 MAA03137 for ; Thu, 25 Sep 2003 12:15:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ymf-0000kM-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 12:16:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2Ymf-0000kJ-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 12:16:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Ymf-0003M3-V3; Thu, 25 Sep 2003 12:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2Yly-0003L4-Fz for mip4@optimus.ietf.org; Thu, 25 Sep 2003 12:15: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 MAA03104 for ; Thu, 25 Sep 2003 12:15:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2Ylw-0000ji-00 for mip4@ietf.org; Thu, 25 Sep 2003 12:15:16 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A2Ylv-0000jI-00 for mip4@ietf.org; Thu, 25 Sep 2003 12:15:15 -0400 Received: from gdommety-w2k01.cisco.com (sjc-vpn2-88.cisco.com [10.21.112.88]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8PGEXxX019419; Thu, 25 Sep 2003 09:14:36 -0700 (PDT) Message-Id: <4.3.2.7.2.20030925090715.028724c8@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Sep 2003 09:14:29 -0700 To: Henrik Levkowetz From: Gopal Dommety Subject: Re: [Mip4] Re: Request for text proposal for your scenario Cc: "Adrangi, Farid" , Jayshree Bharatia , mccap@lucent.com, mip4@ietf.org In-Reply-To: <20030925075852.65bd94e6.henrik@levkowetz.com> References: <4.3.2.7.2.20030924105150.027979b8@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> <96D13222E704DC4D868F0009F0EE53E10AC321@orsmsx410.jf.intel.com> <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030924105150.027979b8@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , At 07:58 AM 9/25/2003 -0400, Henrik Levkowetz wrote: >Hi Gopal, > >Wednesday 24 September 2003, Gopal wrote: > > I think you are thinking "remote access". Think of it as using IPsec > > instead of L2 encryption in 802.11 > > case with IPsec terminating at the edge and FA/HA proving mobility. > >I only say that there is much more text required to explain >this scenario. I'm still not sure I understand it, and I definitely >don't have any understanding of what it contributes to the problem >statement. I think Jayshree and myelf will re-do the write up to provide more details.I will re-do the writeup and send it again. >More comments below. > > > At 09:30 AM 9/24/2003 -0400, Henrik Levkowetz wrote: > > >Hi Gopal and Jayshree, > > > > > > So, I think we still need some changes in this text, because to > > >be frank I still don't understand this. The figure below shows the > > >VPN domain and the forign network as being adjacent, with no internet > > >in between; is that right? In that case, it seems to me this is a > > >roaming within the corporate network scenario, rather than a general > > >roaming scenario. > >I still miss an answer to above question. Sorry, I thought my later comment addressed this. This pertains more to the corporate network sceanrio. I will re-write the section and send it out. > > >Second, the handovers referred to, are these between different FA's > > >in the corporate network, or going out to the public internet? > > > > within the corporate network. when dealing with the public internet it is > > more involved and yet another layer. > >Ok, then the text needs to point out that, and also explain why we are >looking at this case at all. Will make changes to the text. > > >Third, this scenario seems very contrieved, (but this is maybe > > >because I dont't really understand it?) - it seems to me we could > > >scare up 20 different unrealistic scenarios of the same sort, so > > >I don't understand why we want to pick and include this particular > > >one at all?? It seems to me that adding this scenario makes the > > >draft more confusing rather than more understandable. > > > > Hopefully mis-understanding and less contrived :-) > >I'm still not convinced. *Please* provide text which actually >communicates what this is all about to the un-initiated reader. I think Jayshree and myelf will re-do the write up to provide more details.I will re-do the writeup and send it again. Thanks Gopal > Henrik > > > > -Gopal > > > > > > > Henrik > > > > > >Tuesday 23 September 2003, Gopal wrote: > > > > > > > > Farid, > > > > > > > > The text Jayshree sent looks good. I just made minor edits. Here is the > > > > text below: > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > > > . . . > > > > . +----+ +-----+ +-------+ +-------+ . > > > > . |MNs | | FA | | Router| | HAs | . > > > > . |away|<============>| + | | 1..n | | | . > > > > . | | | VPN | +-------+ +-------+ . > > > > . | | | GW | . > > > > . +----+ +-----+ +-------+ +-------+ . > > > > . . | CN | | MNs | . > > > > . . | 1..n | | home | . > > > > . . +-------+ +-------+ . > > > > . . . > > > > ........................................................ > > > > > > > > In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > > > between the > > > > MN and the FA/VPN Gateway.This scenario > > > > IPsec being used to protect the data over the wireless network. > > > > > > > > For end-to-end security model, the VPN > > > > Gateway > > > > must > > > > protect the IP traffic originating at the MN. Since the point of > > > > attachment > > > > changes corresponding to the movement of the MN, it is essential that > > > > the > > > > VPN > > > > tunnel security association must be refreshed after each IP subnet > > > > handoff. > > > > > > > > Hence, this scenario is not practical > > > > where the mobility is involved for > > > > the > > > > real-time applications due to the performance implications. > > > > > > > > > > > > Thanks > > > > Gopal > > > > > > > > > > > > > > > > > > > > > > > > At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > > > > >Any update on this? What should we do next? > > > > >--Farid > > > > > > > > > >-----Original Message----- > > > > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > >Sent: Tuesday, September 16, 2003 11:02 AM > > > > >To: 'Gopal Dommety' > > > > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > >Gopal, > > > > > > > > > >Appreciate if you can make appropriate changes to the proposed text: > > > > > > > > > >Thanks, > > > > >Jayshree > > > > > > > > > >------------- > > > > >Proposed text: > > > > > > > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > > > > > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > > > > . . . > > > > > . +----+ +-----+ +-------+ +-------+ . > > > > > . |MNs | | FA | | Router| | HAs | . > > > > > . |away|<============>| + | | 1..n | | | . > > > > > . | | | VPN | +-------+ +-------+ . > > > > > . | | | GW | . > > > > > . +----+ +-----+ +-------+ +-------+ . > > > > > . . | CN | | MNs | . > > > > > . . | 1..n | | home | . > > > > > . . +-------+ +-------+ . > > > > > . . . > > > > > ........................................................ > > > > > > > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > > > > >between > > > > >the > > > > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > > > > >Gateway > > > > >must > > > > >protect the IP traffic originating at the MN. Since the point of > > > > >attachment > > > > >changes corresponding to the movement of the MN, it is essential that > > > > >the > > > > >VPN > > > > >tunnel security association must be refreshed after each IP subnet > > > > >handoff. > > > > >Hence, this scenario is not practical where the mobility is > involved for > > > > >the > > > > >real-time applications due to the performance implications. > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > Sent: Monday, September 15, 2003 4:39 PM > > > > > > To: 'Gopal Dommety'; Adrangi, Farid > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > Gopal, > > > > > > > > > > > > I was in the impression that you will modify the text. > > > > > > Anyway, I won't able to do much today but let me try tomorrow > > > > > > and send you the text... > > > > > > > > > > > > Regards, > > > > > > Jayshree > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > Jayshree, > > > > > > > > > > > > > > Can you massage the text that you sent to fit what I was > > > > > > referring to. > > > > > > > > > > > > > > -Gopal > > > > > > > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > > > > > > > >Hi Gopal, > > > > > > > >Ok. I guess my interpretation of your scenario was not > accurate! > > > > > > > >Maybe the best thing is that you and Jayshree propose a text > that > > > > > > > >*clearly* articulates the scenario and its problems. > > > > > > Would that be > > > > > > > >possible? Thanks a bunch. BR, > > > > > > > >Farid > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > >Farid, > > > > > > > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > > > > interesting. The > > > > > > > >deployment scenarios of one hop and multiple hop solutions > could be > > > > > > > >very > > > > > > > > > > > > > > > >different. > > > > > > > > > > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel > established > > > > > > > > >between the MN and VPN/FA. > > > > > > > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > > > > a FA. For > > > > > > > > >example, the following picture is not possible: > > > > > > > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > > > > picture can > > > > > > > >be > > > > > > > > >simplified as follows > > > > > > > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > > > > particular > > > > > > > > >established by different IPsec client software running on > > > > > > > the client > > > > > > > > >device!!! > > > > > > > > > > > > > > > > > >So, since the scenario does not support #3 above, then the > only > > > > > > > > >problem that we have is with SA refreshes when the MN > > > > > > changes its > > > > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > > > > > > > >BR, > > > > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > > > > access to the > > > > > > > > >visiting domain. > > > > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > > > > > > > >Thanks > > > > > > > > >Gopal > > > > > > > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > > > > between the > > > > > > > >MN > > > > > > > > >and > > > > > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > > > > > >discussed > > > > > > > > >in > > > > > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > > > > > >unprotected > > > > > > > > > >between these two entities. > > > > > > > > > > > > > > > > > > > >Regards, > > > > > > > > > >Jayshree > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > > gdommety@cisco.com > > > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > > > > there is only > > > > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > > > > the foreign > > > > > > > > > > > and the VPN GW in the VPN domain. In other words, No > IPsec > > > > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > > > > and hence > > > > > > > > > > > data traffic between the MN and the FA is not > > > > > > > protected. Is my > > > > > > > > > > > understanding correct? I will have more > questions/comments > > > > > > > > > > > based on your answers. Thanks for the text and > > > > > > > hopefully we can > > > > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetw > orks.c > > > > > > > > >om > > > > > > > >] > > > > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > > gdommety@cisco.com > > > > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > > > > FA-VPN GW > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > > > > Jayshree > > > > > > > > > > > --------------------- > > > > > > > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > > > > same physical > > > > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > > > > >Domain..(Intranet).... > > > > > > > > > > > . . . > > > > > > > > >. > > > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > > > >+-------+ > > > > > > > > >. > > > > > > > > > > > . |MNs | | FA | . | VPN| | > > > > > > > Router| | HAs > > > > > > > >| > > > > > > > > >. > > > > > > > > > > > . |away| | + | .<=========>| GW | | > 1..n | | > > > > > > > >| > > > > > > > > >. > > > > > > > > > > > . | | | VPN | . | | +-------+ > > > > > > > >+-------+ > > > > > > > > >. > > > > > > > > > > > . | | | GW | . | | > > > > > > > > >. > > > > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > > > > >+-------+ > > > > > > > > >. > > > > > > > > > > > . . . | CN > > > > > > > | | MNs > > > > > > > >| > > > > > > > > >. > > > > > > > > > > > .................... . | 1..n > > > > > > > | | home > > > > > > > >| > > > > > > > > >. > > > > > > > > > > > . +-------+ > > > > > > > >+-------+ > > > > > > > > >. > > > > > > > > > > > . > > > > > > > > >. > > > > > > > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > > > > the FA is > > > > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > > > > is running > > > > > > > > > > > inside the IPSec-ESP. For end-to-end security model, > the VPN > > > > > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > > > > > originating at the MN. Since the point of > > > > > > attachment changes > > > > > > > > > > > corresponding to the movement of the MN, it is > > > > > > essential that > > > > > > > > > > > the VPN tunnel security association must be refreshed > > > > > > > after each > > > > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > > > > practical where > > > > > > > > > > > the mobility is involved due to performance > > > > > > > implications for the > > > > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > > > > gdommety@cisco.com > > > > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > > > Could you please propose a text for the scenario > > > > > > > that you want > > > > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetw > orks.c > > > > > > > > >om > > > > > > > >] > > > > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jayshree > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > > > > had a very > > > > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > > > > am not sure > > > > > > > > > > > > if we derived any conclusion on whether or not we > should > > > > > > > > > > > > include this scenario. To be frank, I don't quite > > > > > > > understand > > > > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > > > > - It seems to present a solution to a specific > > > > > > > > > > > > deployment model > > > > > > > > > > > > rather than a deployment scenario > > > > > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > > > > > elaborate what you mean by deployment model vs > deployment > > > > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a > combined > > > > > > > > > > > > VPN+FA if it > > > > > > > > > > > > does > > > > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > > > > renegotiation when MN moves from one subnet to > another - > > > > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > > > > regardless > > > > > > > > > > > > this scenario has any advantages or not, it is one > of the > > > > > > > > > > > > probable scenario which has potential issues (as > you have > > > > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > > > > the problem > > > > > > > > > > > > statement > > > > > > > > > > > > draft represents combinations of MIPv4 HA and VPN > gateway > > > > > > > > > > > > placement - adding this scenario is going to change > > > > > > > semantics > > > > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > > > > semantics change here. Do you think documenting > > > > > > this in new > > > > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > > > > - I just > > > > > > > > > > > > wanted to make sure that we clearly understand the > > > > > > > reasons for > > > > > > > > > > > > adding this scenario to the problem statement > > > > > > draft. Design > > > > > > > > > > > > team members and interested individuals are welcome > > > > > > > to express > > > > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > > > > >representative > > > > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetw > orks.c > > > > > > > > >om > > > > > > > >] > > > > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > > > > To: Adrangi, Farid > > > > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > > > > understanding > > > > > > > > > > > > is that you will include the scenario of > > > > > > co-existed FA with > > > > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems > and it > > > > > > > > > > > > won't work if the MN is behind an FA in the > > > > > > foreign subnet. > > > > > > > > > > > > But again, this is a problem statement draft. > > > > > > > Hence, I believe > > > > > > > > > > > > that this is the appropriate document for > mentioning this > > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > > > Subject: RE: Comments on VPN Problem Statement > Draft Hello > > > > > > > > > > > > Jayshree This is a good point - I knew someone > > > > > > was to bring > > > > > > > > > > > > this up! At the time of writing these scenarios, we > (the > > > > > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > > > > > scenario would fall into a solution space. Maybe > > > > > > > we did not > > > > > > > > > > > > make the right decision and we should rethink > this. But, > > > > > > > > > > > > before we take this discussion further please allow > > > > > > > me to ask > > > > > > > > > > > > you a few questions about the details of the > > > > > > > scenario (VPN+FA) > > > > > > > > > > > > that you have in mind . Are you thinking to > broadcast FA > > > > > > > > > > > > advertisements through the IPsec tunnel to the > > > > > > MN? If so, > > > > > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > > > > > foreign subnet? Or, If you had something > > > > > > different in mind, > > > > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > > > > > > >[> > > > > > > > >mailto:jayshree@nortelnetworks.c > > > > > > > > >om > > > > > > > >] > > > > > > > > >, > > > > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > This draft > > > > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > > > > currently misses one scenario were the FA is > > > > > > > co-existed with > > > > > > > > > > > > the VPN Gateway. I would think that there are no > technical > > > > > > > > > > > > issues supporting this scenario. It will be good > > > > > > if you can > > > > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > > > > 2.6?) > > > > > > > > > > > > for completeness. > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Sep 25 12:49: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 MAA05308 for ; Thu, 25 Sep 2003 12:49: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 1A2ZIc-0005SL-PC for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 12:49:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8PGn26n020967 for mip4-archive@odin.ietf.org; Thu, 25 Sep 2003 12:49:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZIc-0005RM-HY for mip4-web-archive@optimus.ietf.org; Thu, 25 Sep 2003 12:49: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 MAA05231 for ; Thu, 25 Sep 2003 12:48:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZIa-0001RO-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 12:49:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A2ZIa-0001RL-00 for mip4-web-archive@ietf.org; Thu, 25 Sep 2003 12:49:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZIb-0005QL-K5; Thu, 25 Sep 2003 12:49:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A2ZIF-0005OT-VA for mip4@optimus.ietf.org; Thu, 25 Sep 2003 12:48:40 -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 MAA05186 for ; Thu, 25 Sep 2003 12:48:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A2ZIE-0001QX-00 for mip4@ietf.org; Thu, 25 Sep 2003 12:48:38 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A2ZID-0001QP-00 for mip4@ietf.org; Thu, 25 Sep 2003 12:48:37 -0400 Received: (qmail 1637 invoked from network); 25 Sep 2003 16:48:33 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 25 Sep 2003 16:48:33 -0000 Date: Thu, 25 Sep 2003 18:48:10 +0200 From: Henrik Levkowetz To: Gopal Dommety Cc: "Adrangi, Farid" , Jayshree Bharatia , mccap@lucent.com, mip4@ietf.org Subject: Re: [Mip4] Re: Request for text proposal for your scenario Message-Id: <20030925184810.0ade9aa8.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030925090715.028724c8@mira-sjcm-3.cisco.com> References: <4.3.2.7.2.20030924105150.027979b8@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> <96D13222E704DC4D868F0009F0EE53E10AC321@orsmsx410.jf.intel.com> <4.3.2.7.2.20030923175923.0284fe80@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030924105150.027979b8@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030925090715.028724c8@mira-sjcm-3.cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.w9JM/OdNCNEYVv" 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: , --=.w9JM/OdNCNEYVv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Gopal, Thursday 25 September 2003, Gopal wrote (multiple times!): > I think Jayshree and myelf will re-do the write up to provide more > details.I will re-do the writeup and send it again. Ok, I think even I understand that you'll re-do the writeup to provide more details, and send it again :-)) Thanks, Henrik --=.w9JM/OdNCNEYVv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/cxxgeVhrtTJkXCMRAiB7AJ9X4FpBW/kJNl+n9lsqe5JbR8n4ygCgopdD Qv+UfmvRP3PP20RmVXWbloU= =lods -----END PGP SIGNATURE----- --=.w9JM/OdNCNEYVv-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 29 03:36:33 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 DAA29344 for ; Mon, 29 Sep 2003 03:36: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 1A3sZj-0003Ir-Js for mip4-archive@odin.ietf.org; Mon, 29 Sep 2003 03:36:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8T7a7HR012691 for mip4-archive@odin.ietf.org; Mon, 29 Sep 2003 03:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3sZj-0003Ic-2y for mip4-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 03:36: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 DAA29304 for ; Mon, 29 Sep 2003 03:36:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3sZg-00028e-00 for mip4-web-archive@ietf.org; Mon, 29 Sep 2003 03:36:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3sZg-00028a-00 for mip4-web-archive@ietf.org; Mon, 29 Sep 2003 03:36:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3sZe-0003FQ-80; Mon, 29 Sep 2003 03:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3sZB-0003ET-QE for mip4@optimus.ietf.org; Mon, 29 Sep 2003 03:35:36 -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 DAA29291 for ; Mon, 29 Sep 2003 03:35:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3sZ9-00028J-00 for mip4@ietf.org; Mon, 29 Sep 2003 03:35:31 -0400 Received: from hermes.py.intel.com ([146.152.216.3]) by ietf-mx with esmtp (Exim 4.12) id 1A3sZ8-000284-00 for mip4@ietf.org; Mon, 29 Sep 2003 03:35:30 -0400 Received: from petasus.py.intel.com (petasus.py.intel.com [146.152.221.4]) by hermes.py.intel.com (8.11.6-20030918-01/8.11.6/d: outer.mc,v 1.83 2003/09/05 14:45:27 rfjohns1 Exp $) with ESMTP id h8T7U4s04053 for ; Mon, 29 Sep 2003 07:30:04 GMT Received: from orsmsxvs041.jf.intel.com (orsmsxvs041.jf.intel.com [192.168.65.54]) by petasus.py.intel.com (8.11.6-20030918-01/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h8T7YV523798 for ; Mon, 29 Sep 2003 07:34:31 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs041.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003092900345724404 ; Mon, 29 Sep 2003 00:34:57 -0700 Received: from orsmsx410.amr.corp.intel.com ([192.168.65.64]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 29 Sep 2003 00:34:57 -0700 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Subject: RE: [Mip4] RE: Request for text proposal for your scenario Date: Mon, 29 Sep 2003 00:34:57 -0700 Message-ID: <96D13222E704DC4D868F0009F0EE53E10AC0E7@orsmsx410.jf.intel.com> Thread-Topic: [Mip4] RE: Request for text proposal for your scenario Thread-Index: AcOCxX1znoC65gZgRcWAmrn4FIdr5wDk412w From: "Adrangi, Farid" To: "Gopal Dommety" , "Jayshree Bharatia" Cc: , , X-OriginalArrivalTime: 29 Sep 2003 07:34:57.0636 (UTC) FILETIME=[2EC63240:01C3865C] Content-Transfer-Encoding: quoted-printable Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Gopal Dommety [mailto:gdommety@cisco.com]=20 Sent: Wednesday, September 24, 2003 10:58 AM To: Adrangi, Farid; Jayshree Bharatia Cc: mccap@lucent.com; henrik@levkowetz.com; mip4@ietf.org Subject: Re: [Mip4] RE: Request for text proposal for your scenario At 06:25 AM 9/24/2003 -0700, Adrangi, Farid wrote: >Thanks Gopal. IMO, the scenario lacks some details. For example, > >1) does this scenario allow MN to work in non-colocated mode? That is, > >MN ---FA---VPN/FA ---Intranet yes...But the figure you drew is not correct...It could be as follows.. MN -----VPN/FA ---Intranet Farid> The figure that I drew makes sense if you assume that MN can be attached to the Internet. Actually, I should've drawn like this: MN---FA---Internet---VPN/FA ---Intranet But, reading other mails, I guess your scenario covers only corporate networks so you should make that very clear in your proposed text. >2) What is the role of FA on the VPN gateway? In other words, what is >the difference between > >MN -----VPN/FA ------Intranet (your scenario) >And >MN -------VPN -------Intranet FA can be optionally used for Mobility (I think you left out HA in your figure) Farid> Ok, I left out HA in the above diagram. But, the question is that how does FA help with mobility here? =20 >However, if others are okay with the text as it is, then I'll go ahead >and add it. > >BR, >Farid > > >-----Original Message----- >From: Gopal Dommety [mailto:gdommety@cisco.com] >Sent: Tuesday, September 23, 2003 6:01 PM >To: Adrangi, Farid; Jayshree Bharatia >Cc: mccap@lucent.com; henrik@levkowetz.com; mip4@ietf.org >Subject: RE: Request for text proposal for your scenario > > >Farid, > >The text Jayshree sent looks good. I just made minor edits. Here is the >text below: > > >2.6 Combined VPN Gateway and MIPv4 FA > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > ..Foreign Network............VPN Domain..(Intranet)..... > . . . > . +----+ +-----+ +-------+ +-------+ . > . |MNs | | FA | | Router| | HAs | . > . |away|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| + | | 1..n = | | | . > . | | | VPN | +-------+ +-------+ . > . | | | GW | . > . +----+ +-----+ +-------+ +-------+ . > . . | CN | | MNs | . > . . | 1..n | | home | . > . . +-------+ +-------+ . > . . . > ........................................................ > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP >between the >MN and the FA/VPN Gateway.This scenario > IPsec being used to protect the data over the wireless network. > >For end-to-end security model, the VPN >Gateway >must >protect the IP traffic originating at the MN. Since the point of >attachment >changes corresponding to the movement of the MN, it is essential that >the >VPN >tunnel security association must be refreshed after each IP subnet >handoff. > >Hence, this scenario is not practical >where the mobility is involved for >the >real-time applications due to the performance implications. > > >Thanks >Gopal > > > > > >At 03:22 PM 9/23/2003 -0700, Adrangi, Farid wrote: > >Any update on this? What should we do next? > >--Farid > > > >-----Original Message----- > >From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > >Sent: Tuesday, September 16, 2003 11:02 AM > >To: 'Gopal Dommety' > >Cc: 'mccap@lucent.com'; 'henrik@levkowetz.com'; Adrangi, Farid > >Subject: RE: Request for text proposal for your scenario > > > >Gopal, > > > >Appreciate if you can make appropriate changes to the proposed text: > > > >Thanks, > >Jayshree > > > >------------- > >Proposed text: > > > >2.6 Combined VPN Gateway and MIPv4 FA > > > >MIPv4 FA and the VPN Gateway are running on the same physical machine. > > > > > > ..Foreign Network............VPN Domain..(Intranet)..... > > . . . > > . +----+ +-----+ +-------+ +-------+ . > > . |MNs | | FA | | Router| | HAs | . > > . |away|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| + | | = 1..n | | | . > > . | | | VPN | +-------+ +-------+ . > > . | | | GW | . > > . +----+ +-----+ +-------+ +-------+ . > > . . | CN | | MNs | . > > . . | 1..n | | home | . > > . . +-------+ +-------+ . > > . . . > > ........................................................ > > > >In this scenario, the mipv4 tunnel is running inside the IPSec-ESP > >between > >the > >MN and the FA/VPN Gateway. For end-to-end security model, the VPN > >Gateway > >must > >protect the IP traffic originating at the MN. Since the point of > >attachment > >changes corresponding to the movement of the MN, it is essential that > >the > >VPN > >tunnel security association must be refreshed after each IP subnet > >handoff. > >Hence, this scenario is not practical where the mobility is involved >for > >the > >real-time applications due to the performance implications. > > > > > > > -----Original Message----- > > > From: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Sent: Monday, September 15, 2003 4:39 PM > > > To: 'Gopal Dommety'; Adrangi, Farid > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > Gopal, > > > > > > I was in the impression that you will modify the text. > > > Anyway, I won't able to do much today but let me try tomorrow > > > and send you the text... > > > > > > Regards, > > > Jayshree > > > > > > > -----Original Message----- > > > > From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > Sent: Monday, September 15, 2003 2:03 PM > > > > To: Adrangi, Farid; Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: mccap@lucent.com; henrik@levkowetz.com > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > Jayshree, > > > > > > > > Can you massage the text that you sent to fit what I was > > > referring to. > > > > > > > > -Gopal > > > > > > > > At 04:08 PM 9/11/2003 -0700, Adrangi, Farid wrote: > > > > > > > > >Hi Gopal, > > > > >Ok. I guess my interpretation of your scenario was not accurate! > > > > >Maybe the best thing is that you and Jayshree propose a text that > > > > >*clearly* articulates the scenario and its problems. > > > Would that be > > > > >possible? Thanks a bunch. BR, > > > > >Farid > > > > > > > > > >-----Original Message----- > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > >Sent: Thursday, September 11, 2003 3:43 PM > > > > >To: Adrangi, Farid; Jayshree Bharatia > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > >Farid, > > > > > > > > > >I am not suggesting a solution. I am confused by your > > > > >inferences...comments inline to the best of my confusion. > > > > > > > > > > > > > > > >1) MN may be several hops away from the VPN/FA > > > > > > > > > >I was talking about one hop away. the multiple hops is > > > > interesting. The > > > > >deployment scenarios of one hop and multiple hop solutions could >be > > > > >very > > > > > > > > > >different. > > > > > > > > > > > > > > > >2) FA advertisement is done inside the IPsec tunnel established > > > > > >between the MN and VPN/FA. > > > > > > > > > >It is possible.. but then we are going into solution space. > > > > > > > > > > >3) MN roaming in a foreign network cannot be place behind > > > > a FA. For > > > > > >example, the following picture is not possible: > > > > > > > > > > > >MN ---FA----one or hops----FA/VPN1 > > > > > > > > > > > >4) VPN1/FA could also be your remote access VPN. So, the > > > > picture can > > > > >be > > > > > >simplified as follows > > > > > > > > > > > >MN ----one or more hops -----FA/VPN ---Intranet > > > > > > > > > > > >Note: I get frighten when I see nested IPsec tunnels, in > > > > particular > > > > > >established by different IPsec client software running on > > > > the client > > > > > >device!!! > > > > > > > > > > > >So, since the scenario does not support #3 above, then the only > > > > > >problem that we have is with SA refreshes when the MN > > > changes its > > > > > >point of attachment. Is my understanding correct? > > > > > > > > > > > >BR, > > > > > >FArid > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: Gopal Dommety [mailto:gdommety@cisco.com] > > > > > >Sent: Thursday, September 11, 2003 10:58 AM > > > > > >To: Jayshree Bharatia; Adrangi, Farid > > > > > >Cc: mccap@lucent.com; henrik@levkowetz.com > > > > > >Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > >Hello Farid, Henrick and Jayashree, > > > > > > > > > > > >the scenario I was referring to is as followis: > > > > > > > > > > > >MN---------|VPN/FA|-----------------[VPN2]---------HA > > > > > > > > > > > >VPN1 Provides Encryption/decryption for the link and > > > access to the > > > > > >visiting domain. > > > > > >VPN 2 is optional for remote access. > > > > > > > > > > > >Thanks > > > > > >Gopal > > > > > > > > > > > >At 10:52 AM 9/11/2003 -0500, Jayshree Bharatia wrote: > > > > > > > > > > > > >Hello Farid, > > > > > > > > > > > > > >I would think that there may or may not be IPSec tunnel > > > > between the > > > > >MN > > > > > >and > > > > > > >the FA/VPN. If there is, than it will have similar issue as > > > > > > >discussed > > > > > >in > > > > > > >the proposed text. If there is no IPSec, the traffic will be > > > > > >unprotected > > > > > > >between these two entities. > > > > > > > > > > > > > >Regards, > > > > > > >Jayshree > > > > > > > > -----Original Message----- > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > Sent: Wednesday, September 10, 2003 4:32 PM > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > Thanks Jayshree. Couple of clarifications: > > > > > > > > > > > > > > > > From your description, it is my understanding that > > > > there is only > > > > > > > > one IPsec tunnel, and that is between the FA/VPN in > > > > the foreign > > > > > > > > and the VPN GW in the VPN domain. In other words, No >IPsec > > > > > > > > tunnel between the MN and the VPN GW in VPN domain > > > and hence > > > > > > > > data traffic between the MN and the FA is not > > > > protected. Is my > > > > > > > > understanding correct? I will have more >questions/comments > > > > > > > > based on your answers. Thanks for the text and > > > > hopefully we can > > > > > > > > wrap this up this week. BR, Farid > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > Sent: Wednesday, September 10, 2003 12:15 PM > > > > > > > > To: Adrangi, Farid > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > gdommety@cisco.com > > > > > > > > Subject: RE: Request for text proposal for your scenario > > > > > > > > > > > > > > > > Hi Farid, > > > > > > > > > > > > > > > > The following is my proposed text for the co-located > > > > FA-VPN GW > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > Reagrds, > > > > > > > > Jayshree > > > > > > > > --------------------- > > > > > > > > > > > > > > > > 2.6 Combined VPN Gateway and MIPv4 FA > > > > > > > > > > > > > > > > MIPv4 FA and the VPN Gateway are running on the > > > same physical > > > > > >machine. > > > > > > > > > > > > > > > > > > > > > > > > ..Foreign Network... .....VPN > > > > > >Domain..(Intranet).... > > > > > > > > . . . > > > > > >. > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . |MNs | | FA | . | VPN| | > > > > Router| | HAs > > > > >| > > > > > >. > > > > > > > > . |away| | + | .<=3D=3D=3D=3D=3D=3D=3D=3D=3D>| = GW | | 1..n | >| > > > > >| > > > > > >. > > > > > > > > . | | | VPN | . | | +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . | | | GW | . | | > > > > > >. > > > > > > > > . +----+ +-----+ . +----+ +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . . . | CN > > > > | | MNs > > > > >| > > > > > >. > > > > > > > > .................... . | 1..n > > > > | | home > > > > >| > > > > > >. > > > > > > > > . +-------+ > > > > >+-------+ > > > > > >. > > > > > > > > . > > > > > >. > > > > > > > > > > > > > >............................... > > > > > > > > > > > > > > > > > > > > > > > > In this scenario, two VPN gateways are involved where > > > > the FA is > > > > > > > > considered to be the trusted entity. The mipv4 tunnel > > > > is running > > > > > > > > inside the IPSec-ESP. For end-to-end security model, the >VPN > > > > > > > > Gateway within the VPN Domain must protect the IP traffic > > > > > > > > originating at the MN. Since the point of > > > attachment changes > > > > > > > > corresponding to the movement of the MN, it is > > > essential that > > > > > > > > the VPN tunnel security association must be refreshed > > > > after each > > > > > > > > IP subnet handoff. Hence, this scenario is not > > > > practical where > > > > > > > > the mobility is involved due to performance > > > > implications for the > > > > > > > > real-time applications. > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Wednesday, September 03, 2003 7:54 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mccap@lucent.com; henrik@levkowetz.com; > > > > gdommety@cisco.com > > > > > > > > > Subject: Request for text proposal for your scenario > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > Could you please propose a text for the scenario > > > > that you want > > > > > > > > > to be added to the problem-statement draft? BR, Farid > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > Please see my reply below. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: mip4@ietf.org > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > > > > Thanks for following up on this. You, Gopal, and I > > > > had a very > > > > > > > > > brief conversation on this during IETF-57 - but I > > > > am not sure > > > > > > > > > if we derived any conclusion on whether or not we should > > > > > > > > > include this scenario. To be frank, I don't quite > > > > understand > > > > > > > > > the point behind adding this scenario because, > > > > > > > > > - It seems to present a solution to a specific > > > > > > > > > deployment model > > > > > > > > > rather than a deployment scenario > > > > > > > > > [JB] My understanding is different from yours so please > > > > > > > > > elaborate what you mean by deployment model vs >deployment > > > > > > > > > scenario in this particular context. > > > > > > > > > > > > > > > > > > - I don't quite see the advantages of a >combined > > > > > > > > > VPN+FA if it > > > > > > > > > does > > > > > > > > > not support FA traversal and it does not avoid IPsec > > > > > > > > > renegotiation when MN moves from one subnet to another - > > > > > > > > > perhaps you can elaborate on this? [JB] I think > > > regardless > > > > > > > > > this scenario has any advantages or not, it is one of >the > > > > > > > > > probable scenario which has potential issues (as you >have > > > > > > > > > indicated earlier). > > > > > > > > > > > > > > > > > > - Furthermore, Scenarios in section 2 of > > > > the problem > > > > > > > > > statement > > > > > > > > > draft represents combinations of MIPv4 HA and VPN >gateway > > > > > > > > > placement - adding this scenario is going to change > > > > semantics > > > > > > > > > of the section 2. [JB] I am not sure what you mean by > > > > > > > > > semantics change here. Do you think documenting > > > this in new > > > > > > > > > subsection (2.6) is a problem? > > > > > > > > > > > > > > > > > > I have no problem adding this scenario to the draft > > > > - I just > > > > > > > > > wanted to make sure that we clearly understand the > > > > reasons for > > > > > > > > > adding this scenario to the problem statement > > > draft. Design > > > > > > > > > team members and interested individuals are welcome > > > > to express > > > > > > > > > their opinion on this. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five > > > > > >representative > > > > > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > > > > > >[mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > > > > > To: Adrangi, Farid > > > > > > > > > Cc: 'mip4@ietf.org' > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > > > > > > > > > > As per our earlier discussion during IETF-57, my > > > > understanding > > > > > > > > > is that you will include the scenario of > > > co-existed FA with > > > > > > > > > the VPN gateway in the VPN Problem > > > > > > > > Statement draft. > > > > > > > > > > > > > > > > > > I agree that this particular scenario has problems and >it > > > > > > > > > won't work if the MN is behind an FA in the > > > foreign subnet. > > > > > > > > > But again, this is a problem statement draft. > > > > Hence, I believe > > > > > > > > > that this is the appropriate document for mentioning >this > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Adrangi, Farid > > > > > > > > > > [mailto:farid.adrangi@intel.com] > > > > > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > Subject: RE: Comments on VPN Problem Statement Draft >Hello > > > > > > > > > Jayshree This is a good point - I knew someone > > > was to bring > > > > > > > > > this up! At the time of writing these scenarios, we (the > > > > > > > > > design team) actually discussed this and concluded this > > > > > > > > > scenario would fall into a solution space. Maybe > > > > we did not > > > > > > > > > make the right decision and we should rethink this. >But, > > > > > > > > > before we take this discussion further please allow > > > > me to ask > > > > > > > > > you a few questions about the details of the > > > > scenario (VPN+FA) > > > > > > > > > that you have in mind . Are you thinking to broadcast >FA > > > > > > > > > advertisements through the IPsec tunnel to the > > > MN? If so, > > > > > > > > > how will this work if MN is already behind an FA in the > > > > > > > > > foreign subnet? Or, If you had something > > > different in mind, > > > > > > > > > perhaps you can elaborate on that. Best regards, Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jayshree Bharatia > > > > > > > > > > > > > > > > >[> > > > > >mailto:jayshree@nortelnetworks.c > > > > > >om > > > > >] > > > > > >, > > > > > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > > > > > To: 'farid.adrangi@intel.com' > > > > > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > > > Hello Farid, > > > > > > > > > This draft > > > > (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > > > > > currently misses one scenario were the FA is > > > > co-existed with > > > > > > > > > the VPN Gateway. I would think that there are no >technical > > > > > > > > > issues supporting this scenario. It will be good > > > if you can > > > > > > > > > add this scenario in the draft (perhaps as section > > > > > > > > > 2.6?) > > > > > > > > > for completeness. > > > > > > > > > Thanks, > > > > > > > > > Jayshree > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >_______________________________________________ >Mip4 mailing list >Mip4@ietf.org >https://www.ietf.org/mailman/listinfo/mip4 _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Sep 29 10:58: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 KAA19562 for ; Mon, 29 Sep 2003 10:58: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 1A3zTO-00071K-Dy for mip4-archive@odin.ietf.org; Mon, 29 Sep 2003 10:58:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8TEw25d026980 for mip4-archive@odin.ietf.org; Mon, 29 Sep 2003 10:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTO-000715-AC for mip4-web-archive@optimus.ietf.org; Mon, 29 Sep 2003 10:58: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 KAA19527 for ; Mon, 29 Sep 2003 10:57:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zTL-0006wf-00 for mip4-web-archive@ietf.org; Mon, 29 Sep 2003 10:57:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A3zTL-0006wc-00 for mip4-web-archive@ietf.org; Mon, 29 Sep 2003 10:57:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTN-00070c-1S; Mon, 29 Sep 2003 10:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zTJ-00070J-PI for mip4@optimus.ietf.org; Mon, 29 Sep 2003 10:57:57 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19516; Mon, 29 Sep 2003 10:57:48 -0400 (EDT) Message-Id: <200309291457.KAA19516@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: mip4@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 29 Sep 2003 10:57:47 -0400 Subject: [Mip4] I-D ACTION:draft-ietf-mip4-rfc2006bis-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. 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-00.txt Pages : 86 Date : 2003-9-29 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-rfc2006bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-rfc2006bis-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-9-29110910.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-rfc2006bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-rfc2006bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29110910.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 30 18:30: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 SAA19460 for ; Tue, 30 Sep 2003 18:30: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 1A4T0Q-0001tf-5n for mip4-archive@odin.ietf.org; Tue, 30 Sep 2003 18:30:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UMU6to007290 for mip4-archive@odin.ietf.org; Tue, 30 Sep 2003 18:30:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4T0Q-0001tV-1G for mip4-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 18:30: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 SAA19428 for ; Tue, 30 Sep 2003 18:29:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4T0N-0006BD-00 for mip4-web-archive@ietf.org; Tue, 30 Sep 2003 18:30:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4T0M-0006B9-00 for mip4-web-archive@ietf.org; Tue, 30 Sep 2003 18:30:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4T0M-0001t8-6c; Tue, 30 Sep 2003 18:30:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Szc-0001rw-GK for mip4@optimus.ietf.org; Tue, 30 Sep 2003 18:29:16 -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 SAA19388 for ; Tue, 30 Sep 2003 18:29:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4SzZ-00069y-00 for mip4@ietf.org; Tue, 30 Sep 2003 18:29:13 -0400 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1A4SzY-00069g-00 for mip4@ietf.org; Tue, 30 Sep 2003 18:29:12 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h8UMSf018689 for ; Tue, 30 Sep 2003 15:28:41 -0700 (PDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 30 Sep 2003 17:28:41 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746BD7@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Tue, 30 Sep 2003 17:28:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [Mip4] Changes for RFC3012bis - Issue 1 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, Based on the current discussion we have on this mailing list, I am planning to make the following changes in RFC3012bis for Issue 1. Please let me know if you have any issues with these changes: Issue 1: Current draft (05 version) doesn't have description on how to treat the router solicitations (mobility agent advertisement solicitations) in terms of sending new challenge vs unused challenge. Due to this reason, implementations differ significantly. This causes interoperability issues. Proposal for Issue 1: Change 1 (Accepted) Section 2: From: The Challenge extension, illustrated in figure 1, is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate the latest challenge value that can be used by the mobile node to compute an authentication for its next registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. Eastlake, et al. [5] provides more information on generating pseudo-random numbers suitable for use as values for the challenge. To: The Challenge extension, illustrated in figure 1, is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate a previously unused challenge value that can be used by the mobile node to compute an authentication for its next registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. Eastlake, et al. [5] provides more information on generating pseudo-random numbers suitable for use as values for the challenge. Change 2 (New section - Accepted) 2.1 Handling of Solicited Agent Advertisements When a foreign agent generates an Agent Advertisement in response to a Router Solicitation [4], some additional considerations come into play. According to the Mobile IP base specification [7], the resulting Agent Advertisement may be either multicast or unicast. If the solicited Agent Advertisement is multicast, it MUST NOT generate a new Challenge value and update its window of remembered advertised Challenges. It must instead re-use the most recent of the CHALLENGE_WINDOW Advertisement Challenge values. 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, 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.) _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 30 19:16: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 TAA20492 for ; Tue, 30 Sep 2003 19:16: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 1A4Tiv-0003tj-Vo for mip4-archive@odin.ietf.org; Tue, 30 Sep 2003 19:16:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UNG5fx014980 for mip4-archive@odin.ietf.org; Tue, 30 Sep 2003 19:16:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Tiv-0003tX-QT for mip4-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 19:16: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 TAA20479 for ; Tue, 30 Sep 2003 19:15:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Tiu-0006Xv-00 for mip4-web-archive@ietf.org; Tue, 30 Sep 2003 19:16:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Tiu-0006Xs-00 for mip4-web-archive@ietf.org; Tue, 30 Sep 2003 19:16:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Tir-0003t0-L8; Tue, 30 Sep 2003 19:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Tc0-0003l4-KL for mip4@optimus.ietf.org; Tue, 30 Sep 2003 19:08:56 -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 TAA20295 for ; Tue, 30 Sep 2003 19:08:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Tbx-0006Tv-00 for mip4@ietf.org; Tue, 30 Sep 2003 19:08:53 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=shiraz) by ietf-mx with esmtp (Exim 4.12) id 1A4Tbw-0006Ts-00 for mip4@ietf.org; Tue, 30 Sep 2003 19:08:52 -0400 Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz ident=www-data) by shiraz with esmtp (Exim 3.35 #1 (Debian)) id 1A4Tbw-0003PK-00 for ; Wed, 01 Oct 2003 01:08:52 +0200 Content-Type: text/plain; charset=utf-8 To: mip4@ietf.org From: Jayshree Bharatia Reply-To: Mip4 issue tracker Date: Tue, 30 Sep 2003 23:08:51 +0000 MIME-Version: 1.0 Message-Id: <1064963331.41.0.481591227562.issue10@levkowetz.com> X-Roundup-Name: Mip4 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Subject: [Mip4] [issue10] Treatment of router solicitations regarding new vs. unused challenge 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 This has been entered in the issue tracker as 10. From Jayshree Bharatia : Based on the current discussion we have on this mailing list, I am planning to make the following changes in RFC3012bis for Issue 1. Please let me know if you have any issues with these changes: Issue 1: Current draft (05 version) doesn't have description on how to treat the router solicitations (mobility agent advertisement solicitations) in terms of sending new challenge vs unused challenge. Due to this reason, implementations differ significantly. This causes interoperability issues. Proposal for Issue 1: Change 1 (Accepted) Section 2: From: The Challenge extension, illustrated in figure 1, is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate the latest challenge value that can be used by the mobile node to compute an authentication for its next registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. Eastlake, et al. [5] provides more information on generating pseudo-random numbers suitable for use as values for the challenge. To: The Challenge extension, illustrated in figure 1, is inserted in the Agent Advertisements by the Foreign Agent, in order to communicate a previously unused challenge value that can be used by the mobile node to compute an authentication for its next registration request message. The challenge is selected by the foreign agent to provide local assurance that the mobile node is not replaying any earlier registration request. Eastlake, et al. [5] provides more information on generating pseudo-random numbers suitable for use as values for the challenge. Change 2 (New section - Accepted) 2=2E1 Handling of Solicited Agent Advertisements When a foreign agent generates an Agent Advertisement in response to a Router Solicitation [4], some additional considerations come into play. According to the Mobile IP base specification [7], the resulting Agent Advertisement may be either multicast or unicast.=20 If the solicited Agent Advertisement is multicast, it MUST NOT generate a new Challenge value and update its window of remembered advertised Challenges. It must instead re-use the most recent of the CHALLENGE_WINDOW Advertisement Challenge values. =20 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=2E1), in SHOULD be repeated in the newly issued unicast agent advertiseme= nt, 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.) ---------- category: Technical draft: draft-ietf-mobileip-rfc3012bis messages: 8 nosy: jayshree priority: Must fix status: No discussion title: Treatment of router solicitations regarding new vs. unused challenge ____________________________________________________________ Mip4 issue tracker ____________________________________________________________ _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Sep 30 19:24: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 TAA20762 for ; Tue, 30 Sep 2003 19:24: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 1A4Tqc-0004Hz-NB for mip4-archive@odin.ietf.org; Tue, 30 Sep 2003 19:24:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h8UNO2mp016481 for mip4-archive@odin.ietf.org; Tue, 30 Sep 2003 19:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Tqc-0004Hk-IO for mip4-web-archive@optimus.ietf.org; Tue, 30 Sep 2003 19:24: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 TAA20753 for ; Tue, 30 Sep 2003 19:23:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Tqa-0006dp-00 for mip4-web-archive@ietf.org; Tue, 30 Sep 2003 19:24:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1A4Tqa-0006dm-00 for mip4-web-archive@ietf.org; Tue, 30 Sep 2003 19:24:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Tqb-0004HP-Gs; Tue, 30 Sep 2003 19: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 1A4Tpn-0004EH-9Y for mip4@optimus.ietf.org; Tue, 30 Sep 2003 19:23:11 -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 TAA20739 for ; Tue, 30 Sep 2003 19:23:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Tpl-0006dO-00 for mip4@ietf.org; Tue, 30 Sep 2003 19:23:09 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 1A4Tpk-0006dL-00 for mip4@ietf.org; Tue, 30 Sep 2003 19:23:09 -0400 Received: (qmail 18934 invoked from network); 30 Sep 2003 23:23:08 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 30 Sep 2003 23:23:08 -0000 Date: Wed, 1 Oct 2003 01:23:07 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: Re: [Mip4] [issue10] Changes for RFC3012bis - Issue 1 Message-Id: <20031001012307.5047cc9d.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746BD7@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746BD7@zrc2c000.us.nortel.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_Wed__1_Oct_2003_01_23_07_+0200_=.U2?Dc40msf1(W5" 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_Wed__1_Oct_2003_01_23_07_+0200_=.U2?Dc40msf1(W5 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit 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, > 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 --Multipart_Wed__1_Oct_2003_01_23_07_+0200_=.U2?Dc40msf1(W5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/ehBceVhrtTJkXCMRAqYYAKDNrMm7x6u1BNdWfbRDf0niY1cK/gCgiwcM sT/MXEu05/PiovJA8sdsCrc= =GfnA -----END PGP SIGNATURE----- --Multipart_Wed__1_Oct_2003_01_23_07_+0200_=.U2?Dc40msf1(W5-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4