From exim@www1.ietf.org Mon Aug 4 00:51:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04747 for ; Mon, 4 Aug 2003 00:51: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 19jXJG-0007uP-MQ for mip4-archive@odin.ietf.org; Mon, 04 Aug 2003 00:51:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h744p2G2030397 for mip4-archive@odin.ietf.org; Mon, 4 Aug 2003 00:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXJG-0007uC-I1 for mip4-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 00:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04738 for ; Mon, 4 Aug 2003 00:50:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXJE-00065F-00 for mip4-web-archive@ietf.org; Mon, 04 Aug 2003 00:51:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jXJD-00065B-00 for mip4-web-archive@ietf.org; Mon, 04 Aug 2003 00:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXJE-0007tx-5x; Mon, 04 Aug 2003 00:51:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jXJ9-0007tk-3Z for mip4@optimus.ietf.org; Mon, 04 Aug 2003 00:50:55 -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 AAA04733 for ; Mon, 4 Aug 2003 00:50:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jXJ6-000656-00 for mip4@ietf.org; Mon, 04 Aug 2003 00:50:52 -0400 Received: from fmr05.intel.com ([134.134.136.6] helo=hermes.jf.intel.com) by ietf-mx with esmtp (Exim 4.12) id 19jXJ5-00064o-00 for mip4@ietf.org; Mon, 04 Aug 2003 00:50:51 -0400 Received: from talaria.jf.intel.com (talaria.jf.intel.com [10.7.209.7]) by hermes.jf.intel.com (8.11.6p2/8.11.6/d: outer.mc,v 1.66 2003/05/22 21:17:36 rfjohns1 Exp $) with ESMTP id h744m9918910 for ; Mon, 4 Aug 2003 04:48:09 GMT Received: from orsmsxvs040.jf.intel.com (orsmsxvs040.jf.intel.com [192.168.65.206]) by talaria.jf.intel.com (8.11.6p2/8.11.6/d: inner.mc,v 1.35 2003/05/22 21:18:01 rfjohns1 Exp $) with SMTP id h744DiP10389 for ; Mon, 4 Aug 2003 04:13:44 GMT Received: from orsmsx332.amr.corp.intel.com ([192.168.65.60]) by orsmsxvs040.jf.intel.com (NAVGW 2.5.2.11) with SMTP id M2003080322022119086 ; Sun, 03 Aug 2003 22:02:21 -0700 Received: from orsmsx407.amr.corp.intel.com ([192.168.65.50]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(5.0.2195.5329); Sun, 3 Aug 2003 21:50:15 -0700 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35A43.E4BEDB2F" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Sun, 3 Aug 2003 21:50:14 -0700 Message-ID: Thread-Topic: Comments on VPN Problem Statement Draft Thread-Index: AcNXpIFxBnWEP+hGQO+VRgAmCjmj0QCl/KRg From: "Adrangi, Farid" To: "Jayshree Bharatia" Cc: X-OriginalArrivalTime: 04 Aug 2003 04:50:15.0116 (UTC) FILETIME=[E53350C0:01C35A43] 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 is a multi-part message in MIME format. ------_=_NextPart_001_01C35A43.E4BEDB2F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jayshree, Thanks for following up on this. You, Gopal, and I had a very brief conversation on this during IETF-57 - but I am not sure if we derived any conclusion on whether or not we should include this scenario. To be frank, I don't quite understand the point behind adding this scenario because, - It seems to present a solution to a specific deployment model rather than a deployment scenario=20 - I don't quite see the advantages of a combined VPN+FA if it does not support FA traversal and it does not avoid IPsec renegotiation when MN moves from one subnet to another - perhaps you can elaborate on this? - Furthermore, Scenarios in section 2 of the problem statement draft represents combinations of MIPv4 HA and VPN gateway placement - adding this scenario is going to change semantics of the section 2. =20 I have no problem adding this scenario to the draft - I just wanted to make sure that we clearly understand the reasons for adding this scenario to the problem statement draft. Design team members and interested individuals are welcome to express their opinion on this. =20 =20 Best regards, Farid =20 =20 =20 =20 =20 The following sub-sections introduce five representative combinations of MIPv4 HA and VPN gateway placement. =20 -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]=20 Sent: Thursday, July 31, 2003 1:44 PM To: Adrangi, Farid Cc: 'mip4@ietf.org' Subject: RE: Comments on VPN Problem Statement Draft =20 Hello Farid, =20 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. =20 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. =20 Thanks, Jayshree =20 -----Original Message----- From: Adrangi, Farid [mailto:farid.adrangi@intel.com]=20 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 =20 =20 -----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 =20 Hello Farid,=20 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,=20 Jayshree=20 ------_=_NextPart_001_01C35A43.E4BEDB2F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

Hello Jayshree,

Thanks for following up on = this.  You, Gopal, and I had a very brief conversation on this during IETF-57 = – but I am not sure if we derived any conclusion on whether or not we should = include this scenario.  To be frank, I don’t quite understand the point = behind adding this scenario because,

-          It seems to = present a solution to a specific deployment model rather than a deployment = scenario

-          I don’t = quite see the advantages of  a combined VPN+FA if it does not support FA = traversal and it does not avoid IPsec renegotiation when MN moves from one subnet to = another – perhaps you can elaborate on this?

-          Furthermore, = Scenarios in section 2 of the problem statement draft represents combinations of = MIPv4 HA and VPN gateway placement – adding this scenario is going to = change semantics of the section 2.

 

I have no problem adding this = scenario to the draft – I just wanted to make sure that we clearly understand = the reasons for adding this scenario to the problem statement draft.  Design = team members and interested individuals are welcome to express their opinion = on this. 

 

Best regards,

Farid

 

 

 

 
 
 =
The   following   sub-sections   =
introduce   five   =
representative

   combinations of MIPv4 HA and VPN gateway = placement.

 

-----Original = Message-----
From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com]
Sent: Thursday, July 31, = 2003 1:44 PM
To: Adrangi, Farid
Cc: 'mip4@ietf.org'
Subject: RE: Comments on = VPN Problem Statement Draft

 

Hello = Farid,

 

As per our = earlier discussion during IETF-57, my understanding is that you will include the scenario of co-existed FA with the VPN gateway in the VPN Problem = Statement draft.

 

I agree that = this particular scenario has problems and it won't work if the MN is behind = an FA in the foreign subnet. But again, this is a problem statement draft. Hence, = I believe that this is the appropriate document for mentioning this scenario.

 

Thanks,

Jayshree

 

-----Original Message-----
From: Adrangi, Farid [mailto:farid.adrangi@intel.com]
Sent: Monday, April 07, = 2003 2:58 PM
To: Bharatia, Jayshree [RICH1:2H13:EXCH]
Cc: 'mobile-ip@sunroof.eng.sun.com'
Subject: RE: Comments on = VPN Problem Statement Draft

Hello = Jayshree

This is a good point - I = knew someone was to bring this up!  At the time of writing these = scenarios, we (the design team) actually discussed this and concluded this scenario = would fall into a solution space.  Maybe we did not make the right = decision and we should rethink this.  But, before we take this discussion = further please allow me to ask you a few questions about the details of the = scenario (VPN+FA) that you have in mind .  Are you thinking to broadcast FA advertisements through the IPsec tunnel to the MN?  If so, how will = this work if MN is already behind an FA in the foreign subnet?  Or, If = you had something different in mind, perhaps you can elaborate on = that.

Best = regards,

Farid

 

 

-----Original = Message-----
From: Jayshree Bharatia = [mailto:jayshree= @nortelnetworks.com],
Sent: Friday, April 04, = 2003 3:14 PM
To: = 'farid.adrangi@intel.com'
Cc: 'mobile-ip@sunroof.eng.sun.com'
Subject: Comments on VPN = Problem Statement Draft

 

Hello Farid,

This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) currently misses one scenario were the FA is co-existed with the VPN Gateway. I would think = that there are no technical issues supporting this scenario. It will be good = if you can add this scenario in the draft (perhaps as section 2.6?) for = completeness.

Thanks,
Jayshree =

=00 ------_=_NextPart_001_01C35A43.E4BEDB2F-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 4 18:13: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 SMTP id SAA14057 for ; Mon, 4 Aug 2003 18:13: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 19jnZf-0007PL-4Y for mip4-archive@odin.ietf.org; Mon, 04 Aug 2003 18:13:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h74MD3ca028465 for mip4-archive@odin.ietf.org; Mon, 4 Aug 2003 18:13:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnZe-0007P0-VR for mip4-web-archive@optimus.ietf.org; Mon, 04 Aug 2003 18:13: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 SAA14008 for ; Mon, 4 Aug 2003 18:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnZc-000606-00 for mip4-web-archive@ietf.org; Mon, 04 Aug 2003 18:13:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jnZb-000603-00 for mip4-web-archive@ietf.org; Mon, 04 Aug 2003 18:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jnZd-0007Np-9E; Mon, 04 Aug 2003 18: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 19jnYi-0007Kg-D1 for mip4@optimus.ietf.org; Mon, 04 Aug 2003 18:12:04 -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 SAA13855 for ; Mon, 4 Aug 2003 18:11:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jnSD-0005wi-00 for mip4@ietf.org; Mon, 04 Aug 2003 18:05:21 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19jnSB-0005wU-00 for mip4@ietf.org; Mon, 04 Aug 2003 18:05:20 -0400 Received: (qmail 22290 invoked from network); 4 Aug 2003 22:04:38 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 4 Aug 2003 22:04:38 -0000 Date: Tue, 5 Aug 2003 00:04:38 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: "'charliep@iprg.nokia.com'" , mip4@ietf.org Message-Id: <20030805000438.3cb94910.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746AAE@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746AAE@zrc2c000.us.nortel.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: 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, (I'm adding the mip4 list (and culling the cc list), in line with your suggestion below of getting opinions/suggestions from others too.) More inline: Monday 4 August 2003, Jayshree wrote: > Hi Henrik, > > I can see the following options for the multicasted agent advertisement > issue when it is sent as a response of the solicited agent advertisement: > 1. Treat the agent advertisement different if it was requested by the > solicited agent advertisement (your proposal) > 2. Restrict sending multicasted agent advertisement > 3. Indicate potential issue with the use of multicated agent advertisement Agreed on the alternatives. > Option 1: Not preferred since the whole point of using the challenge in the > agent advertisement is so that the MN can use this challenge information in > the registration procedure if needed. Restricting new challenge value breaks > the mechanism. I have reservation toward treating this specific case > differently especially since it has side effect (mentioned above). Right, here I guess we have somewhat different viewpoints. I see it this way: If all multicast advertisements which are done in response to a solicitation simply repeat the challenge from the most recent unsolicited advertisement, you are in a situation analogous to the one where you was on-link at the time of the unsolicited advertisement, and heard that. As I believe all or nearly all solicitations are done in order to find out if there is an FA on the link (because one did not hear the most recent unsolicited advertisement) and not in order to refresh a challenge, I find this acceptable. At the same time, you are of course perfectly correct in that if the solicitation is done in order to refresh a challenge, it is of no use at all to respond with the same challenge sent with the most recent unsolicited advertisement. As the mobile node has no way to request that the solicited advertisement be sent unicast, the only thing it can do in this situation is to wait for a new unsolicited advertisement with a fresh challenge. > Option 2: solves the problem but adds extra burden on the FA. I guess you mean because it now needs to send unicast responses, rather than multicast? But if soliciting is done to refresh a challenge, then you'd still get just as many solicitations whether they were multicast or unicast. I would deem it an acceptable solution to limit solicited advertisements containing challenges to be unicast, never multicast. > Option 3: Provides guideline to implementers on probable security threat. > This was my earlier proposal. Ok. I don't think guidelines is sufficient, I believe we need requirements to avoid the exact interoperability problems we recently experienced. > I would suggest we can have opinions/suggestions from others as well. I > don't have any issue in incorporating the option agreed by all. Right. We also should have some text to clarify the handling of unicast solicited advertisements. I guess we agree on the handling of those? (i.e. a new challenge should be generated, and treated analogous to a challenge returned with a registration reply?) There is one further change we maybe should review as part of this: To change the requirement on returning a challenge with any registration response from a SHOULD to a MUST. Any viewpoints on that? Regards, Henrik > Regards, > Jayshree > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Monday, August 04, 2003 12:08 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: 'Basavaraj.Patil@nokia.com'; 'mccap@lucent.com'; 'gab@sun.com' > > Subject: Re: [mobile-ip] Re: New issue: 3012bis challenges in > > solicited ag ent advertisements > > > > > > On Monday, 4 Aug 2003, Jayshree wrote: > > > > > Thanks for your reply. I understand your concerns now. > > > > Ah, good! :-) I was almost ready to despair there for a while ,,:-) > > > > > The current text in > > > section 2 is very generic and pertains only to the Agent > > > Advertisement. This is regardless whether the response is triggered > > > due to solicited Agent advertisement from the MN or whether it is > > > multicasted. I am reluctant to change this section (section > > 2) since > > > there is nothing special about sending the multicasted agent > > > advertisement due to solicited agent advertisement. The > > issue is with > > > the fact that it is triggered/sent as a result of solicited agent > > > advertisement. > > > > > > Hence, my proposals is that we can add text detailing this > > particular > > > scenario as a security threat in section 12 (Security > > Considerations) > > > of RFC3012bis. Is this solution agreeable to you? > > > > I think this is not so good, as I don't think new > > requirements should be introduced in the Security > > Considerations section, and the issue here is that we need > > some requirements to regulate how unicast and multicast > > solicited advertisements are handled - specification of this > > should not be left open. > > > > Whether the proposed text is added to seciton 2 or somewhere > > later, like for instance in a new section 3.6 is relatively > > unimportant to me, the important thing is to define the > > behaviour, that the defined behaviour is good, and that the > > text is consistent. > > > > Regards, > > > > Henrik > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 5 06:18: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 SMTP id GAA06529 for ; Tue, 5 Aug 2003 06:18: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 19jytI-0001xS-60 for mip4-archive@odin.ietf.org; Tue, 05 Aug 2003 06:18:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75AI4ZG007523 for mip4-archive@odin.ietf.org; Tue, 5 Aug 2003 06:18:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jytH-0001xG-QT for mip4-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 06:18: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 GAA06526 for ; Tue, 5 Aug 2003 06:17:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jytE-0000xf-00 for mip4-web-archive@ietf.org; Tue, 05 Aug 2003 06:18:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19jytD-0000xb-00 for mip4-web-archive@ietf.org; Tue, 05 Aug 2003 06:17:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jytF-0001x4-Dt; Tue, 05 Aug 2003 06:18:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19jysz-0001vY-5u for mip4@optimus.ietf.org; Tue, 05 Aug 2003 06:17:45 -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 GAA06520 for ; Tue, 5 Aug 2003 06:17:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19jysv-0000xY-00 for mip4@ietf.org; Tue, 05 Aug 2003 06:17:41 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19jyst-0000xK-00 for mip4@ietf.org; Tue, 05 Aug 2003 06:17:40 -0400 Received: (qmail 23754 invoked from network); 5 Aug 2003 10:17:06 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 5 Aug 2003 10:17:06 -0000 Date: Tue, 5 Aug 2003 12:17:06 +0200 From: Henrik Levkowetz To: "Sami Vaarala" Cc: "Tom Hiller" , , mip4@ietf.org Message-Id: <20030805121706.4a8164c6.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: [mobile-ip] relaxed re-registration (was: comments on draft-ietf-mobileip-vpn-problem-solution-02) 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 Sami and Tom, I'm adding the mip4 list to the recipients. Further below: Tuesday 5 August 2003, Sami wrote in response to Tom Hiller on the topic of detecting movement into/out of a VPN domain using frequent MIP re-registrations: ... [ skipping over a lot of interesting questions and responses, to get to one particular item ] ... > 6) Relax the re-registration requirement as follows: > - The MN does not need to re-register periodically, > if there is no traffic. > > - However, when traffic is about to be sent or > received, the traffic is queued up (or dropped), > and a re-registration invoked (assuming more > than N seconds have passed since last re-reg.) > > - If the re-registration goes through, the traffic > is delivered; if not, it is dropped and the MN > registers through the x-HA. > > If we want to have better support for idle devices > (esp. battery powered ones), I'd go with alternative 6. > Although it adds complexity (queue management and such), > such complexity will only be required when the steady > re-registration is an issue. There is still some > battery overhead involved, but that only happens when > the MN is sending/receiving MIP tunneled traffic (i.e. > is active). I find this a particularly interesting suggestion, as it seems to answer several of the issues related to battery consumption which Tom has raised, without some of the downside which other potential solutions seem to have. I think this would be worthy of further consideration. Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 5 15:35: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 PAA25721 for ; Tue, 5 Aug 2003 15:35: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 19k7am-0004s2-4X for mip4-archive@odin.ietf.org; Tue, 05 Aug 2003 15:35:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75JZWVu018722 for mip4-archive@odin.ietf.org; Tue, 5 Aug 2003 15:35:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7al-0004rt-Us for mip4-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 15:35:31 -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 PAA25693 for ; Tue, 5 Aug 2003 15:35: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 19k7aH-0004qd-2N; Tue, 05 Aug 2003 15:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k7aG-0004qO-Gy for mip4@optimus.ietf.org; Tue, 05 Aug 2003 15:35:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25666 for ; Tue, 5 Aug 2003 15:34:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k7aF-0005Bb-00 for mip4@ietf.org; Tue, 05 Aug 2003 15:34:59 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19k7aE-0005BY-00 for mip4@ietf.org; Tue, 05 Aug 2003 15:34:58 -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 h75JYFU19706; Tue, 5 Aug 2003 14:34:15 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h75JYEV07637; Tue, 5 Aug 2003 14:34:14 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ5VOW-0000WS-00; Tue, 05 Aug 2003 15:34:08 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16176.1711.242248.694789@gargle.gargle.HOWL> Date: Tue, 5 Aug 2003 14:34:07 -0500 From: Pete McCann To: Alpesh Cc: mkulkarn@cisco.com, kleung@cisco.com, mip4@ietf.org In-Reply-To: <3F30037C.4090807@cisco.com> References: <3F30037C.4090807@cisco.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] Clarification for Dynamic HA assignment draft Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Alpesh, I think we should attempt to be compatible with the functionality specified in the Mobile IPv4 Diameter specification, which is inside Section 1.4 of draft-ietf-aaa-diameter-mobileip-14.txt: 1.4 Allocation of Home Agent in Foreign Network The Diameter Mobile IP application allows a home agent to be allocated in a foreign network, as required in [MIPREQ, CDMA2000]. When a foreign agent detects that the mobile node has a home agent address equal to 0.0.0.0 or 255.255.255.255 in the Registration Request message, it MUST add a MIP-Feature-Vector AVP with the Home- Agent- Requested flag set to one. If the home agent address is equal to 255.255.255.255, then the foreign agent also MUST set the Home- Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home agent address is set to 0.0.0.0, the foreign agent MUST set the Home- Address-Allocatable-Only-in-Home-Realm flag equal to zero. So yes, both values are used to request dynamic home agent, however, one of them (255.255.255.255) indicates a preference for home realm based HA while the other (0.0.0.0) represents that the MS doesn't care whether the HA is in the home or visited realms. -Pete Alpesh writes: > Pete: > > This is regarding your comment/observation in last IETF while Kent > was presenting the Dynamica HA assignment framework draft. > > Currently, we are proposing to use either 0.0.0.0 or 255.255.255.255 > as the HA address to indicate dynamic HA assignment. I cross-checked > IS-835C and they use these addresses interchangeably. > > You mentioned that some other draft is trying to separate the meaning of > all zero and all ones. My concern is that, it the meaning is not already > defined, > should we rely on that draft? We want to accomodate the 3GPP2 model and > since they are using both values to mean dynamic HA assignment, we want to > go on that path. > > In future, if different meanings get assigned to each value, we can > probably change > our draft. > > Do you have comments/suggestions?? > > -a _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 5 16:16: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 QAA27292 for ; Tue, 5 Aug 2003 16:16: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 19k8Dz-0006rr-O4 for mip4-archive@odin.ietf.org; Tue, 05 Aug 2003 16:16:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75KG36U026368 for mip4-archive@odin.ietf.org; Tue, 5 Aug 2003 16:16:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8Dy-0006rD-U2 for mip4-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 16:16:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27265 for ; Tue, 5 Aug 2003 16:15:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8Dx-0005Zh-00 for mip4-web-archive@ietf.org; Tue, 05 Aug 2003 16:16:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k8Dw-0005Ze-00 for mip4-web-archive@ietf.org; Tue, 05 Aug 2003 16:16:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8Dx-0006qz-N7; Tue, 05 Aug 2003 16:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8DC-0006qN-57 for mip4@optimus.ietf.org; Tue, 05 Aug 2003 16:15:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27228 for ; Tue, 5 Aug 2003 16:15:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8DA-0005ZO-00 for mip4@ietf.org; Tue, 05 Aug 2003 16:15:12 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19k8D9-0005Z2-00 for mip4@ietf.org; Tue, 05 Aug 2003 16:15:11 -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 h75KE1421469; Tue, 5 Aug 2003 15:14:01 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T97SK>; Tue, 5 Aug 2003 15:14:01 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746AB4@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Henrik Levkowetz'" Cc: "'charliep@iprg.nokia.com'" , mip4@ietf.org Date: Tue, 5 Aug 2003 15:13:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35B8E.1B3BA726" 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_01C35B8E.1B3BA726 Content-Type: text/plain Hi Henrik, Having newly generated challenge in the unicast solicited advertisement is ok. I will also change the text to reflect mandatory inclusion of the challenge in a Registration Reply if the FA and the MN are compliant to RFC3012bis. I will able to close this issue once we have some opinions from others on handling the challenge in a multicast agent advertisement. Thanks, Jayshree > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Monday, August 04, 2003 5:05 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'charliep@iprg.nokia.com'; mip4@ietf.org > Subject: Re: [mobile-ip] Re: New issue: 3012bis challenges in > solicited ag ent advertisements > > > Hi Jayshree, > > (I'm adding the mip4 list (and culling the cc list), in > line with your suggestion below of getting > opinions/suggestions from others too.) > > More inline: > > Monday 4 August 2003, Jayshree wrote: > > Hi Henrik, > > > > I can see the following options for the multicasted agent > > advertisement issue when it is sent as a response of the solicited > > agent advertisement: 1. Treat the agent advertisement > different if it > > was requested by the solicited agent advertisement (your > proposal) 2. > > Restrict sending multicasted agent advertisement 3. > Indicate potential > > issue with the use of multicated agent advertisement > > Agreed on the alternatives. > > > Option 1: Not preferred since the whole point of using the > challenge > > in the agent advertisement is so that the MN can use this challenge > > information in the registration procedure if needed. > Restricting new > > challenge value breaks the mechanism. I have reservation toward > > treating this specific case differently especially since it > has side > > effect (mentioned above). > > Right, here I guess we have somewhat different viewpoints. I > see it this > way: If all multicast advertisements which are done in > response to a solicitation simply repeat the challenge from > the most recent unsolicited advertisement, you are in a > situation analogous to the one where you was on-link at the > time of the unsolicited advertisement, and heard that. As I > believe all or nearly all solicitations are done in order to > find out if there is an FA on the link (because one did not > hear the most recent unsolicited advertisement) and not in > order to refresh a challenge, I find this acceptable. > > At the same time, you are of course perfectly correct in that > if the solicitation is done in order to refresh a challenge, > it is of no use at all to respond with the same challenge > sent with the most recent unsolicited advertisement. As the > mobile node has no way to request that the solicited > advertisement be sent unicast, the only thing it can do in > this situation is to wait for a new unsolicited advertisement > with a fresh challenge. > > > Option 2: solves the problem but adds extra burden on the FA. > > I guess you mean because it now needs to send unicast > responses, rather than multicast? But if soliciting is done > to refresh a challenge, then you'd still get just as many > solicitations whether they were multicast or unicast. > > I would deem it an acceptable solution to limit solicited > advertisements containing challenges to be unicast, never multicast. > > > Option 3: Provides guideline to implementers on probable security > > threat. This was my earlier proposal. > > Ok. I don't think guidelines is sufficient, I believe we need > requirements to avoid the exact interoperability problems we > recently experienced. > > > I would suggest we can have opinions/suggestions from > others as well. > > I don't have any issue in incorporating the option agreed by all. > > Right. > > We also should have some text to clarify the handling of > unicast solicited advertisements. I guess we agree on the > handling of those? (i.e. a new challenge should be generated, > and treated analogous to a challenge returned with a > registration reply?) > > There is one further change we maybe should review as part of > this: To change the requirement on returning a challenge with > any registration response from a SHOULD to a MUST. Any > viewpoints on that? > > Regards, > Henrik > > > Regards, > > Jayshree > > > > > -----Original Message----- > > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > Sent: Monday, August 04, 2003 12:08 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: 'Basavaraj.Patil@nokia.com'; 'mccap@lucent.com'; 'gab@sun.com' > > > Subject: Re: [mobile-ip] Re: New issue: 3012bis challenges in > > > solicited ag ent advertisements > > > > > > > > > On Monday, 4 Aug 2003, Jayshree wrote: > > > > > > > Thanks for your reply. I understand your concerns now. > > > > > > Ah, good! :-) I was almost ready to despair there for a > while ,,:-) > > > > > > > The current text in > > > > section 2 is very generic and pertains only to the Agent > > > > Advertisement. This is regardless whether the response > is triggered > > > > due to solicited Agent advertisement from the MN or > whether it is > > > > multicasted. I am reluctant to change this section (section > > > 2) since > > > > there is nothing special about sending the multicasted agent > > > > advertisement due to solicited agent advertisement. The > > > issue is with > > > > the fact that it is triggered/sent as a result of > solicited agent > > > > advertisement. > > > > > > > > Hence, my proposals is that we can add text detailing this > > > particular > > > > scenario as a security threat in section 12 (Security > > > Considerations) > > > > of RFC3012bis. Is this solution agreeable to you? > > > > > > I think this is not so good, as I don't think new > > > requirements should be introduced in the Security > > > Considerations section, and the issue here is that we need > > > some requirements to regulate how unicast and multicast > > > solicited advertisements are handled - specification of this > > > should not be left open. > > > > > > Whether the proposed text is added to seciton 2 or somewhere > > > later, like for instance in a new section 3.6 is relatively > > > unimportant to me, the important thing is to define the > > > behaviour, that the defined behaviour is good, and that the > > > text is consistent. > > > > > > Regards, > > > > > > Henrik > > > > > > > > ------_=_NextPart_001_01C35B8E.1B3BA726 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] Re: New issue: 3012bis challenges in solicited = ag ent advertisements

Hi Henrik,

Having newly generated challenge in the unicast = solicited advertisement is ok. I will also change the text to reflect = mandatory inclusion of the challenge in a Registration Reply if the FA = and the MN are compliant to RFC3012bis.

I will able to close this issue once we have some = opinions from others on handling the challenge in a multicast agent = advertisement.

Thanks,
Jayshree
> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] =
> Sent: Monday, August 04, 2003 5:05 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'charliep@iprg.nokia.com'; = mip4@ietf.org
> Subject: Re: [mobile-ip] Re: New issue: 3012bis = challenges in
> solicited ag ent advertisements
>
>
> Hi Jayshree,
>
>       (I'm adding the = mip4 list (and culling the cc list), in
> line with your suggestion below of getting =
> opinions/suggestions from others too.)
>
>       More = inline:
>
> Monday  4 August 2003, Jayshree = wrote:
> > Hi Henrik,
> >
> > I can see the following options for the = multicasted agent
> > advertisement issue when it is sent as a = response of the solicited
> > agent advertisement: 1. Treat the agent = advertisement
> different if it
> > was requested by the solicited agent = advertisement (your
> proposal) 2.
> > Restrict sending multicasted agent = advertisement 3.
> Indicate potential
> > issue with the use of multicated agent = advertisement
>
> Agreed on the alternatives.
>
> > Option 1: Not preferred since the whole = point of using the
> challenge
> > in the agent advertisement is so that the = MN can use this challenge
> > information in the registration procedure = if needed.
> Restricting new
> > challenge value breaks the mechanism. I = have reservation toward
> > treating this specific case differently = especially since it
> has side
> > effect (mentioned above).
>
> Right, here I guess we have somewhat different = viewpoints. I
> see it this
> way: If all multicast advertisements which are = done in
> response to a solicitation simply repeat the = challenge from
> the most recent unsolicited advertisement, you = are in a
> situation analogous to the one where you was = on-link at the
> time of the unsolicited advertisement, and = heard that. As I
> believe all or nearly all solicitations are = done in order to
> find out if there is an FA on the link (because = one did not
> hear the most recent unsolicited advertisement) = and not in
> order to refresh a challenge, I find this = acceptable.
>
> At the same time, you are of course perfectly = correct in that
> if the solicitation is done in order to refresh = a challenge,
> it is of no use at all to respond with the same = challenge
> sent with the most recent unsolicited = advertisement. As the
> mobile node has no way to request that the = solicited
> advertisement be sent unicast, the only thing = it can do in
> this situation is to wait for a new unsolicited = advertisement
> with a fresh challenge.
>
> > Option 2: solves the problem but adds = extra burden on the FA.
>
> I guess you mean because it now needs to send = unicast
> responses, rather than multicast? But if = soliciting is done
> to refresh a challenge, then you'd still get = just as many
> solicitations whether they were multicast or = unicast.
>
> I would deem it an acceptable solution to limit = solicited
> advertisements containing challenges to be = unicast, never multicast.
>
> > Option 3: Provides guideline to = implementers on probable security
> > threat. This was my earlier = proposal.
>
> Ok. I don't think guidelines is sufficient, I = believe we need
> requirements to avoid the exact = interoperability problems we
> recently experienced.
>
> > I would suggest we can have = opinions/suggestions from
> others as well.
> > I don't have any issue in incorporating = the option agreed by all.
>
> Right.
>
> We also should have some text to clarify the = handling of
> unicast solicited advertisements. I guess we = agree on the
> handling of those? (i.e. a new challenge should = be generated,
> and treated analogous to a challenge returned = with a
> registration reply?)
>
> There is one further change we maybe should = review as part of
> this: To change the requirement on returning a = challenge with
> any registration response from a SHOULD to a = MUST. Any
> viewpoints on that?
>
>       Regards,
>       =         Henrik
>
> > Regards,
> > Jayshree
> >
> > > -----Original Message-----
> > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> > > Sent: Monday, August 04, 2003 12:08 = PM
> > > To: Bharatia, Jayshree = [RICH1:2H13:EXCH]
> > > Cc: 'Basavaraj.Patil@nokia.com'; = 'mccap@lucent.com'; 'gab@sun.com'
> > > Subject: Re: [mobile-ip] Re: New = issue: 3012bis challenges in
> > > solicited ag ent = advertisements
> > >
> > >
> > > On Monday,  4 Aug 2003, Jayshree = wrote:
> > >
> > > > Thanks for your reply. I = understand your concerns now.
> > >
> > > Ah, good! :-) I was almost ready to = despair there for a
> while ,,:-)
> > >
> > > > The current text in
> > > > section 2 is very generic and = pertains only to the Agent
> > > > Advertisement. This is = regardless whether the response
> is triggered
> > > > due to solicited Agent = advertisement from the MN or
> whether it is
> > > > multicasted. I am reluctant to = change this section (section
> > > 2) since
> > > > there is nothing special about = sending the multicasted agent
> > > > advertisement due to solicited = agent advertisement. The
> > > issue is with
> > > > the fact that it is = triggered/sent as a result of
> solicited agent
> > > > advertisement.
> > > >
> > > > Hence, my proposals is that we = can add text detailing this
> > > particular
> > > > scenario as a security threat in = section 12 (Security
> > > Considerations)
> > > > of RFC3012bis. Is this solution = agreeable to you?
> > >
> > > I think this is not so good, as I = don't think new
> > > requirements should be introduced in = the Security
> > > Considerations section, and the issue = here is that we need
> > > some requirements to regulate how = unicast and multicast
> > > solicited advertisements are handled = - specification of this
> > > should not be left open.
> > >
> > > Whether the proposed text is added to = seciton 2 or somewhere
> > > later, like for instance in a new = section 3.6 is relatively
> > > unimportant to me, the important = thing is to define the
> > > behaviour, that the defined behaviour = is good, and that the
> > > text is consistent.
> > >
> > >   Regards,
> > >
> > >        &= nbsp;  Henrik
> > >
> >
>
>
>

------_=_NextPart_001_01C35B8E.1B3BA726-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 5 16:59: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 QAA28523 for ; Tue, 5 Aug 2003 16:59: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 19k8ta-00009R-Ds for mip4-archive@odin.ietf.org; Tue, 05 Aug 2003 16:59:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h75Kx2K7000581 for mip4-archive@odin.ietf.org; Tue, 5 Aug 2003 16:59:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8ta-00009I-8p for mip4-web-archive@optimus.ietf.org; Tue, 05 Aug 2003 16:59: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 QAA28487 for ; Tue, 5 Aug 2003 16:58:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8tY-0005rQ-00 for mip4-web-archive@ietf.org; Tue, 05 Aug 2003 16:59:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19k8tX-0005rN-00 for mip4-web-archive@ietf.org; Tue, 05 Aug 2003 16:58:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8tY-00007G-NJ; Tue, 05 Aug 2003 16:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19k8su-00006k-N8 for mip4@optimus.ietf.org; Tue, 05 Aug 2003 16:58: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 QAA28480 for ; Tue, 5 Aug 2003 16:58:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19k8ss-0005rD-00 for mip4@ietf.org; Tue, 05 Aug 2003 16:58:18 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19k8sr-0005r9-00 for mip4@ietf.org; Tue, 05 Aug 2003 16:58:17 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h75Kv6A07141; Tue, 5 Aug 2003 15:57:06 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h75Kv4V10125; Tue, 5 Aug 2003 15:57:04 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ5ZIY-0001PS-00; Tue, 05 Aug 2003 16:56:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16176.6680.853910.39250@gargle.gargle.HOWL> Date: Tue, 5 Aug 2003 15:56:56 -0500 From: Pete McCann To: Henrik Levkowetz Cc: "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , mip4@ietf.org Subject: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in solicited ag ent advertisements In-Reply-To: <20030805000438.3cb94910.henrik@levkowetz.com> References: <870397D7C140C84DB081B88396458DAF746AAE@zrc2c000.us.nortel.com> <20030805000438.3cb94910.henrik@levkowetz.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Henrik Levkowetz writes: > > Option 2: solves the problem but adds extra burden on the FA. > > I guess you mean because it now needs to send unicast responses, rather > than multicast? But if soliciting is done to refresh a challenge, then > you'd still get just as many solicitations whether they were multicast > or unicast. > > I would deem it an acceptable solution to limit solicited advertisements > containing challenges to be unicast, never multicast. Isn't this open to a similar denial of service attack, assuming that link layer spoofing is possible? That is, an attacker can send spoofed solicitations at a very high rate, causing the FA to repeatedly (unicast) the agent advertisements with fresh challenges to the victim's mobile node. It could happen that the mobile is never able to register because a new solicitation arrives at the FA before the victim's RRQ. The solicitation/advertisement effectively pushes the last unicast challenge out of the 1 slot. Perhaps it should be possible to return the same challenge value in successive unicast solicited agent advertisements, as long as it was not previously used (recall "previously used" means used with a valid MN-AAA or MN-FA authentication extension). I think the same procedure (returning the same challenge) should be followed for unsuccessful Registration Requests where the MN-AAA (or MN-FA) authentication did not check out. If desired, we could change the challenge value after some fairly long period of time (like, 1 minute would easily be long enough to avoid this DoS) if we are really worried about robustness. > > Option 3: Provides guideline to implementers on probable security threat. > > This was my earlier proposal. > > Ok. I don't think guidelines is sufficient, I believe we need requirements > to avoid the exact interoperability problems we recently experienced. > > I would suggest we can have opinions/suggestions from others as well. I > > don't have any issue in incorporating the option agreed by all. > > Right. I think some changes to the draft are in order to avoid the DoS attacks pointed out by Henrik. > We also should have some text to clarify the handling of unicast > solicited advertisements. I guess we agree on the handling of those? > (i.e. a new challenge should be generated, and treated analogous to > a challenge returned with a registration reply?) > > There is one further change we maybe should review as part of this: To > change the requirement on returning a challenge with any registration > response from a SHOULD to a MUST. Any viewpoints on that? Sounds like a good idea, although see above about returning the same (unused) challenge in successive (unsuccessful) responses. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 09:57: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 JAA16483 for ; Wed, 6 Aug 2003 09: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 19kOml-0006DU-9v for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 09:57:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Dv3QM023894 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 09:57:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOml-0006DJ-0F for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 09:57:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16466 for ; Wed, 6 Aug 2003 09:56:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOmj-0002ze-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 09:57:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kOmi-0002za-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 09:57:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kOmi-0006Cj-TO; Wed, 06 Aug 2003 09: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 19kOmE-0006C8-85 for mip4@optimus.ietf.org; Wed, 06 Aug 2003 09:56:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16446 for ; Wed, 6 Aug 2003 09:56:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kOmC-0002zH-00 for mip4@ietf.org; Wed, 06 Aug 2003 09:56:28 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19kOmA-0002ym-00 for mip4@ietf.org; Wed, 06 Aug 2003 09:56:27 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h76Dss711019; Wed, 6 Aug 2003 08:54:55 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0DA0>; Wed, 6 Aug 2003 08:54:55 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Henrik Levkowetz'" Cc: mip4 , "Jayshree Bharatia" Date: Wed, 6 Aug 2003 08:54:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C22.4F9C33CA" 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_01C35C22.4F9C33CA Content-Type: text/plain I am sorry for the late response. Comments inline. Regards, Ahmad 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. <> Well, I do not want to go into a theoretical debate here BUT let us examine what RFC2119 says about SHOULD: " 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. " I am not sure what was the valid reason for any implementer to ignore this one! Was there an understanding of the full implication here!! <> > 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? <> Although, it is clearly mandates the FA to send a challenge that the MN can use for Replay Protection/authentication. Apparently FA can not communicate a previously used Challenge to a specific MN. Yes? How to implement the above is left as implementation specific and standard should not restrict it. <> 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 > > > ------_=_NextPart_001_01C35C22.4F9C33CA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [mobile-ip] New issue: 3012bis challenges in solicited agent = advertisements

I am sorry for the late response.
Comments inline.

Regards,
Ahmad


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.

<<Ahmad-START>>
Well, I do not want to go into a theoretical debate = here BUT let us examine what RFC2119 says about SHOULD:

"
3. SHOULD   This word, or the adjective = "RECOMMENDED", mean that there
   may exist valid reasons in particular = circumstances to ignore a
   particular item, but the full = implications must be understood and
   carefully weighed before choosing a = different course.
"
I am not sure what was the valid reason for any = implementer to ignore this one!
Was there an understanding of the full implication = here!!
<<Ahmad-END>>

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

<<Ahmad-START>>
Although, it is clearly mandates the FA to send a = challenge that the MN can use for Replay = Protection/authentication.
Apparently FA can not communicate a previously used = Challenge to a specific MN. Yes?
How to implement the above is left as implementation = specific and standard should not restrict it.

<<Ahmad-END>>

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


------_=_NextPart_001_01C35C22.4F9C33CA-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 11:39: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 LAA21653 for ; Wed, 6 Aug 2003 11:39: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 19kQNT-0002Yk-8w for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 11:39:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Fd3Dv009834 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 11:39:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQNT-0002YX-3O for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 11:39:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21626 for ; Wed, 6 Aug 2003 11:38:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQNS-0003xl-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 11:39:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kQNR-0003xi-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 11:39:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQNR-0002Xv-0a; Wed, 06 Aug 2003 11:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQMr-0002We-3V for mip4@optimus.ietf.org; Wed, 06 Aug 2003 11:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21606 for ; Wed, 6 Aug 2003 11:38:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQMq-0003ww-00 for mip4@ietf.org; Wed, 06 Aug 2003 11:38:24 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19kQMp-0003wd-00 for mip4@ietf.org; Wed, 06 Aug 2003 11:38:23 -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 h76Fax712822; Wed, 6 Aug 2003 10:36:59 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0G16>; Wed, 6 Aug 2003 10:37:00 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" , Henrik Levkowetz , mip4@ietf.org Cc: "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Wed, 6 Aug 2003 10:36:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C30.9256BA2E" 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_01C35C30.9256BA2E Content-Type: text/plain Hi Pete, Comments inline. Regards, Ahmad > > Isn't this open to a similar denial of service attack, > assuming that link layer spoofing is possible? That is, an > attacker can send spoofed solicitations at a very high rate, > causing the FA to repeatedly (unicast) the agent > advertisements with fresh challenges to the victim's mobile > node. It could happen that the mobile is never able to > register because a new solicitation arrives at the FA before > the victim's RRQ. The solicitation/advertisement effectively > pushes the last unicast challenge out of the 1 slot. > I Agree. > Perhaps it should be possible to return the same challenge > value in successive unicast solicited agent advertisements, > as long as it was not previously used (recall "previously > used" means used with a valid MN-AAA or MN-FA authentication > extension). I Agree. >I think the same procedure (returning the same > challenge) should be followed for unsuccessful Registration > Requests where the MN-AAA (or MN-FA) authentication did not > check out. If desired, we could change the challenge value > after some fairly long period of time (like, 1 minute would > easily be long enough to avoid this DoS) if we are really > worried about robustness. > I think we need to leave this flexible with the condition above. FA can not send a previously used challenge to a specific MN. I believe this is quite enough. > > > Option 3: Provides guideline to implementers on probable > security threat. > > This was my earlier proposal. > > > Ok. I don't think guidelines is sufficient, I believe we > need requirements > to avoid the exact interoperability > problems we recently experienced. > > > > I would suggest we can have opinions/suggestions from > others as well. I > > don't have any issue in incorporating > the option agreed by all. > > > > Right. > > I think some changes to the draft are in order to avoid the > DoS attacks pointed out by Henrik. > I thought Henrik concern was about the consequences of FA does not include a fresh challenge in the RRP. > > We also should have some text to clarify the handling of > unicast > solicited advertisements. I guess we agree on the > handling of those? > (i.e. a new challenge should be > generated, and treated analogous to > a challenge returned > with a registration reply?) > > > There is one further change we maybe should review as part > of this: To > change the requirement on returning a > challenge with any registration > response from a SHOULD to > a MUST. Any viewpoints on that? > > Sounds like a good idea, although see above about returning the same > (unused) challenge in successive (unsuccessful) responses. > I think we need to leave this for implementation with the standard restriction of Previously unused challenge. > -Pete > > > > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > ------_=_NextPart_001_01C35C30.9256BA2E Content-Type: text/html RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in solicited ag ent advertisements

Hi Pete,
Comments inline.

Regards,
Ahmad

>
> Isn't this open to a similar denial of service attack,
> assuming that link layer spoofing is possible?  That is, an
> attacker can send spoofed solicitations at a very high rate,
> causing the FA to repeatedly (unicast) the agent
> advertisements with fresh challenges to the victim's mobile
> node.  It could happen that the mobile is never able to
> register because a new solicitation arrives at the FA before
> the victim's RRQ.  The solicitation/advertisement effectively
> pushes the last unicast challenge out of the 1 slot.
>

I Agree.

> Perhaps it should be possible to return the same challenge
> value in successive unicast solicited agent advertisements,
> as long as it was not previously used (recall "previously
> used" means used with a valid MN-AAA or MN-FA authentication
> extension). 

I Agree.

>I think the same procedure (returning the same
> challenge) should be followed for unsuccessful Registration
> Requests where the MN-AAA (or MN-FA) authentication did not
> check out.  If desired, we could change the challenge value
> after some fairly long period of time (like, 1 minute would
> easily be long enough to avoid this DoS) if we are really
> worried about robustness.
>

I think we need to leave this flexible with the condition above.
FA can not send a previously used challenge to a specific MN.
I believe this is quite enough.

>  > > Option 3: Provides guideline to implementers on probable
> security threat.  > > This was my earlier proposal.  >
>  > Ok. I don't think guidelines is sufficient, I believe we
> need requirements  > to avoid the exact interoperability
> problems we recently experienced.
>
>  > > I would suggest we can have opinions/suggestions from
> others as well. I  > > don't have any issue in incorporating
> the option agreed by all.
>  >
>  > Right.
>
> I think some changes to the draft are in order to avoid the
> DoS attacks pointed out by Henrik.
>
 
I thought Henrik concern was about the consequences of FA does not include a fresh challenge in the RRP.

>  > We also should have some text to clarify the handling of
> unicast  > solicited advertisements. I guess we agree on the
> handling of those?  > (i.e. a new challenge should be
> generated, and treated analogous to  > a challenge returned
> with a registration reply?)  >
>  > There is one further change we maybe should review as part
> of this: To  > change the requirement on returning a
> challenge with any registration  > response from a SHOULD to
> a MUST. Any viewpoints on that?
>
> Sounds like a good idea, although see above about returning the same
> (unused) challenge in successive (unsuccessful) responses.
>

I think we need to leave this for implementation with the standard restriction of
Previously unused challenge.

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

------_=_NextPart_001_01C35C30.9256BA2E-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 11:44: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 LAA21816 for ; Wed, 6 Aug 2003 11:44: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 19kQSJ-0002hK-B2 for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 11:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Fi3UA010364 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 11:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQSJ-0002h5-6a for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 11:44: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 LAA21801 for ; Wed, 6 Aug 2003 11:43:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQSI-0003zn-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 11:44:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kQSH-0003zk-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 11:44:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQSH-0002ft-K8; Wed, 06 Aug 2003 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQS4-0002fU-Rr for mip4@optimus.ietf.org; Wed, 06 Aug 2003 11:43:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21790 for ; Wed, 6 Aug 2003 11:43:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQS3-0003zZ-00 for mip4@ietf.org; Wed, 06 Aug 2003 11:43:47 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kQS2-0003zK-00 for mip4@ietf.org; Wed, 06 Aug 2003 11:43:47 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h76FhDD25610 for ; Wed, 6 Aug 2003 10:43:13 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h76FhC102365; Wed, 6 Aug 2003 10:43:12 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ7FNV-0001GK-00 for mip4@ietf.org; Wed, 06 Aug 2003 11:43:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.8714.115908.206561@gargle.gargle.HOWL> Date: Wed, 6 Aug 2003 10:43:06 -0500 From: Pete McCann To: mip4@ietf.org X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Subject: [Mip4] Draft BOF Minutes 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, Attached are the draft minutes for the MIP4 BOF. If anyone has additions/corrections, please send them. I will be submitting these early next week. -Pete Mobility for IPv4 BOF (mip4) Monday, July 14 at 0900-1130 ============================== CHAIRS: Basavaraj Patil Gabriel Montenegro Phil Roberts NOTE: MIP4 is in the process of being approved as a working group. Final approval MAY happen before Vienna IETF. Details, work items, chairs, etc are likely to change. All presentations slides are available at the following web site. http://www.mindspring.com/~bpatil/IETF57/MIP4_MIP6_MIPSHOP_Slides/ San Fran: discussion on next steps in IP Mobility Proposal of 3 BOFs: MIP4, MIP6, MIPSHOP AGENDA bashing Discussion on Charter and potential work items: 15 min Presenter: Chairs Charter Highlights Interoperability of existing implementations Look at proprietary extensions Progressing the MIPv4 base spec to draft standard Completion of AAA Key exchange for MIP AAA-NAI completion and MIPv4-AAA review Dynamic HA assignment discussion VPN Solution for MIPv4 completion Samita: LPAS document? Should we publish as an informational document? KLeung: some draft Gopal: MIP depends on auth from the client. In WLAN, there is a lot of auth, fast auth, etc. Would it be something that the WG would consider to take advantage of this to do mobility? Raj: if you could frame the question as something the WG could discuss, maybe... but, we are trying to limit the scope of the charter. Gopal: not fast handoff, but it is a fundamental change in the way you look at mobility. Maybe you don't have MIP client on your laptop. Gabriel: 2 things: one is to have L2 triggers with authentication. other thing: how to implement mobility on nodes that don't implement mobileIP Gopal: so how do you take charge of a L2 trigger, second is how do you use some information to detect that MN has moved independent of MIP stack ThomasNarten: might be related to BOF on dna later in the week. What does it have to do with this WG here? This is Mobile IPv4 specific things. Gopal: biggest deployment problem is Mobile IP client stack. We can enhance existing framework to handle nodes without MIP stack. KLeung: applies well to interoperability issue. Key thing is adding support for non-MIP clients using MIP infrastructure. Thomas: That's interesting, but it's a big change. Not clear that this group should be the ones looking at it. Kleung: people are doing this already, sometimes proprietary signaling. Gabriel: everything so far has been mobile initated. Not sure there's scope for network initiated. Gopal: it is a mobile initiated, just not MIPv4 initiated. Raj: the reason you would like to do this is because of the difficulty of deploying MIPv4 on you laptop, right? Gopal: there is work going on elsewhere. Raj: trying to figure out what is the proprietary implementations of MIPv4, see if there is enough interest in this working group to standardize some of these ErikN: when you do this, you have to change home agents too, right? Gopal: there are ways not to change any HA code at all and still make it work. Or, there are ways to make it work better. RajeshKumar: have worked on IPSec agent implementation. As far as MIPv4 clients are concerned, haven't seen any incompatibilities There are a lot of L2 switches that a number of vendors are trying to build. This is mobility at L2, they are not using network layer. No issue with compatibility of Mobile IP. Gopal: LAN switches & VLAN switches: sometimes layer 2, but sometimes layer 3 RajeshKumar: no, L2 is L2, if you do L3 you need MIP. ErikNordmark: dynamic HA issue: might want to configure more things when you connect to your home ISP. enroll BOF, Is there synergy between these efforts? Gab: that point will be explored a bit more in the MIP6 BOF. Heard about enroll, doesn't seem to help that much for handoff from one HA to another, but might help with the initial case. Raj: other thoughts on the charter? Eric (FranceTelecom): Working documents, low latency handoffs? Raj: completed by WG, consensus make it experimental. WG would no longer work on it. We just have a milestone to get it to the IESG & publish it. VPN Design Team Update: 20 min Presenter: Gopal Dommety Problem Statement Draft DT version is finished Security review by Radio Perlman Draft is published draft-ietf-mobileip-vpn-problem-statement-req-03 The I-D which will be completing WG LC before the meeting has been revised following reviews by the Mobile IP security advisor (Radia Perlman). The intent is to provide a status update on the problem statement as well as discuss any LC comments/issues that may be identified Solution Base Solution (no IPSec changes) Optimizations (some changes for efficiency) Base Solution - work completed Need security review Last Call for base solution after security review and Problem Statement review by WG and IESG Optimizations to be completed before next IETF Problem Statement details 16 page draft IP Sec VPN is used to access the Enterprise network How do you get seamless mobility when moving from one hotspot to another or to wide area provider Mobility from one subnet to another inside enterprise Transition from inside enterprise to outside and back Figured out all the various placements of IPSec, Home agents, firewalls, foreign agents. The one that made most sense is: HA deep inside enterprise network VPN at the access concentrator Issues and requirements Without FA: the IPSec SA needs to be renegotiated on movement With FA: FA cannot modify/process IPSec packets from the MN Problem statement draft includes: Issues that need to be addressed for providing seamless mobility in this scenario Requirements for the solution Working Group Last Call RajeshKumar Requirements document is pretty complete Solution draft covers detail (42 pages) but to go to last call people will need some time to review all solutions Gab: only problem statement is about to go to last call. One comment: "seamless" here might be inappropriate Gopal: a little marketing on my part, will look into it VPN solutions discussion: 20 min I-D: draft-ietf-mobileip-vpn-problem-solution-02.txt Presenter: Sami Vaarala of Netseal The design team has discussed a number of options in the solution space. This agenda item is aimed at presenting the conclusions reached and the reasoning behind the choice being made. VPN solutions draft Conclusions and rationale Document a base approach with minimal changes to standards Optimizations considered (but postponed) We need a home agent inside the enterprise We need an external mobility agent IPSec does not have standardize mobility (SA endpoint update) and we want "seamless" mobility even when outside We need to support FAs in the external networks => the lowest layer must speak MIP Some problems left out of scope for now e.g., network with only HTTP access Three layer solution Topology External home agent + firewall + internal home agent First step: discovering whether inside or outside. Send RRQ to external and internal HA, get response from only internal HA. When MN is outside Send RRQ to both external and internal HA, get response only from external HA Then run IKE, VPN address assignment Then run RRQ inside tunnel to internal HA. Must use reverse tunneling to internal HA External movement is handled just by external HA/Mobile IP Pros and Cons of 3 layer solution Pros Only MN is aware No changes to IPSec of MIPv4 Cons Overhead (latency, packet size) Three layers to manage (e.g., authentication) Software complexity Three layers != three boxes Combined VPN + HA box possible Status -02 missing some comments; pending security review George Tsirtsis: do the HA's need to be close to the firewall? Sami: no Charlie What you are assuming, is that it is difficult to make the internal HA visible to the firewall. Typically, firewalls do permit visibility to an internal host. Sami yes, but we are assuming that we have to go through IPSec gateway Charlie why? Maybe packets to HA would not need to be IPSec protected, nothing prevents you from using IPSec to the HA This solution goes beyond complex to fantastically complex Sami: if each HA were part of the security perimeter, our solution would be simpler, but very hard to achieve in practice. but yes we would like to work on optimizations. Henrik: using IPSec directly to the HA is one way, but is not acceptable to many network administrators. We don't have to work on it in any case because it's already supported by standards. If we have to pick one, this is it. Kleung: this is one reason we need a deployment WG. RajeshKumar: Generally, VPN manufacturers are a bit different from mobility vendors It's very hard to get someones IPSec client to work with someone else's software. Given that, don't foresee that some vendor will be able to deal with all different IPSec implementations. So implementation of firewall will be separate from HA for some time. Gopal: complexity is a very relative term. This is a pretty simple solution. Gabriel: any implementation experience? Sami: yes, some, it's doable with client in Windows. It's not too easy but it's possible. It has been used in practice already. Henrik: Birdstep has one commercially available, we have one internally available Gabriel: seems like this would have a certain overhead even if you are internal, right? You have to wait for both registrations to detect where you are, and there are some retry issues. Sami: yes, but strategy is that if you get a response back from the internal HA, you just forget about external HA. If external one responds first, you can accept it optimistically, or retry a few times. Gabriel: you can maybe use some L2 information Sami: yes, you might keep a table of MAC addresses but need to keep in mind security Charlie: intended to be a solution to work without changing administrative practice As it's presented, it seems to say that this complicated solution is the base solution, and benefit is that you don't have to change anything. I would request to present this solution as a trade-off. One is to admit packets to go back to the HA. HA is supposed to deal with security. It is reasonable to suggest to a firewall administrator that they allow packets to go to HA unprotected. Thomas: charlie's point is a pretty good one, you should have an applicability statement. If you are willing to punch holes in the firewall, maybe you can have a slightly more efficient solution. [more discussion back and forth between gopal & charlie & thomas...] Sami: we will clarify for next draft. Dynamic HA discussion: 20 min I-D: draft-kilkarni-mobileip-dynamic-assignment-01.txt Presenter: Kent Leung Capability already deployed in some wireless operators Optimal Home Agent for geographically/topologically distant locations Reduce configuration needs on Mobile Nodes (HA pre-assignment not required) Allow network to select and administratively assign HA to MN Load balance MNs among multiple HAs Hope to accomplish before next IETF Finalize WG charter and chairs Settled by 4 weeks from the end of the meeting Short WGLC on Low Latency handoff in July To IESG in August Progress AAA keys and NAI Interactions with AAA WG RFC 3012bis to IESG in August MIPv4 problem statement to IESG pete: security quesiton is the most important one, yes. but this problem of configuring a SA across domains is very hard. in pp2 we don't have it yet cuz we're waiting for aaa keys and aaa-mipv4 henrik: why both all 0's and all 1's, why not choose 1? pete: diam mipv4 applic did make a difference we don't, we only allow assignemtn in the home domain, but eventually we want to have it also request in the foreign domain panasonic: would like to see more security discussion kent: yes, but we don't want to get tied down to only one method charlie: why not use the initial HA makes the encoding instead of the AAA (analogous to AAA keys). so do you insist on leaving it open? kent: yes charlie: but for example, which SPI to use? there's a roadmap with the AAA drafts, why not use it? kent: not diff from 3344 charlie: yes different, additional parameters to store and transport, in 3344 each HA-MN requires a different MSA ??: route optimization to solve this? kent: you need one ha already. here you don't need to have anythijng configured raj: the point is if you wish to keep the ha closer pete: this draft should not go forward without a security solution. it really should be part of the same roadmap as aaa keys and aaa-mipv4. and not comfortable with sharing one MSA for a group of HA's kent: aaa is not the only way to do it pete: but it should have at least one way of doing it raj: pick a specific method, perhaps the aaa-mipv4 application, but there's need for a solution cuz the current rfc3344 won't quite work Roadmap ------- thomas: finalize WG and chairs within 4 weeks Narten: Status of AAA keys? Tom: most comments addressed, but Lifetime field not used. Charlie: sporadic mention of route optimization for MIPv4, but charter seems to be crafted to exclude it. Under what circumstances would it become a work item? Raj: haven't necessarily seen as much interest. Need to generate interest on mailing list. Gabriel: we were looking at aggressively reducing the number of items. Narten: we should focus on issues where theres deployment experience/issues. Working group needs to come up with criteria for when there is real interest. Real interoperability problems for deployment. Kent Leung: (maybe controversial, but) could we consider Experimental message types similar to VSAs, but act as feedback to standardization. Raj: similar to VSAs that we already have KL: not an extension, but a message type Narten: there are some numbers to use for experimentation/testing, if obstacles we can talk about it. Raj: other items, 3012 bis Gab: reminder that Wednesday morning is MIP6/MIPSHOP IRTF BOF: registration desk 10pm tonight Dave Johnson: Mobicom 2003, Sep 14-19, San Diego http://www.sigmobile.org/mobicom/2003/ _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 12:14: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 MAA22759 for ; Wed, 6 Aug 2003 12:14: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 19kQvK-0004LT-JQ for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 12:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76GE2J5016697 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 12:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQvK-0004LD-EO for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 12:14: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 MAA22753 for ; Wed, 6 Aug 2003 12:13:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQvJ-0004Ep-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 12:14:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kQvI-0004Em-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 12:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQvJ-0004L0-6K; Wed, 06 Aug 2003 12:14:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kQuL-0004J7-9u for mip4@optimus.ietf.org; Wed, 06 Aug 2003 12:13: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 MAA22715 for ; Wed, 6 Aug 2003 12:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kQuK-0004EM-00 for mip4@ietf.org; Wed, 06 Aug 2003 12:13:00 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kQuJ-0004ED-00 for mip4@ietf.org; Wed, 06 Aug 2003 12:12:59 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h76GBmD08583; Wed, 6 Aug 2003 11:11:49 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h76GBl100657; Wed, 6 Aug 2003 11:11:47 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ7GZI-00005S-00; Wed, 06 Aug 2003 12:11:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.10429.271908.5337@gargle.gargle.HOWL> Date: Wed, 6 Aug 2003 11:11:41 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: Henrik Levkowetz , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Ahmad, Ahmad Muhanna writes: > Hi Pete, > Comments inline. > > Regards, > Ahmad > > > > > Isn't this open to a similar denial of service attack, > > assuming that link layer spoofing is possible? That is, an > > attacker can send spoofed solicitations at a very high rate, > > causing the FA to repeatedly (unicast) the agent > > advertisements with fresh challenges to the victim's mobile > > node. It could happen that the mobile is never able to > > register because a new solicitation arrives at the FA before > > the victim's RRQ. The solicitation/advertisement effectively > > pushes the last unicast challenge out of the 1 slot. > > > > I Agree. > > > Perhaps it should be possible to return the same challenge > > value in successive unicast solicited agent advertisements, > > as long as it was not previously used (recall "previously > > used" means used with a valid MN-AAA or MN-FA authentication > > extension). > > I Agree. > > >I think the same procedure (returning the same > > challenge) should be followed for unsuccessful Registration > > Requests where the MN-AAA (or MN-FA) authentication did not > > check out. If desired, we could change the challenge value > > after some fairly long period of time (like, 1 minute would > > easily be long enough to avoid this DoS) if we are really > > worried about robustness. > > > > I think we need to leave this flexible with the condition above. > FA can not send a previously used challenge to a specific MN. > I believe this is quite enough. How about a note in the security considerations section? See below for some suggested text... > > > > Option 3: Provides guideline to implementers on probable > > security threat. > > This was my earlier proposal. > > > > Ok. I don't think guidelines is sufficient, I believe we > > need requirements > to avoid the exact interoperability > > problems we recently experienced. > > > > > > I would suggest we can have opinions/suggestions from > > others as well. I > > don't have any issue in incorporating > > the option agreed by all. > > > > > > Right. > > > > I think some changes to the draft are in order to avoid the > > DoS attacks pointed out by Henrik. > > I thought Henrik concern was about the consequences of FA does not include a > fresh challenge in the RRP. I'll let Henrik speak for himself, but I think his comments were directed specifically at how the FA responds to solicitations and which challenges will be valid for use after it does so. > > > We also should have some text to clarify the handling of > > unicast > solicited advertisements. I guess we agree on the > > handling of those? > (i.e. a new challenge should be > > generated, and treated analogous to > a challenge returned > > with a registration reply?) > > > > There is one further change we maybe should review as part > > of this: To > change the requirement on returning a > > challenge with any registration > response from a SHOULD to > > a MUST. Any viewpoints on that? > > > > Sounds like a good idea, although see above about returning the same > > (unused) challenge in successive (unsuccessful) responses. > > > > I think we need to leave this for implementation with the standard > restriction of > Previously unused challenge. Ok, so the main body of the text can say that the FA always sends a previously unused challenge, with the understanding that "previously used" is defined as we have agreed (i.e., includes FA validity checks). How about this for the security considerations: Note that an active attacker may try to prevent successful registrations by sending a large number of Agent Solicitations or bogus Registration Requests, each of which could cause the FA to respond with a fresh challenge, invalidating the challenge that the MN is currently trying to use. To prevent such attacks, the FA SHOULD repeat the same challenge value in successive unicast responses to Agent Solicitations or in Registration Replies to Requests that did not contain valid MN-AAA or MN-FA authentication extensions for some limited period of time. Note that each challenge returned to an MN MUST be previously unused by that MN. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:02: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 NAA24706 for ; Wed, 6 Aug 2003 13: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 19kRfn-0006T5-0W for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:02:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76H22CN024862 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRfm-0006Sv-RP for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:02:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24690 for ; Wed, 6 Aug 2003 13:01:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRfl-0004gB-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:02:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kRfk-0004g8-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:02:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRfl-0006Si-5s; Wed, 06 Aug 2003 13: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 19kRfW-0006SP-1G for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:01: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 NAA24684 for ; Wed, 6 Aug 2003 13:01:41 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRfU-0004g3-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:01:44 -0400 Received: from sam.comnets.uni-bremen.de ([134.102.186.10] helo=bugs.comnets.uni-bremen.de) by ietf-mx with esmtp (Exim 4.12) id 19kRfT-0004g0-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:01:43 -0400 Received: from scoobydoo (scoobydoo.comnets.uni-bremen.de [134.102.155.152]) by bugs.comnets.uni-bremen.de (8.11.0/8.11.0/SuSE Linux 8.11.0-0.4) with ESMTP id h76H1gK09433 for ; Wed, 6 Aug 2003 19:01:42 +0200 X-Authentication-Warning: bugs.comnets.uni-bremen.de: Host scoobydoo.comnets.uni-bremen.de [134.102.155.152] claimed to be scoobydoo From: "Koojana Kuladinithi" To: Date: Wed, 6 Aug 2003 19:03:44 +0200 Message-ID: <000001c35c3c$b17f29c0$989b6686@scoobydoo> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 7bit Subject: [Mip4] Inquiry about Hierachical Mobile IP for MIPv4 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello all, I think, following draft has expired. draft-ietf-mobileip-reg-tunnel-07.txt (on Hierarchical MIPv4) Can the authors or anybody else tell me why it is not pursued anymore? Kind regards Koojana University of Bremen FB 1 - IKOM/ComNets Koojana Kuladinithi BSc, MSc Otto-Hahn-Allee NW 1 28359 Bremen - Germany Tel.: +49 421 218 8264, Fax: +49 421 218 3601, Mobile: +49 160 2690070 Email: kuladinithi@ikom.org koo@comnets.uni-bremen.de _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:07: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 NAA24921 for ; Wed, 6 Aug 2003 13:07: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 19kRkc-0006fX-6j for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:07:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76H72Ql025629 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:07:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRkc-0006fI-0q for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:07: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 NAA24869 for ; Wed, 6 Aug 2003 13:06:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRka-0004j0-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:07:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kRkZ-0004ix-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13: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 19kRka-0006da-UK; Wed, 06 Aug 2003 13: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 19kRk6-0006d5-DR for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:06:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24831 for ; Wed, 6 Aug 2003 13:06:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRk4-0004ie-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:06:28 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19kRk2-0004iG-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:06:27 -0400 Received: (qmail 29578 invoked from network); 6 Aug 2003 17:05:46 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 6 Aug 2003 17:05:46 -0000 Date: Wed, 6 Aug 2003 19:05:44 +0200 From: Henrik Levkowetz To: Pete McCann Cc: "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , mip4@ietf.org Subject: Re: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in solicited ag ent advertisements Message-Id: <20030806190544.410d346e.henrik@levkowetz.com> In-Reply-To: <16176.6680.853910.39250@gargle.gargle.HOWL> References: <870397D7C140C84DB081B88396458DAF746AAE@zrc2c000.us.nortel.com> <20030805000438.3cb94910.henrik@levkowetz.com> <16176.6680.853910.39250@gargle.gargle.HOWL> 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, Seems we are on the same page. Comments on the proposal of conditional generation of new challenges inline: Tuesday 5 August 2003, Pete wrote: > > Hi, > > Henrik Levkowetz writes: > > > Option 2: solves the problem but adds extra burden on the FA. > > > > I guess you mean because it now needs to send unicast responses, rather > > than multicast? But if soliciting is done to refresh a challenge, then > > you'd still get just as many solicitations whether they were multicast > > or unicast. > > > > I would deem it an acceptable solution to limit solicited advertisements > > containing challenges to be unicast, never multicast. > > Isn't this open to a similar denial of service attack, assuming that > link layer spoofing is possible? That is, an attacker can send > spoofed solicitations at a very high rate, causing the FA to > repeatedly (unicast) the agent advertisements with fresh challenges to > the victim's mobile node. It could happen that the mobile is never > able to register because a new solicitation arrives at the FA before > the victim's RRQ. The solicitation/advertisement effectively pushes > the last unicast challenge out of the 1 slot. Yes, you're right. This could be just as damaging. > Perhaps it should be possible to return the same challenge value in > successive unicast solicited agent advertisements, as long as it was > not previously used (recall "previously used" means used with a valid > MN-AAA or MN-FA authentication extension). I think the same procedure > (returning the same challenge) should be followed for unsuccessful > Registration Requests where the MN-AAA (or MN-FA) authentication did > not check out. If desired, we could change the challenge value after > some fairly long period of time (like, 1 minute would easily be long > enough to avoid this DoS) if we are really worried about robustness. Yes, this seems like a good solution. Henrik > > > Option 3: Provides guideline to implementers on probable security threat. > > > This was my earlier proposal. > > > > Ok. I don't think guidelines is sufficient, I believe we need requirements > > to avoid the exact interoperability problems we recently experienced. > > > > I would suggest we can have opinions/suggestions from others as well. I > > > don't have any issue in incorporating the option agreed by all. > > > > Right. > > I think some changes to the draft are in order to avoid the DoS > attacks pointed out by Henrik. > > > We also should have some text to clarify the handling of unicast > > solicited advertisements. I guess we agree on the handling of those? > > (i.e. a new challenge should be generated, and treated analogous to > > a challenge returned with a registration reply?) > > > > There is one further change we maybe should review as part of this: To > > change the requirement on returning a challenge with any registration > > response from a SHOULD to a MUST. Any viewpoints on that? > > Sounds like a good idea, although see above about returning the same > (unused) challenge in successive (unsuccessful) responses. > > -Pete > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:08:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24951 for ; Wed, 6 Aug 2003 13:08:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRla-0006y1-Pt for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:08:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76H82Zf026775 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRla-0006xm-Ju for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:08: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 NAA24944 for ; Wed, 6 Aug 2003 13:07:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRlY-0004jX-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:08:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kRlY-0004jU-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:08:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRlZ-0006wZ-F1; Wed, 06 Aug 2003 13:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRkj-0006fr-7K for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:07: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 NAA24873 for ; Wed, 6 Aug 2003 13:07:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRkh-0004j6-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:07:07 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19kRkg-0004in-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:07:06 -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 h76H5p713182; Wed, 6 Aug 2003 12:05:51 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T02Q2>; Wed, 6 Aug 2003 12:05:52 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: Henrik Levkowetz , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Wed, 6 Aug 2003 12:05:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C3C.F8104F7C" 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_01C35C3C.F8104F7C Content-Type: text/plain Hi Pete, Comments inline. Regards, Ahmad > > > > How about this for the security considerations: > > Note that an active attacker may try to prevent successful > registrations by sending a large number of Agent Solicitations or > bogus Registration Requests, each of which could cause the FA to > respond with a fresh challenge, invalidating the challenge that the > MN is currently trying to use. To prevent such attacks, the FA > SHOULD repeat the same challenge value in successive unicast > responses to Agent Solicitations or in Registration Replies to > Requests that did not contain valid MN-AAA or MN-FA authentication > extensions for some limited period of time. Note that each > challenge returned to an MN MUST be previously unused by that MN. > Honestly, I am not sure if we are trying to restrict the standard for remote attacks that is not frequently happens nor absolutely prevented. It is usually hard to prevent any of these attacks anyway. The robust solution in my opinion is the one which offers a mechanism for the REAL MN to fight and recover from the consequences of such attack. Let us assume that one of these attacks happens. RFC3012bis offers a recovery solution for the real MN. In any of the mentioned scenarios happened, the REAL MN would be able to solicit and use the challenge received to register. The main concern is what the standard mandating, FA does not send a previously used challenge to MN. FA sends a fresh one in RRP or AA messages, let us leave it to implementation with the unused challenge restriction. > -Pete > > > ------_=_NextPart_001_01C35C3C.F8104F7C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in = s olicited ag ent advertisements

Hi Pete,
Comments inline.

Regards,
Ahmad

>
>
>
> How about this for the security = considerations:
>
>   Note that an active attacker may = try to prevent successful
>   registrations by sending a large = number of Agent Solicitations or
>   bogus Registration Requests, each = of which could cause the FA to
>   respond with a fresh challenge, = invalidating the challenge that the
>   MN is currently trying to = use.  To prevent such attacks, the FA
>   SHOULD repeat the same challenge = value in successive unicast
>   responses to Agent Solicitations or = in Registration Replies to
>   Requests that did not contain valid = MN-AAA or MN-FA authentication
>   extensions for some limited period = of time.  Note that each
>   challenge returned to an MN MUST be = previously unused by that MN.
>

Honestly, I am not sure if we are trying to restrict = the standard for remote attacks that is not frequently happens nor = absolutely prevented.

It is usually hard to prevent any of these attacks = anyway.
The robust solution in my opinion is the one which = offers a mechanism for the REAL MN to fight and recover from the = consequences of such attack.

Let us assume that one of these attacks happens. =
RFC3012bis offers a recovery solution for the real = MN.
In any of the mentioned scenarios happened, the REAL = MN would be able to solicit and use the challenge received to = register.

The main concern is what the standard mandating, FA = does not send a previously used challenge to MN.
FA sends a fresh one in RRP or AA messages, let us = leave it to implementation with the unused challenge = restriction.


> -Pete
>
>
>

------_=_NextPart_001_01C35C3C.F8104F7C-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:23: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 NAA25481 for ; Wed, 6 Aug 2003 13:23: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 19kS06-0007lj-Qy for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:23:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HN2SX029857 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:23:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS06-0007lR-MZ for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13: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 NAA25462 for ; Wed, 6 Aug 2003 13:22:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS04-0004tF-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:23:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kS03-0004tC-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:22:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS05-0007kZ-4R; Wed, 06 Aug 2003 13:23:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kRzw-0007jz-4Y for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:22:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25459 for ; Wed, 6 Aug 2003 13:22:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kRzu-0004t5-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:22:50 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19kRzs-0004sr-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:22:49 -0400 Received: (qmail 29980 invoked from network); 6 Aug 2003 17:22:08 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 6 Aug 2003 17:22:08 -0000 Date: Wed, 6 Aug 2003 19:22:07 +0200 From: Henrik Levkowetz To: "Ahmad Muhanna" Cc: mip4 , "Jayshree Bharatia" Message-Id: <20030806192207.42c1074c.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: 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 Hi Ahmad, Responding in 2 separate messages to your two comments: Wednesday 6 August 2003, Ahmad wrote: > I am sorry for the late response. > Comments inline. > > Regards, > Ahmad > > > 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. > > <> > Well, I do not want to go into a theoretical debate here BUT let us examine > what RFC2119 says about SHOULD: > > " > 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. > " > I am not sure what was the valid reason for any implementer to ignore this > one! > Was there an understanding of the full implication here!! > <> Well, the thing is, there are implementations out there which does not return a new challenge with all registration replies. If we wish to arrange for better interoperability, it doesn't really matter if we feel they are wrong in not following the SHOULD, but rather that we decide what is the behaviour needed for consistent interoperability, and require that, no? Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:28: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 NAA25594 for ; Wed, 6 Aug 2003 13:28: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 19kS4w-0007tP-Ek for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:28:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HS2xv030333 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:28:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS4w-0007t6-9D for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:28: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 NAA25590 for ; Wed, 6 Aug 2003 13:27:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS4u-0004vA-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:28:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kS4t-0004v7-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:27:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS4v-0007rs-AI; Wed, 06 Aug 2003 13:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS4n-0007rf-DF for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:27: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 NAA25585 for ; Wed, 6 Aug 2003 13:27:49 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS4l-0004v4-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:27:51 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19kS4k-0004ur-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:27:50 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h76HQm715654; Wed, 6 Aug 2003 12:26:48 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0272>; Wed, 6 Aug 2003 12:26:49 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Henrik Levkowetz'" Cc: mip4 , "Jayshree Bharatia" Date: Wed, 6 Aug 2003 12:26:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C3F.E5EB078A" 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_01C35C3F.E5EB078A Content-Type: text/plain Hi Henrik, Comments inline. Regards, Ahmad > > Well, the thing is, there are implementations out there which > does not return a new challenge with all registration > replies. If we wish to arrange for better interoperability, > it doesn't really matter if we feel they are wrong in not > following the SHOULD, but rather that we decide what is the > behaviour needed for consistent interoperability, and require > that, no? > OK. I understand BUT you are proposing a change anyway. Why not proposing that those products follow the best recommendation of the standard And start including a fresh new challenge in RRP messages. This will solve the interoperability issue. > Henrik > > > > ------_=_NextPart_001_01C35C3F.E5EB078A Content-Type: text/html RE: [mobile-ip] New issue: 3012bis challenges in solicited agent advertisements

Hi Henrik,
Comments inline.

Regards,
Ahmad

>
> Well, the thing is, there are implementations out there which
> does not return a new challenge with all registration
> replies. If we wish to arrange for better interoperability,
> it doesn't really matter if we feel they are wrong in not
> following the SHOULD, but rather that we decide what is the
> behaviour needed for consistent interoperability, and require
> that, no?
>

OK. I understand BUT you are proposing a change anyway.
Why not proposing that those products follow the best recommendation of the standard
And start including a fresh new challenge in RRP messages.
This will solve the interoperability issue.


>       Henrik
>
>
>
>

------_=_NextPart_001_01C35C3F.E5EB078A-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:29: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 NAA25635 for ; Wed, 6 Aug 2003 13:29: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 19kS5u-000813-BJ for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:29:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76HT2cL030808 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:29:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS5u-00080p-7g for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:29:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25617 for ; Wed, 6 Aug 2003 13:28:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS5s-0004vX-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:29:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kS5r-0004vU-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:28:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kS5t-0007z2-4J; Wed, 06 Aug 2003 13: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 19kS5e-0007yg-UV for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:28: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 NAA25614 for ; Wed, 6 Aug 2003 13:28:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kS5c-0004vR-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:28:45 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19kS5b-0004vE-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:28:43 -0400 Received: (qmail 30013 invoked from network); 6 Aug 2003 17:28:07 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 6 Aug 2003 17:28:07 -0000 Date: Wed, 6 Aug 2003 19:28:06 +0200 From: Henrik Levkowetz To: "Ahmad Muhanna" Cc: mip4 , "Jayshree Bharatia" Message-Id: <20030806192806.281d0303.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: 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 Hi Ahmad, Responding to your second comment: Wednesday 6 August 2003, Ahmad wrote: [...] > > > 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? > > <> > Although, it is clearly mandates the FA to send a challenge that the MN can > use for Replay Protection/authentication. > Apparently FA can not communicate a previously used Challenge to a specific > MN. Yes? > How to implement the above is left as implementation specific and standard > should not restrict it. > > <> As long as we don't provide a specification on how to handle solicited advertisements, and there may be both interoperability and security issues with some of the possible implementations, I'd say that we have a flawed standard. I'm sure that the present lack of text on the matter does not stem from a desire to leave it implementation dependent, but rather that no-one had come across the potential problem and formulated a solution. I believe that we should not leave this wide open and undefined. Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:39: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 NAA26090 for ; Wed, 6 Aug 2003 13:39: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 19kSFZ-0000FG-Po for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:39:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Hd14K000935 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSFZ-0000F0-LA for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:39: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 NAA26041 for ; Wed, 6 Aug 2003 13:38:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSFX-00050a-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:38:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSFX-00050X-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:38:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSFY-0000EG-LB; Wed, 06 Aug 2003 13:39:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSF4-0000E4-GN for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:38:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26015 for ; Wed, 6 Aug 2003 13:38:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSF2-0004zz-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:38:28 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kSF1-0004zn-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:38:27 -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 h76HbFU25074; Wed, 6 Aug 2003 12:37:15 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h76HbE119180; Wed, 6 Aug 2003 12:37:14 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ7KXX-0001UO-00; Wed, 06 Aug 2003 13:37:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.15555.764721.27999@gargle.gargle.HOWL> Date: Wed, 6 Aug 2003 12:37:07 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: Henrik Levkowetz , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Ahmad, See below. Ahmad Muhanna writes: > > How about this for the security considerations: > > > > Note that an active attacker may try to prevent successful > > registrations by sending a large number of Agent Solicitations or > > bogus Registration Requests, each of which could cause the FA to > > respond with a fresh challenge, invalidating the challenge that the > > MN is currently trying to use. To prevent such attacks, the FA > > SHOULD repeat the same challenge value in successive unicast > > responses to Agent Solicitations or in Registration Replies to > > Requests that did not contain valid MN-AAA or MN-FA authentication > > extensions for some limited period of time. Note that each > > challenge returned to an MN MUST be previously unused by that MN. > > > > Honestly, I am not sure if we are trying to restrict the standard for remote > attacks that is not frequently happens nor absolutely prevented. > It is usually hard to prevent any of these attacks anyway. Yes, denial of service is possible for anyone that has access to the channel (just flood it with traffic); however, we should make every effort to ensure that our standards do not introduce new possible attacks to Mobile IP registration or make existing attacks any easier. I think that is what the current 3012-bis document may have done, unless the implementation is very careful to prevent it. > The robust solution in my opinion is the one which offers a mechanism for > the REAL MN to fight and recover from the consequences of such attack. Agreed. > Let us assume that one of these attacks happens. > RFC3012bis offers a recovery solution for the real MN. > In any of the mentioned scenarios happened, the REAL MN would be able to > solicit and use the challenge received to register. The scenario I have in mind is where an attacker inserts a new solicitation (or even bogus registration request) right after every advertisement or registration reply to the MN. This enables denial of service to the MN without requiring the attacker to completely flood the channel; i.e., it is a stronger kind of attack that we have opened up with the Challenge mechanism. > The main concern is what the standard mandating, FA does not send a > previously used challenge to MN. > FA sends a fresh one in RRP or AA messages, let us leave it to > implementation with the unused challenge restriction. We should be writing a document that enables anyone to implement the specification in a robust way, even those that have not participated in or seen this e-mail thread. We should not be hiding easter-eggs for deployments to trip over later. Do you really object to the note that I suggested for the security considerations section? -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:40: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 NAA26152 for ; Wed, 6 Aug 2003 13:40: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 19kSGY-0000K9-IY for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:40:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76He2Cn001239 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:40:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSGY-0000Ju-Db for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:40: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 NAA26125 for ; Wed, 6 Aug 2003 13:39:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSGW-00051T-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:40:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSGV-00051Q-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:39:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSGX-0000Jd-7W; Wed, 06 Aug 2003 13:40:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSFc-0000Fv-Rv for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:39:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26045 for ; Wed, 6 Aug 2003 13:39:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSFa-00050f-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:39:02 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19kSFZ-000502-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:39:01 -0400 Received: (qmail 30101 invoked from network); 6 Aug 2003 17:38:30 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 6 Aug 2003 17:38:30 -0000 Date: Wed, 6 Aug 2003 19:38:30 +0200 From: Henrik Levkowetz To: "Ahmad Muhanna" Cc: mip4 Message-Id: <20030806193830.3504edda.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: 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 Hi Ahmad, I believe that if we want to ensure a certain implementation, the correct way is to have the RFC text express what we want, rather than to try to convince equipment manufacturers that a certain "SHOULD" in practice should be read as a "MUST". In fact, I think that if I tried to say something like that to them, they would be in their full right to tell me to 'go and re-read the RFC, see, it actually says "SHOULD"'. So if we agree on how to implement this, we need to have the RFC express it. Of course, if we don't agree, then we instead need to re-examine the issue on those grounds. Henrik Wednesday 6 August 2003, Ahmad wrote: > Hi Henrik, > Comments inline. > > Regards, > Ahmad > > > > > Well, the thing is, there are implementations out there which > > does not return a new challenge with all registration > > replies. If we wish to arrange for better interoperability, > > it doesn't really matter if we feel they are wrong in not > > following the SHOULD, but rather that we decide what is the > > behaviour needed for consistent interoperability, and require > > that, no? > > > > OK. I understand BUT you are proposing a change anyway. > Why not proposing that those products follow the best recommendation of the > standard > And start including a fresh new challenge in RRP messages. > This will solve the interoperability issue. > > > > Henrik > > > > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 13:52:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26823 for ; Wed, 6 Aug 2003 13:52:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSSF-0000xZ-6I for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 13:52:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Hq7cp003683 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 13:52:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSSA-0000wl-WC for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 13:52: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 NAA26810 for ; Wed, 6 Aug 2003 13:51:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSS7-0005Bo-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:51:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSS6-0005Bl-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 13:51:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSS8-0000vy-E1; Wed, 06 Aug 2003 13:52:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSRD-0000uw-UG for mip4@optimus.ietf.org; Wed, 06 Aug 2003 13:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26701 for ; Wed, 6 Aug 2003 13:51:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSRB-0005AV-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:51:01 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19kSR9-0005A5-00 for mip4@ietf.org; Wed, 06 Aug 2003 13:51:00 -0400 Received: (qmail 30201 invoked from network); 6 Aug 2003 17:50:27 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 6 Aug 2003 17:50:27 -0000 Date: Wed, 6 Aug 2003 19:50:27 +0200 From: Henrik Levkowetz To: Pete McCann Cc: "Ahmad Muhanna" , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" Subject: Re: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Message-Id: <20030806195027.7424ab8a.henrik@levkowetz.com> In-Reply-To: <16177.10429.271908.5337@gargle.gargle.HOWL> References: <16177.10429.271908.5337@gargle.gargle.HOWL> 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 6 August 2003, Pete wrote a proposal for an addition to the security considerations in response to various comments: [...] > > > We also should have some text to clarify the handling of > > > unicast solicited advertisements. I guess we agree on the > > > handling of those? (i.e. a new challenge should be > > > generated, and treated analogous to a challenge returned > > > with a registration reply?) > > > > > > There is one further change we maybe should review as part > > > of this: To change the requirement on returning a > > > challenge with any registration response from a SHOULD to > > > a MUST. Any viewpoints on that? > > > > > > Sounds like a good idea, although see above about returning the > > > same(unused) challenge in successive (unsuccessful) responses. > > > > > > > I think we need to leave this for implementation with the standard > > restriction of Previously unused challenge. > > Ok, so the main body of the text can say that the FA always sends a > previously unused challenge, with the understanding that "previously > used" is defined as we have agreed (i.e., includes FA validity > checks). > > How about this for the security considerations: > > Note that an active attacker may try to prevent successful > registrations by sending a large number of Agent Solicitations or > bogus Registration Requests, each of which could cause the FA to > respond with a fresh challenge, invalidating the challenge that the > MN is currently trying to use. To prevent such attacks, the FA > SHOULD repeat the same challenge value in successive unicast > responses to Agent Solicitations or in Registration Replies to > Requests that did not contain valid MN-AAA or MN-FA authentication > extensions for some limited period of time. Note that each > challenge returned to an MN MUST be previously unused by that MN. This sounds good to me. Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 14:19: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 OAA28016 for ; Wed, 6 Aug 2003 14:19: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 19kSsI-0002Js-KD for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 14:19:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76IJ2sg008912 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 14: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 19kSsI-0002Jf-Ft for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 14: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 OAA27985 for ; Wed, 6 Aug 2003 14:18:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSsG-0005Qg-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:19:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSsF-0005Qd-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14: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 19kSsH-0002JS-AF; Wed, 06 Aug 2003 14: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 19kSsG-0002JH-7h for mip4@optimus.ietf.org; Wed, 06 Aug 2003 14:19:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27978 for ; Wed, 6 Aug 2003 14:18:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSsD-0005QX-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:18:57 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19kSsC-0005Py-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:18:56 -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 h76IHo729263; Wed, 6 Aug 2003 13:17:50 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0KB7>; Wed, 6 Aug 2003 13:17:51 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746AB6@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Pete McCann'" , "Ahmad Muhanna" Cc: Henrik Levkowetz , mip4@ietf.org, "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Wed, 6 Aug 2003 13:17:43 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Pete, I disagree with the proposed text for the reason mentioned earlier for option 1 on this thread. If we have solution to the problem Henrik has pointed out, I agree that we must include that in this document. From the discussion we are having so far, it seems we don't have clean solution to survive challenge-response mechanism from the DOS attack. If the FA identifies that it is attacked, it can take actions like what it could have done normally (when no challenge-response mechanism is used). Regards, Jayshree > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Wednesday, August 06, 2003 12:37 PM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Henrik Levkowetz; mip4@ietf.org; Bharatia, Jayshree > [RICH1:2H13:EXCH]; 'charliep@iprg.nokia.com' > Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis > challenges in s olicited ag ent advertisements > > > > Hi, Ahmad, > > See below. > > Ahmad Muhanna writes: > > > How about this for the security considerations: > > > > > > Note that an active attacker may try to prevent successful > > > registrations by sending a large number of Agent > Solicitations or > > > bogus Registration Requests, each of which could cause > the FA to > > > respond with a fresh challenge, invalidating the > challenge that the > > > MN is currently trying to use. To prevent such attacks, the FA > > > SHOULD repeat the same challenge value in successive unicast > > > responses to Agent Solicitations or in Registration Replies to > > > Requests that did not contain valid MN-AAA or MN-FA > authentication > > > extensions for some limited period of time. Note that each > > > challenge returned to an MN MUST be previously unused > by that MN. > > > > > > > Honestly, I am not sure if we are trying to restrict the > standard for remote > attacks that is not frequently happens > nor absolutely prevented. > It is usually hard to prevent > any of these attacks anyway. > > Yes, denial of service is possible for anyone that has access > to the channel (just flood it with traffic); however, we > should make every effort to ensure that our standards do not > introduce new possible attacks to Mobile IP registration or > make existing attacks any easier. I think that is what the > current 3012-bis document may have done, unless the > implementation is very careful to prevent it. > > > The robust solution in my opinion is the one which offers > a mechanism for > the REAL MN to fight and recover from the > consequences of such attack. > > Agreed. > > > Let us assume that one of these attacks happens. > > RFC3012bis offers a recovery solution for the real MN. > > In any of the mentioned scenarios happened, the REAL MN > would be able to > solicit and use the challenge received to > register. > > The scenario I have in mind is where an attacker inserts a > new solicitation (or even bogus registration request) right > after every advertisement or registration reply to the MN. > This enables denial of service to the MN without requiring > the attacker to completely flood the channel; i.e., it is a > stronger kind of attack that we have opened up with the > Challenge mechanism. > > > The main concern is what the standard mandating, FA does > not send a > previously used challenge to MN. > FA sends a > fresh one in RRP or AA messages, let us leave it to > > implementation with the unused challenge restriction. > > We should be writing a document that enables anyone to > implement the specification in a robust way, even those that > have not participated in or seen this e-mail thread. We > should not be hiding easter-eggs for deployments to trip over > later. Do you really object to the note that I suggested for > the security considerations section? > > -Pete > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 14:21: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 OAA28090 for ; Wed, 6 Aug 2003 14:21: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 19kSuF-0002VZ-Cz for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 14:21:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76IL37F009634 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 14:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSuE-0002VJ-QT for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 14:21: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 OAA28063 for ; Wed, 6 Aug 2003 14:20:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kSuC-0005Rl-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kSuB-0005Ri-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kSuD-0002Tx-7B; Wed, 06 Aug 2003 14:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kStS-0002Mo-QF for mip4@optimus.ietf.org; Wed, 06 Aug 2003 14:20:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28048 for ; Wed, 6 Aug 2003 14:20:10 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kStQ-0005Re-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:20:12 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19kStP-0005RC-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:20:11 -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 h76IJ5729431; Wed, 6 Aug 2003 13:19:05 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0KC5>; Wed, 6 Aug 2003 13:19:06 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: Henrik Levkowetz , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Wed, 6 Aug 2003 13:19:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35C46.EEC058B8" 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_01C35C46.EEC058B8 Content-Type: text/plain Hi Pete, Please see comments inline. > > Yes, denial of service is possible for anyone that has access > to the channel (just flood it with traffic); however, we > should make every effort to ensure that our standards do not > introduce new possible attacks to Mobile IP registration or > make existing attacks any easier. I think that is what the > current 3012-bis document may have done, unless the > implementation is very careful to prevent it. > > > The robust solution in my opinion is the one which offers > a mechanism for > the REAL MN to fight and recover from the > consequences of such attack. > > Agreed. > > > Let us assume that one of these attacks happens. > > RFC3012bis offers a recovery solution for the real MN. > > In any of the mentioned scenarios happened, the REAL MN > would be able to > solicit and use the challenge received to > register. > > The scenario I have in mind is where an attacker inserts a > new solicitation (or even bogus registration request) right > after every advertisement or registration reply to the MN. > This enables denial of service to the MN without requiring > the attacker to completely flood the channel; i.e., it is a > stronger kind of attack that we have opened up with the > Challenge mechanism. > > > The main concern is what the standard mandating, FA does > not send a > previously used challenge to MN. > FA sends a > fresh one in RRP or AA messages, let us leave it to > > implementation with the unused challenge restriction. > > We should be writing a document that enables anyone to > implement the specification in a robust way, even those that > have not participated in or seen this e-mail thread. We > should not be hiding easter-eggs for deployments to trip over > later. Do you really object to the note that I suggested for > the security considerations section? Well, I do not see how the suggested comment provide a solution for this problem. As I said, we have a mechanism for recovery, which I believe enough. Adding this comment is ONLY delaying the effect of the attack for a period of time. Do not you agree? Reagrds, Ahmad > > -Pete > > ------_=_NextPart_001_01C35C46.EEC058B8 Content-Type: text/html RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements

Hi Pete,
Please see comments inline.

>
> Yes, denial of service is possible for anyone that has access
> to the channel (just flood it with traffic); however, we
> should make every effort to ensure that our standards do not
> introduce new possible attacks to Mobile IP registration or
> make existing attacks any easier. I think that is what the
> current 3012-bis document may have done, unless the
> implementation is very careful to prevent it.
>
>  > The robust solution in my opinion is the one which offers
> a mechanism for  > the REAL MN to fight and recover from the
> consequences of such attack.
>
> Agreed.
>
>  > Let us assume that one of these attacks happens.
>  > RFC3012bis offers a recovery solution for the real MN.
>  > In any of the mentioned scenarios happened, the REAL MN
> would be able to  > solicit and use the challenge received to
> register.
>
> The scenario I have in mind is where an attacker inserts a
> new solicitation (or even bogus registration request) right
> after every advertisement or registration reply to the MN. 
> This enables denial of service to the MN without requiring
> the attacker to completely flood the channel; i.e., it is a
> stronger kind of attack that we have opened up with the
> Challenge mechanism.
>
>  > The main concern is what the standard mandating, FA does
> not send a  > previously used challenge to MN.  > FA sends a
> fresh one in RRP or AA messages, let us leave it to  >
> implementation with the unused challenge restriction.
>
> We should be writing a document that enables anyone to
> implement the specification in a robust way, even those that
> have not participated in or seen this e-mail thread.  We
> should not be hiding easter-eggs for deployments to trip over
> later.  Do you really object to the note that I suggested for
> the security considerations section?

Well, I do not see how the suggested comment provide a solution for this problem.
As I said, we have a mechanism for recovery, which I believe enough.
Adding this comment is ONLY delaying the effect of the attack for a period of time.
Do not you agree?

Reagrds,
Ahmad
>
> -Pete
>
>

------_=_NextPart_001_01C35C46.EEC058B8-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 14:33: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 OAA28637 for ; Wed, 6 Aug 2003 14:33: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 19kT5q-00036e-Lc for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 14:33:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76IX2vI011936 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 14:33:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kT5q-00036R-GZ for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 14:33:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28627 for ; Wed, 6 Aug 2003 14:32:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kT5n-0005Ze-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:33:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kT5n-0005Zb-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:32:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kT5p-00035i-Ba; Wed, 06 Aug 2003 14:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kT5D-00033d-Tn for mip4@optimus.ietf.org; Wed, 06 Aug 2003 14:32:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28597 for ; Wed, 6 Aug 2003 14:32:19 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kT5B-0005ZU-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:32:21 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19kT5A-0005Z2-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:32:20 -0400 Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h76IVd701342; Wed, 6 Aug 2003 13:31:39 -0500 (CDT) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 30FXMFVL; Wed, 6 Aug 2003 13:31:39 -0500 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.37]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id P1LBW6YH; Wed, 6 Aug 2003 13:31:40 -0500 Message-ID: <3F3148D7.3020606@iqmail.net> Date: Wed, 06 Aug 2003 13:28:39 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com CC: mobile-ip@sunroof.eng.sun.com, mip4@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] config options with MIP messages Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit draft-le-aaa-diameter-mobileipv6-03.txt: Section 4.3: " This Binding Update MUST be authenticated, therefore a key distribution, e.g. IKE, may need to be executed. This requires many messages to be exchanged between the mobile node and the Home Agent. As an alternative, after the authentication and authorization steps, the AAA servers can be involved and play a role in the key generation and/or the key distribution. " I am surprised to see that you propose to use AAA infrastructure to do key distribution -> use AAA messages to do the job of IKE, however you were objecting to our proposal of using MIP messages to exchange DNS server info because we have DHCP... Just an observation. -Kuntal _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 14:44: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 OAA29111 for ; Wed, 6 Aug 2003 14:44: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 19kTGX-0003yu-V1 for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 14:44:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Ii5Dd015298 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 14:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTGX-0003ye-Q7 for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 14:44:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29100 for ; Wed, 6 Aug 2003 14:43:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTGR-0005i9-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:43:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kTGQ-0005i6-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:43:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTGT-0003xS-2s; Wed, 06 Aug 2003 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTGK-0003xF-EP for mip4@optimus.ietf.org; Wed, 06 Aug 2003 14:43:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29081 for ; Wed, 6 Aug 2003 14:43:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTGH-0005hg-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:43:49 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kTGG-0005h3-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:43:48 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h76IgbE17736; Wed, 6 Aug 2003 13:42:37 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h76Iga111759; Wed, 6 Aug 2003 13:42:36 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ7NYV-0001WS-00; Wed, 06 Aug 2003 14:42:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.19478.30441.175349@gargle.gargle.HOWL> Date: Wed, 6 Aug 2003 13:42:30 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: Henrik Levkowetz , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Ahmad, Ahmad Muhanna writes: > > We should be writing a document that enables anyone to > > implement the specification in a robust way, even those that > > have not participated in or seen this e-mail thread. We > > should not be hiding easter-eggs for deployments to trip over > > later. Do you really object to the note that I suggested for > > the security considerations section? > > Well, I do not see how the suggested comment provide a solution for this > problem. > As I said, we have a mechanism for recovery, which I believe enough. > Adding this comment is ONLY delaying the effect of the attack for a period > of time. > Do not you agree? No, I do not agree. I do not think the existing specification provides for recovery, and I think that the mechanism I suggested completely defeats the attack, or at least, restores the attacker to exactly the power he had before with simple channel-flooding. This is because new solicitations or (invalid) registration requests do not immediately push a valid challenge out of the currently valid set of challenges. This gives the MN time to receive the challenge, compute an authenticator, and send it to the FA even though many, many solicitations or (invalid) registration requests may have been processed in the meantime. Is that clear? -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 14:51: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 OAA29376 for ; Wed, 6 Aug 2003 14:51:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTNG-00044a-KM for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 14:51:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Ip2qU015650 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 14:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTNG-00044L-Ga for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 14:51:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29367 for ; Wed, 6 Aug 2003 14:50:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTND-0005nN-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:50:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kTND-0005nK-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 14:50:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTNF-000447-Ei; Wed, 06 Aug 2003 14:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTMp-00043q-PT for mip4@optimus.ietf.org; Wed, 06 Aug 2003 14:50: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 OAA29363 for ; Wed, 6 Aug 2003 14:50:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTMn-0005n8-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:50:33 -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 19kTMm-0005mv-00 for mip4@ietf.org; Wed, 06 Aug 2003 14:50:32 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 06 Aug 2003 11:54:45 -0700 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h76InwuG005450; Wed, 6 Aug 2003 11:49:59 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-103.cisco.com [128.107.163.103]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKB30470; Wed, 6 Aug 2003 11:43:55 -0700 (PDT) Message-ID: <3F314DD5.9070603@cisco.com> Date: Wed, 06 Aug 2003 11:49:57 -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: Pete McCann CC: mkulkarn@cisco.com, kleung@cisco.com, mip4@ietf.org References: <3F30037C.4090807@cisco.com> <16176.1711.242248.694789@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Re: Clarification for Dynamic HA assignment draft Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete: Okay, so I see that you mean. One concern that we had was that Diameter is still not an RFC and we would be referring to something not a RFC yet. That said, we don't have a problem in incorporating your observation. We can still continue using the term ALL_ZERO_ONE_ADDR - with specific meanings for 0.0.0.0 and 255.255.255.255. Following is the new text ... " ALL_ZERO_ONE_ADDR stands for 0.0.0.0 or 255.255.255.255. 255.255.255.255 would indicate assigning HA in home domain and 0.0.0.0 would mean MN just needs a dynamic HA, it does not care whether in home or visited domain." As already mentioned in the framework, the specific mechanisms to assign the local or visited HA are outside the scope. Let us know what you think. Alpesh Pete McCann wrote: >Hi, Alpesh, > >I think we should attempt to be compatible with the functionality >specified in the Mobile IPv4 Diameter specification, which is inside >Section 1.4 of draft-ietf-aaa-diameter-mobileip-14.txt: > >1.4 Allocation of Home Agent in Foreign Network > > The Diameter Mobile IP application allows a home agent to be > allocated in a foreign network, as required in [MIPREQ, CDMA2000]. > When a foreign agent detects that the mobile node has a home agent > address equal to 0.0.0.0 or 255.255.255.255 in the Registration > Request message, it MUST add a MIP-Feature-Vector AVP with the Home- > Agent- Requested flag set to one. If the home agent address is equal > to 255.255.255.255, then the foreign agent also MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to one. If the home > agent address is set to 0.0.0.0, the foreign agent MUST set the Home- > Address-Allocatable-Only-in-Home-Realm flag equal to zero. > >So yes, both values are used to request dynamic home agent, however, >one of them (255.255.255.255) indicates a preference for home realm >based HA while the other (0.0.0.0) represents that the MS doesn't care >whether the HA is in the home or visited realms. > >-Pete > > >Alpesh writes: > > Pete: > > > > This is regarding your comment/observation in last IETF while Kent > > was presenting the Dynamica HA assignment framework draft. > > > > Currently, we are proposing to use either 0.0.0.0 or 255.255.255.255 > > as the HA address to indicate dynamic HA assignment. I cross-checked > > IS-835C and they use these addresses interchangeably. > > > > You mentioned that some other draft is trying to separate the meaning of > > all zero and all ones. My concern is that, it the meaning is not already > > defined, > > should we rely on that draft? We want to accomodate the 3GPP2 model and > > since they are using both values to mean dynamic HA assignment, we want to > > go on that path. > > > > In future, if different meanings get assigned to each value, we can > > probably change > > our draft. > > > > Do you have comments/suggestions?? > > > > -a > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 15:14: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 PAA00957 for ; Wed, 6 Aug 2003 15:14: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 19kTjW-00058S-8l for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 15:14:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76JE22c019735 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 15:14:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTjW-00058E-3S for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 15:14: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 PAA00892 for ; Wed, 6 Aug 2003 15:13:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTjU-000621-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 15:14:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kTjU-00061y-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 15:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTjU-00057u-F4; Wed, 06 Aug 2003 15:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kTip-00057D-0g for mip4@optimus.ietf.org; Wed, 06 Aug 2003 15:13: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 PAA00816 for ; Wed, 6 Aug 2003 15:13:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kTin-00061E-00 for mip4@ietf.org; Wed, 06 Aug 2003 15:13:17 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19kTim-000616-00 for mip4@ietf.org; Wed, 06 Aug 2003 15:13:16 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h76JCg716112; Wed, 6 Aug 2003 14:12:42 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0LR1>; Wed, 6 Aug 2003 14:12:40 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746AB9@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Adrangi, Farid'" Cc: mip4@ietf.org Date: Wed, 6 Aug 2003 14:12:36 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) 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: , Hello Farid, Please see my reply below. Thanks, Jayshree -----Original Message----- From: Adrangi, Farid [mailto:farid.adrangi@intel.com] Sent: Sunday, August 03, 2003 11:50 PM To: Bharatia, Jayshree [RICH1:2H13:EXCH] Cc: mip4@ietf.org Subject: RE: Comments on VPN Problem Statement Draft Hello Jayshree, Thanks for following up on this. You, Gopal, and I had a very brief conversation on this during IETF-57 - but I am not sure if we derived any conclusion on whether or not we should include this scenario. To be frank, I don't quite understand the point behind adding this scenario because, - It seems to present a solution to a specific deployment model rather than a deployment scenario [JB] My understanding is different from yours so please elaborate what you mean by deployment model vs deployment scenario in this particular context. - I don't quite see the advantages of a combined VPN+FA if it does not support FA traversal and it does not avoid IPsec renegotiation when MN moves from one subnet to another - perhaps you can elaborate on this? [JB] I think regardless this scenario has any advantages or not, it is one of the probable scenario which has potential issues (as you have indicated earlier). - Furthermore, Scenarios in section 2 of the problem statement draft represents combinations of MIPv4 HA and VPN gateway placement - adding this scenario is going to change semantics of the section 2. [JB] I am not sure what you mean by semantics change here. Do you think documenting this in new subsection (2.6) is a problem? I have no problem adding this scenario to the draft - I just wanted to make sure that we clearly understand the reasons for adding this scenario to the problem statement draft. Design team members and interested individuals are welcome to express their opinion on this. Best regards, Farid The following sub-sections introduce five representative combinations of MIPv4 HA and VPN gateway placement. -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] Sent: Thursday, July 31, 2003 1:44 PM To: Adrangi, Farid Cc: 'mip4@ietf.org' Subject: RE: Comments on VPN Problem Statement Draft Hello Farid, As per our earlier discussion during IETF-57, my understanding is that you will include the scenario of co-existed FA with the VPN gateway in the VPN Problem Statement draft. I agree that this particular scenario has problems and it won't work if the MN is behind an FA in the foreign subnet. But again, this is a problem statement draft. Hence, I believe that this is the appropriate document for mentioning this scenario. Thanks, Jayshree -----Original Message----- From: Adrangi, Farid [mailto:farid.adrangi@intel.com] Sent: Monday, April 07, 2003 2:58 PM To: Bharatia, Jayshree [RICH1:2H13:EXCH] Cc: 'mobile-ip@sunroof.eng.sun.com' Subject: RE: Comments on VPN Problem Statement Draft Hello Jayshree This is a good point - I knew someone was to bring this up! At the time of writing these scenarios, we (the design team) actually discussed this and concluded this scenario would fall into a solution space. Maybe we did not make the right decision and we should rethink this. But, before we take this discussion further please allow me to ask you a few questions about the details of the scenario (VPN+FA) that you have in mind . Are you thinking to broadcast FA advertisements through the IPsec tunnel to the MN? If so, how will this work if MN is already behind an FA in the foreign subnet? Or, If you had something different in mind, perhaps you can elaborate on that. Best regards, Farid -----Original Message----- From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], Sent: Friday, April 04, 2003 3:14 PM To: 'farid.adrangi@intel.com' Cc: 'mobile-ip@sunroof.eng.sun.com' Subject: Comments on VPN Problem Statement Draft Hello Farid, This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) currently misses one scenario were the FA is co-existed with the VPN Gateway. I would think that there are no technical issues supporting this scenario. It will be good if you can add this scenario in the draft (perhaps as section 2.6?) for completeness. Thanks, Jayshree _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 17:42: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 RAA05979 for ; Wed, 6 Aug 2003 17:42: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 19kW2l-0003oa-KJ for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 17:42:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Lg3P9014660 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 17:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kW2l-0003oN-Ft for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 17:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05947 for ; Wed, 6 Aug 2003 17:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kW2j-0007RP-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 17:42:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kW2i-0007RL-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 17:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kW2j-0003nE-E4; Wed, 06 Aug 2003 17:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kW2R-0003lu-6o for mip4@optimus.ietf.org; Wed, 06 Aug 2003 17:41:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05928 for ; Wed, 6 Aug 2003 17:41:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kW2O-0007Qi-00 for mip4@ietf.org; Wed, 06 Aug 2003 17:41:40 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kW2O-0007QP-00 for mip4@ietf.org; Wed, 06 Aug 2003 17:41:40 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h76LeTE04592; Wed, 6 Aug 2003 16:40:30 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h76LeR122162; Wed, 6 Aug 2003 16:40:27 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ7W7A-0001GK-00; Wed, 06 Aug 2003 17:40:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.30148.684224.483266@gargle.gargle.HOWL> Date: Wed, 6 Aug 2003 16:40:20 -0500 From: Pete McCann To: "Jayshree Bharatia" Cc: "Ahmad Muhanna" , Henrik Levkowetz , mip4@ietf.org, "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements In-Reply-To: <870397D7C140C84DB081B88396458DAF746AB6@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746AB6@zrc2c000.us.nortel.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Jayshree, Jayshree Bharatia writes: > Pete, > > I disagree with the proposed text for the reason mentioned earlier for > option 1 on this thread. Let me see if I understand your objection. Here is your statement about Option 1: > Option 1: Not preferred since the whole point of using the challenge in the > agent advertisement is so that the MN can use this challenge information in > the registration procedure if needed. Restricting new challenge value breaks > the mechanism. I have reservation toward treating this specific case > differently especially since it has side effect (mentioned above). So, are you worried that if we duplicate the Challenge, then it might not be a fresh challenge that the MN can use? However, any challenge that is sent to the MN in either an RRQ or an Advertisement must be previously unused, as stated explicitly in the body of the document and in the text I proposed for the security considerations. So by definition, this challenge will be useful to the MN for its next RRQ. Is there something I have misunderstood? > If we have solution to the problem Henrik has > pointed out, I agree that we must include that in this document. From the > discussion we are having so far, it seems we don't have clean solution to > survive challenge-response mechanism from the DOS attack. If the FA > identifies that it is attacked, it can take actions like what it could have > done normally (when no challenge-response mechanism is used). What mechanisms are you referring to? There is a statement about rate-limiting agent advertisements in RFC 3344; however, it does not apply to unicast advertisements. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 6 17:50: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 RAA06593 for ; Wed, 6 Aug 2003 17:50: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 19kWAU-0003wR-Ac for mip4-archive@odin.ietf.org; Wed, 06 Aug 2003 17:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h76Lo2Wk015145 for mip4-archive@odin.ietf.org; Wed, 6 Aug 2003 17:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWAU-0003wC-6t for mip4-web-archive@optimus.ietf.org; Wed, 06 Aug 2003 17:50: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 RAA06570 for ; Wed, 6 Aug 2003 17:49:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kWAR-0007aS-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 17:49:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kWAR-0007aP-00 for mip4-web-archive@ietf.org; Wed, 06 Aug 2003 17:49:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWAT-0003vY-5P; Wed, 06 Aug 2003 17:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kWAI-0003v5-Ij for mip4@optimus.ietf.org; Wed, 06 Aug 2003 17:49:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06547 for ; Wed, 6 Aug 2003 17:49:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kWAF-0007aA-00 for mip4@ietf.org; Wed, 06 Aug 2003 17:49:47 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kWAE-0007ZR-00 for mip4@ietf.org; Wed, 06 Aug 2003 17:49:46 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h76Ln4E08069; Wed, 6 Aug 2003 16:49:04 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h76Ln3110656; Wed, 6 Aug 2003 16:49:03 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ7WLL-0001U8-00; Wed, 06 Aug 2003 17:48:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16177.30664.613224.623418@gargle.gargle.HOWL> Date: Wed, 6 Aug 2003 16:48:56 -0500 From: Pete McCann To: Alpesh Cc: mkulkarn@cisco.com, kleung@cisco.com, mip4@ietf.org Subject: [Mip4] Re: Clarification for Dynamic HA assignment draft In-Reply-To: <3F314DD5.9070603@cisco.com> References: <3F30037C.4090807@cisco.com> <16176.1711.242248.694789@gargle.gargle.HOWL> <3F314DD5.9070603@cisco.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Alpesh, Looks good. I also look forward to an expanded security considerations section in your next version of the draft. -Pete Alpesh writes: > Pete: > > Okay, so I see that you mean. One concern that we had was that Diameter > is still not an RFC and we would be referring to something not a RFC yet. > > That said, we don't have a problem in incorporating your observation. We can > still continue using the term ALL_ZERO_ONE_ADDR - with specific meanings > for 0.0.0.0 and 255.255.255.255. > > Following is the new text ... > > " ALL_ZERO_ONE_ADDR stands for 0.0.0.0 or 255.255.255.255. > 255.255.255.255 would indicate assigning HA in home domain and > 0.0.0.0 would mean MN just needs a dynamic > HA, it does not care whether in home or visited domain." > > As already mentioned in the framework, the specific mechanisms to assign > the > local or visited HA are outside the scope. > > Let us know what you think. > Alpesh _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 7 12:07: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 MAA20391 for ; Thu, 7 Aug 2003 12:07: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 19knIA-0004FW-Cs for mip4-archive@odin.ietf.org; Thu, 07 Aug 2003 12:07:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77G76oe016330 for mip4-archive@odin.ietf.org; Thu, 7 Aug 2003 12:07:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knIA-0004FB-5V for mip4-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 12:07: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 MAA20368 for ; Thu, 7 Aug 2003 12:06:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knI8-0000Ef-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 12:07:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19knI8-0000EO-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 12:07:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19knI5-0004Cp-HE; Thu, 07 Aug 2003 12: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 19knHL-00048X-0u for mip4@optimus.ietf.org; Thu, 07 Aug 2003 12:06: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 MAA20327 for ; Thu, 7 Aug 2003 12:06:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19knHJ-0000Do-00 for mip4@ietf.org; Thu, 07 Aug 2003 12:06:13 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19knHI-0000Dg-00 for mip4@ietf.org; Thu, 07 Aug 2003 12:06:13 -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 h77G4kh10427; Thu, 7 Aug 2003 11:04:46 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0YDN>; Thu, 7 Aug 2003 11:04:47 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746ABB@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Pete McCann'" Cc: "Ahmad Muhanna" , Henrik Levkowetz , mip4@ietf.org, "'charliep@iprg.nokia.com'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Thu, 7 Aug 2003 11:04:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35CFD.9E1ECEAA" 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_01C35CFD.9E1ECEAA Content-Type: text/plain Hi Pete, I am struggling between the scope of this document and the problem we are trying to solve. Your current proposal is applicable when FA identifies that it is being attacked. By that time, chances are that the synchronization (wrt challenge) between the mobile node and the FA may not be maintained. The purpose of this draft is to provide challenge-response mechanism for the replay protection. If it is not possible to maintain challenges the way this draft is proposing (due to DOS attack), how far can we go in providing solution? Although, you are suggesting to use previously unused challenge, it still has to fall in the challenge window as per the current text in this draft. If the FA already knows that it is being attacked, I would think that it can also take actions like not sending the response or sending the response without challenge. For me, this will have same impact of repeating previous challenge (at least in this context). So my earlier email indicated that leave it up to the FA how it wants to recover. So the question I have is, in this document, are we trying to maintain the correct challenge window or are we trying to recover from the attack? This will help formulating the text for the "security consideration" section. Regards, Jayshree > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Wednesday, August 06, 2003 4:40 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Henrik Levkowetz; > mip4@ietf.org; 'charliep@iprg.nokia.com' > Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis > challenges in s olicited ag ent advertisements > > > > Hi, Jayshree, > > Jayshree Bharatia writes: > > Pete, > > > > I disagree with the proposed text for the reason mentioned > earlier for > option 1 on this thread. > > Let me see if I understand your objection. Here is your > statement about Option 1: > > > Option 1: Not preferred since the whole point of using the > challenge in the > agent advertisement is so that the MN can > use this challenge information in > the registration > procedure if needed. Restricting new challenge value breaks > > the mechanism. I have reservation toward treating this > specific case > differently especially since it has side > effect (mentioned above). > > So, are you worried that if we duplicate the Challenge, then > it might not be a fresh challenge that the MN can use? > > However, any challenge that is sent to the MN in either an > RRQ or an Advertisement must be previously unused, as stated > explicitly in the body of the document and in the text I > proposed for the security considerations. So by definition, > this challenge will be useful to the MN for its next RRQ. Is > there something I have misunderstood? > > > If we have solution to the problem Henrik has > > pointed out, I agree that we must include that in this > document. From the > discussion we are having so far, it > seems we don't have clean solution to > survive > challenge-response mechanism from the DOS attack. If the FA > > identifies that it is attacked, it can take actions like > what it could have > done normally (when no > challenge-response mechanism is used). > > What mechanisms are you referring to? There is a statement > about rate-limiting agent advertisements in RFC 3344; > however, it does not apply to unicast advertisements. > > -Pete > > > ------_=_NextPart_001_01C35CFD.9E1ECEAA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in = s olicited ag ent advertisements

Hi Pete,

I am struggling between the scope of this document = and the problem we are trying to solve. Your current proposal is = applicable when FA identifies that it is being attacked. By that time, = chances are that the synchronization (wrt challenge) between the mobile = node and the FA may not be maintained. The purpose of this draft is to = provide challenge-response mechanism for the replay protection. If it = is not possible to maintain challenges the way this draft is proposing = (due to DOS attack), how far can we go in providing solution? Although, = you are suggesting to use previously unused challenge, it still has to = fall in the challenge window as per the current text in this = draft.

If the FA already knows that it is being attacked, I = would think that it can also take actions like not sending the response = or sending the response without challenge. For me, this will have same = impact of repeating previous challenge (at least in this context). So = my earlier email indicated that leave it up to the FA how it wants to = recover.

So the question I have is, in this document, are we = trying to maintain the correct challenge window or are we trying to = recover from the attack? This will help formulating the text for the = "security consideration" section.

Regards,
Jayshree
 
> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Wednesday, August 06, 2003 4:40 PM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: Muhanna, Ahmad [RICH2:2Q30:EXCH]; Henrik = Levkowetz;
> mip4@ietf.org; 'charliep@iprg.nokia.com'
> Subject: RE: [Mip4] Re: [mobile-ip] Re: New = issue: 3012bis
> challenges in s olicited ag ent = advertisements
>
>
>
> Hi, Jayshree,
>
> Jayshree Bharatia writes:
>  > Pete,
>  >
>  > I disagree with the proposed text = for the reason mentioned
> earlier for  > option 1 on this thread. =
>
> Let me see if I understand your = objection.  Here is your
> statement about Option 1:
>
>  > Option 1: Not preferred since the = whole point of using the
> challenge in the  > agent advertisement = is so that the MN can
> use this challenge information in  > = the registration
> procedure if needed. Restricting new challenge = value breaks 
> > the mechanism. I have reservation toward = treating this
> specific case  > differently especially = since it has side
> effect (mentioned above).
>
> So, are you worried that if we duplicate the = Challenge, then
> it might not be a fresh challenge that the MN = can use?
>
> However, any challenge that is sent to the MN = in either an
> RRQ or an Advertisement must be previously = unused, as stated
> explicitly in the body of the document and in = the text I
> proposed for the security considerations.  = So by definition,
> this challenge will be useful to the MN for its = next RRQ.  Is
> there something I have misunderstood?
>
>  > If we have solution to the problem = Henrik has
>  > pointed out, I agree that we must = include that in this
> document. From the  > discussion we are = having so far, it
> seems we don't have clean solution to  = > survive
> challenge-response mechanism from the DOS = attack. If the FA 
> > identifies that it is attacked, it can = take actions like
> what it could have  > done normally = (when no
> challenge-response mechanism is used).
>
> What mechanisms are you referring to?  = There is a statement
> about rate-limiting agent advertisements in RFC = 3344;
> however, it does not apply to unicast = advertisements.
>
> -Pete
>
>
>

------_=_NextPart_001_01C35CFD.9E1ECEAA-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 7 13:13: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 NAA22600 for ; Thu, 7 Aug 2003 13:13: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 19koK3-00083A-Ma for mip4-archive@odin.ietf.org; Thu, 07 Aug 2003 13:13:09 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77HD7c1030938 for mip4-archive@odin.ietf.org; Thu, 7 Aug 2003 13:13:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koK2-00082t-0o for mip4-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 13:13: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 NAA22566 for ; Thu, 7 Aug 2003 13:12:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koJw-0000nv-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 13:13:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19koJv-0000ns-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 13:12:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koJw-00081H-JG; Thu, 07 Aug 2003 13:13:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19koJG-00080r-8t for mip4@optimus.ietf.org; Thu, 07 Aug 2003 13:12: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 NAA22556 for ; Thu, 7 Aug 2003 13:12:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19koJE-0000nf-00 for mip4@ietf.org; Thu, 07 Aug 2003 13:12:16 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19koJD-0000nY-00 for mip4@ietf.org; Thu, 07 Aug 2003 13:12: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 h77HB3h26809; Thu, 7 Aug 2003 12:11:03 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T0ZV2>; Thu, 7 Aug 2003 12:11:04 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: Henrik Levkowetz , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , "'Luca Salgarelli'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Thu, 7 Aug 2003 12:11:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35D06.E06F61EE" 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_01C35D06.E06F61EE Content-Type: text/plain Hi Pete, Sorry for the late response. Regards, Ahmad > > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > > We should be writing a document that enables anyone to > > > implement the specification in a robust way, even those that > > > have not participated in or seen this e-mail thread. We > > > should not be hiding easter-eggs for deployments to trip over > > > later. Do you really object to the note that I suggested for > > > the security considerations section? > > > > Well, I do not see how the suggested comment provide a > solution for this > problem. > As I said, we have a > mechanism for recovery, which I believe enough. > > Adding this comment is ONLY delaying the effect of the > attack for a period > of time. > Do not you agree? > > No, I do not agree. I do not think the existing > specification provides for recovery, and I think that the > mechanism I suggested completely defeats the attack, or at > least, restores the attacker to exactly the power he had > before with simple channel-flooding. This is because new > solicitations or (invalid) registration requests do not > immediately push a valid challenge out of the currently valid > set of challenges. This gives the MN time to receive the > challenge, compute an authenticator, and send it to the FA > even though many, many solicitations or (invalid) > registration requests may have been processed in the meantime. > > Is that clear? > After thinking this over and checking an old thread on similar issue with Charlie and Luca, And checking Appendix E, I believe that the Challenge_Window meant to be for the periodically sent Challenges in Agent Advertisement messages that are multicast. I do not think that the Challenge-Window is related to the unicasted AA messages. (unicasted AA is ONLY communicated to One single MN) Having this in mind and the FA periodically (time based) issuing these multicast Agent Advertisement Messages, I believe that FA is supposed to continue sending the latest challenge from the Challenge-Window in a unicast AA message until the next time a new advertised challenge is generated. I do not think that it is possible to issue a new challenge via unicast AA message and consider that as part of the Challenge-Window; since that Challenge is not available for all Mobile Nodes. I believe this address the original concern of this thread. What do you think? I regard to the bogus Registration Request, If the MN receives the successful Reply and an attacker sends A bogus RRQ; YES this will invalidates the Challenge sent in the successful RRP BUT the MN is already registered and will not need to re-register until some good time in the future. > -Pete > > ------_=_NextPart_001_01C35D06.E06F61EE Content-Type: text/html RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements

Hi Pete,
Sorry for the late response.

Regards,
Ahmad

>
>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > > We should be writing a document that enables anyone to
>  > > implement the specification in a robust way, even those that
>  > > have not participated in or seen this e-mail thread.  We
>  > > should not be hiding easter-eggs for deployments to trip over
>  > > later.  Do you really object to the note that I suggested for
>  > > the security considerations section?
>  >
>  > Well, I do not see how the suggested comment provide a
> solution for this  > problem.  > As I said, we have a
> mechanism for recovery, which I believe enough.
>  > Adding this comment is ONLY delaying the effect of the
> attack for a period  > of time.  > Do not you agree?
>
> No, I do not agree.  I do not think the existing
> specification provides for recovery, and I think that the
> mechanism I suggested completely defeats the attack, or at
> least, restores the attacker to exactly the power he had
> before with simple channel-flooding.  This is because new
> solicitations or (invalid) registration requests do not
> immediately push a valid challenge out of the currently valid
> set of challenges.  This gives the MN time to receive the
> challenge, compute an authenticator, and send it to the FA
> even though many, many solicitations or (invalid)
> registration requests may have been processed in the meantime.
>
> Is that clear?
>

After thinking this over and checking an old thread on similar issue with Charlie and Luca,
And checking Appendix E, I believe that the Challenge_Window meant to be for the periodically
sent Challenges in Agent Advertisement messages that are multicast. I do not think that the
Challenge-Window is related to the unicasted AA messages. (unicasted AA is ONLY communicated to
One single MN)

Having this in mind and the FA periodically (time based) issuing these multicast Agent Advertisement
Messages, I believe that FA is supposed to continue sending the latest challenge from the Challenge-Window
in a unicast AA message until the next time a new advertised challenge is generated. I do not think that
it is possible to issue a new challenge via unicast AA message and consider that as part of the Challenge-Window;
since that Challenge is not available for all Mobile Nodes.
I believe this address the original concern of this thread. What do you think?
 
I regard to the bogus Registration Request, If the MN receives the successful Reply and an attacker sends
A bogus RRQ; YES this will invalidates the Challenge sent in the successful RRP BUT the MN is already
registered and will not need to re-register until some good time in the future.

> -Pete
>
>

------_=_NextPart_001_01C35D06.E06F61EE-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 7 15:34: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 PAA29516 for ; Thu, 7 Aug 2003 15:34: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 19kqWR-0001R4-1X for mip4-archive@odin.ietf.org; Thu, 07 Aug 2003 15:34:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77JY3ZI005518 for mip4-archive@odin.ietf.org; Thu, 7 Aug 2003 15:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqWQ-0001Qv-Rr for mip4-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 15:34: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 PAA29496 for ; Thu, 7 Aug 2003 15:33:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqWP-0002An-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 15:34:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kqWO-0002Ak-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 15:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqWP-0001Qd-JZ; Thu, 07 Aug 2003 15:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kqVr-0001Pz-GH for mip4@optimus.ietf.org; Thu, 07 Aug 2003 15:33: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 PAA29478 for ; Thu, 7 Aug 2003 15:33:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kqVp-0002Ad-00 for mip4@ietf.org; Thu, 07 Aug 2003 15:33:25 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19kqVo-0002A3-00 for mip4@ietf.org; Thu, 07 Aug 2003 15:33:24 -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 h77JWAU13445; Thu, 7 Aug 2003 14:32:11 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h77JW8A24862; Thu, 7 Aug 2003 14:32:08 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJ9KXF-0001YS-00; Thu, 07 Aug 2003 15:32:03 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16178.43313.73696.625201@gargle.gargle.HOWL> Date: Thu, 7 Aug 2003 14:32:01 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: Henrik Levkowetz , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , "'Luca Salgarelli'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Ahmad, Ahmad Muhanna writes: > > Ahmad Muhanna writes: > > > > We should be writing a document that enables anyone to > > > > implement the specification in a robust way, even those that > > > > have not participated in or seen this e-mail thread. We > > > > should not be hiding easter-eggs for deployments to trip over > > > > later. Do you really object to the note that I suggested for > > > > the security considerations section? > > > > > > Well, I do not see how the suggested comment provide a > > solution for this > problem. > As I said, we have a > > mechanism for recovery, which I believe enough. > > > Adding this comment is ONLY delaying the effect of the > > attack for a period > of time. > Do not you agree? > > > > No, I do not agree. I do not think the existing > > specification provides for recovery, and I think that the > > mechanism I suggested completely defeats the attack, or at > > least, restores the attacker to exactly the power he had > > before with simple channel-flooding. This is because new > > solicitations or (invalid) registration requests do not > > immediately push a valid challenge out of the currently valid > > set of challenges. This gives the MN time to receive the > > challenge, compute an authenticator, and send it to the FA > > even though many, many solicitations or (invalid) > > registration requests may have been processed in the meantime. > > > > Is that clear? > > > > After thinking this over and checking an old thread on similar issue with > Charlie and Luca, > And checking Appendix E, I believe that the Challenge_Window meant to be for > the periodically > sent Challenges in Agent Advertisement messages that are multicast. I do not > think that the > Challenge-Window is related to the unicasted AA messages. (unicasted AA is > ONLY communicated to > One single MN) I technically agree with you here, but I think there is another per-MN data structure you have forgotten about (see below). > Having this in mind and the FA periodically (time based) issuing these > multicast Agent Advertisement > Messages, I believe that FA is supposed to continue sending the latest > challenge from the Challenge-Window > in a unicast AA message until the next time a new advertised challenge is > generated. I do not think that > it is possible to issue a new challenge via unicast AA message and consider > that as part of the Challenge-Window; > since that Challenge is not available for all Mobile Nodes. > I believe this address the original concern of this thread. What do you > think? But if that Challenge was "previously used" by the MN, it seems proper to generate a new challenge, no? And even though that challenge is not in the global "Challenge-Window" list it should be remembered in a data structure related to that particular mobile node, and should be considered as a valid challenge for that MN. This is reflected in the very last clause of this paragraph from Appendix E: In the program fragment, it is presumed that the foreign agent keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the last advertised challenge used by a mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply. So, I think this should be modified to say "also a record of the last challenge provided to a mobile node in a Registration Reply or unicast Agent Advertisement." > I regard to the bogus Registration Request, If the MN receives the > successful Reply and an attacker sends > A bogus RRQ; YES this will invalidates the Challenge sent in the successful > RRP BUT the MN is already > registered and will not need to re-register until some good time in the > future. It's important to remember that the above data structure is kept only for nodes that have a prior, valid registration. This is to prevent state-exhaustion attacks on the FA. So, I agree with you that it is proper to repeat the last value from the Challenge-Window record of multicast advertisements if you are dealing with an MN of which you have no record. Otherwise, you should repeat the last challenge from your per-MN data structure. It is ok to change this challenge after a longish-period of time (say 1 minute) and that might provide some robustness/security benefit, but you shouldn't change it on every bogus RRQ or un-authenticated solicitation. You should of course change it whenever that challenge becomes "previously used." Perhaps you are saying here that the damage isn't so bad: at most an attacker can prevent a re-registration, and eventually the visitor list entry will timeout, causing the FA to forget all "previously used" challenges for the MN. Then the MN can re-register with any challenge from the global Challenge-Window and re-enable service. However, there could still be a fairly large gap between the timeout of the visitor list entry and the successful re-registration, especially because the MN will experience a long series of STALE_CHALLENGE responses, and it may have backed off on its registration attempts in the meantime. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 7 17:20:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03483 for ; Thu, 7 Aug 2003 17:20:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksBU-0006E9-31 for mip4-archive@odin.ietf.org; Thu, 07 Aug 2003 17:20:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77LKW9S023933 for mip4-archive@odin.ietf.org; Thu, 7 Aug 2003 17:20:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksBT-0006Dw-Jt for mip4-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 17:20:31 -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 RAA03465 for ; Thu, 7 Aug 2003 17:20:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ksAy-0006Ca-OE; Thu, 07 Aug 2003 17: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 19ksAd-0006C1-WF for mip4@optimus.ietf.org; Thu, 07 Aug 2003 17:19: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 RAA03422 for ; Thu, 7 Aug 2003 17:19:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ksAb-0002vD-00 for mip4@ietf.org; Thu, 07 Aug 2003 17:19:37 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19ksAa-0002v3-00 for mip4@ietf.org; Thu, 07 Aug 2003 17:19:36 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h77LIUh00773; Thu, 7 Aug 2003 16:18:30 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <301T00SC>; Thu, 7 Aug 2003 16:18:30 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: Henrik Levkowetz , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , "'Luca Salgarelli'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Thu, 7 Aug 2003 16:18:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35D29.704C2D8E" 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_01C35D29.704C2D8E Content-Type: text/plain Hi Pete, Regards, Ahmad > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Thursday, August 07, 2003 2:32 PM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: Henrik Levkowetz; mip4@ietf.org; Bharatia, Jayshree > [RICH1:2H13:EXCH]; 'charliep@iprg.nokia.com'; 'Luca Salgarelli' > Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis > challenges in s olicited ag ent advertisements > > > > Hi, Ahmad, > > Ahmad Muhanna writes: > > > Ahmad Muhanna writes: > > > > > > No, I do not agree. I do not think the existing > > > specification provides for recovery, and I think that the > > > mechanism I suggested completely defeats the attack, or at > > > least, restores the attacker to exactly the power he had > > > before with simple channel-flooding. This is because new > > > solicitations or (invalid) registration requests do not > > > immediately push a valid challenge out of the currently valid > > > set of challenges. This gives the MN time to receive the > > > challenge, compute an authenticator, and send it to the FA > > > even though many, many solicitations or (invalid) > > > registration requests may have been processed in the meantime. > > > Is that clear? > > > > > > > After thinking this over and checking an old thread on similar issue with > > Charlie and Luca, And checking Appendix E, I believe that the Challenge_Window > > meant to be for the periodically sent Challenges in Agent Advertisement messages > > that are multicast. I do not think that the > > Challenge-Window is related to the unicasted AA messages. (unicasted AA is > > ONLY communicated to One single MN) > > I technically agree with you here, but I think there is > another per-MN data structure you have forgotten about (see below). > > > Having this in mind and the FA periodically (time based) issuing these > > multicast Agent Advertisement > > Messages, I believe that FA is supposed to continue > > sending the latest challenge from the Challenge-Window > > in a unicast AA message until the next time a new > > advertised challenge is generated. I do not think that > > it is possible to issue a new challenge via unicast AA > > message and consider that as part of the Challenge-Window; > > since that Challenge is not available for all Mobile > > Nodes. I believe this address the original concern of this > > thread. What do you think? > > But if that Challenge was "previously used" by the MN, it > seems proper to generate a new challenge, no? And even I absolutely agree with you here. BUT let us be frank. This has to be taken in light of the whole mechanism offered By RFC3012bis. When this was discussed about (April 2002) in another thread, we were very much concerned to have the challenge mechanism work with an optimized solution for scalability and storage requirement. Achieving the most optimized storage requirement as mentioned in Appendix E was done with some assumptions in mid. 1. Minimum Challenge-Window size of 2, as recommended. 2. FA includes a challenge in every RRP message to avoid Agent Solicitation messages; since RRP is sent to the MN anyway. 3. FA needs to keep track of the latest challenge every MN used while from the Challenge-Window. 4. Since the Challenge-Window has a value of 2, it is required that the MN MUST use the latest advertised (multicast) Challenge. This will enable FA to keep track with ONLY one used challenge from the Challenge-Window and NOT 2. 5. FA need to keep track with the latest Challenge sent in the latest RRP message. Even in this one, FA does not need to keep track of the latest used challenge from the RRP. Because FA would send either UNKNOWN or STALE Challenge; respectively. Now: all of this is the minimum the standard requires the FA to have to maintain a robust solution. E.g. 1. some FA would track the challenges sent in unicast Agent Advertisement message per MN because they do not send New challenge in every RRP, it is an implementation issue. 2. Some FA would like to keep track of the last used challenge per MN from RRP to send Stale Challenge, implementation specific. 3. Some FA would like to keep track with the last two used challenges from the Challenge-Window; that is cool. 4. etc.... > though that challenge is not in the global "Challenge-Window" > list it should be remembered in a data structure related to > that particular mobile node, and should be considered as a > valid challenge for that MN. This is reflected in the very > last clause of this paragraph from Appendix E: > > In the program fragment, it is presumed that the foreign agent > keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a > record of the last advertised challenge used by a mobile node, and > also a record of the last challenge provided to a mobile node in a > Registration Reply. > > So, I think this should be modified to say "also a record of > the last challenge provided to a mobile node in a > Registration Reply or unicast Agent Advertisement." > > > I regard to the bogus Registration Request, If the MN > > receives the successful Reply and an attacker sends A > > bogus RRQ; YES this will invalidates the Challenge sent in > > the successful RRP BUT the MN is already > > registered and will not need to re-register until some > > good time in the future. > > It's important to remember that the above data structure is > kept only for nodes that have a prior, valid registration. > This is to prevent state-exhaustion attacks on the FA. So, I > agree with you that it is proper to repeat the last value > from the Challenge-Window record of multicast advertisements > if you are dealing with an MN of which you have no record. > Otherwise, you should repeat the last challenge from your > per-MN data structure. It is ok to change this challenge > after a longish-period of time (say 1 minute) and that might > provide some robustness/security benefit, but you shouldn't > change it on every bogus RRQ or un-authenticated > solicitation. You should of course change it whenever that > challenge becomes "previously used." > > Perhaps you are saying here that the damage isn't so bad: at > most an attacker can prevent a re-registration, and > eventually the visitor list entry will timeout, causing the > FA to forget all "previously used" challenges for the MN. > Then the MN can re-register with any challenge from the > global Challenge-Window and re-enable service. However, there > could still be a fairly large gap between the timeout of the > visitor list entry and the successful re-registration, > especially because the MN will experience a long series of > STALE_CHALLENGE responses, and it may have backed off on its > registration attempts in the meantime. > Mostly true. BUT I meant two things: 1. MN has a plenty of time to pick one of the latest advertised challenges (multicast) for re-registration. 2. If MN is not listening to these challenges, MN would solicit and receive the latest challenge from the Window-challenge (multicast Advertised) and use it for re-registration. > -Pete > > ------_=_NextPart_001_01C35D29.704C2D8E Content-Type: text/html RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements

Hi Pete,

Regards,
Ahmad


> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Thursday, August 07, 2003 2:32 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: Henrik Levkowetz; mip4@ietf.org; Bharatia, Jayshree
> [RICH1:2H13:EXCH]; 'charliep@iprg.nokia.com'; 'Luca Salgarelli'
> Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis
> challenges in s olicited ag ent advertisements
>
>
>
> Hi, Ahmad,
>
> Ahmad Muhanna writes:
>  > > Ahmad Muhanna writes:
>  > >
>  > > No, I do not agree.  I do not think the existing
>  > > specification provides for recovery, and I think that the
>  > > mechanism I suggested completely defeats the attack, or at
>  > > least, restores the attacker to exactly the power he had
>  > > before with simple channel-flooding.  This is because new
>  > > solicitations or (invalid) registration requests do not
>  > > immediately push a valid challenge out of the currently valid
>  > > set of challenges.  This gives the MN time to receive the
>  > > challenge, compute an authenticator, and send it to the FA
>  > > even though many, many solicitations or (invalid)
>  > > registration requests may have been processed in the meantime.
>  > > Is that clear?
>  > >
>  >
>  > After thinking this over and checking an old thread on similar issue with 
>  > Charlie and Luca, And checking Appendix E, I believe that the Challenge_Window
>  > meant to be for the periodically sent Challenges in Agent Advertisement messages
>  > that are multicast. I do not think that the
>  > Challenge-Window is related to the unicasted AA messages. (unicasted AA is 
>  > ONLY communicated to One single MN)
>
> I technically agree with you here, but I think there is
> another per-MN data structure you have forgotten about (see below).
>
>  > Having this in mind and the FA periodically (time based) issuing these 
>  > multicast Agent Advertisement
>  > Messages, I believe that FA is supposed to continue
>  > sending the latest challenge from the Challenge-Window
>  > in a unicast AA message until the next time a new
>  > advertised challenge is generated. I do not think that
>  > it is possible to issue a new challenge via unicast AA
>  > message and consider that as part of the Challenge-Window;
>  > since that Challenge is not available for all Mobile
>  > Nodes. I believe this address the original concern of this
>  > thread. What do you think?
>
> But if that Challenge was "previously used" by the MN, it
> seems proper to generate a new challenge, no?  And even

I absolutely agree with you here. BUT let us be frank.
This has to be taken in light of the whole mechanism offered By RFC3012bis. When this was discussed about (April 2002) in another thread, we were very much concerned to have the challenge mechanism work with an optimized solution for scalability and storage requirement.

Achieving the most optimized storage requirement as mentioned in Appendix E was done with some assumptions in mid.

1. Minimum Challenge-Window size of 2, as recommended.
2. FA includes a challenge in every RRP message to avoid Agent Solicitation messages; since RRP is sent to the MN anyway.

3. FA needs to keep track of the latest challenge every MN used while from the Challenge-Window.
4. Since the Challenge-Window has a value of 2, it is required that the MN MUST use the latest advertised (multicast) Challenge. This will enable FA to keep track with ONLY one used challenge from the Challenge-Window and NOT 2.

5. FA need to keep track with the latest Challenge sent in the latest RRP message. Even in this one, FA does not need to keep track of the latest used challenge from the RRP. Because FA would send either UNKNOWN or STALE Challenge; respectively.

Now: all of this is the minimum the standard requires the FA to have to maintain a robust solution.
E.g.
1. some FA would track the challenges sent in unicast Agent Advertisement message per MN because they do not send New challenge in every RRP, it is an implementation issue.

2. Some FA would like to keep track of the last used challenge per MN from RRP to send Stale Challenge, implementation specific.

3. Some FA would like to keep track with the last two used challenges from the Challenge-Window; that is cool.
4. etc....

> though that challenge is not in the global "Challenge-Window"
> list it should be remembered in a data structure related to
> that particular mobile node, and should be considered as a
> valid challenge for that MN.  This is reflected in the very
> last clause of this paragraph from Appendix E:
>
>    In the program fragment, it is presumed that the foreign agent
>    keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a
>    record of the last advertised challenge used by a mobile node, and
>    also a record of the last challenge provided to a mobile node in a
>    Registration Reply.
>
> So, I think this should be modified to say "also a record of
> the last challenge provided to a mobile node in a
> Registration Reply or unicast Agent Advertisement."
>
>  > I regard to the bogus Registration Request, If the MN
>  > receives the successful Reply and an attacker sends A
>  > bogus RRQ; YES this will invalidates the Challenge sent in
>  > the successful RRP BUT the MN is already
>  > registered and will not need to re-register until some
>  > good time in the future.
>
> It's important to remember that the above data structure is
> kept only for nodes that have a prior, valid registration. 
> This is to prevent state-exhaustion attacks on the FA.  So, I
> agree with you that it is proper to repeat the last value
> from the Challenge-Window record of multicast advertisements
> if you are dealing with an MN of which you have no record. 
> Otherwise, you should repeat the last challenge from your
> per-MN data structure.  It is ok to change this challenge
> after a longish-period of time (say 1 minute) and that might
> provide some robustness/security benefit, but you shouldn't
> change it on every bogus RRQ or un-authenticated
> solicitation.  You should of course change it whenever that
> challenge becomes "previously used."
>
> Perhaps you are saying here that the damage isn't so bad: at
> most an attacker can prevent a re-registration, and
> eventually the visitor list entry will timeout, causing the
> FA to forget all "previously used" challenges for the MN. 
> Then the MN can re-register with any challenge from the
> global Challenge-Window and re-enable service. However, there
> could still be a fairly large gap between the timeout of the
> visitor list entry and the successful re-registration,
> especially because the MN will experience a long series of
> STALE_CHALLENGE responses, and it may have backed off on its
> registration attempts in the meantime.
>

Mostly true. BUT I meant two things:
1. MN has a plenty of time to pick one of the latest advertised challenges (multicast) for re-registration.
2. If MN is not listening to these challenges, MN would solicit and receive the latest challenge from the Window-challenge (multicast Advertised) and use it for re-registration.


> -Pete
>
>

------_=_NextPart_001_01C35D29.704C2D8E-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 7 18:22: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 SAA06736 for ; Thu, 7 Aug 2003 18:22: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 19kt92-0000CJ-GB for mip4-archive@odin.ietf.org; Thu, 07 Aug 2003 18:22:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h77MM4g2000759 for mip4-archive@odin.ietf.org; Thu, 7 Aug 2003 18:22:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kt92-0000CA-7v for mip4-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 18:22:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06707 for ; Thu, 7 Aug 2003 18:21:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kt8z-0003Hx-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 18:22:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kt8y-0003Hu-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 18:22:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kt8y-0000BD-B3; Thu, 07 Aug 2003 18:22:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kt8C-0000At-Nd for mip4@optimus.ietf.org; Thu, 07 Aug 2003 18:21: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 SAA06623 for ; Thu, 7 Aug 2003 18:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kt89-0003Gs-00 for mip4@ietf.org; Thu, 07 Aug 2003 18:21:09 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19kt88-0003Gh-00 for mip4@ietf.org; Thu, 07 Aug 2003 18:21:08 -0400 Received: (qmail 10076 invoked from network); 7 Aug 2003 22:20:36 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 7 Aug 2003 22:20:36 -0000 Date: Fri, 8 Aug 2003 00:20:36 +0200 From: Henrik Levkowetz To: "Ahmad Muhanna" Cc: "'Pete McCann'" , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , "'Luca Salgarelli'" Subject: Re: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Message-Id: <20030808002036.5681e2da.henrik@levkowetz.com> In-Reply-To: References: X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: 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 7 August 2003, Ahmad wrote in response to Pete McCann: [...] > > Ahmad Muhanna writes: > > > > Ahmad Muhanna writes: > > > > > > > > No, I do not agree. I do not think the existing > > > > specification provides for recovery, and I think that the > > > > mechanism I suggested completely defeats the attack, or at > > > > least, restores the attacker to exactly the power he had > > > > before with simple channel-flooding. This is because new > > > > solicitations or (invalid) registration requests do not > > > > immediately push a valid challenge out of the currently valid > > > > set of challenges. This gives the MN time to receive the > > > > challenge, compute an authenticator, and send it to the FA > > > > even though many, many solicitations or (invalid) > > > > registration requests may have been processed in the meantime. > > > > Is that clear? > > > > > > > > > > After thinking this over and checking an old thread on similar > > > issue with Charlie and Luca, And checking Appendix E, I believe > > > that the Challenge_Window meant to be for the periodically sent > > > Challenges in Agent Advertisement messages that are multicast. I > > > do not think that the Challenge-Window is related to the > > > unicasted AA messages.(unicasted AA is ONLY communicated to One > > > single MN) So far, we're in agreement. > > > > I technically agree with you here, but I think there is > > another per-MN data structure you have forgotten about (see below). > > > > > Having this in mind and the FA periodically (time based) issuing > > > these > > > multicast Agent Advertisement > > > Messages, I believe that FA is supposed to continue > > > sending the latest challenge from the Challenge-Window > > > in a unicast AA message until the next time a new > > > advertised challenge is generated. I do not think that > > > it is possible to issue a new challenge via unicast AA > > > message and consider that as part of the Challenge-Window; > > > since that Challenge is not available for all Mobile > > > Nodes. I believe this address the original concern of this > > > thread. What do you think? > > > > But if that Challenge was "previously used" by the MN, it > > seems proper to generate a new challenge, no? And even > > I absolutely agree with you here. BUT let us be frank. > This has to be taken in light of the whole mechanism offered By > RFC3012bis. When this was discussed about (April 2002) in another > thread, we were very much concerned to have the challenge mechanism > work with an optimized solution for scalability and storage > requirement. Achieving the most optimized storage requirement as > mentioned in Appendix E was done with some assumptions in mid. That's fine. Now, as far as I can see, the proposed changes maintain the data structures proposed in Appendix E, not adding additional storage requirements, so we don't have a problem in this respect. [...] > > though that challenge is not in the global "Challenge-Window" > > list it should be remembered in a data structure related to > > that particular mobile node, and should be considered as a > > valid challenge for that MN. This is reflected in the very > > last clause of this paragraph from Appendix E: > > > > In the program fragment, it is presumed that the foreign agent > > keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), > > a record of the last advertised challenge used by a mobile node, > > and also a record of the last challenge provided to a mobile node > > in a Registration Reply. > > > > So, I think this should be modified to say "also a record of > > the last challenge provided to a mobile node in a > > Registration Reply or unicast Agent Advertisement." Yes, that makes sense. > > > In regard to the bogus Registration Request, If the MN > > > receives the successful Reply and an attacker sends A > > > bogus RRQ; YES this will invalidates the Challenge sent in > > > the successful RRP BUT the MN is already > > > registered and will not need to re-register until some > > > good time in the future. > > > > It's important to remember that the above data structure is > > kept only for nodes that have a prior, valid registration. > > This is to prevent state-exhaustion attacks on the FA. So, I > > agree with you that it is proper to repeat the last value > > from the Challenge-Window record of multicast advertisements > > if you are dealing with an MN of which you have no record. > > Otherwise, you should repeat the last challenge from your > > per-MN data structure. It is ok to change this challenge > > after a longish-period of time (say 1 minute) and that might > > provide some robustness/security benefit, but you shouldn't > > change it on every bogus RRQ or un-authenticated > > solicitation. You should of course change it whenever that > > challenge becomes "previously used." > > > > Perhaps you are saying here that the damage isn't so bad: at > > most an attacker can prevent a re-registration, and > > eventually the visitor list entry will timeout, causing the > > FA to forget all "previously used" challenges for the MN. > > Then the MN can re-register with any challenge from the > > global Challenge-Window and re-enable service. However, there > > could still be a fairly large gap between the timeout of the > > visitor list entry and the successful re-registration, > > especially because the MN will experience a long series of > > STALE_CHALLENGE responses, and it may have backed off on its > > registration attempts in the meantime. > > > > Mostly true. BUT I meant two things: > 1. MN has a plenty of time to pick one of the latest advertised > challenges(multicast) for re-registration. > 2. If MN is not listening to these challenges, MN would solicit and > receive the latest challenge from the Window-challenge (multicast > Advertised) and use it for re-registration. Item 1. does not hold if the MN is newly arrived at the link, which I hold is the predominant reason to solicit for an agent advertisement in the first place. For item 2, we currently have no text stating that solicited agent advertisements MUST be multicast nor do we have text stating that they MUST be unicast. It seems you are proposing a solution where we state that they must be multicast? In that case, we need text to this effect, and we also need text to clearly express that the solicited multicast agent advertisement should re-send the latest challenge from the Challenge Window. (However, I'm still not clear on your reason for wanting to exclude unicast solicited agent advertisements.) Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 7 20:24:52 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 UAA09674 for ; Thu, 7 Aug 2003 20:24:52 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3S-0003rA-NS for mip4-archive@odin.ietf.org; Thu, 07 Aug 2003 20:24:27 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h780OQsV014818 for mip4-archive@odin.ietf.org; Thu, 7 Aug 2003 20:24:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv3S-0003qv-HQ for mip4-web-archive@optimus.ietf.org; Thu, 07 Aug 2003 20:24:26 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09539 for ; Thu, 7 Aug 2003 20:24:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kv3Q-0003vl-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 20:24:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19kv3G-0003uO-00 for mip4-web-archive@ietf.org; Thu, 07 Aug 2003 20:24:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kv36-0003h0-TO; Thu, 07 Aug 2003 20:24:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19kuZ2-0002mk-DO for mip4@optimus.ietf.org; Thu, 07 Aug 2003 19:53:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08818 for ; Thu, 7 Aug 2003 19:52:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19kuZ0-0003lA-00 for mip4@ietf.org; Thu, 07 Aug 2003 19:52:58 -0400 Received: from sj-core-4.cisco.com ([171.68.223.138]) by ietf-mx with esmtp (Exim 4.12) id 19kuYz-0003l1-00 for mip4@ietf.org; Thu, 07 Aug 2003 19:52:57 -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 h77NqPpp019130; Thu, 7 Aug 2003 16:52:25 -0700 (PDT) Received: from cisco.com (sjc-vpn2-361.cisco.com [10.21.113.105]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKD02071; Thu, 7 Aug 2003 16:46:12 -0700 (PDT) Message-ID: <3F32E638.8050702@cisco.com> Date: Thu, 07 Aug 2003 16:52:24 -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: mip4@ietf.org CC: Henrik Levkowetz , kleung@cisco.com, mccap@lucent.com Subject: [Mip4] draft-patel-mobileip-experimental-messages-01.txt References: <3F1EDC7C.4060402@cisco.com> <20030723230223.50544972.henrik@levkowetz.com> <3F1EF94D.9000801@cisco.com> <20030723232003.0f35b407.henrik@levkowetz.com> <3F1EFE31.5010801@cisco.com> <20030723235517.6a148de8.henrik@levkowetz.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hello: A new version of the draft Experimental Message Types for Mobile IPv4 is available for your reference at : ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experimental-messages-01.txt This version includes support for experimental extensions as suggested by Henrik. Please send your comments. Alpesh _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Aug 8 11:02: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 LAA14360 for ; Fri, 8 Aug 2003 11: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 19l8kl-0000VE-RX for mip4-archive@odin.ietf.org; Fri, 08 Aug 2003 11:02:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78F237O001928 for mip4-archive@odin.ietf.org; Fri, 8 Aug 2003 11:02:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8kl-0000V1-KY for mip4-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 11:02:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14326 for ; Fri, 8 Aug 2003 11:01:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8kj-0001M8-00 for mip4-web-archive@ietf.org; Fri, 08 Aug 2003 11:02:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19l8ki-0001M5-00 for mip4-web-archive@ietf.org; Fri, 08 Aug 2003 11:02:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19l8kj-0000Up-N5; Fri, 08 Aug 2003 11: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 19l8kg-0000Ub-BZ for mip4@optimus.ietf.org; Fri, 08 Aug 2003 11:01:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14318 for ; Fri, 8 Aug 2003 11:01:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19l8kd-0001Lw-00 for mip4@ietf.org; Fri, 08 Aug 2003 11:01:55 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19l8kc-0001Lt-00 for mip4@ietf.org; Fri, 08 Aug 2003 11:01:54 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h78F0fd21161; Fri, 8 Aug 2003 10:00:41 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <3014AGPV>; Fri, 8 Aug 2003 10:00:42 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Henrik Levkowetz'" Cc: "'Pete McCann'" , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , "'Luca Salgarelli'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Fri, 8 Aug 2003 10:00:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C35DBD.78521716" 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_01C35DBD.78521716 Content-Type: text/plain Hi Henrik, It seems that I misread the latest proposed text by Pete (somehow I read "or" as "and"). I am for this change as proposed by Pete to Appendix E: " In the program fragment, it is presumed that the foreign agent keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the last advertised challenge used by a mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply or a unicast Agent Advertisement. " Regards, Ahmad > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Thursday, August 07, 2003 5:21 PM > To: Muhanna, Ahmad [RICH2:2Q30:EXCH] > Cc: 'Pete McCann'; mip4@ietf.org; Bharatia, Jayshree > [RICH1:2H13:EXCH]; 'charliep@iprg.nokia.com'; 'Luca Salgarelli' > Subject: Re: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis > challenges in s olicited ag ent advertisements > > > Thursday 7 August 2003, Ahmad wrote in response to Pete McCann: > > [...] > > > > Ahmad Muhanna writes: > > > > > Ahmad Muhanna writes: > > > > > > > > > > No, I do not agree. I do not think the existing > > > > > specification provides for recovery, and I think that the > > > > > mechanism I suggested completely defeats the attack, or at > > > > > least, restores the attacker to exactly the power he had > > > > > before with simple channel-flooding. This is because new > > > > > solicitations or (invalid) registration requests do not > > > > > immediately push a valid challenge out of the > currently valid > > > > > set of challenges. This gives the MN time to receive the > > > > > challenge, compute an authenticator, and send it to the FA > > > > > even though many, many solicitations or (invalid) > > > > > registration requests may have been processed in the > meantime. > > > > > Is that clear? > > > > > > > > > > > > > After thinking this over and checking an old thread on similar > > > > issue with Charlie and Luca, And checking Appendix E, > I believe > > > > that the Challenge_Window meant to be for the periodically sent > > > > Challenges in Agent Advertisement messages that are > multicast. I > > > > do not think that the Challenge-Window is related to the > > > > unicasted AA messages.(unicasted AA is ONLY communicated to One > > > > single MN) > > So far, we're in agreement. > > > > > > > I technically agree with you here, but I think there is > > > another per-MN data structure you have forgotten about > (see below). > > > > > > > Having this in mind and the FA periodically (time > based) issuing > > > > these > multicast Agent Advertisement > > > > Messages, I believe that FA is supposed to continue > > > > sending the latest challenge from the Challenge-Window > > > > in a unicast AA message until the next time a new > > > > advertised challenge is generated. I do not think that > > > > it is possible to issue a new challenge via unicast AA > > > > message and consider that as part of the Challenge-Window; > > > > since that Challenge is not available for all Mobile > > > > Nodes. I believe this address the original concern of this > > > > thread. What do you think? > > > > > > But if that Challenge was "previously used" by the MN, it > > > seems proper to generate a new challenge, no? And even > > > > I absolutely agree with you here. BUT let us be frank. > > This has to be taken in light of the whole mechanism offered By > > RFC3012bis. When this was discussed about (April 2002) in another > > thread, we were very much concerned to have the challenge mechanism > > work with an optimized solution for scalability and storage > > requirement. Achieving the most optimized storage requirement as > > mentioned in Appendix E was done with some assumptions in mid. > > That's fine. Now, as far as I can see, the proposed changes > maintain the data structures proposed in Appendix E, not > adding additional storage requirements, so we don't have a > problem in this respect. > > > [...] > > > > though that challenge is not in the global "Challenge-Window" > > > list it should be remembered in a data structure related to > > > that particular mobile node, and should be considered as a > > > valid challenge for that MN. This is reflected in the very > > > last clause of this paragraph from Appendix E: > > > > > > In the program fragment, it is presumed that the foreign agent > > > keeps an array of advertised Challenges > ("VALID_ADV_CHALLENGES"), > > > a record of the last advertised challenge used by a > mobile node, > > > and also a record of the last challenge provided to a > mobile node > > > in a Registration Reply. > > > > > > So, I think this should be modified to say "also a record of > > > the last challenge provided to a mobile node in a > > > Registration Reply or unicast Agent Advertisement." > > Yes, that makes sense. > > > > > > In regard to the bogus Registration Request, If the MN > > > > receives the successful Reply and an attacker sends A > > > > bogus RRQ; YES this will invalidates the Challenge sent in > > > > the successful RRP BUT the MN is already > > > > registered and will not need to re-register until some > > > > good time in the future. > > > > > > It's important to remember that the above data structure is > > > kept only for nodes that have a prior, valid registration. > > > This is to prevent state-exhaustion attacks on the FA. So, I > > > agree with you that it is proper to repeat the last value > > > from the Challenge-Window record of multicast advertisements > > > if you are dealing with an MN of which you have no record. > > > Otherwise, you should repeat the last challenge from your > > > per-MN data structure. It is ok to change this challenge > > > after a longish-period of time (say 1 minute) and that might > > > provide some robustness/security benefit, but you shouldn't > > > change it on every bogus RRQ or un-authenticated > > > solicitation. You should of course change it whenever that > > > challenge becomes "previously used." > > > > > > Perhaps you are saying here that the damage isn't so bad: at > > > most an attacker can prevent a re-registration, and > > > eventually the visitor list entry will timeout, causing the > > > FA to forget all "previously used" challenges for the MN. > > > Then the MN can re-register with any challenge from the > > > global Challenge-Window and re-enable service. However, there > > > could still be a fairly large gap between the timeout of the > > > visitor list entry and the successful re-registration, > > > especially because the MN will experience a long series of > > > STALE_CHALLENGE responses, and it may have backed off on its > > > registration attempts in the meantime. > > > > > > > Mostly true. BUT I meant two things: > > 1. MN has a plenty of time to pick one of the latest advertised > > challenges(multicast) for re-registration. > > 2. If MN is not listening to these challenges, MN would solicit and > > receive the latest challenge from the Window-challenge (multicast > > Advertised) and use it for re-registration. > > Item 1. does not hold if the MN is newly arrived at the link, > which I hold is the predominant reason to solicit for an > agent advertisement in the first place. > > For item 2, we currently have no text stating that solicited > agent advertisements MUST be multicast nor do we have text > stating that they MUST be unicast. It seems you are proposing > a solution where we state that they must be multicast? In > that case, we need text to this effect, and we also need text > to clearly express that the solicited multicast agent > advertisement should re-send the latest challenge from the > Challenge Window. > > (However, I'm still not clear on your reason for wanting to > exclude unicast solicited agent advertisements.) > > Henrik > > ------_=_NextPart_001_01C35DBD.78521716 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in = s olicited ag ent advertisements

Hi Henrik,

It seems that I misread the latest proposed text by = Pete (somehow I read "or" as "and"). I am for this = change as proposed by Pete to Appendix E:

"
   In the program fragment, it is presumed = that the foreign agent
   keeps an array of advertised Challenges = ("VALID_ADV_CHALLENGES"), a
   record of the last advertised challenge = used by a mobile node, and
   also a record of the last challenge = provided to a mobile node in a
   Registration Reply or a unicast Agent = Advertisement.
"

Regards,
Ahmad


> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] =
> Sent: Thursday, August 07, 2003 5:21 PM
> To: Muhanna, Ahmad [RICH2:2Q30:EXCH]
> Cc: 'Pete McCann'; mip4@ietf.org; Bharatia, = Jayshree
> [RICH1:2H13:EXCH]; 'charliep@iprg.nokia.com'; = 'Luca Salgarelli'
> Subject: Re: [Mip4] Re: [mobile-ip] Re: New = issue: 3012bis
> challenges in s olicited ag ent = advertisements
>
>
> Thursday  7 August 2003, Ahmad wrote in = response to Pete McCann:
>
> [...]
>
> > > Ahmad Muhanna writes:
> > >  > > Ahmad Muhanna = writes:
> > >  > >
> > >  > > No, I do not = agree.  I do not think the existing
> > >  > > specification = provides for recovery, and I think that the
> > >  > > mechanism I suggested = completely defeats the attack, or at
> > >  > > least, restores the = attacker to exactly the power he had
> > >  > > before with simple = channel-flooding.  This is because new
> > >  > > solicitations or = (invalid) registration requests do not
> > >  > > immediately push a = valid challenge out of the
> currently valid
> > >  > > set of = challenges.  This gives the MN time to receive the
> > >  > > challenge, compute an = authenticator, and send it to the FA
> > >  > > even though many, = many solicitations or (invalid)
> > >  > > registration requests = may have been processed in the
> meantime.
> > >  > > Is that clear?
> > >  > >
> > >  >
> > >  > After thinking this over = and checking an old thread on similar
> > >  > issue with  Charlie = and Luca, And checking Appendix E,
> I believe
> > >  > that the Challenge_Window = meant to be for the periodically sent
> > >  > Challenges in Agent = Advertisement messages that are
> multicast. I
> > >  > do not think that the = Challenge-Window is related to the
> > >  > unicasted AA = messages.(unicasted AA is ONLY communicated to One
> > >  > single MN)
>
> So far, we're in agreement.
>
> > >
> > > I technically agree with you here, = but I think there is
> > > another per-MN data structure you = have forgotten about
> (see below).
> > >
> > >  > Having this in mind and = the FA periodically (time
> based) issuing 
> > > > these  > multicast Agent = Advertisement
> > >  > Messages, I believe that = FA is supposed to continue
> > >  > sending the latest = challenge from the Challenge-Window
> > >  > in a unicast AA message = until the next time a new
> > >  > advertised challenge is = generated. I do not think that
> > >  > it is possible to issue a = new challenge via unicast AA
> > >  > message and consider that = as part of the Challenge-Window;
> > >  > since that Challenge is = not available for all Mobile
> > >  > Nodes. I believe this = address the original concern of this
> > >  > thread. What do you = think?
> > >
> > > But if that Challenge was = "previously used" by the MN, it
> > > seems proper to generate a new = challenge, no?  And even
> >
> > I absolutely agree with you here. BUT let = us be frank.
> > This has to be taken in light of the whole = mechanism offered By
> > RFC3012bis. When this was discussed about = (April 2002) in another
> > thread, we were very much concerned to = have the challenge mechanism
> > work with an optimized solution for = scalability and storage
> > requirement. Achieving the most optimized = storage requirement as
> > mentioned in Appendix E was done with some = assumptions in mid.
>
> That's fine. Now, as far as I can see, the = proposed changes
> maintain the data structures proposed in = Appendix E, not
> adding additional storage requirements, so we = don't have a
> problem in this respect.
>
>
> [...]
>
> > > though that challenge is not in the = global "Challenge-Window"
> > > list it should be remembered in a = data structure related to
> > > that particular mobile node, and = should be considered as a
> > > valid challenge for that MN.  = This is reflected in the very
> > > last clause of this paragraph from = Appendix E:
> > >
> > >    In the program = fragment, it is presumed that the foreign agent
> > >    keeps an array of = advertised Challenges
> ("VALID_ADV_CHALLENGES"),
> > >    a record of the = last advertised challenge used by a
> mobile node,
> > >    and also a record = of the last challenge provided to a
> mobile node
> > >    in a Registration = Reply.
> > >
> > > So, I think this should be modified = to say "also a record of
> > > the last challenge provided to a = mobile node in a
> > > Registration Reply or unicast Agent = Advertisement."
>
> Yes, that makes sense.
>
>
> > >  > In regard to the bogus = Registration Request, If the MN
> > >  > receives the successful = Reply and an attacker sends A
> > >  > bogus RRQ; YES this will = invalidates the Challenge sent in
> > >  > the successful RRP BUT the = MN is already
> > >  > registered and will not = need to re-register until some
> > >  > good time in the = future.
> > >
> > > It's important to remember that the = above data structure is
> > > kept only for nodes that have a = prior, valid registration. 
> > > This is to prevent state-exhaustion = attacks on the FA.  So, I
> > > agree with you that it is proper to = repeat the last value
> > > from the Challenge-Window record of = multicast advertisements
> > > if you are dealing with an MN of = which you have no record. 
> > > Otherwise, you should repeat the last = challenge from your
> > > per-MN data structure.  It is ok = to change this challenge
> > > after a longish-period of time (say 1 = minute) and that might
> > > provide some robustness/security = benefit, but you shouldn't
> > > change it on every bogus RRQ or = un-authenticated
> > > solicitation.  You should of = course change it whenever that
> > > challenge becomes "previously = used."
> > >
> > > Perhaps you are saying here that the = damage isn't so bad: at
> > > most an attacker can prevent a = re-registration, and
> > > eventually the visitor list entry = will timeout, causing the
> > > FA to forget all "previously = used" challenges for the MN. 
> > > Then the MN can re-register with any = challenge from the
> > > global Challenge-Window and re-enable = service. However, there
> > > could still be a fairly large gap = between the timeout of the
> > > visitor list entry and the successful = re-registration,
> > > especially because the MN will = experience a long series of
> > > STALE_CHALLENGE responses, and it may = have backed off on its
> > > registration attempts in the = meantime.
> > >
> >
> > Mostly true. BUT I meant two = things:
> > 1. MN has a plenty of time to pick one of = the latest advertised
> > challenges(multicast) for = re-registration.
> > 2. If MN is not listening to these = challenges, MN would solicit and
> > receive the latest challenge from the = Window-challenge (multicast
> > Advertised) and use it for = re-registration.
>
> Item 1. does not hold if the MN is newly = arrived at the link,
> which I hold is the predominant reason to = solicit for an
> agent advertisement in the first place.
>
> For item 2, we currently have no text stating = that solicited
> agent advertisements MUST be multicast nor do = we have text
> stating that they MUST be unicast. It seems you = are proposing
> a solution where we state that they must be = multicast? In
> that case, we need text to this effect, and we = also need text
> to clearly express that the solicited multicast = agent
> advertisement should re-send the latest = challenge from the
> Challenge Window.
>
> (However, I'm still not clear on your reason = for wanting to
> exclude unicast solicited agent = advertisements.)
>
>       Henrik
>
>

------_=_NextPart_001_01C35DBD.78521716-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Aug 8 14:59: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 OAA21160 for ; Fri, 8 Aug 2003 14:59: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 19lCSc-0002HI-E9 for mip4-archive@odin.ietf.org; Fri, 08 Aug 2003 14:59:34 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h78IxYHO008750 for mip4-archive@odin.ietf.org; Fri, 8 Aug 2003 14:59:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCSc-0002H3-8R for mip4-web-archive@optimus.ietf.org; Fri, 08 Aug 2003 14:59:34 -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 OAA21155 for ; Fri, 8 Aug 2003 14:59: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 19lCS5-0002C9-1u; Fri, 08 Aug 2003 14:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19lCRr-0002Bw-Rw for mip4@optimus.ietf.org; Fri, 08 Aug 2003 14:58:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21140 for ; Fri, 8 Aug 2003 14:58:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19lCRk-0002w9-00 for mip4@ietf.org; Fri, 08 Aug 2003 14:58:40 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19lCRj-0002vq-00 for mip4@ietf.org; Fri, 08 Aug 2003 14:58:39 -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 h78IvRU19866; Fri, 8 Aug 2003 13:57:28 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h78IvOH29784; Fri, 8 Aug 2003 13:57:24 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJBDZJ-00021C-00; Fri, 08 Aug 2003 14:57:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16179.62093.840833.840071@gargle.gargle.HOWL> Date: Fri, 8 Aug 2003 13:57:17 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "'Henrik Levkowetz'" , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , "'Luca Salgarelli'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Ahmad, Ok, good... do you have a suggestion for how to handle the security considerations text? In light of our discussion, it seems like the FA should be repeating the challenge from its data structure for the MN, if it has a valid visitor list entry. Otherwise, it is ok to repeat the last value from the Challenge-Window. This "latest" challenge can be changed (either on a global or per-MN basis) on a relatively slow timescale, but should not be changed by un-authenticated RRQs or agent solicitations. Could you capture this with some wording you are happy with? -Pete Ahmad Muhanna writes: > Hi Henrik, > > It seems that I misread the latest proposed text by Pete (somehow I read > "or" as "and"). I am for this change as proposed by Pete to Appendix E: > > " > In the program fragment, it is presumed that the foreign agent > keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a > record of the last advertised challenge used by a mobile node, and > also a record of the last challenge provided to a mobile node in a > Registration Reply or a unicast Agent Advertisement. > " > > Regards, > Ahmad _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sun Aug 10 01:04: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 BAA16235 for ; Sun, 10 Aug 2003 01:04: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 19liN9-0004Xl-KP for mip4-archive@odin.ietf.org; Sun, 10 Aug 2003 01:04:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7A543DK017459 for mip4-archive@odin.ietf.org; Sun, 10 Aug 2003 01:04:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19liN9-0004XV-FW for mip4-web-archive@optimus.ietf.org; Sun, 10 Aug 2003 01:04:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16214 for ; Sun, 10 Aug 2003 01:04:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19liN6-00055x-00 for mip4-web-archive@ietf.org; Sun, 10 Aug 2003 01:04:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19liN5-00055r-00 for mip4-web-archive@ietf.org; Sun, 10 Aug 2003 01: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 19liN7-0004Wa-84; Sun, 10 Aug 2003 01:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19liMG-0004WD-CJ for mip4@optimus.ietf.org; Sun, 10 Aug 2003 01:03: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 BAA16175 for ; Sun, 10 Aug 2003 01:03:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19liMD-00055K-00 for mip4@ietf.org; Sun, 10 Aug 2003 01:03:05 -0400 Received: from i20101-d122.viapvt.sk ([195.28.81.251] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19liMC-000550-00 for mip4@ietf.org; Sun, 10 Aug 2003 01:03:04 -0400 Received: (qmail 5657 invoked from network); 10 Aug 2003 05:03:00 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 10 Aug 2003 05:03:00 -0000 Date: Sun, 10 Aug 2003 07:02:59 +0200 From: Henrik Levkowetz To: mip4@ietf.org Cc: Pete McCann Message-Id: <20030810070259.756b7d5b.henrik@levkowetz.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 Subject: [Mip4] draft-kulkarni-mobileip-dynamic-assignment as Workgroup Item? Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit One of the charter items of the mip4 working group is dynamic HA assignment. The document draft-kulkarni-mobileip-dynamic-assignment-01.txt proposes a mechanism for doing this at registration time. We would now like to confirm with the working group that this document should be made the basis of registration time HA assignment, and moved forward as a workgroup item. Any objections? The chairs _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 11 03:14: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 DAA08792 for ; Mon, 11 Aug 2003 03:14: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 19m6sV-0007cj-7x for mip4-archive@odin.ietf.org; Mon, 11 Aug 2003 03:14:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B7E3kp029306 for mip4-archive@odin.ietf.org; Mon, 11 Aug 2003 03:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6sU-0007cb-NK for mip4-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 03:14: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 DAA08789 for ; Mon, 11 Aug 2003 03:13:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m6sS-0003bM-00 for mip4-web-archive@ietf.org; Mon, 11 Aug 2003 03:14:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m6sS-0003bI-00 for mip4-web-archive@ietf.org; Mon, 11 Aug 2003 03:14:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6sS-0007cP-Qo; Mon, 11 Aug 2003 03:14:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6rX-0007b2-EH for mip4@optimus.ietf.org; Mon, 11 Aug 2003 03:13: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 DAA08761 for ; Mon, 11 Aug 2003 03:12:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m6rV-0003b1-00 for mip4@ietf.org; Mon, 11 Aug 2003 03:13:01 -0400 Received: from populo.vip.fi ([213.173.130.25] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19m6rU-0003ax-00 for mip4@ietf.org; Mon, 11 Aug 2003 03:13:00 -0400 Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by populo.vip.fi (8.8.8p1/8.8.5) with ESMTP id KAA02775; Mon, 11 Aug 2003 10:12:53 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 11 Aug 2003 10:12:53 +0300 Message-ID: Thread-Topic: [mobile-ip] comments on draft-ietf-mobileip-vpn-problem-solution-02 Thread-Index: AcNfYFHXM79d6RnuSz6TNoo/mBZ2rgAaYHHQ From: "Sami Vaarala" To: "Tom Hiller" , Cc: Content-Transfer-Encoding: quoted-printable Subject: [Mip4] RE: [mobile-ip] comments on draft-ietf-mobileip-vpn-problem-solution-02 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 Tom, Some quick comments below. I'll post a -03b version soon with some edits that outline how alternative 6 might look in the specification; have a look and comment. Best regards, -Sami > > For instance, do you mean that we detect entry into the internal network > > using RRQ/RRP but don't monitor the i-HA and detect exit using link > > layer triggers? (And rule out other causes for problems, such as > > administrator mistakes in configuring switches?) >=20 > As an example, link level security could be set up via key distribution > such as with EAP, that is, when all the details are finalized. Right. For the particular case of 802.1x/11i we can do better, but we still need to solve the generic case? > Your draft has a rule that says the VPN firewall needs to block outside > traffic to the HA-i, so security needs to be configured correctly no > matter what. The first requirement is to make the solution sane, while the second is limiting damage when the requirements are not met (which will eventually happen). > > In laptop use, for instance, higher frequency of re-registration is > > desirable because problems (such as routing issues, HA reboot etc) can > > be detected early enough (otherwise you have a black hole). Furthermore, > > with NATs one has to re-register roughly once a minute or less anyway > > (when outside). But that's laptops. >=20 > I thought from reading the draft that the pinging only was necessary when > running inside the VPN; do I understand correctly this happens all the > time? Then I can say for cdma2000 this is bad news. I discuss the battery > impact below. Frequent re-registration would be necessary only when in the internal network, yes. Of course ordinary Mobile IPv4 re-registration would still be required even when in the external network (which could be every hour or whatever is configured). And if there is a NAT outside, then tunneled ICMP Echo (see RFC 3519) is required. (If IPsec is the lowest layer protocol, one needs IPsec NAT keepalives; there is no way out of this NAT keepalive problem.) > [...] > In my initial comment I was thinking about hand held devices with > batteries. Some enterprises could be like that -- delivery services=20 > could have mobiles that are sometimes inside and sometimes outside > their buildings, for example. Or employees with hand held wireless > devices that change radio usage when the user walks in the building. > I assumed we'd like a solution that works a wide range of wireless > devices. Yes, I agree, supporting a wide range of wireless devices is desirable. > > This is equivalent to what we (Netseal) and several other MIP/IPsec > > vendors deploy today. Either the combined security/mobility device > > is in the DMZ (which has routing impact) or the device is inside (and > > we have a pinhole). The latter has been clearly unacceptable to some > > customers, which is why there is interest in avoiding both problems. > > (The concern is that you will have a large security perimeter because > > you need pinholes for every i-HA there is; this may be a large number > > in a large enterprise.) >=20 > Can you provide some examples of what is a large number of > home agents with associated numbers of users? One reasonable setup is where you have one home agent per site. For large enterprises this could be dozens. If one wants optimal routing, there would have to be one home agent per subnet. The perceived problem is not management as such, but that instead of one (or a few) security critical devices, there is one in every site or subnet. > > What you suggest also requires changes in the IPsec layer, namely > > to allow IPsec SA endpoint update, which is not part of the > > specifications. Which means that the solution is either proprietary > > (these proprietary products are already out there) or needs more > > IPsec specification work. >=20 > Some specification work will be necessary; the question is what is the > best long term approach. I have been concerned your solution rules out > hand held mobile devices; reading forward I need to think about your > alternatives and gather more information. Thinking out of the box, IMO the best long term approach would be to design a standardized hybrid of IPsec and Mobile IPv4, dropping a number of IPsec features on the way for simplicity. This is essentially the combined HA/VPN approach, but maintaining separate security and mobility layers is not useful since the layers need to interoperate anyway. This would simplify implementation, and would be especially applicable to small devices. However, one constraint is that we need something that can be deployed now (or very soon), which is why not changing IPsec becomes important. =20 > > This is a good solution (already deployed :) but it is not a > > solution to the problem statement document, which assumes that > > the security perimeter should not be distributed (see e.g. > > sections 2.5, 4, 5.1), as is the case with the "pinhole" > > approach. It seems that we disagree on the requirements > > document? >=20 > I think we have to be pragmatic to some extent. If the requirements > produce a solution that requires devices that are more or less assumed > to be plugged into a power source then we have to review the requirements > and examine the various tradeoffs with other solutions. And we have to > review the requirement for pinging out the the VPN when there is NAT. I agree to some extent, especially that we need to be pragmatic. I'm quite confident that we can work out the re-registration issue to suit battery powered devices better. > > Some alternatives to go forward: > > 2) We emphasize that the solution is for current enterprise users > > (typically laptops), and that it is not necessarily applicable to > > small battery-powered devices (i.e. keep current solution). >=20 > At a minimum, we would need to address pinging outside the VPN as this > has spectral implication apart from battery ones. Right. That's only necessary when there is a NAT outside, and one wants to maintain the tunnel. I don't think there's much we can do here, except change NATs :-) Other pinging or overhead traffic should not be necessary (apart from re-registration with a desired interval, such as every hour). > > 3) We rely on RRQ/RRP to detect entry, and use L2 triggers to detect > > exit; if in doubt, the administrator could say that IPsec shall always > > be used (although this defeats the point to some extent, because traffic > > goes through DMZ). >=20 > Question: I was thinking the home agents could also support IPSec, i.e., > combined mobility/security entities. Therefore, when mobiles are inside > the VPN traffic, wouldn't the traffic stay inside the VPN? We worked out quite a few scenarios with this approach, and they all end up either changing the security perimeter or changing standards in a non-trivial way. If I understand correctly, you propose to combine IPsec/MIPv4 into the i-HA (I'm assuming there is still a traditional VPN in the DMZ, as we're otherwise discussing the pinhole solution). In this case one would still detect the internal network to avoid overhead and routing traffic through the DMZ. The problems here are double IPsec when MN is outside and changes in standards that are more than deployment tweaking. > > 6) Relax the re-registration requirement as follows: - The MN does not > > need to re-register periodically, if there is no traffic. > > [...] > > We need more input from mobile vendors on the complexity issue of this > alternative. One initial thought: it's probably necessary to buffer data > because discarding data would appear like buggy network service to users. Yes; on the other hand large buffers are problematic on small devices. Buffering of a few packets seems acceptable to me, though, particularly because a device would probably have to do that anyway for a proper ARP implementation. > Thanks for your many comments and ideas. I respond today in order > to avoid looking like I dropped off this exchange. I need a bit > more time to think, and to read your thoughts on my comments above. Thank you, it's been enlightening. Best regards, -Sami _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 11 03:16: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 DAA08853 for ; Mon, 11 Aug 2003 03:16: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 19m6uP-0007hu-Te for mip4-archive@odin.ietf.org; Mon, 11 Aug 2003 03:16:01 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7B7G1Sp029620 for mip4-archive@odin.ietf.org; Mon, 11 Aug 2003 03:16:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6uP-0007hf-M7 for mip4-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 03:16: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 DAA08839 for ; Mon, 11 Aug 2003 03:15:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m6uN-0003bs-00 for mip4-web-archive@ietf.org; Mon, 11 Aug 2003 03:15:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19m6uM-0003bp-00 for mip4-web-archive@ietf.org; Mon, 11 Aug 2003 03:15:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6uO-0007gL-Hr; Mon, 11 Aug 2003 03:16:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19m6tX-0007fD-VZ for mip4@optimus.ietf.org; Mon, 11 Aug 2003 03:15: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 DAA08816 for ; Mon, 11 Aug 2003 03:15:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19m6tV-0003bc-00 for mip4@ietf.org; Mon, 11 Aug 2003 03:15:05 -0400 Received: from populo.vip.fi ([213.173.130.25] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19m6tV-0003bZ-00 for mip4@ietf.org; Mon, 11 Aug 2003 03:15:05 -0400 Received: from server.netseal.com (kone1.intrasec2.vip.fi [213.173.159.46]) by populo.vip.fi (8.8.8p1/8.8.5) with ESMTP id KAA03045; Mon, 11 Aug 2003 10:15:05 +0300 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Mon, 11 Aug 2003 10:15:04 +0300 Message-ID: Thread-Topic: vpn solution draft -03b Thread-Index: AcNf1ytJQgZwOdf5TXq8qDx9R6DpFQ== From: "Sami Vaarala" To: Cc: Content-Transfer-Encoding: quoted-printable Subject: [Mip4] vpn solution draft -03b Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Hi, I've incorporated some more edits based on IETF 57 and Tom Hiller's comments into -03b. The draft, and diffs to -02 are available at: http://www.hut.fi/~svaarala/mipvpn Best regards, -Sami -- Sami Vaarala Senior System Architect Netseal (http://www.netseal.com/) _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 11 08:57: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 IAA14629 for ; Mon, 11 Aug 2003 08:57: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 19mCES-0001jc-Rs for mip4-archive@odin.ietf.org; Mon, 11 Aug 2003 08:57:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7BCv44H006664 for mip4-archive@odin.ietf.org; Mon, 11 Aug 2003 08:57:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCES-0001jP-KZ for mip4-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 08:57:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14621 for ; Mon, 11 Aug 2003 08:56:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCER-0005bG-00 for mip4-web-archive@ietf.org; Mon, 11 Aug 2003 08:57:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mCEQ-0005bD-00 for mip4-web-archive@ietf.org; Mon, 11 Aug 2003 08:57:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mCEP-0001jD-Pk; Mon, 11 Aug 2003 08: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 19mCDm-0001iV-Vk for mip4@optimus.ietf.org; Mon, 11 Aug 2003 08:56: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 IAA14599 for ; Mon, 11 Aug 2003 08:56:17 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mCDl-0005ad-00 for mip4@ietf.org; Mon, 11 Aug 2003 08:56:21 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19mCDk-0005aK-00 for mip4@ietf.org; Mon, 11 Aug 2003 08:56:20 -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 h7BCswg21260; Mon, 11 Aug 2003 07:54:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id <3014AT0S>; Mon, 11 Aug 2003 07:54:58 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "'Henrik Levkowetz'" , mip4@ietf.org, "Jayshree Bharatia" , "'charliep@iprg.nokia.com'" , "'Luca Salgarelli'" Subject: RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in s olicited ag ent advertisements Date: Mon, 11 Aug 2003 07:54:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36007.C4779638" 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_01C36007.C4779638 Content-Type: text/plain > > Hi, Ahmad, > > Ok, good... do you have a suggestion for how to handle the > security considerations text? > > In light of our discussion, it seems like the FA should be > repeating the challenge from its data structure for the MN, > if it has a valid visitor list entry. Otherwise, it is ok to > repeat the last value from the Challenge-Window. This > "latest" challenge can be changed (either on a global or > per-MN basis) on a relatively slow timescale, but should not > be changed by un-authenticated RRQs or agent solicitations. > Could you capture this with some wording you are happy with? > Hi Pete, Mr. Co-Chair, Beside what general requirement any box needs to have for defeating a DOS attack, I do not think we need any special handling with respect to the MN-FA Challenge. Regards, Ahmad > -Pete > ------_=_NextPart_001_01C36007.C4779638 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] Re: [mobile-ip] Re: New issue: 3012bis challenges in = s olicited ag ent advertisements

 
>
> Hi, Ahmad,
>
> Ok, good... do you have a suggestion for how to = handle the
> security considerations text?
>
> In light of our discussion, it seems like the = FA should be
> repeating the challenge from its data structure = for the MN,
> if it has a valid visitor list entry.  = Otherwise, it is ok to
> repeat the last value from the = Challenge-Window.  This
> "latest" challenge can be changed = (either on a global or
> per-MN basis) on a relatively slow timescale, = but should not
> be changed by un-authenticated RRQs or agent = solicitations. 
> Could you capture this with some wording you = are happy with?
>
 
Hi Pete, Mr. Co-Chair,

Beside what general requirement any box needs to have = for defeating a DOS attack, I do not think we need any special handling = with respect to the MN-FA Challenge.

Regards,
Ahmad

> -Pete
>

------_=_NextPart_001_01C36007.C4779638-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 11 21:42: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 VAA13328 for ; Mon, 11 Aug 2003 21:42: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 19mOAk-0004bi-Tt for mip4-archive@odin.ietf.org; Mon, 11 Aug 2003 21:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7C1g2Ik017706 for mip4-archive@odin.ietf.org; Mon, 11 Aug 2003 21:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOAk-0004bR-Oh for mip4-web-archive@optimus.ietf.org; Mon, 11 Aug 2003 21:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13290 for ; Mon, 11 Aug 2003 21:41:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mOAh-0003hm-00 for mip4-web-archive@ietf.org; Mon, 11 Aug 2003 21:41:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mOAh-0003hj-00 for mip4-web-archive@ietf.org; Mon, 11 Aug 2003 21:41:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mOAj-0004b5-9S; Mon, 11 Aug 2003 21:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mO9x-0004aZ-T4 for mip4@optimus.ietf.org; Mon, 11 Aug 2003 21:41:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13252 for ; Mon, 11 Aug 2003 21:41:07 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mO9v-0003hN-00 for mip4@ietf.org; Mon, 11 Aug 2003 21:41:11 -0400 Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx with esmtp (Exim 4.12) id 19mO9u-0003hE-00 for mip4@ietf.org; Mon, 11 Aug 2003 21:41:10 -0400 Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10]) by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h7C1eWRZ263718; Mon, 11 Aug 2003 21:40:32 -0400 Received: from cichlid.adsl.duke.edu (sig-9-65-210-186.mts.ibm.com [9.65.210.186]) by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h7C1eVm6382372; Mon, 11 Aug 2003 19:40:31 -0600 Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h7C1d5303908; Mon, 11 Aug 2003 21:39:05 -0400 Message-Id: <200308120139.h7C1d5303908@cichlid.adsl.duke.edu> To: Henrik Levkowetz cc: Kent Leung , Alpesh , mip4@ietf.org Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt In-Reply-To: Message from henrik@levkowetz.com of "Fri, 25 Jul 2003 09:34:37 +0200." <20030725093437.3c38502d.henrik@levkowetz.com> Date: Mon, 11 Aug 2003 21:39:05 -0400 From: Thomas Narten 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: , Playing catchup... There is no need to give a format for experimental options. The whole point is that the format depends on what one is testing. Also, the purpose of experimental messages (at least as I understand them and as is described in draft-narten-iana-experimental-allocations-03.txt) is that they are for experimentation, _not_ deployment, and not for achieving interoperability with other implementations. They are designed so that one can safely use them in a controlled setting (e.g., lab or testbed) without conflicting with other registered usages. They are _not_ designed for vendors to use to define new message types that they can safely deploy without fear of conflicting with some other use. Indeed, this is exactly the kind of thing we want to avoid -- multiple different vendor-specific message types in use in practice. If something really is useful, as soon as it becomes clear it is useful, it should be documented and made an RFC proper, and relatively quickly. Experimental allocations are for dealing with the period before something becomes documented in an RFC or otherwise recognized as being generally useful. Thomas _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 13 04:36: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 EAA12566 for ; Wed, 13 Aug 2003 04:36: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 19mr6w-0005ST-NY for mip4-archive@odin.ietf.org; Wed, 13 Aug 2003 04:36:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7D8a2f8020981 for mip4-archive@odin.ietf.org; Wed, 13 Aug 2003 04:36:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mr6w-0005SK-IR for mip4-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 04:36: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 EAA12550 for ; Wed, 13 Aug 2003 04:35:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mr6t-0007el-00 for mip4-web-archive@ietf.org; Wed, 13 Aug 2003 04:35:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19mr6t-0007eh-00 for mip4-web-archive@ietf.org; Wed, 13 Aug 2003 04:35:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mr6v-0005S0-5j; Wed, 13 Aug 2003 04:36:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19mr6l-0005RZ-16 for mip4@optimus.ietf.org; Wed, 13 Aug 2003 04:35: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 EAA12542 for ; Wed, 13 Aug 2003 04:35:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19mr6i-0007eY-00 for mip4@ietf.org; Wed, 13 Aug 2003 04:35:48 -0400 Received: from i20101-d122.viapvt.sk ([195.28.81.251] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19mr6f-0007eS-00 for mip4@ietf.org; Wed, 13 Aug 2003 04:35:45 -0400 Received: (qmail 8616 invoked from network); 13 Aug 2003 08:35:09 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 13 Aug 2003 08:35:09 -0000 Date: Wed, 13 Aug 2003 10:35:06 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20030813103506.3f0c4305.henrik@levkowetz.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 Subject: [Mip4] Current state of 3012bis solicited agent advertisement issue. Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit This is a summary of the status of the issue of how to handle solicited agent advertisements with challenges according to 3012bis. There has been few participants so far in these discussions. In order to gauge consensus, please respond to the individual proposed text poits below if you have a position, and indicate whether you support or oppose the text as proposed. This includes those who have already participated in the discussions, too, as it has not always been easy to determine exactly where there is and is not consensus when going over the notes: --- Background: The current RFC3012 text says that an FA MAY include a new challenge in any registration reply, successful or not. At least one current implementation accordingly does not return a challenge with the registration reply when the registration attempt for some reason is unsuccessful (could be a timestamp mismatch with the HA, or some other rectifiable issue with the first registration request). At least one other current implementation expect an unsuccessful registration reply to provide a new challenge (as the challenge used in the previous registration request cannot be used again, and may have been taken from the most recent unsolicited agent advertisement). In this situation, these two implementations, which both follow the current RFC 3012, deadlock and never can reach a successful registration. The implementation which does not supply a new challenge with an unsuccessful registration reply expects an advertisement solicitation, and will provide a fresh challenge in this case, but whether a fresh challenge or a repeat of the most recent unsolicited multicast challenge should be provided in a solicited advertisement is also not specified in the current document text. The discussions around this subject also brought to light a number of denial of service attacks which would be possible with certain ways of resolving the issues above. --- Here are proposed text changes for 3012bis, to ensure this deadlock does not occur, and to prevent more grave denial of service attacks than could occur in a non-3012bis situation. The text has been taken from explicit text proposals and from the discussion notes when no explicit text has been provided earlier. Proposed text: - Add at the end of section 2 (as Section 2.1) - or as section 3.6 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. However, a foreign agent which provides challenge handling according to this document is restricted to only respond with unicast agent advertisements in response to a router solicitation. The agent advertisement which is unicast back to the soliciting mobile node MUST be handled as follows: A new Challenge value MUST be re-generated periodically and remembered as the most recent challenge issued to the mobile node. It is RECOMMENDED that this period be on the order of 60 seconds. If the challenge most recently issued to the soliciting mobile node has not been previously used (as defined in Section 1.1), and the re-generation period has not elapsed, the most recent challenge unicast to the mobile node through a registration reply or a unicast agent advertisement SHOULD be repeated in the newly issued unicast agent advertisement. (For further discussion of this, see Section 12.) - 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. - In section 3.3, change From: The Foreign Agent SHOULD include a new Mobile-Foreign Challenge Extension in any Registration Reply, successful or not. If the foreign agent includes this extension in a successful Registration Reply, the extension SHOULD precede a Mobile-Foreign authentication extension. Suppose the ... To: A Foreign Agent which provides challenge handling according to this document MUST include a previously unused Mobile-Foreign Challenge Extension in any Registration Reply, successful or not. If the foreign agent includes this extension in a successful Registration Reply, the extension SHOULD precede a Mobile-Foreign authentication extension. If the challenge most recently issued to the soliciting mobile node has not been previously used (as defined in Section 1.1), and the re-generation period (as described in section 2.1) has not elapsed, the most recent challenge unicast to the mobile node through a registration reply or a unicast agent advertisement SHOULD be repeated in the registration reply. Suppose the ... - Add the following at the end of Section 12: Note that an active attacker may try to prevent successful registrations by sending a large number of Agent Solicitations or bogus Registration Requests, each of which could cause the FA to respond with a fresh challenge, invalidating the challenge that the MN is currently trying to use. To prevent such attacks, the FA SHOULD repeat the same challenge value in successive unicast responses to Agent Solicitations or in Registration Replies to Requests that did not contain valid MN-AAA or MN-FA authentication extensions for some limited period of time (on the order of 60 seconds). Note that each challenge returned to an MN MUST be previously unused by that MN. - In Appendix E, change the second paragraph From: In the program fragment, it is presumed that the foreign agent keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the last advertised challenge used by a mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply. To: In the program fragment, it is presumed that the foreign agent keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the last advertised challenge used by a mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply or unicast Agent Advertisement. --- As mentioned above, if you have a position on this issue, please respond to the list, indicating your acceptance or rejection of each individual text proposal. The chairs. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 13 12:04: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 MAA24377 for ; Wed, 13 Aug 2003 12:04: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 19my6Y-00061y-R4 for mip4-archive@odin.ietf.org; Wed, 13 Aug 2003 12:04:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7DG46xx023178 for mip4-archive@odin.ietf.org; Wed, 13 Aug 2003 12:04:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19my6Y-00061l-NA for mip4-web-archive@optimus.ietf.org; Wed, 13 Aug 2003 12:04: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 MAA24368 for ; Wed, 13 Aug 2003 12:04:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19my6X-0002nS-00 for mip4-web-archive@ietf.org; Wed, 13 Aug 2003 12:04:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19my6W-0002nP-00 for mip4-web-archive@ietf.org; Wed, 13 Aug 2003 12:04:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19my6T-00060s-60; Wed, 13 Aug 2003 12:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19my6D-00060b-HM for mip4@optimus.ietf.org; Wed, 13 Aug 2003 12:03: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 MAA24359 for ; Wed, 13 Aug 2003 12:03:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19my6C-0002n3-00 for mip4@ietf.org; Wed, 13 Aug 2003 12:03:44 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19my6B-0002md-00 for mip4@ietf.org; Wed, 13 Aug 2003 12:03: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 h7DG36a01626 for ; Wed, 13 Aug 2003 11:03:07 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 13 Aug 2003 11:03:06 -0500 Message-ID: From: "Ahmad Muhanna" To: "'mip4@ietf.org'" Cc: "Jayshree Bharatia" Date: Wed, 13 Aug 2003 11:03:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C361B4.618B651E" Subject: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS 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_01C361B4.618B651E Content-Type: text/plain Hello, During an interoperability testing activity the Root Cause of the following problem is caused by RFC3012bis not offering a clear retransmission mechanism between the MN and the FA. The scenario goes as follows: 1. MN successfully Registers with the FA and receives a RRP (ID1) with a new challenge (FAC1) 2. MN starts downloading a large file which takes a long time. 3. MN sends a RRQ (Re-Registration, ID2) with challenge (FAC1) and starts a timer of (x seconds) before retrying. 4. FA process the RRQ and forward to HA and relay to MN a successful RRP (ID2) with challenge (FAC2). 5. Since the MN is busy downloading a large file, MN does not receive RRP on time. 6. MN retry timer expires and retransmits RRQ (ID3)using Challenge(FAC1) and increase the retry timer to 2x seconds (RFC3344). 7. FA rejects RRQ and sends RRP (ID3) with "Stale Challenge" and Challenge value (FAC2) 8. For the same reason in step 5, MN retransmits RRQ (ID4) message with challenge (FAC1) and increase timer to (4x seconds). 9. FA rejects RRQ and sends RRP (ID4) with "Stale Challenge" and Challenge value (FAC2) 10. MN receives RRP (ID2) before retry timer expires but ignores it because it tracks ID4. 11. MN receives RRP (ID3) before retry timer expires but ignores it because it tracks ID4. 12. MN receives RRP (ID4) before retry timer expires and act upon it, "Stale Challenge" 13. MN uses challenge received in RRP(ID4) and sends RRQ(ID5). This RRQ is not a retransmit, retry timer = x seconds. 14. The scenario continues as in steps 4-13. 15. This continue in infinite loop denying the MN Re-Registration and eventually the MN loose its connection due to lifetime expiry. This causes a DOS and prevents MN from downloading a large file. The above scenario is basically caused by the fact that RFC3012bis introduced the MN-FA challenge for replay protection without offering a real retransmit mechanism between MN and FA to prevent such SERIOUS problem from happening. For this problem I would like to offer the following solution: 1.) OLD TEXT: 3.1. Mobile Node Processing for Registration Requests Retransmission behavior for Registration Requests is identical to that specified in Mobile IP specification [7]. A retransmitted Registration Request MAY use the same Challenge value as given in the original Registration Request. PROPOSED TEXT: Retransmission behavior for Registration Requests is identical to that specified in Mobile IP specification [7]. A retransmitted Registration Request MAY use the same Challenge value as given in the original Registration Request or a Retransmit Challenge (see section 1.1). 2.) OLD TEXT: 3.2. Foreign Agent Processing for Registration Requests If a mobile node retransmits a Registration Request with the same Challenge extension, and the Foreign Agent still has a pending Registration Request record in effect for the mobile node, then the Foreign Agent forwards the Registration Request to the Home Agent again. ... 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. ... PROPOSED TEXT: OLD TEXT: 3.2. Foreign Agent Processing for Registration Requests If a mobile node retransmits a Registration Request with the same Challenge extension or a Retransmit Challenge, and the Foreign Agent still has a pending Registration Request record in effect for the mobile node, then the Foreign Agent forwards the Registration Request to the Home Agent again. ... The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was a Retransmit Challenge, 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. ... 1.1. Terminology ADD the following definition: Retransmit Challenge: A challenge used by the MN to indicate to the Foreign Agent that it is retransmitting its Registration Request. The value of the Retransmit Challenge MUST equal the challenge value used in the MN latest Registration Request plus 1. Regards, Ahmad ------_=_NextPart_001_01C361B4.618B651E Content-Type: text/html Content-Transfer-Encoding: quoted-printable New Issue: 3102bis Stale Challenge may cause a DOS

Hello,

During an interoperability = testing activity the Root Cause of the following problem is caused by = RFC3012bis not offering a clear retransmission mechanism between the MN = and the FA. The scenario goes as follows:


1. MN successfully Registers = with the FA and receives a RRP (ID1) with a new challenge (FAC1) =
2. MN starts downloading a = large file which takes a long time.
3. MN sends a RRQ = (Re-Registration, ID2) with challenge (FAC1) and starts a timer of (x = seconds) before retrying.
4. FA process the RRQ and = forward to HA and relay to MN a successful RRP (ID2) with challenge = (FAC2).
5. Since the MN is busy = downloading a large file, MN does not receive RRP on time.
6. MN retry timer expires and = retransmits RRQ (ID3)using Challenge(FAC1) and increase the retry timer = to 2x seconds (RFC3344).

7. FA rejects RRQ and sends RRP = (ID3) with "Stale Challenge" and Challenge value (FAC2) =
8. For the same reason in step = 5, MN retransmits RRQ (ID4) message with challenge (FAC1) and increase = timer to (4x seconds).

9. FA rejects RRQ and sends RRP = (ID4) with "Stale Challenge" and Challenge value = (FAC2)

10. MN receives RRP (ID2) before = retry timer expires but ignores it because it tracks ID4.
11. MN receives RRP (ID3) = before retry timer expires but ignores it because it tracks ID4. =
12. MN receives RRP (ID4) = before retry timer expires and act upon it, "Stale = Challenge"

13. MN uses challenge received = in RRP(ID4) and sends RRQ(ID5). This RRQ is not a retransmit, retry = timer =3D x seconds.
14. The scenario continues as = in steps 4-13.

15. This continue in infinite = loop denying the MN Re-Registration and eventually the MN loose its = connection due to lifetime expiry. This causes a DOS and prevents MN = from downloading a large file.

The above scenario is basically = caused by the fact that RFC3012bis introduced the MN-FA challenge for = replay protection without offering a real retransmit mechanism between = MN and FA to prevent such SERIOUS problem from happening. For this = problem I would like to offer the following solution:


1.)
OLD TEXT:
3.1. Mobile Node Processing for = Registration Requests
Retransmission behavior for = Registration Requests is identical to that specified in Mobile IP = specification [7]. A retransmitted Registration Request MAY use the = same Challenge value as given in the original Registration Request. =

PROPOSED TEXT:
Retransmission behavior for = Registration Requests is identical to that specified in Mobile IP = specification [7]. A retransmitted Registration Request MAY use the = same Challenge value as given in the original Registration Request or a = Retransmit Challenge (see section 1.1).

2.)
OLD TEXT:
3.2. Foreign Agent Processing = for Registration Requests
   If a mobile node = retransmits a Registration Request with the same
   Challenge = extension, and the Foreign Agent still has a pending
   Registration = Request record in effect for the mobile node, then
   the Foreign Agent = forwards the Registration Request to the Home
   Agent again. = ...

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



PROPOSED TEXT:
OLD TEXT:
3.2. Foreign Agent Processing = for Registration Requests
   If a mobile node = retransmits a Registration Request with the same
   Challenge = extension or a Retransmit Challenge, and the Foreign Agent
   still has a = pending Registration Request record in effect for the
   mobile node, then = the Foreign Agent forwards the Registration Request
   to the Home Agent = again. ...

   The Foreign Agent = MUST NOT accept any Challenge in the Registration
   Request unless it = was a Retransmit Challenge, 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.  ...


1.1. Terminology
ADD the following = definition:

Retransmit Challenge:
A challenge used by the MN to = indicate to the Foreign Agent that it is retransmitting its = Registration Request. The value of the Retransmit Challenge MUST equal = the challenge value used in the MN latest Registration Request plus 1. =


Regards,
Ahmad

------_=_NextPart_001_01C361B4.618B651E-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 14 17:46:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27697 for ; Thu, 14 Aug 2003 17:46:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPv0-00021c-B1 for mip4-archive@odin.ietf.org; Thu, 14 Aug 2003 17:46:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ELk22T007780 for mip4-archive@odin.ietf.org; Thu, 14 Aug 2003 17:46:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPv0-00021P-6a for mip4-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 17:46:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27694 for ; Thu, 14 Aug 2003 17:45:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nPux-0006AG-00 for mip4-web-archive@ietf.org; Thu, 14 Aug 2003 17:45:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nPux-0006AC-00 for mip4-web-archive@ietf.org; Thu, 14 Aug 2003 17:45:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPuy-00021C-FI; Thu, 14 Aug 2003 17:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nPuD-00020o-L1 for mip4@optimus.ietf.org; Thu, 14 Aug 2003 17:45: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 RAA27678 for ; Thu, 14 Aug 2003 17:45:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nPuB-0006A1-00 for mip4@ietf.org; Thu, 14 Aug 2003 17:45:11 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19nPuA-00069s-00 for mip4@ietf.org; Thu, 14 Aug 2003 17:45:10 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7ELiaE29366; Thu, 14 Aug 2003 16:44:36 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7ELiZj21049; Thu, 14 Aug 2003 16:44:35 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJMPQ2-00017O-00; Thu, 14 Aug 2003 17:44:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16188.696.536937.422217@gargle.gargle.HOWL> Date: Thu, 14 Aug 2003 16:44:24 -0500 From: Pete McCann To: mip4@ietf.org Cc: Henrik Levkowetz Subject: [Mip4] draft-kulkarni-mobileip-dynamic-assignment as Workgroup Item? In-Reply-To: <20030810070259.756b7d5b.henrik@levkowetz.com> References: <20030810070259.756b7d5b.henrik@levkowetz.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Henrik Levkowetz writes: > > One of the charter items of the mip4 working group is dynamic HA > assignment. The document draft-kulkarni-mobileip-dynamic-assignment-01.txt > proposes a mechanism for doing this at registration time. We would now > like to confirm with the working group that this document should be > made the basis of registration time HA assignment, and moved forward > as a workgroup item. Any objections? > > The chairs [chair hat off for a moment] I wanted to offer some of my own comments on this draft - I hope others will read it closely and comment as well. At a high level, what this draft does is allow one HA to redirect a registration request to a different HA, when the HA field (not the destination IP address) is set to 0.0.0.0 or 255.255.255.255. My main concern with this draft is that there is a lot left unspecified (just look for all the occurrences of "outside the scope") and some of these unspecified procedures are actually quite important. For example, the abstract says: The distance between a MN and HA affects the latency for control and data traffic. When the distance between the MN and HA is large, the resulting latency may be unacceptable. Therefore, it is advantageous to select a nearest HA to the MN during initial registration. The mechanism outlined in the draft doesn't seem to satisfy this requirement. This is because "Directed" HA must be a-priori configured with the "Assigned" HA IP address, which implies they would be in the same domain. So, the real meat of the above requirement is that: (1) the MN (or the FA) must somehow discover a local HA to which the message can be sent; and, (2) the MN must develop a security association with that HA. Both of these procedures are ruled explicitly outside the scope of the draft. Note that I think (1) or (2) can be met with procedures that don't require any notion of "Directed" or "Assigned" HA. Rather, the main thrust of the draft seems to be at the next requirement listed in the abstract: There are other reasons for assigning an optimal HA beyond just locality, such as administrative policies, load balancing etc. The abstract goes on to state: This draft proposes a generic lightweight dynamic home agent assignment framework. The goal of the framework is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA assignment. At best, this draft is really defining some front-end behavior (message formats and Mobile IP processing) that would enable dynamic home agent assignment, but I wouldn't go so far as to call it a framework (due to the large amount of unspecified work left to do). The draft also assumes that the assigned HA will be able to verify the authentication extensions in the redirected RRQ. In section 5.1 the draft states: Example of one such implementation is where MN shares identical security associations with all the Directed HA(s) and Assigned HA(s) in the network. I consider this to be completely unacceptable security practice and I think this statement should be removed from the draft. Rather, it seems like this method will only work with something like the MN-AAA extension that can be verified from one of many HAs in the network, and that a security association MUST be developed dynamically along the lines of the AAA-keys draft. I think limitations like this should be described in the security considerations. I understand a new version with expanded security considerations is in preparation; I will defer additional security comments until it comes out. So, I think the draft may be valuable in that it specifies the front-end behavior necessary to enable AAA-keys and the MIPv4 Diameter application. This is similar to the way the NAI and MN-AAA draft specify front-end behavior, while leaving the actual authentication to AAA mechanisms specified elsewhere. However, this draft seems to sneak in some additional HA redirection functionality (purely for load balancing) that I am not convinced is required at this time. I would like to hear the opinions of others in the WG on whether this is important enough to include in the current draft - perhaps it could best be addressed with a separate draft, using a Rejection code instead of a forwarding mechanism? -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 14 19:31:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01698 for ; Thu, 14 Aug 2003 19:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nRYe-0005s4-10 for mip4-archive@odin.ietf.org; Thu, 14 Aug 2003 19:31:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7ENV3H5022568 for mip4-archive@odin.ietf.org; Thu, 14 Aug 2003 19:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nRYd-0005rv-Qg for mip4-web-archive@optimus.ietf.org; Thu, 14 Aug 2003 19:31:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01669 for ; Thu, 14 Aug 2003 19:31:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nRYc-0006vr-00 for mip4-web-archive@ietf.org; Thu, 14 Aug 2003 19:31:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nRYb-0006vo-00 for mip4-web-archive@ietf.org; Thu, 14 Aug 2003 19:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nRYb-0005rh-Ug; Thu, 14 Aug 2003 19:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nRY5-0005qE-8S for mip4@optimus.ietf.org; Thu, 14 Aug 2003 19:30:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01665 for ; Thu, 14 Aug 2003 19:30:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nRY3-0006vi-00 for mip4@ietf.org; Thu, 14 Aug 2003 19:30:27 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19nRY2-0006v3-00 for mip4@ietf.org; Thu, 14 Aug 2003 19:30:26 -0400 Received: from zrc2c001.us.nortel.com (zrc2c001.us.nortel.com [47.103.121.31]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7ENTf607492; Thu, 14 Aug 2003 18:29:41 -0500 (CDT) Received: from zrc2c009.us.nortel.com ([47.103.120.49]) by zrc2c001.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QZ6Q2YZS; Thu, 14 Aug 2003 18:29:42 -0500 Received: from iqmail.net (chowdury-2.us.nortel.com [47.103.84.37]) by zrc2c009.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id QY18GV5Q; Thu, 14 Aug 2003 18:29:41 -0500 Message-ID: <3F3C1A9C.4040705@iqmail.net> Date: Thu, 14 Aug 2003 18:26:20 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Kuntal Chowdhury User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann CC: mip4@ietf.org Subject: Re: [Mip4] draft-kulkarni-mobileip-dynamic-assignment as Workgroup Item? References: <20030810070259.756b7d5b.henrik@levkowetz.com> <16188.696.536937.422217@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Pete McCann wrote: > Hi, > > Henrik Levkowetz writes: > > > > One of the charter items of the mip4 working group is dynamic HA > > assignment. The document draft-kulkarni-mobileip-dynamic-assignment-01.txt > > proposes a mechanism for doing this at registration time. We would now > > like to confirm with the working group that this document should be > > made the basis of registration time HA assignment, and moved forward > > as a workgroup item. Any objections? > > > > The chairs > > [chair hat off for a moment] > > I wanted to offer some of my own comments on this draft - I hope > others will read it closely and comment as well. > > > At a high level, what this draft does is allow one HA to redirect a > registration request to a different HA, when the HA field (not the > destination IP address) is set to 0.0.0.0 or 255.255.255.255. > The MN does not know the HA's address to begin with. Therefore the FA needs to figure out (R=1 case) which directed HA to relay the RRQ. The draft talks about how the FA discovers the "unicast" address to put in the destination of the IP packet. This is also an important aspect of the draft. > My main concern with this draft is that there is a lot left > unspecified (just look for all the occurrences of "outside the scope") > and some of these unspecified procedures are actually quite > important. For example, the abstract says: > > The distance between a > MN and HA affects the latency for control and data traffic. > When the distance between the MN and HA is large, the resulting > latency may be unacceptable. Therefore, it is advantageous to > select a nearest HA to the MN during initial registration. > > The mechanism outlined in the draft doesn't seem to satisfy this > requirement. This is because "Directed" HA must be a-priori > configured with the "Assigned" HA IP address, which implies they would > be in the same domain. So, the real meat of the above requirement is > that: > > (1) the MN (or the FA) must somehow discover a local HA to which the > message can be sent; and, I think the draft talks about this part in 5.4. > (2) the MN must develop a security association with that HA. > The MN has an SA with the home network: is a valid assumption. I don't think we need to pick a particular mechanism to establish SA between the MN and the HA in a framework document. > Both of these procedures are ruled explicitly outside the scope of the > draft. Note that I think (1) or (2) can be met with procedures that > don't require any notion of "Directed" or "Assigned" HA. Rather, the > main thrust of the draft seems to be at the next requirement listed in > the abstract: > My reading of the draft is somewhat different. I think the above paragraph in the abstract clearly states that assignment of an HA in the close proximity of the MN is the main motivation for dynamic HA assignment. If dynamic HA assignment addresses RO for MIPv4, then we should go for it. However, I think the draft lacks details on how this location aware HA assignment scheme works without any location info exchange. > There are other reasons for assigning an optimal HA beyond just > locality, such as administrative policies, load balancing etc. > I think load balancing is an important motivation for dynamic HA assignment. I would say that the draft lacks details on this significant motivation. > The abstract goes on to state: > > This draft proposes a generic lightweight dynamic home agent > assignment framework. The goal of the framework is to provide a > mechanism to assign an optimal HA for a Mobile IP session while > allowing any suitable method for HA assignment. > > At best, this draft is really defining some front-end behavior > (message formats and Mobile IP processing) that would enable dynamic > home agent assignment, but I wouldn't go so far as to call it a > framework (due to the large amount of unspecified work left to do). > > I agree that this draft leaves too many things unspecified. We should identify those areas for improvement and add necessary details. > The draft also assumes that the assigned HA will be able to verify the > authentication extensions in the redirected RRQ. In section 5.1 the > draft states: > > Example of one such implementation is where MN > shares identical security associations with all the Directed > HA(s) and Assigned HA(s) in the network. > > I consider this to be completely unacceptable security practice and I > think this statement should be removed from the draft. Rather, it > seems like this method will only work with something like the MN-AAA > extension that can be verified from one of many HAs in the network, > and that a security association MUST be developed dynamically along > the lines of the AAA-keys draft. I think limitations like this should > be described in the security considerations. I understand a new > version with expanded security considerations is in preparation; I > will defer additional security comments until it comes out. > > The above sentence is an example. It does not mandate anything. No harm keeping it. > So, I think the draft may be valuable in that it specifies the > front-end behavior necessary to enable AAA-keys and the MIPv4 Diameter > application. This is similar to the way the NAI and MN-AAA draft > specify front-end behavior, while leaving the actual authentication to > AAA mechanisms specified elsewhere. However, this draft seems to > sneak in some additional HA redirection functionality (purely for load > balancing) that I am not convinced is required at this time. I would > like to hear the opinions of others in the WG on whether this is > important enough to include in the current draft - perhaps it could > best be addressed with a separate draft, using a Rejection code > instead of a forwarding mechanism? > > I don't think we should attempt to link this draft with AAA-keys and MIPv4 Diameter at all, it is irrelevant. Regarding load balancing, the draft does not emphasize much about it. I believe the draft should have a section on load balancing aspect as well. -Kuntal _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Aug 15 13:31:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05900 for ; Fri, 15 Aug 2003 13:31:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niPp-00071F-BY for mip4-archive@odin.ietf.org; Fri, 15 Aug 2003 13:31:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FHV5X9026977 for mip4-archive@odin.ietf.org; Fri, 15 Aug 2003 13:31:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niPn-000712-Pz for mip4-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 13:31:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05860 for ; Fri, 15 Aug 2003 13:30:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niPl-0004Wf-00 for mip4-web-archive@ietf.org; Fri, 15 Aug 2003 13:31:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19niPl-0004Wc-00 for mip4-web-archive@ietf.org; Fri, 15 Aug 2003 13:31:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niPl-00070l-LC; Fri, 15 Aug 2003 13:31:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19niOq-0006xb-9K for mip4@optimus.ietf.org; Fri, 15 Aug 2003 13:30:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05850 for ; Fri, 15 Aug 2003 13:30:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19niOo-0004WR-00 for mip4@ietf.org; Fri, 15 Aug 2003 13:30:02 -0400 Received: from auemail2.lucent.com ([192.11.223.163] helo=auemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19niOn-0004WO-00 for mip4@ietf.org; Fri, 15 Aug 2003 13:30:01 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by auemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7FHTfI03392; Fri, 15 Aug 2003 12:29:42 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7FHTJV24607; Fri, 15 Aug 2003 12:29:19 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJO8KT-0001PK-00; Fri, 15 Aug 2003 13:29:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16189.6252.444024.674837@gargle.gargle.HOWL> Date: Fri, 15 Aug 2003 12:29:16 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "'mip4@ietf.org'" , "Jayshree Bharatia" Subject: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Ahmad, A couple of questions on your proposal, and then a comment: Ahmad Muhanna writes: > Hello, > > During an interoperability testing activity the Root Cause of the following > problem is caused by RFC3012bis not offering a clear retransmission > mechanism between the MN and the FA. The scenario goes as follows: > > > 1. MN successfully Registers with the FA and receives a RRP (ID1) with a new > challenge (FAC1) > 2. MN starts downloading a large file which takes a long time. > 3. MN sends a RRQ (Re-Registration, ID2) with challenge (FAC1) and starts a > timer of (x seconds) before retrying. > 4. FA process the RRQ and forward to HA and relay to MN a successful RRP > (ID2) with challenge (FAC2). > 5. Since the MN is busy downloading a large file, MN does not receive RRP on > time. > 6. MN retry timer expires and retransmits RRQ (ID3)using Challenge(FAC1) and > increase the retry timer to 2x seconds (RFC3344). > 7. FA rejects RRQ and sends RRP (ID3) with "Stale Challenge" and Challenge > value (FAC2) > 8. For the same reason in step 5, MN retransmits RRQ (ID4) message with > challenge (FAC1) and increase timer to (4x seconds). > 9. FA rejects RRQ and sends RRP (ID4) with "Stale Challenge" and Challenge > value (FAC2) > > 10. MN receives RRP (ID2) before retry timer expires but ignores it because > it tracks ID4. > 11. MN receives RRP (ID3) before retry timer expires but ignores it because > it tracks ID4. > 12. MN receives RRP (ID4) before retry timer expires and act upon it, "Stale > Challenge" > > 13. MN uses challenge received in RRP(ID4) and sends RRQ(ID5). This RRQ is > not a retransmit, retry timer = x seconds. > 14. The scenario continues as in steps 4-13. > > 15. This continue in infinite loop denying the MN Re-Registration and > eventually the MN loose its connection due to lifetime expiry. This causes a > DOS and prevents MN from downloading a large file. > > The above scenario is basically caused by the fact that RFC3012bis > introduced the MN-FA challenge for replay protection without offering a real > retransmit mechanism between MN and FA to prevent such SERIOUS problem from > happening. For this problem I would like to offer the following solution: > > > 1.) > OLD TEXT: > 3.1. Mobile Node Processing for Registration Requests > Retransmission behavior for Registration Requests is identical to that > specified in Mobile IP specification [7]. A retransmitted Registration > Request MAY use the same Challenge value as given in the original > Registration Request. > > PROPOSED TEXT: > Retransmission behavior for Registration Requests is identical to that > specified in Mobile IP specification [7]. A retransmitted Registration > Request MAY use the same Challenge value as given in the original > Registration Request or a Retransmit Challenge (see section 1.1). > > 2.) > OLD TEXT: > 3.2. Foreign Agent Processing for Registration Requests > If a mobile node retransmits a Registration Request with the same > Challenge extension, and the Foreign Agent still has a pending > Registration Request record in effect for the mobile node, then > the Foreign Agent forwards the Registration Request to the Home > Agent again. ... > > 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. ... > > > > PROPOSED TEXT: > OLD TEXT: ^^^^^^^^ I assume this is a typo, below is new text > 3.2. Foreign Agent Processing for Registration Requests > If a mobile node retransmits a Registration Request with the same > Challenge extension or a Retransmit Challenge, and the Foreign Agent > still has a pending Registration Request record in effect for the > mobile node, then the Foreign Agent forwards the Registration Request > to the Home Agent again. ... ^^^^^ If the MN uses a "Retransmit Challenge", then which registration request should be forwarded to the HA here - the old one or the new one? > The Foreign Agent MUST NOT accept any Challenge in the Registration > Request unless it was a Retransmit Challenge, 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. ... > > > 1.1. Terminology > ADD the following definition: > > Retransmit Challenge: > A challenge used by the MN to indicate to the Foreign Agent that it is > retransmitting its Registration Request. The value of the Retransmit > Challenge MUST equal the challenge value used in the MN latest Registration > Request plus 1. So the MN should increment the Challenge field with each retransmission? Is that what you mean? Does this mean the FA must be prepared to accept any of the currently valid challenges plus some window N? > Regards, > Ahmad I agree with you that Challenge values become STALE_CHALLENGE only after the FA receives the RRP from the HA, which is a bit strange, because it means that you can retransmit a request (and it will be accepted and forwarded by the FA) only up to the point where the FA receives the response from the HA. After that, if you lose/delay the RRP on its way to the MN, new retransmissions received by the FA will be interpreted as STALE_CHALLENGE. I think the assumption was that eventually, the MN will get a clean request/response end-to-end, and registration will complete. If, as you point out, the forward channel towards the MN is congested, and it is impossible to guarantee timely delivery of the RRP, the MN may not receive the RRP before it increments the ID field (note that only the Timestamp based replay protection causes the ID field to increment on a retransmission) and retransmits the request. If the channel is still congested, it may never receive a valid response to its most recently transmitted registration request. However, I fail to see how your changes fix this problem. It seems like even if we had a way to indicate the presence of a retransmission to the FA, the circumstances that you outline could still take place. In fact, RRPs may be dropped entirely on the reverse link due to congestion, not just arrive late. It is true that the challenge response mechanism introduces a new failure case (STALE_CHALLENGE), but this seems incidental to me. Rather, I think we can only fall back on this text which is in RFC 3344: The maximum time until a new Registration Request is sent SHOULD be no greater than the requested Lifetime of the Registration Request. The minimum value SHOULD be large enough to account for the size of the messages, twice the round trip time for transmission to the home agent, and at least an additional 100 milliseconds to allow for processing the messages before responding. The round trip time for transmission to the home agent will be at least as large as the time required to transmit the messages at the link speed of the mobile node's current point of attachment. Some circuits add another 200 milliseconds of satellite delay in the total round trip time to the home agent. The minimum time between Registration Requests MUST NOT be less than 1 second. Each successive retransmission timeout period SHOULD be at least twice the previous period, as long as that is less than the maximum as specified above. So, if you know you are on a link with a lot of buffering, you should increase the minimum interval between retransmissions to take into account the worst-case round trip time. This will ensure that, if there is any response to your request in the queue, you will get it prior to retransmitting. The basic Mobile IP message flow requires a complete round-trip between MN & HA, where no link along the path drops the message. Retransmission is performed end-to-end. I don't see how or why we should change this. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Aug 15 15:42:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11060 for ; Fri, 15 Aug 2003 15:42:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkSY-0006gy-QK for mip4-archive@odin.ietf.org; Fri, 15 Aug 2003 15:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FJg28m025720 for mip4-archive@odin.ietf.org; Fri, 15 Aug 2003 15:42:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkSY-0006gl-M2 for mip4-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 15:42:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11049 for ; Fri, 15 Aug 2003 15:41:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkSX-0005TY-00 for mip4-web-archive@ietf.org; Fri, 15 Aug 2003 15:42:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nkSW-0005TV-00 for mip4-web-archive@ietf.org; Fri, 15 Aug 2003 15:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkSX-0006gS-4S; Fri, 15 Aug 2003 15:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nkRh-0006ce-3h for mip4@optimus.ietf.org; Fri, 15 Aug 2003 15: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 PAA11012 for ; Fri, 15 Aug 2003 15:41:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nkRf-0005Sr-00 for mip4@ietf.org; Fri, 15 Aug 2003 15:41:07 -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 19nkRf-0005Sn-00 for mip4@ietf.org; Fri, 15 Aug 2003 15:41:07 -0400 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7FJeY7F003514; Fri, 15 Aug 2003 12:40:34 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-128-107-163-220.cisco.com [128.107.163.220]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKK68285; Fri, 15 Aug 2003 12:33:13 -0700 (PDT) Message-Id: <4.3.2.7.2.20030815123655.02325050@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Aug 2003 12:40:32 -0700 To: Thomas Narten From: Kent Leung Subject: Re: [Mip4] draft-patel-mobileip-experimental-messages-00.txt Cc: Henrik Levkowetz , Alpesh , mip4@ietf.org In-Reply-To: <200308120139.h7C1d5303908@cichlid.adsl.duke.edu> References: 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: , Hi Thomas. Agree with your feedback. Your comments were considered and applied in the latest version, announced in 8/7 email below. We will post the -01 version to the WG soon. Kent >To: mip4@ietf.org >CC: Henrik Levkowetz , kleung@cisco.com, > mccap@lucent.com >Subject: [Mip4] draft-patel-mobileip-experimental-messages-01.txt > >Hello: > >A new version of the draft >Experimental Message Types for Mobile IPv4 > >is available for your reference at : > >ftp://ftp-eng.cisco.com/ftp/mipdrafts/draft-patel-mobileip-experimental-messages-01.txt > >This version includes support for experimental extensions as suggested by >Henrik. > >Please send your comments. >Alpesh At 09:39 PM 8/11/2003 -0400, Thomas Narten wrote: >Playing catchup... > >There is no need to give a format for experimental options. The whole >point is that the format depends on what one is testing. Also, the >purpose of experimental messages (at least as I understand them and as >is described in draft-narten-iana-experimental-allocations-03.txt) is >that they are for experimentation, _not_ deployment, and not for >achieving interoperability with other implementations. They are >designed so that one can safely use them in a controlled setting >(e.g., lab or testbed) without conflicting with other registered >usages. > >They are _not_ designed for vendors to use to define new message types >that they can safely deploy without fear of conflicting with some >other use. Indeed, this is exactly the kind of thing we want to avoid >-- multiple different vendor-specific message types in use in >practice. If something really is useful, as soon as it becomes clear >it is useful, it should be documented and made an RFC proper, and >relatively quickly. Experimental allocations are for dealing with the >period before something becomes documented in an RFC or otherwise >recognized as being generally useful. > >Thomas _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Aug 15 16:34: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 QAA12583 for ; Fri, 15 Aug 2003 16:34: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 19nlGs-0001Tx-PB for mip4-archive@odin.ietf.org; Fri, 15 Aug 2003 16:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FKY2dp005691 for mip4-archive@odin.ietf.org; Fri, 15 Aug 2003 16:34:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlGs-0001Ti-KY for mip4-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 16:34: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 QAA12553 for ; Fri, 15 Aug 2003 16:33:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlGq-0005qw-00 for mip4-web-archive@ietf.org; Fri, 15 Aug 2003 16:34:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nlGq-0005qt-00 for mip4-web-archive@ietf.org; Fri, 15 Aug 2003 16:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlGr-0001TW-MI; Fri, 15 Aug 2003 16:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nlGa-0001RI-04 for mip4@optimus.ietf.org; Fri, 15 Aug 2003 16:33:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12534 for ; Fri, 15 Aug 2003 16:33:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nlGX-0005qT-00 for mip4@ietf.org; Fri, 15 Aug 2003 16:33:41 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 19nlGW-0005qP-00 for mip4@ietf.org; Fri, 15 Aug 2003 16:33:40 -0400 Message-ID: <038a01c3636c$8a38ec70$976015ac@dclkempt40> From: "James Kempf" To: Date: Fri, 15 Aug 2003 13:33:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Mip4] Call For Journal Papers: Next Generation Mobile Security 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 Wireless Personal Communications special issue on: "Security for Next Generation Mobile Communications" Guest Editors: Anand Prasad, DoCoMo Comm. Labs. Europe GmbH James Kempf, DoCoMo Comm. Labs. USA, Inc. The special session on "Security for Next Generation Mobile Communications" in WPMC 2003 held in Yokosuka, Japan, received five high quality papers which inspired the editors of the Kulwer journal to publish a special issue. This call for papers requests researchers interested in publishing a high quality paper in the field of next generation communications security for mobile communications systems to contribute papers to the journal. We are moving towards an era where "always-on" devices will provide communication anywhere, anytime and any kind of service. The "always-on" mobile device usage model faces new security issues. Long term secure sessions and simple security for multiple services challenge the current state of security technology. In addition, the trend towards heterogeneous networks, also known as "Beyond 3G" or B3G, integrates various heterogeneous access network technologies underneath a common IP layer. The different access network technologies have their own security requirements and mechanisms, making the integration of multiple access technologies for simple network access more challenging. In addition, many existing security protocols re- implement common security operations at different layers of the stack. A more modularized architecture, allowing common operations like certificate exchanged to be reused, would simplify many protocols and reduce implementation overhead. Finally, the trend toward software defined radio may require a new approach to security in order to accommodate dynamically reconfigurable spectrum usage. In this special issue our focus will be particularly on network layer security for next generation mobile networks. Possible topics are: . Modularized security architectures and implementations for reduced footprint, . Security issues related to mobility in heterogonous networks . Location privacy, . Opportunistic security, . Security for ad hoc networks, . Lightweight security infrastructure (ex. lightweight key distribution), . Bridging the divide between traditional AAA and e-commerce techniques for authentication and authorization, . Security techniques for software defined radio and dynamic spectrum usage. More information about the journal, including formatting instructions, can be found at: http://www.kluweronline.com/issn/0929-6212 Important dates: Submission of manuscripts : 1 December 2003 Notification of acceptance : 1 March 2004 Final Manuscripts Due : 1 April 2004 Publication of Feature Topic : second half 2004 Submissions should be sent to one of the guest editors: Anand R. Prasad Dr. James Kempf DoCoMo Comm. Labs. Europe GmbH DoCoMo Comm. Labs. USA, Inc. Landsberger strasse 308-312 181 Metro Drive, Suite 300 80687 Munich San Jose, CA 95110 Germany USA E-mail: prasad@docomolab-euro.com E-mail: kempf@docomolabs-usa.com _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Aug 15 18:21:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16563 for ; Fri, 15 Aug 2003 18: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 19nmwR-0007q4-Lp for mip4-archive@odin.ietf.org; Fri, 15 Aug 2003 18:21:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7FML32I030125 for mip4-archive@odin.ietf.org; Fri, 15 Aug 2003 18:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmwR-0007po-39 for mip4-web-archive@optimus.ietf.org; Fri, 15 Aug 2003 18:21: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 SAA16553 for ; Fri, 15 Aug 2003 18:20:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nmwO-0006Xj-00 for mip4-web-archive@ietf.org; Fri, 15 Aug 2003 18:21:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19nmwN-0006Xf-00 for mip4-web-archive@ietf.org; Fri, 15 Aug 2003 18:20:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19nmwO-0007pW-VX; Fri, 15 Aug 2003 18: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 19nmvi-0007om-6u for mip4@optimus.ietf.org; Fri, 15 Aug 2003 18:20: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 SAA16539 for ; Fri, 15 Aug 2003 18:20:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19nmve-0006XS-00 for mip4@ietf.org; Fri, 15 Aug 2003 18:20:14 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19nmvd-0006XB-00 for mip4@ietf.org; Fri, 15 Aug 2003 18:20:13 -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 h7FMJbq19695; Fri, 15 Aug 2003 17:19:37 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Aug 2003 17:19:38 -0500 Message-ID: From: "Ahmad Muhanna" To: "'Pete McCann'" Cc: "'mip4@ietf.org'" , "Jayshree Bharatia" Subject: RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS Date: Fri, 15 Aug 2003 17:19:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3637B.5037057A" 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_01C3637B.5037057A Content-Type: text/plain Hi Pete, Please see comments inline. Regards, Ahmad > > Hi, Ahmad, > > A couple of questions on your proposal, and then a comment: > > Ahmad Muhanna writes: > > Hello, > > > > During an interoperability testing activity the Root Cause of the following problem is caused by RFC3012bis not > offering a clear retransmission mechanism between the MN and the FA. The scenario goes as follows: > > > > 1. MN successfully Registers with the FA and receives a RRP (ID1) with a new challenge (FAC1) > > 2. MN starts downloading a large file which takes a long time. > > 3. MN sends a RRQ (Re-Registration, ID2) with challenge (FAC1) and starts a timer of (x seconds) before retrying. > > 4. FA process the RRQ and forward to HA and relay to MN a successful RRP (ID2) with challenge (FAC2). > > 5. Since the MN is busy downloading a large file, MN does not receive RRP on time. > > 6. MN retry timer expires and retransmits RRQ (ID3)using Challenge(FAC1) and increase the retry timer to 2x seconds (RFC3344). > > 7. FA rejects RRQ and sends RRP (ID3) with "Stale Challenge" and Challenge value (FAC2) > > 8. For the same reason in step 5, MN retransmits RRQ (ID4) message with challenge (FAC1) and increase timer to (4x seconds). > > 9. FA rejects RRQ and sends RRP (ID4) with "Stale Challenge" and Challenge value (FAC2) > > 10. MN receives RRP (ID2) before retry timer expires but ignores it because it tracks ID4. > > 11. MN receives RRP (ID3) before retry timer expires but ignores it because it tracks ID4. > > 12. MN receives RRP (ID4) before retry timer expires and act upon it, "Stale Challenge" > > 13. MN uses challenge received in RRP(ID4) and sendsRRQ(ID5). This RRQ is not a retransmit, retry timer = x seconds. > > 14. The scenario continues as in steps 4-13. > > 15. This continue in infinite loop denying the MN Re-Registration and eventually the MN loose its connection due to lifetime expiry. This causes a DOS and prevents MN from downloading a large file. > > The above scenario is basically caused by the fact that RFC3012bis introduced the MN-FA challenge for replay > > protection without offering a real retransmit mechanism between MN and FA to prevent such SERIOUS problem from > > happening. For this problem I would like to offer the following solution: > > > > 1.) > > OLD TEXT: > > 3.1. Mobile Node Processing for Registration Requests > > Retransmission behavior for Registration Requests is identical to that > > specified in Mobile IP specification [7]. A retransmitted Registration > > Request MAY use the same Challenge value as given in the original > > Registration Request. > > > > PROPOSED TEXT: > > Retransmission behavior for Registration Requests is identical to that > > specified in Mobile IP specification [7]. A retransmitted Registration > > Request MAY use the same Challenge value as given in the original > > Registration Request or a Retransmit Challenge (see section 1.1). > > 2.) > > OLD TEXT: > > 3.2. Foreign Agent Processing for Registration Requests > > If a mobile node retransmits a Registration Request with the same > > Challenge extension, and the Foreign Agent still has a pending > > Registration Request record in effect for the mobile node, then > > the Foreign Agent forwards the Registration Request to the Home > > Agent again. ... > > > > 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. ... > > > > > > > > PROPOSED TEXT: > > OLD TEXT: > ^^^^^^^^ I assume this is a typo, below is new text [AM] YES. > > 3.2. Foreign Agent Processing for Registration Requests > > If a mobile node retransmits a Registration Request with the same > > Challenge extension or a Retransmit Challenge, and the Foreign Agent > > still has a pending Registration Request record in effect for the > > mobile node, then the Foreign Agent forwards the Registration Request > > to the Home Agent again. ... > ^^^^^ > If the MN uses a "Retransmit Challenge", then which > registration request should be forwarded to the HA here - the > old one or the new one? > [AM] To be exactly handled the same way a retransmit is currently done. i.e. it depends on the state of the call at the FA. > > The Foreign Agent MUST NOT accept any Challenge in the Registration > > Request unless it was a Retransmit Challenge, 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. ... > > > > > > 1.1. Terminology > > ADD the following definition: > > > > Retransmit Challenge: > > A challenge used by the MN to indicate to the Foreign > > Agent that it is retransmitting its Registration Request. > > The value of the Retransmit Challenge MUST equal the > > challenge value used in the MN latest Registration Request plus 1. > > So the MN should increment the Challenge field with each > retransmission? Is that what you mean? [AM] Yes. > Does this mean the FA must be prepared to accept any of the currently valid > challenges plus some window N? [AM] YES. We may call it a tolerance window. Similar to what the HA has for the MN with timesatmp replay protection. > > > Regards, > > Ahmad > > > I agree with you that Challenge values become STALE_CHALLENGE > only after the FA receives the RRP from the HA, which is a > bit strange, because it means that you can retransmit a > request (and it will be accepted and forwarded by the FA) > only up to the point where the FA receives the response from > the HA. After that, if you lose/delay the RRP on its way to > the MN, new retransmissions received by the FA will be > interpreted as STALE_CHALLENGE. I think the assumption was > that eventually, the MN will get a clean request/response > end-to-end, and registration will complete. [AM] I agree. > > If, as you point out, the forward channel towards the MN is > congested, and it is impossible to guarantee timely delivery > of the RRP, the MN may not receive the RRP before it > increments the ID field (note that only the Timestamp based > replay protection causes the ID field to increment on a > retransmission) and retransmits the request. > However, I fail to see how your changes fix this problem. It > seems like even if we had a way to indicate the presence of a > retransmission to the FA, the circumstances that you outline > could still take place. In fact, RRPs may be dropped entirely > on the reverse link due to congestion, not just arrive late. > It is true that the challenge response mechanism introduces a > new failure case (STALE_CHALLENGE), but this seems incidental to me. [AM] You are highlighting two issues here. 1. The channel is totally blocked (???) and all RRPs will be dropped in the way to the MN. This scenario no one has a solution for and we should not worry about fixing it. 2. The second issue is the one I am trying to solve. The incidental case when the channel is congested and the RRP taking more time than expected to arrive at the MN or the channel is congested that some of the RRP is dropped BUT NOT every RRP is dropped. My solution to this problem is to prevent Stale-Challenge DOS by allowing the MN to indicate to the FA that it is a retransmit and the FA will accept the RRQ and relay it to the HA. By NOT blocking the retransmit RRQ at the FA due to STALE_CHALLENGE, a successful RRP with code (00) is always sent to the MN. This gives the MN a chance to receive one successful RRP message before MN hits its retry timer (retransmit timer). i.e. In the example I outlined earlier, MN will receive RRP (ID4) "successful" while it is tracking ID4. This makes the MN happy and Re-Registration will complete successfully. > > Rather, I think we can only fall back on this text which is > in RFC 3344: > > The maximum time until a new Registration Request is sent SHOULD be > no greater than the requested Lifetime of the Registration Request. > The minimum value SHOULD be large enough to account for the size of > the messages, twice the round trip time for transmission to the home > agent, and at least an additional 100 milliseconds to allow for > processing the messages before responding. The round trip time for > transmission to the home agent will be at least as large as the time > required to transmit the messages at the link speed of the mobile > node's current point of attachment. Some circuits add another 200 > milliseconds of satellite delay in the total round trip time to the > home agent. The minimum time between Registration Requests MUST NOT > be less than 1 second. Each successive retransmission timeout period > SHOULD be at least twice the previous period, as long as that is less > than the maximum as specified above. > > So, if you know you are on a link with a lot of buffering, > you should increase the minimum interval between > retransmissions to take into account the worst-case round > trip time. This will ensure that, if there is any response > to your request in the queue, you will get it prior to retransmitting. [AM] I think the process you just highlighted is to provide the MN with a dynamic mechanism to detect the state of the link. I believe it is very difficult to statically predict the sate of the link that the MN is attached to, especially with inter-technology handoff, etc... > > The basic Mobile IP message flow requires a complete > round-trip between MN & HA, where no link along the path > drops the message. Retransmission is performed end-to-end. I > don't see how or why we should change this. > [AM] Unfortunately, RFC3012bis broke the mechanism outlined above in section 3.6.3 (RFC3344) by the stale-challenge mechanism. This solution is needed to enable the MN to make use of the above mechanism. > -Pete > > > ------_=_NextPart_001_01C3637B.5037057A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a = DOS

Hi Pete,
Please see comments inline.

Regards,
Ahmad
 
>
> Hi, Ahmad,
>
> A couple of questions on your proposal, and = then a comment:
>
> Ahmad Muhanna writes:
>  > Hello,
>  >
>  > During an interoperability testing = activity the Root Cause of the following problem is caused by = RFC3012bis not
> offering a clear retransmission mechanism = between the MN and the FA. The scenario goes as follows:
>  >
>  > 1. MN successfully Registers with = the FA and receives a RRP (ID1) with a new challenge (FAC1)
>  > 2. MN starts downloading a large = file which takes a long time.
>  > 3. MN sends a RRQ (Re-Registration, = ID2) with challenge (FAC1) and starts a timer of (x seconds) before = retrying.
>  > 4. FA process the RRQ and forward to = HA and relay to MN a successful RRP (ID2) with challenge (FAC2). =
>  > 5. Since the MN is busy downloading = a large file, MN does not receive RRP on time. 
>  > 6. MN retry timer expires and = retransmits RRQ (ID3)using Challenge(FAC1) and increase the retry timer = to 2x seconds (RFC3344). 

>  > 7. FA rejects RRQ and sends RRP (ID3) = with "Stale Challenge" and Challenge value (FAC2)
>  > 8. For the same reason in step 5, MN = retransmits RRQ (ID4) message with challenge (FAC1) and increase timer = to (4x seconds).

>  > 9. FA rejects RRQ and sends RRP (ID4) = with "Stale Challenge" and Challenge value (FAC2)
>  > 10. MN receives RRP (ID2) before = retry timer expires but ignores it because it tracks ID4.
>  > 11. MN receives RRP (ID3) before = retry timer expires but ignores it because it tracks ID4.
>  > 12. MN receives RRP (ID4) before = retry timer expires and act upon it, "Stale Challenge" =
>  > 13. MN uses challenge received in = RRP(ID4) and sendsRRQ(ID5). This RRQ is not a retransmit, retry timer = =3D x seconds. 

>  > 14. The scenario continues as in = steps 4-13.
>  > 15. This continue in infinite loop = denying the MN Re-Registration and eventually the MN loose its = connection due to lifetime expiry. This causes a DOS and prevents MN = from downloading a large file.

 
>  > The above scenario is basically = caused by the fact that RFC3012bis introduced the MN-FA challenge for = replay
>  > protection without offering a real = retransmit mechanism between MN and FA to prevent such SERIOUS problem = from
>  > happening. For this problem I would = like to offer the following solution:
>  >
>  > 1.)
>  > OLD TEXT:
>  > 3.1. Mobile Node Processing for = Registration Requests
>  > Retransmission behavior for = Registration Requests is identical to that 
>  > specified in Mobile IP specification = [7]. A retransmitted Registration 
>  > Request MAY use the same Challenge = value as given in the original 
>  > Registration Request.
>  >
>  > PROPOSED TEXT:
>  > Retransmission behavior for = Registration Requests is identical to that 
>  > specified in Mobile IP specification = [7]. A retransmitted Registration 
>  > Request MAY use the same Challenge = value as given in the original 
>  > Registration Request or a Retransmit = Challenge (see section 1.1).
>  > 2.)
>  > OLD TEXT:
>  > 3.2. Foreign Agent Processing for = Registration Requests
>  >    If a mobile node = retransmits a Registration Request with the same
>  >    Challenge = extension, and the Foreign Agent still has a pending
>  >    Registration = Request record in effect for the mobile node, then
>  >    the Foreign Agent = forwards the Registration Request to the Home
>  >    Agent again. = ...
>  >
>  >    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. ...
>  >
>  >
>  >
>  > PROPOSED TEXT:
>  > OLD TEXT:
>    ^^^^^^^^ I assume this is a = typo, below is new text
[AM]
YES.

>  > 3.2. Foreign Agent Processing for = Registration Requests
>  >    If a mobile node = retransmits a Registration Request with the same
>  >    Challenge = extension or a Retransmit Challenge, and the Foreign Agent
>  >    still has a = pending Registration Request record in effect for the
>  >    mobile node, then = the Foreign Agent forwards the Registration Request
>  >    to the Home Agent = again. ...

>          = ;            = ;   ^^^^^
> If the MN uses a "Retransmit = Challenge", then which
> registration request should be forwarded to the = HA here - the
> old one or the new one?
>

[AM]
To be exactly handled the same way a retransmit is = currently done. i.e. it depends on the state of the call at the = FA.

>  >    The Foreign Agent = MUST NOT accept any Challenge in the Registration
>  >    Request unless it = was a Retransmit Challenge, 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.  ...
>  >
>  >
>  > 1.1. Terminology
>  > ADD the following definition:
>  >
>  > Retransmit Challenge:
>  > A challenge used by the MN to = indicate to the Foreign
>  > Agent that it is retransmitting its = Registration Request.
>  > The value of the Retransmit = Challenge MUST equal the
>  > challenge value used in the MN = latest Registration Request plus 1.
>
> So the MN should increment the Challenge field = with each
> retransmission?  Is that what you = mean? 

[AM]
Yes.

> Does this mean the FA must be prepared to accept = any of the currently valid
> challenges plus some window N?

[AM]
YES.
We may call it a tolerance window. Similar to what = the HA has for the MN with timesatmp replay protection.
>
>  > Regards,
>  > Ahmad
>
>
> I agree with you that Challenge values become = STALE_CHALLENGE
> only after the FA receives the RRP from the HA, = which is a
> bit strange, because it means that you can = retransmit a
> request (and it will be accepted and forwarded = by the FA)
> only up to the point where the FA receives the = response from
> the HA.  After that, if you lose/delay the = RRP on its way to
> the MN, new retransmissions received by the FA = will be
> interpreted as STALE_CHALLENGE.  I think = the assumption was
> that eventually, the MN will get a clean = request/response
> end-to-end, and registration will = complete.

[AM]
I agree.
>
> If, as you point out, the forward channel = towards the MN is
> congested, and it is impossible to guarantee = timely delivery
> of the RRP, the MN may not receive the RRP = before it
> increments the ID field (note that only the = Timestamp based
> replay protection causes the ID field to = increment on a
> retransmission) and retransmits the = request. 
> However, I fail to see how your changes fix = this problem.  It
> seems like even if we had a way to indicate the = presence of a
> retransmission to the FA, the circumstances = that you outline
> could still take place. In fact, RRPs may be = dropped entirely
> on the reverse link due to congestion, not just = arrive late. 
> It is true that the challenge response = mechanism introduces a
> new failure case (STALE_CHALLENGE), but this = seems incidental to me.

[AM]
You are highlighting two issues here.
1. The channel is totally blocked (???) and all RRPs = will be dropped in the way to the MN. This scenario no one has a = solution for and we should not worry about fixing it.

2. The second issue is the one I am trying to solve. = The incidental case when the channel is congested and the RRP taking = more time than expected to arrive at the MN or the channel is congested = that some of the RRP is dropped BUT NOT every RRP is = dropped.

My solution to this problem is to prevent = Stale-Challenge DOS by allowing the MN to indicate to the FA that it is = a retransmit and the FA will accept the RRQ and relay it to the HA. By = NOT blocking the retransmit RRQ at the FA due to STALE_CHALLENGE, a = successful RRP with code (00) is always sent to the MN. This gives the = MN a chance to receive one successful RRP message before MN hits its = retry timer (retransmit timer).

i.e. In the example I outlined earlier, MN will = receive RRP (ID4) "successful" while it is tracking ID4. This = makes the MN happy and Re-Registration will complete successfully. =

>
> Rather, I think we can only fall back on this = text which is
> in RFC 3344:
>
>    The maximum time until a new = Registration Request is sent SHOULD be
>    no greater than the requested = Lifetime of the Registration Request.
>    The minimum value SHOULD be = large enough to account for the size of
>    the messages, twice the round = trip time for transmission to the home
>    agent, and at least an = additional 100 milliseconds to allow for
>    processing the messages = before responding.  The round trip time for
>    transmission to the home = agent will be at least as large as the time
>    required to transmit the = messages at the link speed of the mobile
>    node's current point of = attachment.  Some circuits add another 200
>    milliseconds of satellite = delay in the total round trip time to the
>    home agent.  The minimum = time between Registration Requests MUST NOT
>    be less than 1 second.  = Each successive retransmission timeout period
>    SHOULD be at least twice the = previous period, as long as that is less
>    than the maximum as specified = above.
>
> So, if you know you are on a link with a lot of = buffering,
> you should increase the minimum interval = between
> retransmissions to take into account the = worst-case round
> trip time.  This will ensure that, if = there is any response
> to your request in the queue, you will get it = prior to retransmitting.

[AM]
I think the process you just highlighted is to = provide the MN with a dynamic mechanism to detect the state of the = link. I believe it is very difficult to statically predict the sate of = the link that the MN is attached to, especially with inter-technology = handoff, etc...

>
> The basic Mobile IP message flow requires a = complete
> round-trip between MN & HA, where no link = along the path
> drops the message. Retransmission is performed = end-to-end.  I
> don't see how or why we should change = this.
>
[AM]
Unfortunately, RFC3012bis broke the mechanism = outlined above in section 3.6.3 (RFC3344) by the stale-challenge = mechanism.

This solution is needed to enable the MN to make use = of the above mechanism. 
 
> -Pete
>
>
>

------_=_NextPart_001_01C3637B.5037057A-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 18 04:21: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 EAA13391 for ; Mon, 18 Aug 2003 04:21: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 19ofGD-0005St-Me for mip4-archive@odin.ietf.org; Mon, 18 Aug 2003 04:21:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7I8L5RN021006 for mip4-archive@odin.ietf.org; Mon, 18 Aug 2003 04:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ofGC-0005Sj-8S for mip4-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 04:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13387 for ; Mon, 18 Aug 2003 04:21:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ofG9-0005ey-00 for mip4-web-archive@ietf.org; Mon, 18 Aug 2003 04:21:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ofG8-0005eu-00 for mip4-web-archive@ietf.org; Mon, 18 Aug 2003 04:21:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19ofGA-0005SX-67; Mon, 18 Aug 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 19ofFf-0005SF-4E for mip4@optimus.ietf.org; Mon, 18 Aug 2003 04:20:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13367 for ; Mon, 18 Aug 2003 04:20:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ofFc-0005er-00 for mip4@ietf.org; Mon, 18 Aug 2003 04:20:28 -0400 Received: from mail.birdstep.com ([80.239.52.35]) by ietf-mx with esmtp (Exim 4.12) id 19ofFb-0005ed-00 for mip4@ietf.org; Mon, 18 Aug 2003 04:20:27 -0400 Received: from espenlaptop (dhcp-12-13.birdstep.com [10.0.12.13]) by mail.birdstep.com (8.12.8/8.12.8) with SMTP id h7I8JpoH016091; Mon, 18 Aug 2003 10:19:51 +0200 Reply-To: From: "Espen Klovning" To: "Henrik Levkowetz" , Subject: RE: [Mip4] Current state of 3012bis solicited agent advertisement issue. Date: Mon, 18 Aug 2003 10:17:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030813103506.3f0c4305.henrik@levkowetz.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 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 Henrik We are happy with the proposed text. It will solve some of the interop issues we have seen. espen Espen Klovning Birdstep Technology ASA -> Proposed text: -> -> - Add at the end of section 2 (as Section 2.1) - or as section 3.6 -> -> 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. -> However, a foreign agent which provides challenge handling according -> to this document is restricted to only respond with unicast agent -> advertisements in response to a router solicitation. -> -> The agent advertisement which is unicast back to the soliciting -> mobile node MUST be handled as follows: A new Challenge value MUST -> be re-generated periodically and remembered as the most recent -> challenge issued to the mobile node. It is RECOMMENDED that this -> period be on the order of 60 seconds. If the challenge most recently -> issued to the soliciting mobile node has not been previously used -> (as defined in Section 1.1), and the re-generation period has not -> elapsed, the most recent challenge unicast to the mobile node -> through a registration reply or a unicast agent advertisement SHOULD -> be repeated in the newly issued unicast agent advertisement. (For -> further discussion of this, see Section 12.) OK -> - 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. OK -> -> - In section 3.3, change -> -> From: -> The Foreign Agent SHOULD include a new Mobile-Foreign Challenge -> Extension in any Registration Reply, successful or not. If the -> foreign agent includes this extension in a successful Registration -> Reply, the extension SHOULD precede a Mobile-Foreign authentication -> extension. Suppose the ... -> -> To: -> A Foreign Agent which provides challenge handling according to this -> document MUST include a previously unused Mobile-Foreign Challenge -> Extension in any Registration Reply, successful or not. If the -> foreign agent includes this extension in a successful Registration -> Reply, the extension SHOULD precede a Mobile-Foreign authentication -> extension. -> -> If the challenge most recently issued to the soliciting mobile node -> has not been previously used (as defined in Section 1.1), and the -> re-generation period (as described in section 2.1) has not elapsed, -> the most recent challenge unicast to the mobile node through a -> registration reply or a unicast agent advertisement SHOULD be -> repeated in the registration reply. -> -> Suppose the ... OK -> -> - Add the following at the end of Section 12: -> -> Note that an active attacker may try to prevent successful -> registrations by sending a large number of Agent Solicitations or -> bogus Registration Requests, each of which could cause the FA to -> respond with a fresh challenge, invalidating the challenge that the -> MN is currently trying to use. To prevent such attacks, the FA -> SHOULD repeat the same challenge value in successive unicast -> responses to Agent Solicitations or in Registration Replies to -> Requests that did not contain valid MN-AAA or MN-FA authentication -> extensions for some limited period of time (on the order of 60 -> seconds). Note that each challenge returned to an MN MUST be -> previously unused by that MN. OK -> -> - In Appendix E, change the second paragraph -> -> From: -> -> In the program fragment, it is presumed that the foreign agent -> keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a -> record of the last advertised challenge used by a mobile node, and -> also a record of the last challenge provided to a mobile node in a -> Registration Reply. -> -> To: -> -> In the program fragment, it is presumed that the foreign agent keeps -> an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record -> of the last advertised challenge used by a mobile node, and also a -> record of the last challenge provided to a mobile node in a -> Registration Reply or unicast Agent Advertisement. OK _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 18 04:57: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 EAA13993 for ; Mon, 18 Aug 2003 04: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 19ofp1-0006KT-Gv for mip4-archive@odin.ietf.org; Mon, 18 Aug 2003 04:57:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7I8v3MP024330 for mip4-archive@odin.ietf.org; Mon, 18 Aug 2003 04: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 19ofp1-0006KL-3b for mip4-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 04: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 EAA13990 for ; Mon, 18 Aug 2003 04:56:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ofoy-0005ro-00 for mip4-web-archive@ietf.org; Mon, 18 Aug 2003 04:57:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19ofox-0005rl-00 for mip4-web-archive@ietf.org; Mon, 18 Aug 2003 04: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 19ofoz-0006K5-Qs; Mon, 18 Aug 2003 04: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 19ofoG-0006Im-PW for mip4@optimus.ietf.org; Mon, 18 Aug 2003 04:56: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 EAA13982 for ; Mon, 18 Aug 2003 04:56:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19ofoD-0005rd-00 for mip4@ietf.org; Mon, 18 Aug 2003 04:56:13 -0400 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19ofoD-0005rH-00 for mip4@ietf.org; Mon, 18 Aug 2003 04:56:13 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7I8tYD21037; Mon, 18 Aug 2003 03:55:34 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7I8tUT25575; Mon, 18 Aug 2003 03:55:31 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJT4SE-00020O-00; Mon, 18 Aug 2003 04:55:26 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16192.38013.438380.494752@gargle.gargle.HOWL> Date: Mon, 18 Aug 2003 03:55:25 -0500 From: Pete McCann To: "Ahmad Muhanna" Cc: "'mip4@ietf.org'" , "Jayshree Bharatia" Subject: RE: [Mip4] New Issue: 3102bis Stale Challenge may cause a DOS In-Reply-To: References: X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Ahmad, Ahmad Muhanna writes: > > > 3.2. Foreign Agent Processing for Registration Requests > > > If a mobile node retransmits a Registration Request with the same > > > Challenge extension or a Retransmit Challenge, and the Foreign Agent > > > > still has a pending Registration Request record in effect for the > > > mobile node, then the Foreign Agent forwards the Registration > Request > > > to the Home Agent again. ... > > > ^^^^^ > > If the MN uses a "Retransmit Challenge", then which > > registration request should be forwarded to the HA here - the > > old one or the new one? > > > > [AM] > To be exactly handled the same way a retransmit is currently done. i.e. it > depends on the state of the call at the FA. So, you are saying that whether or not the FA has received a response to the original RRQ from the HA, it forwards the new registration request to the HA, not a copy of the old one, right? You used the words "forwards the Registration Request to the Home Agent again" but you didn't specify what you mean by "the Registration Request". The new one is not identical to the old one, as it differs in both the Challenge and Identification fields. > > > Retransmit Challenge: > > > A challenge used by the MN to indicate to the Foreign > > > Agent that it is retransmitting its Registration Request. > > > The value of the Retransmit Challenge MUST equal the > > > challenge value used in the MN latest Registration Request plus 1. > > > > So the MN should increment the Challenge field with each > > retransmission? Is that what you mean? > > [AM] > Yes. > > > Does this mean the FA must be prepared to accept any of the currently > valid > > challenges plus some window N? > > [AM] > YES. > We may call it a tolerance window. Similar to what the HA has for the MN > with timesatmp replay protection. So we have to be careful here - we are (slightly) weakening the strength of the Challenge mechanism if we allow a whole range of consecutive challenges to be valid at the FA instead of just one. How do we choose the proper window size? Is it possible to characterize the resulting strength/weakness of the challenge mechanism? > > If, as you point out, the forward channel towards the MN is > > congested, and it is impossible to guarantee timely delivery > > of the RRP, the MN may not receive the RRP before it > > increments the ID field (note that only the Timestamp based > > replay protection causes the ID field to increment on a > > retransmission) and retransmits the request. > > However, I fail to see how your changes fix this problem. It > > seems like even if we had a way to indicate the presence of a > > retransmission to the FA, the circumstances that you outline > > could still take place. In fact, RRPs may be dropped entirely > > on the reverse link due to congestion, not just arrive late. > > It is true that the challenge response mechanism introduces a > > new failure case (STALE_CHALLENGE), but this seems incidental to me. > > [AM] > You are highlighting two issues here. > 1. The channel is totally blocked (???) and all RRPs will be dropped in the > way to the MN. This scenario no one has a solution for and we should not > worry about fixing it. > > 2. The second issue is the one I am trying to solve. The incidental case > when the channel is congested and the RRP taking more time than expected to > arrive at the MN or the channel is congested that some of the RRP is dropped > BUT NOT every RRP is dropped. > > My solution to this problem is to prevent Stale-Challenge DOS by allowing > the MN to indicate to the FA that it is a retransmit and the FA will accept > the RRQ and relay it to the HA. By NOT blocking the retransmit RRQ at the FA > due to STALE_CHALLENGE, a successful RRP with code (00) is always sent to > the MN. This gives the MN a chance to receive one successful RRP message > before MN hits its retry timer (retransmit timer). > > i.e. In the example I outlined earlier, MN will receive RRP (ID4) > "successful" while it is tracking ID4. This makes the MN happy and > Re-Registration will complete successfully. But, what if the RRP (ID4) is delayed until the MN retransmits again? Really, the root cause of this problem is that the MN didn't wait long enough for the first response. > > Rather, I think we can only fall back on this text which is > > in RFC 3344: > > > > The maximum time until a new Registration Request is sent SHOULD be > > no greater than the requested Lifetime of the Registration Request. > > The minimum value SHOULD be large enough to account for the size of > > the messages, twice the round trip time for transmission to the home > > agent, and at least an additional 100 milliseconds to allow for > > processing the messages before responding. The round trip time for > > transmission to the home agent will be at least as large as the time > > required to transmit the messages at the link speed of the mobile > > node's current point of attachment. Some circuits add another 200 > > milliseconds of satellite delay in the total round trip time to the > > home agent. The minimum time between Registration Requests MUST NOT > > be less than 1 second. Each successive retransmission timeout period > > SHOULD be at least twice the previous period, as long as that is less > > than the maximum as specified above. > > > > So, if you know you are on a link with a lot of buffering, > > you should increase the minimum interval between > > retransmissions to take into account the worst-case round > > trip time. This will ensure that, if there is any response > > to your request in the queue, you will get it prior to retransmitting. > > [AM] > I think the process you just highlighted is to provide the MN with a dynamic > mechanism to detect the state of the link. I believe it is very difficult to > statically predict the sate of the link that the MN is attached to, > especially with inter-technology handoff, etc... Well, I think you have to have some estimate of the RTT of the link when choosing this parameter. If you are running over a cdma2000 link you probably should not set the initial retransmit interval smaller than 4 seconds. > > The basic Mobile IP message flow requires a complete > > round-trip between MN & HA, where no link along the path > > drops the message. Retransmission is performed end-to-end. I > > don't see how or why we should change this. > > > [AM] > Unfortunately, RFC3012bis broke the mechanism outlined above in section > 3.6.3 (RFC3344) by the stale-challenge mechanism. > This solution is needed to enable the MN to make use of the above mechanism. I don't think the retransmit mechanism is broken, you just need to choose the right interval for the type of link you are on. You have also pointed out that receipt of a STALE_CHALLENGE is really at best an ambiguous indicator to the MN of whether or not it is registered. In the situation you outlined, the FA has a valid registration renewal for the MN but the MN doesn't know it. Perhaps we should state that the MN should not disconnect itself merely because its old Lifetime expired, when it receives one or more STALE_CHALLENGE results from its attempts to register in the meantime. That is, if the MN can continue to send and receive packets on the link, it is possible to keep going even though the MN's local estimate of the Lifetime has expired. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 18 06:13: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 GAA14892 for ; Mon, 18 Aug 2003 06:13: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 19oh0Y-0008Vt-Ob for mip4-archive@odin.ietf.org; Mon, 18 Aug 2003 06:13:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IAD2pr032719 for mip4-archive@odin.ietf.org; Mon, 18 Aug 2003 06:13:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oh0Y-0008Ve-KB for mip4-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 06:13: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 GAA14886 for ; Mon, 18 Aug 2003 06:12:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oh0U-0006E4-00 for mip4-web-archive@ietf.org; Mon, 18 Aug 2003 06:12:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19oh0U-0006E1-00 for mip4-web-archive@ietf.org; Mon, 18 Aug 2003 06:12:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19oh0X-0008VJ-2V; Mon, 18 Aug 2003 06: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 19oh0A-0008Uq-Mb for mip4@optimus.ietf.org; Mon, 18 Aug 2003 06:12:38 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14877 for ; Mon, 18 Aug 2003 06:12:32 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19oh06-0006Dj-00 for mip4@ietf.org; Mon, 18 Aug 2003 06:12:34 -0400 Received: from fep06-0.kolumbus.fi ([193.229.0.57] helo=fep06-app.kolumbus.fi) by ietf-mx with esmtp (Exim 4.12) id 19oh06-0006Dg-00 for mip4@ietf.org; Mon, 18 Aug 2003 06:12:34 -0400 Received: from yin.bjorns.net ([62.248.131.182]) by fep06-app.kolumbus.fi with ESMTP id <20030818101202.XCGQ8538.fep06-app.kolumbus.fi@yin.bjorns.net> for ; Mon, 18 Aug 2003 13:12:02 +0300 Received: from bjorn by yin.bjorns.net with local (Exim 3.35 #1 (Debian)) id 19oh06-0005Kx-00 for ; Mon, 18 Aug 2003 13:12:34 +0300 Date: Mon, 18 Aug 2003 13:12:34 +0300 From: Bjorn Andersson To: mip4@ietf.org Message-ID: <20030818101234.GB20228@yin.bjorns.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA14878 Subject: [Mip4] Re: Current state of 3012bis solicited agent advertisement issue. 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 Henrik Levkowetz wrote: > This is a summary of the status of the issue of how to handle > solicited agent advertisements with challenges according to 3012bis. >=20 > There has been few participants so far in these discussions. In > order to gauge consensus, please respond to the individual proposed > text poits below if you have a position, and indicate whether you > support or oppose the text as proposed. All points are OK in my opinion. Bj=F6rn --=20 Bj=F6rn Andersson PGP id 5AFC144B _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Mon Aug 18 15:00: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 PAA29488 for ; Mon, 18 Aug 2003 15:00: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 19opEZ-00014h-C1 for mip4-archive@odin.ietf.org; Mon, 18 Aug 2003 15:00:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7IJ0320004127 for mip4-archive@odin.ietf.org; Mon, 18 Aug 2003 15:00:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19opEZ-00013q-3i for mip4-web-archive@optimus.ietf.org; Mon, 18 Aug 2003 15:00:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29448 for ; Mon, 18 Aug 2003 14:59:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19opEW-0001kD-00 for mip4-web-archive@ietf.org; Mon, 18 Aug 2003 15:00:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19opEV-0001k9-00 for mip4-web-archive@ietf.org; Mon, 18 Aug 2003 14:59:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19opEX-00013W-HC; Mon, 18 Aug 2003 15:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19opDe-00012P-5q for mip4@optimus.ietf.org; Mon, 18 Aug 2003 14:59: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 OAA29433 for ; Mon, 18 Aug 2003 14:59:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19opDb-0001jo-00 for mip4@ietf.org; Mon, 18 Aug 2003 14:59:03 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19opDa-0001jk-00 for mip4@ietf.org; Mon, 18 Aug 2003 14:59:02 -0400 Received: (qmail 20405 invoked from network); 18 Aug 2003 18:58:43 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 18 Aug 2003 18:58:43 -0000 Date: Mon, 18 Aug 2003 20:58:42 +0200 From: Henrik Levkowetz To: Tsirtsis George Cc: "'mobile-ip@sunroof.eng.sun.com'" , "'Pete McCann'" , mip4@ietf.org Message-Id: <20030818205842.26f0524f.henrik@levkowetz.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0BFFDE@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A0BFFDE@ftmail.lab.flarion.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 Subject: [Mip4] Re: [mobile-ip] FW: I-D ACTION:draft-tsirtsis-v4v6-mipv4-00.txt Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Thanks, George. Actually, as the mobile-ip list is being deprecated, new discussions should preferrably go to the mip4, mip6 or mipshop list, depending on topic. So I'm copying the mip4 list on this, and suggest we leave the mobile-ip list off future postings. Henrik Monday 18 August 2003, George wrote: > All, > > Here is a first stub on the Mobile IPv4 changes that we propose so that we > deal with most of the issues described in > > > We are also working on the MIPv6 version which we hope to publish soon. > > I did not copy the MIP4 list to avoid too much cross-posting but I copy the > MIP4 chairs (Pete/Henrik) for their consideration. > > Regards > George (and Hesham) > > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > Sent: Monday, August 18, 2003 4:14 PM > Subject: I-D ACTION:draft-tsirtsis-v4v6-mipv4-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Dual Stack Mobile IPv4 > Author(s) : G. Tsirtsis, H. Soliman > Filename : draft-tsirtsis-v4v6-mipv4-00.txt > Pages : 17 > Date : 2003-8-18 > > This specification provides IPv6 extensions to the Mobile IPv4 > [MIPv4] protocol. The extensions allow a dual stack node to use IPv4 > and IPv6 home addresses as well as move between IPv4 and dual stack > network infrastructures. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-tsirtsis-v4v6-mipv4-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, type > "cd internet-drafts" and then > "get draft-tsirtsis-v4v6-mipv4-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-tsirtsis-v4v6-mipv4-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 12:30: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 MAA21551 for ; Tue, 19 Aug 2003 12:30: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 19p9Mx-00058m-L0 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 12:30:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JGU3EH019754 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 12:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9Mx-00058X-GS for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 12:30: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 MAA21510 for ; Tue, 19 Aug 2003 12:29:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9Mw-00036E-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 12:30:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p9Mv-000368-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 12:30:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9Mv-000583-MS; Tue, 19 Aug 2003 12:30:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9Mg-00057G-R5 for mip4@optimus.ietf.org; Tue, 19 Aug 2003 12:29: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 MAA21491 for ; Tue, 19 Aug 2003 12:29:41 -0400 (EDT) From: jonathan.n@telia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9Mf-00035k-00 for mip4@ietf.org; Tue, 19 Aug 2003 12:29:45 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19p9MZ-00035E-00 for mip4@ietf.org; Tue, 19 Aug 2003 12:29:41 -0400 To: Date: Tue, 19 Aug 2003 18:29:25 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00364DF1" Message-Id: Subject: [Mip4] Re: That movie Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_00364DF1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_00364DF1 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00364DF1-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 12:34: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 MAA21848 for ; Tue, 19 Aug 2003 12:34: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 19p9Qp-0005L3-38 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 12:34:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JGY3gL020515 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 12:34:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9Qo-0005Ko-Ud for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 12:34: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 MAA21814 for ; Tue, 19 Aug 2003 12:33:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9Qn-0003BL-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 12:34:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p9Qm-0003BE-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 12:34:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9Qn-0005JL-D1; Tue, 19 Aug 2003 12:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9QO-0005Hl-Et for mip4@optimus.ietf.org; Tue, 19 Aug 2003 12:33:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21750 for ; Tue, 19 Aug 2003 12:33:30 -0400 (EDT) From: thommy_persson@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9QM-00039z-00 for Mip4@ietf.org; Tue, 19 Aug 2003 12:33:34 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19p9QG-00038q-00 for Mip4@ietf.org; Tue, 19 Aug 2003 12:33:30 -0400 To: Date: Tue, 19 Aug 2003 18:33:14 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0039CD7D" Message-Id: Subject: [Mip4] Re: Wicked screensaver Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0039CD7D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0039CD7D Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0039CD7D-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 12:35: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 MAA21946 for ; Tue, 19 Aug 2003 12:35: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 19p9Ro-0005PE-J3 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 12:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JGZ44k020770 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 12:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9Ro-0005Ol-Ap for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 12:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21907 for ; Tue, 19 Aug 2003 12:34:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9Rm-0003Ct-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 12:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p9Rl-0003Cq-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 12:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9Rl-0005NY-AG; Tue, 19 Aug 2003 12:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9Rc-0005Ls-Lp for mip4@optimus.ietf.org; Tue, 19 Aug 2003 12:34:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21869 for ; Tue, 19 Aug 2003 12:34:47 -0400 (EDT) From: ultimatedarkness88@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9Rb-0003C7-00 for mip4@ietf.org; Tue, 19 Aug 2003 12:34:51 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19p9RU-0003Bj-00 for mip4@ietf.org; Tue, 19 Aug 2003 12:34:46 -0400 To: Date: Tue, 19 Aug 2003 18:34:30 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_003AF5D0" Message-Id: Subject: [Mip4] Your details Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_003AF5D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_003AF5D0 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_003AF5D0-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 13:02:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23360 for ; Tue, 19 Aug 2003 13:02:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9ru-0006v5-Ls for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 13:02:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JH22nW026593 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 13:02:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9ru-0006uq-Gp for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 13:02:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23328 for ; Tue, 19 Aug 2003 13:01:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9rs-0003de-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 13:02:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19p9rs-0003db-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 13:02:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19p9rt-0006uY-7L; Tue, 19 Aug 2003 13: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 19p9rT-0006u9-F1 for mip4@optimus.ietf.org; Tue, 19 Aug 2003 13:01: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 NAA23317 for ; Tue, 19 Aug 2003 13:01:29 -0400 (EDT) From: gamerschoice@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19p9rR-0003dR-00 for mip4@ietf.org; Tue, 19 Aug 2003 13:01:33 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19p9rL-0003dA-00 for mip4@ietf.org; Tue, 19 Aug 2003 13:01:28 -0400 To: Date: Tue, 19 Aug 2003 19:01:12 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00536952" Message-Id: Subject: [Mip4] Re: Thank you! Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_00536952 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_00536952 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00536952-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 13:37:39 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 NAA25299 for ; Tue, 19 Aug 2003 13:37:39 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pAPx-00004z-2Y for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 13:37:13 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JHbDcU032754 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 13:37:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pAPw-0008W9-Sk for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 13: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 NAA25279 for ; Tue, 19 Aug 2003 13:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAPu-0004Ee-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 13:37:10 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pAPl-0004EI-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 13:37:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pAPm-0008QP-6v; Tue, 19 Aug 2003 13:37:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pAPk-0008PA-Hh for mip4@optimus.ietf.org; Tue, 19 Aug 2003 13:37:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25253 for ; Tue, 19 Aug 2003 13:36:56 -0400 (EDT) From: L4nzY@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAPi-0004Do-00 for Mip4@ietf.org; Tue, 19 Aug 2003 13:36:58 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19pAPb-0004Dd-00 for Mip4@ietf.org; Tue, 19 Aug 2003 13:36:53 -0400 To: Date: Tue, 19 Aug 2003 19:36:37 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0073D56B" Message-Id: Subject: [Mip4] Thank you! Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_0073D56B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_0073D56B Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0073D56B-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 13:39: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 NAA25412 for ; Tue, 19 Aug 2003 13:39: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 19pARi-0000Nb-5v for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 13:39:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JHd2Vu001453 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 13:39:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pARi-0000NM-1n for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 13:39:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25384 for ; Tue, 19 Aug 2003 13:38:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pARf-0004GA-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 13:39:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pARf-0004G7-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 13:38:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pARh-0000MR-49; Tue, 19 Aug 2003 13:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pAR7-0000Js-Vm for mip4@optimus.ietf.org; Tue, 19 Aug 2003 13:38:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25372 for ; Tue, 19 Aug 2003 13:38:21 -0400 (EDT) From: RWM@zde.cz Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pAR5-0004G2-00 for mip4@ietf.org; Tue, 19 Aug 2003 13:38:23 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19pAR0-0004F1-00 for mip4@ietf.org; Tue, 19 Aug 2003 13:38:20 -0400 To: Date: Tue, 19 Aug 2003 19:38:04 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00752826" Message-Id: Subject: [Mip4] Your details Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_00752826 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00752826 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00752826-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 14:24:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27984 for ; Tue, 19 Aug 2003 14:24:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pB9G-0002Qk-S8 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 14:24:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JIO2iJ009333 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 14: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 19pB9G-0002QQ-Ly for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 14: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 OAA27963 for ; Tue, 19 Aug 2003 14:23:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pB9E-00053l-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 14:24:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pB9D-00053i-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 14: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 19pB9F-0002Pb-E3; Tue, 19 Aug 2003 14: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 19pB8P-0002P2-5L for mip4@optimus.ietf.org; Tue, 19 Aug 2003 14:23: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 OAA27931 for ; Tue, 19 Aug 2003 14:23:04 -0400 (EDT) From: dv@btinternet.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pB8M-000531-00 for Mip4@ietf.org; Tue, 19 Aug 2003 14:23:06 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19pB8G-00052H-00 for Mip4@ietf.org; Tue, 19 Aug 2003 14:23:02 -0400 To: Date: Tue, 19 Aug 2003 20:22:46 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_009E14D0" Message-Id: Subject: [Mip4] Re: Your application Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_009E14D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_009E14D0 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_009E14D0-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 14:48: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 OAA29644 for ; Tue, 19 Aug 2003 14:48: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 19pBWV-0003at-Cq for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 14:48:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JIm35l013816 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 14:48:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pBWV-0003al-9J for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 14:48: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 OAA29637 for ; Tue, 19 Aug 2003 14:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pBWS-0005WH-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 14:48:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pBWS-0005WE-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 14:48:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pBWT-0003aT-Kw; Tue, 19 Aug 2003 14:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pBWJ-0003aC-30 for mip4@optimus.ietf.org; Tue, 19 Aug 2003 14:47: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 OAA29620 for ; Tue, 19 Aug 2003 14:47:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pBWG-0005W4-00 for mip4@ietf.org; Tue, 19 Aug 2003 14:47:48 -0400 Received: from omr-m03.mx.aol.com ([64.12.138.3]) by ietf-mx with esmtp (Exim 4.12) id 19pBWF-0005Va-00 for mip4@ietf.org; Tue, 19 Aug 2003 14:47:47 -0400 Received: from rly-xn04.mx.aol.com (rly-xn04.mail.aol.com [172.20.83.137]) by omr-m03.mx.aol.com (v90_r2.6) with ESMTP id RELAYIN4-0819144644; Tue, 19 Aug 2003 14:46:44 -0500 Received: from localhost (localhost) by rly-xn04.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with internal id OAB21572; Tue, 19 Aug 2003 14:46:44 -0400 (EDT) Date: Tue, 19 Aug 2003 14:46:44 -0400 (EDT) From: Mail Delivery Subsystem Message-Id: <200308191846.OAB21572@rly-xn04.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="OAB21572.1061318804/rly-xn04.mx.aol.com" Auto-Submitted: auto-generated (failure) Subject: [Mip4] Returned mail: User unknown Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a MIME-encapsulated message --OAB21572.1061318804/rly-xn04.mx.aol.com The original message was received at Tue, 19 Aug 2003 14:46:19 -0400 (EDT) from as11-2-6.sto.s.bonet.se [217.215.164.169] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to air-xn02.mail.aol.com.: >>> RCPT To: <<< 550 MAILBOX NOT FOUND 550 ... User unknown --OAB21572.1061318804/rly-xn04.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-xn04.mx.aol.com Arrival-Date: Tue, 19 Aug 2003 14:46:19 -0400 (EDT) Final-Recipient: RFC822; macmaninfi@aol.com Action: failed Status: 5.1.1 Remote-MTA: DNS; air-xn02.mail.aol.com Diagnostic-Code: SMTP; 550 MAILBOX NOT FOUND Last-Attempt-Date: Tue, 19 Aug 2003 14:46:44 -0400 (EDT) --OAB21572.1061318804/rly-xn04.mx.aol.com Content-Type: text/rfc822-headers Received: from HALIPE (as11-2-6.sto.s.bonet.se [217.215.164.169]) by rly-xn04.mx.aol.com (v95.1) with ESMTP id MAILRELAYINXN42-6423f42707330d; Tue, 19 Aug 2003 14:46:12 -0400 From: To: Subject: Re: Your application Date: Tue, 19 Aug 2003 20:45:57 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00B34CF6" X-AOL-IP: 217.215.164.169 X-AOL-SCOLL-SCORE: 0:XXX:XX X-AOL-SCOLL-URL_COUNT: 0 Message-ID: <200308191446.6423f42707330d@rly-xn04.mx.aol.com> --OAB21572.1061318804/rly-xn04.mx.aol.com-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 14:50: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 OAA29752 for ; Tue, 19 Aug 2003 14:50: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 19pBYQ-0003g4-JW for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 14:50:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JIo2xN014130 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 14:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pBYQ-0003fp-GG for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 14:50: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 OAA29730 for ; Tue, 19 Aug 2003 14:49:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pBYN-0005YT-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 14:49:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pBYN-0005YQ-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 14:49:59 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pBYP-0003eV-Es; Tue, 19 Aug 2003 14:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pBXX-0003dJ-Ph for mip4@optimus.ietf.org; Tue, 19 Aug 2003 14:49: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 OAA29704 for ; Tue, 19 Aug 2003 14:49:02 -0400 (EDT) From: barf@zeelandnet.nl Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pBXV-0005Xt-00 for Mip4@ietf.org; Tue, 19 Aug 2003 14:49:05 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19pBXU-0005WZ-00 for Mip4@ietf.org; Tue, 19 Aug 2003 14:49:04 -0400 To: Date: Tue, 19 Aug 2003 20:48:50 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00B5F121" Message-Id: Subject: [Mip4] Re: Approved Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_00B5F121 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00B5F121-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 15:21: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 PAA02717 for ; Tue, 19 Aug 2003 15:21: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 19pC2S-0005ib-J4 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 15:21:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JJL4eu021975 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 15:21:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pC2S-0005hT-8v for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 15:21:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02689 for ; Tue, 19 Aug 2003 15:21:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pC2Q-00068P-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 15:21:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pC2P-00068J-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 15:21:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pC2P-0005gd-It; Tue, 19 Aug 2003 15:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pC1y-0005eq-Au for mip4@optimus.ietf.org; Tue, 19 Aug 2003 15:20: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 PAA02645 for ; Tue, 19 Aug 2003 15:20:30 -0400 (EDT) From: illuminati@sezampro.yu Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pC1x-00067W-00 for mip4@ietf.org; Tue, 19 Aug 2003 15:20:33 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19pC1b-000660-00 for mip4@ietf.org; Tue, 19 Aug 2003 15:20:24 -0400 To: Date: Tue, 19 Aug 2003 21:19:56 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00D26D37" Message-Id: Subject: [Mip4] Re: Thank you! Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_00D26D37 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00D26D37 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00D26D37-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 15:32: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 PAA03476 for ; Tue, 19 Aug 2003 15:32: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 19pCD6-0006GX-Ni for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 15:32:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JJW4wg024079 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 15:32:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCD6-0006GI-JD for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 15:32:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03434 for ; Tue, 19 Aug 2003 15:32:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCD5-0006ML-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 15:32:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pCD4-0006MG-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 15:32:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCD4-0006Eo-O6; Tue, 19 Aug 2003 15:32:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCCz-0006EA-My for mip4@optimus.ietf.org; Tue, 19 Aug 2003 15:31:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03418 for ; Tue, 19 Aug 2003 15:31:53 -0400 (EDT) From: 3Epodbot@yahoo.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCCy-0006Lx-00 for Mip4@ietf.org; Tue, 19 Aug 2003 15:31:56 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19pCCc-0006Km-00 for Mip4@ietf.org; Tue, 19 Aug 2003 15:31:46 -0400 To: Date: Tue, 19 Aug 2003 21:31:19 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00DCD9D2" Message-Id: Subject: [Mip4] Thank you! Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_00DCD9D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_00DCD9D2 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00DCD9D2-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 16:06: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 QAA06393 for ; Tue, 19 Aug 2003 16:06: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 19pCjy-0008NA-JI for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 16:06:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JK62BB032183 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 16:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCjy-0008Mv-DZ for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 16:06:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06365 for ; Tue, 19 Aug 2003 16:05:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCjw-0007DG-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 16:06:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pCjw-0007DD-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 16:06:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCjw-0008Mf-QN; Tue, 19 Aug 2003 16:06:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pCjE-0008JP-Kj for mip4@optimus.ietf.org; Tue, 19 Aug 2003 16:05: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 QAA06294 for ; Tue, 19 Aug 2003 16:05:12 -0400 (EDT) From: fbk_marcus@hotmail.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pCjD-0007Br-00 for Mip4@ietf.org; Tue, 19 Aug 2003 16:05:15 -0400 Received: from as11-2-6.sto.s.bonet.se ([217.215.164.169] helo=HALIPE) by ietf-mx with esmtp (Exim 4.12) id 19pCj2-0007Aa-00 for Mip4@ietf.org; Tue, 19 Aug 2003 16:05:08 -0400 To: Date: Tue, 19 Aug 2003 22:04:50 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00FB8706" Message-Id: Subject: [Mip4] Re: Approved Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format --_NextPart_000_00FB8706 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_00FB8706 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_00FB8706-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 16:37:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07889 for ; Tue, 19 Aug 2003 16:37:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDE1-0001jC-38 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 16:37:05 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JKb52w006636 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 16:37:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDE0-0001ix-TQ for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 16:37:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07877 for ; Tue, 19 Aug 2003 16:36:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pDDz-0007g3-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 16:37:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pDDy-0007g0-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 16:37:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDDx-0001gY-Fy; Tue, 19 Aug 2003 16:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pDDR-0001fK-UG for mip4@optimus.ietf.org; Tue, 19 Aug 2003 16:36:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07817 for ; Tue, 19 Aug 2003 16:36:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pDDQ-0007ey-00 for mip4@ietf.org; Tue, 19 Aug 2003 16:36:28 -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 19pDDP-0007dh-00 for mip4@ietf.org; Tue, 19 Aug 2003 16:36:27 -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 h7JKZtPk010769; Tue, 19 Aug 2003 13:35:55 -0700 (PDT) Received: from KLEUNG-W2K.cisco.com (dhcp-10-34-253-205.cisco.com [10.34.253.205]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKN91045; Tue, 19 Aug 2003 13:28:00 -0700 (PDT) Message-Id: <4.3.2.7.2.20030819133508.02442ee8@mira-sjcm-2.cisco.com> X-Sender: kleung@mira-sjcm-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 19 Aug 2003 13:35:54 -0700 To: Henrik Levkowetz From: Kent Leung Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. Cc: mip4@ietf.org In-Reply-To: <20030813103506.3f0c4305.henrik@levkowetz.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: , All points look good to me. Kent At 10:35 AM 8/13/2003 +0200, Henrik Levkowetz wrote: > This is a summary of the status of the issue of how to handle >solicited agent advertisements with challenges according to 3012bis. > >There has been few participants so far in these discussions. In >order to gauge consensus, please respond to the individual proposed >text poits below if you have a position, and indicate whether you >support or oppose the text as proposed. > >This includes those who have already participated in the discussions, >too, as it has not always been easy to determine exactly where there is >and is not consensus when going over the notes: _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 17:35: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 RAA10205 for ; Tue, 19 Aug 2003 17:35: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 19pE88-0004Yd-H9 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 17:35:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JLZ41X017513 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 17:35:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pE88-0004YO-DL for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 17:35:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10197 for ; Tue, 19 Aug 2003 17:34:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pE85-0000US-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 17:35:02 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pE85-0000UO-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 17:35:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pE86-0004Y4-37; Tue, 19 Aug 2003 17:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pE7R-0004SR-HQ for mip4@optimus.ietf.org; Tue, 19 Aug 2003 17:34:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10171 for ; Tue, 19 Aug 2003 17:34:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pE7P-0000U2-00 for mip4@ietf.org; Tue, 19 Aug 2003 17:34:19 -0400 Received: from omr-m02.mx.aol.com ([64.12.138.2]) by ietf-mx with esmtp (Exim 4.12) id 19pE7O-0000Tb-00 for mip4@ietf.org; Tue, 19 Aug 2003 17:34:18 -0400 Received: from rly-xg05.mx.aol.com (rly-xg05.mail.aol.com [172.20.115.202]) by omr-m02.mx.aol.com (v90_r2.6) with ESMTP id RELAYIN6-0819173337; Tue, 19 Aug 2003 17:33:37 -0500 Received: from localhost (localhost) by rly-xg05.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with internal id RAD16853; Tue, 19 Aug 2003 17:33:37 -0400 (EDT) Date: Tue, 19 Aug 2003 17:33:37 -0400 (EDT) From: Mail Delivery Subsystem Message-Id: <200308192133.RAD16853@rly-xg05.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="RAD16853.1061328817/rly-xg05.mx.aol.com" Auto-Submitted: auto-generated (failure) Subject: [Mip4] Returned mail: User unknown Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a MIME-encapsulated message --RAD16853.1061328817/rly-xg05.mx.aol.com The original message was received at Tue, 19 Aug 2003 17:33:11 -0400 (EDT) from as11-2-6.sto.s.bonet.se [217.215.164.169] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to air-xg01.mail.aol.com.: >>> RCPT To: <<< 550 MAILBOX NOT FOUND 550 ... User unknown --RAD16853.1061328817/rly-xg05.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-xg05.mx.aol.com Arrival-Date: Tue, 19 Aug 2003 17:33:11 -0400 (EDT) Final-Recipient: RFC822; macmaninfi@aol.com Action: failed Status: 5.1.1 Remote-MTA: DNS; air-xg01.mail.aol.com Diagnostic-Code: SMTP; 550 MAILBOX NOT FOUND Last-Attempt-Date: Tue, 19 Aug 2003 17:33:37 -0400 (EDT) --RAD16853.1061328817/rly-xg05.mx.aol.com Content-Type: text/rfc822-headers Received: from HALIPE (as11-2-6.sto.s.bonet.se [217.215.164.169]) by rly-xg05.mx.aol.com (v95.1) with ESMTP id MAILRELAYINXG58-4723f42979233; Tue, 19 Aug 2003 17:33:07 -0400 From: To: Subject: Re: That movie Date: Tue, 19 Aug 2003 23:32:52 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_014C1EC3" X-AOL-IP: 217.215.164.169 X-AOL-SCOLL-SCORE: 0:XXX:XX X-AOL-SCOLL-URL_COUNT: 0 Message-ID: <200308191733.4723f42979233@rly-xg05.mx.aol.com> --RAD16853.1061328817/rly-xg05.mx.aol.com-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 18:25:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13137 for ; Tue, 19 Aug 2003 18:25:53 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEuv-0007AH-7W for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 18:25:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7JMPTOx027539 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 18:25:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEuv-0007A2-1V for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 18:25:29 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13076 for ; Tue, 19 Aug 2003 18:25:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pEur-0000xo-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 18:25:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pEug-0000wI-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 18:25:14 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pEuY-00072R-82; Tue, 19 Aug 2003 18:25:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pElA-0006dx-U7 for mip4@optimus.ietf.org; Tue, 19 Aug 2003 18:15:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12618 for ; Tue, 19 Aug 2003 18:15:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pEl8-0000rg-00 for mip4@ietf.org; Tue, 19 Aug 2003 18:15:22 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19pEl7-0000rP-00 for mip4@ietf.org; Tue, 19 Aug 2003 18:15:21 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7JMEIV11220; Tue, 19 Aug 2003 15:14:18 -0700 X-mProtect: <200308192214> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsqBL4e; Tue, 19 Aug 2003 15:14:16 PDT Message-ID: <3F42A139.496CFF3D@iprg.nokia.com> Date: Tue, 19 Aug 2003 15:14:17 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. References: <20030813103506.3f0c4305.henrik@levkowetz.com> 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 Henrik Levkowetz wrote: > Background: > > The current RFC3012 text says that an FA MAY include a new challenge in > any registration reply, successful or not. > > At least one current implementation accordingly does not return a > challenge with the registration reply when the registration attempt for > some reason is unsuccessful (could be a timestamp mismatch with the HA, > or some other rectifiable issue with the first registration request). > > At least one other current implementation expect an unsuccessful > registration reply to provide a new challenge (as the challenge used in > the previous registration request cannot be used again, and may have > been taken from the most recent unsolicited agent advertisement). > > In this situation, these two implementations, which both follow the > current RFC 3012, deadlock and never can reach a successful > registration. The client should NOT deadlock. It should be able to use the next advertised (unsolicited) challenge. > The implementation which does not supply a new challenge with an > unsuccessful registration reply expects an advertisement solicitation, > and will provide a fresh challenge in this case, but whether a fresh > challenge or a repeat of the most recent unsolicited multicast > challenge should be provided in a solicited advertisement is also not > specified in the current document text. Either one should work, presumably...(?) > The discussions around this subject also brought to light a number > of denial of service attacks which would be possible with certain > ways of resolving the issues above. I saw the one about how a client could "use" the unsolicited advertisements, BUT the foreign agent should not be fooled. In fact, a challenge used by one mobile node should still be able to be used by another mobile node (with a different IP address). So, this does not seem like a very potent threat. > Here are proposed text changes for 3012bis, to ensure this deadlock > does not occur, and to prevent more grave denial of service attacks > than could occur in a non-3012bis situation. The text has been taken > from explicit text proposals and from the discussion notes when no > explicit text has been provided earlier. But what if there isn't a deadlock situation? > Proposed text: I'll look at this next! Regards, Charlie P. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 20:06:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16752 for ; Tue, 19 Aug 2003 20:06:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUL-0001yq-Jo for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K069Yo007607 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUL-0001ya-6C for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 20:06: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 UAA16570 for ; Tue, 19 Aug 2003 20:06:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pGUJ-0001pQ-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 20:06:07 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pGUI-0001pN-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 20:06:06 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUG-0001vA-6W; Tue, 19 Aug 2003 20:06:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pF68-0007WG-P2 for mip4@optimus.ietf.org; Tue, 19 Aug 2003 18:37:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13531 for ; Tue, 19 Aug 2003 18:36:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pF65-00015e-00 for mip4@ietf.org; Tue, 19 Aug 2003 18:37:01 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19pF64-00015M-00 for mip4@ietf.org; Tue, 19 Aug 2003 18:37:00 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7JMZwe30378; Tue, 19 Aug 2003 15:35:58 -0700 X-mProtect: <200308192235> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdAfYQ2a; Tue, 19 Aug 2003 15:35:56 PDT Message-ID: <3F42A64D.BA9A067D@iprg.nokia.com> Date: Tue, 19 Aug 2003 15:35:57 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. References: <20030813103506.3f0c4305.henrik@levkowetz.com> 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 Hello again folks, > Proposed text: > > - Add at the end of section 2 (as Section 2.1) - or as section 3.6 > > 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. > However, a foreign agent which provides challenge handling according > to this document is restricted to only respond with unicast agent > advertisements in response to a router solicitation. This seems O.K. > The agent advertisement which is unicast back to the soliciting > mobile node MUST be handled as follows: A new Challenge value MUST > be re-generated periodically and remembered as the most recent > challenge issued to the mobile node. It is RECOMMENDED that this > period be on the order of 60 seconds. If the challenge most recently > issued to the soliciting mobile node has not been previously used > (as defined in Section 1.1), and the re-generation period has not > elapsed, the most recent challenge unicast to the mobile node > through a registration reply or a unicast agent advertisement SHOULD > be repeated in the newly issued unicast agent advertisement. (For > further discussion of this, see Section 12.) I don't understand the need for the periodic regeneration. Perhaps this is because I didn't follow all the previous discussion, but it seems to me that the mobile can retransmit its solicitation if it didn't get a challenge, and I can't think of any other reason for the periodic advertisement to be unicasted. > - 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. Looks O.K. > - In section 3.3, change > > From: > The Foreign Agent SHOULD include a new Mobile-Foreign Challenge > Extension in any Registration Reply, successful or not. If the > foreign agent includes this extension in a successful Registration > Reply, the extension SHOULD precede a Mobile-Foreign authentication > extension. Suppose the ... > > To: > A Foreign Agent which provides challenge handling according to this > document MUST include a previously unused Mobile-Foreign Challenge > Extension in any Registration Reply, successful or not. If the > foreign agent includes this extension in a successful Registration > Reply, the extension SHOULD precede a Mobile-Foreign authentication > extension. I don't understand why this is. It would be especially unneeded if, for instance, the foreign agent had just sent a multicast Challenge value a few milliseconds earlier. > If the challenge most recently issued to the soliciting mobile node > has not been previously used (as defined in Section 1.1), and the > re-generation period (as described in section 2.1) has not elapsed, > the most recent challenge unicast to the mobile node through a > registration reply or a unicast agent advertisement SHOULD be > repeated in the registration reply. Here, again, I fail to see the point of the regeneration period. I hope someone won't mind educating me about it. > - Add the following at the end of Section 12: > > Note that an active attacker may try to prevent successful > registrations by sending a large number of Agent Solicitations or > bogus Registration Requests, each of which could cause the FA to > respond with a fresh challenge, invalidating the challenge that the > MN is currently trying to use. To prevent such attacks, the FA > SHOULD repeat the same challenge value in successive unicast > responses to Agent Solicitations or in Registration Replies to > Requests that did not contain valid MN-AAA or MN-FA authentication > extensions for some limited period of time (on the order of 60 > seconds). Note that each challenge returned to an MN MUST be > previously unused by that MN. Even better if the foreign agent allows more than one mobile node to use the same challenge value. Why not? > - In Appendix E, change the second paragraph > > From: > > In the program fragment, it is presumed that the foreign agent > keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a > record of the last advertised challenge used by a mobile node, and > also a record of the last challenge provided to a mobile node in a > Registration Reply. > > To: > > In the program fragment, it is presumed that the foreign agent keeps > an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record > of the last advertised challenge used by a mobile node, and also a > record of the last challenge provided to a mobile node in a > Registration Reply or unicast Agent Advertisement. This seems O.K. Regards, Charlie P. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 20:06:47 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 UAA16846 for ; Tue, 19 Aug 2003 20:06:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUW-0002A8-ON for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K06KKs008294 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUW-00029b-Gy for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 20:06: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 UAA16628 for ; Tue, 19 Aug 2003 20:06:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pGUU-0001qe-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 20:06:18 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pGUU-0001qN-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 20:06:18 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUR-00024d-V4; Tue, 19 Aug 2003 20:06:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pFiZ-0000TI-1Y for mip4@optimus.ietf.org; Tue, 19 Aug 2003 19:16:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15294 for ; Tue, 19 Aug 2003 19:16:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pFiX-0001U4-00 for mip4@ietf.org; Tue, 19 Aug 2003 19:16:45 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx with esmtp (Exim 4.12) id 19pFiV-0001TY-00 for mip4@ietf.org; Tue, 19 Aug 2003 19:16:44 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h7JNFbB09546; Tue, 19 Aug 2003 16:15:37 -0700 X-mProtect: <200308192315> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpduwZsJ8; Tue, 19 Aug 2003 16:15:35 PDT Message-ID: <3F42AF98.FBE79C18@iprg.nokia.com> Date: Tue, 19 Aug 2003 16:15:36 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Henrik Levkowetz CC: mip4@ietf.org Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. References: <20030813103506.3f0c4305.henrik@levkowetz.com> <3F42A139.496CFF3D@iprg.nokia.com> <20030820004939.4ba37265.henrik@levkowetz.com> 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 Hello Henrik, Henrik Levkowetz wrote: > > > In this situation, these two implementations, which both follow the > > > current RFC 3012, deadlock and never can reach a successful > > > registration. > > > > The client should NOT deadlock. It should be able to > > use the next advertised (unsolicited) challenge. > > Seems reasonable (although not explicitly described in 3012). Is it needed to specify that a client MUST be able to receive a multicast solicitation even though it has received a Registration Reply message...? > Obviously, we want sane > implementations of both unicast solicited advertisements and multicast > solicited advertisements (if we want to keep both kinds), so the goal of > the text clarifications which has been proposed and discussed is just > that. I'm happy with clarifications, but I'd prefer not to create additional restrictions except where they're needed. Aren't both kinds of advertisements useful? In fact, originally there was only the multicast variety, but the unicast registration extensions seemed pretty handy... > One of the more disadvantageous implementations would be one where a > solicitation resulted in the generation of a new (multicast) challenge, > which would take the most recent slot of the CHALLENGE_WINDOW remembered > challenges. The lifetime of any challenge could then be severely reduced > by a malicious node soliciting with a high frequency. That would be bad. In fact, I think it would be reasonable to specify an upper limit on the frequency of multicast advertisements, not more than a few each second. > Another disadvantageous implementation would be to respond with unicast > solicited advertisements with a fresh challenge, treated in the same > manner as challenges returned to individual nodes in registration > replies. As there is only one valid such challenge remembered for each > individual node, a rogue node would then at any time be able to solicit > for a new advertisement, which would make any challenge individually > provided to the proper node earlier forgotten, i.e. invalid. This should be allowed, certainly, but not mandated. The problem is that we have to avoid making the foreign agent work "too hard" when generating good random numbers. It's not trivial in terms of processing requirement. >>> Here are proposed text changes for 3012bis, to ensure this deadlock >>> does not occur ........... > >> But what if there isn't a deadlock situation? > > Well, we observed one... Was it different than the situation described above? But then I thought you agreed that the deadlock shouldn't occur...(?) Regards, Charlie P. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 20:07:00 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 UAA16992 for ; Tue, 19 Aug 2003 20:06: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 19pGUj-0002JY-Hc for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:33 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K06XCJ008890 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUj-0002JF-By for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 20:06:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16717 for ; Tue, 19 Aug 2003 20:06:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pGUh-0001s4-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 20:06:31 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pGUg-0001pR-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 20:06:30 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUK-0001xn-Am; Tue, 19 Aug 2003 20:06:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pFIh-0007yZ-3i for mip4@optimus.ietf.org; Tue, 19 Aug 2003 18:50: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 SAA14195 for ; Tue, 19 Aug 2003 18:49:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pFId-0001D7-00 for mip4@ietf.org; Tue, 19 Aug 2003 18:49:59 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19pFId-0001Cm-00 for mip4@ietf.org; Tue, 19 Aug 2003 18:49:59 -0400 Received: (qmail 25923 invoked from network); 19 Aug 2003 22:49:39 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 19 Aug 2003 22:49:39 -0000 Date: Wed, 20 Aug 2003 00:49:39 +0200 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. Message-Id: <20030820004939.4ba37265.henrik@levkowetz.com> In-Reply-To: <3F42A139.496CFF3D@iprg.nokia.com> References: <20030813103506.3f0c4305.henrik@levkowetz.com> <3F42A139.496CFF3D@iprg.nokia.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 Tuesday 19 August 2003, Charles wrote: > Henrik Levkowetz wrote: > > > Background: > > > > The current RFC3012 text says that an FA MAY include a new challenge in > > any registration reply, successful or not. > > > > At least one current implementation accordingly does not return a > > challenge with the registration reply when the registration attempt for > > some reason is unsuccessful (could be a timestamp mismatch with the HA, > > or some other rectifiable issue with the first registration request). > > > > At least one other current implementation expect an unsuccessful > > registration reply to provide a new challenge (as the challenge used in > > the previous registration request cannot be used again, and may have > > been taken from the most recent unsolicited agent advertisement). > > > > In this situation, these two implementations, which both follow the > > current RFC 3012, deadlock and never can reach a successful > > registration. > > The client should NOT deadlock. It should be able to > use the next advertised (unsolicited) challenge. Seems reasonable (although not explicitly described in 3012). > > The implementation which does not supply a new challenge with an > > unsuccessful registration reply expects an advertisement solicitation, > > and will provide a fresh challenge in this case, but whether a fresh > > challenge or a repeat of the most recent unsolicited multicast > > challenge should be provided in a solicited advertisement is also not > > specified in the current document text. > > Either one should work, presumably...(?) Either one would work for the client, but there are different pros and cons, with some of the cons being rather disadvantageous, as discussed earlier. > > The discussions around this subject also brought to light a number > > of denial of service attacks which would be possible with certain > > ways of resolving the issues above. > > I saw the one about how a client could "use" the unsolicited > advertisements, BUT the foreign agent should not be fooled. > In fact, a challenge used by one mobile node should still be > able to be used by another mobile node (with a different IP > address). So, this does not seem like a very potent threat. This is true for certain possible implementations of solicited advertisements, but not for others. Obviously, we want sane implementations of both unicast solicited advertisements and multicast solicited advertisements (if we want to keep both kinds), so the goal of the text clarifications which has been proposed and discussed is just that. One of the more disadvantageous implementations would be one where a solicitation resulted in the generation of a new (multicast) challenge, which would take the most recent slot of the CHALLENGE_WINDOW remembered challenges. The lifetime of any challenge could then be severely reduced by a malicious node soliciting with a high frequency. Another disadvantageous implementation would be to respond with unicast solicited advertisements with a fresh challenge, treated in the same manner as challenges returned to individual nodes in registration replies. As there is only one valid such challenge remembered for each individual node, a rogue node would then at any time be able to solicit for a new advertisement, which would make any challenge individually provided to the proper node earlier forgotten, i.e. invalid. > > Here are proposed text changes for 3012bis, to ensure this deadlock > > does not occur, and to prevent more grave denial of service attacks > > than could occur in a non-3012bis situation. The text has been taken > > from explicit text proposals and from the discussion notes when no > > explicit text has been provided earlier. > > But what if there isn't a deadlock situation? Well, we observed one... > > Proposed text: > > I'll look at this next! Right-o. Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 20:07:17 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 UAA17062 for ; Tue, 19 Aug 2003 20:07:17 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGV0-0002Oq-Sj for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K06oxi009219 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGV0-0002Oc-NI for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 20:06:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16740 for ; Tue, 19 Aug 2003 20:06:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pGUm-0001sc-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 20:06:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pGUk-0001py-00 for mip4-web-archive@ietf.org; Tue, 19 Aug 2003 20:06:34 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUO-00022G-Cz; Tue, 19 Aug 2003 20:06:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pFaz-0000LS-B6 for mip4@optimus.ietf.org; Tue, 19 Aug 2003 19:08:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14784 for ; Tue, 19 Aug 2003 19:08:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pFaw-0001Lk-00 for mip4@ietf.org; Tue, 19 Aug 2003 19:08:54 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19pFav-0001LE-00 for mip4@ietf.org; Tue, 19 Aug 2003 19:08:53 -0400 Received: (qmail 25988 invoked from network); 19 Aug 2003 23:08:40 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 19 Aug 2003 23:08:40 -0000 Date: Wed, 20 Aug 2003 01:08:40 +0200 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. Message-Id: <20030820010840.33d169eb.henrik@levkowetz.com> In-Reply-To: <3F42A64D.BA9A067D@iprg.nokia.com> References: <20030813103506.3f0c4305.henrik@levkowetz.com> <3F42A64D.BA9A067D@iprg.nokia.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 Charles, Responding to the particular points where you had further comments: Tuesday 19 August 2003, Charles wrote: > Hello again folks, [...] > > > The agent advertisement which is unicast back to the soliciting > > mobile node MUST be handled as follows: A new Challenge value MUST > > be re-generated periodically and remembered as the most recent > > challenge issued to the mobile node. It is RECOMMENDED that this > > period be on the order of 60 seconds. If the challenge most recently > > issued to the soliciting mobile node has not been previously used > > (as defined in Section 1.1), and the re-generation period has not > > elapsed, the most recent challenge unicast to the mobile node > > through a registration reply or a unicast agent advertisement SHOULD > > be repeated in the newly issued unicast agent advertisement. (For > > further discussion of this, see Section 12.) > > I don't understand the need for the periodic regeneration. Perhaps > this is because I didn't follow all the previous discussion, but > it seems to me that the mobile can retransmit its solicitation if > it didn't get a challenge, and I can't think of any other reason for > the periodic advertisement to be unicasted. Some other people also had objections to the periodic regeneration. It would only be necessary if the FA and mobile node had conflicting ideas about the validity of a challenge, and even then there would be the option of waiting for the next multicast advertisement. My impression is that we should skip the regeneration. [...] > > > - In section 3.3, change > > > > From: > > The Foreign Agent SHOULD include a new Mobile-Foreign Challenge > > Extension in any Registration Reply, successful or not. If the > > foreign agent includes this extension in a successful Registration > > Reply, the extension SHOULD precede a Mobile-Foreign authentication > > extension. Suppose the ... > > > > To: > > A Foreign Agent which provides challenge handling according to this > > document MUST include a previously unused Mobile-Foreign Challenge > > Extension in any Registration Reply, successful or not. If the > > foreign agent includes this extension in a successful Registration > > Reply, the extension SHOULD precede a Mobile-Foreign authentication > > extension. > > I don't understand why this is. It would be especially unneeded if, > for instance, the foreign agent had just sent a multicast Challenge value > a few milliseconds earlier. Yes. But then we will have to specify under which circumstances one could omit returning a new challenge in a registration reply. The current text has resulted in at least one implementation which never return a new challenge with an unsuccessful registration reply, which was one component in the observed deadlock. > > If the challenge most recently issued to the soliciting mobile node > > has not been previously used (as defined in Section 1.1), and the > > re-generation period (as described in section 2.1) has not elapsed, > > the most recent challenge unicast to the mobile node through a > > registration reply or a unicast agent advertisement SHOULD be > > repeated in the registration reply. > > Here, again, I fail to see the point of the regeneration period. > I hope someone won't mind educating me about it. As indicated above, we don't really need it and it seems we don't have consensus on it. > > - Add the following at the end of Section 12: > > > > Note that an active attacker may try to prevent successful > > registrations by sending a large number of Agent Solicitations or > > bogus Registration Requests, each of which could cause the FA to > > respond with a fresh challenge, invalidating the challenge that the > > MN is currently trying to use. To prevent such attacks, the FA > > SHOULD repeat the same challenge value in successive unicast > > responses to Agent Solicitations or in Registration Replies to > > Requests that did not contain valid MN-AAA or MN-FA authentication > > extensions for some limited period of time (on the order of 60 > > seconds). Note that each challenge returned to an MN MUST be > > previously unused by that MN. > > Even better if the foreign agent allows more than one mobile node > to use the same challenge value. Why not? This is the case with multicast challenges, of course. But currently we only require the FA to remember one individual challenge per mobile node, and if an impostor has the ability to invalidate that one (by causing it to be replaced by a newer one) it has blocked the mobile from succeeding in its next registration attempt. Regards, Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Tue Aug 19 20:07:20 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 UAA17092 for ; Tue, 19 Aug 2003 20:07:20 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGV4-0002Q9-2V for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:54 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7K06sEw009299 for mip4-archive@odin.ietf.org; Tue, 19 Aug 2003 20:06:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGV3-0002Pu-Uh for mip4-web-archive@optimus.ietf.org; Tue, 19 Aug 2003 20:06:53 -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 UAA16898 for ; Tue, 19 Aug 2003 20:06:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGUZ-0002CT-HX; Tue, 19 Aug 2003 20:06:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pGAY-0001SN-Jp for mip4@optimus.ietf.org; Tue, 19 Aug 2003 19:45: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 TAA15970 for ; Tue, 19 Aug 2003 19:45:38 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pGAU-0001fC-00 for mip4@ietf.org; Tue, 19 Aug 2003 19:45:38 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19pGAS-0001en-00 for mip4@ietf.org; Tue, 19 Aug 2003 19:45:37 -0400 Received: (qmail 26230 invoked from network); 19 Aug 2003 23:45:22 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 19 Aug 2003 23:45:22 -0000 Date: Wed, 20 Aug 2003 01:45:22 +0200 From: Henrik Levkowetz To: "Charles E. Perkins" Cc: mip4@ietf.org Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. Message-Id: <20030820014522.6456f8c9.henrik@levkowetz.com> In-Reply-To: <3F42AF98.FBE79C18@iprg.nokia.com> References: <20030813103506.3f0c4305.henrik@levkowetz.com> <3F42A139.496CFF3D@iprg.nokia.com> <20030820004939.4ba37265.henrik@levkowetz.com> <3F42AF98.FBE79C18@iprg.nokia.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 Charles, Tuesday 19 August 2003, Charles wrote: > > Hello Henrik, > > Henrik Levkowetz wrote: > > > > > In this situation, these two implementations, which both follow the > > > > current RFC 3012, deadlock and never can reach a successful > > > > registration. > > > > > > The client should NOT deadlock. It should be able to > > > use the next advertised (unsolicited) challenge. > > > > Seems reasonable (although not explicitly described in 3012). > > Is it needed to specify that a client MUST be able to receive > a multicast solicitation even though it has received a Registration > Reply message...? ,:-] Apparently it might be needed to specify something like that... > > > Obviously, we want sane > > implementations of both unicast solicited advertisements and multicast > > solicited advertisements (if we want to keep both kinds), so the goal of > > the text clarifications which has been proposed and discussed is just > > that. > > I'm happy with clarifications, but I'd prefer not to create > additional restrictions except where they're needed. Aren't both > kinds of advertisements useful? In fact, originally there was > only the multicast variety, but the unicast registration extensions > seemed pretty handy... Yes, I think both are useful. We just have to make sure that we don't get bad implementations out there. The original impetus for my postings on this subject was to get solicited advertisements specified, for this reason. > > One of the more disadvantageous implementations would be one where a > > solicitation resulted in the generation of a new (multicast) challenge, > > which would take the most recent slot of the CHALLENGE_WINDOW remembered > > challenges. The lifetime of any challenge could then be severely reduced > > by a malicious node soliciting with a high frequency. > > That would be bad. In fact, I think it would be reasonable to > specify an upper limit on the frequency of multicast advertisements, > not more than a few each second. I could go with that - although I guess my idea of a few might be as many as 50 or so, as a rough guess. > > Another disadvantageous implementation would be to respond with unicast > > solicited advertisements with a fresh challenge, treated in the same > > manner as challenges returned to individual nodes in registration > > replies. As there is only one valid such challenge remembered for each > > individual node, a rogue node would then at any time be able to solicit > > for a new advertisement, which would make any challenge individually > > provided to the proper node earlier forgotten, i.e. invalid. > > This should be allowed, certainly, but not mandated. The problem is > that we have to avoid making the foreign agent work "too hard" when > generating good random numbers. It's not trivial in terms of processing > requirement. Ok on the processing requirements. Our proposal for handling this situation (as manifested in the text proposals) is simply to not calculate new individual challenges as long as there is an unused challenge available for the node. In that situation we would rather repeat that challenge. > >>> Here are proposed text changes for 3012bis, to ensure this deadlock > >>> does not occur ........... > > > >> But what if there isn't a deadlock situation? > > > > Well, we observed one... > > Was it different than the situation described above? But then > I thought you agreed that the deadlock shouldn't occur...(?) Shouldn't, but did. It was as described in the summary, and prompted, rather than completely encompassed, the solicited advertisement issues discussed later. Regards, Henrik _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 06:44: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 GAA03249 for ; Wed, 20 Aug 2003 06:44: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 19pQRf-0006Ky-FJ for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 06:44:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KAi3iA024355 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 06:44:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQRf-0006Kk-Bh for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 06:44: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 GAA03236 for ; Wed, 20 Aug 2003 06:43:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQRb-0007Cs-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 06:43:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pQRa-0007Cp-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 06:43:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQRc-0006J3-Md; Wed, 20 Aug 2003 06:44:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQR0-0006IQ-EJ for mip4@optimus.ietf.org; Wed, 20 Aug 2003 06:43:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03206 for ; Wed, 20 Aug 2003 06:43:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQQw-0007C6-00 for Mip4@ietf.org; Wed, 20 Aug 2003 06:43:18 -0400 Received: from eggplant.propagation.net ([63.249.173.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQQv-0007C3-00 for Mip4@ietf.org; Wed, 20 Aug 2003 06:43:17 -0400 Received: from localhost (localhost) by eggplant.propagation.net (8.9.3p2/8.8.5) with internal id FAA22131; Wed, 20 Aug 2003 05:40:10 -0500 Date: Wed, 20 Aug 2003 05:40:10 -0500 From: Mail Delivery Subsystem Message-Id: <200308201040.FAA22131@eggplant.propagation.net> To: Mip4@ietf.org MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="FAA22131.1061376010/eggplant.propagation.net" Auto-Submitted: auto-generated (failure) Subject: [Mip4] Returned mail: Can't create output Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a MIME-encapsulated message --FAA22131.1061376010/eggplant.propagation.net The original message was received at Wed, 20 Aug 2003 05:40:10 -0500 from mail@localhost ----- The following addresses had permanent fatal errors ----- usabilitysciences@usabilitysciences.com ----- Transcript of session follows ----- procmail: Quota exceeded while writing "/var/spool/mail/usabilitysciences" 550 usabilitysciences@usabilitysciences.com... Can't create output --FAA22131.1061376010/eggplant.propagation.net Content-Type: message/delivery-status Reporting-MTA: dns; eggplant.propagation.net Arrival-Date: Wed, 20 Aug 2003 05:40:10 -0500 Final-Recipient: RFC822; usabilitysciences@usabilitysciences.com Action: failed Status: 5.3.0 Last-Attempt-Date: Wed, 20 Aug 2003 05:40:10 -0500 --FAA22131.1061376010/eggplant.propagation.net Content-Type: message/rfc822 Return-Path: Received: (from mail@localhost) by eggplant.propagation.net (8.9.3p2/8.8.5) id FAA22115 for usabilitysciences@usabilitysciences.com; Wed, 20 Aug 2003 05:40:10 -0500 From: Mip4@ietf.org Received: from HALIPE (as11-2-6.sto.s.bonet.se [217.215.164.169]) by eggplant.propagation.net (8.9.3p2/8.8.5) with ESMTP id FAA21892 for ; Wed, 20 Aug 2003 05:39:59 -0500 Message-Id: <200308201039.FAA21892@eggplant.propagation.net> To: Subject: Re: Thank you! Date: Wed, 20 Aug 2003 12:42:51 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_002CD5D5" This is a multipart message in MIME format --_NextPart_000_002CD5D5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_002CD5D5 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_002CD5D5-- --_NextPart_000_002CD5D5-- --FAA22131.1061376010/eggplant.propagation.net-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 06:50: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 GAA03515 for ; Wed, 20 Aug 2003 06:50: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 19pQXT-0006ZT-M0 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 06:50:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KAo3R2025255 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 06:50:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQXT-0006ZG-IH for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 06:50: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 GAA03490 for ; Wed, 20 Aug 2003 06:49:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQXP-0007GK-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 06:49:59 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pQXO-0007GH-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 06:49:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQXR-0006Xk-QX; Wed, 20 Aug 2003 06:50:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pQXE-0006X9-SZ for mip4@optimus.ietf.org; Wed, 20 Aug 2003 06:49:48 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03477 for ; Wed, 20 Aug 2003 06:49:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pQXA-0007G2-00 for mip4@ietf.org; Wed, 20 Aug 2003 06:49:44 -0400 Received: from omr-d05.mx.aol.com ([205.188.156.66]) by ietf-mx with esmtp (Exim 4.12) id 19pQXA-0007Fe-00 for mip4@ietf.org; Wed, 20 Aug 2003 06:49:44 -0400 Received: from rly-xn05.mx.aol.com (rly-xn05.mail.aol.com [172.20.83.138]) by omr-d05.mx.aol.com (v90_r2.6) with ESMTP id RELAYIN1-0820064859; Wed, 20 Aug 2003 06:48:59 -0400 Received: from localhost (localhost) by rly-xn05.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with internal id GAC15180; Wed, 20 Aug 2003 06:48:59 -0400 (EDT) Date: Wed, 20 Aug 2003 06:48:59 -0400 (EDT) From: Mail Delivery Subsystem Message-Id: <200308201048.GAC15180@rly-xn05.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="GAC15180.1061376539/rly-xn05.mx.aol.com" Auto-Submitted: auto-generated (failure) Subject: [Mip4] Returned mail: User unknown Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a MIME-encapsulated message --GAC15180.1061376539/rly-xn05.mx.aol.com The original message was received at Wed, 20 Aug 2003 06:48:29 -0400 (EDT) from as11-2-6.sto.s.bonet.se [217.215.164.169] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to air-xn03.mail.aol.com.: >>> RCPT To: <<< 550 MAILBOX NOT FOUND 550 ... User unknown --GAC15180.1061376539/rly-xn05.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-xn05.mx.aol.com Arrival-Date: Wed, 20 Aug 2003 06:48:29 -0400 (EDT) Final-Recipient: RFC822; shtabmdr@aol.com Action: failed Status: 5.1.1 Remote-MTA: DNS; air-xn03.mail.aol.com Diagnostic-Code: SMTP; 550 MAILBOX NOT FOUND Last-Attempt-Date: Wed, 20 Aug 2003 06:48:59 -0400 (EDT) --GAC15180.1061376539/rly-xn05.mx.aol.com Content-Type: text/rfc822-headers Received: from HALIPE (as11-2-6.sto.s.bonet.se [217.215.164.169]) by rly-xn05.mx.aol.com (v95.1) with ESMTP id MAILRELAYINXN58-6523f4351ee342; Wed, 20 Aug 2003 06:48:15 -0400 From: To: Subject: Re: Details Date: Wed, 20 Aug 2003 12:47:59 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0031889D" X-AOL-IP: 217.215.164.169 X-AOL-SCOLL-SCORE: 0:XXX:XX X-AOL-SCOLL-URL_COUNT: 0 Message-ID: <200308200648.6523f4351ee342@rly-xn05.mx.aol.com> --GAC15180.1061376539/rly-xn05.mx.aol.com-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 08:38: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 IAA06606 for ; Wed, 20 Aug 2003 08: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 19pSDx-0002iQ-Ve for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 08:38:02 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KCc1Fr010432 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 08: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 19pSDx-0002iB-SN for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 08:38: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 IAA06594 for ; Wed, 20 Aug 2003 08:37:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pSDw-0000IX-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 08:38:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pSDw-0000IU-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 08:38:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pSDw-0002hw-C0; Wed, 20 Aug 2003 08: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 19pSD0-0002Ox-RU for mip4@optimus.ietf.org; Wed, 20 Aug 2003 08:37: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 IAA06587 for ; Wed, 20 Aug 2003 08:36:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pSCz-0000IJ-00 for mip4@ietf.org; Wed, 20 Aug 2003 08:37:01 -0400 Received: from fmx3.freemail.hu ([195.228.242.223]) by ietf-mx with smtp (Exim 4.12) id 19pSCy-0000I3-00 for mip4@ietf.org; Wed, 20 Aug 2003 08:37:01 -0400 Received: (qmail 81688 invoked for bounce); 20 Aug 2003 14:06:30 +0200 Date: 20 Aug 2003 14:06:30 +0200 From: MAILER-DAEMON@freemail.hu To: mip4@ietf.org Message-Id: Subject: [Mip4] failure notice Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Hi. This is the qmail-send program at freemail.hu. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : Sorry, no mailbox here by that name. (#5.1.1) --- Below this line is a copy of the message. Return-Path: Received: (qmail 90843 invoked from network); 20 Aug 2003 13:37:26 +0200 Return-Path:<> From:mip4@ietf.org To:krychek@freemail.hu Date:Wed Aug 20 13:37:26 2003 Subject:Virusveszely! Virus warning! MIME-Version:1.0 Content-Type:multipart/mixed; boundary="=NEXT=AVPCHECK=2003=232=1061379446=90324=1=" This is a MIME-encapsulated message --=NEXT=AVPCHECK=2003=232=1061379446=90324=1= Content-Type:text/plain Content-Transfer-Encoding:US-ASCII A(z) mip4@ietf.org cimrol Onnek kuldott level virust tartalmaz. The email message you have received from mip4@ietf.org contains virus. --------------------------------------------------------- packed: PE_Patch packed: TeLock infected: I-Worm.Sobig.f I/O error. I/O error. deleted: I-Worm.Sobig.f --------------------------------------------------------- --=NEXT=AVPCHECK=2003=232=1061379446=90324=1= Content-Type:message/rfc822; Content-Transfer-Encoding:8bit Received: from as11-2-6.sto.s.bonet.se (HELO HALIPE) (217.215.164.169) by fmx3.freemail.hu with SMTP; 20 Aug 2003 13:37:19 +0200 From: To: Subject: Re: Your application Date: Wed, 20 Aug 2003 13:37:03 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_005E76F9" This is a multipart message in MIME format --_NextPart_000_005E76F9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_005E76F9 Content-Type: application/octet-stream; name="document_9446.pif" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="document_9446.pif" --_NextPart_000_005E76F9-- --=NEXT=AVPCHECK=2003=232=1061379446=90324=1=-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 11:03:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12502 for ; Wed, 20 Aug 2003 11:03:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUUJ-0008Qw-GR for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:03:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KF33e7032418 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUUJ-0008Qn-9I for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 11:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12492 for ; Wed, 20 Aug 2003 11:02:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUUG-0001eE-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:03:00 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pUUG-0001e9-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUUH-0008QH-7Y; Wed, 20 Aug 2003 11:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUU0-0008PW-Fx for mip4@optimus.ietf.org; Wed, 20 Aug 2003 11:02:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12468 for ; Wed, 20 Aug 2003 11:02:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUTx-0001dm-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:02:41 -0400 Received: from omr-m07.mx.aol.com ([64.12.138.19]) by ietf-mx with esmtp (Exim 4.12) id 19pUTx-0001dX-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:02:41 -0400 Received: from rly-xb01.mx.aol.com (rly-xb01.mail.aol.com [172.20.105.102]) by omr-m07.mx.aol.com (v90_r2.6) with ESMTP id RELAYIN9-0820110155; Wed, 20 Aug 2003 11:01:55 -0400 Received: from localhost (localhost) by rly-xb01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with internal id LAE20636; Wed, 20 Aug 2003 11:01:55 -0400 (EDT) Date: Wed, 20 Aug 2003 11:01:55 -0400 (EDT) From: Mail Delivery Subsystem Message-Id: <200308201501.LAE20636@rly-xb01.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="LAE20636.1061391715/rly-xb01.mx.aol.com" Auto-Submitted: auto-generated (failure) Subject: [Mip4] Returned mail: User unknown Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a MIME-encapsulated message --LAE20636.1061391715/rly-xb01.mx.aol.com The original message was received at Wed, 20 Aug 2003 11:01:39 -0400 (EDT) from as11-2-6.sto.s.bonet.se [217.215.164.169] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to air-xb03.mail.aol.com.: >>> RCPT To: <<< 550 MAILBOX NOT FOUND 550 ... User unknown --LAE20636.1061391715/rly-xb01.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-xb01.mx.aol.com Arrival-Date: Wed, 20 Aug 2003 11:01:39 -0400 (EDT) Final-Recipient: RFC822; macmaninfi@aol.com Action: failed Status: 5.1.1 Remote-MTA: DNS; air-xb03.mail.aol.com Diagnostic-Code: SMTP; 550 MAILBOX NOT FOUND Last-Attempt-Date: Wed, 20 Aug 2003 11:01:55 -0400 (EDT) --LAE20636.1061391715/rly-xb01.mx.aol.com Content-Type: text/rfc822-headers Received: from HALIPE (as11-2-6.sto.s.bonet.se [217.215.164.169]) by rly-xb01.mx.aol.com (v95.1) with ESMTP id MAILRELAYINXB16-883f438d4d84; Wed, 20 Aug 2003 11:01:34 -0400 From: To: Subject: Re: Wicked screensaver Date: Wed, 20 Aug 2003 17:01:18 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_01197400" X-AOL-IP: 217.215.164.169 X-AOL-SCOLL-SCORE: 0:XXX:XX X-AOL-SCOLL-URL_COUNT: 0 Message-ID: <200308201101.883f438d4d84@rly-xb01.mx.aol.com> --LAE20636.1061391715/rly-xb01.mx.aol.com-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 11:12:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13231 for ; Wed, 20 Aug 2003 11:12:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUcx-0000sk-MS for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:12:00 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFBxrT003384 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUcx-0000sV-Ho for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 11:11:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13201 for ; Wed, 20 Aug 2003 11:11:53 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUcw-0001mI-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:11:58 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pUcw-0001mF-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:11:58 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUcw-0000rA-Bi; Wed, 20 Aug 2003 11:11:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUcH-0000od-Hc for mip4@optimus.ietf.org; Wed, 20 Aug 2003 11:11: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 LAA13110 for ; Wed, 20 Aug 2003 11:11:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUcE-0001kr-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:11:14 -0400 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 19pUcD-0001kk-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:11:13 -0400 Received: from frmail35.netfr.alcatel.fr (frmail35.netfr.alcatel.fr [155.132.251.35]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id h7KFB4PT019928 for ; Wed, 20 Aug 2003 17:11:04 +0200 Received: from alcatel.fr ([172.25.73.32]) by frmail35.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2003082017110162:2337 ; Wed, 20 Aug 2003 17:11:01 +0200 Message-ID: <3F438F86.9080606@alcatel.fr> Date: Wed, 20 Aug 2003 17:11:02 +0200 From: Bertrand.Lapraye@alcatel.fr User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org X-MIMETrack: Itemize by SMTP Server on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 08/20/2003 17:11:01, Serialize by Router on FRMAIL35/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 08/20/2003 17:11:03, Serialize complete at 08/20/2003 17:11:03 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Virus-Scanned: by amavisd-new Content-Transfer-Encoding: 7bit Subject: [Mip4] several irrelevent mails received. Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi All, Sorry to pollute the list but I receive from this morning some irrelevent mails coming from aol.om domain and apparently send to mip4 mailing list . Is that a global pb or local ? Thanks. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 11:15: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 LAA13324 for ; Wed, 20 Aug 2003 11:15: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 19pUfu-00010q-Sw for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:15:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFF20X003883 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:15:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUfu-00010W-Cc for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 11:15: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 LAA13311 for ; Wed, 20 Aug 2003 11:14:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUft-0001oP-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:15:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pUfs-0001oM-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:15:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUfs-0000zB-VP; Wed, 20 Aug 2003 11:15:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUfI-0000yJ-Oy for mip4@optimus.ietf.org; Wed, 20 Aug 2003 11:14:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13285 for ; Wed, 20 Aug 2003 11:14:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUfH-0001ny-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:14:23 -0400 Received: from maile.telia.com ([194.22.190.16]) by ietf-mx with esmtp (Exim 4.12) id 19pUfD-0001nv-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:14:20 -0400 Received: from d1o881.telia.com (d1o881.telia.com [213.66.156.241]) by maile.telia.com (8.12.9/8.12.9) with ESMTP id h7KFEIl0012787 for ; Wed, 20 Aug 2003 17:14:18 +0200 (CEST) X-Original-Recipient: Received: from localhost (localhost) by d1o881.telia.com (8.10.2p2/8.10.1) id h7KFEHb13045; Wed, 20 Aug 2003 17:14:17 +0200 (CEST) Date: Wed, 20 Aug 2003 17:14:17 +0200 (CEST) From: Mail Delivery Subsystem Message-Id: <200308201514.h7KFEHb13045@d1o881.telia.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="h7KFEHb13045.1061392457/d1o881.telia.com" Auto-Submitted: auto-generated (failure) Subject: [Mip4] Returned mail: see transcript for details Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a MIME-encapsulated message --h7KFEHb13045.1061392457/d1o881.telia.com The original message was received at Wed, 20 Aug 2003 17:14:17 +0200 (CEST) from mailf.telia.com [194.22.194.25] ----- The following addresses had permanent fatal errors ----- (reason: service unavailable) ----- Transcript of session follows ----- Your e-mail to <> has not been delivered. The receiver's mailbox is full. When the mailbox has been emptied you will be able to resend this e-mail. 554 5.0.0 ... Service unavailable --h7KFEHb13045.1061392457/d1o881.telia.com Content-Type: message/delivery-status Reporting-MTA: dns; d1o881.telia.com Received-From-MTA: DNS; mailf.telia.com Arrival-Date: Wed, 20 Aug 2003 17:14:17 +0200 (CEST) Final-Recipient: RFC822; u87125783@d1o881.telia.com Action: failed Status: 5.5.0 Diagnostic-Code: X-Unix; 69 Last-Attempt-Date: Wed, 20 Aug 2003 17:14:17 +0200 (CEST) --h7KFEHb13045.1061392457/d1o881.telia.com Content-Type: message/rfc822 Return-Path: Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by d1o881.telia.com (8.10.2p2/8.10.1) with ESMTP id h7KFEGb13041 for ; Wed, 20 Aug 2003 17:14:17 +0200 (CEST) Received: from HALIPE (as11-2-6.sto.s.bonet.se [217.215.164.169]) by mailf.telia.com (8.12.9/8.12.9) with ESMTP id h7KFEBVT013784 for ; Wed, 20 Aug 2003 17:14:11 +0200 (CEST) X-Original-Recipient: Message-Id: <200308201514.h7KFEBVT013784@mailf.telia.com> From: To: Subject: Re: Thank you! Date: Wed, 20 Aug 2003 17:13:55 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0124FF58" This is a multipart message in MIME format --_NextPart_000_0124FF58 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit See the attached file for details --_NextPart_000_0124FF58 Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_0124FF58-- --_NextPart_000_0124FF58-- --h7KFEHb13045.1061392457/d1o881.telia.com-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 11:31:57 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 LAA14582 for ; Wed, 20 Aug 2003 11:31:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUvs-0001VK-IX for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:31:32 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFVWXF005776 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:31:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUvs-0001V5-DT for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 11:31: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 LAA14527 for ; Wed, 20 Aug 2003 11:31:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUvO-0001TG-3m; Wed, 20 Aug 2003 11:31:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUv4-0001SR-3a for mip4@optimus.ietf.org; Wed, 20 Aug 2003 11:30: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 LAA14443 for ; Wed, 20 Aug 2003 11:30:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUv3-00026k-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:30:41 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19pUv2-00025V-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:30:40 -0400 Received: (qmail 6382 invoked from network); 20 Aug 2003 15:30:27 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 20 Aug 2003 15:30:27 -0000 Date: Wed, 20 Aug 2003 17:30:11 +0200 From: Henrik Levkowetz To: Bertrand.Lapraye@alcatel.fr Cc: mip4@ietf.org Subject: Re: [Mip4] several irrelevent mails received. Message-Id: <20030820173011.10ba2a28.henrik@levkowetz.com> In-Reply-To: <3F438F86.9080606@alcatel.fr> References: <3F438F86.9080606@alcatel.fr> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.mxBf2T1Fmp+'5/" 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: , --=.mxBf2T1Fmp+'5/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Bertrand, This seems to be a side effect of the list being hit by 100+ virus propagation mails during yesterday and today. We are currently looking at ways to protect the list from both spam and virii, to reduce the problem. Henrik Wednesday 20 August 2003, Bertrand.Lapraye@alcatel.fr wrote: > Hi All, > > Sorry to pollute the list but I receive from this morning some > irrelevent mails coming from aol.om domain and apparently send to mip4 > mailing list . Is that a global pb or local ? > > Thanks. > > > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > --=.mxBf2T1Fmp+'5/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q5QSeVhrtTJkXCMRAk4VAKCVghtBvrJvEQdwaTHHHNHEVRp1YwCeO2kA kjHeftlBbw2PdAylcn+q43A= =Iy6D -----END PGP SIGNATURE----- --=.mxBf2T1Fmp+'5/-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 11:35:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15094 for ; Wed, 20 Aug 2003 11:35:55 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUzj-0001q5-PW for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:35:31 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFZVN3007063 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:35:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUzj-0001pq-Lv for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 11:35:31 -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 LAA15060 for ; Wed, 20 Aug 2003 11:35:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUzF-0001lL-BD; Wed, 20 Aug 2003 11:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pUyG-0001XW-Ln for mip4@optimus.ietf.org; Wed, 20 Aug 2003 11:34:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14836 for ; Wed, 20 Aug 2003 11:33:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pUyF-0002ET-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:33:59 -0400 Received: from omr-m07.mx.aol.com ([64.12.138.19]) by ietf-mx with esmtp (Exim 4.12) id 19pUyE-0002Ck-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:33:59 -0400 Received: from rly-xb01.mx.aol.com (rly-xb01.mail.aol.com [172.20.105.102]) by omr-m07.mx.aol.com (v90_r2.6) with ESMTP id RELAYIN2-0820113307; Wed, 20 Aug 2003 11:33:07 -0400 Received: from localhost (localhost) by rly-xb01.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with internal id LAE26174; Wed, 20 Aug 2003 11:33:07 -0400 (EDT) Date: Wed, 20 Aug 2003 11:33:07 -0400 (EDT) From: Mail Delivery Subsystem Message-Id: <200308201533.LAE26174@rly-xb01.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="LAE26174.1061393587/rly-xb01.mx.aol.com" Auto-Submitted: auto-generated (failure) Subject: [Mip4] Returned mail: User unknown Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a MIME-encapsulated message --LAE26174.1061393587/rly-xb01.mx.aol.com The original message was received at Wed, 20 Aug 2003 11:32:38 -0400 (EDT) from as11-2-6.sto.s.bonet.se [217.215.164.169] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to air-xb03.mail.aol.com.: >>> RCPT To: <<< 550 MAILBOX NOT FOUND 550 ... User unknown --LAE26174.1061393587/rly-xb01.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-xb01.mx.aol.com Arrival-Date: Wed, 20 Aug 2003 11:32:38 -0400 (EDT) Final-Recipient: RFC822; shtabmdr@aol.com Action: failed Status: 5.1.1 Remote-MTA: DNS; air-xb03.mail.aol.com Diagnostic-Code: SMTP; 550 MAILBOX NOT FOUND Last-Attempt-Date: Wed, 20 Aug 2003 11:33:07 -0400 (EDT) --LAE26174.1061393587/rly-xb01.mx.aol.com Content-Type: text/rfc822-headers Received: from HALIPE (as11-2-6.sto.s.bonet.se [217.215.164.169]) by rly-xb01.mx.aol.com (v95.1) with ESMTP id MAILRELAYINXB14-863f439490124; Wed, 20 Aug 2003 11:32:33 -0400 From: To: Subject: Re: Thank you! Date: Wed, 20 Aug 2003 17:32:16 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_0135D049" X-AOL-IP: 217.215.164.169 X-AOL-SCOLL-SCORE: 0:XXX:XX X-AOL-SCOLL-URL_COUNT: 0 Message-ID: <200308201132.863f439490124@rly-xb01.mx.aol.com> --LAE26174.1061393587/rly-xb01.mx.aol.com-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 11:51: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 LAA16307 for ; Wed, 20 Aug 2003 11:51: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 19pVEp-0002vx-FV for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:51:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFp78Q011271 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:51:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVEp-0002vU-Av for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 11:51: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 LAA16248 for ; Wed, 20 Aug 2003 11:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVEm-0002dV-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:51:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pVEj-0002dP-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:51:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVEk-0002rm-Ab; Wed, 20 Aug 2003 11:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVE5-0002pP-AL for mip4@optimus.ietf.org; Wed, 20 Aug 2003 11:50: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 LAA16174 for ; Wed, 20 Aug 2003 11:50:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVE4-0002bv-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:50:20 -0400 Received: from [66.250.68.24] (helo=mxc1.isplogin.com) by ietf-mx with esmtp (Exim 4.12) id 19pVE3-0002bj-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:50:19 -0400 From: MAILER-DAEMON@mh1.711.net To: Date: Wed, 20 Aug 2003 10:47:17 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===77156511====mh1-clt.711.net===_" Subject: [Mip4] WARNING. Mail Delayed: Your details 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: , --_===77156511====mh1-clt.711.net===_ Content-Type: text/plain; charset="utf-8" This is a warning message only. Your message remains in the server queue, the server will try to send it again. You should not try to resend your message now. Message delivery to 'wilder@cleanweb.net' delayed SMTP module(domain cleanweb.net) reports: connection with mail.cleanweb.net is broken --_===77156511====mh1-clt.711.net===_ Content-Type: message/delivery-status Reporting-MTA: dns; mh1-clt.711.net Original-Recipient: rfc822; Final-Recipient: rfc822; Action: delayed Status: 4.0.0 --_===77156511====mh1-clt.711.net===_ Content-Type: text/rfc822-headers Received: from [217.215.164.169] (HELO HALIPE) by mh1-clt.711.net (CommuniGate Pro SMTP 4.1.1) with ESMTP id 77124728 for wilder@cleanweb.net; Wed, 20 Aug 2003 08:56:18 -0400 From: To: Subject: Your details Date: Wed, 20 Aug 2003 14:54:39 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00A582C5" Message-ID: --_===77156511====mh1-clt.711.net===_-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 11:52: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 LAA16420 for ; Wed, 20 Aug 2003 11:52: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 19pVFm-00036i-71 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:52:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KFq6Us011938 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 11:52:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVFm-00036M-3t for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 11:52: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 LAA16352 for ; Wed, 20 Aug 2003 11:51:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVFj-0002fT-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:52:03 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pVFi-0002fO-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 11:52:02 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVFi-00034z-Pt; Wed, 20 Aug 2003 11:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pVFd-00033l-3i for mip4@optimus.ietf.org; Wed, 20 Aug 2003 11:51:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16340 for ; Wed, 20 Aug 2003 11:51:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pVFb-0002f7-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:51:55 -0400 Received: from [66.250.68.24] (helo=mxc1.isplogin.com) by ietf-mx with esmtp (Exim 4.12) id 19pVFa-0002f4-00 for mip4@ietf.org; Wed, 20 Aug 2003 11:51:55 -0400 From: MAILER-DAEMON@mh1.711.net To: Date: Wed, 20 Aug 2003 10:13:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/report; report-type="delivery-status"; boundary="_===77145647====mh1-clt.711.net===_" Subject: [Mip4] Undeliverable mail: Re: Your application 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: , --_===77145647====mh1-clt.711.net===_ Content-Type: text/plain; charset="utf-8" Our SPAM/CONTENT filter has rejected your message to 'wilder@cleanweb.net'. Please reword and try again. If you continue to have problems have 'wilder@cleanweb.net' contact their ISP. SMTP module(domain cleanweb.net) reports: connection with mail.cleanweb.net is broken --_===77145647====mh1-clt.711.net===_ Content-Type: message/delivery-status Reporting-MTA: dns; mh1-clt.711.net Original-Recipient: rfc822; Final-Recipient: rfc822; Action: failed Status: 4.0.0 --_===77145647====mh1-clt.711.net===_ Content-Type: text/rfc822-headers Received: from [217.215.164.169] (HELO HALIPE) by mh1-clt.711.net (CommuniGate Pro SMTP 4.1.1) with ESMTP id 77108931 for wilder@cleanweb.net; Wed, 20 Aug 2003 07:46:10 -0400 From: To: Subject: Re: Your application Date: Wed, 20 Aug 2003 13:44:31 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_00654DBC" Message-ID: --_===77145647====mh1-clt.711.net===_-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 12:42: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 MAA18726 for ; Wed, 20 Aug 2003 12:42: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 19pW27-0006LC-8J for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 12:42:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KGg3dH024375 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 12:42:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW27-0006L4-2A for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 12:42:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18715 for ; Wed, 20 Aug 2003 12:41:55 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pW25-0003Na-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 12:42:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pW24-0003NX-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 12:42:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW24-0006Ke-MS; Wed, 20 Aug 2003 12:42:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pW1a-0006Jz-OR for mip4@optimus.ietf.org; Wed, 20 Aug 2003 12:41:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18666 for ; Wed, 20 Aug 2003 12:41:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pW1Z-0003Mm-00 for Mip4@ietf.org; Wed, 20 Aug 2003 12:41:29 -0400 Received: from cust4.xnet.cz ([213.151.79.37] ident=root) by ietf-mx with esmtp (Exim 4.12) id 19pW1W-0003Md-00 for Mip4@ietf.org; Wed, 20 Aug 2003 12:41:27 -0400 Received: from localhost (localhost) by cust4.xnet.cz (8.11.4/8.11.5) id h7KGfKH03295; Wed, 20 Aug 2003 18:41:20 +0200 (CEST) Date: Wed, 20 Aug 2003 18:41:20 +0200 (CEST) From: Mail Delivery Subsystem Message-Id: <200308201641.h7KGfKH03295@cust4.xnet.cz> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="h7KGfKH03295.1061397680/cust4.xnet.cz" Auto-Submitted: auto-generated (failure) Subject: [Mip4] Returned mail: see transcript for details Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , This is a MIME-encapsulated message --h7KGfKH03295.1061397680/cust4.xnet.cz The original message was received at Wed, 20 Aug 2003 18:37:47 +0200 (CEST) from root@holub.xnet.cz [213.151.79.58] ----- The following addresses had permanent fatal errors ----- (reason: addressee unknown) ----- Transcript of session follows ----- unknown name: rwm 550 5.1.1 ... User unknown --h7KGfKH03295.1061397680/cust4.xnet.cz Content-Type: message/delivery-status Reporting-MTA: dns; cust4.xnet.cz Received-From-MTA: DNS; holub.xnet.cz Arrival-Date: Wed, 20 Aug 2003 18:37:47 +0200 (CEST) Final-Recipient: RFC822; RWM@zde.cz Action: failed Status: 5.1.1 Diagnostic-Code: X-Unix; 67 Last-Attempt-Date: Wed, 20 Aug 2003 18:39:02 +0200 (CEST) --h7KGfKH03295.1061397680/cust4.xnet.cz Content-Type: message/rfc822 Return-Path: Received: from holub.xnet.cz (root@holub.xnet.cz [213.151.79.58]) by cust4.xnet.cz (8.11.4/8.11.5) with ESMTP id h7KGZiH08237 for ; Wed, 20 Aug 2003 18:37:47 +0200 (CEST) Received: from HALIPE (as11-2-6.sto.s.bonet.se [217.215.164.169]) by holub.xnet.cz (8.12.2/8.12.2) with ESMTP id h7KGqKVd002162 for ; Wed, 20 Aug 2003 18:52:23 +0200 (CEST) Message-Id: <200308201652.h7KGqKVd002162@holub.xnet.cz> From: To: Subject: Re: That movie Date: Wed, 20 Aug 2003 18:35:34 +0200 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="_NextPart_000_016F8CCC" This is a multipart message in MIME format --_NextPart_000_016F8CCC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Please see the attached file for details. --_NextPart_000_016F8CCC Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: wicked_scr.scr, Content-Type: application/octet-stream] The attachment file in the message has been removed by eManager. --_NextPart_000_016F8CCC-- --_NextPart_000_016F8CCC-- --h7KGfKH03295.1061397680/cust4.xnet.cz-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 13:03: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 NAA19920 for ; Wed, 20 Aug 2003 13:03: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 19pWMR-00079p-SU for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 13:03:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KH33Jv027512 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 13:03:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWMR-00079a-LN for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 13:03:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19885 for ; Wed, 20 Aug 2003 13:02:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWMP-0003gB-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 13:03:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pWMO-0003g8-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 13:03:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWMP-00078a-Jn; Wed, 20 Aug 2003 13:03:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWLo-00078D-EP for mip4@optimus.ietf.org; Wed, 20 Aug 2003 13:02: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 NAA19834 for ; Wed, 20 Aug 2003 13:02:16 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWLm-0003fL-00 for mip4@ietf.org; Wed, 20 Aug 2003 13:02:22 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19pWLl-0003eJ-00 for mip4@ietf.org; Wed, 20 Aug 2003 13:02:21 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7KH1D302536; Wed, 20 Aug 2003 12:01:14 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Aug 2003 12:01:13 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746AF6@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Henrik Levkowetz'" Cc: mip4@ietf.org, "Charles E. Perkins" Subject: RE: [Mip4] Current state of 3012bis solicited agent advertisement issue. Date: Wed, 20 Aug 2003 12:01:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3673C.A96055EC" 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_01C3673C.A96055EC Content-Type: text/plain Hi Henrik, Please see my response inline. Regards, Jayshree > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Tuesday, August 19, 2003 6:45 PM > To: Charles E. Perkins > Cc: mip4@ietf.org > Subject: Re: [Mip4] Current state of 3012bis solicited agent > advertisement issue. ... > > > One of the more disadvantageous implementations would be > one where a > > > solicitation resulted in the generation of a new (multicast) > > > challenge, which would take the most recent slot of the > > > CHALLENGE_WINDOW remembered challenges. The lifetime of any > > > challenge could then be severely reduced by a malicious node > > > soliciting with a high frequency. > > > > That would be bad. In fact, I think it would be reasonable > to specify > > an upper limit on the frequency of multicast > advertisements, not more > > than a few each second. > > I could go with that - although I guess my idea of a few > might be as many as 50 or so, as a rough guess. > [JB] Currently we have the following text in RFC3344 (section 2.4): "The rate at which a mobile node sends Solicitations MUST be limited by the mobile node. The mobile node MAY send three initial Solicitations at a maximum rate of one per second while searching for an agent. After this, the rate at which Solicitations are sent MUST be reduced so as to limit the overhead on the local link. Subsequent Solicitations MUST be sent using a binary exponential backoff mechanism, doubling the interval between consecutive Solicitations, up to a maximum interval. The maximum interval SHOULD be chosen appropriately based upon the characteristics of the media over which the mobile node is soliciting. This maximum interval SHOULD be at least one minute between Solicitations...." Are we looking for further restriction apart from this? Also, I would think that if we specify to use "previously unused challenge" for the multicast agent advertisement, it will help also since in these cases, the FA is not allocating new challenges for each solicited requests. ------_=_NextPart_001_01C3673C.A96055EC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] Current state of 3012bis solicited agent = advertisement issue.

Hi Henrik,

Please see my response inline.

Regards,
Jayshree

> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] =
> Sent: Tuesday, August 19, 2003 6:45 PM
> To: Charles E. Perkins
> Cc: mip4@ietf.org
> Subject: Re: [Mip4] Current state of 3012bis = solicited agent
> advertisement issue.
...

> > > One of the more disadvantageous = implementations would be
> one where a
> > > solicitation resulted in the = generation of a new (multicast)
> > > challenge, which would take the most = recent slot of the
> > > CHALLENGE_WINDOW remembered = challenges. The lifetime of any
> > > challenge could then be severely = reduced by a malicious node
> > > soliciting with a high = frequency.
> >
> > That would be bad.  In fact, I think = it would be reasonable
> to specify
> > an upper limit on the frequency of = multicast
> advertisements, not more
> > than a few each second.
>
> I could go with that - although I guess my idea = of a few
> might be as many as 50 or so, as a rough = guess.
>
[JB] Currently we have the following text in RFC3344 = (section 2.4):
"The rate at which a mobile node sends = Solicitations MUST be limited by the mobile node.  The mobile node = MAY send three initial Solicitations at a maximum rate of one per = second while searching for an agent.  After this, the rate at = which Solicitations are sent MUST

be reduced so as to limit the overhead on the local = link.  Subsequent Solicitations MUST be sent using a binary = exponential backoff mechanism, doubling the interval between = consecutive Solicitations, up to a maximum interval.  The maximum = interval SHOULD be chosen appropriately based upon the characteristics = of the media over which the mobile node is soliciting.  This = maximum interval SHOULD be at least one minute between = Solicitations...."

Are we looking for further restriction apart from = this? Also, I would think that if we specify to use "previously = unused challenge" for the multicast agent advertisement, it will = help also since in these cases, the FA is not allocating new challenges = for each solicited requests.

------_=_NextPart_001_01C3673C.A96055EC-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 20 13:15: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 NAA20386 for ; Wed, 20 Aug 2003 13:15: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 19pWY3-0007o6-9V for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 13:15:03 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7KHF3P7030004 for mip4-archive@odin.ietf.org; Wed, 20 Aug 2003 13:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWY3-0007nZ-4P for mip4-web-archive@optimus.ietf.org; Wed, 20 Aug 2003 13:15: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 NAA20363 for ; Wed, 20 Aug 2003 13:14:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWY1-0003oM-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 13:15:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pWY0-0003oJ-00 for mip4-web-archive@ietf.org; Wed, 20 Aug 2003 13:15:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWY1-0007mQ-KF; Wed, 20 Aug 2003 13:15:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pWXU-0007ln-Ei for mip4@optimus.ietf.org; Wed, 20 Aug 2003 13:14:28 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20343 for ; Wed, 20 Aug 2003 13:14:22 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pWXS-0003nw-00 for mip4@ietf.org; Wed, 20 Aug 2003 13:14:26 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19pWXR-0003nl-00 for mip4@ietf.org; Wed, 20 Aug 2003 13:14:25 -0400 Received: (qmail 7187 invoked from network); 20 Aug 2003 17:14:11 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 20 Aug 2003 17:14:11 -0000 Date: Wed, 20 Aug 2003 19:14:09 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: mip4@ietf.org, "Charles E. Perkins" Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. Message-Id: <20030820191409.593c78c7.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746AF6@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746AF6@zrc2c000.us.nortel.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.x5P_jMuk1qF3MZ" 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: , --=.x5P_jMuk1qF3MZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Jayshree, My thoughts on this below: Wednesday 20 August 2003, Jayshree wrote: > > > > > One of the more disadvantageous implementations would be one > > > > where a solicitation resulted in the generation of a new > > > > (multicast) challenge, which would take the most recent slot of > > > > the CHALLENGE_WINDOW remembered challenges. The lifetime of any > > > > challenge could then be severely reduced by a malicious node > > > > soliciting with a high frequency. > > > > > > That would be bad. In fact, I think it would be reasonable to > > > specify an upper limit on the frequency of multicast > > > advertisements, not more than a few each second. > > > > I could go with that - although I guess my idea of a few > > might be as many as 50 or so, as a rough guess. > > > [JB] Currently we have the following text in RFC3344 (section 2.4): > "The rate at which a mobile node sends Solicitations MUST be limited > by the mobile node. The mobile node MAY send three initial > Solicitations at a maximum rate of one per second while searching for > an agent. After this, the rate at which Solicitations are sent MUST > be reduced so as to limit the overhead on the local link. Subsequent > Solicitations MUST be sent using a binary exponential backoff > mechanism, doubling the interval between consecutive Solicitations, up > to a maximum interval. The maximum interval SHOULD be chosen > appropriately based upon the characteristics of the media over which > the mobile node is soliciting. This maximum interval SHOULD be at > least one minute between Solicitations...." > > Are we looking for further restriction apart from this? Also, I would > think that if we specify to use "previously unused challenge" for the > multicast agent advertisement, it will help also since in these cases, > the FA is not allocating new challenges for each solicited requests. Yes, the paragraph above only restricts the rate at wich a well-behaved mobile node sends solicitations. It seems Charlie and I agree on also putting a limit on how often an FA may send multicast advertisements (in response to e.g. solicitations) in order to limit the load a hostile node may put on the FA by sending very frequent solicitations. To also specify to use a "previously unused challenge" in multicast advertisements may also be a good thing, but we still should have the rate limitation, as a hostile node may very well otherwise combine solicitations and registration requests in order to make each advertised challenge used as soon as it has been advertised. Regards, Henrik --=.x5P_jMuk1qF3MZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q6xieVhrtTJkXCMRAnYvAKDORWVot0vcRHzgKwOJIkCC0P+hjACgxC8B 35ugYmDrNpT+990q2dan/oY= =PiKq -----END PGP SIGNATURE----- --=.x5P_jMuk1qF3MZ-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 21 01:33: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 BAA04752 for ; Thu, 21 Aug 2003 01:33: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 19pi4G-00018C-Cb for mip4-archive@odin.ietf.org; Thu, 21 Aug 2003 01:33:04 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7L5X4UP004348 for mip4-archive@odin.ietf.org; Thu, 21 Aug 2003 01:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pi4G-000183-8h for mip4-web-archive@optimus.ietf.org; Thu, 21 Aug 2003 01:33:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04724 for ; Thu, 21 Aug 2003 01:32:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pi4D-000645-00 for mip4-web-archive@ietf.org; Thu, 21 Aug 2003 01:33:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19pi4C-000640-00 for mip4-web-archive@ietf.org; Thu, 21 Aug 2003 01:33:00 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pi4D-00016U-1i; Thu, 21 Aug 2003 01:33:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19pi3m-00015i-Jq for mip4@optimus.ietf.org; Thu, 21 Aug 2003 01:32: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 BAA04669 for ; Thu, 21 Aug 2003 01:32:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19pi3j-000633-00 for mip4@ietf.org; Thu, 21 Aug 2003 01:32:31 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19pi3i-00062s-00 for mip4@ietf.org; Thu, 21 Aug 2003 01:32:30 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7L5V5C20673; Thu, 21 Aug 2003 00:31:06 -0500 (CDT) Received: from mccap-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7L5V2s05251; Thu, 21 Aug 2003 00:31:03 -0500 (CDT) Received: from [127.0.0.1] (helo=MCCAP-1.lucent.com) by mccap-1.lucent.com with esmtp (Exim 4.04) id HJYFBI-0001I4-00; Thu, 21 Aug 2003 01:30:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16196.22796.979860.809933@gargle.gargle.HOWL> Date: Thu, 21 Aug 2003 00:30:52 -0500 From: Pete McCann To: Henrik Levkowetz Cc: "Charles E. Perkins" , mip4@ietf.org Subject: Re: [Mip4] Current state of 3012bis solicited agent advertisement issue. In-Reply-To: <20030820010840.33d169eb.henrik@levkowetz.com> References: <20030813103506.3f0c4305.henrik@levkowetz.com> <3F42A64D.BA9A067D@iprg.nokia.com> <20030820010840.33d169eb.henrik@levkowetz.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Just to amplify on one point made by Henrik: Henrik Levkowetz writes: > > > - Add the following at the end of Section 12: > > > > > > Note that an active attacker may try to prevent successful > > > registrations by sending a large number of Agent Solicitations or > > > bogus Registration Requests, each of which could cause the FA to > > > respond with a fresh challenge, invalidating the challenge that the > > > MN is currently trying to use. To prevent such attacks, the FA > > > SHOULD repeat the same challenge value in successive unicast > > > responses to Agent Solicitations or in Registration Replies to > > > Requests that did not contain valid MN-AAA or MN-FA authentication > > > extensions for some limited period of time (on the order of 60 > > > seconds). Note that each challenge returned to an MN MUST be > > > previously unused by that MN. > > > > Even better if the foreign agent allows more than one mobile node > > to use the same challenge value. Why not? > > This is the case with multicast challenges, of course. But currently we > only require the FA to remember one individual challenge per mobile > node, and if an impostor has the ability to invalidate that one (by > causing it to be replaced by a newer one) it has blocked the mobile from > succeeding in its next registration attempt. A good way to think about this problem is to realize that the FA is keeping state (look at Appendix E): there is the global list of challenges and then there is the per-MN data structure that includes one unused challenge per MN. If we ever allow unauthenticated messages (such as ordinary solicitations or bogus Registration Requests) to trigger a modification of this state, then we are in trouble. -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 27 03:37:13 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 DAA01696 for ; Wed, 27 Aug 2003 03:37:13 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rtia-0002xV-60 for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 02:23:45 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7R6NgME011346 for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 02:23:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rrqJ-0003Kc-1s for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 00:23: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 AAA17861 for ; Wed, 27 Aug 2003 00:23:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rrqG-0003n8-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 00:23:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19rrqG-0003n4-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 00:23:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rmfm-0004jr-MY; Tue, 26 Aug 2003 18:52:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19rarq-0006P6-TO for mip4@optimus.ietf.org; Tue, 26 Aug 2003 06:16:03 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26435 for ; Tue, 26 Aug 2003 06:15:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19rarn-0006pY-00 for mip4@ietf.org; Tue, 26 Aug 2003 06:15:59 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 19rarl-0006ox-00 for mip4@ietf.org; Tue, 26 Aug 2003 06:15:58 -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 h7QAF7wf017287; Tue, 26 Aug 2003 12:15:07 +0200 Date: Tue, 26 Aug 2003 12:15:06 +0200 From: Henrik Levkowetz To: ietf-mip-vpn@liqwidnet.com, mip4@ietf.org, "Adrangi, Farid" Message-Id: <20030826121506.14df5e34.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 X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,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 Subject: [Mip4] Re: FW: 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: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, I'm picking up this thread and putting it onto the main mip4 list. Please remove the mip-vpn design team list address from future replies. I would like to see this draft sent up to the IESG for consideration ASAP. In case we get (unexpected) pushback, it would be good to get it before the solutions draft is complete... Please respond to Farid's query below, so we can wrap this up. If any other minor adjustments are needed as a result of the WG last call, I'd like them done and an updated draft out soon; at which point we will send it to the ADs. If there are no adjustments to be done, we'll send up the current draft ( -03 ). Let's get's this one shipped, shall we? As Section 2 of the draft explicitly discusses possible placements of HA vs. VPN-GW, and (as we discussed in the design team) the co-location of an FA with the VPN-GW is a possible optimization feature of a solution to the problems posed, rather than a separate problem scenario, my viewpoint is that we should not put this in the problem statement draft. It should be described properly in a vpn-traversal optimization draft, though. Regards, Henrik On Tuesday, 12 Aug 2003, Farid wrote: > Hello All, > What do you think about Jayshree's request to add a new scenario to > the problem statement draft? > BR, > Farid > > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > Sent: Wednesday, August 06, 2003 12:13 PM > To: Adrangi, Farid > Cc: mip4@ietf.org > Subject: RE: Comments on VPN Problem Statement Draft > > Hello Farid, > > Please see my reply below. > > Thanks, > Jayshree > -----Original Message----- > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > Sent: Sunday, August 03, 2003 11:50 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: mip4@ietf.org > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Jayshree, > > Thanks for following up on this. You, Gopal, and I had a very brief > > conversation on this during IETF-57 - but I am not sure if we > > derived any conclusion on whether or not we should include this > > scenario. To be frank, I don't quite understand the point behind > > adding this scenario because, > > - It seems to present a solution to a specific deployment > > model rather than a deployment scenario > > [JB] My understanding is different from yours so please elaborate what > you mean by deployment model vs deployment scenario in this particular > context. > > > - I don't quite see the advantages of a combined VPN+FA if it > > does not support FA traversal and it does not avoid IPsec > > renegotiation when MN moves from one subnet to another - perhaps you > > can elaborate on this? > > [JB] I think regardless this scenario has any advantages or not, it is > one of the probable scenario which has potential issues (as you have > indicated earlier). > > > - Furthermore, Scenarios in section 2 of the problem statement > > draft represents combinations of MIPv4 HA and VPN gateway placement > > - adding this scenario is going to change semantics of the section > > 2. > > [JB] I am not sure what you mean by semantics change here. Do you > think documenting this in new subsection (2.6) is a problem? > > > I have no problem adding this scenario to the draft - I just wanted > > to make sure that we clearly understand the reasons for adding this > > scenario to the problem statement draft. Design team members and > > interested individuals are welcome to express their opinion on this. > > > > > > Best regards, > > Farid > > > > > > The following sub-sections introduce five representative > combinations of MIPv4 HA and VPN gateway placement. > > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > Sent: Thursday, July 31, 2003 1:44 PM > To: Adrangi, Farid > Cc: 'mip4@ietf.org' > Subject: RE: Comments on VPN Problem Statement Draft > > Hello Farid, > > As per our earlier discussion during IETF-57, my understanding is that > you will include the scenario of co-existed FA with the VPN gateway in > the VPN Problem Statement draft. > > I agree that this particular scenario has problems and it won't work > if the MN is behind an FA in the foreign subnet. But again, this is a > problem statement draft. Hence, I believe that this is the appropriate > document for > mentioning this scenario. > > Thanks, > Jayshree > > -----Original Message----- > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > Sent: Monday, April 07, 2003 2:58 PM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'mobile-ip@sunroof.eng.sun.com' > Subject: RE: Comments on VPN Problem Statement Draft > Hello Jayshree > This is a good point - I knew someone was to bring this up! At the > time of writing these scenarios, we (the design team) actually > discussed this and concluded this scenario would fall into a solution > space. Maybe we did not make the right decision and we should rethink > this. But, before we take this discussion further please allow me to > ask you a few questions about the details of the scenario (VPN+FA) > that you have in mind . Are you thinking to broadcast FA > advertisements through the IPsec tunnel to the MN? If so, how will > this work if MN is already behind an FA in the foreign subnet? Or, If > you had something different in mind, perhaps you can elaborate on > that. Best regards, > Farid > > > -----Original Message----- > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > Sent: Friday, April 04, 2003 3:14 PM > To: 'farid.adrangi@intel.com' > Cc: 'mobile-ip@sunroof.eng.sun.com' > Subject: Comments on VPN Problem Statement Draft > > Hello Farid, > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > currently misses one scenario were the FA is co-existed with the VPN > Gateway. I would think that there are no technical issues supporting > this scenario. It will be good if you can add this scenario in the > draft (perhaps as section 2.6?) for completeness. > Thanks, > Jayshree > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Wed Aug 27 23:22:03 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 XAA08680 for ; Wed, 27 Aug 2003 23:22:03 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8xh-0004zM-UC for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 18:40:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7RMeLpd019172 for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 18:40:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4Mu-0006va-1H for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 13:46:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21667 for ; Wed, 27 Aug 2003 13:45:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s4Mr-0004S4-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 13:46:01 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s4Mr-0004S1-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 13:46:01 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2qQ-0000Ia-N6; Wed, 27 Aug 2003 12:08:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s2hG-0008Gg-3k for mip4@optimus.ietf.org; Wed, 27 Aug 2003 11:58: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 LAA11546 for ; Wed, 27 Aug 2003 11:58:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s2hE-0001aA-00 for mip4@ietf.org; Wed, 27 Aug 2003 11:58:56 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19s2hD-0001Ze-00 for mip4@ietf.org; Wed, 27 Aug 2003 11:58:55 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7RFwKB13673 for ; Wed, 27 Aug 2003 10:58:21 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 10:58:21 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B22@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 27 Aug 2003 10:58:20 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Mip4] RFC3012bis Issues 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: , Last week we (myself, Ahmad Muhanna, Pete McCann) had a conference call discussing current RFC3012bis issues and we also had some email conversation after that between myself, Ahmad Muhanna, Pete McCann, Charlie Perkins and Henrik Levkowetz. I tried to compile the current issues and their proposals. Please note that some of the points are agreed among few of us but not all. Regardless, I like to have your opinion on the current proposals. Also, please point out any other issues you may have encountered as a part of interoperability testing. There are two issues we have been discussing so far. Note that we have common proposal for the last two issues (2a and 2b). Issue 1: Current draft (05 version) doesn't have description on how to treat ICMP messages in terms of sending new challenge vs unused challenge. Due to this reason, implementations differ significantly. This causes interoperability issues. Issue 2a: Since the behavior of ICMP messages are not explicit from the draft, chances are that the FA generates new challenge every time it receives the Agent Solicitation. This has potential DOS attack threat especially for the case where the multicast Agent Advertisements are sent upon receipt of the Agent Solicitation. Issue 2b: This draft doesn't provide a mechanism to prevent the FA from receiving bogus Registration Requests/Agent Solicitations. The current proposals for these issues will be posted subsequently (in separate emails). Please provide your comments/suggestions once you receive them. Thanks, Jayshree _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 01:06:42 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 BAA17665 for ; Thu, 28 Aug 2003 01:06:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCdr-0002Aj-Uw for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 22:36:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2a7Nv008341 for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 22:36:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBaV-0005hd-M3 for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 21:28: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 VAA27859 for ; Wed, 27 Aug 2003 21:28:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sBaS-0005T9-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 21:28:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sBaS-0005T6-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 21:28:32 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sB09-0002xI-KY; Wed, 27 Aug 2003 20:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5Ne-0002RB-6d for mip4@optimus.ietf.org; Wed, 27 Aug 2003 14:50:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26055 for ; Wed, 27 Aug 2003 14:50:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5NW-0005TL-00 for mip4@ietf.org; Wed, 27 Aug 2003 14:50:47 -0400 Received: from [213.80.52.78] (helo=mailgw.local.ipunplugged.com) by ietf-mx with esmtp (Exim 4.12) id 19s5NV-0005Sw-00 for mip4@ietf.org; Wed, 27 Aug 2003 14:50:46 -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 h7RIoEwf012718; Wed, 27 Aug 2003 20:50:14 +0200 Date: Wed, 27 Aug 2003 20:50:13 +0200 From: Henrik Levkowetz To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: Re: [Mip4] RFC3012bis Issues Message-Id: <20030827205013.3940d71c.henrik@levkowetz.com> In-Reply-To: <870397D7C140C84DB081B88396458DAF746B22@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746B22@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 X-Spam-Status: No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,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, A small clarification, to tie this together with earlier discussions on the list - the ICMP messages Jayshree refers to below are specifically the router solicitations (mobility agent advertisement solicitations) sent by mobile nodes, and the resulting agent advertisements sent by foreign agents. Henrik On Wednesday, 27 Aug 2003, Jayshree wrote: > Last week we (myself, Ahmad Muhanna, Pete McCann) had a conference call > discussing current RFC3012bis issues and we also had some email conversation > after that between myself, Ahmad Muhanna, Pete McCann, Charlie Perkins and > Henrik Levkowetz. I tried to compile the current issues and their proposals. > Please note that some of the points are agreed among few of us but not all. > Regardless, I like to have your opinion on the current proposals. Also, > please point out any other issues you may have encountered as a part of > interoperability testing. > > There are two issues we have been discussing so far. Note that we have > common proposal for the last two issues (2a and 2b). > > Issue 1: Current draft (05 version) doesn't have description on how to treat > ICMP messages in terms of sending new challenge vs unused challenge. Due to > this reason, implementations differ significantly. This causes > interoperability issues. > Issue 2a: Since the behavior of ICMP messages are not explicit from the > draft, chances are that the FA generates new challenge every time it > receives the Agent Solicitation. This has potential DOS attack threat > especially for the case where the multicast Agent Advertisements are sent > upon receipt of the Agent Solicitation. > Issue 2b: This draft doesn't provide a mechanism to prevent the FA from > receiving bogus Registration Requests/Agent Solicitations. > > The current proposals for these issues will be posted subsequently (in > separate emails). Please provide your comments/suggestions once you receive > them. > > Thanks, > Jayshree > > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 Henrik -- You can have peace. Or you can have freedom. Don't ever count on having both at once. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 01:24: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 BAA18966 for ; Thu, 28 Aug 2003 01:24: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 19sDna-0008Ft-Vq for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 23:50:15 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3oEJZ031725 for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 23:50:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBcW-0005mZ-51 for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 21:30: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 VAA28098 for ; Wed, 27 Aug 2003 21:30:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sBcH-0005WH-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 21:30:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sBcG-0005WE-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 21:30:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sAIb-0000TA-MA; Wed, 27 Aug 2003 20:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s5ie-0003hS-38 for mip4@optimus.ietf.org; Wed, 27 Aug 2003 15:12:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28686 for ; Wed, 27 Aug 2003 15:12:31 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s5ic-00062M-00 for mip4@ietf.org; Wed, 27 Aug 2003 15:12:34 -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 19s5ib-00061j-00 for mip4@ietf.org; Wed, 27 Aug 2003 15:12:33 -0400 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 27 Aug 2003 12:12:02 -0700 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h7RJC07b007129; Wed, 27 Aug 2003 12:12:01 -0700 (PDT) Received: from cisco.com (dhcp-128-107-163-51.cisco.com [128.107.163.51]) by mira-sjc5-a.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJI44669; Wed, 27 Aug 2003 11:56:52 -0700 (PDT) Message-ID: <3F4D027F.3000704@cisco.com> Date: Wed, 27 Aug 2003 12:11:59 -0700 From: Milind Kulkarni User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pete McCann CC: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] draft-kulkarni-mobileip-dynamic-assignment as Workgroup Item? References: <20030810070259.756b7d5b.henrik@levkowetz.com> <16188.696.536937.422217@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi Pete, Sorry for the delay. Kuntal has already answered most of the concerns. Before we go into the details of the draft, the motivation for the draft is: - To get assigned with an "optimized" home agent for a given MN. - The definition of "optmized" home agent is left to suit the various deployments. That is because we want to keep the mechanism generic, so that it can accommodate different requirements. For example, one deployment may want to select nearest geographical HA, while another may choose to select the HA that is cheaper (in terms of money) to go to. Some other deployment may want to choose an HA based on certain time of the day, and so on. There can be many variations. - To propose a mechanism that is generic, open for accommodating various requirements and should work with any existing infrastructure such as AAA etc. - The MIP v6 group also considers this as a problem, and was presented in Vienna IETF as part of Thoughts on Bootstrapping Mobility. More inline..... Pete McCann wrote: > Hi, > > Henrik Levkowetz writes: > > > > One of the charter items of the mip4 working group is dynamic HA > > assignment. The document draft-kulkarni-mobileip-dynamic-assignment-01.txt > > proposes a mechanism for doing this at registration time. We would now > > like to confirm with the working group that this document should be > > made the basis of registration time HA assignment, and moved forward > > as a workgroup item. Any objections? > > > > The chairs > > [chair hat off for a moment] > > I wanted to offer some of my own comments on this draft - I hope > others will read it closely and comment as well. > > > At a high level, what this draft does is allow one HA to redirect a > registration request to a different HA, when the HA field (not the > destination IP address) is set to 0.0.0.0 or 255.255.255.255. One of the key points of the draft is that it allows the RRQ to be responded to by a dynamically assigned home agent. Various metrics and mechanisms can be used to assign the HA intelligently. We are not suggesting or enforcing any specific mechanism. Using the same logic, there may not be any further redirection and the first HA to receive the RRQ can accept and create binding. > > My main concern with this draft is that there is a lot left > unspecified (just look for all the occurrences of "outside the scope") > and some of these unspecified procedures are actually quite > important. For example, the abstract says: Since the draft specifies a framework (or a structure or a front end mechanism, whatever we call it), in our opinion it should be open and satfisy as many requirements. As mentioned earlier, we want various implementors to define their own "optimal" behavior rather than forcing what we think is optimal. Hence the details on how to get to ones optimal HA is left out of scope. The draft says this in sections 1, 5.5. However the mulitple occurrences of the text "out of scope" are due to repeatition of same text so that each section is self sufficient. It can be removed in next rev. > > The distance between a > MN and HA affects the latency for control and data traffic. > When the distance between the MN and HA is large, the resulting > latency may be unacceptable. Therefore, it is advantageous to > select a nearest HA to the MN during initial registration. > > The mechanism outlined in the draft doesn't seem to satisfy this > requirement. This is because "Directed" HA must be a-priori > configured with the "Assigned" HA IP address, which implies they would > be in the same domain. So, the real meat of the above requirement is > that: > > (1) the MN (or the FA) must somehow discover a local HA to which the > message can be sent; and, > (2) the MN must develop a security association with that HA. > > Both of these procedures are ruled explicitly outside the scope of the > draft. Note that I think (1) or (2) can be met with procedures that > don't require any notion of "Directed" or "Assigned" HA. Rather, the > main thrust of the draft seems to be at the next requirement listed in > the abstract: > > There are other reasons for assigning an optimal HA beyond just > locality, such as administrative policies, load balancing etc. > Right, the framework tries to provide a sort of tool that can satisfy more that one requirement. I am not sure why that's not ok. > The abstract goes on to state: > > This draft proposes a generic lightweight dynamic home agent > assignment framework. The goal of the framework is to provide a > mechanism to assign an optimal HA for a Mobile IP session while > allowing any suitable method for HA assignment. > > At best, this draft is really defining some front-end behavior > (message formats and Mobile IP processing) that would enable dynamic > home agent assignment, but I wouldn't go so far as to call it a > framework (due to the large amount of unspecified work left to do). If the term "framework" isn't appealing, can you suggest appropriate alternative? The reason for terming as such is because it incorporates (i) the ability to allow the RRQ to be responded to by dyn HA and (ii) logical separation of 2 addresses viz. Directed HA address and Assigned HA address. The Directed HA and Assigned HA are merely logical entities and dealt extensively in section 5.3, 5.4 and 5.5. We do not want to suggest a specific mechanism e.g. AAA, DNS etc. and tie it specifically tp form a solution as we envision that it is deployment specific. Thus we are providing a generic framework/ front end mechanism within MoObile IP to allow that. > > > The draft also assumes that the assigned HA will be able to verify the > authentication extensions in the redirected RRQ. In section 5.1 the > draft states: > > Example of one such implementation is where MN > shares identical security associations with all the Directed > HA(s) and Assigned HA(s) in the network. > > I consider this to be completely unacceptable security practice and I > think this statement should be removed from the draft. Rather, it > seems like this method will only work with something like the MN-AAA > extension that can be verified from one of many HAs in the network, > and that a security association MUST be developed dynamically along > the lines of the AAA-keys draft. I think limitations like this should > be described in the security considerations. I understand a new > version with expanded security considerations is in preparation; I > will defer additional security comments until it comes out. Since this section is updated in latest version of the draft, let's defer the discussion on SAs. I will send the new version to the WG soon. > > > So, I think the draft may be valuable in that it specifies the > front-end behavior necessary to enable AAA-keys and the MIPv4 Diameter > application. This is similar to the way the NAI and MN-AAA draft > specify front-end behavior, while leaving the actual authentication to > AAA mechanisms specified elsewhere. However, this draft seems to > sneak in some additional HA redirection functionality (purely for load > balancing) that I am not convinced is required at this time. I respectfully disagree, load balancing may not be needed immediately, but is a valid requirement and the logical separation of assigned HA and directed HA address solves it too. Load balancing is one example where dynamic HA framework is useful. There is no intention to 'sneak' in a solution. THis is a real problem for large deployment with 'millions' of subscribers as is starting to happen with 3G deployment. On the contrary, the way we see it is, this draft adds a lot of practical value to the MN-AAA key distribution draft. With that draft, the SA are dynamically derived with an HA, but how is the HA found. If an 'optimal' HA is dynamically found, then that draft can be used to set up SAs. Thanks, Milind > I would > like to hear the opinions of others in the WG on whether this is > important enough to include in the current draft - perhaps it could > best be addressed with a separate draft, using a Rejection code > instead of a forwarding mechanism? > > > -Pete > > > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 03:18:42 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 DAA10788 for ; Thu, 28 Aug 2003 03:18:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCPP-0000qy-4A for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 22:21:11 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S2LBum003275 for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 22:21:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8uB-0004dN-9l for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 18:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15179 for ; Wed, 27 Aug 2003 18:36:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s8u8-00023o-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 18:36:40 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s8u7-00023l-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 18:36:39 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s4YR-0007d5-2E; Wed, 27 Aug 2003 13:57:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s36c-0001H8-T7 for mip4@optimus.ietf.org; Wed, 27 Aug 2003 12:25:10 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13202 for ; Wed, 27 Aug 2003 12:25:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s36b-0001yB-00 for mip4@ietf.org; Wed, 27 Aug 2003 12:25:09 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19s36a-0001xE-00 for mip4@ietf.org; Wed, 27 Aug 2003 12:25:08 -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 h7RGOaB27820 for ; Wed, 27 Aug 2003 11:24:37 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 11:24:37 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B24@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 27 Aug 2003 11:24:36 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Mip4] RFC3012bis: Proposal for Issue1 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , The current proposal for issue 1 is to use "previously unused challenge" in section 2 for all multicast and unicast Agent Advertisements. In addition to this, Henrik proposed a new text for a new subsection 2.1. 2.1 Handling of Solicited Agent Advertisements When a foreign agent generates an Agent Advertisement in response to a Router Solicitation [4], some additional considerations come into play. According to the Mobile IP base specification [7], the resulting Agent Advertisement may be either multicast or unicast. If the solicited Agent Advertisement is multicast, it MUST NOT generate a new Challenge value and update its window of remembered advertised Challenges. It must instead re-use the most recent of the CHALLENGE_WINDOW Advertisement Challenge values. If the agent advertisement is unicast back to the soliciting mobile node MUST be handled as follows: If the challenge most recently unicast to the soliciting mobile node has not been previously used (as defined in Section 1.1), in SHOULD be repeated in the newly issued unicast agent advertisement, otherwise a new challenge MUST be generated and remembered as the most recent challenge issued to the mobile node. (For further discussion of this, see Section 12.) A foreign agent SHOULD NOT respond arbitrarily often to agent solicitations, in order to limit processing load, especially in the face of hostile nodes soliciting at a very high rate. The rate of solicited agent advertisement responses SHOULD at most be 50 per second. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 04:31:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16804 for ; Thu, 28 Aug 2003 04:31:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDWP-0006i4-Fl for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 23:32:29 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S3WTHx025784 for mip4-archive@odin.ietf.org; Wed, 27 Aug 2003 23:32:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s99t-0005Qa-7y for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 18:52:57 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16111 for ; Wed, 27 Aug 2003 18:52:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s99q-0002JX-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 18:52:54 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19s99p-0002JU-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 18:52:53 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s46D-0005BV-3C; Wed, 27 Aug 2003 13:28:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s3Wv-00032O-ID for mip4@optimus.ietf.org; Wed, 27 Aug 2003 12:52:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16555 for ; Wed, 27 Aug 2003 12:52:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s3Wt-00032V-00 for mip4@ietf.org; Wed, 27 Aug 2003 12:52:19 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19s3Wt-00031j-00 for mip4@ietf.org; Wed, 27 Aug 2003 12:52:19 -0400 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h7RGplB01543 for ; Wed, 27 Aug 2003 11:51:48 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 11:51:48 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B25@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 27 Aug 2003 11:51:45 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change1 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , The original proposal from Henrik was to mandate a challenge in a Registration Reply. After few email exchanges, it was decided that the current text in section 3.3 (RFC3012bis (version 05) ) is ok. In addition to the current text, Henrik proposed the following text to be used as a guidance/background: (section 3.3) One example of a situation where the Foreign Agent MAY omit the inclusion of a Mobile-Foreign Challenge Extension in the Registration Reply would be when a new challenge has been multicast recently. The Foreign Agent could then assume that the mobile node with high likelihood has received and can use the multicast challenge. A mobile node MUST be prepared to use a multicast challenge in lieu of one returned in a Registration Reply, and MUST solicit for one if it has not already received one in a Registration Reply or Agent Advertisement. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 04:47:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18098 for ; Thu, 28 Aug 2003 04:47:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFsR-0006EZ-OF for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 02:03:23 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S63Nws023946 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 02:03:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCR0-0000yc-Pk for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 22:22:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02606 for ; Wed, 27 Aug 2003 22:22:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sCQx-0006mN-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 22:22:47 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sCQx-0006mK-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 22:22:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBHb-0004XQ-PL; Wed, 27 Aug 2003 21:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s6IM-00058o-Ml for mip4@optimus.ietf.org; Wed, 27 Aug 2003 15:49:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02410 for ; Wed, 27 Aug 2003 15:49:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s6IK-0006tA-00 for mip4@ietf.org; Wed, 27 Aug 2003 15:49:28 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19s6IK-0006sX-00 for mip4@ietf.org; Wed, 27 Aug 2003 15:49:28 -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 h7RJmuB19702 for ; Wed, 27 Aug 2003 14:48:56 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 14:48:57 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B2A@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 27 Aug 2003 14:48:54 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change4 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , The following text was proposed to be added in section 12. This is a modified version of the text proposed by Henrik on the mailing list earlier. (section 12) Note that an active attacker may try to prevent successful registrations by sending a large number of Agent Solicitations or bogus Registration Requests, each of which could cause the FA to respond with a fresh challenge, invalidating the challenge that the MN is currently trying to use. To prevent such attacks, the FA SHOULD repeat the same challenge value in successive unicast responses to Agent Solicitations or in Registration Replies to Requests that did not contain valid MN-AAA or MN-FA authentication extensions. Note that each challenge returned to an MN MUST be previously unused by that MN. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 06:21:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25874 for ; Thu, 28 Aug 2003 06:21:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sFav-0005Wr-Hr for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 01:45:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S5jHCB021247 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 01:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCWR-0001Ju-QB for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 22:28:27 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03023 for ; Wed, 27 Aug 2003 22:28:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sCWO-0006uE-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 22:28:24 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sCWO-0006uB-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 22:28:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sB7t-0003Qw-34; Wed, 27 Aug 2003 20: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 19s6Gw-00055M-7w for mip4@optimus.ietf.org; Wed, 27 Aug 2003 15:48: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 PAA02296 for ; Wed, 27 Aug 2003 15:47:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s6Gu-0006qu-00 for mip4@ietf.org; Wed, 27 Aug 2003 15:48:00 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19s6Gt-0006pu-00 for mip4@ietf.org; Wed, 27 Aug 2003 15:47:59 -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 h7RJlPB19391 for ; Wed, 27 Aug 2003 14:47:25 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 14:47:26 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B29@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 27 Aug 2003 14:47:17 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change3 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 change further extends point mentioned in change 1 for issue 2. The proposal from Henrik was to clarify the use of challenge. This text is intended as a new paragraph in section 3.3. "If the challenge most recently issued to the soliciting mobile node has not been previously used (as defined in Section 1.1), the most recent challenge unicast to the mobile node through a registration reply or a unicast agent advertisement SHOULD be repeated in the registration reply." This proposal was further modified by Pete differentiating the processing at the FA for the registered and unregistered users: "When responding to an unregistered MN with an unsuccessful Registration Reply, the FA SHOULD include the same challenge that was last included in a multicast Agent Advertisement. When responding to a registered MN with a successful or unsuccessful Registration Reply, the FA SHOULD include the same challenge that was last included in a multicast Agent Advertisement, when that challenge is previously unused by the MN. Otherwise, the FA SHOULD include the same challenge that was previously unicast to the MN in a Registration Reply or Agent Advertisement, unless that challenge was previously used. In that case, the FA SHOULD create a new challenge and return it to the MN, storing a copy of it with the visitor list entry for that MN." _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 07:02:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00386 for ; Thu, 28 Aug 2003 07:02:54 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sHMH-0004g4-LH for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 03:38:17 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S7cG8D017976 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 03:38:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCi8-0002ht-6W for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 22:40: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 WAA04359 for ; Wed, 27 Aug 2003 22:40:25 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sCi4-0007IC-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 22:40:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sCi4-0007I9-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 22:40:28 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sBeq-0005y0-0r; Wed, 27 Aug 2003 21:33:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s6Js-0005Fr-Fu for mip4@optimus.ietf.org; Wed, 27 Aug 2003 15:51:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02583 for ; Wed, 27 Aug 2003 15:50:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s6Jq-0006w2-00 for mip4@ietf.org; Wed, 27 Aug 2003 15:51:02 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19s6Jp-0006vG-00 for mip4@ietf.org; Wed, 27 Aug 2003 15:51:01 -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 h7RJoUB19870 for ; Wed, 27 Aug 2003 14:50:30 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 14:50:31 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B2B@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 27 Aug 2003 14:50:30 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change5 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: , It was decided that challenges sent in unicast Agent Advertisements and sent in Registration Reply messages should be treated same at the FA. For this, the following text is proposed by Henrik and Pete: (change 5.1-Section 3.2) From: The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in last Registration Reply issued to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. To: The Foreign Agent MUST NOT accept any Challenge in the Registration Request unless it was offered in the last Registration Reply or unicast Agent Advertisement sent to the Mobile Node, or else advertised as one of the last CHALLENGE_WINDOW (see section 9) Challenge values inserted into the immediately preceding Agent advertisements. (change 5.2-Appendix E) From: In the program fragment, it is presumed that the foreign agent keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the last advertised challenge used by a mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply. To: In the program fragment, it is presumed that the foreign agent keeps an array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the last advertised challenge used by a mobile node, and also a record of the last challenge provided to a mobile node in a Registration Reply or unicast Agent Advertisement. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 07:13:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01311 for ; Thu, 28 Aug 2003 07:13:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sI8V-0007Vc-0u for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 04:28:07 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7S8S6LA028859 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 04:28:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sCzr-0004Bh-Rl for mip4-web-archive@optimus.ietf.org; Wed, 27 Aug 2003 22:58:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06449 for ; Wed, 27 Aug 2003 22:58:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sCzo-00004r-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 22:58:48 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sCzn-00004n-00 for mip4-web-archive@ietf.org; Wed, 27 Aug 2003 22:58:47 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s8Gp-0002oP-E1; Wed, 27 Aug 2003 17: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 19s411-0004tn-8I for mip4@optimus.ietf.org; Wed, 27 Aug 2003 13:23: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 NAA19535 for ; Wed, 27 Aug 2003 13:23:20 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s40y-0003qJ-00 for mip4@ietf.org; Wed, 27 Aug 2003 13:23:24 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19s40y-0003ps-00 for mip4@ietf.org; Wed, 27 Aug 2003 13:23:24 -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 h7RHMqB13660 for ; Wed, 27 Aug 2003 12:22:52 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Aug 2003 12:22:53 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B26@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'mip4@ietf.org'" Date: Wed, 27 Aug 2003 12:22:52 -0500 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change2 Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , The current proposal from Pete is to reuse the challenge in the Registration Reply of the Registration Request for which the authentication fails at the FA. This challenge sent in the Registration reply will be same as the challenge received in the Registration Request for which the reply is sent. To reflect this point, the following changes are proposed by Jayshree: (change 2.1-Section 3.2) From: If the registration message contains a Mobile-Foreign Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AUTHENTICATION (see Section 10). To: (Added last statement) If the registration message contains a Mobile-Foreign Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AUTHENTICATION (see Section 10). In this case, if the Mobile Node is currently registered, the challenge included in the Registration Reply by the Foreign Agent MUST be the same as the one received in the Registration Request. (change 2.2-Section 3.2) From: If the registration message contains a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AAA_AUTHENTICATION_SET_BY_FA. To: (Added last statement) If the registration message contains a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification, the Foreign Agent MAY send a Registration Reply to the mobile node with Code value BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, if the Mobile Node is currently registered, the challenge included in the Registration Reply by the Foreign Agent MUST be the same as the one received in the Registration Request. (change 2.3-Section 3.5) From: BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if the Registration Request contains a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification. A Mobile Node that receives a BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new Challenge value in any new registration, obtained either from an Agent Advertisement, or from a Challenge extension to the Registration Reply containing the error. To: (Replaced "new Challenge" to "Challenge") BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if the Registration Request contains a Mobile-AAA Authentication extension with an incorrect authenticator that fails verification. A Mobile Node that receives a BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a Challenge value in any new registration, obtained either from an Agent Advertisement, or from a Challenge extension to the Registration Reply containing the error. _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 10:30:22 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19692 for ; Thu, 28 Aug 2003 10:30:22 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKmG-0001vX-6w for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 07:17:20 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SBHKwi007397 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 07:17:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIXD-0000UE-OJ for mip4-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 04:53: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 EAA18727 for ; Thu, 28 Aug 2003 04:53:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIXA-00009p-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 04:53:36 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sIXA-00009m-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 04:53:36 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDLJ-0005vj-ID; Wed, 27 Aug 2003 23:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9gu-0006td-4R for mip4@optimus.ietf.org; Wed, 27 Aug 2003 19:27: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 TAA18404 for ; Wed, 27 Aug 2003 19:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s9gs-000304-00 for mip4@ietf.org; Wed, 27 Aug 2003 19:27:02 -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 19s9gr-0002z9-00 for mip4@ietf.org; Wed, 27 Aug 2003 19:27:01 -0400 Received: from gdommety-w2k01.cisco.com ([128.107.176.208]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7RNQVtI027361; Wed, 27 Aug 2003 16:26:31 -0700 (PDT) Message-Id: <4.3.2.7.2.20030827161326.028205d0@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Aug 2003 16:16:03 -0700 To: Henrik Levkowetz , ietf-mip-vpn@liqwidnet.com, mip4@ietf.org, "Adrangi, Farid" From: Gopal Dommety Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft In-Reply-To: <20030826121506.14df5e34.henrik@levkowetz.com> References: 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: , Farid and Henrik, It would make sense to add the scenario that jayshree was bringing up. This was what I was bringing up during the initial discussion. -Gopal At 12:15 PM 8/26/2003 +0200, Henrik Levkowetz wrote: >Hi, > > > > I'm picking up this thread and putting it onto the main mip4 list. >Please remove the mip-vpn design team list address from future replies. > >I would like to see this draft sent up to the IESG for consideration >ASAP. In case we get (unexpected) pushback, it would be good to get it >before the solutions draft is complete... > >Please respond to Farid's query below, so we can wrap this up. If any >other minor adjustments are needed as a result of the WG last call, I'd >like them done and an updated draft out soon; at which point we will >send it to the ADs. If there are no adjustments to be done, we'll send >up the current draft ( -03 ). > >Let's get's this one shipped, shall we? > > > > > >As Section 2 of the draft explicitly discusses possible placements of HA >vs. VPN-GW, and (as we discussed in the design team) the co-location of >an FA with the VPN-GW is a possible optimization feature of a solution >to the problems posed, rather than a separate problem scenario, my >viewpoint is that we should not put this in the problem statement draft. > >It should be described properly in a vpn-traversal optimization draft, >though. > > > > Regards, > Henrik > > > > > >On Tuesday, 12 Aug 2003, Farid wrote: > > Hello All, > > What do you think about Jayshree's request to add a new scenario to > > the problem statement draft? > > BR, > > Farid > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > Sent: Wednesday, August 06, 2003 12:13 PM > > To: Adrangi, Farid > > Cc: mip4@ietf.org > > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > > > Please see my reply below. > > > > Thanks, > > Jayshree > > -----Original Message----- > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > Sent: Sunday, August 03, 2003 11:50 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: mip4@ietf.org > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > Hello Jayshree, > > > Thanks for following up on this. You, Gopal, and I had a very brief > > > conversation on this during IETF-57 - but I am not sure if we > > > derived any conclusion on whether or not we should include this > > > scenario. To be frank, I don't quite understand the point behind > > > adding this scenario because, > > > - It seems to present a solution to a specific deployment > > > model rather than a deployment scenario > > > > [JB] My understanding is different from yours so please elaborate what > > you mean by deployment model vs deployment scenario in this particular > > context. > > > > > - I don't quite see the advantages of a combined VPN+FA if it > > > does not support FA traversal and it does not avoid IPsec > > > renegotiation when MN moves from one subnet to another - perhaps you > > > can elaborate on this? > > > > [JB] I think regardless this scenario has any advantages or not, it is > > one of the probable scenario which has potential issues (as you have > > indicated earlier). > > > > > - Furthermore, Scenarios in section 2 of the problem statement > > > draft represents combinations of MIPv4 HA and VPN gateway placement > > > - adding this scenario is going to change semantics of the section > > > 2. > > > > [JB] I am not sure what you mean by semantics change here. Do you > > think documenting this in new subsection (2.6) is a problem? > > > > > I have no problem adding this scenario to the draft - I just wanted > > > to make sure that we clearly understand the reasons for adding this > > > scenario to the problem statement draft. Design team members and > > > interested individuals are welcome to express their opinion on this. > > > > > > > > > Best regards, > > > Farid > > > > > > > > > > > > The following sub-sections introduce five representative > > combinations of MIPv4 HA and VPN gateway placement. > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > Sent: Thursday, July 31, 2003 1:44 PM > > To: Adrangi, Farid > > Cc: 'mip4@ietf.org' > > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > > > As per our earlier discussion during IETF-57, my understanding is that > > you will include the scenario of co-existed FA with the VPN gateway in > > the VPN Problem Statement draft. > > > > I agree that this particular scenario has problems and it won't work > > if the MN is behind an FA in the foreign subnet. But again, this is a > > problem statement draft. Hence, I believe that this is the appropriate > > document for > > mentioning this scenario. > > > > Thanks, > > Jayshree > > > > -----Original Message----- > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > Sent: Monday, April 07, 2003 2:58 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: Comments on VPN Problem Statement Draft > > Hello Jayshree > > This is a good point - I knew someone was to bring this up! At the > > time of writing these scenarios, we (the design team) actually > > discussed this and concluded this scenario would fall into a solution > > space. Maybe we did not make the right decision and we should rethink > > this. But, before we take this discussion further please allow me to > > ask you a few questions about the details of the scenario (VPN+FA) > > that you have in mind . Are you thinking to broadcast FA > > advertisements through the IPsec tunnel to the MN? If so, how will > > this work if MN is already behind an FA in the foreign subnet? Or, If > > you had something different in mind, perhaps you can elaborate on > > that. Best regards, > > Farid > > > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > > Sent: Friday, April 04, 2003 3:14 PM > > To: 'farid.adrangi@intel.com' > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > Subject: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > currently misses one scenario were the FA is co-existed with the VPN > > Gateway. I would think that there are no technical issues supporting > > this scenario. It will be good if you can add this scenario in the > > draft (perhaps as section 2.6?) for completeness. > > Thanks, > > Jayshree > > > > >_______________________________________________ >Mip4 mailing list >Mip4@ietf.org >https://www.ietf.org/mailman/listinfo/mip4 _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 10:33:00 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 KAA19865 for ; Thu, 28 Aug 2003 10:33:00 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKkd-0001il-W1 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 07:15:41 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SBFd9W006611 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 07:15:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIQN-0000AI-DA for mip4-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 04:46: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 EAA18009 for ; Thu, 28 Aug 2003 04:46:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIQK-0007mc-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 04:46:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sIQJ-0007mY-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 04:46:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sDLN-0005x4-MJ; Wed, 27 Aug 2003 23:21:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19s9gu-0006te-H4 for mip4@optimus.ietf.org; Wed, 27 Aug 2003 19:27: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 TAA18407 for ; Wed, 27 Aug 2003 19:26:58 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19s9gs-000307-00 for mip4@ietf.org; Wed, 27 Aug 2003 19:27:02 -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 19s9gr-0002zA-00 for mip4@ietf.org; Wed, 27 Aug 2003 19:27:02 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 27 Aug 2003 16:26:32 -0700 Received: from gdommety-w2k01.cisco.com ([128.107.176.208]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7RNQVtK027361; Wed, 27 Aug 2003 16:26:32 -0700 (PDT) Message-Id: <4.3.2.7.2.20030827161646.02827e70@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Aug 2003 16:18:02 -0700 To: Henrik Levkowetz , ietf-mip-vpn@liqwidnet.com, mip4@ietf.org, "Adrangi, Farid" From: Gopal Dommety Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft In-Reply-To: <20030826121506.14df5e34.henrik@levkowetz.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Henrik, We should ship this with the added scenario. Do we have an agreement to add the scenario. -Gopal At 12:15 PM 8/26/2003 +0200, Henrik Levkowetz wrote: >Hi, > > > > I'm picking up this thread and putting it onto the main mip4 list. >Please remove the mip-vpn design team list address from future replies. > >I would like to see this draft sent up to the IESG for consideration >ASAP. In case we get (unexpected) pushback, it would be good to get it >before the solutions draft is complete... > >Please respond to Farid's query below, so we can wrap this up. If any >other minor adjustments are needed as a result of the WG last call, I'd >like them done and an updated draft out soon; at which point we will >send it to the ADs. If there are no adjustments to be done, we'll send >up the current draft ( -03 ). > >Let's get's this one shipped, shall we? > > > > > >As Section 2 of the draft explicitly discusses possible placements of HA >vs. VPN-GW, and (as we discussed in the design team) the co-location of >an FA with the VPN-GW is a possible optimization feature of a solution >to the problems posed, rather than a separate problem scenario, my >viewpoint is that we should not put this in the problem statement draft. > >It should be described properly in a vpn-traversal optimization draft, >though. > > > > Regards, > Henrik > > > > > >On Tuesday, 12 Aug 2003, Farid wrote: > > Hello All, > > What do you think about Jayshree's request to add a new scenario to > > the problem statement draft? > > BR, > > Farid > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > Sent: Wednesday, August 06, 2003 12:13 PM > > To: Adrangi, Farid > > Cc: mip4@ietf.org > > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > > > Please see my reply below. > > > > Thanks, > > Jayshree > > -----Original Message----- > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > Sent: Sunday, August 03, 2003 11:50 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: mip4@ietf.org > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > Hello Jayshree, > > > Thanks for following up on this. You, Gopal, and I had a very brief > > > conversation on this during IETF-57 - but I am not sure if we > > > derived any conclusion on whether or not we should include this > > > scenario. To be frank, I don't quite understand the point behind > > > adding this scenario because, > > > - It seems to present a solution to a specific deployment > > > model rather than a deployment scenario > > > > [JB] My understanding is different from yours so please elaborate what > > you mean by deployment model vs deployment scenario in this particular > > context. > > > > > - I don't quite see the advantages of a combined VPN+FA if it > > > does not support FA traversal and it does not avoid IPsec > > > renegotiation when MN moves from one subnet to another - perhaps you > > > can elaborate on this? > > > > [JB] I think regardless this scenario has any advantages or not, it is > > one of the probable scenario which has potential issues (as you have > > indicated earlier). > > > > > - Furthermore, Scenarios in section 2 of the problem statement > > > draft represents combinations of MIPv4 HA and VPN gateway placement > > > - adding this scenario is going to change semantics of the section > > > 2. > > > > [JB] I am not sure what you mean by semantics change here. Do you > > think documenting this in new subsection (2.6) is a problem? > > > > > I have no problem adding this scenario to the draft - I just wanted > > > to make sure that we clearly understand the reasons for adding this > > > scenario to the problem statement draft. Design team members and > > > interested individuals are welcome to express their opinion on this. > > > > > > > > > Best regards, > > > Farid > > > > > > > > > > > > The following sub-sections introduce five representative > > combinations of MIPv4 HA and VPN gateway placement. > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > Sent: Thursday, July 31, 2003 1:44 PM > > To: Adrangi, Farid > > Cc: 'mip4@ietf.org' > > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > > > As per our earlier discussion during IETF-57, my understanding is that > > you will include the scenario of co-existed FA with the VPN gateway in > > the VPN Problem Statement draft. > > > > I agree that this particular scenario has problems and it won't work > > if the MN is behind an FA in the foreign subnet. But again, this is a > > problem statement draft. Hence, I believe that this is the appropriate > > document for > > mentioning this scenario. > > > > Thanks, > > Jayshree > > > > -----Original Message----- > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > Sent: Monday, April 07, 2003 2:58 PM > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > Subject: RE: Comments on VPN Problem Statement Draft > > Hello Jayshree > > This is a good point - I knew someone was to bring this up! At the > > time of writing these scenarios, we (the design team) actually > > discussed this and concluded this scenario would fall into a solution > > space. Maybe we did not make the right decision and we should rethink > > this. But, before we take this discussion further please allow me to > > ask you a few questions about the details of the scenario (VPN+FA) > > that you have in mind . Are you thinking to broadcast FA > > advertisements through the IPsec tunnel to the MN? If so, how will > > this work if MN is already behind an FA in the foreign subnet? Or, If > > you had something different in mind, perhaps you can elaborate on > > that. Best regards, > > Farid > > > > > > -----Original Message----- > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > > Sent: Friday, April 04, 2003 3:14 PM > > To: 'farid.adrangi@intel.com' > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > Subject: Comments on VPN Problem Statement Draft > > > > Hello Farid, > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > currently misses one scenario were the FA is co-existed with the VPN > > Gateway. I would think that there are no technical issues supporting > > this scenario. It will be good if you can add this scenario in the > > draft (perhaps as section 2.6?) for completeness. > > Thanks, > > Jayshree > > > > >_______________________________________________ >Mip4 mailing list >Mip4@ietf.org >https://www.ietf.org/mailman/listinfo/mip4 _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 17:03:42 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 RAA18816 for ; Thu, 28 Aug 2003 17:03:41 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQqW-0004BH-1p for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 13:46:08 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SHk72G016062 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 13:46:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sN8w-0001qg-DK for mip4-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 09:48:54 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15152 for ; Thu, 28 Aug 2003 09:48:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sN8u-0007Kg-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 09:48:52 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sN8t-0007Kc-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 09:48:51 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKly-0001sJ-LB; Thu, 28 Aug 2003 07:17:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sI56-0007KA-60 for mip4@optimus.ietf.org; Thu, 28 Aug 2003 04:24:36 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16143 for ; Thu, 28 Aug 2003 04:24:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sI53-0007IK-00 for mip4@ietf.org; Thu, 28 Aug 2003 04:24:33 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19sI51-0007Gt-00 for mip4@ietf.org; Thu, 28 Aug 2003 04:24:32 -0400 Received: (qmail 3496 invoked from network); 28 Aug 2003 08:24:00 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 28 Aug 2003 08:24:00 -0000 Date: Thu, 28 Aug 2003 10:23:59 +0200 From: Henrik Levkowetz To: Gopal Dommety Cc: ietf-mip-vpn@liqwidnet.com, mip4@ietf.org, "Adrangi, Farid" Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft Message-Id: <20030828102359.70279f6c.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030827161326.028205d0@mira-sjcm-3.cisco.com> References: <4.3.2.7.2.20030827161326.028205d0@mira-sjcm-3.cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.TxzHHzU6XSopQS" 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: , --=.TxzHHzU6XSopQS Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi Gopal, So you see this scenario as one of the possible problem scenarios we potentially would need to solve? Henrik Wednesday 27 August 2003, Gopal wrote: > Farid and Henrik, > > It would make sense to add the scenario that jayshree was bringing > up. This was what I was bringing up during the initial discussion. > > -Gopal > > > At 12:15 PM 8/26/2003 +0200, Henrik Levkowetz wrote: > >Hi, > > > > > > > > I'm picking up this thread and putting it onto the main mip4 list. > >Please remove the mip-vpn design team list address from future replies. > > > >I would like to see this draft sent up to the IESG for consideration > >ASAP. In case we get (unexpected) pushback, it would be good to get it > >before the solutions draft is complete... > > > >Please respond to Farid's query below, so we can wrap this up. If any > >other minor adjustments are needed as a result of the WG last call, I'd > >like them done and an updated draft out soon; at which point we will > >send it to the ADs. If there are no adjustments to be done, we'll send > >up the current draft ( -03 ). > > > >Let's get's this one shipped, shall we? > > > > > > > > > > > >As Section 2 of the draft explicitly discusses possible placements of HA > >vs. VPN-GW, and (as we discussed in the design team) the co-location of > >an FA with the VPN-GW is a possible optimization feature of a solution > >to the problems posed, rather than a separate problem scenario, my > >viewpoint is that we should not put this in the problem statement draft. > > > >It should be described properly in a vpn-traversal optimization draft, > >though. > > > > > > > > Regards, > > Henrik > > > > > > > > > > > >On Tuesday, 12 Aug 2003, Farid wrote: > > > Hello All, > > > What do you think about Jayshree's request to add a new scenario to > > > the problem statement draft? > > > BR, > > > Farid > > > > > > -----Original Message----- > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > To: Adrangi, Farid > > > Cc: mip4@ietf.org > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > > > > Please see my reply below. > > > > > > Thanks, > > > Jayshree > > > -----Original Message----- > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > Sent: Sunday, August 03, 2003 11:50 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: mip4@ietf.org > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > Hello Jayshree, > > > > Thanks for following up on this. You, Gopal, and I had a very brief > > > > conversation on this during IETF-57 - but I am not sure if we > > > > derived any conclusion on whether or not we should include this > > > > scenario. To be frank, I don't quite understand the point behind > > > > adding this scenario because, > > > > - It seems to present a solution to a specific deployment > > > > model rather than a deployment scenario > > > > > > [JB] My understanding is different from yours so please elaborate what > > > you mean by deployment model vs deployment scenario in this particular > > > context. > > > > > > > - I don't quite see the advantages of a combined VPN+FA if it > > > > does not support FA traversal and it does not avoid IPsec > > > > renegotiation when MN moves from one subnet to another - perhaps you > > > > can elaborate on this? > > > > > > [JB] I think regardless this scenario has any advantages or not, it is > > > one of the probable scenario which has potential issues (as you have > > > indicated earlier). > > > > > > > - Furthermore, Scenarios in section 2 of the problem statement > > > > draft represents combinations of MIPv4 HA and VPN gateway placement > > > > - adding this scenario is going to change semantics of the section > > > > 2. > > > > > > [JB] I am not sure what you mean by semantics change here. Do you > > > think documenting this in new subsection (2.6) is a problem? > > > > > > > I have no problem adding this scenario to the draft - I just wanted > > > > to make sure that we clearly understand the reasons for adding this > > > > scenario to the problem statement draft. Design team members and > > > > interested individuals are welcome to express their opinion on this. > > > > > > > > > > > > Best regards, > > > > Farid > > > > > > > > > > > > > > > > > > The following sub-sections introduce five representative > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > -----Original Message----- > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > Sent: Thursday, July 31, 2003 1:44 PM > > > To: Adrangi, Farid > > > Cc: 'mip4@ietf.org' > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > > > > As per our earlier discussion during IETF-57, my understanding is that > > > you will include the scenario of co-existed FA with the VPN gateway in > > > the VPN Problem Statement draft. > > > > > > I agree that this particular scenario has problems and it won't work > > > if the MN is behind an FA in the foreign subnet. But again, this is a > > > problem statement draft. Hence, I believe that this is the appropriate > > > document for > > > mentioning this scenario. > > > > > > Thanks, > > > Jayshree > > > > > > -----Original Message----- > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > Sent: Monday, April 07, 2003 2:58 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: Comments on VPN Problem Statement Draft > > > Hello Jayshree > > > This is a good point - I knew someone was to bring this up! At the > > > time of writing these scenarios, we (the design team) actually > > > discussed this and concluded this scenario would fall into a solution > > > space. Maybe we did not make the right decision and we should rethink > > > this. But, before we take this discussion further please allow me to > > > ask you a few questions about the details of the scenario (VPN+FA) > > > that you have in mind . Are you thinking to broadcast FA > > > advertisements through the IPsec tunnel to the MN? If so, how will > > > this work if MN is already behind an FA in the foreign subnet? Or, If > > > you had something different in mind, perhaps you can elaborate on > > > that. Best regards, > > > Farid > > > > > > > > > -----Original Message----- > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > > > Sent: Friday, April 04, 2003 3:14 PM > > > To: 'farid.adrangi@intel.com' > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > currently misses one scenario were the FA is co-existed with the VPN > > > Gateway. I would think that there are no technical issues supporting > > > this scenario. It will be good if you can add this scenario in the > > > draft (perhaps as section 2.6?) for completeness. > > > Thanks, > > > Jayshree > > > > > > > > >_______________________________________________ > >Mip4 mailing list > >Mip4@ietf.org > >https://www.ietf.org/mailman/listinfo/mip4 > > > _______________________________________________ > Mip4 mailing list > Mip4@ietf.org > https://www.ietf.org/mailman/listinfo/mip4 > --=.TxzHHzU6XSopQS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TbwfeVhrtTJkXCMRAtDdAJ4ypfNlQOEknrsbMNC/qWZajAAlPwCfYEMT PSuV7wwIGYOi0hQ9DkBbYII= =80YV -----END PGP SIGNATURE----- --=.TxzHHzU6XSopQS-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 17:20:47 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 RAA20057 for ; Thu, 28 Aug 2003 17:20:47 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQqs-0004Cs-Ec for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 13:46:30 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7SHkUHf016160 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 13:46:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sN9T-0001uF-9J for mip4-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 09:49: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 JAA15179 for ; Thu, 28 Aug 2003 09:49:21 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sN9R-0007LH-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 09:49:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sN9Q-0007LE-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 09:49:24 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sKk4-0001fW-1T; Thu, 28 Aug 2003 07:15:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sIGf-0007ys-0v for mip4@optimus.ietf.org; Thu, 28 Aug 2003 04:36:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17304 for ; Thu, 28 Aug 2003 04:36:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sIGb-0007bS-00 for mip4@ietf.org; Thu, 28 Aug 2003 04:36:29 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19sIGa-0007ab-00 for mip4@ietf.org; Thu, 28 Aug 2003 04:36:28 -0400 Received: (qmail 3542 invoked from network); 28 Aug 2003 08:35:54 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 28 Aug 2003 08:35:54 -0000 Date: Thu, 28 Aug 2003 10:35:53 +0200 From: Henrik Levkowetz Cc: gdommety@cisco.com, mip4@ietf.org, "Adrangi, Farid" Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft Message-Id: <20030828103553.7f8a1f26.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030827161646.02827e70@mira-sjcm-3.cisco.com> References: <4.3.2.7.2.20030827161646.02827e70@mira-sjcm-3.cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.IW1krJW.dSY1qv" 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: , --=.IW1krJW.dSY1qv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit The way I tally it, we currently have 2 for (Jayshree, Gopal), 2 against (Farid, Henrik) which makes it neither here nor there as far as rough consensus goes. We'll have to get some more feedback on this before moving on, either way. Dorothy? Sami? Espen? Milind? Nitsan? Qiang? Others? Please comment. Regards, Henrik Wednesday 27 August 2003, Gopal wrote: > Henrik, > > We should ship this with the added scenario. Do we have an agreement to add > the scenario. > > -Gopal > > At 12:15 PM 8/26/2003 +0200, Henrik Levkowetz wrote: > >Hi, > > > > > > > > I'm picking up this thread and putting it onto the main mip4 list. > >Please remove the mip-vpn design team list address from future replies. > > > >I would like to see this draft sent up to the IESG for consideration > >ASAP. In case we get (unexpected) pushback, it would be good to get it > >before the solutions draft is complete... > > > >Please respond to Farid's query below, so we can wrap this up. If any > >other minor adjustments are needed as a result of the WG last call, I'd > >like them done and an updated draft out soon; at which point we will > >send it to the ADs. If there are no adjustments to be done, we'll send > >up the current draft ( -03 ). > > > >Let's get's this one shipped, shall we? > > > > > > > > > > > >As Section 2 of the draft explicitly discusses possible placements of HA > >vs. VPN-GW, and (as we discussed in the design team) the co-location of > >an FA with the VPN-GW is a possible optimization feature of a solution > >to the problems posed, rather than a separate problem scenario, my > >viewpoint is that we should not put this in the problem statement draft. > > > >It should be described properly in a vpn-traversal optimization draft, > >though. > > > > > > > > Regards, > > Henrik > > > > > > > > > > > >On Tuesday, 12 Aug 2003, Farid wrote: > > > Hello All, > > > What do you think about Jayshree's request to add a new scenario to > > > the problem statement draft? > > > BR, > > > Farid > > > > > > -----Original Message----- > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > To: Adrangi, Farid > > > Cc: mip4@ietf.org > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > > > > Please see my reply below. > > > > > > Thanks, > > > Jayshree > > > -----Original Message----- > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > Sent: Sunday, August 03, 2003 11:50 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: mip4@ietf.org > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > Hello Jayshree, > > > > Thanks for following up on this. You, Gopal, and I had a very brief > > > > conversation on this during IETF-57 - but I am not sure if we > > > > derived any conclusion on whether or not we should include this > > > > scenario. To be frank, I don't quite understand the point behind > > > > adding this scenario because, > > > > - It seems to present a solution to a specific deployment > > > > model rather than a deployment scenario > > > > > > [JB] My understanding is different from yours so please elaborate what > > > you mean by deployment model vs deployment scenario in this particular > > > context. > > > > > > > - I don't quite see the advantages of a combined VPN+FA if it > > > > does not support FA traversal and it does not avoid IPsec > > > > renegotiation when MN moves from one subnet to another - perhaps you > > > > can elaborate on this? > > > > > > [JB] I think regardless this scenario has any advantages or not, it is > > > one of the probable scenario which has potential issues (as you have > > > indicated earlier). > > > > > > > - Furthermore, Scenarios in section 2 of the problem statement > > > > draft represents combinations of MIPv4 HA and VPN gateway placement > > > > - adding this scenario is going to change semantics of the section > > > > 2. > > > > > > [JB] I am not sure what you mean by semantics change here. Do you > > > think documenting this in new subsection (2.6) is a problem? > > > > > > > I have no problem adding this scenario to the draft - I just wanted > > > > to make sure that we clearly understand the reasons for adding this > > > > scenario to the problem statement draft. Design team members and > > > > interested individuals are welcome to express their opinion on this. > > > > > > > > > > > > Best regards, > > > > Farid > > > > > > > > > > > > > > > > > > The following sub-sections introduce five representative > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > -----Original Message----- > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > Sent: Thursday, July 31, 2003 1:44 PM > > > To: Adrangi, Farid > > > Cc: 'mip4@ietf.org' > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > > > > As per our earlier discussion during IETF-57, my understanding is that > > > you will include the scenario of co-existed FA with the VPN gateway in > > > the VPN Problem Statement draft. > > > > > > I agree that this particular scenario has problems and it won't work > > > if the MN is behind an FA in the foreign subnet. But again, this is a > > > problem statement draft. Hence, I believe that this is the appropriate > > > document for > > > mentioning this scenario. > > > > > > Thanks, > > > Jayshree > > > > > > -----Original Message----- > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > Sent: Monday, April 07, 2003 2:58 PM > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: RE: Comments on VPN Problem Statement Draft > > > Hello Jayshree > > > This is a good point - I knew someone was to bring this up! At the > > > time of writing these scenarios, we (the design team) actually > > > discussed this and concluded this scenario would fall into a solution > > > space. Maybe we did not make the right decision and we should rethink > > > this. But, before we take this discussion further please allow me to > > > ask you a few questions about the details of the scenario (VPN+FA) > > > that you have in mind . Are you thinking to broadcast FA > > > advertisements through the IPsec tunnel to the MN? If so, how will > > > this work if MN is already behind an FA in the foreign subnet? Or, If > > > you had something different in mind, perhaps you can elaborate on > > > that. Best regards, > > > Farid > > > > > > > > > -----Original Message----- > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > > > Sent: Friday, April 04, 2003 3:14 PM > > > To: 'farid.adrangi@intel.com' > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > Subject: Comments on VPN Problem Statement Draft > > > > > > Hello Farid, > > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > currently misses one scenario were the FA is co-existed with the VPN > > > Gateway. I would think that there are no technical issues supporting > > > this scenario. It will be good if you can add this scenario in the > > > draft (perhaps as section 2.6?) for completeness. > > > Thanks, > > > Jayshree > > > > > > > > >_______________________________________________ > >Mip4 mailing list > >Mip4@ietf.org > >https://www.ietf.org/mailman/listinfo/mip4 > > --=.IW1krJW.dSY1qv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Tb7qeVhrtTJkXCMRAlEBAKCDO+0+v4jA0yryXoORVFxBJJ5RFACg0/aU pI+HZxBaYLQQjHQbRk9aZ8g= =DVs4 -----END PGP SIGNATURE----- --=.IW1krJW.dSY1qv-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 22:45:09 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 WAA14681 for ; Thu, 28 Aug 2003 22:45:09 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sWoA-0004Lu-4V for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 20:08:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T086KE016726 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 20:08:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sVlj-0001QK-Sy for mip4-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 19:01: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 TAA28074 for ; Thu, 28 Aug 2003 19:01:24 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sVld-00011R-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 19:01:25 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sVld-00011O-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 19:01:25 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sRy5-0007LG-Pg; Thu, 28 Aug 2003 14:58:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQbv-0002ha-Vs for mip4@optimus.ietf.org; Thu, 28 Aug 2003 13:31:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02924 for ; Thu, 28 Aug 2003 13:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sQbt-0003TB-00 for mip4@ietf.org; Thu, 28 Aug 2003 13:31:01 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19sQbs-0003Sr-00 for mip4@ietf.org; Thu, 28 Aug 2003 13:31:00 -0400 Received: (qmail 4009 invoked from network); 28 Aug 2003 17:30:23 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 28 Aug 2003 17:30:23 -0000 Date: Thu, 28 Aug 2003 19:30:22 +0200 From: Henrik Levkowetz To: Gopal Dommety Cc: mip4@ietf.org, "Adrangi, Farid" Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft Message-Id: <20030828193022.0582fb2a.henrik@levkowetz.com> In-Reply-To: <4.3.2.7.2.20030828094448.0297c7b0@mira-sjcm-3.cisco.com> References: <4.3.2.7.2.20030827161646.02827e70@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030827161646.02827e70@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030828094448.0297c7b0@mira-sjcm-3.cisco.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.2C,u79PMpHe:8E" 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: , --=.2C,u79PMpHe:8E Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit But the way I understand it, this scenario is not a problem, but rather a component in one of the possible (optimized) solutions, which is why it doesn't quite make sense to me to put it in the problem statement ? Henrik Thursday 28 August 2003, Gopal wrote: > > My recommendation is to documet the sceanrio and not to solve it. > > > At 10:35 AM 8/28/2003 +0200, Henrik Levkowetz wrote: > >The way I tally it, we currently have 2 for (Jayshree, Gopal), 2 against > >(Farid, Henrik) which makes it neither here nor there as far as rough > >consensus goes. We'll have to get some more feedback on this before moving > >on, either way. Dorothy? Sami? Espen? Milind? Nitsan? Qiang? Others? > >Please comment. > > > > Regards, > > Henrik > > > >Wednesday 27 August 2003, Gopal wrote: > > > Henrik, > > > > > > We should ship this with the added scenario. Do we have an agreement to > > add > > > the scenario. > > > > > > -Gopal > > > > > > At 12:15 PM 8/26/2003 +0200, Henrik Levkowetz wrote: > > > >Hi, > > > > > > > > > > > > > > > > I'm picking up this thread and putting it onto the main mip4 > > list. > > > >Please remove the mip-vpn design team list address from future replies. > > > > > > > >I would like to see this draft sent up to the IESG for consideration > > > >ASAP. In case we get (unexpected) pushback, it would be good to get it > > > >before the solutions draft is complete... > > > > > > > >Please respond to Farid's query below, so we can wrap this up. If any > > > >other minor adjustments are needed as a result of the WG last call, I'd > > > >like them done and an updated draft out soon; at which point we will > > > >send it to the ADs. If there are no adjustments to be done, we'll send > > > >up the current draft ( -03 ). > > > > > > > >Let's get's this one shipped, shall we? > > > > > > > > > > > > > > > > > > > > > > > >As Section 2 of the draft explicitly discusses possible placements of HA > > > >vs. VPN-GW, and (as we discussed in the design team) the co-location of > > > >an FA with the VPN-GW is a possible optimization feature of a solution > > > >to the problems posed, rather than a separate problem scenario, my > > > >viewpoint is that we should not put this in the problem statement draft. > > > > > > > >It should be described properly in a vpn-traversal optimization draft, > > > >though. > > > > > > > > > > > > > > > > Regards, > > > > Henrik > > > > > > > > > > > > > > > > > > > > > > > >On Tuesday, 12 Aug 2003, Farid wrote: > > > > > Hello All, > > > > > What do you think about Jayshree's request to add a new scenario to > > > > > the problem statement draft? > > > > > BR, > > > > > Farid > > > > > > > > > > -----Original Message----- > > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > To: Adrangi, Farid > > > > > Cc: mip4@ietf.org > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > Hello Farid, > > > > > > > > > > Please see my reply below. > > > > > > > > > > Thanks, > > > > > Jayshree > > > > > -----Original Message----- > > > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Cc: mip4@ietf.org > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > Thanks for following up on this. You, Gopal, and I had a very brief > > > > > > conversation on this during IETF-57 - but I am not sure if we > > > > > > derived any conclusion on whether or not we should include this > > > > > > scenario. To be frank, I don't quite understand the point behind > > > > > > adding this scenario because, > > > > > > - It seems to present a solution to a specific deployment > > > > > > model rather than a deployment scenario > > > > > > > > > > [JB] My understanding is different from yours so please elaborate what > > > > > you mean by deployment model vs deployment scenario in this particular > > > > > context. > > > > > > > > > > > - I don't quite see the advantages of a combined VPN+FA if it > > > > > > does not support FA traversal and it does not avoid IPsec > > > > > > renegotiation when MN moves from one subnet to another - perhaps you > > > > > > can elaborate on this? > > > > > > > > > > [JB] I think regardless this scenario has any advantages or not, it is > > > > > one of the probable scenario which has potential issues (as you have > > > > > indicated earlier). > > > > > > > > > > > - Furthermore, Scenarios in section 2 of the problem statement > > > > > > draft represents combinations of MIPv4 HA and VPN gateway placement > > > > > > - adding this scenario is going to change semantics of the section > > > > > > 2. > > > > > > > > > > [JB] I am not sure what you mean by semantics change here. Do you > > > > > think documenting this in new subsection (2.6) is a problem? > > > > > > > > > > > I have no problem adding this scenario to the draft - I just wanted > > > > > > to make sure that we clearly understand the reasons for adding this > > > > > > scenario to the problem statement draft. Design team members and > > > > > > interested individuals are welcome to express their opinion on this. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five representative > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > -----Original Message----- > > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > To: Adrangi, Farid > > > > > Cc: 'mip4@ietf.org' > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > Hello Farid, > > > > > > > > > > As per our earlier discussion during IETF-57, my understanding is that > > > > > you will include the scenario of co-existed FA with the VPN gateway in > > > > > the VPN Problem Statement draft. > > > > > > > > > > I agree that this particular scenario has problems and it won't work > > > > > if the MN is behind an FA in the foreign subnet. But again, this is a > > > > > problem statement draft. Hence, I believe that this is the appropriate > > > > > document for > > > > > mentioning this scenario. > > > > > > > > > > Thanks, > > > > > Jayshree > > > > > > > > > > -----Original Message----- > > > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > Hello Jayshree > > > > > This is a good point - I knew someone was to bring this up! At the > > > > > time of writing these scenarios, we (the design team) actually > > > > > discussed this and concluded this scenario would fall into a solution > > > > > space. Maybe we did not make the right decision and we should rethink > > > > > this. But, before we take this discussion further please allow me to > > > > > ask you a few questions about the details of the scenario (VPN+FA) > > > > > that you have in mind . Are you thinking to broadcast FA > > > > > advertisements through the IPsec tunnel to the MN? If so, how will > > > > > this work if MN is already behind an FA in the foreign subnet? Or, If > > > > > you had something different in mind, perhaps you can elaborate on > > > > > that. Best regards, > > > > > Farid > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > To: 'farid.adrangi@intel.com' > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > Hello Farid, > > > > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > currently misses one scenario were the FA is co-existed with the VPN > > > > > Gateway. I would think that there are no technical issues supporting > > > > > this scenario. It will be good if you can add this scenario in the > > > > > draft (perhaps as section 2.6?) for completeness. > > > > > Thanks, > > > > > Jayshree > > > > > > > > > > > > > > > > >_______________________________________________ > > > >Mip4 mailing list > > > >Mip4@ietf.org > > > >https://www.ietf.org/mailman/listinfo/mip4 > > > > > > > > > > --=.2C,u79PMpHe:8E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/TjwveVhrtTJkXCMRAmQ1AJ4oTNkTCvdhoyGrAA01H8RKcZ23UwCeLkrH W3TxoargLfZ5yMlI4sdNN3U= =e183 -----END PGP SIGNATURE----- --=.2C,u79PMpHe:8E-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Thu Aug 28 23:23: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 XAA18078 for ; Thu, 28 Aug 2003 23:23: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 19sWws-000508-EZ for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 20:17:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T0H6H1019214 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 20:17:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sVQE-0000ru-Fd for mip4-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 18:39: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 SAA26571 for ; Thu, 28 Aug 2003 18:39:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sVQB-0000hO-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 18:39:15 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sVQB-0000hL-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 18:39:15 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSXv-0000RJ-LS; Thu, 28 Aug 2003 15:35:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sPtf-0000ii-LA for mip4@optimus.ietf.org; Thu, 28 Aug 2003 12:45: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 MAA29258 for ; Thu, 28 Aug 2003 12:45:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sPtd-0002Yb-00 for mip4@ietf.org; Thu, 28 Aug 2003 12:45:17 -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 19sPtd-0002Y1-00 for mip4@ietf.org; Thu, 28 Aug 2003 12:45:17 -0400 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 28 Aug 2003 09:44:47 -0700 Received: from gdommety-w2k01.cisco.com (sjc-vpn3-533.cisco.com [10.21.66.21]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h7SGibgN023964; Thu, 28 Aug 2003 09:44:40 -0700 (PDT) Message-Id: <4.3.2.7.2.20030828094129.0286abc8@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Aug 2003 09:44:35 -0700 To: Henrik Levkowetz From: Gopal Dommety Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft Cc: ietf-mip-vpn@liqwidnet.com, mip4@ietf.org, "Adrangi, Farid" In-Reply-To: <20030828102359.70279f6c.henrik@levkowetz.com> References: <4.3.2.7.2.20030827161326.028205d0@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030827161326.028205d0@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Henrik, No!!! My recommendation is to document the scenario and state that we are not focus on it currently. I think documenting completes the scenarios. I think there will be a lot of issues to solve for this scenario. Cheers Gopal At 10:23 AM 8/28/2003 +0200, Henrik Levkowetz wrote: >Hi Gopal, > >So you see this scenario as one of the possible problem scenarios we >potentially would need to solve? > > Henrik > >Wednesday 27 August 2003, Gopal wrote: > > Farid and Henrik, > > > > It would make sense to add the scenario that jayshree was bringing > > up. This was what I was bringing up during the initial discussion. > > > > -Gopal > > > > > > At 12:15 PM 8/26/2003 +0200, Henrik Levkowetz wrote: > > >Hi, > > > > > > > > > > > > I'm picking up this thread and putting it onto the main mip4 > list. > > >Please remove the mip-vpn design team list address from future replies. > > > > > >I would like to see this draft sent up to the IESG for consideration > > >ASAP. In case we get (unexpected) pushback, it would be good to get it > > >before the solutions draft is complete... > > > > > >Please respond to Farid's query below, so we can wrap this up. If any > > >other minor adjustments are needed as a result of the WG last call, I'd > > >like them done and an updated draft out soon; at which point we will > > >send it to the ADs. If there are no adjustments to be done, we'll send > > >up the current draft ( -03 ). > > > > > >Let's get's this one shipped, shall we? > > > > > > > > > > > > > > > > > >As Section 2 of the draft explicitly discusses possible placements of HA > > >vs. VPN-GW, and (as we discussed in the design team) the co-location of > > >an FA with the VPN-GW is a possible optimization feature of a solution > > >to the problems posed, rather than a separate problem scenario, my > > >viewpoint is that we should not put this in the problem statement draft. > > > > > >It should be described properly in a vpn-traversal optimization draft, > > >though. > > > > > > > > > > > > Regards, > > > Henrik > > > > > > > > > > > > > > > > > >On Tuesday, 12 Aug 2003, Farid wrote: > > > > Hello All, > > > > What do you think about Jayshree's request to add a new scenario to > > > > the problem statement draft? > > > > BR, > > > > Farid > > > > > > > > -----Original Message----- > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > To: Adrangi, Farid > > > > Cc: mip4@ietf.org > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > Hello Farid, > > > > > > > > Please see my reply below. > > > > > > > > Thanks, > > > > Jayshree > > > > -----Original Message----- > > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: mip4@ietf.org > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > Hello Jayshree, > > > > > Thanks for following up on this. You, Gopal, and I had a very brief > > > > > conversation on this during IETF-57 - but I am not sure if we > > > > > derived any conclusion on whether or not we should include this > > > > > scenario. To be frank, I don't quite understand the point behind > > > > > adding this scenario because, > > > > > - It seems to present a solution to a specific deployment > > > > > model rather than a deployment scenario > > > > > > > > [JB] My understanding is different from yours so please elaborate what > > > > you mean by deployment model vs deployment scenario in this particular > > > > context. > > > > > > > > > - I don't quite see the advantages of a combined VPN+FA if it > > > > > does not support FA traversal and it does not avoid IPsec > > > > > renegotiation when MN moves from one subnet to another - perhaps you > > > > > can elaborate on this? > > > > > > > > [JB] I think regardless this scenario has any advantages or not, it is > > > > one of the probable scenario which has potential issues (as you have > > > > indicated earlier). > > > > > > > > > - Furthermore, Scenarios in section 2 of the problem statement > > > > > draft represents combinations of MIPv4 HA and VPN gateway placement > > > > > - adding this scenario is going to change semantics of the section > > > > > 2. > > > > > > > > [JB] I am not sure what you mean by semantics change here. Do you > > > > think documenting this in new subsection (2.6) is a problem? > > > > > > > > > I have no problem adding this scenario to the draft - I just wanted > > > > > to make sure that we clearly understand the reasons for adding this > > > > > scenario to the problem statement draft. Design team members and > > > > > interested individuals are welcome to express their opinion on this. > > > > > > > > > > > > > > > Best regards, > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five representative > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > -----Original Message----- > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > To: Adrangi, Farid > > > > Cc: 'mip4@ietf.org' > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > Hello Farid, > > > > > > > > As per our earlier discussion during IETF-57, my understanding is that > > > > you will include the scenario of co-existed FA with the VPN gateway in > > > > the VPN Problem Statement draft. > > > > > > > > I agree that this particular scenario has problems and it won't work > > > > if the MN is behind an FA in the foreign subnet. But again, this is a > > > > problem statement draft. Hence, I believe that this is the appropriate > > > > document for > > > > mentioning this scenario. > > > > > > > > Thanks, > > > > Jayshree > > > > > > > > -----Original Message----- > > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Jayshree > > > > This is a good point - I knew someone was to bring this up! At the > > > > time of writing these scenarios, we (the design team) actually > > > > discussed this and concluded this scenario would fall into a solution > > > > space. Maybe we did not make the right decision and we should rethink > > > > this. But, before we take this discussion further please allow me to > > > > ask you a few questions about the details of the scenario (VPN+FA) > > > > that you have in mind . Are you thinking to broadcast FA > > > > advertisements through the IPsec tunnel to the MN? If so, how will > > > > this work if MN is already behind an FA in the foreign subnet? Or, If > > > > you had something different in mind, perhaps you can elaborate on > > > > that. Best regards, > > > > Farid > > > > > > > > > > > > -----Original Message----- > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > To: 'farid.adrangi@intel.com' > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > Hello Farid, > > > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > currently misses one scenario were the FA is co-existed with the VPN > > > > Gateway. I would think that there are no technical issues supporting > > > > this scenario. It will be good if you can add this scenario in the > > > > draft (perhaps as section 2.6?) for completeness. > > > > Thanks, > > > > Jayshree > > > > > > > > > > > > >_______________________________________________ > > >Mip4 mailing list > > >Mip4@ietf.org > > >https://www.ietf.org/mailman/listinfo/mip4 > > > > > > _______________________________________________ > > Mip4 mailing list > > Mip4@ietf.org > > https://www.ietf.org/mailman/listinfo/mip4 > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Aug 29 00:37: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 AAA24562 for ; Fri, 29 Aug 2003 00:37: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 19sXEM-0005qk-8n for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 20:35:10 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T0ZANZ022476 for mip4-archive@odin.ietf.org; Thu, 28 Aug 2003 20:35:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sSxz-0001pU-8f for mip4-web-archive@optimus.ietf.org; Thu, 28 Aug 2003 16:01:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13903 for ; Thu, 28 Aug 2003 16:01:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sSxx-0005mo-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 16:01:57 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sSxx-0005mk-00 for mip4-web-archive@ietf.org; Thu, 28 Aug 2003 16:01:57 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sShZ-00016k-Vt; Thu, 28 Aug 2003 15: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 19sPuJ-0000kf-8g for mip4@optimus.ietf.org; Thu, 28 Aug 2003 12:45:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29307 for ; Thu, 28 Aug 2003 12:45:52 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sPuH-0002Za-00 for mip4@ietf.org; Thu, 28 Aug 2003 12:45:57 -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 19sPuG-0002Yf-00 for mip4@ietf.org; Thu, 28 Aug 2003 12:45:56 -0400 Received: from cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Aug 2003 09:45:27 -0700 Received: from gdommety-w2k01.cisco.com (sjc-vpn3-533.cisco.com [10.21.66.21]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h7SGjECc010870; Thu, 28 Aug 2003 09:45:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20030828094448.0297c7b0@mira-sjcm-3.cisco.com> X-Sender: gdommety@mira-sjcm-3.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Aug 2003 09:45:12 -0700 To: Henrik Levkowetz From: Gopal Dommety Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft Cc: mip4@ietf.org, "Adrangi, Farid" In-Reply-To: <20030828103553.7f8a1f26.henrik@levkowetz.com> References: <4.3.2.7.2.20030827161646.02827e70@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030827161646.02827e70@mira-sjcm-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , My recommendation is to documet the sceanrio and not to solve it. At 10:35 AM 8/28/2003 +0200, Henrik Levkowetz wrote: >The way I tally it, we currently have 2 for (Jayshree, Gopal), 2 against >(Farid, Henrik) which makes it neither here nor there as far as rough >consensus goes. We'll have to get some more feedback on this before moving >on, either way. Dorothy? Sami? Espen? Milind? Nitsan? Qiang? Others? >Please comment. > > Regards, > Henrik > >Wednesday 27 August 2003, Gopal wrote: > > Henrik, > > > > We should ship this with the added scenario. Do we have an agreement to > add > > the scenario. > > > > -Gopal > > > > At 12:15 PM 8/26/2003 +0200, Henrik Levkowetz wrote: > > >Hi, > > > > > > > > > > > > I'm picking up this thread and putting it onto the main mip4 > list. > > >Please remove the mip-vpn design team list address from future replies. > > > > > >I would like to see this draft sent up to the IESG for consideration > > >ASAP. In case we get (unexpected) pushback, it would be good to get it > > >before the solutions draft is complete... > > > > > >Please respond to Farid's query below, so we can wrap this up. If any > > >other minor adjustments are needed as a result of the WG last call, I'd > > >like them done and an updated draft out soon; at which point we will > > >send it to the ADs. If there are no adjustments to be done, we'll send > > >up the current draft ( -03 ). > > > > > >Let's get's this one shipped, shall we? > > > > > > > > > > > > > > > > > >As Section 2 of the draft explicitly discusses possible placements of HA > > >vs. VPN-GW, and (as we discussed in the design team) the co-location of > > >an FA with the VPN-GW is a possible optimization feature of a solution > > >to the problems posed, rather than a separate problem scenario, my > > >viewpoint is that we should not put this in the problem statement draft. > > > > > >It should be described properly in a vpn-traversal optimization draft, > > >though. > > > > > > > > > > > > Regards, > > > Henrik > > > > > > > > > > > > > > > > > >On Tuesday, 12 Aug 2003, Farid wrote: > > > > Hello All, > > > > What do you think about Jayshree's request to add a new scenario to > > > > the problem statement draft? > > > > BR, > > > > Farid > > > > > > > > -----Original Message----- > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > To: Adrangi, Farid > > > > Cc: mip4@ietf.org > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > Hello Farid, > > > > > > > > Please see my reply below. > > > > > > > > Thanks, > > > > Jayshree > > > > -----Original Message----- > > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: mip4@ietf.org > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > Hello Jayshree, > > > > > Thanks for following up on this. You, Gopal, and I had a very brief > > > > > conversation on this during IETF-57 - but I am not sure if we > > > > > derived any conclusion on whether or not we should include this > > > > > scenario. To be frank, I don't quite understand the point behind > > > > > adding this scenario because, > > > > > - It seems to present a solution to a specific deployment > > > > > model rather than a deployment scenario > > > > > > > > [JB] My understanding is different from yours so please elaborate what > > > > you mean by deployment model vs deployment scenario in this particular > > > > context. > > > > > > > > > - I don't quite see the advantages of a combined VPN+FA if it > > > > > does not support FA traversal and it does not avoid IPsec > > > > > renegotiation when MN moves from one subnet to another - perhaps you > > > > > can elaborate on this? > > > > > > > > [JB] I think regardless this scenario has any advantages or not, it is > > > > one of the probable scenario which has potential issues (as you have > > > > indicated earlier). > > > > > > > > > - Furthermore, Scenarios in section 2 of the problem statement > > > > > draft represents combinations of MIPv4 HA and VPN gateway placement > > > > > - adding this scenario is going to change semantics of the section > > > > > 2. > > > > > > > > [JB] I am not sure what you mean by semantics change here. Do you > > > > think documenting this in new subsection (2.6) is a problem? > > > > > > > > > I have no problem adding this scenario to the draft - I just wanted > > > > > to make sure that we clearly understand the reasons for adding this > > > > > scenario to the problem statement draft. Design team members and > > > > > interested individuals are welcome to express their opinion on this. > > > > > > > > > > > > > > > Best regards, > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five representative > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > -----Original Message----- > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > To: Adrangi, Farid > > > > Cc: 'mip4@ietf.org' > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > Hello Farid, > > > > > > > > As per our earlier discussion during IETF-57, my understanding is that > > > > you will include the scenario of co-existed FA with the VPN gateway in > > > > the VPN Problem Statement draft. > > > > > > > > I agree that this particular scenario has problems and it won't work > > > > if the MN is behind an FA in the foreign subnet. But again, this is a > > > > problem statement draft. Hence, I believe that this is the appropriate > > > > document for > > > > mentioning this scenario. > > > > > > > > Thanks, > > > > Jayshree > > > > > > > > -----Original Message----- > > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > Hello Jayshree > > > > This is a good point - I knew someone was to bring this up! At the > > > > time of writing these scenarios, we (the design team) actually > > > > discussed this and concluded this scenario would fall into a solution > > > > space. Maybe we did not make the right decision and we should rethink > > > > this. But, before we take this discussion further please allow me to > > > > ask you a few questions about the details of the scenario (VPN+FA) > > > > that you have in mind . Are you thinking to broadcast FA > > > > advertisements through the IPsec tunnel to the MN? If so, how will > > > > this work if MN is already behind an FA in the foreign subnet? Or, If > > > > you had something different in mind, perhaps you can elaborate on > > > > that. Best regards, > > > > Farid > > > > > > > > > > > > -----Original Message----- > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > To: 'farid.adrangi@intel.com' > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > Hello Farid, > > > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > currently misses one scenario were the FA is co-existed with the VPN > > > > Gateway. I would think that there are no technical issues supporting > > > > this scenario. It will be good if you can add this scenario in the > > > > draft (perhaps as section 2.6?) for completeness. > > > > Thanks, > > > > Jayshree > > > > > > > > > > > > >_______________________________________________ > > >Mip4 mailing list > > >Mip4@ietf.org > > >https://www.ietf.org/mailman/listinfo/mip4 > > > > > > _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Fri Aug 29 05:54: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 FAA05584 for ; Fri, 29 Aug 2003 05:54:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sfaj-0003Wv-Nz for mip4-archive@odin.ietf.org; Fri, 29 Aug 2003 05:30:50 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7T9UnfM013568 for mip4-archive@odin.ietf.org; Fri, 29 Aug 2003 05:30:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19se0x-000692-2C for mip4-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 03:49:47 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23585 for ; Fri, 29 Aug 2003 03:49:40 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19se0u-0003oi-00 for mip4-web-archive@ietf.org; Fri, 29 Aug 2003 03:49:44 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19se0t-0003of-00 for mip4-web-archive@ietf.org; Fri, 29 Aug 2003 03:49:43 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19scA2-0005MU-P9; Fri, 29 Aug 2003 01:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sQkq-0003WQ-Cp for mip4@optimus.ietf.org; Thu, 28 Aug 2003 13:40: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 NAA03683 for ; Thu, 28 Aug 2003 13:40:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sQko-0003hJ-00 for mip4@ietf.org; Thu, 28 Aug 2003 13:40:14 -0400 Received: from [63.143.179.146] (helo=email-filesrv) by ietf-mx with esmtp (Exim 4.12) id 19sQkm-0003gK-00 for mip4@ietf.org; Thu, 28 Aug 2003 13:40:12 -0400 Received: from [192.168.100.1] by email-filesrv (ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.1.7)); Thu, 28 Aug 2003 13:28:52 -0400 Message-ID: <053501c36d8a$75647c60$ca64a8c0@LIQWID6JXZJUXA> Reply-To: "Qiang Zhang" From: "Qiang Zhang" To: , "Henrik Levkowetz" Cc: , "Adrangi, Farid" References: <4.3.2.7.2.20030827161326.028205d0@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030827161326.028205d0@mira-sjcm-3.cisco.com> <4.3.2.7.2.20030828094129.0286abc8@mira-sjcm-3.cisco.com> Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft Date: Thu, 28 Aug 2003 13:33:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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 Figure 10 in the Section 4 of problem statement actually presented the scenario. I think it is reasonable to add a 2.6 to make this scenario explicit thus to "complete" as Gopal mentioned. Q ----- Original Message ----- From: "Gopal Dommety" To: "Henrik Levkowetz" Cc: ; ; "Adrangi, Farid" Sent: Thursday, August 28, 2003 12:44 PM Subject: Re: [Mip4] Re: FW: Comments on VPN Problem Statement Draft > Henrik, > > No!!! My recommendation is to document the scenario and state that we are > not focus on it currently. > I think documenting completes the scenarios. I think there will be a lot > of issues to solve for this scenario. > > Cheers > Gopal > > > > > At 10:23 AM 8/28/2003 +0200, Henrik Levkowetz wrote: > >Hi Gopal, > > > >So you see this scenario as one of the possible problem scenarios we > >potentially would need to solve? > > > > Henrik > > > >Wednesday 27 August 2003, Gopal wrote: > > > Farid and Henrik, > > > > > > It would make sense to add the scenario that jayshree was bringing > > > up. This was what I was bringing up during the initial discussion. > > > > > > -Gopal > > > > > > > > > At 12:15 PM 8/26/2003 +0200, Henrik Levkowetz wrote: > > > >Hi, > > > > > > > > > > > > > > > > I'm picking up this thread and putting it onto the main mip4 > > list. > > > >Please remove the mip-vpn design team list address from future replies. > > > > > > > >I would like to see this draft sent up to the IESG for consideration > > > >ASAP. In case we get (unexpected) pushback, it would be good to get it > > > >before the solutions draft is complete... > > > > > > > >Please respond to Farid's query below, so we can wrap this up. If any > > > >other minor adjustments are needed as a result of the WG last call, I'd > > > >like them done and an updated draft out soon; at which point we will > > > >send it to the ADs. If there are no adjustments to be done, we'll send > > > >up the current draft ( -03 ). > > > > > > > >Let's get's this one shipped, shall we? > > > > > > > > > > > > > > > > > > > > > > > >As Section 2 of the draft explicitly discusses possible placements of HA > > > >vs. VPN-GW, and (as we discussed in the design team) the co-location of > > > >an FA with the VPN-GW is a possible optimization feature of a solution > > > >to the problems posed, rather than a separate problem scenario, my > > > >viewpoint is that we should not put this in the problem statement draft. > > > > > > > >It should be described properly in a vpn-traversal optimization draft, > > > >though. > > > > > > > > > > > > > > > > Regards, > > > > Henrik > > > > > > > > > > > > > > > > > > > > > > > >On Tuesday, 12 Aug 2003, Farid wrote: > > > > > Hello All, > > > > > What do you think about Jayshree's request to add a new scenario to > > > > > the problem statement draft? > > > > > BR, > > > > > Farid > > > > > > > > > > -----Original Message----- > > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > > Sent: Wednesday, August 06, 2003 12:13 PM > > > > > To: Adrangi, Farid > > > > > Cc: mip4@ietf.org > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > Hello Farid, > > > > > > > > > > Please see my reply below. > > > > > > > > > > Thanks, > > > > > Jayshree > > > > > -----Original Message----- > > > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > > > Sent: Sunday, August 03, 2003 11:50 PM > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Cc: mip4@ietf.org > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > > > > > > > Hello Jayshree, > > > > > > Thanks for following up on this. You, Gopal, and I had a very brief > > > > > > conversation on this during IETF-57 - but I am not sure if we > > > > > > derived any conclusion on whether or not we should include this > > > > > > scenario. To be frank, I don't quite understand the point behind > > > > > > adding this scenario because, > > > > > > - It seems to present a solution to a specific deployment > > > > > > model rather than a deployment scenario > > > > > > > > > > [JB] My understanding is different from yours so please elaborate what > > > > > you mean by deployment model vs deployment scenario in this particular > > > > > context. > > > > > > > > > > > - I don't quite see the advantages of a combined VPN+FA if it > > > > > > does not support FA traversal and it does not avoid IPsec > > > > > > renegotiation when MN moves from one subnet to another - perhaps you > > > > > > can elaborate on this? > > > > > > > > > > [JB] I think regardless this scenario has any advantages or not, it is > > > > > one of the probable scenario which has potential issues (as you have > > > > > indicated earlier). > > > > > > > > > > > - Furthermore, Scenarios in section 2 of the problem statement > > > > > > draft represents combinations of MIPv4 HA and VPN gateway placement > > > > > > - adding this scenario is going to change semantics of the section > > > > > > 2. > > > > > > > > > > [JB] I am not sure what you mean by semantics change here. Do you > > > > > think documenting this in new subsection (2.6) is a problem? > > > > > > > > > > > I have no problem adding this scenario to the draft - I just wanted > > > > > > to make sure that we clearly understand the reasons for adding this > > > > > > scenario to the problem statement draft. Design team members and > > > > > > interested individuals are welcome to express their opinion on this. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > Farid > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > The following sub-sections introduce five representative > > > > > combinations of MIPv4 HA and VPN gateway placement. > > > > > > > > > > -----Original Message----- > > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com] > > > > > Sent: Thursday, July 31, 2003 1:44 PM > > > > > To: Adrangi, Farid > > > > > Cc: 'mip4@ietf.org' > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > > > > > > Hello Farid, > > > > > > > > > > As per our earlier discussion during IETF-57, my understanding is that > > > > > you will include the scenario of co-existed FA with the VPN gateway in > > > > > the VPN Problem Statement draft. > > > > > > > > > > I agree that this particular scenario has problems and it won't work > > > > > if the MN is behind an FA in the foreign subnet. But again, this is a > > > > > problem statement draft. Hence, I believe that this is the appropriate > > > > > document for > > > > > mentioning this scenario. > > > > > > > > > > Thanks, > > > > > Jayshree > > > > > > > > > > -----Original Message----- > > > > > From: Adrangi, Farid [mailto:farid.adrangi@intel.com] > > > > > Sent: Monday, April 07, 2003 2:58 PM > > > > > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > Subject: RE: Comments on VPN Problem Statement Draft > > > > > Hello Jayshree > > > > > This is a good point - I knew someone was to bring this up! At the > > > > > time of writing these scenarios, we (the design team) actually > > > > > discussed this and concluded this scenario would fall into a solution > > > > > space. Maybe we did not make the right decision and we should rethink > > > > > this. But, before we take this discussion further please allow me to > > > > > ask you a few questions about the details of the scenario (VPN+FA) > > > > > that you have in mind . Are you thinking to broadcast FA > > > > > advertisements through the IPsec tunnel to the MN? If so, how will > > > > > this work if MN is already behind an FA in the foreign subnet? Or, If > > > > > you had something different in mind, perhaps you can elaborate on > > > > > that. Best regards, > > > > > Farid > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Jayshree Bharatia [mailto:jayshree@nortelnetworks.com], > > > > > Sent: Friday, April 04, 2003 3:14 PM > > > > > To: 'farid.adrangi@intel.com' > > > > > Cc: 'mobile-ip@sunroof.eng.sun.com' > > > > > Subject: Comments on VPN Problem Statement Draft > > > > > > > > > > Hello Farid, > > > > > This draft (draft-ietf-mobileip-vpn-problem-statement-req-01) > > > > > currently misses one scenario were the FA is co-existed with the VPN > > > > > Gateway. I would think that there are no technical issues supporting > > > > > this scenario. It will be good if you can add this scenario in the > > > > > draft (perhaps as section 2.6?) for completeness. > > > > > Thanks, > > > > > Jayshree > > > > > > > > > > > > > > > > >_______________________________________________ > > > >Mip4 mailing list > > > >Mip4@ietf.org > > > >https://www.ietf.org/mailman/listinfo/mip4 > > > > > > > > > _______________________________________________ > > > 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 Sat Aug 30 03:12:20 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 DAA27582 for ; Sat, 30 Aug 2003 03:12:19 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19szTu-00061g-Kd for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 02:45:06 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U6j6Qw023151 for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 02:45:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19swly-0005LG-HJ for mip4-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 23:51: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 XAA06615 for ; Fri, 29 Aug 2003 23:51:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19swlw-00051b-00 for mip4-web-archive@ietf.org; Fri, 29 Aug 2003 23:51:32 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19swlv-00051X-00 for mip4-web-archive@ietf.org; Fri, 29 Aug 2003 23:51:31 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svBS-0000eK-1V; Fri, 29 Aug 2003 22:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sqR5-00040d-Jf for mip4@optimus.ietf.org; Fri, 29 Aug 2003 17:05: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 RAA05102 for ; Fri, 29 Aug 2003 17:05:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sqR3-0007FQ-00 for mip4@ietf.org; Fri, 29 Aug 2003 17:05:33 -0400 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 19sqR0-0007EW-00 for mip4@ietf.org; Fri, 29 Aug 2003 17:05: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 h7TL4sw28748; Fri, 29 Aug 2003 16:04:54 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Aug 2003 16:04:55 -0500 Message-ID: <870397D7C140C84DB081B88396458DAF746B3C@zrc2c000.us.nortel.com> From: "Jayshree Bharatia" To: "'Pete McCann'" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Date: Fri, 29 Aug 2003 16:04:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C36E71.1EB4EADE" 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_01C36E71.1EB4EADE Content-Type: text/plain Hi Pete This is not good. Putting all proposals in one email is difficult to manage. The original email itself is of four pages. Hence, it will be good if you can split your responses accordingly. Thanks, Jayshree > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com] > Sent: Friday, August 29, 2003 11:56 AM > To: Bharatia, Jayshree [RICH1:2H13:EXCH] > Cc: 'mip4@ietf.org' > Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change5 > > > > Hi, Jayshree, > > I am reorganizing all the text proposals into this one note > for easier reference. See comments below, and let me know if > I missed one of your notes. > > > [note chair hat is off for the remainder of this message] > > > > The current proposal for issue 1 is to use "previously > unused challenge" in > section 2 for all multicast and > unicast Agent Advertisements. > > I am not sure what you mean by this. Can you give a specific > text proposal, and a location for it in the draft? > > > In addition to this, Henrik proposed a new text for a new > subsection 2.1. > > > > 2.1 Handling of Solicited Agent Advertisements > > > > When a foreign agent generates an Agent Advertisement in > response to a > Router Solicitation [4], some additional > considerations come into play. > According to the Mobile IP > base specification [7], the resulting Agent > Advertisement > may be either multicast or unicast. > > > If the solicited Agent Advertisement is multicast, it MUST > NOT generate a > new Challenge value and update its window > of remembered advertised > Challenges. It must instead > re-use the most recent of the CHALLENGE_WINDOW > > Advertisement Challenge values. > > > If the agent advertisement is unicast back to the > soliciting mobile node > MUST be handled as follows: If the > challenge most recently unicast to the > ^ insert the word "it" > > > soliciting mobile node has not been previously used (as > defined in Section > 1.1), in SHOULD > be repeated in the > newly issued unicast agent advertisement, otherwise a new > > challenge MUST be generated and remembered as the most recent > challenge > issued to the mobile node. (For further > discussion of this, see Section 12.) > > I agree with this so far. > > > A foreign agent SHOULD NOT respond arbitrarily often to > agent solicitations, > in order to limit processing load, > especially in the face of hostile nodes > soliciting at a > very high rate. The rate of solicited agent advertisement > > responses SHOULD at most be 50 per second. > > I am not sure we need the last paragraph. Overload control, > especially the choice of which solicitations to discard, is a > tricky subject. I don't know that we will come to any > agreement on a maximum rate (cf. previous discussions on the > Mobile IP list regarding multicast agent advertisement rates). > > > > The original proposal from Henrik was to mandate a > challenge in a > Registration Reply. After few email > exchanges, it was decided that the > current text in section > 3.3 (RFC3012bis (version 05) ) is ok. In addition to > the > current text, Henrik proposed the following text to be used > as a > guidance/background: > > > (section 3.3) > > One example of a situation where the Foreign Agent MAY > omit the inclusion of > a Mobile-Foreign Challenge Extension > in the Registration Reply would be when > a new challenge > has been multicast recently. The Foreign Agent could then > > assume that the mobile node with high likelihood has received > and can use > the multicast challenge. A mobile node MUST be > prepared to use a multicast > challenge in lieu of one > returned in a Registration Reply, and MUST solicit > for one > if it has not already received one in a Registration Reply or > Agent > Advertisement. > > This is good, but it doesn't seem quite strong enough, i.e., > we still have a SHOULD on the inclusion of the previously > unused challenge. It seems to me we should require (with a > MUST) the inclusion of a challenge in the registration reply > if something like the condition above isn't met, and > similarly should require (with a MUST) the inclusion of a > challenge in responses to Agent Solicitations if the > condition isn't met. This is the only way to guarantee > progress on a link where advertisements may be lost and where > there is a long interval between unsolicited advertisements. > > > > > The current proposal from Pete is to reuse the challenge > in the Registration > Reply of the Registration Request for > which the authentication fails at the > FA. This challenge > sent in the Registration reply will be same as the > > challenge received in the Registration Request for which the > reply is sent. > > > To reflect this point, the following changes are proposed > by Jayshree: > > > (change 2.1-Section 3.2) > > From: > > If the registration message contains a Mobile-Foreign > Authentication > extension with an incorrect authenticator > that fails verification, the > Foreign Agent MAY send a > Registration Reply to the mobile node with Code > value > BAD_AUTHENTICATION (see Section 10). > > > > To: (Added last statement) > > If the registration message contains a Mobile-Foreign > Authentication > extension with an incorrect authenticator > that fails verification, the > Foreign Agent MAY send a > Registration Reply to the mobile node with Code > value > BAD_AUTHENTICATION (see Section 10). In this case, if the > Mobile Node > is currently registered, the challenge > included in the Registration Reply > by the Foreign Agent > MUST be the same as the one received in the > Registration > Request. > > > (change 2.2-Section 3.2) > From: > If the > registration message contains a Mobile-AAA Authentication > extension > with an incorrect authenticator that fails > verification, the Foreign Agent > MAY send a Registration > Reply to the mobile node with Code value > > BAD_AAA_AUTHENTICATION_SET_BY_FA. > > > > To: (Added last statement) > > If the registration message contains a Mobile-AAA > Authentication extension > with an incorrect authenticator > that fails verification, the Foreign Agent > MAY send a > Registration Reply to the mobile node with Code value > > BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, if the > Mobile Node is > currently registered, the challenge > included in the Registration Reply by > the Foreign Agent > MUST be the same as the one received in the Registration > > Request. > > > (change 2.3-Section 3.5) > > From: > > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by > the Foreign Agent if > the Registration Request contains a > Mobile-AAA Authentication extension with > an incorrect > authenticator that fails verification. A Mobile Node that > > receives a > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new > Challenge value in any new > registration, obtained either > from an Agent Advertisement, or from a > Challenge extension > to the Registration Reply containing the error. > > > To: (Replaced "new Challenge" to "Challenge") > > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by > the Foreign Agent if > the Registration Request contains a > Mobile-AAA Authentication extension with > an incorrect > authenticator that fails verification. A Mobile Node that > > receives a > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a > Challenge value in any new > registration, obtained either > from an Agent Advertisement, or from a > Challenge extension > to the Registration Reply containing the error. > > I don't support the text changes above, although I may have > proposed the principle of "repeating challenges." Perhaps we > don't need to make any text changes in this section, but can > confine the new text to the security considerations (see my > proposal below). > > > > This change further extends point mentioned in change 1 > for issue 2. The > proposal from Henrik was to clarify the > use of challenge. This text is > intended as a new paragraph > in section 3.3. > > > > "If the challenge most recently issued to the soliciting > mobile node has not > been previously used (as defined in > Section 1.1), the most recent challenge > unicast to the > mobile node through a registration reply or a unicast agent > > advertisement SHOULD be repeated in the registration reply." > > > This proposal was further modified by Pete differentiating > the processing at > the FA for the registered and > unregistered users: > > > "When responding to an unregistered MN with an > unsuccessful Registration > Reply, the FA SHOULD include the > same challenge that was last included in a > multicast Agent > Advertisement. When responding to a registered MN with a > > successful or unsuccessful Registration Reply, the FA SHOULD > include the > same challenge that was last included in a > multicast Agent Advertisement, > when that challenge is > previously unused by the MN. Otherwise, the FA > SHOULD > include the same challenge that was previously unicast to the > MN in a > Registration Reply or Agent Advertisement, unless > that challenge was > previously used. In that case, the FA > SHOULD create a new challenge and > return it to the MN, > storing a copy of it with the visitor list entry for > that MN." > > Based on the subsequent discussion, I don't think we need the > text changes above. See the security considerations: > > > > The following text was proposed to be added in section 12. > This is a > modified version of the text proposed by Henrik > on the mailing list earlier. > > > (section 12) > > Note that an active attacker may try to prevent successful > registrations by > sending a large number of Agent > Solicitations or bogus Registration > Requests, each of > which could cause the FA to respond with a fresh > > challenge, invalidating the challenge that the MN is > currently trying to > use. To prevent such attacks, the FA > SHOULD repeat the same challenge value > in successive > unicast responses to Agent Solicitations or in Registration > > Replies to Requests that did not contain valid MN-AAA or > MN-FA > authentication extensions. Note that each challenge > returned to an MN MUST > be previously unused by that MN. > > Based on subsequent comments from Ahmad, maybe we can make > the requirement more generic here, and give a specific > example in Appendix E. For here, how about: > > Note that an active attacker may try to prevent successful > registrations by sending a large number of Agent > Solicitations or bogus Registration Requests, each of which > could cause the FA to respond with a fresh challenge, > invalidating the challenge that the MN is currently trying to > use. To prevent such attacks, the FA MUST NOT invalidate > previously unused challenges when responding to > unauthenticated Registration Requests or Agent Solicitations. > In addition, the FA MUST NOT allocate new storage when > responding to such messages, because this would also create > the possibility of denial of service. > > > > > > It was decided that challenges sent in unicast Agent > Advertisements and sent > in Registration Reply messages > should be treated same at the FA. For this, > the following > text is proposed by Henrik and Pete: > > > (change 5.1-Section 3.2) > > From: > > The Foreign Agent MUST NOT accept any Challenge in the > Registration Request > unless it was offered in last > Registration Reply issued to the Mobile Node, > or else > advertised as one of the last CHALLENGE_WINDOW (see section > 9) > Challenge values inserted into the immediately > preceding Agent > advertisements. > > > To: > > The Foreign Agent MUST NOT accept any Challenge in the > Registration Request > unless it was offered in the last > Registration Reply or unicast Agent > Advertisement sent to > the Mobile Node, or else advertised as one of the last > > CHALLENGE_WINDOW (see section 9) Challenge values inserted > into the > immediately preceding Agent advertisements. > > > (change 5.2-Appendix E) > > From: > > In the program fragment, it is presumed that the foreign > agent keeps an > array of advertised Challenges > ("VALID_ADV_CHALLENGES"), a record of the > last advertised > challenge used by a mobile node, and > also a record of the > last challenge provided to a mobile node in a > Registration > Reply. > > > To: > > In the program fragment, it is presumed that the foreign > agent keeps an > array of advertised Challenges > ("VALID_ADV_CHALLENGES"), a record of the > last advertised > challenge used by a mobile node, and also a record of the > > last challenge provided to a mobile node in a Registration > Reply or unicast > Agent Advertisement. > > After that, we could add, "To meet the security obligations > outlined in Section 12, the FA SHOULD use one of the already > stored, previously unused challenges when responding to an > unauthenticated Registration Request or Agent Solicitation." > > > -Pete > > ------_=_NextPart_001_01C36E71.1EB4EADE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5

Hi Pete

This is not good. Putting all proposals in one email = is difficult to manage. The original email itself is of four pages. = Hence, it will be good if you can split your responses = accordingly.

Thanks,
Jayshree

> -----Original Message-----
> From: Pete McCann [mailto:mccap@lucent.com]
> Sent: Friday, August 29, 2003 11:56 AM
> To: Bharatia, Jayshree [RICH1:2H13:EXCH]
> Cc: 'mip4@ietf.org'
> Subject: [Mip4] RFC3012bis: Proposal for = Issue2-Change5
>
>
>
> Hi, Jayshree,
>
> I am reorganizing all the text proposals into = this one note
> for easier reference.  See comments below, = and let me know if
> I missed one of your notes.
>
>
> [note chair hat is off for the remainder of = this message]
>
>
>  > The current proposal for issue 1 is = to use "previously
> unused challenge" in  > section 2 = for all multicast and
> unicast Agent Advertisements.
>
> I am not sure what you mean by this.  Can = you give a specific
> text proposal, and a location for it in the = draft?
>
>  > In addition to this, Henrik proposed = a new text for a new
> subsection 2.1.
>  >
>  > 2.1 Handling of Solicited Agent = Advertisements
>  >
>  > When a foreign agent generates an = Agent Advertisement in
> response to a  > Router Solicitation = [4], some additional
> considerations come into play.  > = According to the Mobile IP
> base specification [7], the resulting = Agent  > Advertisement
> may be either multicast or unicast.  > =
>  > If the solicited Agent Advertisement = is multicast, it MUST
> NOT generate a  > new Challenge value = and update its window
> of remembered advertised  > Challenges. = It must instead
> re-use the most recent of the = CHALLENGE_WINDOW  >
> Advertisement Challenge values.  > =
>  > If the agent advertisement is = unicast back to the
> soliciting mobile node  > MUST be = handled as follows: If the
> challenge most recently unicast to the
>   ^ insert the word = "it"
>
>  > soliciting mobile node has not been = previously used (as
> defined in Section  > 1.1), in = SHOULD  > be repeated in the
> newly issued unicast agent advertisement, = otherwise a new  >
> challenge MUST be generated and remembered as = the most recent
> challenge  > issued to the mobile node. = (For further
> discussion of this, see Section 12.)
>
> I agree with this so far.
>
>  > A foreign agent SHOULD NOT respond = arbitrarily often to
> agent solicitations,  > in order to = limit processing load,
> especially in the face of hostile nodes  = > soliciting at a
> very high rate. The rate of solicited agent = advertisement  >
> responses SHOULD at most be 50 per = second.
>
> I am not sure we need the last paragraph.  = Overload control,
> especially the choice of which solicitations to = discard, is a
> tricky subject.  I don't know that we will = come to any
> agreement on a maximum rate (cf. previous = discussions on the
> Mobile IP list regarding multicast agent = advertisement rates).
>
>
>  > The original proposal from Henrik = was to mandate a
> challenge in a  > Registration Reply. = After few email
> exchanges, it was decided that the  > = current text in section
> 3.3 (RFC3012bis (version 05) ) is ok. In = addition to  > the
> current text, Henrik proposed the following = text to be used
> as a  > guidance/background:  > =
>  > (section 3.3)
>  > One example of a situation where the = Foreign Agent MAY
> omit the inclusion of  > a = Mobile-Foreign Challenge Extension
> in the Registration Reply would be when  = > a new challenge
> has been multicast recently. The Foreign Agent = could then  >
> assume that the mobile node with high = likelihood has received
> and can use  > the multicast challenge. = A mobile node MUST be
> prepared to use a multicast  > = challenge in lieu of one
> returned in a Registration Reply, and MUST = solicit  > for one
> if it has not already received one in a = Registration Reply or
> Agent  > Advertisement.
>
> This is good, but it doesn't seem quite strong = enough, i.e.,
> we still have a SHOULD on the inclusion of the = previously
> unused challenge.  It seems to me we = should require (with a
> MUST) the inclusion of a challenge in the = registration reply
> if something like the condition above isn't = met, and
> similarly should require (with a MUST) the = inclusion of a
> challenge in responses to Agent Solicitations = if the
> condition isn't met.  This is the only way = to guarantee
> progress on a link where advertisements may be l= ost and where
> there is a long interval between unsolicited = advertisements.
>
>
>
>  > The current proposal from Pete is to = reuse the challenge
> in the Registration  > Reply of the = Registration Request for
> which the authentication fails at the  = > FA. This challenge
> sent in the Registration reply will be same as = the  >
> challenge received in the Registration Request = for which the
> reply is sent.  >
>  > To reflect this point, the following = changes are proposed
> by Jayshree:  >
>  > (change 2.1-Section 3.2)
>  > From:
>  > If the registration message contains = a Mobile-Foreign
> Authentication  > extension with an = incorrect authenticator
> that fails verification, the  > Foreign = Agent MAY send a
> Registration Reply to the mobile node with = Code  > value
> BAD_AUTHENTICATION (see Section 10).
>  >
>  > To: (Added last statement)
>  > If the registration message contains = a Mobile-Foreign
> Authentication  > extension with an = incorrect authenticator
> that fails verification, the  > Foreign = Agent MAY send a
> Registration Reply to the mobile node with = Code  > value
> BAD_AUTHENTICATION (see Section 10). In this = case, if  the
> Mobile Node  > is currently registered, = the challenge
> included in the  Registration Reply  = > by the Foreign Agent
> MUST be the same as the one received in = the  > Registration
> Request.  >  >  > = (change 2.2-Section 3.2)  > From:  > If the
> registration message contains a Mobile-AAA = Authentication
> extension  > with an incorrect = authenticator that fails
> verification, the Foreign Agent  > MAY = send a Registration
> Reply to the mobile node with Code value  = >
> BAD_AAA_AUTHENTICATION_SET_BY_FA.
>  >
>  > To: (Added last statement)
>  > If the registration message contains = a Mobile-AAA
> Authentication extension  > with an = incorrect authenticator
> that fails verification, the Foreign = Agent  > MAY send a
> Registration Reply to the mobile node with Code = value  >
> BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, = if  the
> Mobile Node is  > currently registered, = the challenge
> included in the Registration Reply by  = > the Foreign Agent
> MUST be the same as the one received in the = Registration  >
> Request.  >
>  > (change 2.3-Section 3.5)
>  > From:
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA: = This error is sent by
> the Foreign Agent if  > the = Registration Request contains a
> Mobile-AAA Authentication extension with  = > an incorrect
> authenticator that fails verification.  A = Mobile Node that  >
> receives a  > = BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new
> Challenge value in any new  > = registration, obtained either
> from an Agent Advertisement, or from a  = > Challenge extension
> to the Registration Reply containing the = error.  >
>  > To: (Replaced "new = Challenge" to "Challenge")
>  > BAD_AAA_AUTHENTICATION_SET_BY_FA: = This error is sent by
> the Foreign Agent if  > the = Registration Request contains a
> Mobile-AAA Authentication extension with  = > an incorrect
> authenticator that fails verification.  A = Mobile Node that  >
> receives a  > = BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a
> Challenge value in any new  > = registration, obtained either
> from an Agent Advertisement, or from a  = > Challenge extension
> to the Registration Reply containing the = error.
>
> I don't support the text changes above, = although I may have
> proposed the principle of "repeating = challenges."  Perhaps we
> don't need to make any text changes in this = section, but can
> confine the new text to the security = considerations (see my
> proposal below).
>
>
>  > This change further extends point = mentioned in change 1
> for issue 2. The  > proposal from = Henrik was to clarify the
> use of challenge. This text is  > = intended as a new paragraph
> in section 3.3.
>  >
>  > "If the challenge most recently = issued to the soliciting
> mobile node has not  > been previously = used (as defined in
> Section 1.1), the most recent challenge  = > unicast to the
> mobile node through a registration reply or a = unicast agent 
> > advertisement SHOULD be repeated in the = registration reply."  >
>  > This proposal was further modified = by Pete differentiating
> the processing at  > the FA for the = registered and
> unregistered users:  >
>  > "When responding to an = unregistered MN with an
> unsuccessful Registration  > Reply, the = FA SHOULD include the
> same challenge that was last included in = a  > multicast Agent
> Advertisement.  When responding to a = registered MN with a  >
> successful or unsuccessful Registration Reply, = the FA SHOULD
> include the  > same challenge that was = last included in a
> multicast Agent Advertisement,  > when = that challenge is
> previously unused by the MN.  Otherwise, = the FA  > SHOULD
> include the same challenge that was previously = unicast to the
> MN in a  > Registration Reply or Agent = Advertisement, unless
> that challenge was  > previously = used.  In that case, the FA
> SHOULD create a new challenge and  > = return it to the MN,
> storing a copy of it with the visitor list = entry for  > that MN."
>
> Based on the subsequent discussion, I don't = think we need the
> text changes above.  See the security = considerations:
>
>
>  > The following text was proposed to = be added in section 12.
> This is a  > modified version of the = text proposed by Henrik
> on the mailing list earlier.  >
>  > (section 12)
>  > Note that an active attacker may try = to prevent successful
> registrations by  > sending a large = number of Agent
> Solicitations or bogus Registration  > = Requests, each of
> which could cause the FA to respond with a = fresh  >
> challenge, invalidating the challenge that the = MN is
> currently trying to  > use.  To = prevent such attacks, the FA
> SHOULD repeat the same challenge value  = > in successive
> unicast responses to Agent Solicitations or in = Registration 
> > Replies to Requests that did not contain = valid MN-AAA or
> MN-FA  > authentication = extensions.  Note that each challenge
> returned to an MN MUST  > be previously = unused by that MN.
>
> Based on subsequent comments from Ahmad, maybe = we can make
> the requirement more generic here, and give a = specific
> example in Appendix E.  For here, how = about:
>
> Note that an active attacker may try to prevent = successful
> registrations by sending a large number of = Agent
> Solicitations or bogus Registration Requests, = each of which
> could cause the FA to respond with a fresh = challenge,
> invalidating the challenge that the MN is = currently trying to
> use.  To prevent such attacks, the FA MUST = NOT invalidate
> previously unused challenges when responding to =
> unauthenticated Registration Requests or Agent = Solicitations.
>  In addition, the FA MUST NOT allocate new = storage when
> responding to such messages, because this would = also create
> the possibility of denial of service.
>
>
>
>
>  > It was decided that challenges sent = in unicast Agent
> Advertisements and sent  > in = Registration Reply messages
> should be treated same at the FA. For = this,  > the following
> text is proposed by Henrik and Pete:  > =
>  > (change 5.1-Section 3.2)
>  > From:
>  > The Foreign Agent MUST NOT accept = any Challenge in the
> Registration Request  > unless it was = offered in last
> Registration Reply issued to the Mobile = Node,  > or else
> advertised as one of the last CHALLENGE_WINDOW = (see section
> 9)  > Challenge values inserted into = the immediately
> preceding Agent  > = advertisements.  >
>  > To:
>  > The Foreign Agent MUST NOT accept = any Challenge in the
> Registration Request  > unless it was = offered in the last
> Registration Reply or unicast Agent  > = Advertisement sent to
> the Mobile Node, or else advertised as one of = the last  >
> CHALLENGE_WINDOW (see section 9) Challenge = values inserted
> into the  > immediately preceding Agent = advertisements.  >
>  > (change 5.2-Appendix E)
>  > From:
>  > In the program fragment, it is = presumed that the foreign
> agent keeps an  > array of advertised = Challenges
> ("VALID_ADV_CHALLENGES"), a record of = the  > last advertised
> challenge used by a mobile node, and  > = also a record of the
> last challenge provided to a mobile node in = a  > Registration
> Reply.  >
>  > To:
>  > In the program fragment, it is = presumed that the foreign
> agent keeps an  > array of advertised = Challenges
> ("VALID_ADV_CHALLENGES"), a record of = the  > last advertised
> challenge used by a mobile node, and also a = record of the  >
> last challenge provided to a mobile node in a = Registration
> Reply or unicast  > Agent = Advertisement.
>
> After that, we could add, "To meet the = security obligations
> outlined in Section 12, the FA SHOULD use one = of the already
> stored, previously unused challenges when = responding to an
> unauthenticated Registration Request or Agent = Solicitation."
>
>
> -Pete
>
>

------_=_NextPart_001_01C36E71.1EB4EADE-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Aug 30 03:28: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 DAA28313 for ; Sat, 30 Aug 2003 03:28: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 19szTX-0005wa-Jh for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 02:44:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U6ihF7022833 for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 02:44:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19swpn-0005Ue-FD for mip4-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 23:55:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06807 for ; Fri, 29 Aug 2003 23:55:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19swpk-0005Ca-00 for mip4-web-archive@ietf.org; Fri, 29 Aug 2003 23:55:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19swpj-0005CX-00 for mip4-web-archive@ietf.org; Fri, 29 Aug 2003 23:55:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svBH-0000cH-7z; Fri, 29 Aug 2003 22:09:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sqxO-0005wH-Sp for mip4@optimus.ietf.org; Fri, 29 Aug 2003 17:38:59 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07768 for ; Fri, 29 Aug 2003 17:38:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sqxM-0000cE-00 for mip4@ietf.org; Fri, 29 Aug 2003 17:38:56 -0400 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19sqxL-0000bI-00 for mip4@ietf.org; Fri, 29 Aug 2003 17:38:55 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail1.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7TLcHP11514; Fri, 29 Aug 2003 16:38:18 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7TLcFY09078; Fri, 29 Aug 2003 16:38:16 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16207.51139.367422.145534@gargle.gargle.HOWL> Date: Fri, 29 Aug 2003 16:38:11 -0500 From: Pete McCann To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: RE: [Mip4] RFC3012bis: Proposal for Issue2-Change5 In-Reply-To: <870397D7C140C84DB081B88396458DAF746B3C@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746B3C@zrc2c000.us.nortel.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Jayshree, As you can see from my note, many of my responses are inter-related. I do not think we can easily separate the items. The response is only 250 lines; if you can convince your mailer not to reformat the quoted lines it should be manageable. If you would like I can post a smaller version with just the text changes that I personally think are necessary. It should be much shorter, but would leave out the flow of the discussion. -Pete Jayshree Bharatia writes: > Hi Pete > > This is not good. Putting all proposals in one email is difficult to manage. > The original email itself is of four pages. Hence, it will be good if you > can split your responses accordingly. > > Thanks, > Jayshree _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Aug 30 03:47: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 DAA29536 for ; Sat, 30 Aug 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 19syF4-0001qk-Il for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 01:25:43 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U5Pg1c007106 for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 01:25:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svY3-0001j7-Sb for mip4-web-archive@optimus.ietf.org; Fri, 29 Aug 2003 22:33: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 WAA00851 for ; Fri, 29 Aug 2003 22:32:59 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19svY0-0001dO-00 for mip4-web-archive@ietf.org; Fri, 29 Aug 2003 22:33:04 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19svY0-0001dK-00 for mip4-web-archive@ietf.org; Fri, 29 Aug 2003 22:33:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19stkc-0004GA-SH; Fri, 29 Aug 2003 20:37:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19soPW-000760-Iv for mip4@optimus.ietf.org; Fri, 29 Aug 2003 14:55:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23349 for ; Fri, 29 Aug 2003 14:55:42 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19soPT-0003lY-00 for mip4@ietf.org; Fri, 29 Aug 2003 14:55:47 -0400 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19soPS-0003l6-00 for mip4@ietf.org; Fri, 29 Aug 2003 14:55:46 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by hoemail2.firewall.lucent.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h7TIsuC02801; Fri, 29 Aug 2003 13:54:57 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7TIspY07022; Fri, 29 Aug 2003 13:54:52 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16207.41336.199384.249570@gargle.gargle.HOWL> Date: Fri, 29 Aug 2003 13:54:48 -0500 From: Pete McCann To: Milind Kulkarni Cc: mip4@ietf.org, Henrik Levkowetz Subject: Re: [Mip4] draft-kulkarni-mobileip-dynamic-assignment as Workgroup Item? In-Reply-To: <3F4D027F.3000704@cisco.com> References: <20030810070259.756b7d5b.henrik@levkowetz.com> <16188.696.536937.422217@gargle.gargle.HOWL> <3F4D027F.3000704@cisco.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Milind, Milind Kulkarni writes: > Hi Pete, > > Sorry for the delay. No problem - sorry this note is delayed a couple of days as well. > Kuntal has already answered most of the > concerns. Hmm... I think we have a slightly different reading of his note. > Before we go into the details of the draft, the > motivation for the draft is: > > - To get assigned with an "optimized" home agent for a given MN. > > - The definition of "optmized" home agent is left to suit the > various deployments. That is because we want to keep the > mechanism generic, so that it can accommodate different > requirements. > For example, one deployment may want to select nearest > geographical HA, while another may choose to select the > HA that is cheaper (in terms of money) to go to. Some > other deployment may want to choose an HA based on certain > time of the day, and so on. There can be many variations. > > - To propose a mechanism that is generic, open for accommodating > various requirements and should work with any existing > infrastructure such as AAA etc. > > - The MIP v6 group also considers this as a problem, and was > presented in Vienna IETF as part of Thoughts on > Bootstrapping Mobility. I agree with the above goals; however, I think you may have combined two separable mechanisms unnecessarily, and I have a couple of issues with each. > More inline..... > > > Pete McCann wrote: > > Hi, > > > > Henrik Levkowetz writes: > > > > > > One of the charter items of the mip4 working group is dynamic HA > > > assignment. The document draft-kulkarni-mobileip-dynamic-assignment-01.txt > > > proposes a mechanism for doing this at registration time. We would now > > > like to confirm with the working group that this document should be > > > made the basis of registration time HA assignment, and moved forward > > > as a workgroup item. Any objections? > > > > > > The chairs > > > > [chair hat off for a moment] > > > > I wanted to offer some of my own comments on this draft - I hope > > others will read it closely and comment as well. > > > > > > At a high level, what this draft does is allow one HA to redirect a > > registration request to a different HA, when the HA field (not the > > destination IP address) is set to 0.0.0.0 or 255.255.255.255. > > One of the key points of the draft is that it allows the RRQ to be > responded to by a dynamically assigned home agent. > > Various metrics and mechanisms can be used to assign the HA > intelligently. We are not suggesting or enforcing any specific > mechanism. Using the same logic, there may not be any further > redirection and the first HA to receive the RRQ can accept and > create binding. I agree with this statement, and I am not proposing that we add selection mechanisms or criteria to the draft. > > My main concern with this draft is that there is a lot left > > unspecified (just look for all the occurrences of "outside the scope") > > and some of these unspecified procedures are actually quite > > important. For example, the abstract says: > > Since the draft specifies a framework (or a structure or a front > end mechanism, whatever we call it), in our opinion it should > be open and satfisy as many requirements. As mentioned earlier, > we want various implementors to define their own "optimal" > behavior rather than forcing what we think is optimal. > Hence the details on how to get to ones optimal HA is left > out of scope. The draft says this in sections 1, 5.5. However > the mulitple occurrences of the text "out of scope" are due to > repeatition of same text so that each section is self sufficient. > It can be removed in next rev. I don't think it needs to be removed everywhere (it is appropriate in some places). See below... > > The distance between a > > MN and HA affects the latency for control and data traffic. > > When the distance between the MN and HA is large, the resulting > > latency may be unacceptable. Therefore, it is advantageous to > > select a nearest HA to the MN during initial registration. > > > > The mechanism outlined in the draft doesn't seem to satisfy this > > requirement. This is because "Directed" HA must be a-priori > > configured with the "Assigned" HA IP address, which implies they would > > be in the same domain. So, the real meat of the above requirement is > > that: > > > > (1) the MN (or the FA) must somehow discover a local HA to which the > > message can be sent; and, > > (2) the MN must develop a security association with that HA. > > > > Both of these procedures are ruled explicitly outside the scope of the > > draft. Note that I think (1) or (2) can be met with procedures that > > don't require any notion of "Directed" or "Assigned" HA. Rather, the > > main thrust of the draft seems to be at the next requirement listed in > > the abstract: > > > > There are other reasons for assigning an optimal HA beyond just > > locality, such as administrative policies, load balancing etc. > > > > Right, the framework tries to provide a sort of tool that can satisfy > more that one requirement. I am not sure why that's not ok. Let me try to rephrase my issue: there are many lines of text in the draft devoted to the forwarding registration requests from Directed HA to Assigned HA. In fact, I would have to say this mechanism is the main new *protocol* that is specified by this draft. However, this mechanism seems targeted at the second motivation, rather than the first. Personally, I would have written this draft with more of a focus on the way an MN sends the RRQ to an FA, and the FA picks an HA. Sure, the actual choice is outside the scope, but you could mention, e.g., consultation of a AAA infrastructure, and/or looking at the HA address in the RRQ to determine local vs. home network. Also, I think this should only be allowed when the MN uses an authorization enabling extension that can be verified from multiple different points in the network, such as MN-AAA (i.e., MN-HA MUST NOT be used with this mechanism). It can only be used when registering via an FA. Also, a new security association MUST be created along with the registration. Taken together, these sorts of changes would go a long way to satisfying the first stated goal, which is allocation of a local/remote HA for assisting with more optimal routing. > > The abstract goes on to state: > > > > This draft proposes a generic lightweight dynamic home agent > > assignment framework. The goal of the framework is to provide a > > mechanism to assign an optimal HA for a Mobile IP session while > > allowing any suitable method for HA assignment. > > > > At best, this draft is really defining some front-end behavior > > (message formats and Mobile IP processing) that would enable dynamic > > home agent assignment, but I wouldn't go so far as to call it a > > framework (due to the large amount of unspecified work left to do). > > If the term "framework" isn't appealing, can you suggest appropriate > alternative? The reason for terming as such is because it incorporates > (i) the ability to allow the RRQ to be responded to by dyn HA and > (ii) logical separation of 2 addresses viz. Directed HA address and > Assigned HA address. The Directed HA and Assigned HA are merely > logical entities and dealt extensively in section 5.3, 5.4 and 5.5. > > We do not want to suggest a specific mechanism e.g. AAA, DNS etc. > and tie it specifically tp form a solution as we envision that it > is deployment specific. Thus we are providing a generic framework/ > front end mechanism within MoObile IP to allow that. I like the term "front end mechanism" better than "framework." This draft really describes only the Mobile IP processing, while leaving a lot to back-end infrastructure. The term "framework" implies something more complete. > > The draft also assumes that the assigned HA will be able to verify the > > authentication extensions in the redirected RRQ. In section 5.1 the > > draft states: > > > > Example of one such implementation is where MN > > shares identical security associations with all the Directed > > HA(s) and Assigned HA(s) in the network. > > > > I consider this to be completely unacceptable security practice and I > > think this statement should be removed from the draft. Rather, it > > seems like this method will only work with something like the MN-AAA > > extension that can be verified from one of many HAs in the network, > > and that a security association MUST be developed dynamically along > > the lines of the AAA-keys draft. I think limitations like this should > > be described in the security considerations. I understand a new > > version with expanded security considerations is in preparation; I > > will defer additional security comments until it comes out. > > Since this section is updated in latest version of the draft, let's > defer the discussion on SAs. I will send the new version to the > WG soon. Ok, I look forward to it. > > So, I think the draft may be valuable in that it specifies the > > front-end behavior necessary to enable AAA-keys and the MIPv4 Diameter > > application. This is similar to the way the NAI and MN-AAA draft > > specify front-end behavior, while leaving the actual authentication to > > AAA mechanisms specified elsewhere. However, this draft seems to > > sneak in some additional HA redirection functionality (purely for load > > balancing) that I am not convinced is required at this time. > > I respectfully disagree, load balancing may not be needed > immediately, but is a valid requirement and the logical separation > of assigned HA and directed HA address solves it too. > > Load balancing is one example where dynamic HA framework is useful. > There is no intention to 'sneak' in a solution. THis is a real > problem for large deployment with 'millions' of subscribers as is > starting to happen with 3G deployment. > > On the contrary, the way we see it is, this draft adds a lot of > practical value to the MN-AAA key distribution draft. With that > draft, the SA are dynamically derived with an HA, but how is the > HA found. If an 'optimal' HA is dynamically found, then that > draft can be used to set up SAs. I do see value in load balancing, but I wonder if it could be addressed separately. For example, we could have a rejection code that specified a new HA. Upon further consideration, I have a number of new technical questions about the mechanism of forwarding a registration request from one HA to another: 1) It doesn't appear to work when using co-located COA when registering via an FA. In this case, the COA in the RRQ does NOT indicate where to send a response. Your mechanism seems to depend on this, because it over-writes the original source IP address of the packet. 2) It seems to open a security vulnerability, because an FA must now process any response that comes from anywhere with a matching Identifier. If it is a rejection, the FA will delete the pending visitor list entry. This could allow attackers to deny service when the MN tries to register. Previously, we could argue that deployment of ingress filtering alleviated this concern. Note that an FA often does not have a security association to every HA with which it will interact. 3) Can we guarantee that the routing of RRQs among HAs will be loop-free? In contrast, a rejection code would not introduce the new security concerns, because we keep the existing Mobile IP message flow. The MN would need to create/obtain security associations with each HA independently (i.e., security would be orthogonal to the dynamic assignment). Finally, the MN would have the ability to detect misconfigured HAs that were pointing at each other because it would see each redirection on an end-to-end basis. -Pete > Thanks, > Milind > > > > I would > > like to hear the opinions of others in the WG on whether this is > > important enough to include in the current draft - perhaps it could > > best be addressed with a separate draft, using a Rejection code > > instead of a forwarding mechanism? > > > > > > -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Aug 30 04:41:49 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01896 for ; Sat, 30 Aug 2003 04:41:49 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19szUh-00068F-OC for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 02:45:55 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7U6jt07023564 for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 02:45:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19sxJx-0006cC-B3 for mip4-web-archive@optimus.ietf.org; Sat, 30 Aug 2003 00:26:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08102 for ; Sat, 30 Aug 2003 00:26:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19sxJu-0005yb-00 for mip4-web-archive@ietf.org; Sat, 30 Aug 2003 00:26:38 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19sxJt-0005yY-00 for mip4-web-archive@ietf.org; Sat, 30 Aug 2003 00:26:37 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19svAC-0000Pe-HE; Fri, 29 Aug 2003 22:08:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19smYU-0001KM-FK for mip4@optimus.ietf.org; Fri, 29 Aug 2003 12:56: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 MAA13676 for ; Fri, 29 Aug 2003 12:56:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19smYS-00019L-00 for mip4@ietf.org; Fri, 29 Aug 2003 12:56:56 -0400 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 19smYR-00018x-00 for mip4@ietf.org; Fri, 29 Aug 2003 12:56:55 -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 h7TGuDU10938; Fri, 29 Aug 2003 11:56:13 -0500 (CDT) Received: from MCCAP-1.lucent.com by nwsgpa.ih.lucent.com (8.11.6+Sun/EMS-1.5 sol2) id h7TGuBY29177; Fri, 29 Aug 2003 11:56:11 -0500 (CDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16207.34215.643142.575989@gargle.gargle.HOWL> Date: Fri, 29 Aug 2003 11:56:07 -0500 From: Pete McCann To: "Jayshree Bharatia" Cc: "'mip4@ietf.org'" Subject: [Mip4] RFC3012bis: Proposal for Issue2-Change5 In-Reply-To: <870397D7C140C84DB081B88396458DAF746B2B@zrc2c000.us.nortel.com> References: <870397D7C140C84DB081B88396458DAF746B2B@zrc2c000.us.nortel.com> X-Mailer: VM 7.14 under 21.5 (beta14) "cassava" XEmacs Lucid Content-Transfer-Encoding: 7bit Sender: mip4-admin@ietf.org Errors-To: mip4-admin@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Mobility for IPv4 List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Hi, Jayshree, I am reorganizing all the text proposals into this one note for easier reference. See comments below, and let me know if I missed one of your notes. [note chair hat is off for the remainder of this message] > The current proposal for issue 1 is to use "previously unused challenge" in > section 2 for all multicast and unicast Agent Advertisements. I am not sure what you mean by this. Can you give a specific text proposal, and a location for it in the draft? > In addition to this, Henrik proposed a new text for a new subsection 2.1. > > 2.1 Handling of Solicited Agent Advertisements > > When a foreign agent generates an Agent Advertisement in response to a > Router Solicitation [4], some additional considerations come into play. > According to the Mobile IP base specification [7], the resulting Agent > Advertisement may be either multicast or unicast. > > If the solicited Agent Advertisement is multicast, it MUST NOT generate a > new Challenge value and update its window of remembered advertised > Challenges. It must instead re-use the most recent of the CHALLENGE_WINDOW > Advertisement Challenge values. > > If the agent advertisement is unicast back to the soliciting mobile node > MUST be handled as follows: If the challenge most recently unicast to the ^ insert the word "it" > soliciting mobile node has not been previously used (as defined in Section > 1.1), in SHOULD > be repeated in the newly issued unicast agent advertisement, otherwise a new > challenge MUST be generated and remembered as the most recent challenge > issued to the mobile node. (For further discussion of this, see Section 12.) I agree with this so far. > A foreign agent SHOULD NOT respond arbitrarily often to agent solicitations, > in order to limit processing load, especially in the face of hostile nodes > soliciting at a very high rate. The rate of solicited agent advertisement > responses SHOULD at most be 50 per second. I am not sure we need the last paragraph. Overload control, especially the choice of which solicitations to discard, is a tricky subject. I don't know that we will come to any agreement on a maximum rate (cf. previous discussions on the Mobile IP list regarding multicast agent advertisement rates). > The original proposal from Henrik was to mandate a challenge in a > Registration Reply. After few email exchanges, it was decided that the > current text in section 3.3 (RFC3012bis (version 05) ) is ok. In addition to > the current text, Henrik proposed the following text to be used as a > guidance/background: > > (section 3.3) > One example of a situation where the Foreign Agent MAY omit the inclusion of > a Mobile-Foreign Challenge Extension in the Registration Reply would be when > a new challenge has been multicast recently. The Foreign Agent could then > assume that the mobile node with high likelihood has received and can use > the multicast challenge. A mobile node MUST be prepared to use a multicast > challenge in lieu of one returned in a Registration Reply, and MUST solicit > for one if it has not already received one in a Registration Reply or Agent > Advertisement. This is good, but it doesn't seem quite strong enough, i.e., we still have a SHOULD on the inclusion of the previously unused challenge. It seems to me we should require (with a MUST) the inclusion of a challenge in the registration reply if something like the condition above isn't met, and similarly should require (with a MUST) the inclusion of a challenge in responses to Agent Solicitations if the condition isn't met. This is the only way to guarantee progress on a link where advertisements may be lost and where there is a long interval between unsolicited advertisements. > The current proposal from Pete is to reuse the challenge in the Registration > Reply of the Registration Request for which the authentication fails at the > FA. This challenge sent in the Registration reply will be same as the > challenge received in the Registration Request for which the reply is sent. > > To reflect this point, the following changes are proposed by Jayshree: > > (change 2.1-Section 3.2) > From: > If the registration message contains a Mobile-Foreign Authentication > extension with an incorrect authenticator that fails verification, the > Foreign Agent MAY send a Registration Reply to the mobile node with Code > value BAD_AUTHENTICATION (see Section 10). > > To: (Added last statement) > If the registration message contains a Mobile-Foreign Authentication > extension with an incorrect authenticator that fails verification, the > Foreign Agent MAY send a Registration Reply to the mobile node with Code > value BAD_AUTHENTICATION (see Section 10). In this case, if the Mobile Node > is currently registered, the challenge included in the Registration Reply > by the Foreign Agent MUST be the same as the one received in the > Registration Request. > > > (change 2.2-Section 3.2) > From: > If the registration message contains a Mobile-AAA Authentication extension > with an incorrect authenticator that fails verification, the Foreign Agent > MAY send a Registration Reply to the mobile node with Code value > BAD_AAA_AUTHENTICATION_SET_BY_FA. > > To: (Added last statement) > If the registration message contains a Mobile-AAA Authentication extension > with an incorrect authenticator that fails verification, the Foreign Agent > MAY send a Registration Reply to the mobile node with Code value > BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, if the Mobile Node is > currently registered, the challenge included in the Registration Reply by > the Foreign Agent MUST be the same as the one received in the Registration > Request. > > (change 2.3-Section 3.5) > From: > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if > the Registration Request contains a Mobile-AAA Authentication extension with > an incorrect authenticator that fails verification. A Mobile Node that > receives a > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new Challenge value in any new > registration, obtained either from an Agent Advertisement, or from a > Challenge extension to the Registration Reply containing the error. > > To: (Replaced "new Challenge" to "Challenge") > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if > the Registration Request contains a Mobile-AAA Authentication extension with > an incorrect authenticator that fails verification. A Mobile Node that > receives a > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a Challenge value in any new > registration, obtained either from an Agent Advertisement, or from a > Challenge extension to the Registration Reply containing the error. I don't support the text changes above, although I may have proposed the principle of "repeating challenges." Perhaps we don't need to make any text changes in this section, but can confine the new text to the security considerations (see my proposal below). > This change further extends point mentioned in change 1 for issue 2. The > proposal from Henrik was to clarify the use of challenge. This text is > intended as a new paragraph in section 3.3. > > "If the challenge most recently issued to the soliciting mobile node has not > been previously used (as defined in Section 1.1), the most recent challenge > unicast to the mobile node through a registration reply or a unicast agent > advertisement SHOULD be repeated in the registration reply." > > This proposal was further modified by Pete differentiating the processing at > the FA for the registered and unregistered users: > > "When responding to an unregistered MN with an unsuccessful Registration > Reply, the FA SHOULD include the same challenge that was last included in a > multicast Agent Advertisement. When responding to a registered MN with a > successful or unsuccessful Registration Reply, the FA SHOULD include the > same challenge that was last included in a multicast Agent Advertisement, > when that challenge is previously unused by the MN. Otherwise, the FA > SHOULD include the same challenge that was previously unicast to the MN in a > Registration Reply or Agent Advertisement, unless that challenge was > previously used. In that case, the FA SHOULD create a new challenge and > return it to the MN, storing a copy of it with the visitor list entry for > that MN." Based on the subsequent discussion, I don't think we need the text changes above. See the security considerations: > The following text was proposed to be added in section 12. This is a > modified version of the text proposed by Henrik on the mailing list earlier. > > (section 12) > Note that an active attacker may try to prevent successful registrations by > sending a large number of Agent Solicitations or bogus Registration > Requests, each of which could cause the FA to respond with a fresh > challenge, invalidating the challenge that the MN is currently trying to > use. To prevent such attacks, the FA SHOULD repeat the same challenge value > in successive unicast responses to Agent Solicitations or in Registration > Replies to Requests that did not contain valid MN-AAA or MN-FA > authentication extensions. Note that each challenge returned to an MN MUST > be previously unused by that MN. Based on subsequent comments from Ahmad, maybe we can make the requirement more generic here, and give a specific example in Appendix E. For here, how about: Note that an active attacker may try to prevent successful registrations by sending a large number of Agent Solicitations or bogus Registration Requests, each of which could cause the FA to respond with a fresh challenge, invalidating the challenge that the MN is currently trying to use. To prevent such attacks, the FA MUST NOT invalidate previously unused challenges when responding to unauthenticated Registration Requests or Agent Solicitations. In addition, the FA MUST NOT allocate new storage when responding to such messages, because this would also create the possibility of denial of service. > It was decided that challenges sent in unicast Agent Advertisements and sent > in Registration Reply messages should be treated same at the FA. For this, > the following text is proposed by Henrik and Pete: > > (change 5.1-Section 3.2) > From: > The Foreign Agent MUST NOT accept any Challenge in the Registration Request > unless it was offered in last Registration Reply issued to the Mobile Node, > or else advertised as one of the last CHALLENGE_WINDOW (see section 9) > Challenge values inserted into the immediately preceding Agent > advertisements. > > To: > The Foreign Agent MUST NOT accept any Challenge in the Registration Request > unless it was offered in the last Registration Reply or unicast Agent > Advertisement sent to the Mobile Node, or else advertised as one of the last > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > immediately preceding Agent advertisements. > > (change 5.2-Appendix E) > From: > In the program fragment, it is presumed that the foreign agent keeps an > array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the > last advertised challenge used by a mobile node, and > also a record of the last challenge provided to a mobile node in a > Registration Reply. > > To: > In the program fragment, it is presumed that the foreign agent keeps an > array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the > last advertised challenge used by a mobile node, and also a record of the > last challenge provided to a mobile node in a Registration Reply or unicast > Agent Advertisement. After that, we could add, "To meet the security obligations outlined in Section 12, the FA SHOULD use one of the already stored, previously unused challenges when responding to an unauthenticated Registration Request or Agent Solicitation." -Pete _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Aug 30 11:27:01 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 LAA18115 for ; Sat, 30 Aug 2003 11:27:01 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t7GW-0001AH-9Z for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 11:03:48 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7UF3mDt004439 for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 11:03:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t6gQ-0007Zk-OF for mip4-web-archive@optimus.ietf.org; Sat, 30 Aug 2003 10:26:30 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14878 for ; Sat, 30 Aug 2003 10:26:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t6gO-0005n0-00 for mip4-web-archive@ietf.org; Sat, 30 Aug 2003 10:26:28 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19t6gN-0005mw-00 for mip4-web-archive@ietf.org; Sat, 30 Aug 2003 10:26:27 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t63e-0006H6-OF; Sat, 30 Aug 2003 09:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t2lD-0007V3-J8 for mip4@optimus.ietf.org; Sat, 30 Aug 2003 06:15:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05309 for ; Sat, 30 Aug 2003 06:15:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t2l9-000055-00 for mip4@ietf.org; Sat, 30 Aug 2003 06:15:07 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19t2l7-00004y-00 for mip4@ietf.org; Sat, 30 Aug 2003 06:15:05 -0400 Received: (qmail 11256 invoked from network); 30 Aug 2003 10:14:28 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 30 Aug 2003 10:14:28 -0000 Date: Sat, 30 Aug 2003 12:14:27 +0200 From: Henrik Levkowetz To: Pete McCann Cc: Milind Kulkarni , mip4@ietf.org Subject: Re: [Mip4] draft-kulkarni-mobileip-dynamic-assignment as Workgroup Item? Message-Id: <20030830121427.049e5f6e.henrik@levkowetz.com> In-Reply-To: <16207.41336.199384.249570@gargle.gargle.HOWL> References: <20030810070259.756b7d5b.henrik@levkowetz.com> <16188.696.536937.422217@gargle.gargle.HOWL> <3F4D027F.3000704@cisco.com> <16207.41336.199384.249570@gargle.gargle.HOWL> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.kQfAeV:b+MuzC(" 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: , --=.kQfAeV:b+MuzC( Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I pretty much agree to what Pete's said below. With respect to making this a workgroup item (co-chair hat off), I've got two possibly conflicting comments. (I'll expand on these in follow-up mails): 1) We've had some very recent discussions in the office about this, and will be implementing the current proposal (due to customer demand), but with the expectation that the mechanism will change, and also with the addition of a vendor-specific extension we see is needed. This is to some extent in favour of making this a workgroup item, to get standardisation. 2) I have concerns with the routing in this proposal - RRQ's being answered by a different HA than the one they were directed to seems to break more than one current mechanism, and open up security issues (as mentioned by Pete below). One mechanism which Pete doesn't mention, which may also be broken by this changed routing is NAT traversal, which is crucial in practical deployment today. This indicates quite strongly that we need to develop and possibly change this proposal quite materially before making it a workgroup item. Having these two quite contrary viewpoints, I'd like to propose a way forward, too: Having participated on the EAP list to some extent the last half year or so, as editor of the revised EAP specification (rfc2284bis) I have seen one possible way to work which has been used quite profitably there: Worthwhile drafts which are within the charter are discussed and developed on the list, with formalized issue tracking and everything, but only made formal workgroup items when they appear reasonably mature. The eap drafts in this category today are respectively in version -03, -04 and -07. This is a way forward where drafts get some further time to show whether they have support from the list in general, get more stability, have possibly major changes worked out etc, before the WG commits to bringing them forward as standards. Maybe this is a model to consider here too? Henrik Friday 29 August 2003, Pete wrote: > > Hi, Milind, > > Milind Kulkarni writes: > > Hi Pete, > > > > Sorry for the delay. > > No problem - sorry this note is delayed a couple of days as well. > > > Kuntal has already answered most of the > > concerns. > > Hmm... I think we have a slightly different reading of his note. > > > Before we go into the details of the draft, the > > motivation for the draft is: > > > > - To get assigned with an "optimized" home agent for a given MN. > > > > - The definition of "optmized" home agent is left to suit the > > various deployments. That is because we want to keep the > > mechanism generic, so that it can accommodate different > > requirements. > > For example, one deployment may want to select nearest > > geographical HA, while another may choose to select the > > HA that is cheaper (in terms of money) to go to. Some > > other deployment may want to choose an HA based on certain > > time of the day, and so on. There can be many variations. > > > > - To propose a mechanism that is generic, open for accommodating > > various requirements and should work with any existing > > infrastructure such as AAA etc. > > > > - The MIP v6 group also considers this as a problem, and was > > presented in Vienna IETF as part of Thoughts on > > Bootstrapping Mobility. > > I agree with the above goals; however, I think you may have combined > two separable mechanisms unnecessarily, and I have a couple of issues > with each. > > > More inline..... > > > > > > Pete McCann wrote: > > > Hi, > > > > > > Henrik Levkowetz writes: > > > > > > > > One of the charter items of the mip4 working group is dynamic HA > > > > assignment. The document draft-kulkarni-mobileip-dynamic-assignment-01.txt > > > > proposes a mechanism for doing this at registration time. We would now > > > > like to confirm with the working group that this document should be > > > > made the basis of registration time HA assignment, and moved forward > > > > as a workgroup item. Any objections? > > > > > > > > The chairs > > > > > > [chair hat off for a moment] > > > > > > I wanted to offer some of my own comments on this draft - I hope > > > others will read it closely and comment as well. > > > > > > > > > At a high level, what this draft does is allow one HA to redirect a > > > registration request to a different HA, when the HA field (not the > > > destination IP address) is set to 0.0.0.0 or 255.255.255.255. > > > > One of the key points of the draft is that it allows the RRQ to be > > responded to by a dynamically assigned home agent. > > > > Various metrics and mechanisms can be used to assign the HA > > intelligently. We are not suggesting or enforcing any specific > > mechanism. Using the same logic, there may not be any further > > redirection and the first HA to receive the RRQ can accept and > > create binding. > > I agree with this statement, and I am not proposing that we add > selection mechanisms or criteria to the draft. > > > > My main concern with this draft is that there is a lot left > > > unspecified (just look for all the occurrences of "outside the scope") > > > and some of these unspecified procedures are actually quite > > > important. For example, the abstract says: > > > > Since the draft specifies a framework (or a structure or a front > > end mechanism, whatever we call it), in our opinion it should > > be open and satfisy as many requirements. As mentioned earlier, > > we want various implementors to define their own "optimal" > > behavior rather than forcing what we think is optimal. > > Hence the details on how to get to ones optimal HA is left > > out of scope. The draft says this in sections 1, 5.5. However > > the mulitple occurrences of the text "out of scope" are due to > > repeatition of same text so that each section is self sufficient. > > It can be removed in next rev. > > I don't think it needs to be removed everywhere (it is appropriate in > some places). See below... > > > > The distance between a > > > MN and HA affects the latency for control and data traffic. > > > When the distance between the MN and HA is large, the resulting > > > latency may be unacceptable. Therefore, it is advantageous to > > > select a nearest HA to the MN during initial registration. > > > > > > The mechanism outlined in the draft doesn't seem to satisfy this > > > requirement. This is because "Directed" HA must be a-priori > > > configured with the "Assigned" HA IP address, which implies they would > > > be in the same domain. So, the real meat of the above requirement is > > > that: > > > > > > (1) the MN (or the FA) must somehow discover a local HA to which the > > > message can be sent; and, > > > (2) the MN must develop a security association with that HA. > > > > > > Both of these procedures are ruled explicitly outside the scope of the > > > draft. Note that I think (1) or (2) can be met with procedures that > > > don't require any notion of "Directed" or "Assigned" HA. Rather, the > > > main thrust of the draft seems to be at the next requirement listed in > > > the abstract: > > > > > > There are other reasons for assigning an optimal HA beyond just > > > locality, such as administrative policies, load balancing etc. > > > > > > > Right, the framework tries to provide a sort of tool that can satisfy > > more that one requirement. I am not sure why that's not ok. > > Let me try to rephrase my issue: there are many lines of text in the > draft devoted to the forwarding registration requests from Directed HA > to Assigned HA. In fact, I would have to say this mechanism is the > main new *protocol* that is specified by this draft. However, this > mechanism seems targeted at the second motivation, rather than the > first. > > Personally, I would have written this draft with more of a focus on > the way an MN sends the RRQ to an FA, and the FA picks an HA. Sure, > the actual choice is outside the scope, but you could mention, e.g., > consultation of a AAA infrastructure, and/or looking at the HA address > in the RRQ to determine local vs. home network. Also, I think this > should only be allowed when the MN uses an authorization enabling > extension that can be verified from multiple different points in the > network, such as MN-AAA (i.e., MN-HA MUST NOT be used with this > mechanism). It can only be used when registering via an FA. Also, a > new security association MUST be created along with the registration. > Taken together, these sorts of changes would go a long way to > satisfying the first stated goal, which is allocation of a > local/remote HA for assisting with more optimal routing. > > > > The abstract goes on to state: > > > > > > This draft proposes a generic lightweight dynamic home agent > > > assignment framework. The goal of the framework is to provide a > > > mechanism to assign an optimal HA for a Mobile IP session while > > > allowing any suitable method for HA assignment. > > > > > > At best, this draft is really defining some front-end behavior > > > (message formats and Mobile IP processing) that would enable dynamic > > > home agent assignment, but I wouldn't go so far as to call it a > > > framework (due to the large amount of unspecified work left to do). > > > > If the term "framework" isn't appealing, can you suggest appropriate > > alternative? The reason for terming as such is because it incorporates > > (i) the ability to allow the RRQ to be responded to by dyn HA and > > (ii) logical separation of 2 addresses viz. Directed HA address and > > Assigned HA address. The Directed HA and Assigned HA are merely > > logical entities and dealt extensively in section 5.3, 5.4 and 5.5. > > > > We do not want to suggest a specific mechanism e.g. AAA, DNS etc. > > and tie it specifically tp form a solution as we envision that it > > is deployment specific. Thus we are providing a generic framework/ > > front end mechanism within MoObile IP to allow that. > > I like the term "front end mechanism" better than "framework." This > draft really describes only the Mobile IP processing, while leaving a > lot to back-end infrastructure. The term "framework" implies > something more complete. > > > > The draft also assumes that the assigned HA will be able to verify the > > > authentication extensions in the redirected RRQ. In section 5.1 the > > > draft states: > > > > > > Example of one such implementation is where MN > > > shares identical security associations with all the Directed > > > HA(s) and Assigned HA(s) in the network. > > > > > > I consider this to be completely unacceptable security practice and I > > > think this statement should be removed from the draft. Rather, it > > > seems like this method will only work with something like the MN-AAA > > > extension that can be verified from one of many HAs in the network, > > > and that a security association MUST be developed dynamically along > > > the lines of the AAA-keys draft. I think limitations like this should > > > be described in the security considerations. I understand a new > > > version with expanded security considerations is in preparation; I > > > will defer additional security comments until it comes out. > > > > Since this section is updated in latest version of the draft, let's > > defer the discussion on SAs. I will send the new version to the > > WG soon. > > Ok, I look forward to it. > > > > So, I think the draft may be valuable in that it specifies the > > > front-end behavior necessary to enable AAA-keys and the MIPv4 Diameter > > > application. This is similar to the way the NAI and MN-AAA draft > > > specify front-end behavior, while leaving the actual authentication to > > > AAA mechanisms specified elsewhere. However, this draft seems to > > > sneak in some additional HA redirection functionality (purely for load > > > balancing) that I am not convinced is required at this time. > > > > I respectfully disagree, load balancing may not be needed > > immediately, but is a valid requirement and the logical separation > > of assigned HA and directed HA address solves it too. > > > > Load balancing is one example where dynamic HA framework is useful. > > There is no intention to 'sneak' in a solution. THis is a real > > problem for large deployment with 'millions' of subscribers as is > > starting to happen with 3G deployment. > > > > On the contrary, the way we see it is, this draft adds a lot of > > practical value to the MN-AAA key distribution draft. With that > > draft, the SA are dynamically derived with an HA, but how is the > > HA found. If an 'optimal' HA is dynamically found, then that > > draft can be used to set up SAs. > > I do see value in load balancing, but I wonder if it could be > addressed separately. For example, we could have a rejection code > that specified a new HA. > > Upon further consideration, I have a number of new technical questions > about the mechanism of forwarding a registration request from one HA > to another: > > 1) It doesn't appear to work when using co-located COA when > registering via an FA. In this case, the COA in the RRQ does NOT > indicate where to send a response. Your mechanism seems to depend > on this, because it over-writes the original source IP address of > the packet. > > 2) It seems to open a security vulnerability, because an FA must now > process any response that comes from anywhere with a matching > Identifier. If it is a rejection, the FA will delete the pending > visitor list entry. This could allow attackers to deny service when the MN > tries to register. Previously, we could argue that deployment of > ingress filtering alleviated this concern. Note that an FA often does > not have a security association to every HA with which it will interact. > > 3) Can we guarantee that the routing of RRQs among HAs will be > loop-free? > > In contrast, a rejection code would not introduce the new security > concerns, because we keep the existing Mobile IP message flow. The MN > would need to create/obtain security associations with each HA > independently (i.e., security would be orthogonal to the dynamic > assignment). Finally, the MN would have the ability to detect > misconfigured HAs that were pointing at each other because it would > see each redirection on an end-to-end basis. > > -Pete > > > > Thanks, > > Milind > > > > > > > I would > > > like to hear the opinions of others in the WG on whether this is > > > important enough to include in the current draft - perhaps it could > > > best be addressed with a separate draft, using a Rejection code > > > instead of a forwarding mechanism? > > > > > > > > > -Pete --=.kQfAeV:b+MuzC( Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/UHkEeVhrtTJkXCMRAiYTAJ9PWSRqNxAf67EQgO9XHXmL6ybSzQCfRy7A r+WCRigVVuI14GywlfZd57M= =4jgS -----END PGP SIGNATURE----- --=.kQfAeV:b+MuzC(-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Aug 30 11:28:18 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 LAA18235 for ; Sat, 30 Aug 2003 11:28:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t70f-0000Hx-UU for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 10:47:26 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7UElPEd001101 for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 10:47:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t6f6-0007Un-78 for mip4-web-archive@optimus.ietf.org; Sat, 30 Aug 2003 10:25: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 KAA14743 for ; Sat, 30 Aug 2003 10:25:00 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t6f3-0005ju-00 for mip4-web-archive@ietf.org; Sat, 30 Aug 2003 10:25:05 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19t6f2-0005jr-00 for mip4-web-archive@ietf.org; Sat, 30 Aug 2003 10:25:04 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t64D-0006LR-TZ; Sat, 30 Aug 2003 09:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t44U-0001x2-NG for mip4@optimus.ietf.org; Sat, 30 Aug 2003 07:39:11 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07763 for ; Sat, 30 Aug 2003 07:39:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t44T-0001rc-00 for mip4@ietf.org; Sat, 30 Aug 2003 07:39:09 -0400 Received: from h195n1fls311o871.telia.com ([213.64.174.195] helo=riesling.local.levkowetz.com) by ietf-mx with smtp (Exim 4.12) id 19t44S-0001rV-00 for mip4@ietf.org; Sat, 30 Aug 2003 07:39:08 -0400 Received: (qmail 11773 invoked from network); 30 Aug 2003 11:38:31 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 30 Aug 2003 11:38:31 -0000 Date: Sat, 30 Aug 2003 13:38:31 +0200 From: Henrik Levkowetz To: Pete McCann Cc: "Jayshree Bharatia" , "'mip4@ietf.org'" Subject: Re: [Mip4] RFC3012bis: Proposal for Issue2-Change5 Message-Id: <20030830133831.34812a03.henrik@levkowetz.com> In-Reply-To: <16207.34215.643142.575989@gargle.gargle.HOWL> References: <870397D7C140C84DB081B88396458DAF746B2B@zrc2c000.us.nortel.com> <16207.34215.643142.575989@gargle.gargle.HOWL> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="=.w9iPB,Ek?A,+9w" 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: , --=.w9iPB,Ek?A,+9w Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Pete, Jayshree, Commenting on some specific proposals from Pete below (chair hat off): Friday 29 August 2003, Pete wrote: > > Hi, Jayshree, > > I am reorganizing all the text proposals into this one note for easier > reference. See comments below, and let me know if I missed one of > your notes. > > > [note chair hat is off for the remainder of this message] > > > > The current proposal for issue 1 is to use "previously unused challenge" in > > section 2 for all multicast and unicast Agent Advertisements. > > I am not sure what you mean by this. Can you give a specific text > proposal, and a location for it in the draft? > > > In addition to this, Henrik proposed a new text for a new subsection 2.1. > > > > 2.1 Handling of Solicited Agent Advertisements > > > > When a foreign agent generates an Agent Advertisement in response to a > > Router Solicitation [4], some additional considerations come into play. > > According to the Mobile IP base specification [7], the resulting Agent > > Advertisement may be either multicast or unicast. > > > > If the solicited Agent Advertisement is multicast, it MUST NOT generate a > > new Challenge value and update its window of remembered advertised > > Challenges. It must instead re-use the most recent of the CHALLENGE_WINDOW > > Advertisement Challenge values. > > > > If the agent advertisement is unicast back to the soliciting mobile node > > MUST be handled as follows: If the challenge most recently unicast to the > ^ insert the word "it" > > > soliciting mobile node has not been previously used (as defined in Section > > 1.1), in SHOULD > > be repeated in the newly issued unicast agent advertisement, otherwise a new > > challenge MUST be generated and remembered as the most recent challenge > > issued to the mobile node. (For further discussion of this, see Section 12.) > > I agree with this so far. > > > A foreign agent SHOULD NOT respond arbitrarily often to agent solicitations, > > in order to limit processing load, especially in the face of hostile nodes > > soliciting at a very high rate. The rate of solicited agent advertisement > > responses SHOULD at most be 50 per second. > > I am not sure we need the last paragraph. Overload control, > especially the choice of which solicitations to discard, is a tricky > subject. I don't know that we will come to any agreement on a maximum > rate (cf. previous discussions on the Mobile IP list regarding > multicast agent advertisement rates). I'm ok with not specifying any particular maximum rate. What adding some text to the security considerations section about this (in addition to the proposal you (Pete) make further down) : "In order to limit processing load, a foreign agent need not respond arbitrarily often to agent solicitations. In the face of hostile nodes soliciting at a very high rate, a foreign agent MAY limit the rate of agent advertisement responses." > > The original proposal from Henrik was to mandate a challenge in a > > Registration Reply. After few email exchanges, it was decided that the > > current text in section 3.3 (RFC3012bis (version 05) ) is ok. In addition to > > the current text, Henrik proposed the following text to be used as a > > guidance/background: > > > > (section 3.3) > > One example of a situation where the Foreign Agent MAY omit the inclusion of > > a Mobile-Foreign Challenge Extension in the Registration Reply would be when > > a new challenge has been multicast recently. The Foreign Agent could then > > assume that the mobile node with high likelihood has received and can use > > the multicast challenge. A mobile node MUST be prepared to use a multicast > > challenge in lieu of one returned in a Registration Reply, and MUST solicit > > for one if it has not already received one in a Registration Reply or Agent > > Advertisement. > > This is good, but it doesn't seem quite strong enough, i.e., we still > have a SHOULD on the inclusion of the previously unused challenge. It > seems to me we should require (with a MUST) the inclusion of a > challenge in the registration reply if something like the condition > above isn't met, and similarly should require (with a MUST) the > inclusion of a challenge in responses to Agent Solicitations if the > condition isn't met. This is the only way to guarantee progress on a > link where advertisements may be lost and where there is a long > interval between unsolicited advertisements. Ok. What about the following text, instead of the proposed paragraph above: "One example of a situation where the Foreign Agent MAY omit the inclusion of a Mobile-Foreign Challenge Extension in the Registration Reply would be when a new challenge has been multicast recently. The Foreign Agent could then assume that the mobile node with high likelihood has received and can use the multicast challenge. If a foreign agent has conditions in which it omits the inclusion of a Mobile-Foreign Challenge Extension in the Registration Reply, it still MUST respond with an agent advertisement containing a previously unused challenge in response to a subsequent agent solicitation from the same mobile node. Otherwise (when the said conditions are not met) the foreign agent MUST include a previously unused challenge in any Registration Reply, successful or not. A mobile node MUST be prepared to use a challenge from a unicast or multicast Agent Advertisement in lieu of one returned in a Registration Reply, and MUST solicit for one if it has not already received one in a Registration Reply." > > > > > The current proposal from Pete is to reuse the challenge in the Registration > > Reply of the Registration Request for which the authentication fails at the > > FA. This challenge sent in the Registration reply will be same as the > > challenge received in the Registration Request for which the reply is sent. > > > > To reflect this point, the following changes are proposed by Jayshree: > > > > (change 2.1-Section 3.2) > > From: > > If the registration message contains a Mobile-Foreign Authentication > > extension with an incorrect authenticator that fails verification, the > > Foreign Agent MAY send a Registration Reply to the mobile node with Code > > value BAD_AUTHENTICATION (see Section 10). > > > > To: (Added last statement) > > If the registration message contains a Mobile-Foreign Authentication > > extension with an incorrect authenticator that fails verification, the > > Foreign Agent MAY send a Registration Reply to the mobile node with Code > > value BAD_AUTHENTICATION (see Section 10). In this case, if the Mobile Node > > is currently registered, the challenge included in the Registration Reply > > by the Foreign Agent MUST be the same as the one received in the > > Registration Request. > > > > > > (change 2.2-Section 3.2) > > From: > > If the registration message contains a Mobile-AAA Authentication extension > > with an incorrect authenticator that fails verification, the Foreign Agent > > MAY send a Registration Reply to the mobile node with Code value > > BAD_AAA_AUTHENTICATION_SET_BY_FA. > > > > To: (Added last statement) > > If the registration message contains a Mobile-AAA Authentication extension > > with an incorrect authenticator that fails verification, the Foreign Agent > > MAY send a Registration Reply to the mobile node with Code value > > BAD_AAA_AUTHENTICATION_SET_BY_FA. In this case, if the Mobile Node is > > currently registered, the challenge included in the Registration Reply by > > the Foreign Agent MUST be the same as the one received in the Registration > > Request. > > > > (change 2.3-Section 3.5) > > From: > > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if > > the Registration Request contains a Mobile-AAA Authentication extension with > > an incorrect authenticator that fails verification. A Mobile Node that > > receives a > > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a new Challenge value in any new > > registration, obtained either from an Agent Advertisement, or from a > > Challenge extension to the Registration Reply containing the error. > > > > To: (Replaced "new Challenge" to "Challenge") > > BAD_AAA_AUTHENTICATION_SET_BY_FA: This error is sent by the Foreign Agent if > > the Registration Request contains a Mobile-AAA Authentication extension with > > an incorrect authenticator that fails verification. A Mobile Node that > > receives a > > BAD_AAA_AUTHENTICATION_SET_BY_FA MUST use a Challenge value in any new > > registration, obtained either from an Agent Advertisement, or from a > > Challenge extension to the Registration Reply containing the error. > > I don't support the text changes above, although I may have proposed > the principle of "repeating challenges." Perhaps we don't need to > make any text changes in this section, but can confine the new text to > the security considerations (see my proposal below). Ok with me. > > This change further extends point mentioned in change 1 for issue 2. The > > proposal from Henrik was to clarify the use of challenge. This text is > > intended as a new paragraph in section 3.3. > > > > "If the challenge most recently issued to the soliciting mobile node has not > > been previously used (as defined in Section 1.1), the most recent challenge > > unicast to the mobile node through a registration reply or a unicast agent > > advertisement SHOULD be repeated in the registration reply." > > > > This proposal was further modified by Pete differentiating the processing at > > the FA for the registered and unregistered users: > > > > "When responding to an unregistered MN with an unsuccessful Registration > > Reply, the FA SHOULD include the same challenge that was last included in a > > multicast Agent Advertisement. When responding to a registered MN with a > > successful or unsuccessful Registration Reply, the FA SHOULD include the > > same challenge that was last included in a multicast Agent Advertisement, > > when that challenge is previously unused by the MN. Otherwise, the FA > > SHOULD include the same challenge that was previously unicast to the MN in a > > Registration Reply or Agent Advertisement, unless that challenge was > > previously used. In that case, the FA SHOULD create a new challenge and > > return it to the MN, storing a copy of it with the visitor list entry for > > that MN." > > Based on the subsequent discussion, I don't think we need the text > changes above. See the security considerations: I'm ok with skipping this change and handling it through the security consideration change proposed. > > The following text was proposed to be added in section 12. This is a > > modified version of the text proposed by Henrik on the mailing list earlier. > > > > (section 12) > > Note that an active attacker may try to prevent successful registrations by > > sending a large number of Agent Solicitations or bogus Registration > > Requests, each of which could cause the FA to respond with a fresh > > challenge, invalidating the challenge that the MN is currently trying to > > use. To prevent such attacks, the FA SHOULD repeat the same challenge value > > in successive unicast responses to Agent Solicitations or in Registration > > Replies to Requests that did not contain valid MN-AAA or MN-FA > > authentication extensions. Note that each challenge returned to an MN MUST > > be previously unused by that MN. > > Based on subsequent comments from Ahmad, maybe we can make the > requirement more generic here, and give a specific example in Appendix > E. For here, how about: > > Note that an active attacker may try to prevent successful > registrations by sending a large number of Agent Solicitations or > bogus Registration Requests, each of which could cause the FA to > respond with a fresh challenge, invalidating the challenge that the MN > is currently trying to use. To prevent such attacks, the FA MUST NOT > invalidate previously unused challenges when responding to > unauthenticated Registration Requests or Agent Solicitations. In > addition, the FA MUST NOT allocate new storage when responding to such > messages, because this would also create the possibility of denial of > service. Ok with me. > > It was decided that challenges sent in unicast Agent Advertisements and sent > > in Registration Reply messages should be treated same at the FA. For this, > > the following text is proposed by Henrik and Pete: > > > > (change 5.1-Section 3.2) > > From: > > The Foreign Agent MUST NOT accept any Challenge in the Registration Request > > unless it was offered in last Registration Reply issued to the Mobile Node, > > or else advertised as one of the last CHALLENGE_WINDOW (see section 9) > > Challenge values inserted into the immediately preceding Agent > > advertisements. > > > > To: > > The Foreign Agent MUST NOT accept any Challenge in the Registration Request > > unless it was offered in the last Registration Reply or unicast Agent > > Advertisement sent to the Mobile Node, or else advertised as one of the last > > CHALLENGE_WINDOW (see section 9) Challenge values inserted into the > > immediately preceding Agent advertisements. > > > > (change 5.2-Appendix E) > > From: > > In the program fragment, it is presumed that the foreign agent keeps an > > array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the > > last advertised challenge used by a mobile node, and > > also a record of the last challenge provided to a mobile node in a > > Registration Reply. > > > > To: > > In the program fragment, it is presumed that the foreign agent keeps an > > array of advertised Challenges ("VALID_ADV_CHALLENGES"), a record of the > > last advertised challenge used by a mobile node, and also a record of the > > last challenge provided to a mobile node in a Registration Reply or unicast > > Agent Advertisement. > > After that, we could add, "To meet the security obligations outlined > in Section 12, the FA SHOULD use one of the already stored, previously > unused challenges when responding to an unauthenticated Registration > Request or Agent Solicitation." Ok with me. Regards, Henrik --=.w9iPB,Ek?A,+9w Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/UIy3eVhrtTJkXCMRAt1yAJ9UfybC2k1CHIf0GmfNmIXr33aFKgCggiJc qjgZlwOICn13Q4WmoIk2PMs= =LVCP -----END PGP SIGNATURE----- --=.w9iPB,Ek?A,+9w-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4 From exim@www1.ietf.org Sat Aug 30 11:28:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18290 for ; Sat, 30 Aug 2003 11:28:56 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t70c-0000HE-Ah for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 10:47:22 -0400 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h7UElMGs001060 for mip4-archive@odin.ietf.org; Sat, 30 Aug 2003 10:47:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t6fF-0007VE-6x for mip4-web-archive@optimus.ietf.org; Sat, 30 Aug 2003 10:25:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14769 for ; Sat, 30 Aug 2003 10:25:09 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t6fC-0005kX-00 for mip4-web-archive@ietf.org; Sat, 30 Aug 2003 10:25:14 -0400 Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19t6fB-0005kT-00 for mip4-web-archive@ietf.org; Sat, 30 Aug 2003 10:25:13 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t63q-0006J7-H2; Sat, 30 Aug 2003 09:46:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19t3Dx-0008Vu-Ir for mip4@optimus.ietf.org; Sat, 30 Aug 2003 06:44: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 GAA06137 for ; Sat, 30 Aug 2003 06:44:45 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19t3Dt-0000kt-00 for mip4@ietf.org; Sat, 30 Aug 2003 06:44: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 19t3Ds-0000kj-00 for mip4@ietf.org; Sat, 30 Aug 2003 06:44:48 -0400 Received: (qmail 11402 invoked from network); 30 Aug 2003 10:44:19 -0000 Received: from unknown (HELO riesling) (127.0.0.1) by localhost with SMTP; 30 Aug 2003 10:44:19 -0000 Date: Sat, 30 Aug 2003 12:44:18 +0200 From: Henrik Levkowetz To: mip4@ietf.org Message-Id: <20030830124418.7a176d93.henrik@levkowetz.com> X-Mailer: Sylpheed version 0.9.0claws (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="e=.ZE,nlp?/vh=,," Subject: [Mip4] [Issue] draft-kulkarni-mobileip-dynamic-assignment: Routing concerns 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: , --e=.ZE,nlp?/vh=,, Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, One concern I've had with this draft is the change in routing. In MIPv4, prior to this, RRQ and RRP has always travelled back and forth between the same two end nodes, while here we introduce a change where a different node than the HA originally addressed by the MN may be answering. Pete has already pointed out 3 issues with this: a) It removes the possibility to do ingress filtering of RRPs, which widens the possibility of DOS attacks by forging rejections b) It seems not to work with co-located CoA registration through FA c) It raises the possibility of routing loops amongst HA's I'd like to add yet another one: d) It seems to me that it also breaks the NAT traversal mechanism, which is rather crucial to a large part of the deployment scenarios we are currently seeing. The port on the NAT from which the original request was issued is lost through the forwarding, and if the Directed HA overwrites the source address, the detection of the NAT is also made impossible. (Actually, if the Directed HA overwrites the source address, an Assigned HA with NAT traversal support would identify the Directed HA as a NAT) For these reasons, I think it would be much better to have a solution where the first (Directed) HA returns an error reply and and indication of the next HA to contact to the MN. This would remove all the objections above, admittedly with the loss of some efficiency, but correct operation has to come before efficiency, as I see it. Henrik --e=.ZE,nlp?/vh=,, Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/UIADeVhrtTJkXCMRAglZAKDQUM43dfpYaWlh65a0AWiKq1vwhQCgqrYC RxoihF2u/9K6gdFCjSqk8e0= =GmQ3 -----END PGP SIGNATURE----- --e=.ZE,nlp?/vh=,,-- _______________________________________________ Mip4 mailing list Mip4@ietf.org https://www.ietf.org/mailman/listinfo/mip4