From exim@www1.ietf.org Wed Jul 23 17:04:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02811 for ; Wed, 23 Jul 2003 17:04: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 19fQmN-0006gP-IP for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:04:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NL47oI025689 for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:04:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQmN-0006gG-FB for mip4-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 17:04: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 RAA02791 for ; Wed, 23 Jul 2003 17:04:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fQmL-0000nZ-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:04:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fQmF-0000nW-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:03:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQmG-0006fl-Ri; Wed, 23 Jul 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 19fQlZ-0006f4-Uw for mip4@optimus.ietf.org; Wed, 23 Jul 2003 17:03: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 RAA02759 for ; Wed, 23 Jul 2003 17:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fQlX-0000nL-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:03:15 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19fQlM-0000mW-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:03:05 -0400 Received: (qmail 14923 invoked from network); 23 Jul 2003 21:02:23 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 23 Jul 2003 21:02:23 -0000 Date: Wed, 23 Jul 2003 23:02:23 +0200 From: Henrik Levkowetz To: Alpesh Cc: mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Message-Id: <20030723230223.50544972.henrik@levkowetz.com> In-Reply-To: <3F1EDC7C.4060402@cisco.com> References: <3F1EDC7C.4060402@cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Alpesh, I'd considered writing something like this, but you beat me to it! :-) Some comments: * I don't believe the vendor/org-ID should be in there - that would mean that during experimentation, you still could not use extensions with exactly the format they would have when eventually deployed. As laid out in your draft, there is not a great deal of difference from the existing vendor-specific options, and one might as well use them. I believe that apart from assigning the number, the format should be left completely unspecified. * In order to be able to experiment with both skippable and non-skippable options, there needs to be assigned numbers for experimental extensions in both ranges. Just one won't do, as mip entities already are (should be) coded to handle the two ranges differently. * Possibly 1 single experimental number in each range is insufficient - witness the AAA key extensions. On the other hand, it could be argued that in order not to exhaust the existing address space too fast, experimenters should be encouraged to use subtypes, so 1 experimental number in each range is advisable. Comments? Henrik Wednesday 23 July 2003, Alpesh wrote: > > > Hi: > > A new ID is available for your reference at: > > ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experimental-messages-00.txt > > Abstract > > > Mobile IPv4 message types range from 0 to 255. This document > reserves a message type for use by an individual, company, or > organization for experimental purpose, to evaluate enhancements > to Mobile IPv4 messages before formal standards proposal. > > Thanks > Alpesh > > > > > > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 23 17:10:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03004 for ; Wed, 23 Jul 2003 17:10: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 19fQsC-0007Eq-56 for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:10:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLA8am027820 for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:10:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQsA-0007Eb-Ko for mip4-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 17:10: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 RAA02994 for ; Wed, 23 Jul 2003 17:10:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fQs8-0000qA-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:10:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fQs2-0000q7-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:09:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQs4-0007Dx-IJ; Wed, 23 Jul 2003 17:10:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fQrx-00079K-Bu for mip4@optimus.ietf.org; Wed, 23 Jul 2003 17:09: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 RAA02985 for ; Wed, 23 Jul 2003 17:09:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fQrv-0000pv-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:09:51 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19fQrk-0000pg-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:09:40 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Jul 2003 14:09:50 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6NL8c89011301; Wed, 23 Jul 2003 14:08:38 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-124.cisco.com [128.107.163.124]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJN34408; Wed, 23 Jul 2003 14:04:27 -0700 (PDT) Message-ID: <3F1EF94D.9000801@cisco.com> Date: Wed, 23 Jul 2003 14:08:29 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt References: <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> Content-Type: multipart/alternative; boundary="------------040100020105090205090707" 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: , --------------040100020105090205090707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Henrik: Good that you responded on the new alias - so it is functional now! Also, good that you too were thinking something similar :) Beyond that, please inline under ALPS>> Henrik Levkowetz wrote: >Hi Alpesh, > > I'd considered writing something like this, but you beat me >to it! :-) > > Some comments: > > * I don't believe the vendor/org-ID should be in there - >that would mean that during experimentation, you still could not >use extensions with exactly the format they would have when >eventually deployed. As laid out in your draft, there is not a >great deal of difference from the existing vendor-specific options, >and one might as well use them. I believe that apart from assigning >the number, the format should be left completely unspecified. > ALPS>> We thought of doing that, but then that may create interoperability issues - the fix would have been for implementations to include their (C/N)VSEs in each message. We thought that by including the Vendor/Org_ID right in the message type, parsing could be simplified - entity won't have to parse the whole message to analyze the semantics. Comments? Others? > > * In order to be able to experiment with both skippable >and non-skippable options, there needs to be assigned numbers for >experimental extensions in both ranges. Just one won't do, as >mip entities already are (should be) coded to handle the two >ranges differently. > ALPS>> Hmm, probably I missed that in RFC3344 that we have skippable and unskippable messages. I thought we have reserved the range for extensions only. I thought we didn't - but can double check. > > * Possibly 1 single experimental number in each range is >insufficient - witness the AAA key extensions. On the other hand, >it could be argued that in order not to exhaust the existing >address space too fast, experimenters should be encouraged to use >subtypes, so 1 experimental number in each range is advisable. >Comments? > ALPS>> See above and beyond that, agree that experimenters would use subtypes to interpret the message differently. Alpesh > > Henrik > > >Wednesday 23 July 2003, Alpesh wrote: > > >>Hi: >> >>A new ID is available for your reference at: >> >>ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experimental-messages-00.txt >> >> Abstract >> >> >> Mobile IPv4 message types range from 0 to 255. This document >> reserves a message type for use by an individual, company, or >> organization for experimental purpose, to evaluate enhancements >> to Mobile IPv4 messages before formal standards proposal. >> >>Thanks >>Alpesh >> >> >> >> >> >>_______________________________________________ >>Mip4 mailing list >>Mip4@ietf.org >>https://www.ietf.org/mailman/listinfo/mip4 >> >> >> > > > > --------------040100020105090205090707 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Henrik:

Good that you responded on the new alias - so it is functional now!
Also, good that you too were thinking something similar :)

Beyond that, please inline under ALPS>>

Henrik Levkowetz wrote:
Hi Alpesh,

	I'd considered writing something like this, but you beat me
to it! :-)

	Some comments:

	* I don't believe the vendor/org-ID should be in there - 
that would mean that during experimentation, you still could not
use extensions with exactly the format they would have when 
eventually deployed. As laid out in your draft, there is not a
great deal of difference from the existing vendor-specific options,
and one might as well use them. I believe that apart from assigning
the number, the format should be left completely unspecified.
ALPS>> We thought of doing that, but then that may create interoperability issues - the
fix would have been for implementations to include their (C/N)VSEs in each message. We
thought that by including the Vendor/Org_ID right in the message type, parsing could be
simplified - entity won't have to parse the whole message to analyze the semantics.

Comments? Others?

	* In order to be able to experiment with both skippable 
and non-skippable options, there needs to be assigned numbers for
experimental extensions in both ranges. Just one won't do, as 
mip entities already are (should be) coded to handle the two
ranges differently.
ALPS>> Hmm, probably I missed that in RFC3344 that we have skippable and unskippable
messages. I thought we have reserved the range for extensions only. I thought we didn't - but
can double check.

	* Possibly 1 single experimental number in each range is
insufficient - witness the AAA key extensions. On the other hand,
it could be argued that in order not to exhaust the existing 
address space too fast, experimenters should be encouraged to use
subtypes, so 1 experimental number in each range is advisable.
Comments?
ALPS>> See above and beyond that, agree that experimenters would use subtypes to
interpret the message differently.

Alpesh

	Henrik


Wednesday 23 July 2003, Alpesh wrote:
  
Hi:

A new ID is available for your reference at:

ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experimental-messages-00.txt

   Abstract


        Mobile IPv4 message types range from 0 to 255. This document
        reserves a message type for use by an individual, company, or
        organization for experimental purpose, to evaluate enhancements
        to Mobile IPv4 messages before formal standards proposal.

Thanks
Alpesh





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

--------------040100020105090205090707-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 23 17:25: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 RAA03466 for ; Wed, 23 Jul 2003 17:25:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fR6w-0007ri-75 for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:25:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLPMSC030228 for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:25:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fR6u-0007r0-MR for mip4-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 17:25: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 RAA03433 for ; Wed, 23 Jul 2003 17:25:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fR6r-0000xA-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:25:17 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fR6j-0000va-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:25:09 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fR2i-0007bz-TO; Wed, 23 Jul 2003 17: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 19fR2L-0007bH-Uh for mip4@optimus.ietf.org; Wed, 23 Jul 2003 17:20: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 RAA03267 for ; Wed, 23 Jul 2003 17:20:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fR2J-0000vM-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:20:35 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19fR28-0000uo-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:20:24 -0400 Received: (qmail 15033 invoked from network); 23 Jul 2003 21:20:03 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 23 Jul 2003 21:20:03 -0000 Date: Wed, 23 Jul 2003 23:20:03 +0200 From: Henrik Levkowetz To: Alpesh Cc: mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Message-Id: <20030723232003.0f35b407.henrik@levkowetz.com> In-Reply-To: <3F1EF94D.9000801@cisco.com> References: <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alpesh, Oops, sorry, There's the danger of assuming similar thoughts! I read too swiftly, and managed to read experimental *extension* instead of message! No, your're right, we don't have skippable/non-skippable messages. I still don't think the vendor ID should be in there, but now for a different reason: it would make it inviting to use this not as an opaque experimental message, but as a vendor-specific message, which might be used not for experimentation but for persistent vendor-specific use. This could be a real destroyer of interoperability. But here's one additional comment then: Maybe it would be good to specify experimental *extensions* while we're at it? :-) Henrik Wednesday 23 July 2003, Alpesh wrote: > Henrik: > > Good that you responded on the new alias - so it is functional now! > Also, good that you too were thinking something similar :) > > Beyond that, please inline under ALPS>> > > Henrik Levkowetz wrote: > > >Hi Alpesh, > > > > I'd considered writing something like this, but you beat me > >to it! :-) > > > > Some comments: > > > > * I don't believe the vendor/org-ID should be in there - > >that would mean that during experimentation, you still could not > >use extensions with exactly the format they would have when > >eventually deployed. As laid out in your draft, there is not a > >great deal of difference from the existing vendor-specific options, > >and one might as well use them. I believe that apart from assigning > >the number, the format should be left completely unspecified. > > > ALPS>> We thought of doing that, but then that may create > interoperability issues - the > fix would have been for implementations to include their (C/N)VSEs in > each message. We > thought that by including the Vendor/Org_ID right in the message type, > > parsing could be > simplified - entity won't have to parse the whole message to analyze > the semantics. > > Comments? Others? > > > > > * In order to be able to experiment with both skippable > >and non-skippable options, there needs to be assigned numbers for > >experimental extensions in both ranges. Just one won't do, as > >mip entities already are (should be) coded to handle the two > >ranges differently. > > > ALPS>> Hmm, probably I missed that in RFC3344 that we have skippable > ALPS>and > unskippable > messages. I thought we have reserved the range for extensions only. I > thought we didn't - but > can double check. > > > > > * Possibly 1 single experimental number in each range is > >insufficient - witness the AAA key extensions. On the other hand, > >it could be argued that in order not to exhaust the existing > >address space too fast, experimenters should be encouraged to use > >subtypes, so 1 experimental number in each range is advisable. > >Comments? > > > ALPS>> See above and beyond that, agree that experimenters would use > subtypes to > interpret the message differently. > > Alpesh > > > > > Henrik > > > > > >Wednesday 23 July 2003, Alpesh wrote: > > > > > >>Hi: > >> > >>A new ID is available for your reference at: > >> > >>ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experime > >ntal-messages-00.txt> > >> Abstract > >> > >> > >> Mobile IPv4 message types range from 0 to 255. This document > >> reserves a message type for use by an individual, company, > >or> organization for experimental purpose, to evaluate > >enhancements> to Mobile IPv4 messages before formal standards > >proposal.> > >>Thanks > >>Alpesh > >> > >> > >> > >> > >> > >>_______________________________________________ > >>Mip4 mailing list > >>Mip4@ietf.org > >>https://www.ietf.org/mailman/listinfo/mip4 > >> > >> > >> > > > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 23 17:32:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03694 for ; Wed, 23 Jul 2003 17:32: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 19fRDT-00083F-Ht for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:32:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLW7sM030945 for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:32:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRDT-000832-DF for mip4-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 17:32: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 RAA03663 for ; Wed, 23 Jul 2003 17:32:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRDR-00010v-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:32:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fRDL-00010s-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:31:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRDN-00082X-Ah; Wed, 23 Jul 2003 17:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRCp-0007zp-UG for mip4@optimus.ietf.org; Wed, 23 Jul 2003 17:31: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 RAA03651 for ; Wed, 23 Jul 2003 17:31:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRCn-00010Q-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:31:25 -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 19fRCc-0000z4-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:31:14 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Jul 2003 14:36:03 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6NLTM8B028705; Wed, 23 Jul 2003 14:29:25 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-124.cisco.com [128.107.163.124]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJN37558; Wed, 23 Jul 2003 14:25:18 -0700 (PDT) Message-ID: <3F1EFE31.5010801@cisco.com> Date: Wed, 23 Jul 2003 14:29:21 -0700 From: Alpesh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt References: <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> Content-Type: multipart/alternative; boundary="------------060807010402030602000408" 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: , --------------060807010402030602000408 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Henrik: See under ALPS>> Henrik Levkowetz wrote: >Alpesh, > >Oops, sorry, > > There's the danger of assuming similar thoughts! I read >too swiftly, and managed to read experimental *extension* instead >of message! > > No, your're right, we don't have skippable/non-skippable >messages. > > I still don't think the vendor ID should be in there, but >now for a different reason: it would make it inviting to use this >not as an opaque experimental message, but as a vendor-specific >message, which might be used not for experimentation but for >persistent vendor-specific use. This could be a real destroyer >of interoperability. > ALPS>> Even if used as a vendor specific message (I am neither intending nor suggesting that), why would it destroy interoperability? If my implementation does not know how to parse your messages, then there is no interoperability even for experimental messages - right? > > But here's one additional comment then: Maybe it would be >good to specify experimental *extensions* while we're at it? :-) > ALPS>> Don't the VSE's serve the purpose of experimental extensions? Vendors can then bring to IETF if they want to standardize them. -a > > Henrik > >Wednesday 23 July 2003, Alpesh wrote: > > >>Henrik: >> >>Good that you responded on the new alias - so it is functional now! >>Also, good that you too were thinking something similar :) >> >>Beyond that, please inline under ALPS>> >> >>Henrik Levkowetz wrote: >> >> >> >>>Hi Alpesh, >>> >>> I'd considered writing something like this, but you beat me >>>to it! :-) >>> >>> Some comments: >>> >>> * I don't believe the vendor/org-ID should be in there - >>>that would mean that during experimentation, you still could not >>>use extensions with exactly the format they would have when >>>eventually deployed. As laid out in your draft, there is not a >>>great deal of difference from the existing vendor-specific options, >>>and one might as well use them. I believe that apart from assigning >>>the number, the format should be left completely unspecified. >>> >>> >>> >>ALPS>> We thought of doing that, but then that may create >>interoperability issues - the >>fix would have been for implementations to include their (C/N)VSEs in >>each message. We >>thought that by including the Vendor/Org_ID right in the message type, >> >>parsing could be >>simplified - entity won't have to parse the whole message to analyze >>the semantics. >> >>Comments? Others? >> >> >> >>> * In order to be able to experiment with both skippable >>>and non-skippable options, there needs to be assigned numbers for >>>experimental extensions in both ranges. Just one won't do, as >>>mip entities already are (should be) coded to handle the two >>>ranges differently. >>> >>> >>> >>ALPS>> Hmm, probably I missed that in RFC3344 that we have skippable >>ALPS>and >>unskippable >>messages. I thought we have reserved the range for extensions only. I >>thought we didn't - but >>can double check. >> >> >> >>> * Possibly 1 single experimental number in each range is >>>insufficient - witness the AAA key extensions. On the other hand, >>>it could be argued that in order not to exhaust the existing >>>address space too fast, experimenters should be encouraged to use >>>subtypes, so 1 experimental number in each range is advisable. >>>Comments? >>> >>> >>> >>ALPS>> See above and beyond that, agree that experimenters would use >>subtypes to >>interpret the message differently. >> >>Alpesh >> >> >> >>> Henrik >>> >>> >>>Wednesday 23 July 2003, Alpesh wrote: >>> >>> >>> >>> >>>>Hi: >>>> >>>>A new ID is available for your reference at: >>>> >>>>ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experime >>>> >>>> >>>ntal-messages-00.txt> >>> >>> >>>> Abstract >>>> >>>> >>>> Mobile IPv4 message types range from 0 to 255. This document >>>> reserves a message type for use by an individual, company, >>>> >>>> >>>or> organization for experimental purpose, to evaluate >>>enhancements> to Mobile IPv4 messages before formal standards >>>proposal.> >>> >>> >>>>Thanks >>>>Alpesh >>>> >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Mip4 mailing list >>>>Mip4@ietf.org >>>>https://www.ietf.org/mailman/listinfo/mip4 >>>> >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> > > > > --------------060807010402030602000408 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Henrik:
See under ALPS>>

Henrik Levkowetz wrote:
Alpesh,

Oops, sorry,

	There's the danger of assuming similar thoughts! I read
too swiftly, and managed to read experimental *extension* instead
of message!

	No, your're right, we don't have skippable/non-skippable
messages.

	I still don't think the vendor ID should be in there, but
now for a different reason: it would make it inviting to use this
not as an opaque experimental message, but as a vendor-specific
message, which might be used not for experimentation but for 
persistent vendor-specific use. This could be a real destroyer
of interoperability.
ALPS>> Even if used as a vendor specific message (I am neither intending nor suggesting
that), why would it destroy interoperability?
If my implementation does not know how to parse your messages, then there is no
interoperability even for experimental messages - right? 

	But here's one additional comment then: Maybe it would be
good to specify experimental *extensions* while we're at it? :-)


ALPS>> Don't the VSE's serve the purpose of experimental extensions? Vendors can
then bring to IETF if they want to standardize them.

-a

	Henrik

Wednesday 23 July 2003, Alpesh wrote:
  
Henrik:

Good that you responded on the new alias - so it is functional now!
Also, good that you too were thinking something similar :)

Beyond that, please inline under ALPS>>

Henrik Levkowetz wrote:

    
Hi Alpesh,

	I'd considered writing something like this, but you beat me
to it! :-)

	Some comments:

	* I don't believe the vendor/org-ID should be in there - 
that would mean that during experimentation, you still could not
use extensions with exactly the format they would have when 
eventually deployed. As laid out in your draft, there is not a
great deal of difference from the existing vendor-specific options,
and one might as well use them. I believe that apart from assigning
the number, the format should be left completely unspecified.

      
ALPS>> We thought of doing that, but then that may create 
interoperability issues - the
fix would have been for implementations to include their (C/N)VSEs in 
each message. We
thought that by including the Vendor/Org_ID right in the message type,

parsing could be
simplified - entity won't have to parse the whole message to analyze
the semantics.

Comments? Others?

    
	* In order to be able to experiment with both skippable 
and non-skippable options, there needs to be assigned numbers for
experimental extensions in both ranges. Just one won't do, as 
mip entities already are (should be) coded to handle the two
ranges differently.

      
ALPS>> Hmm, probably I missed that in RFC3344 that we have skippable
ALPS>and 
unskippable
messages. I thought we have reserved the range for extensions only. I 
thought we didn't - but
can double check.

    
	* Possibly 1 single experimental number in each range is
insufficient - witness the AAA key extensions. On the other hand,
it could be argued that in order not to exhaust the existing 
address space too fast, experimenters should be encouraged to use
subtypes, so 1 experimental number in each range is advisable.
Comments?

      
ALPS>> See above and beyond that, agree that experimenters would use 
subtypes to
interpret the message differently.

Alpesh

    
	Henrik


Wednesday 23 July 2003, Alpesh wrote:
 

      
Hi:

A new ID is available for your reference at:

ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experime
        
ntal-messages-00.txt>
      
  Abstract


       Mobile IPv4 message types range from 0 to 255. This document
       reserves a message type for use by an individual, company,
        
or>        organization for experimental purpose, to evaluate
enhancements>        to Mobile IPv4 messages before formal standards
proposal.>
      
Thanks
Alpesh





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

--------------060807010402030602000408-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 23 17:56: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 RAA04357 for ; Wed, 23 Jul 2003 17:56: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 19fRag-00012Q-DF for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:56:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6NLu6Gq003989 for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 17:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRag-00012G-5p for mip4-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 17:56: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 RAA04351 for ; Wed, 23 Jul 2003 17:56:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRad-0001Ah-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:56:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fRaY-0001Ae-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 17:55:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRaa-00011j-2n; Wed, 23 Jul 2003 17:56:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fRaR-00011W-NU for mip4@optimus.ietf.org; Wed, 23 Jul 2003 17:55: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 RAA04347 for ; Wed, 23 Jul 2003 17:55:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fRaP-0001AX-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:55:49 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19fRaE-0001AM-00 for mip4@ietf.org; Wed, 23 Jul 2003 17:55:38 -0400 Received: (qmail 15264 invoked from network); 23 Jul 2003 21:55:18 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 23 Jul 2003 21:55:18 -0000 Date: Wed, 23 Jul 2003 23:55:17 +0200 From: Henrik Levkowetz To: Alpesh Cc: mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Message-Id: <20030723235517.6a148de8.henrik@levkowetz.com> In-Reply-To: <3F1EFE31.5010801@cisco.com> References: <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> <3F1EFE31.5010801@cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Wednesday 23 July 2003, Alpesh wrote in reply to Henrik: > > I still don't think the vendor ID should be in there, but > >now for a different reason: it would make it inviting to use this > >not as an opaque experimental message, but as a vendor-specific > >message, which might be used not for experimentation but for > >persistent vendor-specific use. This could be a real destroyer > >of interoperability. > > > ALPS> Even if used as a vendor specific message (I am neither > ALPS> intending nor suggesting that), why would it destroy > ALPS> interoperability? If my implementation does not know how to > ALPS> parse your messages, then there is no interoperability even for > ALPS> experimental messages - right? Well, my thinking was that if vendors design in vendor specific messages to do various things, and use them for not only experimentation, but rely on them to make some features work right, it could both decrease the desire to write up and standardise the features, and evolve into a morass of tens or hundreds of different ways of implementing more or less the same feature. Currently, the *messages* are fixed, so the basic operation of the protocol is the same, while we have vendor-specific *extensions* to carry special things (and experiment). But if the *messages* also come in a vendor-specific flavour, it would basically be possible to design a whole new alternate protocol in parallel, but still maintain that it was Mobile-IP. > > But here's one additional comment then: Maybe it would be > > good to specify experimental *extensions* while we're at it? :-) > > > > ALPS> Don't the VSE's serve the purpose of experimental extensions? > ALPS> Vendors can then bring to IETF if they want to standardize them. For sure. But it's the same thing there - you can't use exactly the same format during experimentation as in final deployment. Having experimental extensions available during interop-testing of new features would ensure we didn't get into the trouble we recently did with already deployed extension numbers which had not been registered with IANA. Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 23 20:42: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 UAA08875 for ; Wed, 23 Jul 2003 20:42: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 19fUAP-0000iK-Ce for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 20:41:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O0f9Ld002744 for mip4-archive@odin.ietf.org; Wed, 23 Jul 2003 20:41:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fUAP-0000iB-9D for mip4-web-archive@optimus.ietf.org; Wed, 23 Jul 2003 20:41: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 UAA08840 for ; Wed, 23 Jul 2003 20:41:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fUAN-00022l-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 20:41:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fUAH-00022i-00 for mip4-web-archive@ietf.org; Wed, 23 Jul 2003 20:41:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fUAI-0000hg-OZ; Wed, 23 Jul 2003 20:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fUAB-0000hI-VZ for mip4@optimus.ietf.org; Wed, 23 Jul 2003 20:40: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 UAA08833 for ; Wed, 23 Jul 2003 20:40:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fUA9-00022Z-00 for mip4@ietf.org; Wed, 23 Jul 2003 20:40:53 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19fU9z-000227-00 for mip4@ietf.org; Wed, 23 Jul 2003 20:40:43 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6O0dppp000210; Wed, 23 Jul 2003 17:39:51 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-128-107-163-91.cisco.com [128.107.163.91]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJN61542; Wed, 23 Jul 2003 17:35:46 -0700 (PDT) Message-Id: <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 23 Jul 2003 17:39:43 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Cc: Alpesh , mip4@ietf.org In-Reply-To: <20030723235517.6a148de8.henrik@levkowetz.com> References: <3F1EFE31.5010801@cisco.com> <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> <3F1EFE31.5010801@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 11:55 PM 7/23/2003 +0200, Henrik Levkowetz wrote: >Well, my thinking was that if vendors design in vendor specific messages >to do various things, and use them for not only experimentation, but >rely on them to make some features work right, it could both decrease >the desire to write up and standardise the features, and evolve into a >morass of tens or hundreds of different ways of implementing more or >less the same feature. Currently, the *messages* are fixed, so the basic >operation of the protocol is the same, while we have vendor-specific >*extensions* to carry special things (and experiment). But if the >*messages* also come in a vendor-specific flavour, it would basically >be possible to design a whole new alternate protocol in parallel, but >still maintain that it was Mobile-IP. Good point. That was what we had in mind to begin with, then thought to provide a reference format to avoid inter-operability issues between experimentations. That resulted in stating the specific message format. We could go back to original format of having a Type field which is designated as EXP-MSG-TYPE and rest as opaque. But also show the current format as reference model. Though wondering if conflict between experimentations be required to be avoided? >For sure. But it's the same thing there - you can't use exactly the >same format during experimentation as in final deployment. Having >experimental extensions available during interop-testing of new >features would ensure we didn't get into the trouble we recently did >with already deployed extension numbers which had not been registered >with IANA. If folks deploy messages with unregistered IANA extension types, then they will need to fix them if the types are assigned elsewhere. Not sure having experimental extension type will help? Let's say experimental extension type used for an extension w/o IANA type number. When IANA assigns the number, the implementation still has to go back to fix the type number. There doesn't seem to be alot of difference using VSEs that are formatted somewhat similar instead. Kent _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Jul 24 03:47:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27726 for ; Thu, 24 Jul 2003 03:47: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 19faod-00023i-FR for mip4-archive@odin.ietf.org; Thu, 24 Jul 2003 03:47:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6O7l7s3007914 for mip4-archive@odin.ietf.org; Thu, 24 Jul 2003 03:47:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19faoc-00023Z-JP for mip4-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 03:47: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 DAA27707 for ; Thu, 24 Jul 2003 03:47:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19faoa-00043W-00 for mip4-web-archive@ietf.org; Thu, 24 Jul 2003 03:47:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19faoU-00043T-00 for mip4-web-archive@ietf.org; Thu, 24 Jul 2003 03: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 19faoW-00022c-6o; Thu, 24 Jul 2003 03: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 19fane-0001x3-Fu for mip4@optimus.ietf.org; Thu, 24 Jul 2003 03:46:06 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27685 for ; Thu, 24 Jul 2003 03:46:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fanb-00043B-00 for mip4@ietf.org; Thu, 24 Jul 2003 03:46:04 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19fanQ-00041j-00 for mip4@ietf.org; Thu, 24 Jul 2003 03:45:53 -0400 Received: (qmail 18979 invoked from network); 24 Jul 2003 07:43:51 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 24 Jul 2003 07:43:51 -0000 Date: Thu, 24 Jul 2003 09:43:50 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Alpesh , mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Message-Id: <20030724094350.5ff3711d.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> References: <3F1EFE31.5010801@cisco.com> <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> <3F1EFE31.5010801@cisco.com> <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Kent, Wednesday 23 July 2003, Kent wrote: > At 11:55 PM 7/23/2003 +0200, Henrik Levkowetz wrote: > > > >Well, my thinking was that if vendors design in vendor specific messages > >to do various things, and use them for not only experimentation, but > >rely on them to make some features work right, it could both decrease > >the desire to write up and standardise the features, and evolve into a > >morass of tens or hundreds of different ways of implementing more or > >less the same feature. Currently, the *messages* are fixed, so the basic > >operation of the protocol is the same, while we have vendor-specific > >*extensions* to carry special things (and experiment). But if the > >*messages* also come in a vendor-specific flavour, it would basically > >be possible to design a whole new alternate protocol in parallel, but > >still maintain that it was Mobile-IP. > > > Good point. That was what we had in mind to begin with, then thought to > provide a reference format to avoid inter-operability issues between > experimentations. That resulted in stating the specific message format. > > We could go back to original format of having a Type field which is > designated as EXP-MSG-TYPE and rest as opaque. But also > show the current format as reference model. > > Though wondering if conflict between experimentations be required to > be avoided? Personally, I'd say that if an extension is used for experimentation, you need to have some amount of control and monitoring of the experiment, otherwise you won't get any significant amount of reliable data to draw conclusions from. You'd certainly want to eliminate other experiments in the same setup, as they could skew or invalidate your data. So I'm not even sure that avoiding conflict is advisable, more important could be to discover influences in your setup which should not really be there. > > >For sure. But it's the same thing there - you can't use exactly the > >same format during experimentation as in final deployment. Having > >experimental extensions available during interop-testing of new > >features would ensure we didn't get into the trouble we recently did > >with already deployed extension numbers which had not been registered > >with IANA. > > If folks deploy messages with unregistered IANA extension types, then > they will need to fix them if the types are assigned elsewhere. Not sure > having experimental extension type will help? Let's say experimental > extension type used for an extension w/o IANA type number. When > IANA assigns the number, the implementation still has to go back to > fix the type number. There doesn't seem to be alot of difference using > VSEs that are formatted somewhat similar instead. There shouldn't be, I guess, but maybe you remember the query I sent you some months ago about use of unassigned extension numbers? This was because the number first assigned for one of the UDP tunnelling extensions was already being used by some implementations for an aaa-keys extension, and we had to re-assign. Apparently some people had agreed on those numbers during an interop, and gone ahead and deployed products with those numbers. There would have been a much stronger incentive to use VSEs when deploying if all interop testing was done with a known experimental extension number, I believe. Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Jul 24 12:20:38 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 MAA12411 for ; Thu, 24 Jul 2003 12:20:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fipB-0006Lu-5m for mip4-archive@odin.ietf.org; Thu, 24 Jul 2003 12:20:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OGKDub024412 for mip4-archive@odin.ietf.org; Thu, 24 Jul 2003 12:20:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fipB-0006Lf-0x for mip4-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 12:20: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 MAA12405 for ; Thu, 24 Jul 2003 12:20:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fip9-0007EK-00 for mip4-web-archive@ietf.org; Thu, 24 Jul 2003 12:20:11 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fip4-0007EB-00 for mip4-web-archive@ietf.org; Thu, 24 Jul 2003 12:20:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fioy-0006KU-Ol; Thu, 24 Jul 2003 12:20:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fioW-0006Jy-H3 for mip4@optimus.ietf.org; Thu, 24 Jul 2003 12:19: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 MAA12378 for ; Thu, 24 Jul 2003 12:19:27 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fioS-0007E2-00 for mip4@ietf.org; Thu, 24 Jul 2003 12:19:28 -0400 Received: from [63.78.179.217] (helo=mgw-dax2.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19fioH-0007Dm-00 for mip4@ietf.org; Thu, 24 Jul 2003 12:19:17 -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 h6OGIiG22833 for ; Thu, 24 Jul 2003 11:18:44 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 24 Jul 2003 11:19:08 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 24 Jul 2003 11:17:29 -0500 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, 24 Jul 2003 11:17:29 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB46C@daebe007.americas.nokia.com> Thread-Topic: WG LC: draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt Thread-Index: AcNR/xOhAt+aiqrqQmCGsfdqgS/m2Q== To: , X-OriginalArrivalTime: 24 Jul 2003 16:17:29.0786 (UTC) FILETIME=[146F61A0:01C351FF] Content-Transfer-Encoding: quoted-printable Subject: [Mip4] WG LC: draft-ietf-mobileip-lowlatency-handoffs-v4-05.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 Hello, This is a WG last call for "Low Latency Handoffs in Mobile IPv4" I-D : draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt Status sought for I-D: Experimental Please submit your comments to the mailing list or the editor (Karim El Malki). The WG last call will expire on August 6th, = 2003. -Chairs _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Jul 24 12:29:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12941 for ; Thu, 24 Jul 2003 12:29: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 19fixo-0006pc-P8 for mip4-archive@odin.ietf.org; Thu, 24 Jul 2003 12:29:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OGT8Md026256 for mip4-archive@odin.ietf.org; Thu, 24 Jul 2003 12:29:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fixn-0006pP-8V for mip4-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 12:29: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 MAA12918 for ; Thu, 24 Jul 2003 12:29:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fixl-0007IS-00 for mip4-web-archive@ietf.org; Thu, 24 Jul 2003 12:29:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fixg-0007IP-00 for mip4-web-archive@ietf.org; Thu, 24 Jul 2003 12:29:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fixh-0006oQ-9G; Thu, 24 Jul 2003 12:29:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fixb-0006oB-GS for mip4@optimus.ietf.org; Thu, 24 Jul 2003 12:28: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 MAA12909 for ; Thu, 24 Jul 2003 12:28:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fixa-0007IF-00 for mip4@ietf.org; Thu, 24 Jul 2003 12:28:54 -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 19fixP-0007H2-00 for mip4@ietf.org; Thu, 24 Jul 2003 12:28:43 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h6OGQD89023705; Thu, 24 Jul 2003 09:26:13 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn2-62.cisco.com [10.21.112.62]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJO24311; Thu, 24 Jul 2003 09:22:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20030724091346.02c1dc10@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 24 Jul 2003 09:24:10 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Cc: Alpesh , mip4@ietf.org In-Reply-To: <20030724094350.5ff3711d.henrik@levkowetz.com> References: <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> <3F1EFE31.5010801@cisco.com> <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> <3F1EFE31.5010801@cisco.com> <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.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 09:43 AM 7/24/2003 +0200, Henrik Levkowetz wrote: > > We could go back to original format of having a Type field which is > > designated as EXP-MSG-TYPE and rest as opaque. But also > > show the current format as reference model. > > > > Though wondering if conflict between experimentations be required to > > be avoided? > >Personally, I'd say that if an extension is used for experimentation, >you need to have some amount of control and monitoring of the >experiment, otherwise you won't get any significant amount of reliable >data to draw conclusions from. You'd certainly want to eliminate other >experiments in the same setup, as they could skew or invalidate your >data. So I'm not even sure that avoiding conflict is advisable, more >important could be to discover influences in your setup which should not >really be there. So this means agreement that existing format remain as reference model, right? >There shouldn't be, I guess, but maybe you remember the query I sent you >some months ago about use of unassigned extension numbers? This was >because the number first assigned for one of the UDP tunnelling >extensions was already being used by some implementations for an >aaa-keys extension, and we had to re-assign. Apparently some people had >agreed on those numbers during an interop, and gone ahead and deployed >products with those numbers. There would have been a much stronger >incentive to use VSEs when deploying if all interop testing was done >with a known experimental extension number, I believe. > Yes, I remember the problem faced before and agree we need to avoid that in the future. A few options: 1) Use VSE with Vendor ID 0 "reserved" for pre-standard interop. I'm not in favor of this at all, just wanted to throw the options out there. 2) Add experimental extension types (critical and normal) to the draft as well. May be useful to have a range of types instead of just one in each category? Maybe 8 each? Note: seems other protocols have also defined experimental message types and extensions (ie RADIUS). Kent _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Jul 24 18:55: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 SAA05180 for ; Thu, 24 Jul 2003 18:55: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 19fozL-0003AV-RB for mip4-archive@odin.ietf.org; Thu, 24 Jul 2003 18:55:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6OMt7Tj012173 for mip4-archive@odin.ietf.org; Thu, 24 Jul 2003 18:55:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fozL-0003AG-MR for mip4-web-archive@optimus.ietf.org; Thu, 24 Jul 2003 18:55: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 SAA05166 for ; Thu, 24 Jul 2003 18:55:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fozI-0002zt-00 for mip4-web-archive@ietf.org; Thu, 24 Jul 2003 18:55:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fozC-0002zp-00 for mip4-web-archive@ietf.org; Thu, 24 Jul 2003 18:54:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fozE-00036i-RS; Thu, 24 Jul 2003 18:55:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19foyd-00036I-Ue for mip4@optimus.ietf.org; Thu, 24 Jul 2003 18:54: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 SAA05137; Thu, 24 Jul 2003 18:54:16 -0400 (EDT) From: Basavaraj.Patil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19foya-0002zl-00; Thu, 24 Jul 2003 18:54:20 -0400 Received: from [63.78.179.216] (helo=mgw-dax1.ext.nokia.com) by ietf-mx with esmtp (Exim 4.12) id 19foyP-0002zf-00; Thu, 24 Jul 2003 18:54:10 -0400 Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6OMri117972; Thu, 24 Jul 2003 17:53:44 -0500 (CDT) Received: from daebh002.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 24 Jul 2003 17:53:44 -0500 Received: from daebe007.NOE.Nokia.com ([172.18.242.211]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 24 Jul 2003 17:53:26 -0500 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, 24 Jul 2003 17:53:26 -0500 Message-ID: <697DAA22C5004B4596E033803A7CEF44024DB489@daebe007.americas.nokia.com> Thread-Topic: IRTF list created for IP Mobility work Thread-Index: AcNSNmXW3YRSYVtRQw+dRqmsIf56jg== To: Cc: , , X-OriginalArrivalTime: 24 Jul 2003 22:53:26.0621 (UTC) FILETIME=[649CB8D0:01C35236] Content-Transfer-Encoding: quoted-printable Subject: [Mip4] IRTF list created for IP Mobility work 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 Hello, Following up on the IP Mobility bar BoF that was held at IETF57, we now have a mailing list setup for the work (thanks to Vern). The address for subscribing to the list is: irtf-mobility-charter-request@irtf.org and type subscribe in the body. The next step will be to get a grip on the charter and the scope of the work items. -Basavaraj _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Jul 25 03:38: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 DAA27446 for ; Fri, 25 Jul 2003 03:38: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 19fx9T-0006fl-1X for mip4-archive@odin.ietf.org; Fri, 25 Jul 2003 03:38:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P7c6W0025645 for mip4-archive@odin.ietf.org; Fri, 25 Jul 2003 03:38:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx9S-0006fQ-Rc for mip4-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 03:38: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 DAA27414 for ; Fri, 25 Jul 2003 03:38:02 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fx9Q-00066o-00 for mip4-web-archive@ietf.org; Fri, 25 Jul 2003 03:38:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19fx9L-00066l-00 for mip4-web-archive@ietf.org; Fri, 25 Jul 2003 03:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fx9M-0006c8-Qz; Fri, 25 Jul 2003 03: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 19fx8x-0006V2-0r for mip4@optimus.ietf.org; Fri, 25 Jul 2003 03:37: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 DAA27282 for ; Fri, 25 Jul 2003 03:37:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fx6q-00065s-00 for mip4@ietf.org; Fri, 25 Jul 2003 03:35:24 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19fx6f-000657-00 for mip4@ietf.org; Fri, 25 Jul 2003 03:35:13 -0400 Received: (qmail 22180 invoked from network); 25 Jul 2003 07:34:37 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 25 Jul 2003 07:34:37 -0000 Date: Fri, 25 Jul 2003 09:34:37 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Alpesh , mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Message-Id: <20030725093437.3c38502d.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030724091346.02c1dc10@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> <3F1EFE31.5010801@cisco.com> <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> <3F1EFE31.5010801@cisco.com> <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030724091346.02c1dc10@mira-sjcm-2.cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thursday 24 July 2003, Kent wrote: > At 09:43 AM 7/24/2003 +0200, Henrik Levkowetz wrote: > > > > We could go back to original format of having a Type field which is > > > designated as EXP-MSG-TYPE and rest as opaque. But also > > > show the current format as reference model. > > > > > > Though wondering if conflict between experimentations be required to > > > be avoided? > > > >Personally, I'd say that if an extension is used for experimentation, > >you need to have some amount of control and monitoring of the > >experiment, otherwise you won't get any significant amount of reliable > >data to draw conclusions from. You'd certainly want to eliminate other > >experiments in the same setup, as they could skew or invalidate your > >data. So I'm not even sure that avoiding conflict is advisable, more > >important could be to discover influences in your setup which should not > >really be there. > > > So this means agreement that existing format remain as reference model, > right? Eh - not sure which original format you mean :-) - I think the best would be to use: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Opaque ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Opaque ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >There shouldn't be, I guess, but maybe you remember the query I sent you > >some months ago about use of unassigned extension numbers? This was > >because the number first assigned for one of the UDP tunnelling > >extensions was already being used by some implementations for an > >aaa-keys extension, and we had to re-assign. Apparently some people had > >agreed on those numbers during an interop, and gone ahead and deployed > >products with those numbers. There would have been a much stronger > >incentive to use VSEs when deploying if all interop testing was done > >with a known experimental extension number, I believe. > > > > > Yes, I remember the problem faced before and agree we need to avoid that > in the future. > > A few options: > > 1) Use VSE with Vendor ID 0 "reserved" for pre-standard interop. I'm not in > favor of this at all, just wanted to throw the options out there. Right, I agree. > 2) Add experimental extension types (critical and normal) to the draft as well. > May be useful to have a range of types instead of just one in each category? > Maybe 8 each? Note: seems other protocols have also defined experimental > message types and extensions (ie RADIUS). Right. EAP is doing the same in 2284bis. I originally was thinking 2 or 4 of each, but then I started to think of the situation which DHCP faced after some years of deployment - near exhaustion of the option values - so I thought that it might encourage the use of extensions with subtypes, rather than multiple extensions, to have only one of each. Thoughts? Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Jul 25 04:21: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 EAA28473 for ; Fri, 25 Jul 2003 04:21:58 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxpU-0000lG-Pu for mip4-archive@odin.ietf.org; Fri, 25 Jul 2003 04:21:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6P8LWad002922 for mip4-archive@odin.ietf.org; Fri, 25 Jul 2003 04:21:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxpU-0000l3-Il for mip4-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 04:21: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 EAA28470 for ; Fri, 25 Jul 2003 04: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 19fxp0-0000jz-7u; Fri, 25 Jul 2003 04:21:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19fxoj-0000iW-Dz for mip4@optimus.ietf.org; Fri, 25 Jul 2003 04:20: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 EAA28464 for ; Fri, 25 Jul 2003 04:20:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19fxog-0006OD-00 for mip4@ietf.org; Fri, 25 Jul 2003 04:20:42 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19fxoV-0006NJ-00 for mip4@ietf.org; Fri, 25 Jul 2003 04:20:31 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6P8I6pp025602; Fri, 25 Jul 2003 01:18:06 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (sjc-vpn1-3.cisco.com [10.21.96.3]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJP18906; Fri, 25 Jul 2003 01:13:47 -0700 (PDT) Message-Id: <4.3.2.7.2.20030725005417.02c96ee0@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 25 Jul 2003 01:17:53 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Cc: Alpesh , mip4@ietf.org In-Reply-To: <20030725093437.3c38502d.henrik@levkowetz.com> References: <4.3.2.7.2.20030724091346.02c1dc10@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> <3F1EFE31.5010801@cisco.com> <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> <3F1EFE31.5010801@cisco.com> <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030724091346.02c1dc10@mira-sjcm-2.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 09:34 AM 7/25/2003 +0200, Henrik Levkowetz wrote: >Eh - not sure which original format you mean :-) - I think the best would be >to use: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Opaque ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > Opaque ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > This would be the format of Experimental Message. The one that's in version 00 would be kept as possible way of filling in the fields for Vendor Specific implementations. >I originally was thinking 2 or 4 of each, but then I started to think of the >situation which DHCP faced after some years of deployment - near >exhaustion of the >option values - so I thought that it might encourage the use of extensions >with >subtypes, rather than multiple extensions, to have only one of each. Thoughts? Right, using subtype would be ideal way to conserve type values. The only issue I see is that if we are trying to use Experimental Extensions so pre-draft implementations can use exact formats with only different type value to inter-operate, then this doesn't provide that capability if the new extension does not have subtypes. I don't think that's a big deal and can go with your suggestion of just 1 value for each category with subtypes. Thanks. Kent _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Jul 25 09:13:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03870 for ; Fri, 25 Jul 2003 09:13: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 19g2Ng-0002x2-BW for mip4-archive@odin.ietf.org; Fri, 25 Jul 2003 09:13:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6PDD8A5011339 for mip4-archive@odin.ietf.org; Fri, 25 Jul 2003 09:13:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2Ng-0002wo-6j for mip4-web-archive@optimus.ietf.org; Fri, 25 Jul 2003 09:13: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 JAA03859 for ; Fri, 25 Jul 2003 09:13:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g2Ne-00009i-00 for mip4-web-archive@ietf.org; Fri, 25 Jul 2003 09:13:06 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19g2NY-00009f-00 for mip4-web-archive@ietf.org; Fri, 25 Jul 2003 09:13:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2NZ-0002vj-B5; Fri, 25 Jul 2003 09:13:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19g2Mp-0002vP-9M for mip4@optimus.ietf.org; Fri, 25 Jul 2003 09:12: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 JAA03856 for ; Fri, 25 Jul 2003 09:12:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19g2Mn-00009T-00 for mip4@ietf.org; Fri, 25 Jul 2003 09:12:13 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 19g2Mc-00009M-00 for mip4@ietf.org; Fri, 25 Jul 2003 09:12:02 -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 h6PDApai004491; Fri, 25 Jul 2003 15:10:52 +0200 Date: Fri, 25 Jul 2003 15:10:50 +0200 From: Henrik Levkowetz To: Kent Leung Cc: Alpesh , mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Message-Id: <20030725151050.51ad51b0.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030725005417.02c96ee0@mira-sjcm-2.cisco.com> References: <4.3.2.7.2.20030724091346.02c1dc10@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> <3F1EFE31.5010801@cisco.com> <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> <3F1EFE31.5010801@cisco.com> <4.3.2.7.2.20030723171335.02c33380@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030724091346.02c1dc10@mira-sjcm-2.cisco.com> <4.3.2.7.2.20030725005417.02c96ee0@mira-sjcm-2.cisco.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.3 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,NEW_DOMAIN_EXTENSIONS, 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) X-RAVMilter-Version: 8.4.4(snapshot 20030410) (mailgw.local.ipunplugged.com) 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 Kent, On Friday, 25 Jul 2003, Kent wrote: > At 09:34 AM 7/25/2003 +0200, Henrik Levkowetz wrote: > > >Eh - not sure which original format you mean :-) - I think the best > >would be to use: > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type | Opaque ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Opaque ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > This would be the format of Experimental Message. Ok. > The one that's in version 00 would be kept as possible way of filling > in the fields for Vendor Specific implementations. I see. I'm still a bit doubtful about publishing this format, as it might facilitate experimental stuff leaking out into deployment, though. > > >I originally was thinking 2 or 4 of each, but then I started to think > >of the situation which DHCP faced after some years of deployment - > >near exhaustion of the > >option values - so I thought that it might encourage the use of > >extensions with > >subtypes, rather than multiple extensions, to have only one of each. > >Thoughts? > > > Right, using subtype would be ideal way to conserve type values. The > only issue I see is that if we are trying to use Experimental > Extensions so pre-draft implementations can use exact formats with > only different type value to inter-operate, then this doesn't provide > that capability if the new extension does not have subtypes. True, but only if the existance of only 1 experimental type would make new designs consistently use subtypes for multiple extensions belonging to the same feature ,:-) > I don't think that's a big deal and can go with your suggestion of > just 1 value for each category with subtypes. Ok. I'm open to using more than 1, too, if there is a proper need for it. Regards, Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Jul 28 15:59: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 PAA19091 for ; Mon, 28 Jul 2003 15:59: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 19hE99-000805-6n for mip4-archive@odin.ietf.org; Mon, 28 Jul 2003 15:59:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SJx3n4030752 for mip4-archive@odin.ietf.org; Mon, 28 Jul 2003 15: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 19hE99-0007zv-2P for mip4-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 15: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 PAA19083 for ; Mon, 28 Jul 2003 15:58:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hE97-0007MJ-00 for mip4-web-archive@ietf.org; Mon, 28 Jul 2003 15:59:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hE97-0007MF-00 for mip4-web-archive@ietf.org; Mon, 28 Jul 2003 15: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 19hE97-0007yq-Dl; Mon, 28 Jul 2003 15: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 19hE8o-0007yB-Gt for mip4@optimus.ietf.org; Mon, 28 Jul 2003 15:58: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 PAA19061 for ; Mon, 28 Jul 2003 15:58:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hE8l-0007Li-00 for mip4@ietf.org; Mon, 28 Jul 2003 15:58:39 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19hE8k-0007LL-00 for mip4@ietf.org; Mon, 28 Jul 2003 15:58:38 -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 h6SJvZ222657; Mon, 28 Jul 2003 14:57:35 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T643V>; Mon, 28 Jul 2003 14:57:35 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746A84@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Henrik Levkowetz'" , mip4 Cc: mobile-ip@sunroof.eng.sun.com Date: Mon, 28 Jul 2003 14:57:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35542.7C50B594" Subject: [Mip4] RE: New issue: 3012bis challenges in solicited agent advertisemen ts 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_01C35542.7C50B594 Content-Type: text/plain Hello Henrik, Please see my response inline. Thanks, Jayshree > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, July 23, 2003 10:05 AM > To: mip4 > Cc: mobile-ip@sunroof.eng.sun.com; Bharatia, Jayshree > [RICH1:2H13:EXCH] > Subject: New issue: 3012bis challenges in solicited agent > advertisements > > > Hi, > > We've had some recent interoperability experiences around > 3012 / 3012bis which suggest that there are some cases > involving solicited agent advertisements which are not > currently covered, and which need to be explicitly described. > > Background: > > In 3012bis, a mobility agent generates a new challenge when > it does an unsolicitated agent advertisement. These > challenges are remembered with a history of CHALLENGE_WINDOW > challenges. > > A new challenge value is also produced for individual mobile > nodes when replying with a challenge in a registration > response. The most recently issued challenge is remembered > as part of that particular mobile node's registration data. > > The case where a mobility agent responds with an > advertisement in response to a router solicitation is not > explicitly covered. Such advertisements may be either > unicast or multicast (unsolicited advertisements are > multicast, not unicast). > > Issues: > > * When unicasting an agent advertisement in response to an > agent solicitation, should a new challenge be produced, or > should the most recent challenge generated for unsolicited > agent advertisements be re-sent? > ( If a mobile node for some reason has already used the most recent > challenge sent in an unsolicited agent advertisement, and > the foreign > agent does not (in spite of the proposed SHOULD in the > current draft) > include a new challenge in it's most recent registration > reply, it is > highly advisable that the challenge in a unicast solicitated agent > advertisement is fresh, not a copy of an earlier advertisement > challenge. ) > - Proposal: For unicast advertisements, generate a new > challenge. > > * If a new challenge is produced for a unicast router > advertisement, should it change the advertisement challenge history? > ( This could open up for a DOS attack, where a MN could solicitate > often enough that challenges available for other MNs listening to > regular RAs would only be within the remembered history for a very > short time. ) > - Proposal: Do not remember challenges generated for unicast > agent advertisements as part of the advertisement challenge > history of CHALLENGE_WINDOW challenges. > > * If not, should a new challenge produced for a unicast > router advertisement be used completely analogous with a new > challenge returned to an individual MN in a registration response? > - Proposal: Yes, treat it in the same manner as a challenge > returned in a registration reply. > > * When multicasting a response to an agent solicitation, > should a new challenge be produced, or should the most > recent challenge generated for unsolicited agent > advertisements be re-sent? > ( Again, updating the history of advertisement challenges here could > open up for a DOS attack. Furthermore, as multicast solicited agent > advertisements can be heard by all on the link, not only the > soliciter, and handled as an unsolicited advertisement, they should > behave in the same manner as an unsolicited advertisement. ) > - Proposal: When the response to a solicitation is multicast, > re-use the most recently generated advertisement > challenge. Do not > update or invalidate the history of advertisement challenges. > [JB] I am trying to see the difference between the "multicasted response to an agent solicitation" case vs "unsolicited multicasted agent advertisement". From the above description, it seems you agree that both these cases are handled in similar way. But the proposed text (section 2.1-second paragraph mentioned below) just talks about multicasted response to solicited Agent Advertisement. Why? Also, I am not sure I agree with your statement regarding DOS attack since this may be the case for the "unsolicited multicasted agent advertisement" as well. It will be good if you can provide further clarification on this issue. > > > Proposed text: > > Add at the end of section 2: > > 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 solicited Agent Advertisement is unicast back to the > soliciting > mobile node, it MUST be handled in the same manner as described for > Challenges issued in a Registration Reply. A new Challenge value > MUST be generated and remembered as the most recent > challenge issued > to the mobile node. > > > In section 3.2, change > > 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. > > > Comments? > > Henrik > ------_=_NextPart_001_01C35542.7C50B594 Content-Type: text/html RE: New issue: 3012bis challenges in solicited agent advertisements

Hello Henrik,

Please see my response inline.

Thanks,
Jayshree

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: Wednesday, July 23, 2003 10:05 AM
> To: mip4
> Cc: mobile-ip@sunroof.eng.sun.com; Bharatia, Jayshree
> [RICH1:2H13:EXCH]
> Subject: New issue: 3012bis challenges in solicited agent
> advertisements
>
>
> Hi,
>
> We've had some recent interoperability experiences around
> 3012 / 3012bis which suggest that there are some cases
> involving solicited agent advertisements which are not
> currently covered, and which need to be explicitly described.
>
> Background:
>
>  In 3012bis, a mobility agent generates a new challenge when
> it does an  unsolicitated agent advertisement. These
> challenges are remembered with  a history of CHALLENGE_WINDOW
> challenges.
>
>  A new challenge value is also produced for individual mobile
> nodes when  replying with a challenge in a registration
> response. The most recently  issued challenge is remembered
> as part of that particular mobile node's  registration data.
>
>  The case where a mobility agent responds with an
> advertisement in response  to a router solicitation is not
> explicitly covered. Such advertisements  may be either
> unicast or multicast (unsolicited advertisements are 
> multicast, not unicast).
>
> Issues:
>
>  * When unicasting an agent advertisement in response to an
> agent  solicitation, should a new challenge be produced, or
> should the most  recent challenge generated for unsolicited
> agent advertisements be  re-sent?
>   ( If a mobile node for some reason has already used the most recent
>   challenge sent in an unsolicited agent advertisement, and
> the foreign
>   agent does not (in spite of the proposed SHOULD in the
> current draft)
>   include a new challenge in it's most recent registration
> reply, it is
>   highly advisable that the challenge in a unicast solicitated agent
>   advertisement is fresh, not a copy of an earlier advertisement
>   challenge. ) 
>       - Proposal: For unicast advertisements, generate a new
> challenge.
>      
>  * If a new challenge is produced for a unicast router
> advertisement,  should it change the advertisement challenge history?
>   ( This could open up for a DOS attack, where a MN could solicitate
>   often enough that challenges available for other MNs listening to
>   regular RAs would only be within the remembered history for a very
>   short time. )
>       - Proposal: Do not remember challenges generated for unicast
>         agent advertisements as part of the advertisement challenge
>         history of CHALLENGE_WINDOW challenges.
>
>  * If not, should a new challenge produced for a unicast
> router  advertisement be used completely analogous with a new
> challenge  returned to an individual MN in a registration response?
>       - Proposal: Yes, treat it in the same manner as a challenge
>         returned in a registration reply.
>
>  * When multicasting a response to an agent solicitation,
> should a new  challenge be produced, or should the most
> recent challenge generated  for unsolicited agent
> advertisements be re-sent?
>   ( Again, updating the history of advertisement challenges here could
>   open up for a DOS attack. Furthermore, as multicast solicited agent
>   advertisements can be heard by all on the link, not only the
>   soliciter, and handled as an unsolicited advertisement, they should
>   behave in the same manner as an unsolicited advertisement. )
>       - Proposal: When the response to a solicitation is multicast,
>         re-use the most recently generated advertisement
> challenge. Do not
>         update or invalidate the history of advertisement challenges.
>
[JB] I am trying to see the difference between the "multicasted response to an agent solicitation" case vs "unsolicited multicasted agent advertisement". From the above description, it seems you agree that both these cases are handled in similar way. But the proposed text (section 2.1-second paragraph mentioned below) just talks about multicasted response to solicited Agent Advertisement. Why? Also, I am not sure I agree with your statement regarding DOS attack since this may be the case for the "unsolicited multicasted agent advertisement" as well. It will be good if you can provide further clarification on this issue.

>
>
> Proposed text:
>
> Add at the end of section 2:
>
> 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 solicited Agent Advertisement is unicast back to the
> soliciting
>   mobile node, it MUST be handled in the same manner as described for
>   Challenges issued in a Registration Reply.  A new Challenge value
>   MUST be generated and remembered as the most recent
> challenge issued
>   to the mobile node.
>
>
> In section 3.2, change
>
> 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. 
>
>
> Comments?
>
>       Henrik
>

------_=_NextPart_001_01C35542.7C50B594-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Jul 28 16:24: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 QAA19926 for ; Mon, 28 Jul 2003 16:24: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 19hEXK-0001zy-VU for mip4-archive@odin.ietf.org; Mon, 28 Jul 2003 16:24:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6SKO26A007676 for mip4-archive@odin.ietf.org; Mon, 28 Jul 2003 16: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 19hEXK-0001yv-3v for mip4-web-archive@optimus.ietf.org; Mon, 28 Jul 2003 16: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 QAA19910 for ; Mon, 28 Jul 2003 16:23:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hEXI-0007fw-00 for mip4-web-archive@ietf.org; Mon, 28 Jul 2003 16:24:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hEXH-0007ft-00 for mip4-web-archive@ietf.org; Mon, 28 Jul 2003 16: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 19hEXJ-0001yk-12; Mon, 28 Jul 2003 16: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 19hEWM-0001th-1q for mip4@optimus.ietf.org; Mon, 28 Jul 2003 16:23: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 QAA19875 for ; Mon, 28 Jul 2003 16:22:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hEWK-0007fK-00 for mip4@ietf.org; Mon, 28 Jul 2003 16:23:00 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19hEWJ-0007f3-00 for mip4@ietf.org; Mon, 28 Jul 2003 16:22:59 -0400 Received: (qmail 3520 invoked from network); 28 Jul 2003 20:22:50 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 28 Jul 2003 20:22:50 -0000 Date: Mon, 28 Jul 2003 22:22:49 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: mip4 , mobile-ip@sunroof.eng.sun.com, "Charles E. Perkins" Message-Id: <20030728222249.45b24ec2.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746A84@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746A84@zrc2c000.us.nortel.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 Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: New issue: 3012bis challenges in solicited agent advertisements 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, Comments inline. Regards, Henrik Monday 28 July 2003, Jayshree wrote: > Hello Henrik, > > Please see my response inline. > > Thanks, > Jayshree > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, July 23, 2003 10:05 AM > > To: mip4 > > Cc: mobile-ip@sunroof.eng.sun.com; Bharatia, Jayshree > > [RICH1:2H13:EXCH] > > Subject: New issue: 3012bis challenges in solicited agent > > advertisements > > > > > > Hi, > > > > We've had some recent interoperability experiences around > > 3012 / 3012bis which suggest that there are some cases > > involving solicited agent advertisements which are not > > currently covered, and which need to be explicitly described. > > > > Background: > > > > In 3012bis, a mobility agent generates a new challenge when > > it does an unsolicitated agent advertisement. These > > challenges are remembered with a history of CHALLENGE_WINDOW > > challenges. > > > > A new challenge value is also produced for individual mobile > > nodes when replying with a challenge in a registration > > response. The most recently issued challenge is remembered > > as part of that particular mobile node's registration data. > > > > The case where a mobility agent responds with an > > advertisement in response to a router solicitation is not > > explicitly covered. Such advertisements may be either > > unicast or multicast (unsolicited advertisements are > > multicast, not unicast). > > > > Issues: > > > > * When unicasting an agent advertisement in response to an > > agent solicitation, should a new challenge be produced, or > > should the most recent challenge generated for unsolicited > > agent advertisements be re-sent? > > ( If a mobile node for some reason has already used the most recent > > challenge sent in an unsolicited agent advertisement, and the foreign > > agent does not (in spite of the proposed SHOULD in the current draft) > > include a new challenge in it's most recent registration reply, it is > > highly advisable that the challenge in a unicast solicitated agent > > advertisement is fresh, not a copy of an earlier advertisement > > challenge. ) > > - Proposal: For unicast advertisements, generate a new > > challenge. > > > > * If a new challenge is produced for a unicast router > > advertisement, should it change the advertisement challenge history? > > ( This could open up for a DOS attack, where a MN could solicitate > > often enough that challenges available for other MNs listening to > > regular RAs would only be within the remembered history for a very > > short time. ) > > - Proposal: Do not remember challenges generated for unicast > > agent advertisements as part of the advertisement challenge > > history of CHALLENGE_WINDOW challenges. > > > > * If not, should a new challenge produced for a unicast > > router advertisement be used completely analogous with a new > > challenge returned to an individual MN in a registration response? > > - Proposal: Yes, treat it in the same manner as a challenge > > returned in a registration reply. > > > > * When multicasting a response to an agent solicitation, > > should a new challenge be produced, or should the most > > recent challenge generated for unsolicited agent > > advertisements be re-sent? > > ( Again, updating the history of advertisement challenges here could > > open up for a DOS attack. Furthermore, as multicast solicited agent > > advertisements can be heard by all on the link, not only the > > soliciter, and handled as an unsolicited advertisement, they should > > behave in the same manner as an unsolicited advertisement. ) > > - Proposal: When the response to a solicitation is multicast, > > re-use the most recently generated advertisement challenge. Do not > > update or invalidate the history of advertisement challenges. > > > [JB] I am trying to see the difference between the "multicasted response to > an agent solicitation" case vs "unsolicited multicasted agent > advertisement". From the above description, it seems you agree that both > these cases are handled in similar way. But the proposed text (section > 2.1-second paragraph mentioned below) just talks about multicasted response > to solicited Agent Advertisement. Why? Umm.. no, the proposed text (see below) for section 2.1 has 3 paragraphs, and the third paragraph talks about the case where the response is unicast back to the solicitor, not multicast. Or did I misunderstand you somehow? > Also, I am not sure I agree with your > statement regarding DOS attack since this may be the case for the > "unsolicited multicasted agent advertisement" as well. It will be good if > you can provide further clarification on this issue. No, as long as an attacker cannot provoke too early removal of challenges from the challenge window, there is no problem. Only if the attacker is given a way to provoke premature ageing of the challenges is there a problem. For this reason, we need to describe a way to handle solicited advertisements which doesn't provide such a possibility. I'm not sure I understand where we disagree? > > > > > > > Proposed text: > > > > Add at the end of section 2: > > > > 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 solicited Agent Advertisement is unicast back to the > > soliciting > > mobile node, it MUST be handled in the same manner as described for > > Challenges issued in a Registration Reply. A new Challenge value > > MUST be generated and remembered as the most recent > > challenge issued > > to the mobile node. > > > > > > In section 3.2, change > > > > 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. > > > > > > Comments? > > > > Henrik > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 30 11:53: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 LAA05809 for ; Wed, 30 Jul 2003 11:53: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 19htGB-0005gb-Lm for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 11:53:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFr3Kh021857 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 11:53:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htGB-0005gS-GF for mip4-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11:53: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 LAA05799 for ; Wed, 30 Jul 2003 11:52:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htGA-0001Gx-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 11:53:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htG9-0001Gt-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 11:53:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htG9-0005gH-8Q; Wed, 30 Jul 2003 11:53:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htG3-0005g5-TJ for mip4@optimus.ietf.org; Wed, 30 Jul 2003 11:52: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 LAA05794 for ; Wed, 30 Jul 2003 11:52:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htG2-0001Gq-00 for mip4@ietf.org; Wed, 30 Jul 2003 11:52:54 -0400 Received: from e34.co.us.ibm.com ([32.97.110.132]) by ietf-mx with esmtp (Exim 4.12) id 19htG1-0001Gg-00 for mip4@ietf.org; Wed, 30 Jul 2003 11:52:54 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e34.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6UFqMEh222378; Wed, 30 Jul 2003 11:52:22 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-225-201.mts.ibm.com [9.65.225.201]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6UFqHVC038800; Wed, 30 Jul 2003 09:52:20 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h6UFpDw08681; Wed, 30 Jul 2003 11:51:14 -0400 Message-Id: <200307301551.h6UFpDw08681@cichlid.adsl.duke.edu> To: mip4@ietf.org cc: mobile-ip@sunroof.eng.sun.com Date: Wed, 30 Jul 2003 11:51:13 -0400 From: Thomas Narten Subject: [Mip4] Chairing and status of mip4 WG 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: , As I mentioned in Vienna, I think the proposed MIP4 charter is ready to take to the IESG for their review and will do so shortly. There has been a bit more wordsmithing to its content, so we'll post the updated version to the list shortly. In terms of chairing, Henrik Levkowetz and Pete McCann have agreed to co-chair the new group. I'd like to welcome Henrik and Pete and thank Gabriel, Raj and Phil for their work in chairing the WG up until this point. The new and previous chairs are working together to ensure a smooth transition. At this point, all mip4 related discussion should be taking place on the mip4 mailing list, and should no longer (in general) be cc'ed to the mobileip mailing list. To get on the new list: Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 Thomas _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 30 11:57:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05999 for ; Wed, 30 Jul 2003 11:57:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htK1-0005uk-OF for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 11:57:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UFv1WJ022729 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 11: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 19htK1-0005uW-Jn for mip4-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 11: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 LAA05992 for ; Wed, 30 Jul 2003 11:56:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htK0-0001Iz-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 11:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htJz-0001Iw-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 11:56:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htK0-0005tT-Gl; Wed, 30 Jul 2003 11:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htJf-0005r4-3k for mip4@optimus.ietf.org; Wed, 30 Jul 2003 11:56:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05967 for ; Wed, 30 Jul 2003 11:56:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htJd-0001IS-00 for mip4@ietf.org; Wed, 30 Jul 2003 11:56:37 -0400 Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx with esmtp (Exim 4.12) id 19htJc-0001IH-00 for mip4@ietf.org; Wed, 30 Jul 2003 11:56:36 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h6UFu5Uj044670 for ; Wed, 30 Jul 2003 11:56:05 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-225-201.mts.ibm.com [9.65.225.201]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h6UFu3VC011670 for ; Wed, 30 Jul 2003 09:56:03 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h6UFsxS09191 for ; Wed, 30 Jul 2003 11:55:00 -0400 Message-Id: <200307301555.h6UFsxS09191@cichlid.adsl.duke.edu> To: mip4@ietf.org Date: Wed, 30 Jul 2003 11:54:59 -0400 From: Thomas Narten Subject: [Mip4] 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: , 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. > Mobility security association > A Mobility Security Association is a simplex > connection that serves to authenticate MIPv4 control > 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. > 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. > 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.) > 1. Using the Key Material from the extension, the mobile node > calculates > > key = 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? > 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. 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? 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... > One further detail deserves mention. The Mobility Security > Association to be established between the mobile node and the foreign > 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 between > 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?). Nits: Could use a TOC (see ID nits, http://www.ietf.org/ID-nits.html) > AAA Registration Keys for Mobile IP title doesn't satisfy ID nits? (Not sure AAA will be acceptable to rfc editor). > the Authentication Data need by authentication extensions used in s/need/needed/ ? > 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. > 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)/ > 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/ > 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. > The following steps are performed on the AAA server: AAAL or AAAH? (I assume the former). > 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? > The Generalized MN-FA Key Reply extension supplies a registration key > requested by using one of the subtypes of the Generalized MN-FA Key not a "registration key", but "keying material" > MN-FA Key Reply Subtype Data > An encoded copy of the registration key, along with any > other information needed by the recipient to create the > designated Mobility Security Association. needs better text; this is not a key, its keying material. (do the same throughout document) > 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? > 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. 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? > 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... 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. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 30 12:38: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 MAA07593 for ; Wed, 30 Jul 2003 12:38: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 19htxi-0000Mi-3r for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 12:38:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGc2QK001400 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 12:38:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htxi-0000MV-0I for mip4-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12:38: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 MAA07584 for ; Wed, 30 Jul 2003 12:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htxg-0001gG-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 12:38:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19htxf-0001gD-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 12:37:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htxh-0000Lq-0n; Wed, 30 Jul 2003 12:38:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19htwu-0008WV-Eq for mip4@optimus.ietf.org; Wed, 30 Jul 2003 12:37: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 MAA07543 for ; Wed, 30 Jul 2003 12:37:06 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19htws-0001fT-00 for mip4@ietf.org; Wed, 30 Jul 2003 12:37:11 -0400 Received: from ihemail1.lucent.com ([192.11.222.161] helo=ihemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19htwr-0001eu-00 for mip4@ietf.org; Wed, 30 Jul 2003 12:37:10 -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 h6UGaOh11435; Wed, 30 Jul 2003 11:36:24 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6UGaNY06803; Wed, 30 Jul 2003 11:36:23 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HIUJGH-0001SC-00; Wed, 30 Jul 2003 12:36:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16167.62464.142256.993385@gargle.gargle.HOWL> Date: Wed, 30 Jul 2003 11:36:16 -0500 From: Pete McCann To: Thomas Narten Cc: mip4@ietf.org Subject: [Mip4] Chairing and status of mip4 WG In-Reply-To: <200307301551.h6UFpDw08681@cichlid.adsl.duke.edu> References: <200307301551.h6UFpDw08681@cichlid.adsl.duke.edu> 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, Thomas, all, Thanks for the welcome, and for entrusting Henrik and me with the job of overseeing the important work that needs to get accomplished here in MIP4. My thanks as well to Gabriel, Raj, and Phil for their help so far (I'm sure we'll need more of it in the days and weeks to come). My hope is that the MIP4 working group becomes a place where well-reasoned, focused, and amicable (yes!) discussion produces standards that meet the current deployment needs of Mobile IPv4, without compromising the quality and integrity we expect from Internet protocols. -Pete Thomas Narten writes: > As I mentioned in Vienna, I think the proposed MIP4 charter is ready > to take to the IESG for their review and will do so shortly. There has > been a bit more wordsmithing to its content, so we'll post the updated > version to the list shortly. > > In terms of chairing, Henrik Levkowetz and Pete McCann have agreed to > co-chair the new group. I'd like to welcome Henrik and Pete and thank > Gabriel, Raj and Phil for their work in chairing the WG up until this > point. The new and previous chairs are working together to ensure a > smooth transition. > > At this point, all mip4 related discussion should be taking place on > the mip4 mailing list, and should no longer (in general) be cc'ed to > the mobileip mailing list. To get on the new list: > > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > > Thomas _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 30 12:45:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07777 for ; Wed, 30 Jul 2003 12:45:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hu4U-0000Wk-Lz for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 12:45:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UGj2Cc002020 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 12:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hu4U-0000W1-Hi for mip4-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 12: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 MAA07755 for ; Wed, 30 Jul 2003 12:44:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hu4S-0001iF-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 12:45:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hu4S-0001iC-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 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 19hu4T-0000VP-DM; Wed, 30 Jul 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 19hu3h-0000U7-CK for mip4@optimus.ietf.org; Wed, 30 Jul 2003 12:44: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 MAA07702 for ; Wed, 30 Jul 2003 12:44:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hu3f-0001hy-00 for mip4@ietf.org; Wed, 30 Jul 2003 12:44:11 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19hu3e-0001hX-00 for mip4@ietf.org; Wed, 30 Jul 2003 12:44:10 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6UGh1X17919; Wed, 30 Jul 2003 11:43:01 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T7RKS>; Wed, 30 Jul 2003 11:43:02 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746A8E@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Henrik Levkowetz'" Cc: mip4 , mobile-ip@sunroof.eng.sun.com, "Charles E. Perkins" Date: Wed, 30 Jul 2003 11:43:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C356B9.A3C860A4" Subject: [Mip4] RE: [mobile-ip] Re: New issue: 3012bis challenges in solicited ag ent advertisements 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_01C356B9.A3C860A4 Content-Type: text/plain Hi Henrik, Please see my comments inline. Thanks, Jayshree ... > > [JB] I am trying to see the difference between the "multicasted > > response to an agent solicitation" case vs "unsolicited multicasted > > agent advertisement". From the above description, it seems > you agree > > that both these cases are handled in similar way. But the proposed > > text (section 2.1-second paragraph mentioned below) just > talks about > > multicasted response to solicited Agent Advertisement. Why? > > Umm.. no, the proposed text (see below) for section 2.1 has 3 > paragraphs, and the third paragraph talks about the case > where the response is unicast back to the solicitor, not > multicast. Or did I misunderstand you somehow? > [JB] My question was related to second paragraph (section 2.1) of your proposed text in which you are proposing that if the solicited agent advertisement is multicasted, new challenge value must not be generated. Basically, the intent is to use the challenge sent in an Agent Advertisement for the Registration procedure. Re-using the challenge will solve only certain cases and not all. I can see the potential security problem in this particular case but not sure on the severity because of the challenge mechanism. Any help on this security topic will be appreciated. >... > > > Proposed text: > > > > > > Add at the end of section 2: > > > > > > 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 solicited Agent Advertisement is unicast back to the > > > soliciting > > > mobile node, it MUST be handled in the same manner as > described for > > > Challenges issued in a Registration Reply. A new > Challenge value > > > MUST be generated and remembered as the most recent > > > challenge issued > > > to the mobile node. > > > > > > > > > In section 3.2, change > > > > > > 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. ------_=_NextPart_001_01C356B9.A3C860A4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: New issue: 3012bis challenges in solicited = agent advertisements

Hi Henrik,

Please see my comments inline.

Thanks,
Jayshree

...
> > [JB] I am trying to see the difference = between the "multicasted
> > response to an agent solicitation" = case vs "unsolicited multicasted
> > agent advertisement". From the above = description, it seems
> you agree
> > that both these cases are handled in = similar way. But the proposed
> > text (section 2.1-second paragraph = mentioned below) just
> talks about
> > multicasted response to solicited Agent = Advertisement. Why?
>
> Umm.. no, the proposed text (see below) for = section 2.1 has 3
> paragraphs, and the third paragraph talks about = the case
> where the response is unicast back to the = solicitor, not
> multicast. Or did I misunderstand you = somehow?
>
[JB] My question was related to second paragraph = (section 2.1) of your proposed text in which you are proposing that if = the solicited agent advertisement is multicasted, new challenge value = must not be generated. Basically, the intent is to use the challenge = sent in an Agent Advertisement for the Registration procedure. Re-using = the challenge will solve only certain cases and not all.

I can see the potential security problem in this = particular case but not sure on the severity because of the challenge = mechanism. Any help on this security topic will be = appreciated.

>...
> > > Proposed text:
> > >
> > > Add at the end of section 2:
> > >
> > > 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 solicited Agent = Advertisement is unicast back to the
> > > soliciting
> > >   mobile node, it MUST be = handled in the same manner as
> described for
> > >   Challenges issued in a = Registration Reply.  A new
> Challenge value
> > >   MUST be generated and = remembered as the most recent
> > > challenge issued
> > >   to the mobile = node.
> > >
> > >
> > > In section 3.2, change
> > >
> > > 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.

------_=_NextPart_001_01C356B9.A3C860A4-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 30 16:05: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 QAA16029 for ; Wed, 30 Jul 2003 16:05: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 19hxC3-0001ui-96 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 16:05:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UK536h007338 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 16: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 19hxC3-0001u9-4Q for mip4-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 16: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 QAA16021 for ; Wed, 30 Jul 2003 16:04:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hxC1-0003DS-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 16:05:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hxC0-0003DP-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 16: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 19hxC1-0001tS-AV; Wed, 30 Jul 2003 16: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 19hxBy-0001tD-0s for mip4@optimus.ietf.org; Wed, 30 Jul 2003 16:04: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 QAA16018 for ; Wed, 30 Jul 2003 16:04:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hxBw-0003DM-00 for mip4@ietf.org; Wed, 30 Jul 2003 16:04:56 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19hxBv-0003Cy-00 for mip4@ietf.org; Wed, 30 Jul 2003 16:04:55 -0400 Received: (qmail 3449 invoked from network); 30 Jul 2003 20:04:22 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 30 Jul 2003 20:04:22 -0000 Date: Wed, 30 Jul 2003 22:04:21 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: mip4 , "Charles E. Perkins" Message-Id: <20030730220421.40daac1c.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746A8E@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746A8E@zrc2c000.us.nortel.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 Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in solicited ag ent advertisements 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, comments inline. Regards, Henrik Wednesday 30 July 2003, Jayshree wrote: > Hi Henrik, > > Please see my comments inline. > > Thanks, > Jayshree > > ... > > > [JB] I am trying to see the difference between the "multicasted > > > response to an agent solicitation" case vs "unsolicited > > > multicasted agent advertisement". From the above description, it > > > seems you agree that both these cases are handled in similar way. > > > But the proposed text (section 2.1-second paragraph mentioned > > > below) just talks about multicasted response to solicited Agent > > > Advertisement. Why? > > > > Umm.. no, the proposed text (see below) for section 2.1 has 3 > > paragraphs, and the third paragraph talks about the case > > where the response is unicast back to the solicitor, not > > multicast. Or did I misunderstand you somehow? > > > [JB] My question was related to second paragraph (section 2.1) of your > proposed text in which you are proposing that if the solicited agent > advertisement is multicasted, new challenge value must not be > generated. Basically, the intent is to use the challenge sent in an > Agent Advertisement for the Registration procedure. Re-using the > challenge will solve only certain cases and not all. I think that if the solicited agent adverticement re-uses the most recent challenge from an unsolicited advertisement, there are no unsolved cases, so the proposed text would be good. The only potential problem with the solicited multicast advertisements are that they occur at the command of an uncontrolled entity, and may occur at any rate supportable by the medium. So if the most recent unsolicited challenge was not re-used, but a new generated and used to update the challenge window, a hostile MN could swiftly age out earlier challenges. This is inherently not the case with the unsolicited advertisements, which occur at a fixed rate controlled by the configuration of the mobility agent. Apparently, you think there are unsolved cases beyond this? Could you elaborate on them, please? > I can see the potential security problem in this particular case but > not sure on the severity because of the challenge mechanism. Any help > on this security topic will be appreciated. > >... > > > > Proposed text: > > > > > > > > Add at the end of section 2: > > > > > > > > 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 solicited Agent Advertisement is unicast back to the soliciting > > > > mobile node, it MUST be handled in the same manner as described for > > > > Challenges issued in a Registration Reply. A new Challenge value > > > > MUST be generated and remembered as the most recent challenge issued > > > > to the mobile node. > > > > > > > > > > > > In section 3.2, change > > > > > > > > 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. > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 30 16:56: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 QAA17307 for ; Wed, 30 Jul 2003 16:56: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 19hxzP-0003l4-5f for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 16:56:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UKu33Q014439 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 16:56:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxzP-0003kO-0s for mip4-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 16:56:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17301 for ; Wed, 30 Jul 2003 16:55:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hxzM-0003VH-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 16:56:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hxzL-0003VE-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 16:55:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxzN-0003hu-57; Wed, 30 Jul 2003 16:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hxyb-0003h2-AT for mip4@optimus.ietf.org; Wed, 30 Jul 2003 16:55:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17281 for ; Wed, 30 Jul 2003 16:55:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hxyZ-0003Ur-00 for mip4@ietf.org; Wed, 30 Jul 2003 16:55:11 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19hxyY-0003Ul-00 for mip4@ietf.org; Wed, 30 Jul 2003 16:55:10 -0400 Received: (qmail 3730 invoked from network); 30 Jul 2003 20:54:32 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 30 Jul 2003 20:54:32 -0000 Date: Wed, 30 Jul 2003 22:54:31 +0200 From: Henrik Levkowetz To: Pete McCann Cc: Thomas Narten , mip4@ietf.org Subject: Re: [Mip4] Chairing and status of mip4 WG Message-Id: <20030730225431.481de33c.henrik@levkowetz.com> In-Reply-To: <16167.62464.142256.993385@gargle.gargle.HOWL> References: <200307301551.h6UFpDw08681@cichlid.adsl.duke.edu> <16167.62464.142256.993385@gargle.gargle.HOWL> 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 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, Yes, what more can I say? Pete's said it so well, and has my complete agreement! Henrik Wednesday 30 July 2003, Pete McCann wrote: > > Hi, Thomas, all, > > Thanks for the welcome, and for entrusting Henrik and me with the job > of overseeing the important work that needs to get accomplished here > in MIP4. My thanks as well to Gabriel, Raj, and Phil for their help > so far (I'm sure we'll need more of it in the days and weeks to come). > > My hope is that the MIP4 working group becomes a place where > well-reasoned, focused, and amicable (yes!) discussion produces > standards that meet the current deployment needs of Mobile IPv4, > without compromising the quality and integrity we expect from Internet > protocols. > > -Pete > > Thomas Narten writes: > > As I mentioned in Vienna, I think the proposed MIP4 charter is ready > > to take to the IESG for their review and will do so shortly. There has > > been a bit more wordsmithing to its content, so we'll post the updated > > version to the list shortly. > > > > In terms of chairing, Henrik Levkowetz and Pete McCann have agreed to > > co-chair the new group. I'd like to welcome Henrik and Pete and thank > > Gabriel, Raj and Phil for their work in chairing the WG up until this > > point. The new and previous chairs are working together to ensure a > > smooth transition. > > > > At this point, all mip4 related discussion should be taking place on > > the mip4 mailing list, and should no longer (in general) be cc'ed to > > the mobileip mailing list. To get on the new list: > > > > Mip4 mailing list > > Mip4@ietf.org > > https://www.ietf.org/mailman/listinfo/mip4 > > > > Thomas > > > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 30 17:57: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 RAA19854 for ; Wed, 30 Jul 2003 17:57: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 19hywR-00078p-RX for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 17:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6ULv3nN027450 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 17: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 19hywR-00078f-LS for mip4-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 17: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 RAA19815 for ; Wed, 30 Jul 2003 17:56:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hywO-00049O-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 17:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hywO-00049L-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 17: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 19hywP-00075V-DI; Wed, 30 Jul 2003 17: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 19hyvy-00072l-Hy for mip4@optimus.ietf.org; Wed, 30 Jul 2003 17:56: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 RAA19804 for ; Wed, 30 Jul 2003 17:56:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hyvv-00048w-00 for mip4@ietf.org; Wed, 30 Jul 2003 17:56:31 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19hyvv-00048a-00 for mip4@ietf.org; Wed, 30 Jul 2003 17:56:31 -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 h6ULtSX06651; Wed, 30 Jul 2003 16:55:29 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T7YWK>; Wed, 30 Jul 2003 16:55:29 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Henrik Levkowetz'" , mip4 Cc: mobile-ip@sunroof.eng.sun.com, "Jayshree Bharatia" Date: Wed, 30 Jul 2003 16:55:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C356E5.0105AEB8" Subject: [Mip4] RE: [mobile-ip] New issue: 3012bis challenges in solicited agent advertisements 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_01C356E5.0105AEB8 Content-Type: text/plain Hi Henrik, I think the issue at hand is already addressed in the standard as follows: 1. If the Foreign Agent is RFC3012(RFC3012-bis) compliant it sends a new Challenge in RRP and then, as you said, we wont see this issue. 2. On the other hand, it is the responsibility of the FA to ensure that the challenge it sends is a fresh one; especially when sent to a specific MN. RFC3012 section 2.0, requires the FA to sends a challenge that can be used by the MN to: - Provide a replay protection - authenticate the message " 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. " Regards, Ahmad > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, July 23, 2003 10:05 AM > To: mip4 > Cc: mobile-ip@sunroof.eng.sun.com; Bharatia, Jayshree > [RICH1:2H13:EXCH] > Subject: [mobile-ip] New issue: 3012bis challenges in > solicited agent advertisements > > > Hi, > > We've had some recent interoperability experiences around > 3012 / 3012bis which suggest that there are some cases > involving solicited agent advertisements which are not > currently covered, and which need to be explicitly described. > > Background: > > In 3012bis, a mobility agent generates a new challenge when > it does an unsolicitated agent advertisement. These > challenges are remembered with a history of CHALLENGE_WINDOW > challenges. > > A new challenge value is also produced for individual mobile > nodes when replying with a challenge in a registration > response. The most recently issued challenge is remembered > as part of that particular mobile node's registration data. > > The case where a mobility agent responds with an > advertisement in response to a router solicitation is not > explicitly covered. Such advertisements may be either > unicast or multicast (unsolicited advertisements are > multicast, not unicast). > > Issues: > > * When unicasting an agent advertisement in response to an > agent solicitation, should a new challenge be produced, or > should the most recent challenge generated for unsolicited > agent advertisements be re-sent? > ( If a mobile node for some reason has already used the most recent > challenge sent in an unsolicited agent advertisement, and > the foreign > agent does not (in spite of the proposed SHOULD in the > current draft) > include a new challenge in it's most recent registration > reply, it is > highly advisable that the challenge in a unicast solicitated agent > advertisement is fresh, not a copy of an earlier advertisement > challenge. ) > - Proposal: For unicast advertisements, generate a new > challenge. > > * If a new challenge is produced for a unicast router > advertisement, should it change the advertisement challenge history? > ( This could open up for a DOS attack, where a MN could solicitate > often enough that challenges available for other MNs listening to > regular RAs would only be within the remembered history for a very > short time. ) > - Proposal: Do not remember challenges generated for unicast > agent advertisements as part of the advertisement challenge > history of CHALLENGE_WINDOW challenges. > > * If not, should a new challenge produced for a unicast > router advertisement be used completely analogous with a new > challenge returned to an individual MN in a registration response? > - Proposal: Yes, treat it in the same manner as a challenge > returned in a registration reply. > > * When multicasting a response to an agent solicitation, > should a new challenge be produced, or should the most > recent challenge generated for unsolicited agent > advertisements be re-sent? > ( Again, updating the history of advertisement challenges here could > open up for a DOS attack. Furthermore, as multicast solicited agent > advertisements can be heard by all on the link, not only the > soliciter, and handled as an unsolicited advertisement, they should > behave in the same manner as an unsolicited advertisement. ) > - Proposal: When the response to a solicitation is multicast, > re-use the most recently generated advertisement > challenge. Do not > update or invalidate the history of advertisement challenges. > > > > Proposed text: > > Add at the end of section 2: > > 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 solicited Agent Advertisement is unicast back to the > soliciting > mobile node, it MUST be handled in the same manner as described for > Challenges issued in a Registration Reply. A new Challenge value > MUST be generated and remembered as the most recent > challenge issued > to the mobile node. > > > In section 3.2, change > > 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. > > > Comments? > > Henrik > ------_=_NextPart_001_01C356E5.0105AEB8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] New issue: 3012bis challenges in solicited agent = advertisements

Hi Henrik,

I think the issue at hand is already addressed in the = standard as follows:

1. If the Foreign Agent is RFC3012(RFC3012-bis) = compliant it sends a new Challenge in RRP and then, as you said, we = wont see this issue.

2. On the other hand, it is the responsibility of the = FA to ensure that the challenge it sends is a fresh one; especially = when sent to a specific MN. RFC3012 section 2.0, requires the FA to = sends a challenge that can be used by the MN to:

   - Provide a replay protection
   - authenticate the message

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

Regards,
Ahmad


> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] =
> Sent: Wednesday, July 23, 2003 10:05 AM
> To: mip4
> Cc: mobile-ip@sunroof.eng.sun.com; Bharatia, = Jayshree
> [RICH1:2H13:EXCH]
> Subject: [mobile-ip] New issue: 3012bis = challenges in
> solicited agent advertisements
>
>
> Hi,
>
> We've had some recent interoperability = experiences around
> 3012 / 3012bis which suggest that there are = some cases
> involving solicited agent advertisements which = are not
> currently covered, and which need to be = explicitly described.
>
> Background:
>
>  In 3012bis, a mobility agent generates a = new challenge when
> it does an  unsolicitated agent = advertisement. These
> challenges are remembered with  a history = of CHALLENGE_WINDOW
> challenges.
>
>  A new challenge value is also produced = for individual mobile
> nodes when  replying with a challenge in a = registration
> response. The most recently  issued = challenge is remembered
> as part of that particular mobile node's  = registration data.
>
>  The case where a mobility agent responds = with an
> advertisement in response  to a router = solicitation is not
> explicitly covered. Such advertisements  = may be either
> unicast or multicast (unsolicited = advertisements are 
> multicast, not unicast).
>
> Issues:
>
>  * When unicasting an agent advertisement = in response to an
> agent  solicitation, should a new = challenge be produced, or
> should the most  recent challenge = generated for unsolicited
> agent advertisements be  re-sent?
>   ( If a mobile node for some reason = has already used the most recent
>   challenge sent in an unsolicited = agent advertisement, and
> the foreign
>   agent does not (in spite of the = proposed SHOULD in the
> current draft)
>   include a new challenge in it's = most recent registration
> reply, it is
>   highly advisable that the challenge = in a unicast solicitated agent
>   advertisement is fresh, not a copy = of an earlier advertisement
>   challenge. ) 
>       - Proposal: For = unicast advertisements, generate a new
> challenge.
>      
>  * If a new challenge is produced for a = unicast router
> advertisement,  should it change the = advertisement challenge history?
>   ( This could open up for a DOS = attack, where a MN could solicitate
>   often enough that challenges = available for other MNs listening to
>   regular RAs would only be within = the remembered history for a very
>   short time. )
>       - Proposal: Do = not remember challenges generated for unicast
>         agent = advertisements as part of the advertisement challenge
>         history = of CHALLENGE_WINDOW challenges.
>
>  * If not, should a new challenge produced = for a unicast
> router  advertisement be used completely = analogous with a new
> challenge  returned to an individual MN in = a registration response?
>       - Proposal: Yes, = treat it in the same manner as a challenge
>         returned = in a registration reply.
>
>  * When multicasting a response to an = agent solicitation,
> should a new  challenge be produced, or = should the most
> recent challenge generated  for = unsolicited agent
> advertisements be re-sent?
>   ( Again, updating the history of = advertisement challenges here could
>   open up for a DOS attack. = Furthermore, as multicast solicited agent
>   advertisements can be heard by all = on the link, not only the
>   soliciter, and handled as an = unsolicited advertisement, they should
>   behave in the same manner as an = unsolicited advertisement. )
>       - Proposal: When = the response to a solicitation is multicast,
>         re-use = the most recently generated advertisement
> challenge. Do not
>         update or = invalidate the history of advertisement challenges.
>
>
>
> Proposed text:
>
> Add at the end of section 2:
>
> 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 solicited Agent = Advertisement is unicast back to the
> soliciting
>   mobile node, it MUST be handled in = the same manner as described for
>   Challenges issued in a Registration = Reply.  A new Challenge value
>   MUST be generated and remembered as = the most recent
> challenge issued
>   to the mobile node.
>
>
> In section 3.2, change
>
> 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. 
>
>
> Comments?
>
>       Henrik
>

------_=_NextPart_001_01C356E5.0105AEB8-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Jul 30 18:19: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 SAA21817 for ; Wed, 30 Jul 2003 18:19: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 19hzHi-0008Hd-KC for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 18:19:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6UMJ2hF031837 for mip4-archive@odin.ietf.org; Wed, 30 Jul 2003 18:19:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hzHi-0008HQ-GK for mip4-web-archive@optimus.ietf.org; Wed, 30 Jul 2003 18:19:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21814 for ; Wed, 30 Jul 2003 18:18:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hzHf-0004RO-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 18:18:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19hzHf-0004RL-00 for mip4-web-archive@ietf.org; Wed, 30 Jul 2003 18:18:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hzHh-0008Gj-By; Wed, 30 Jul 2003 18:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19hzHM-0008Ft-Fa for mip4@optimus.ietf.org; Wed, 30 Jul 2003 18:18: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 SAA21807 for ; Wed, 30 Jul 2003 18:18:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19hzHJ-0004R6-00 for mip4@ietf.org; Wed, 30 Jul 2003 18:18:37 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19hzHI-0004Qg-00 for mip4@ietf.org; Wed, 30 Jul 2003 18:18:36 -0400 Received: (qmail 4373 invoked from network); 30 Jul 2003 22:18:00 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 30 Jul 2003 22:18:00 -0000 Date: Thu, 31 Jul 2003 00:17:59 +0200 From: Henrik Levkowetz To: "Ahmad Muhanna" Cc: mip4 , "Jayshree Bharatia" Message-Id: <20030731001759.6ba28532.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: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [mobile-ip] New issue: 3012bis challenges in solicited agent advertisements 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 Wednesday 30 July 2003, Ahmad wrote: > Hi Henrik, > > I think the issue at hand is already addressed in the standard as follows: > > 1. If the Foreign Agent is RFC3012(RFC3012-bis) compliant it sends a new > Challenge in RRP and then, as you said, we wont see this issue. No, unfortunately not. 3012bis sayst that an FA SHOULD (not MUST) provide a new challenge in the registration reply. > 2. On the other hand, it is the responsibility of the FA to ensure that the > challenge it sends is a fresh one; especially when sent to a specific MN. > RFC3012 section 2.0, requires the FA to sends a challenge that can be used > by the MN to: > - Provide a replay protection > - authenticate the message > > " > 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. > " This still does not provide any guidance on how specifically to handle solicited agent advertisements. As we've come across this issue as an interoperability problem in shipping implementations that follow the current 3012bis, it seems prudent to specify how to handle the situation, no? Regards, Henrik > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, July 23, 2003 10:05 AM > > To: mip4 > > Cc: mobile-ip@sunroof.eng.sun.com; Bharatia, Jayshree > > [RICH1:2H13:EXCH] > > Subject: [mobile-ip] New issue: 3012bis challenges in > > solicited agent advertisements > > > > > > Hi, > > > > We've had some recent interoperability experiences around > > 3012 / 3012bis which suggest that there are some cases > > involving solicited agent advertisements which are not > > currently covered, and which need to be explicitly described. > > > > Background: > > > > In 3012bis, a mobility agent generates a new challenge when > > it does an unsolicitated agent advertisement. These > > challenges are remembered with a history of CHALLENGE_WINDOW > > challenges. > > > > A new challenge value is also produced for individual mobile > > nodes when replying with a challenge in a registration > > response. The most recently issued challenge is remembered > > as part of that particular mobile node's registration data. > > > > The case where a mobility agent responds with an > > advertisement in response to a router solicitation is not > > explicitly covered. Such advertisements may be either > > unicast or multicast (unsolicited advertisements are > > multicast, not unicast). > > > > Issues: > > > > * When unicasting an agent advertisement in response to an > > agent solicitation, should a new challenge be produced, or > > should the most recent challenge generated for unsolicited > > agent advertisements be re-sent? > > ( If a mobile node for some reason has already used the most recent > > challenge sent in an unsolicited agent advertisement, and > > the foreign > > agent does not (in spite of the proposed SHOULD in the > > current draft) > > include a new challenge in it's most recent registration > > reply, it is > > highly advisable that the challenge in a unicast solicitated agent > > advertisement is fresh, not a copy of an earlier advertisement > > challenge. ) > > - Proposal: For unicast advertisements, generate a new > > challenge. > > > > * If a new challenge is produced for a unicast router > > advertisement, should it change the advertisement challenge history? > > ( This could open up for a DOS attack, where a MN could solicitate > > often enough that challenges available for other MNs listening to > > regular RAs would only be within the remembered history for a very > > short time. ) > > - Proposal: Do not remember challenges generated for unicast > > agent advertisements as part of the advertisement challenge > > history of CHALLENGE_WINDOW challenges. > > > > * If not, should a new challenge produced for a unicast > > router advertisement be used completely analogous with a new > > challenge returned to an individual MN in a registration response? > > - Proposal: Yes, treat it in the same manner as a challenge > > returned in a registration reply. > > > > * When multicasting a response to an agent solicitation, > > should a new challenge be produced, or should the most > > recent challenge generated for unsolicited agent > > advertisements be re-sent? > > ( Again, updating the history of advertisement challenges here could > > open up for a DOS attack. Furthermore, as multicast solicited agent > > advertisements can be heard by all on the link, not only the > > soliciter, and handled as an unsolicited advertisement, they should > > behave in the same manner as an unsolicited advertisement. ) > > - Proposal: When the response to a solicitation is multicast, > > re-use the most recently generated advertisement > > challenge. Do not > > update or invalidate the history of advertisement challenges. > > > > > > > > Proposed text: > > > > Add at the end of section 2: > > > > 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 solicited Agent Advertisement is unicast back to the > > soliciting > > mobile node, it MUST be handled in the same manner as described for > > Challenges issued in a Registration Reply. A new Challenge value > > MUST be generated and remembered as the most recent > > challenge issued > > to the mobile node. > > > > > > In section 3.2, change > > > > 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. > > > > > > Comments? > > > > Henrik > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Jul 31 15:09: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 PAA09178 for ; Thu, 31 Jul 2003 15:09: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 19iInS-0000gt-Gp for mip4-archive@odin.ietf.org; Thu, 31 Jul 2003 15:09:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VJ96Q3002653 for mip4-archive@odin.ietf.org; Thu, 31 Jul 2003 15:09:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iInS-0000gi-8t for mip4-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 15:09: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 PAA09127 for ; Thu, 31 Jul 2003 15:09:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iInP-0006fW-00 for mip4-web-archive@ietf.org; Thu, 31 Jul 2003 15:09:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iInO-0006fS-00 for mip4-web-archive@ietf.org; Thu, 31 Jul 2003 15:09:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iInN-0000fL-2o; Thu, 31 Jul 2003 15:09:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iIme-0000c5-Jp for mip4@optimus.ietf.org; Thu, 31 Jul 2003 15:08: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 PAA09034 for ; Thu, 31 Jul 2003 15:08:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iImb-0006f5-00 for mip4@ietf.org; Thu, 31 Jul 2003 15:08:13 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19iIma-0006ew-00 for mip4@ietf.org; Thu, 31 Jul 2003 15:08:12 -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 h6VJ7Va02671; Thu, 31 Jul 2003 14:07:31 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T81PC>; Thu, 31 Jul 2003 14:07:31 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746A9E@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Pete McCann'" Cc: "'Basavaraj.Patil@nokia.com'" , "'gab@sun.com'" , "'mip4@ietf.org'" Date: Thu, 31 Jul 2003 14:07:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35796.F773F12C" Subject: [Mip4] RE: [mobile-ip] Comments on 3012bis Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , 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_01C35796.F773F12C Content-Type: text/plain Hello Pete, I have revised the terminology for the "previously used challenge" for section 1.1 as below: "previously used challenge: The challenge is previously used challenge if the Mobile Node sent the same challenge to the Foreign Agent in a previous Registration Request, and that previous Registration Request passed all validity checks performed by the Foreign Agent. The Foreign Agent may not be able to keep records for all previously used challenges, but see section 3.2 for minimal requirements." I believe we won't be requiring terminology "stale challenge" since it is not used anywhere else in the document. Also, there won't be any changes required on current definition of "STALE_CHALLENGE". Let me know if you have any comments/suggestions. Regards, Jayshree > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Wednesday, July 16, 2003 7:59 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'Basavaraj.Patil@nokia.com'; 'gab@sun.com'; > 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: [mobile-ip] Comments on 3012bis > > > > Hi, Jayshree, > > The issue is that the text says you shall reject previously > used challenges (in all cases but retransmissions of valid > requests). If "previously used" includes RRQs that weren't > validated, then it is possible for an attacker to use them up > before the MN can register. > > -Pete > > > Jayshree Bharatia writes: > > Pete, > > > > I am not sure I understand your concern well. Can you > please clarify what > risks are associated if the malicious > node consumes "previously used > challenges". > > > > Thanks, > > Jayshree > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Friday, July 11, 2003 9:53 AM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: 'Basavaraj.Patil@nokia.com'; 'gab@sun.com'; > > > 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: [mobile-ip] Comments on 3012bis > > > > > > > > > > > > Hi, Jayshree, > > > > > > One point below... > > > > > > Jayshree Bharatia writes: > > > > > No, it is possible to reuse the challenge in a > retransmitted > > > > > registration request, as outlined in Section 3.2. Under my > > > > > reading of that section a retransmission of a Challenge is > > > > > still a "previously used" challenge, even though the Reply > > > > > has not been sent/received. Note that this is > different from > > > > > a "stale challenge" which is one that has been used in a > > > > > request, validated by the FA, and for which a Reply > was sent > > > > > to the MN. I would like to keep this distinction in the > > > > > definitions. Otherwise, I think you will need to re-write > > > > > some of the text in Section 3.2. > > > > > > > > > [JB] I agree that the differentiation is based on whether > > > the FA has sent > corresponding Registration Reply to the MN > > > or not. If the FA has already > sent the reply, and the MN > > > sends the same challenge in the new Registration > Request, > > > it will be "stale challenge". Otherwise, if it will be just > > > > "previously used challenge". If we have agreement on this, > > > I like to propose > the following: > 1. The new (proposed > > > earlier) text will still be valid for the "stale > > > > challenge" terminology. > 2. Add new definition called > > > "previously used challenge" with the following > description > > > for section 1.1: > "previously used challenge: Any challenge > > > that has been used by the Mobile > Node in the previous > > > Registration Request" > > > > > I notice that you have additional statement saying "and > > > that previous > Registration Request passed all checks prior > > > to forwarding to the HA". I > would rather not specify where > > > exactly the Registration Request may be > getting processed > > > once it is received at the FA. It may be forwarded to AAA > > > > or HA. Also, even if it doesn't passes all checks, it is > > > still considered as > a "previously used challenge". > > > > > > But I think this opens up a denial of service attack, where > > > malicious nodes can consume challenges on behalf of other > > > nodes on the same link. If you don't at least check the > > > MN-AAA or MN-FA authentication on the Challenge, you should > > > not mark it as "previously used" for that mobile. That's why > > > I put the language about passing validity checks at the FA. > > > This could be consultation of a AAA interface or verification > > > of the MN-FA auth extension---I was intentionally vague > about that. > > > > > -Pete > > ------_=_NextPart_001_01C35796.F773F12C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Comments on 3012bis

Hello Pete,

I have revised the terminology for the = "previously used challenge" for section 1.1 as below:

"previously used challenge: The challenge is = previously used challenge if the Mobile Node sent the same challenge to = the Foreign Agent in a previous Registration Request, and that previous = Registration Request passed all validity checks performed by the = Foreign Agent. The Foreign Agent may not be able to keep records for = all previously used challenges, but see section 3.2 for minimal = requirements."

I believe we won't be requiring terminology = "stale challenge" since it is not used anywhere else in the = document. Also, there won't be any changes required on current = definition of "STALE_CHALLENGE".

Let me know if you have any = comments/suggestions.

Regards,
Jayshree

> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Wednesday, July 16, 2003 7:59 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'Basavaraj.Patil@nokia.com'; 'gab@sun.com'; =
> 'mobile-ip@sunroof.eng.sun.com'
> Subject: RE: [mobile-ip] Comments on = 3012bis
>
>
>
> Hi, Jayshree,
>
> The issue is that the text says you shall = reject previously
> used challenges (in all cases but = retransmissions of valid
> requests).  If "previously used" = includes RRQs that weren't
> validated, then it is possible for an attacker = to use them up
> before the MN can register.
>
> -Pete
>
>
> Jayshree Bharatia writes:
>  > Pete,
>  >
>  > I am not sure I understand your = concern well. Can you
> please clarify what  > risks are = associated if the malicious
> node consumes "previously used  > = challenges".
>  >
>  > Thanks,
>  > Jayshree
>  > > -----Original = Message-----
>  > > From: Pete McCann [mailto:mccap@lucent.com]
>  > > Sent: Friday, July 11, 2003 = 9:53 AM
>  > > To: Bharatia, Jayshree = [RICH1:2H13:EXCH]
>  > > Cc: = 'Basavaraj.Patil@nokia.com'; 'gab@sun.com';
>  > > = 'mobile-ip@sunroof.eng.sun.com'
>  > > Subject: RE: [mobile-ip] = Comments on 3012bis
>  > >
>  > >
>  > >
>  > > Hi, Jayshree,
>  > >
>  > > One point below...
>  > >
>  > > Jayshree Bharatia = writes:
>  > >  > > No, it is = possible to reuse the challenge in a
> retransmitted
>  > >  > > registration = request, as outlined in Section 3.2.  Under my
>  > >  > > reading of that = section a retransmission of a Challenge is
>  > >  > > still a = "previously used" challenge, even though the Reply
>  > >  > > has not been = sent/received.  Note that this is
> different from
>  > >  > > a "stale = challenge" which is one that has been used in a
>  > >  > > request, = validated by the FA, and for which a Reply
> was sent
>  > >  > > to the = MN.  I would like to keep this distinction in the
>  > >  > > = definitions.  Otherwise, I think you will need to re-write
>  > >  > > some of the = text in Section 3.2.
>  > >  > >
>  > >  > [JB] I agree that = the differentiation is based on whether
>  > > the FA has sent  > = corresponding Registration Reply to the MN
>  > > or not. If the FA has = already  > sent the reply, and the MN
>  > > sends the same challenge in the = new Registration  > Request,
>  > > it will be "stale = challenge". Otherwise, if it will be just 
>  > > > "previously used = challenge". If we have agreement on this,
>  > > I like to propose  > = the following:  > 1. The new (proposed
>  > > earlier) text will still be = valid for the "stale  >
>  > > challenge" = terminology.  > 2. Add new definition called
>  > > "previously used = challenge" with the following  > description
>  > > for section 1.1:  > = "previously used challenge: Any challenge
>  > > that has been used by the = Mobile  > Node in the previous
>  > > Registration = Request"  >
>  > >  > I notice that you = have additional statement saying "and
>  > > that previous  > = Registration Request passed all checks prior
>  > > to forwarding to the HA". = I  > would rather not specify where
>  > > exactly the Registration = Request may be  > getting processed
>  > > once it is received at the FA. = It may be forwarded to AAA  >
>  > > or HA. Also, even if it doesn't = passes all checks, it is
>  > > still considered as  > = a "previously used challenge".
>  > >
>  > > But I think this opens up a = denial of service attack, where
>  > > malicious nodes can consume = challenges on behalf of other
>  > > nodes on the same link.  = If you don't at least check the
>  > > MN-AAA or MN-FA authentication = on the Challenge, you should
>  > > not mark it as "previously = used" for that mobile.  That's why
>  > > I put the language about = passing validity checks at the FA. 
>  > > This could be consultation of a = AAA interface or verification
>  > > of the MN-FA auth extension---I = was intentionally vague
> about that.  > >
>  > > -Pete
>
>

------_=_NextPart_001_01C35796.F773F12C-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Jul 31 16:02: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 QAA12164 for ; Thu, 31 Jul 2003 16:02: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 19iJdA-0002uk-Om for mip4-archive@odin.ietf.org; Thu, 31 Jul 2003 16:02:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VK2WvZ011201 for mip4-archive@odin.ietf.org; Thu, 31 Jul 2003 16: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 19iJdA-0002ua-Ja for mip4-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 16: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 QAA12153 for ; Thu, 31 Jul 2003 16:02: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 19iJcf-0002sy-Ld; Thu, 31 Jul 2003 16: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 19iJby-0002si-Ar for mip4@optimus.ietf.org; Thu, 31 Jul 2003 16:01: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 QAA12129 for ; Thu, 31 Jul 2003 16:01:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJbw-0007Cl-00 for mip4@ietf.org; Thu, 31 Jul 2003 16:01:16 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19iJbv-0007CQ-00 for mip4@ietf.org; Thu, 31 Jul 2003 16:01: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 h6VK0Da16109; Thu, 31 Jul 2003 15:00:13 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T8FWL>; Thu, 31 Jul 2003 15:00:13 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746AA0@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Henrik Levkowetz'" Cc: mip4 , "Charles E. Perkins" Date: Thu, 31 Jul 2003 15:00:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3579E.557E2CCC" Subject: [Mip4] RE: [mobile-ip] Re: New issue: 3012bis challenges in solicited ag ent advertisements 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_01C3579E.557E2CCC Content-Type: text/plain Henrik, I am trying to understand the problem space of the issue you have raised on the mailing list. At first glace, it seems the issue is related to "SHOULD" terminology for sending the Registration Reply. But then you have mentioned security issues associated with it. Your current proposal for the multicasted agent advertisement (sent in response of agent solicitation) is to reuse the challenge from the previous unsolicited agent advertisement. It's not clear to me how this solution really solves the problem. Aging out the challenge may not be very severe since the message has been multicasted to other hosts as well. Also, by keeping the same challenge, the Mobile Node will run out of challenge values for the registration. It will be helpful if you can just explain the scenario which you are considering and the relevant issue. Thanks, Jayshree > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, July 30, 2003 3:04 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: mip4; Charles E. Perkins > Subject: Re: [mobile-ip] Re: New issue: 3012bis challenges in > solicited ag ent advertisements > > > Hi Jayshree, > > comments inline. > > Regards, > Henrik > > Wednesday 30 July 2003, Jayshree wrote: > > Hi Henrik, > > > > Please see my comments inline. > > > > Thanks, > > Jayshree > > > > ... > > > > [JB] I am trying to see the difference between the "multicasted > > > > response to an agent solicitation" case vs "unsolicited > > > > multicasted agent advertisement". From the above > description, it > > > > seems you agree that both these cases are handled in > similar way. > > > > But the proposed text (section 2.1-second paragraph mentioned > > > > below) just talks about multicasted response to solicited Agent > > > > Advertisement. Why? > > > > > > Umm.. no, the proposed text (see below) for section 2.1 has 3 > > > paragraphs, and the third paragraph talks about the case > where the > > > response is unicast back to the solicitor, not multicast. > Or did I > > > misunderstand you somehow? > > > > > [JB] My question was related to second paragraph (section > 2.1) of your > > proposed text in which you are proposing that if the > solicited agent > > advertisement is multicasted, new challenge value must not be > > generated. Basically, the intent is to use the challenge sent in an > > Agent Advertisement for the Registration procedure. Re-using the > > challenge will solve only certain cases and not all. > > I think that if the solicited agent adverticement re-uses the > most recent challenge from an unsolicited advertisement, > there are no unsolved cases, so the proposed text would be > good. The only potential problem with the solicited multicast > advertisements are that they occur at the command of an > uncontrolled entity, and may occur at any rate supportable by > the medium. So if the most recent unsolicited challenge was > not re-used, but a new generated and used to update the > challenge window, a hostile MN could swiftly age out earlier > challenges. This is inherently not the case with the > unsolicited advertisements, which occur at a fixed rate > controlled by the configuration of the > mobility agent. > > Apparently, you think there are unsolved cases beyond this? Could > you elaborate on them, please? > > > I can see the potential security problem in this particular > case but > > not sure on the severity because of the challenge > mechanism. Any help > > on this security topic will be appreciated. > > >... > > > > > Proposed text: > > > > > > > > > > Add at the end of section 2: > > > > > > > > > > 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 solicited Agent Advertisement is unicast > back to the soliciting > > > > > mobile node, it MUST be handled in the same manner > as described for > > > > > Challenges issued in a Registration Reply. A new > Challenge value > > > > > MUST be generated and remembered as the most recent > challenge issued > > > > > to the mobile node. > > > > > > > > > > > > > > > In section 3.2, change > > > > > > > > > > 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. > > > > > ------_=_NextPart_001_01C3579E.557E2CCC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: New issue: 3012bis challenges in solicited = ag ent advertisements

Henrik,

I am trying to understand the problem space of the = issue you have raised on the mailing list. At first glace, it seems the = issue is related to "SHOULD" terminology for sending the = Registration Reply. But then you have mentioned security issues = associated with it. Your current proposal for the multicasted agent = advertisement (sent in response of agent solicitation) is to reuse the = challenge from the previous unsolicited agent advertisement. It's not = clear to me how this solution really solves the problem. Aging out the = challenge may not be very severe since the message has been multicasted = to other hosts as well. Also, by keeping the same challenge, the Mobile = Node will run out of challenge values for the registration.

It will be helpful if you can just explain the = scenario which you are considering and the relevant issue.

Thanks,
Jayshree

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] =
> Sent: Wednesday, July 30, 2003 3:04 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: mip4; Charles E. Perkins
> Subject: Re: [mobile-ip] Re: New issue: 3012bis = challenges in
> solicited ag ent advertisements
>
>
> Hi Jayshree,
>
>       comments = inline.
>
>       Regards,
>       =         Henrik
>
> Wednesday 30 July 2003, Jayshree wrote:
> > Hi Henrik,
> >
> > Please see my comments inline.
> >
> > Thanks,
> > Jayshree
> >
> > ...
> > > > [JB] I am trying to see the = difference between the "multicasted
> > > > response to an agent = solicitation" case vs "unsolicited
> > > > multicasted agent = advertisement". From the above
> description, it
> > > > seems you agree that both these = cases are handled in
> similar way.
> > > > But the proposed text (section = 2.1-second paragraph mentioned
> > > > below) just talks about = multicasted response to solicited Agent
> > > > Advertisement. Why?
> > >
> > > Umm.. no, the proposed text (see = below) for section 2.1 has 3
> > > paragraphs, and the third paragraph = talks about the case
> where the
> > > response is unicast back to the = solicitor, not multicast.
> Or did I
> > > misunderstand you somehow?
> > >
> > [JB] My question was related to second = paragraph (section
> 2.1) of your
> > proposed text in which you are proposing = that if the
> solicited agent
> > advertisement is multicasted, new = challenge value must not be
> > generated. Basically, the intent is to use = the challenge sent in an
> > Agent Advertisement for the Registration = procedure. Re-using the
> > challenge will solve only certain cases = and not all.
>
> I think that if the solicited agent = adverticement re-uses the
> most recent challenge from an unsolicited = advertisement,
> there are no unsolved cases, so the proposed = text would be
> good. The only potential problem with the = solicited multicast
> advertisements are that they occur at the = command of an
> uncontrolled entity, and may occur at any rate = supportable by
> the medium. So if the most recent unsolicited = challenge was
> not re-used, but a new generated and used to = update the
> challenge window, a hostile MN could swiftly = age out earlier
> challenges. This is inherently not the case = with the
> unsolicited advertisements, which occur at a = fixed rate
> controlled by the configuration of the
> mobility agent.
>
> Apparently, you think there are unsolved cases = beyond this? Could
> you elaborate on them, please?
>
> > I can see the potential security problem = in this particular
> case but
> > not sure on the severity because of the = challenge
> mechanism. Any help
> > on this security topic will be = appreciated.
> > >...
> > > > > Proposed text:
> > > > >
> > > > > Add at the end of section = 2:
> > > > >
> > > > > 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 = solicited Agent Advertisement is unicast
> back to the soliciting
> > > > >   mobile node, it = MUST be handled in the same manner
> as described for
> > > > >   Challenges = issued in a Registration Reply.  A new
> Challenge value
> > > > >   MUST be = generated and remembered as the most recent
> challenge issued
> > > > >   to the mobile = node.
> > > > >
> > > > >
> > > > > In section 3.2, = change
> > > > >
> > > > > 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.
> >
>
>
>

------_=_NextPart_001_01C3579E.557E2CCC-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Jul 31 16:07: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 QAA12412 for ; Thu, 31 Jul 2003 16:07: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 19iJhV-0003P6-PY for mip4-archive@odin.ietf.org; Thu, 31 Jul 2003 16:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VK71D3013075 for mip4-archive@odin.ietf.org; Thu, 31 Jul 2003 16: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 19iJhV-0003Og-Js for mip4-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 16:07: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 QAA12391 for ; Thu, 31 Jul 2003 16:06:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJhT-0007Gi-00 for mip4-web-archive@ietf.org; Thu, 31 Jul 2003 16:06:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iJhT-0007Gf-00 for mip4-web-archive@ietf.org; Thu, 31 Jul 2003 16:06:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJhU-0003N0-9h; Thu, 31 Jul 2003 16:07:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iJgp-0003HG-4i for mip4@optimus.ietf.org; Thu, 31 Jul 2003 16:06:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12371 for ; Thu, 31 Jul 2003 16:06:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iJgn-0007GL-00 for mip4@ietf.org; Thu, 31 Jul 2003 16:06:17 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19iJgm-0007G8-00 for mip4@ietf.org; Thu, 31 Jul 2003 16:06:16 -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 h6VK4cU10249; Thu, 31 Jul 2003 15:04:39 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h6VK4bR06386; Thu, 31 Jul 2003 15:04:37 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HIWNRI-00010W-00; Thu, 31 Jul 2003 16:04:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16169.30284.686006.735030@gargle.gargle.HOWL> Date: Thu, 31 Jul 2003 15:04:28 -0500 From: Pete McCann To: "Jayshree Bharatia" Cc: "'Basavaraj.Patil@nokia.com'" , "'gab@sun.com'" , "'mip4@ietf.org'" In-Reply-To: <870397D7C140C84DB081B88396458DAF746A9E@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746A9E@zrc2c000.us.nortel.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] RE: [mobile-ip] Comments on 3012bis Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Jayshree, I agree with the definition of "previously used challenge" you give below, and I also agree the existing procedures for when to return STALE_CHALLENGE should now be correct. -Pete Jayshree Bharatia writes: > Hello Pete, > > I have revised the terminology for the "previously used challenge" for > section 1.1 as below: > > "previously used challenge: The challenge is previously used challenge if > the Mobile Node sent the same challenge to the Foreign Agent in a previous > Registration Request, and that previous Registration Request passed all > validity checks performed by the Foreign Agent. The Foreign Agent may not be > able to keep records for all previously used challenges, but see section 3.2 > for minimal requirements." > > I believe we won't be requiring terminology "stale challenge" since it is > not used anywhere else in the document. Also, there won't be any changes > required on current definition of "STALE_CHALLENGE". > > Let me know if you have any comments/suggestions. > > Regards, > Jayshree > > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Wednesday, July 16, 2003 7:59 AM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: 'Basavaraj.Patil@nokia.com'; 'gab@sun.com'; > > 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: [mobile-ip] Comments on 3012bis > > > > > > > > Hi, Jayshree, > > > > The issue is that the text says you shall reject previously > > used challenges (in all cases but retransmissions of valid > > requests). If "previously used" includes RRQs that weren't > > validated, then it is possible for an attacker to use them up > > before the MN can register. > > > > -Pete > > > > > > Jayshree Bharatia writes: > > > Pete, > > > > > > I am not sure I understand your concern well. Can you > > please clarify what > risks are associated if the malicious > > node consumes "previously used > challenges". > > > > > > Thanks, > > > Jayshree > > > > -----Original Message----- > > > > From: Pete McCann [mailto:mccap@lucent.com] > > > > Sent: Friday, July 11, 2003 9:53 AM > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: 'Basavaraj.Patil@nokia.com'; 'gab@sun.com'; > > > > 'mobile-ip@sunroof.eng.sun.com' > > > > Subject: RE: [mobile-ip] Comments on 3012bis > > > > > > > > > > > > > > > > Hi, Jayshree, > > > > > > > > One point below... > > > > > > > > Jayshree Bharatia writes: > > > > > > No, it is possible to reuse the challenge in a > > retransmitted > > > > > > registration request, as outlined in Section 3.2. Under my > > > > > > reading of that section a retransmission of a Challenge is > > > > > > still a "previously used" challenge, even though the Reply > > > > > > has not been sent/received. Note that this is > > different from > > > > > > a "stale challenge" which is one that has been used in a > > > > > > request, validated by the FA, and for which a Reply > > was sent > > > > > > to the MN. I would like to keep this distinction in the > > > > > > definitions. Otherwise, I think you will need to re-write > > > > > > some of the text in Section 3.2. > > > > > > > > > > > [JB] I agree that the differentiation is based on whether > > > > the FA has sent > corresponding Registration Reply to the MN > > > > or not. If the FA has already > sent the reply, and the MN > > > > sends the same challenge in the new Registration > Request, > > > > it will be "stale challenge". Otherwise, if it will be just > > > > > "previously used challenge". If we have agreement on this, > > > > I like to propose > the following: > 1. The new (proposed > > > > earlier) text will still be valid for the "stale > > > > > challenge" terminology. > 2. Add new definition called > > > > "previously used challenge" with the following > description > > > > for section 1.1: > "previously used challenge: Any challenge > > > > that has been used by the Mobile > Node in the previous > > > > Registration Request" > > > > > > I notice that you have additional statement saying "and > > > > that previous > Registration Request passed all checks prior > > > > to forwarding to the HA". I > would rather not specify where > > > > exactly the Registration Request may be > getting processed > > > > once it is received at the FA. It may be forwarded to AAA > > > > > or HA. Also, even if it doesn't passes all checks, it is > > > > still considered as > a "previously used challenge". > > > > > > > > But I think this opens up a denial of service attack, where > > > > malicious nodes can consume challenges on behalf of other > > > > nodes on the same link. If you don't at least check the > > > > MN-AAA or MN-FA authentication on the Challenge, you should > > > > not mark it as "previously used" for that mobile. That's why > > > > I put the language about passing validity checks at the FA. > > > > This could be consultation of a AAA interface or verification > > > > of the MN-FA auth extension---I was intentionally vague > > about that. > > > > > > -Pete > > > > > > > > > > RE: [mobile-ip] Comments on 3012bis > > > >

Hello Pete, >

> >

I have revised the terminology for the "previously used challenge" for section 1.1 as below: >

> >

"previously used challenge: The challenge is previously used challenge if the Mobile Node sent the same challenge to the Foreign Agent in a previous Registration Request, and that previous Registration Request passed all validity checks performed by the Foreign Agent. The Foreign Agent may not be able to keep records for all previously used challenges, but see section 3.2 for minimal requirements."

> >

I believe we won't be requiring terminology "stale challenge" since it is not used anywhere else in the document. Also, there won't be any changes required on current definition of "STALE_CHALLENGE".

> >

Let me know if you have any comments/suggestions. >

> >

Regards, >
Jayshree >

> >

> -----Original Message----- >
> From: Pete McCann [mailto:mccap@lucent.com] >
> Sent: Wednesday, July 16, 2003 7:59 AM >
> To: Bharatia, Jayshree [RICH1:2H13:EXCH] >
> Cc: 'Basavaraj.Patil@nokia.com'; 'gab@sun.com'; >
> 'mobile-ip@sunroof.eng.sun.com' >
> Subject: RE: [mobile-ip] Comments on 3012bis >
> >
> >
> >
> Hi, Jayshree, >
> >
> The issue is that the text says you shall reject previously >
> used challenges (in all cases but retransmissions of valid >
> requests).  If "previously used" includes RRQs that weren't >
> validated, then it is possible for an attacker to use them up >
> before the MN can register. >
> >
> -Pete >
> >
> >
> Jayshree Bharatia writes: >
>  > Pete, >
>  > >
>  > I am not sure I understand your concern well. Can you >
> please clarify what  > risks are associated if the malicious >
> node consumes "previously used  > challenges". >
>  > >
>  > Thanks, >
>  > Jayshree >
>  > > -----Original Message----- >
>  > > From: Pete McCann [mailto:mccap@lucent.com] >
>  > > Sent: Friday, July 11, 2003 9:53 AM >
>  > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] >
>  > > Cc: 'Basavaraj.Patil@nokia.com'; 'gab@sun.com'; >
>  > > 'mobile-ip@sunroof.eng.sun.com' >
>  > > Subject: RE: [mobile-ip] Comments on 3012bis >
>  > > >
>  > > >
>  > > >
>  > > Hi, Jayshree, >
>  > > >
>  > > One point below... >
>  > > >
>  > > Jayshree Bharatia writes: >
>  > >  > > No, it is possible to reuse the challenge in a >
> retransmitted >
>  > >  > > registration request, as outlined in Section 3.2.  Under my >
>  > >  > > reading of that section a retransmission of a Challenge is >
>  > >  > > still a "previously used" challenge, even though the Reply >
>  > >  > > has not been sent/received.  Note that this is >
> different from >
>  > >  > > a "stale challenge" which is one that has been used in a >
>  > >  > > request, validated by the FA, and for which a Reply >
> was sent >
>  > >  > > to the MN.  I would like to keep this distinction in the >
>  > >  > > definitions.  Otherwise, I think you will need to re-write >
>  > >  > > some of the text in Section 3.2. >
>  > >  > > >
>  > >  > [JB] I agree that the differentiation is based on whether >
>  > > the FA has sent  > corresponding Registration Reply to the MN >
>  > > or not. If the FA has already  > sent the reply, and the MN >
>  > > sends the same challenge in the new Registration  > Request, >
>  > > it will be "stale challenge". Otherwise, if it will be just  >
>  > > > "previously used challenge". If we have agreement on this, >
>  > > I like to propose  > the following:  > 1. The new (proposed >
>  > > earlier) text will still be valid for the "stale  > >
>  > > challenge" terminology.  > 2. Add new definition called >
>  > > "previously used challenge" with the following  > description >
>  > > for section 1.1:  > "previously used challenge: Any challenge >
>  > > that has been used by the Mobile  > Node in the previous >
>  > > Registration Request"  > >
>  > >  > I notice that you have additional statement saying "and >
>  > > that previous  > Registration Request passed all checks prior >
>  > > to forwarding to the HA". I  > would rather not specify where >
>  > > exactly the Registration Request may be  > getting processed >
>  > > once it is received at the FA. It may be forwarded to AAA  > >
>  > > or HA. Also, even if it doesn't passes all checks, it is >
>  > > still considered as  > a "previously used challenge". >
>  > > >
>  > > But I think this opens up a denial of service attack, where >
>  > > malicious nodes can consume challenges on behalf of other >
>  > > nodes on the same link.  If you don't at least check the >
>  > > MN-AAA or MN-FA authentication on the Challenge, you should >
>  > > not mark it as "previously used" for that mobile.  That's why >
>  > > I put the language about passing validity checks at the FA.  >
>  > > This could be consultation of a AAA interface or verification >
>  > > of the MN-FA auth extension---I was intentionally vague >
> about that.  > > >
>  > > -Pete >
> >
> >

> > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Jul 31 16:45: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 QAA13262 for ; Thu, 31 Jul 2003 16:45: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 19iKII-0004pJ-Go for mip4-archive@odin.ietf.org; Thu, 31 Jul 2003 16:45:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h6VKj2RJ018547 for mip4-archive@odin.ietf.org; Thu, 31 Jul 2003 16:45:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iKII-0004p4-B8 for mip4-web-archive@optimus.ietf.org; Thu, 31 Jul 2003 16: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 QAA13250 for ; Thu, 31 Jul 2003 16:44:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iKIG-0007SH-00 for mip4-web-archive@ietf.org; Thu, 31 Jul 2003 16:45:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19iKIF-0007SE-00 for mip4-web-archive@ietf.org; Thu, 31 Jul 2003 16:44:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19iKIH-0004oq-9M; Thu, 31 Jul 2003 16: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 19iKI2-0004ob-0q for mip4@optimus.ietf.org; Thu, 31 Jul 2003 16:44: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 QAA13241 for ; Thu, 31 Jul 2003 16:44:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19iKI0-0007S8-00 for mip4@ietf.org; Thu, 31 Jul 2003 16:44:44 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19iKHz-0007Rz-00 for mip4@ietf.org; Thu, 31 Jul 2003 16:44: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 h6VKi3a22487; Thu, 31 Jul 2003 15:44:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T8GX9>; Thu, 31 Jul 2003 15:44:03 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746AA2@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Adrangi, Farid'" Cc: "'mip4@ietf.org'" Date: Thu, 31 Jul 2003 15:43:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C357A4.77DC6E36" Subject: [Mip4] RE: Comments on VPN Problem Statement 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: , 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_01C357A4.77DC6E36 Content-Type: text/plain 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_01C357A4.77DC6E36 Content-Type: text/html Message
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_01C357A4.77DC6E36-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4