From mip6-bounces@ietf.org Wed Nov 01 01:37:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf9hy-0003RC-9h; Wed, 01 Nov 2006 01:36:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf9hw-0003Qy-SZ for mip6@ietf.org; Wed, 01 Nov 2006 01:36:16 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf9ht-0007KX-6z for mip6@ietf.org; Wed, 01 Nov 2006 01:36:14 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA16a9IK005759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 31 Oct 2006 22:36:09 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.141.78]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA16a6C8028363; Tue, 31 Oct 2006 22:36:08 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Oct 2006 22:36:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT Date: Tue, 31 Oct 2006 22:36:06 -0800 Message-ID: In-Reply-To: <45481BD4.9070506@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT Thread-Index: Acb9bBfRW63j67/rQdCXJcCllT2tLAAEdu8A From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Soliman, Hesham" X-OriginalArrivalTime: 01 Nov 2006 06:36:06.0957 (UTC) FILETIME=[02B315D0:01C6FD80] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I don't understand something here. Why would ESP tunnel mode not provide the needed protection? Given that we already have two IP headers in this case, it isn't even adding any overhead. I can't see why we need anything else.=20 I can understand not wanting to impose AH, but I don't see ESP tunnel mode as a restriction at all.=20 So, the headers would simply be: IPv4 HDR (src=3Dnatted-v4, dst=3DHA-addr) UDP ESP IPv6 HDR (src=3Dv4-mapped-v6, dst=3DHA-addr) DST-OPT MH (BU) What's the problem with that?=20 Vidya > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Tuesday, October 31, 2006 8:00 PM > To: Soliman, Hesham > Cc: Narayanan, Vidya; mip6@ietf.org; Pascal Thubert (pthubert) > Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not=20 > be usedwhen traversingIPv4 NAT >=20 > Soliman, Hesham wrote: > > > well, if there is a NAT on the path the source > address on the=20 > > outer IPv4 header is modified. > > > anytime a packet goes through a NAT, we have > this=20 > problem. this=20 > > is a common problem. so I > don't think we should design a=20 > DS-MIPv6 =20 > > > specific mechanism to protect an address that > is=20 > modified by the=20 > > NAT. its not worth it. > >=20 > > =3D> You keep repeating that and I keep answering as follows:=20 > If there=20 > > is an alt-coa in the packet then the HA has no way of=20 > knowing if there=20 > > was a NAT or not without checking it first, it can't simply compare=20 > > the outer headers... >=20 > I actually agree with this. :) >=20 > Again, this has nothing to do with the presence of the > > NAT and everything to do with the presence of the alt-CoA... > >=20 > > So it makes zero sense to say that the "HA should ignore=20 > the alt-coa=20 > > if a NAT were detected" because the HA can't possibly know=20 > that a NAT=20 > > was en route without inspecting the alt-coa.... >=20 > hmmm... there is a misunderstanding. I didn't say ignore the=20 > alt-CoA option. I said the HA should not use the contents of=20 > the altCoA option as the CoA when it detects a NAT. >=20 > it does not matter if the HA compares the source address on=20 > the outer IPv4 header with the source address of the inner=20 > header or the contents of the altCoA option to detect the=20 > presence of a NAT. its the same for me. >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 01:44:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf9pz-0007p2-Hb; Wed, 01 Nov 2006 01:44:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf9py-0007ou-8F for mip6@ietf.org; Wed, 01 Nov 2006 01:44:34 -0500 Received: from neon.tcs.hut.fi ([130.233.215.20] helo=mail.tcs.hut.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf9pv-0001aU-JK for mip6@ietf.org; Wed, 01 Nov 2006 01:44:34 -0500 Received: by mail.tcs.hut.fi (Postfix, from userid 65534) id 73A212C00B6D5; Wed, 1 Nov 2006 08:44:30 +0200 (EET) Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by mail.tcs.hut.fi (Postfix) with ESMTP id 195F62C0016E2; Wed, 1 Nov 2006 08:44:30 +0200 (EET) Date: Wed, 1 Nov 2006 08:44:30 +0200 (EET) From: Wassim Haddad To: "Soliman, Hesham" Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be used when traversingIPv4 NAT In-Reply-To: <2309978910A6A6478C2C7585692B0AF40151E4@NAEX16.na.qualcomm.com> Message-ID: References: <2309978910A6A6478C2C7585692B0AF40151E4@NAEX16.na.qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-TCS: No X-Spam-Checker-Version: SpamAssassin 3.0.3-tcs20061018 (2005-04-27) on mail.tcs.hut.fi X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.3-tcs20061018 X-Spam-TCS-score: 0.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Reading Pascal's comment: 1. YES Wassim H. On Tue, 31 Oct 2006, Soliman, Hesham wrote: > Pascal, all, > > There's been a lot of emails on this issue so I think WG members are > fully informed now about what this issue involves. I will ask a simple > question and I'd like people to choose one of the options below. To > avoid any confusion I'm keeping the question simple and clear. > > Leaving the checksum option and integrity issue aside (because I know we > can fix it and I'm writing a separate issue for it) please let give me > an answer to the following question: > > Do you agree that the MN does not include the Alt-CoA option in the BU > when it is located in an IPv4-only network? > > 1. Yes > 2. No > > Please include a brief reason for you answer, Pascal already did so I > don't expect another one :). As I said, ignore the checksum issue, this > will be handled separately. > > FWIW, I choose 1) above because it's the only way to make sure that the > HA can detect the presence of a NAT by comparing the outer v4 addresses > with the IPv6 header. > > Hesham > > > > -----Original Message----- > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > Sent: Tuesday, October 31, 2006 4:12 AM > > To: Soliman, Hesham; mip6@ietf.org > > Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used > > when traversingIPv4 NAT > > > > Hi Hesham: > > > > I agree: > > > > 1) with relaxing the requirement in RFC 3775 to include an Alt CoA > > option all the time. > > > > 2) that the MN should omit it, as opposed to the HA filtering it out. > > The Alt CoA is the real address at which the MN is reachable, that is > > what HAs implement today, that is what all people in the art > > understand. > > I want to stay simple and keep it that way. I'd hate to > > have rules like > > "this is A but then if there is also that then this is B which is the > > opposite of A", etc... we are not lawyers! > > > > 3) that we have to find an alternate way to endure that the MN is > > reachable at the CoA, defined as the source of the packet when the HA > > gets it. > > > > I'd also agree that: > > > > 4) UDP is used all the time in IPv4 roaming situation, regardless on > > whether NAT is detected or not. That's not really in the > > mail but since > > you fixed the message format in the thread to add UDP, I > > take advantage > > of the exchange to raise that point again. > > > > I disagree: > > > > 5) to jump too quickly on the conclusion that the checksum > > is the way to > > go. I understand that it has value in certain scenarios that you > > mention. But it fails to guarantee that the MN is reachable > > at the CoA > > in another common case that is NAT; and it does not protect against a > > rogue DHCP server assigning you an IPv4 DoS'ed address, which could > > easily happen in the IPv4 world. > > > > So when you call for consensus, please leave open the > > solution to 3) so > > we can see if there's a preferable alternative. I, for one, > > would favor > > an approach like 2 BU flows in row, which would emulate a 3 way > > handshake and guarantee the reachability of the MN in all cases. > > > > Pascal > > > > > > > > > > >-----Original Message----- > > >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > > >Sent: Thursday, October 19, 2006 6:19 PM > > >To: mip6@ietf.org > > >Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used when > > traversingIPv4 NAT > > > > > >Folks, > > > > > >This issue was revived mainly due to Vijay points on the > > need for the > > >checksum option when the alt-CoA is not used. Let me summarise the > > >issues first then propose a way forward. > > > > > >Summary: > > >-------- > > > > > >The initial resolution for the issue suggested that we add > > a checksum > > >option that includes a checksum on the src and dst addresses in the > > IPv6 > > >header. This was suggested to be used when the alt-coa is > > not present > > to > > >maintain the integrity of the src address when ESP is used. > > I want to > > >emphasise that this is only needed when ESP is used, not with AH. > > > > > >Now the point that Vijay raised is also quite valid: With NAT > > traversal, > > >the outer IPv4 header is vulnerable, yet it is needed because the HA > > >responds to that address and sets up the UDP tunnel to the outer > > >(natted) IPv4 src address in the packet containing the BU. > > There is no > > >way we can secure that address, yet, it essentially acts as another > > >binding, which if modified maliciously, would redirect the > > MN's packets > > >to another IPv4 address. To be clear, here is the packet format: > > >BU packet received by HA after passing through NAT: > > > IPv4 HDR (src=natted-v4, dst=HA-addr) > > > UDP > > > IPv6 HDR (src=v4-mapped-v6, dst=HA-addr) > > > ESP > > > DST-OPT > > > MH (BU) > > > > > >The HA responds with a similar packet including the BA and > > forwards all > > >future packets in the UDP tunnel, with the dst address in the IPv4 > > >header being the "natted-v4" address above. > > >So essentially protecting the BU does not protect the MN from > > >redirection attacks in this case because the IPv4 header is > > vulnerable. > > >This is an inherent problem with NAT traversal. There is practically > > >nothing we can do about it. > > > > > >So the remaining question is: Is it worth worrying about > > the integrity > > >of the BU in this case? IMHO I think the answer is yes. > > Why? Two main > > >reasons: > > > > > >1. There can be cases where the BU is sent to a local HA and the > > >operator can guarantee that no NATs are in the path. In this case we > > >would lose integrity for no reason, i.e. the BU becomes the weakest > > >link. This is not unusual really because an operator may > > decide that it > > >will only provide the HA function within its domain, which > > happens to > > >not include NATs between the MN and the HA. > > > > > >2. We have precedence with MIPv4 and NAT traversal where the RREQ is > > >still secure despite the UNSAF NAT traversal. > > > > > >Note that the answer to 1) above may be "Use AH", but I > > prefer to not > > >force that on implementations that do not do it today > > (although I would > > >personally prefer AH in general for the BU). > > > > > >For these reasons, and there may be more, I prefer to not > > take this big > > >decision to lose the integrity for the BU. > > > > > >Way forward: > > >------------ > > > > > >This issue is now closed, we all agree on it, but there may be > > >disagreement on the checksum part. So I suggest that I > > generate a new > > >issue for this discussion. Until the new issue is resolved, > > I won't add > > >the checksum option to the draft. > > > > > >Feel free to send comments. > > > > > >Hesham > > > > > >_______________________________________________ > > >Mip6 mailing list > > >Mip6@ietf.org > > >https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 06:42:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfETP-0008Lw-Uh; Wed, 01 Nov 2006 06:41:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfETO-0008KP-CH for mip6@ietf.org; Wed, 01 Nov 2006 06:41:34 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfETL-0001hG-8R for mip6@ietf.org; Wed, 01 Nov 2006 06:41:34 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA1BfSii024849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 03:41:29 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA1BfQqW024895; Wed, 1 Nov 2006 03:41:28 -0800 (PST) Received: from SANEXCAS02.na.qualcomm.com ([172.30.36.176]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 03:41:27 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 03:41:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT Date: Wed, 1 Nov 2006 03:41:24 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF40367BD@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT Thread-Index: Acb9bBfRW63j67/rQdCXJcCllT2tLAAEdu8AAAsX8DA= From: "Soliman, Hesham" To: "Narayanan, Vidya" , "Vijay Devarapalli" X-OriginalArrivalTime: 01 Nov 2006 11:41:26.0626 (UTC) FILETIME=[AA12BC20:01C6FDAA] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org This is a good idea I think. But let's save this discussion for the separate issue handling the integrity of the packet. I'll send it out soon. But my initial reaction is that this might be better than the checksum option since it doesn't add anything new and doesn't add overhead.=20 Hesham > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Wednesday, November 01, 2006 5:36 PM > To: Vijay Devarapalli; Soliman, Hesham > Cc: mip6@ietf.org; Pascal Thubert (pthubert) > Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not=20 > beusedwhen traversingIPv4 NAT >=20 >=20 > I don't understand something here. Why would ESP tunnel mode=20 > not provide > the needed protection? Given that we already have two IP=20 > headers in this > case, it isn't even adding any overhead. I can't see why we need > anything else.=20 >=20 > I can understand not wanting to impose AH, but I don't see ESP tunnel > mode as a restriction at all.=20 >=20 > So, the headers would simply be: >=20 > IPv4 HDR (src=3Dnatted-v4, dst=3DHA-addr) > UDP > ESP > IPv6 HDR (src=3Dv4-mapped-v6, dst=3DHA-addr) > DST-OPT > MH (BU) >=20 >=20 > What's the problem with that?=20 >=20 > Vidya >=20 >=20 > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > > Sent: Tuesday, October 31, 2006 8:00 PM > > To: Soliman, Hesham > > Cc: Narayanan, Vidya; mip6@ietf.org; Pascal Thubert (pthubert) > > Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not=20 > > be usedwhen traversingIPv4 NAT > >=20 > > Soliman, Hesham wrote: > > > > well, if there is a NAT on the path the source >=20 > address on the=20 > > > outer IPv4 header is modified. > > > > anytime a packet goes through a NAT, we have > this=20 > > problem. this=20 > > > is a common problem. so I > don't think we should design a=20 > > DS-MIPv6 =20 > > > > specific mechanism to protect an address that > is=20 > > modified by the=20 > > > NAT. its not worth it. > > >=20 > > > =3D> You keep repeating that and I keep answering as follows:=20 > > If there=20 > > > is an alt-coa in the packet then the HA has no way of=20 > > knowing if there=20 > > > was a NAT or not without checking it first, it can't=20 > simply compare=20 > > > the outer headers... > >=20 > > I actually agree with this. :) > >=20 > > Again, this has nothing to do with the presence of the > > > NAT and everything to do with the presence of the alt-CoA... > > >=20 > > > So it makes zero sense to say that the "HA should ignore=20 > > the alt-coa=20 > > > if a NAT were detected" because the HA can't possibly know=20 > > that a NAT=20 > > > was en route without inspecting the alt-coa.... > >=20 > > hmmm... there is a misunderstanding. I didn't say ignore the=20 > > alt-CoA option. I said the HA should not use the contents of=20 > > the altCoA option as the CoA when it detects a NAT. > >=20 > > it does not matter if the HA compares the source address on=20 > > the outer IPv4 header with the source address of the inner=20 > > header or the contents of the altCoA option to detect the=20 > > presence of a NAT. its the same for me. > >=20 > > Vijay > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 10:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIGj-0005ig-Bf; Wed, 01 Nov 2006 10:44:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIGh-0005ee-W7 for mip6@ietf.org; Wed, 01 Nov 2006 10:44:44 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfI3T-0000o7-CL for mip6@ietf.org; Wed, 01 Nov 2006 10:31:10 -0500 Received: from [10.1.210.16] ([10.1.210.16]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 07:31:02 -0800 Message-ID: <4548BDAB.4050409@azairenet.com> Date: Wed, 01 Nov 2006 07:30:51 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 15:31:02.0640 (UTC) FILETIME=[BD37A700:01C6FDCA] X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org when you create an IPsec SA in tunnel mode, the source address on the inner header becomes a traffic selector (goes in the TSi as the address). it shouldn't be the v4-mapped-v6 address. it has to be the v6 home address. Vijay Narayanan, Vidya wrote: > I don't understand something here. Why would ESP tunnel mode not provide > the needed protection? Given that we already have two IP headers in this > case, it isn't even adding any overhead. I can't see why we need > anything else. > > I can understand not wanting to impose AH, but I don't see ESP tunnel > mode as a restriction at all. > > So, the headers would simply be: > > IPv4 HDR (src=natted-v4, dst=HA-addr) > UDP > ESP > IPv6 HDR (src=v4-mapped-v6, dst=HA-addr) > DST-OPT > MH (BU) > > > What's the problem with that? > > Vidya > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, October 31, 2006 8:00 PM >> To: Soliman, Hesham >> Cc: Narayanan, Vidya; mip6@ietf.org; Pascal Thubert (pthubert) >> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not >> be usedwhen traversingIPv4 NAT >> >> Soliman, Hesham wrote: >>> > well, if there is a NAT on the path the source > address on the >>> outer IPv4 header is modified. >>> > anytime a packet goes through a NAT, we have > this >> problem. this >>> is a common problem. so I > don't think we should design a >> DS-MIPv6 >>>> specific mechanism to protect an address that > is >> modified by the >>> NAT. its not worth it. >>> >>> => You keep repeating that and I keep answering as follows: >> If there >>> is an alt-coa in the packet then the HA has no way of >> knowing if there >>> was a NAT or not without checking it first, it can't simply compare >>> the outer headers... >> I actually agree with this. :) >> >> Again, this has nothing to do with the presence of the >>> NAT and everything to do with the presence of the alt-CoA... >>> >>> So it makes zero sense to say that the "HA should ignore >> the alt-coa >>> if a NAT were detected" because the HA can't possibly know >> that a NAT >>> was en route without inspecting the alt-coa.... >> hmmm... there is a misunderstanding. I didn't say ignore the >> alt-CoA option. I said the HA should not use the contents of >> the altCoA option as the CoA when it detects a NAT. >> >> it does not matter if the HA compares the source address on >> the outer IPv4 header with the source address of the inner >> header or the contents of the altCoA option to detect the >> presence of a NAT. its the same for me. >> >> Vijay >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 10:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIMn-0000oi-Rm; Wed, 01 Nov 2006 10:51:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIMm-0000ng-Og for mip6@ietf.org; Wed, 01 Nov 2006 10:51:00 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfIMj-0006dk-7E for mip6@ietf.org; Wed, 01 Nov 2006 10:51:00 -0500 Received: from [10.1.210.16] ([10.1.210.16]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 07:50:56 -0800 Message-ID: <4548C250.9050207@azairenet.com> Date: Wed, 01 Nov 2006 07:50:40 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Mip6] WG LC: Yoshihiro Ohba's review References: <20061010133810.GA1208@ipv6-3.int-evry.fr> <45480357.2030601@azairenet.com> <20061101024039.GB22250@steelhead> In-Reply-To: <20061101024039.GB22250@steelhead> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 15:50:56.0499 (UTC) FILETIME=[84D01430:01C6FDCD] X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Yoshihiro Ohba wrote: > Hi Vijay, > > What I meant in my comment was that these requirements seem to > indicate "mandatory-to-support and optional-to-use" features, and thus > I thought it is better to say "MUST be able to" than "SHOULD be able > to". Perhaps we could simply say: > > G5.2 The AAAH MAY indicate to the HA if the MN is authorized to > autoconfigure its Home Address. > > G6.2 The NAS MAY notify that it supports the functionalities described > in [4]. sounds good to me. Vijay > > Yoshihiro Ohba > > > On Tue, Oct 31, 2006 at 06:15:51PM -0800, Vijay Devarapalli wrote: >> Gerardo Giaretta wrote: >> >>>> G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is >>>> authorized to autoconfigure its Home Address. >>>> >>>> YO: Why this is not "MUST be able to"? >>>> >>> I'll fix it. >> this might be specific to the home agent. basically >> the AAAH might not care whether the HA assigns the >> home address or if the HA allows the MN to >> autoconfigure the home address. so I don't think we >> should have a "MUST" here. >> >>>> G6.2 The NAS SHOULD be able to notify that it supports the >>>> functionalities described in [4]. >>>> >>>> YO: The NAS notifies to whom? I guess the NAS notifies AAAH server of >>>> the functionalities. If so, please explicitly mention it. Also why >>>> this is not "MUST be able to"? >>>> >>> ok, I'll fix it >> again, should this be a MUST? I don't think we >> should be requiring the NAS to be able to tell the >> AAAH that it can support this functionality. Kuntal? >> >> Vijay >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 13:18:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKfE-0003Bd-WA; Wed, 01 Nov 2006 13:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKfD-0003BU-Ec for mip6@ietf.org; Wed, 01 Nov 2006 13:18:11 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfKer-0007KA-L7 for mip6@ietf.org; Wed, 01 Nov 2006 13:18:11 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA1IHjjS013087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 10:17:47 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA1ICikB001373; Wed, 1 Nov 2006 10:17:43 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 10:14:49 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT Date: Wed, 1 Nov 2006 10:14:49 -0800 Message-ID: In-Reply-To: <4548BDAB.4050409@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT Thread-Index: Acb9ysWdh+uqzJqzRsGFFqpET9KrvgAFrqng From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 01 Nov 2006 18:14:49.0916 (UTC) FILETIME=[9EBAF7C0:01C6FDE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Let's discuss this more separate from this issue, as Hesham says. I don't think there is a problem. We can talk in SD to make sure there isn't an issue here.=20 Vidya=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Wednesday, November 01, 2006 7:31 AM > To: Narayanan, Vidya > Cc: Soliman, Hesham; mip6@ietf.org; Pascal Thubert (pthubert) > Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not=20 > be usedwhen traversingIPv4 NAT >=20 > when you create an IPsec SA in tunnel mode, the source=20 > address on the inner header becomes a traffic selector (goes=20 > in the TSi as the address). > it shouldn't be the v4-mapped-v6 address. it has to be the v6=20 > home address. >=20 > Vijay >=20 > Narayanan, Vidya wrote: > > I don't understand something here. Why would ESP tunnel mode not=20 > > provide the needed protection? Given that we already have two IP=20 > > headers in this case, it isn't even adding any overhead. I=20 > can't see=20 > > why we need anything else. > >=20 > > I can understand not wanting to impose AH, but I don't see=20 > ESP tunnel=20 > > mode as a restriction at all. > >=20 > > So, the headers would simply be: > >=20 > > IPv4 HDR (src=3Dnatted-v4, dst=3DHA-addr) > > UDP > > ESP > > IPv6 HDR (src=3Dv4-mapped-v6, dst=3DHA-addr) > > DST-OPT > > MH (BU) > >=20 > >=20 > > What's the problem with that?=20 > >=20 > > Vidya > >=20 > >=20 > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Tuesday, October 31, 2006 8:00 PM > >> To: Soliman, Hesham > >> Cc: Narayanan, Vidya; mip6@ietf.org; Pascal Thubert (pthubert) > >> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be=20 > >> usedwhen traversingIPv4 NAT > >> > >> Soliman, Hesham wrote: > >>> > well, if there is a NAT on the path the source >=20 > address on the=20 > >>> outer IPv4 header is modified. > >>> > anytime a packet goes through a NAT, we have > this > >> problem. this > >>> is a common problem. so I > don't think we should design a > >> DS-MIPv6 > >>>> specific mechanism to protect an address that > is > >> modified by the > >>> NAT. its not worth it. > >>> > >>> =3D> You keep repeating that and I keep answering as follows:=20 > >> If there > >>> is an alt-coa in the packet then the HA has no way of > >> knowing if there > >>> was a NAT or not without checking it first, it can't=20 > simply compare=20 > >>> the outer headers... > >> I actually agree with this. :) > >> > >> Again, this has nothing to do with the presence of the > >>> NAT and everything to do with the presence of the alt-CoA... > >>> > >>> So it makes zero sense to say that the "HA should ignore > >> the alt-coa > >>> if a NAT were detected" because the HA can't possibly know > >> that a NAT > >>> was en route without inspecting the alt-coa.... > >> hmmm... there is a misunderstanding. I didn't say ignore=20 > the alt-CoA=20 > >> option. I said the HA should not use the contents of the altCoA=20 > >> option as the CoA when it detects a NAT. > >> > >> it does not matter if the HA compares the source address=20 > on the outer=20 > >> IPv4 header with the source address of the inner header or the=20 > >> contents of the altCoA option to detect the presence of a NAT. its=20 > >> the same for me. > >> > >> Vijay > >> >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 13:37:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKxW-00032N-CX; Wed, 01 Nov 2006 13:37:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfKxV-000322-6d for mip6@ietf.org; Wed, 01 Nov 2006 13:37:05 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfKxQ-0004Ms-Sk for mip6@ietf.org; Wed, 01 Nov 2006 13:37:05 -0500 Received: from [10.1.201.12] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 10:37:00 -0800 Message-ID: <4548E948.2040204@azairenet.com> Date: Wed, 01 Nov 2006 10:36:56 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 18:37:00.0039 (UTC) FILETIME=[B78BA170:01C6FDE4] X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Narayanan, Vidya wrote: > Let's discuss this more separate from this issue, as Hesham says. I > don't think there is a problem. We can talk in SD to make sure there > isn't an issue here. I don't like this step-by-step process of splitting an issue into multiple small issues. it is easy to miss the context and just say yes or no to a particular small issue. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 13:52:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLCn-0004F1-4q; Wed, 01 Nov 2006 13:52:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLCl-0004EC-Rf for mip6@ietf.org; Wed, 01 Nov 2006 13:52:51 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLCi-0000Mq-QD for mip6@ietf.org; Wed, 01 Nov 2006 13:52:51 -0500 Received: from [10.1.201.12] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 10:52:48 -0800 Message-ID: <4548ECFF.2040001@azairenet.com> Date: Wed, 01 Nov 2006 10:52:47 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 18:52:48.0258 (UTC) FILETIME=[ECBA5E20:01C6FDE6] X-Spam-Score: 0.1 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Narayanan, Vidya wrote: > I > don't think there is a problem. We can talk in SD to make sure there > isn't an issue here. I missed replying to the above part. :) you can't change the source address in the inner header when a tunnel mode IPsec SA is used without invalidating the IPsec SA. so you always need the home address to appear as the source address on the inner header. from draft-ietf-mip6-ikev2-ipsec-07.txt > o The mobile node and the home agent MUST create security > associations based on the home address, so that the security > associations survive change in care-of address. When using IKEv2 > as the key exchange protocol, the home address should be carried > as the initiator IP address in the TSi payload during the > CREATE_CHILD_SA exchange [4]. for a tunnel mode SA, this means the source address on the inner IP header must be the home address. from RFC 3776 > mobile node SPD-S: > - IF source = home_address_1 & destination = any & > proto = MH & local_mh_type = HoTi & > remote_mh_type = HoT > Then use SA ESP tunnel mode > IDi = user_1, IDr = home_agent_1, > TSi = home_address_1, MH, HoTi > TSr = any, MH, HoT > outer src addr = care_of_address_1, > outer dst addr = home_agent_1, > inner src addr = home_address_1 note the "home_address_1 in the TSi when creating a tunnel SA. Vijay > > Vidya > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Wednesday, November 01, 2006 7:31 AM >> To: Narayanan, Vidya >> Cc: Soliman, Hesham; mip6@ietf.org; Pascal Thubert (pthubert) >> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not >> be usedwhen traversingIPv4 NAT >> >> when you create an IPsec SA in tunnel mode, the source >> address on the inner header becomes a traffic selector (goes >> in the TSi as the address). >> it shouldn't be the v4-mapped-v6 address. it has to be the v6 >> home address. >> >> Vijay >> >> Narayanan, Vidya wrote: >>> I don't understand something here. Why would ESP tunnel mode not >>> provide the needed protection? Given that we already have two IP >>> headers in this case, it isn't even adding any overhead. I >> can't see >>> why we need anything else. >>> >>> I can understand not wanting to impose AH, but I don't see >> ESP tunnel >>> mode as a restriction at all. >>> >>> So, the headers would simply be: >>> >>> IPv4 HDR (src=natted-v4, dst=HA-addr) >>> UDP >>> ESP >>> IPv6 HDR (src=v4-mapped-v6, dst=HA-addr) >>> DST-OPT >>> MH (BU) >>> >>> >>> What's the problem with that? >>> >>> Vidya >>> >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>> Sent: Tuesday, October 31, 2006 8:00 PM >>>> To: Soliman, Hesham >>>> Cc: Narayanan, Vidya; mip6@ietf.org; Pascal Thubert (pthubert) >>>> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be >>>> usedwhen traversingIPv4 NAT >>>> >>>> Soliman, Hesham wrote: >>>>> > well, if there is a NAT on the path the source > >> address on the >>>>> outer IPv4 header is modified. >>>>> > anytime a packet goes through a NAT, we have > this >>>> problem. this >>>>> is a common problem. so I > don't think we should design a >>>> DS-MIPv6 >>>>>> specific mechanism to protect an address that > is >>>> modified by the >>>>> NAT. its not worth it. >>>>> >>>>> => You keep repeating that and I keep answering as follows: >>>> If there >>>>> is an alt-coa in the packet then the HA has no way of >>>> knowing if there >>>>> was a NAT or not without checking it first, it can't >> simply compare >>>>> the outer headers... >>>> I actually agree with this. :) >>>> >>>> Again, this has nothing to do with the presence of the >>>>> NAT and everything to do with the presence of the alt-CoA... >>>>> >>>>> So it makes zero sense to say that the "HA should ignore >>>> the alt-coa >>>>> if a NAT were detected" because the HA can't possibly know >>>> that a NAT >>>>> was en route without inspecting the alt-coa.... >>>> hmmm... there is a misunderstanding. I didn't say ignore >> the alt-CoA >>>> option. I said the HA should not use the contents of the altCoA >>>> option as the CoA when it detects a NAT. >>>> >>>> it does not matter if the HA compares the source address >> on the outer >>>> IPv4 header with the source address of the inner header or the >>>> contents of the altCoA option to detect the presence of a NAT. its >>>> the same for me. >>>> >>>> Vijay >>>> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 14:09:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLSO-0005Qp-MZ; Wed, 01 Nov 2006 14:09:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLSM-0005IZ-OP for mip6@ietf.org; Wed, 01 Nov 2006 14:08:58 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLSC-0003Ip-Gl for mip6@ietf.org; Wed, 01 Nov 2006 14:08:58 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA1J8igk029668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 11:08:46 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.141.78]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA1J8ce9029654; Wed, 1 Nov 2006 11:08:44 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 11:08:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Wed, 1 Nov 2006 11:08:39 -0800 Message-ID: In-Reply-To: <4548E948.2040204@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb95SWhkkgu6VW7RnKRTucSOtYxxAAAQElw From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 01 Nov 2006 19:08:39.0561 (UTC) FILETIME=[23BFAF90:01C6FDE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org All, This is something I should've raised yesterday when I read all the emails, but after sleeping over it and some other discussions, I'm still confused - so, figured I should raise it now :) =20 First, I don't believe that an AltCoA option (v4 or v6) buys anything. Let's look at this.=20 In IPv4, the outer IP address is always up for modifications and there is no way to distinguish an adversary modifying it from a NAT modifying it. And, if the outer IPv4 source address is different from the inner IP address, there is no way for the HA to figure out whether the modification is due to a NAT or an adversary. Such is the truth with NATs and there is nothing that can be done about it. Even if the outer and inner IP addresses are the same, there is no way to figure out that they are the same because there is no NAT or because a NAT-ed IP address in the outer header has been modified back to equal the inner IP address by an adversary. This is quite feasible, especially when the inner packet is not encrypted and totally depends on the intention of the attacker.=20 The presence of the Alt-CoA option buys nothing exactly for the same reasons. The fact that the Alt-CoA option is integrity protected means nothing, since the HA still must use the outer IP address as the CoA - and there is no guarantee about that being intact.=20 We cannot pick and choose what attacks we like and what we don't. Either we protect against redirection attacks or we don't. At this point, I'm saying that integrity protection of the actual CoA alone proves nothing. Reachability checks have more value than integrity protection of a field that is allowed to be modified. Reachability checks too, in the absence of confidentiality on the inner packet, does not guarantee that an attacker is not on the path - but, it at least proves that the MN is reachable at that address.=20 So, my vote would be to perform an optional reachability check and document the vulnerability that may still exist.=20 Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 14:10:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLUA-0007r8-Ur; Wed, 01 Nov 2006 14:10:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLU9-0007pr-Au for mip6@ietf.org; Wed, 01 Nov 2006 14:10:49 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLTv-0003nZ-CD for mip6@ietf.org; Wed, 01 Nov 2006 14:10:49 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA1JAVPa029880 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 11:10:33 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.141.78]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA1J8cf9029654; Wed, 1 Nov 2006 11:10:30 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 11:10:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT Date: Wed, 1 Nov 2006 11:10:29 -0800 Message-ID: In-Reply-To: <4548ECFF.2040001@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT Thread-Index: Acb95x/repjOeq63TRuRkZmqp9FbZwAAgiZg From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 01 Nov 2006 19:10:29.0117 (UTC) FILETIME=[650C9AD0:01C6FDE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I was not assuming that the SPD entries and selectors for this would be the same as those for regular MIP6 - but, let's first discuss what we are protecting (see the email I just sent out with a subject change).=20 Vidya =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Wednesday, November 01, 2006 10:53 AM > To: Narayanan, Vidya > Cc: Soliman, Hesham; mip6@ietf.org; Pascal Thubert (pthubert) > Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not=20 > be usedwhen traversingIPv4 NAT >=20 > Narayanan, Vidya wrote: > > I > > don't think there is a problem. We can talk in SD to make=20 > sure there=20 > > isn't an issue here. >=20 > I missed replying to the above part. :) >=20 > you can't change the source address in the inner header when=20 > a tunnel mode IPsec SA is used without invalidating the IPsec=20 > SA. so you always need the home address to appear as the=20 > source address on the inner header. >=20 > from draft-ietf-mip6-ikev2-ipsec-07.txt >=20 > > o The mobile node and the home agent MUST create security > > associations based on the home address, so that the security > > associations survive change in care-of address. When=20 > using IKEv2 > > as the key exchange protocol, the home address should=20 > be carried > > as the initiator IP address in the TSi payload during the > > CREATE_CHILD_SA exchange [4]. >=20 > for a tunnel mode SA, this means the source address on the=20 > inner IP header must be the home address. >=20 > from RFC 3776 >=20 > > mobile node SPD-S: > > - IF source =3D home_address_1 & destination =3D any & > > proto =3D MH & local_mh_type =3D HoTi & > > remote_mh_type =3D HoT > > Then use SA ESP tunnel mode > > IDi =3D user_1, IDr =3D home_agent_1, > > TSi =3D home_address_1, MH, HoTi > > TSr =3D any, MH, HoT > > outer src addr =3D care_of_address_1, > > outer dst addr =3D home_agent_1, > > inner src addr =3D home_address_1 >=20 > note the "home_address_1 in the TSi when creating a tunnel SA. >=20 > Vijay >=20 > >=20 > > Vidya > >=20 > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >> Sent: Wednesday, November 01, 2006 7:31 AM > >> To: Narayanan, Vidya > >> Cc: Soliman, Hesham; mip6@ietf.org; Pascal Thubert (pthubert) > >> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be=20 > >> usedwhen traversingIPv4 NAT > >> > >> when you create an IPsec SA in tunnel mode, the source=20 > address on the=20 > >> inner header becomes a traffic selector (goes in the TSi as the=20 > >> address). > >> it shouldn't be the v4-mapped-v6 address. it has to be the v6 home=20 > >> address. > >> > >> Vijay > >> > >> Narayanan, Vidya wrote: > >>> I don't understand something here. Why would ESP tunnel mode not=20 > >>> provide the needed protection? Given that we already have two IP=20 > >>> headers in this case, it isn't even adding any overhead. I > >> can't see > >>> why we need anything else. > >>> > >>> I can understand not wanting to impose AH, but I don't see > >> ESP tunnel > >>> mode as a restriction at all. > >>> > >>> So, the headers would simply be: > >>> > >>> IPv4 HDR (src=3Dnatted-v4, dst=3DHA-addr) > >>> UDP > >>> ESP > >>> IPv6 HDR (src=3Dv4-mapped-v6, dst=3DHA-addr) > >>> DST-OPT > >>> MH (BU) > >>> > >>> > >>> What's the problem with that?=20 > >>> > >>> Vidya > >>> > >>> > >>>> -----Original Message----- > >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > >>>> Sent: Tuesday, October 31, 2006 8:00 PM > >>>> To: Soliman, Hesham > >>>> Cc: Narayanan, Vidya; mip6@ietf.org; Pascal Thubert (pthubert) > >>>> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be=20 > >>>> usedwhen traversingIPv4 NAT > >>>> > >>>> Soliman, Hesham wrote: > >>>>> > well, if there is a NAT on the path the source > > >> address on the > >>>>> outer IPv4 header is modified. > >>>>> > anytime a packet goes through a NAT, we have > this > >>>> problem. this > >>>>> is a common problem. so I > don't think we should design a > >>>> DS-MIPv6 > >>>>>> specific mechanism to protect an address that > is > >>>> modified by the > >>>>> NAT. its not worth it. > >>>>> > >>>>> =3D> You keep repeating that and I keep answering as follows:=20 > >>>> If there > >>>>> is an alt-coa in the packet then the HA has no way of > >>>> knowing if there > >>>>> was a NAT or not without checking it first, it can't > >> simply compare > >>>>> the outer headers... > >>>> I actually agree with this. :) > >>>> > >>>> Again, this has nothing to do with the presence of the > >>>>> NAT and everything to do with the presence of the alt-CoA... > >>>>> > >>>>> So it makes zero sense to say that the "HA should ignore > >>>> the alt-coa > >>>>> if a NAT were detected" because the HA can't possibly know > >>>> that a NAT > >>>>> was en route without inspecting the alt-coa.... > >>>> hmmm... there is a misunderstanding. I didn't say ignore > >> the alt-CoA > >>>> option. I said the HA should not use the contents of the altCoA=20 > >>>> option as the CoA when it detects a NAT. > >>>> > >>>> it does not matter if the HA compares the source address > >> on the outer > >>>> IPv4 header with the source address of the inner header or the=20 > >>>> contents of the altCoA option to detect the presence of=20 > a NAT. its=20 > >>>> the same for me. > >>>> > >>>> Vijay > >>>> > >> >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 14:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLeM-0000xR-Vp; Wed, 01 Nov 2006 14:21:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLeL-0000ww-Cz for mip6@ietf.org; Wed, 01 Nov 2006 14:21:21 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLeG-0006c0-Qh for mip6@ietf.org; Wed, 01 Nov 2006 14:21:21 -0500 Received: from [10.1.201.12] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 11:21:16 -0800 Message-ID: <4548F3AB.5040208@azairenet.com> Date: Wed, 01 Nov 2006 11:21:15 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 19:21:16.0117 (UTC) FILETIME=[E6B0F850:01C6FDEA] X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Narayanan, Vidya wrote: > I was not assuming that the SPD entries and selectors for this would be > the same as those for regular MIP6 the restriction comes from RFC 4301. we are not planning to remove that in DS-MIPv6. Vijay - but, let's first discuss what we > are protecting (see the email I just sent out with a subject change). > > Vidya > > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Wednesday, November 01, 2006 10:53 AM >> To: Narayanan, Vidya >> Cc: Soliman, Hesham; mip6@ietf.org; Pascal Thubert (pthubert) >> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not >> be usedwhen traversingIPv4 NAT >> >> Narayanan, Vidya wrote: >>> I >>> don't think there is a problem. We can talk in SD to make >> sure there >>> isn't an issue here. >> I missed replying to the above part. :) >> >> you can't change the source address in the inner header when >> a tunnel mode IPsec SA is used without invalidating the IPsec >> SA. so you always need the home address to appear as the >> source address on the inner header. >> >> from draft-ietf-mip6-ikev2-ipsec-07.txt >> >>> o The mobile node and the home agent MUST create security >>> associations based on the home address, so that the security >>> associations survive change in care-of address. When >> using IKEv2 >>> as the key exchange protocol, the home address should >> be carried >>> as the initiator IP address in the TSi payload during the >>> CREATE_CHILD_SA exchange [4]. >> for a tunnel mode SA, this means the source address on the >> inner IP header must be the home address. >> >> from RFC 3776 >> >>> mobile node SPD-S: >>> - IF source = home_address_1 & destination = any & >>> proto = MH & local_mh_type = HoTi & >>> remote_mh_type = HoT >>> Then use SA ESP tunnel mode >>> IDi = user_1, IDr = home_agent_1, >>> TSi = home_address_1, MH, HoTi >>> TSr = any, MH, HoT >>> outer src addr = care_of_address_1, >>> outer dst addr = home_agent_1, >>> inner src addr = home_address_1 >> note the "home_address_1 in the TSi when creating a tunnel SA. >> >> Vijay >> >>> Vidya >>> >>>> -----Original Message----- >>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>> Sent: Wednesday, November 01, 2006 7:31 AM >>>> To: Narayanan, Vidya >>>> Cc: Soliman, Hesham; mip6@ietf.org; Pascal Thubert (pthubert) >>>> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be >>>> usedwhen traversingIPv4 NAT >>>> >>>> when you create an IPsec SA in tunnel mode, the source >> address on the >>>> inner header becomes a traffic selector (goes in the TSi as the >>>> address). >>>> it shouldn't be the v4-mapped-v6 address. it has to be the v6 home >>>> address. >>>> >>>> Vijay >>>> >>>> Narayanan, Vidya wrote: >>>>> I don't understand something here. Why would ESP tunnel mode not >>>>> provide the needed protection? Given that we already have two IP >>>>> headers in this case, it isn't even adding any overhead. I >>>> can't see >>>>> why we need anything else. >>>>> >>>>> I can understand not wanting to impose AH, but I don't see >>>> ESP tunnel >>>>> mode as a restriction at all. >>>>> >>>>> So, the headers would simply be: >>>>> >>>>> IPv4 HDR (src=natted-v4, dst=HA-addr) >>>>> UDP >>>>> ESP >>>>> IPv6 HDR (src=v4-mapped-v6, dst=HA-addr) >>>>> DST-OPT >>>>> MH (BU) >>>>> >>>>> >>>>> What's the problem with that? >>>>> >>>>> Vidya >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >>>>>> Sent: Tuesday, October 31, 2006 8:00 PM >>>>>> To: Soliman, Hesham >>>>>> Cc: Narayanan, Vidya; mip6@ietf.org; Pascal Thubert (pthubert) >>>>>> Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be >>>>>> usedwhen traversingIPv4 NAT >>>>>> >>>>>> Soliman, Hesham wrote: >>>>>>> > well, if there is a NAT on the path the source > >>>> address on the >>>>>>> outer IPv4 header is modified. >>>>>>> > anytime a packet goes through a NAT, we have > this >>>>>> problem. this >>>>>>> is a common problem. so I > don't think we should design a >>>>>> DS-MIPv6 >>>>>>>> specific mechanism to protect an address that > is >>>>>> modified by the >>>>>>> NAT. its not worth it. >>>>>>> >>>>>>> => You keep repeating that and I keep answering as follows: >>>>>> If there >>>>>>> is an alt-coa in the packet then the HA has no way of >>>>>> knowing if there >>>>>>> was a NAT or not without checking it first, it can't >>>> simply compare >>>>>>> the outer headers... >>>>>> I actually agree with this. :) >>>>>> >>>>>> Again, this has nothing to do with the presence of the >>>>>>> NAT and everything to do with the presence of the alt-CoA... >>>>>>> >>>>>>> So it makes zero sense to say that the "HA should ignore >>>>>> the alt-coa >>>>>>> if a NAT were detected" because the HA can't possibly know >>>>>> that a NAT >>>>>>> was en route without inspecting the alt-coa.... >>>>>> hmmm... there is a misunderstanding. I didn't say ignore >>>> the alt-CoA >>>>>> option. I said the HA should not use the contents of the altCoA >>>>>> option as the CoA when it detects a NAT. >>>>>> >>>>>> it does not matter if the HA compares the source address >>>> on the outer >>>>>> IPv4 header with the source address of the inner header or the >>>>>> contents of the altCoA option to detect the presence of >> a NAT. its >>>>>> the same for me. >>>>>> >>>>>> Vijay >>>>>> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 14:30:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLmo-0006KU-9r; Wed, 01 Nov 2006 14:30:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfLmn-0006KP-Dj for mip6@ietf.org; Wed, 01 Nov 2006 14:30:05 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfLmg-0008Ko-31 for mip6@ietf.org; Wed, 01 Nov 2006 14:30:05 -0500 Received: from [10.1.201.12] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 11:29:57 -0800 Message-ID: <4548F5B5.4070000@azairenet.com> Date: Wed, 01 Nov 2006 11:29:57 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 19:29:57.0586 (UTC) FILETIME=[1D82D320:01C6FDEC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: mip6@ietf.org, "Soliman, Hesham" Subject: [Mip6] Re: What are we protecting over IPv4 in DS-MIP6? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Narayanan, Vidya wrote: > We cannot pick and choose what attacks we like and what we don't. Either > we protect against redirection attacks or we don't. At this point, I'm > saying that integrity protection of the actual CoA alone proves nothing. > Reachability checks have more value than integrity protection of a field > that is allowed to be modified. Reachability checks too, in the absence > of confidentiality on the inner packet, does not guarantee that an > attacker is not on the path - but, it at least proves that the MN is > reachable at that address. > > So, my vote would be to perform an optional reachability check and > document the vulnerability that may still exist. so your solution is to perform a return routability check on the IPv4 CoA. this is certainly a good solution. it has been suggested many times in the past to add a return routability check for the CoA for MIPv6 in general to prevent re-direction attacks, i.e., a legitimate mobile node uses someone else's CoA. but there was no consensus to add that. two points to note here 1. we add a round trip between the BU and BAck. the WG as to decide if that is worth adding to the DS-MIPv6 spec. 2. the exchange of BU/BAck is preceded by an IKEv2 exchange between the MN and the HA. since IKEv2 involves multiple round trips and the fact that the IKE SA is based on the IPv4 CoA, we get some protection already. please consider these two points. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 15:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMUs-0002jf-05; Wed, 01 Nov 2006 15:15:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfMUq-0002ja-Q7 for mip6@ietf.org; Wed, 01 Nov 2006 15:15:36 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfMUn-0000Ni-BL for mip6@ietf.org; Wed, 01 Nov 2006 15:15:36 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA1KFU4I005027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 12:15:31 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.na.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA1KFT1F024748; Wed, 1 Nov 2006 12:15:30 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 12:15:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Nov 2006 12:15:28 -0800 Message-ID: In-Reply-To: <4548F5B5.4070000@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? Thread-Index: Acb97Cag/5CjgBJTRVmzWXby8nRBeAAA9p+Q From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 01 Nov 2006 20:15:30.0084 (UTC) FILETIME=[7A34EE40:01C6FDF2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip6@ietf.org, "Soliman, Hesham" Subject: [Mip6] RE: What are we protecting over IPv4 in DS-MIP6? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > >=20 > > So, my vote would be to perform an optional reachability check and=20 > > document the vulnerability that may still exist. >=20 > so your solution is to perform a return routability check on=20 > the IPv4 CoA. this is certainly a good solution. it has been=20 > suggested many times in the past to add a return routability=20 > check for the CoA for MIPv6 in general to prevent=20 > re-direction attacks, i.e., a legitimate mobile node uses=20 > someone else's CoA. >=20 This is completely different from the case at hand. When an MN that legitimately owns the claimed HoA (let's differentiate this from a *legitimate* MN that would behave properly) uses someone else's IP address (it doesn't have to be CoA) as it's CoA, the result is a *DDoS attack* on the owner of that address. Clearly, here, the MN is acting as an attacker. And, given that there are other ways to launch DDoS attacks on a victim and that such an attack is traceable to the MN via checks at the HA, based on administrative channels, this is not worth protecting against.=20 The case at hand is one that results in a *redirection attack* on a legitimate MN. It is equivalent to an attacker claiming the MN'S HoA at the HA. The MN is the victim here, as opposed to the attacker in the previous case. This is a very different case and is a cause for conern, especially because, this is not detectable at the HA even by administrative channels and the MN is being denied service. This is because, the attacker is on-path and using a valid integrity protected packet from the MN and making an allowable modification to the packet to realize this attack.=20 Hence, the case at hand is worth protecting against. Note that this is unique to the IPv4 tunneled case alone. Such an attack is not feasible with regular MIP6 (oh, assuming that v6 deployments won't use NATs, but then, NATs are a religion and one never knows what an admin may be thinking :)).=20 > but there was no consensus to add that. >=20 > two points to note here >=20 > 1. we add a round trip between the BU and BAck. the WG as to=20 > decide if that is worth adding to the > DS-MIPv6 spec. Hence, it should be a SHOULD and not a MUST. Implementations that don't do this stand to be more vulnerable and if they are certain about not having on-path attackers in their networks, that's their choice.=20 > 2. the exchange of BU/BAck is preceded by an IKEv2 exchange=20 > between the MN and the HA. since IKEv2 involves multiple=20 > round trips and the fact that the IKE SA is based on the IPv4=20 > CoA, we get some protection already. >=20 Not really. Especially given that the IKE SA can be pointed to the new CoA as the CoA changes, this doesn't buy anything AFAICT.=20 So, I still maintain my vote on optional reachability checks :)=20 Vidya > please consider these two points. >=20 > Vijay >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 17:33:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOdA-0005CA-J8; Wed, 01 Nov 2006 17:32:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfOd9-0005C3-0D for mip6@ietf.org; Wed, 01 Nov 2006 17:32:19 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GfOd7-00026u-K5 for mip6@ietf.org; Wed, 01 Nov 2006 17:32:18 -0500 Received: (qmail invoked by alias); 01 Nov 2006 22:32:16 -0000 Received: from p54985D2A.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.93.42] by mail.gmx.net (mp045) with SMTP; 01 Nov 2006 23:32:16 +0100 X-Authenticated: #29516787 Message-ID: <4549206E.4060601@gmx.net> Date: Wed, 01 Nov 2006 23:32:14 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Mip6] Comments for draft-ietf-mip6-aaa-ha-goals-03 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, I went through the draft-ietf-mip6-aaa-ha-goals-03 document. The document only needs some minor corrections. Terminology section: You might want to say: " In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1], with the qualification that unless otherwise stated these words apply to the design of the AAA protocol extension, not its implementation or its usage. " The requirements should then be phrased in such a way that they refer to the design of the protocol rather its usage. The following example shows what I mean: G5.1 The HA SHOULD be able to communicate to the AAAH server the Home Address allocated to the MN (e.g., for allowing the AAAH server to perform a DNS update on behalf of the MN). Here, I think the AAA protocol extension MUST allow Home Address to be communicated from the HA to the MN. It is, however, not necessary to use it. G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is authorized to autoconfigure its Home Address. The same here. The protocol must support a way to allow the AAAH to indicate whether autoconfigure the HoA. It obviously does not need to use it. The same is true for G2.2, G2.3, G5.1, G5.2, G6.2, and G6.3. Requirement G6.3 should use the terms AAAH and NAS instead of ASP/MSP/MSA. I am not sure whether you agree with me but see it in the following way: If I don't implement SHOULD and MAY requirements I don't think I can design an interoperable protocol. G2.1 The AAA-HA interface SHOULD allow the use of Network Access Identifier (NAI) to identify the user. Why "SHOULD" instead of "MUST"? What identifier would you like to use instead of a NAI? There are still some minor typos and editorial issues in the document. I will not describe them here. I would replace the term "interface" with "protocol" and "goals" with "requirements" to get the document more inline with other IETF requirements documents. Ciao Hannes _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 01 18:55:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPvE-000506-SX; Wed, 01 Nov 2006 18:55:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfPqI-000198-S8 for mip6@ietf.org; Wed, 01 Nov 2006 18:49:58 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfPoc-0006P8-EM for mip6@ietf.org; Wed, 01 Nov 2006 18:48:15 -0500 Received: from [192.168.77.23] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 15:48:13 -0800 Message-ID: <45493163.1010600@azairenet.com> Date: Wed, 01 Nov 2006 15:44:35 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2006 23:48:13.0773 (UTC) FILETIME=[31F54FD0:01C6FE10] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mip6@ietf.org, "Soliman, Hesham" Subject: [Mip6] Re: What are we protecting over IPv4 in DS-MIP6? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org ok. stepping back a bit, I will let the WG decide whether we want to add a return routability check for the IPv4 CoA. it will work of course. my preference would be not to add this since it adds a round trip, making it two round trips every time you send a BU. Vijay Narayanan, Vidya wrote: >>> So, my vote would be to perform an optional reachability check and >>> document the vulnerability that may still exist. >> so your solution is to perform a return routability check on >> the IPv4 CoA. this is certainly a good solution. it has been >> suggested many times in the past to add a return routability >> check for the CoA for MIPv6 in general to prevent >> re-direction attacks, i.e., a legitimate mobile node uses >> someone else's CoA. >> > > This is completely different from the case at hand. When an MN that > legitimately owns the claimed HoA (let's differentiate this from a > *legitimate* MN that would behave properly) uses someone else's IP > address (it doesn't have to be CoA) as it's CoA, the result is a *DDoS > attack* on the owner of that address. Clearly, here, the MN is acting as > an attacker. And, given that there are other ways to launch DDoS attacks > on a victim and that such an attack is traceable to the MN via checks at > the HA, based on administrative channels, this is not worth protecting > against. > > The case at hand is one that results in a *redirection attack* on a > legitimate MN. It is equivalent to an attacker claiming the MN'S HoA at > the HA. The MN is the victim here, as opposed to the attacker in the > previous case. This is a very different case and is a cause for conern, > especially because, this is not detectable at the HA even by > administrative channels and the MN is being denied service. This is > because, the attacker is on-path and using a valid integrity protected > packet from the MN and making an allowable modification to the packet to > realize this attack. > > Hence, the case at hand is worth protecting against. Note that this is > unique to the IPv4 tunneled case alone. Such an attack is not feasible > with regular MIP6 (oh, assuming that v6 deployments won't use NATs, but > then, NATs are a religion and one never knows what an admin may be > thinking :)). > >> but there was no consensus to add that. >> >> two points to note here >> >> 1. we add a round trip between the BU and BAck. the WG as to >> decide if that is worth adding to the >> DS-MIPv6 spec. > > Hence, it should be a SHOULD and not a MUST. Implementations that don't > do this stand to be more vulnerable and if they are certain about not > having on-path attackers in their networks, that's their choice. > >> 2. the exchange of BU/BAck is preceded by an IKEv2 exchange >> between the MN and the HA. since IKEv2 involves multiple >> round trips and the fact that the IKE SA is based on the IPv4 >> CoA, we get some protection already. >> > > Not really. Especially given that the IKE SA can be pointed to the new > CoA as the CoA changes, this doesn't buy anything AFAICT. > > So, I still maintain my vote on optional reachability checks :) > > Vidya > >> please consider these two points. >> >> Vijay >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 00:41:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVIS-00050W-Ef; Thu, 02 Nov 2006 00:39:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfVIQ-0004kw-Sq for mip6@ietf.org; Thu, 02 Nov 2006 00:39:22 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfVIP-0006wX-E8 for mip6@ietf.org; Thu, 02 Nov 2006 00:39:22 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA25dJBr025840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 1 Nov 2006 21:39:19 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA25dH43025496; Wed, 1 Nov 2006 21:39:18 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 21:39:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Nov 2006 21:39:11 -0800 Message-ID: In-Reply-To: <45493163.1010600@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? Thread-Index: Acb+E1e0PWYzwdbTTfmQcnJA+r7F0QAK7g7w From: "Narayanan, Vidya" To: "Vijay Devarapalli" X-OriginalArrivalTime: 02 Nov 2006 05:39:17.0097 (UTC) FILETIME=[3CAD7D90:01C6FE41] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: mip6@ietf.org, "Soliman, Hesham" Subject: [Mip6] RE: What are we protecting over IPv4 in DS-MIP6? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 > ok. stepping back a bit, I will let the WG decide whether we=20 > want to add a return routability check for the IPv4 CoA. it=20 > will work of course. >=20 > my preference would be not to add this since it adds a round=20 > trip, making it two round trips every time you send a BU. >=20 That is not the question. The question is whether it is important to protect against redirection attacks while traversing IPv4 networks. I believe it is. If not, it is somewhat akin to saying that we don't care about a malicious MN claiming an incorrect HoA and then, we might as well say that no address authorization is needed. Well, ok, that is a bit of exaggeration :) The latter can be realized by off-path attacks, while the IPv4 case is about on-path attacks.=20 I think that the vulnerability is not insignificant and needs protection. Once we agree on that, we can see how best to do the reachability checks and if there is a way to do it without always impacting handoff latency.=20 Vidya > Vijay >=20 > Narayanan, Vidya wrote: > >>> So, my vote would be to perform an optional reachability=20 > check and=20 > >>> document the vulnerability that may still exist. > >> so your solution is to perform a return routability check=20 > on the IPv4=20 > >> CoA. this is certainly a good solution. it has been suggested many=20 > >> times in the past to add a return routability check for=20 > the CoA for=20 > >> MIPv6 in general to prevent re-direction attacks, i.e., a=20 > legitimate=20 > >> mobile node uses someone else's CoA. > >> > >=20 > > This is completely different from the case at hand. When an MN that=20 > > legitimately owns the claimed HoA (let's differentiate this from a > > *legitimate* MN that would behave properly) uses someone else's IP=20 > > address (it doesn't have to be CoA) as it's CoA, the result=20 > is a *DDoS > > attack* on the owner of that address. Clearly, here, the MN=20 > is acting=20 > > as an attacker. And, given that there are other ways to launch DDoS=20 > > attacks on a victim and that such an attack is traceable to=20 > the MN via=20 > > checks at the HA, based on administrative channels, this is=20 > not worth=20 > > protecting against. > >=20 > > The case at hand is one that results in a *redirection attack* on a=20 > > legitimate MN. It is equivalent to an attacker claiming the=20 > MN'S HoA=20 > > at the HA. The MN is the victim here, as opposed to the attacker in=20 > > the previous case. This is a very different case and is a cause for=20 > > conern, especially because, this is not detectable at the=20 > HA even by=20 > > administrative channels and the MN is being denied service. This is=20 > > because, the attacker is on-path and using a valid=20 > integrity protected=20 > > packet from the MN and making an allowable modification to=20 > the packet=20 > > to realize this attack. > >=20 > > Hence, the case at hand is worth protecting against. Note=20 > that this is=20 > > unique to the IPv4 tunneled case alone. Such an attack is=20 > not feasible=20 > > with regular MIP6 (oh, assuming that v6 deployments won't use NATs,=20 > > but then, NATs are a religion and one never knows what an=20 > admin may be=20 > > thinking :)). > >=20 > >> but there was no consensus to add that. > >> > >> two points to note here > >> > >> 1. we add a round trip between the BU and BAck. the WG as=20 > to decide=20 > >> if that is worth adding to the > >> DS-MIPv6 spec. > >=20 > > Hence, it should be a SHOULD and not a MUST. Implementations that=20 > > don't do this stand to be more vulnerable and if they are certain=20 > > about not having on-path attackers in their networks,=20 > that's their choice. > >=20 > >> 2. the exchange of BU/BAck is preceded by an IKEv2=20 > exchange between=20 > >> the MN and the HA. since IKEv2 involves multiple round=20 > trips and the=20 > >> fact that the IKE SA is based on the IPv4 CoA, we get some=20 > protection=20 > >> already. > >> > >=20 > > Not really. Especially given that the IKE SA can be pointed=20 > to the new=20 > > CoA as the CoA changes, this doesn't buy anything AFAICT. > >=20 > > So, I still maintain my vote on optional reachability checks :) > >=20 > > Vidya > >=20 > >> please consider these two points. > >> > >> Vijay > >> >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 01:44:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfWIP-0006U5-0L; Thu, 02 Nov 2006 01:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfWIN-0006Sq-LY for mip6@ietf.org; Thu, 02 Nov 2006 01:43:23 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfWIL-0004ym-FJ for mip6@ietf.org; Thu, 02 Nov 2006 01:43:23 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA26hJ1o003395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 1 Nov 2006 22:43:20 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.na.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA26hIUl000481 for ; Wed, 1 Nov 2006 22:43:19 -0800 (PST) Received: from sanexcas01.na.qualcomm.com ([172.30.36.175]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 22:43:18 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 22:43:18 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be used whentraversingIPv4 NAT Date: Wed, 1 Nov 2006 22:43:14 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF40368D2@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] concensus: issue 76: Alt CoA should not be used whentraversingIPv4 NAT Thread-Index: AcbuKRTePQYFgB62S8u2UMKyCITDHgAaLNXAAABwFpABQRjqkAIq1qwgACpqkBAAVx8ygA== From: "Soliman, Hesham" To: X-OriginalArrivalTime: 02 Nov 2006 06:43:18.0650 (UTC) FILETIME=[2E6BF5A0:01C6FE4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, On the question I posted below, we got the following answer:=20 Yes: 5 No: 1 Other (Yes and No): 1. This was Ryuji's comment where he said he would go for "Yes" if integrity is ensured. We have concensus on removing the Alt-CoA and I will post a separate issue on the security aspect of this. Hopefully we can resolve the security issue during IETF week.=20 This issue is now closed. Thanks for your feedback. Hesham > -----Original Message----- > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com]=20 > Sent: Wednesday, November 01, 2006 12:11 AM > To: Pascal Thubert (pthubert); mip6@ietf.org > Subject: [Mip6] concensus: issue 76: Alt CoA should not be=20 > used whentraversingIPv4 NAT >=20 > Pascal, all,=20 >=20 > There's been a lot of emails on this issue so I think WG members are > fully informed now about what this issue involves. I will=20 > ask a simple > question and I'd like people to choose one of the options below. To > avoid any confusion I'm keeping the question simple and clear.=20 >=20 > Leaving the checksum option and integrity issue aside=20 > (because I know we > can fix it and I'm writing a separate issue for it) please=20 > let give me > an answer to the following question:=20 >=20 > Do you agree that the MN does not include the Alt-CoA option=20 > in the BU > when it is located in an IPv4-only network?=20 >=20 > 1. Yes > 2. No >=20 > Please include a brief reason for you answer, Pascal already did so I > don't expect another one :). As I said, ignore the checksum=20 > issue, this > will be handled separately. >=20 > FWIW, I choose 1) above because it's the only way to make=20 > sure that the > HA can detect the presence of a NAT by comparing the outer=20 > v4 addresses > with the IPv6 header.=20 >=20 > Hesham >=20 >=20 > > -----Original Message----- > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > > Sent: Tuesday, October 31, 2006 4:12 AM > > To: Soliman, Hesham; mip6@ietf.org > > Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used=20 > > when traversingIPv4 NAT > >=20 > > Hi Hesham: > >=20 > > I agree: > >=20 > > 1) with relaxing the requirement in RFC 3775 to include an Alt CoA > > option all the time. > >=20 > > 2) that the MN should omit it, as opposed to the HA=20 > filtering it out. > > The Alt CoA is the real address at which the MN is=20 > reachable, that is > > what HAs implement today, that is what all people in the art=20 > > understand. > > I want to stay simple and keep it that way. I'd hate to=20 > > have rules like > > "this is A but then if there is also that then this is B=20 > which is the > > opposite of A", etc... we are not lawyers!=20 > >=20 > > 3) that we have to find an alternate way to endure that the MN is > > reachable at the CoA, defined as the source of the packet=20 > when the HA > > gets it. > >=20 > > I'd also agree that: > >=20 > > 4) UDP is used all the time in IPv4 roaming situation,=20 > regardless on > > whether NAT is detected or not. That's not really in the=20 > > mail but since > > you fixed the message format in the thread to add UDP, I=20 > > take advantage > > of the exchange to raise that point again. > >=20 > > I disagree: > >=20 > > 5) to jump too quickly on the conclusion that the checksum=20 > > is the way to > > go. I understand that it has value in certain scenarios that you > > mention. But it fails to guarantee that the MN is reachable=20 > > at the CoA > > in another common case that is NAT; and it does not=20 > protect against a > > rogue DHCP server assigning you an IPv4 DoS'ed address,=20 > which could > > easily happen in the IPv4 world.=20 > >=20 > > So when you call for consensus, please leave open the=20 > > solution to 3) so > > we can see if there's a preferable alternative. I, for one,=20 > > would favor > > an approach like 2 BU flows in row, which would emulate a 3 way > > handshake and guarantee the reachability of the MN in all cases.=20 > >=20 > > Pascal > >=20 > >=20 > >=20 > >=20 > > >-----Original Message----- > > >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > > >Sent: Thursday, October 19, 2006 6:19 PM > > >To: mip6@ietf.org > > >Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used when > > traversingIPv4 NAT > > > > > >Folks, > > > > > >This issue was revived mainly due to Vijay points on the=20 > > need for the > > >checksum option when the alt-CoA is not used. Let me=20 > summarise the > > >issues first then propose a way forward. > > > > > >Summary: > > >-------- > > > > > >The initial resolution for the issue suggested that we add=20 > > a checksum > > >option that includes a checksum on the src and dst=20 > addresses in the > > IPv6 > > >header. This was suggested to be used when the alt-coa is=20 > > not present > > to > > >maintain the integrity of the src address when ESP is used.=20 > > I want to > > >emphasise that this is only needed when ESP is used, not with AH. > > > > > >Now the point that Vijay raised is also quite valid: With NAT > > traversal, > > >the outer IPv4 header is vulnerable, yet it is needed=20 > because the HA > > >responds to that address and sets up the UDP tunnel to the outer > > >(natted) IPv4 src address in the packet containing the BU.=20 > > There is no > > >way we can secure that address, yet, it essentially acts=20 > as another > > >binding, which if modified maliciously, would redirect the=20 > > MN's packets > > >to another IPv4 address. To be clear, here is the packet format: > > >BU packet received by HA after passing through NAT: > > > IPv4 HDR (src=3Dnatted-v4, dst=3DHA-addr) > > > UDP > > > IPv6 HDR (src=3Dv4-mapped-v6, dst=3DHA-addr) > > > ESP > > > DST-OPT > > > MH (BU) > > > > > >The HA responds with a similar packet including the BA and=20 > > forwards all > > >future packets in the UDP tunnel, with the dst address=20 > in the IPv4 > > >header being the "natted-v4" address above. > > >So essentially protecting the BU does not protect the MN from > > >redirection attacks in this case because the IPv4 header is=20 > > vulnerable. > > >This is an inherent problem with NAT traversal. There is=20 > practically > > >nothing we can do about it. > > > > > >So the remaining question is: Is it worth worrying about=20 > > the integrity > > >of the BU in this case? IMHO I think the answer is yes.=20 > > Why? Two main > > >reasons: > > > > > >1. There can be cases where the BU is sent to a local HA and the > > >operator can guarantee that no NATs are in the path. In=20 > this case we > > >would lose integrity for no reason, i.e. the BU becomes=20 > the weakest > > >link. This is not unusual really because an operator may=20 > > decide that it > > >will only provide the HA function within its domain, which=20 > > happens to > > >not include NATs between the MN and the HA. > > > > > >2. We have precedence with MIPv4 and NAT traversal where=20 > the RREQ is > > >still secure despite the UNSAF NAT traversal. > > > > > >Note that the answer to 1) above may be "Use AH", but I=20 > > prefer to not > > >force that on implementations that do not do it today=20 > > (although I would > > >personally prefer AH in general for the BU). > > > > > >For these reasons, and there may be more, I prefer to not=20 > > take this big > > >decision to lose the integrity for the BU. > > > > > >Way forward: > > >------------ > > > > > >This issue is now closed, we all agree on it, but there may be > > >disagreement on the checksum part. So I suggest that I=20 > > generate a new > > >issue for this discussion. Until the new issue is resolved,=20 > > I won't add > > >the checksum option to the draft. > > > > > >Feel free to send comments. > > > > > >Hesham > > > > > >_______________________________________________ > > >Mip6 mailing list > > >Mip6@ietf.org > > >https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 02:10:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfWiE-00023w-Bs; Thu, 02 Nov 2006 02:10:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfWiD-00023r-Hb for mip6@ietf.org; Thu, 02 Nov 2006 02:10:05 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfWiC-0001CA-T2 for mip6@ietf.org; Thu, 02 Nov 2006 02:10:05 -0500 Received: from [10.1.210.4] ([10.1.210.4]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Nov 2006 23:09:59 -0800 Message-ID: <454999BA.8060208@azairenet.com> Date: Wed, 01 Nov 2006 23:09:46 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [Mip6] concensus: issue 76: Alt CoA should not be used whentraversingIPv4 NAT References: <2309978910A6A6478C2C7585692B0AF40368D2@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF40368D2@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2006 07:09:59.0748 (UTC) FILETIME=[E8C02040:01C6FE4D] X-Spam-Score: 0.1 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org thats funny. we had a 40 hour consensus call on the "YES" and "NO" options. :) anyway, I think this is a wrong decision. we would need to re-visit this if the new solution to provide integrity protection for the IPv4 CoA is too complicated or not worth the tradeoff. Vijay Soliman, Hesham wrote: > Hi all, > > On the question I posted below, we got the following answer: > > Yes: 5 > No: 1 > > Other (Yes and No): 1. This was Ryuji's comment where he said he would > go for "Yes" if integrity is ensured. > > We have concensus on removing the Alt-CoA and I will post a separate > issue on the security aspect of this. Hopefully we can resolve the > security issue during IETF week. > > This issue is now closed. Thanks for your feedback. > > Hesham > > > -----Original Message----- > > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > > Sent: Wednesday, November 01, 2006 12:11 AM > > To: Pascal Thubert (pthubert); mip6@ietf.org > > Subject: [Mip6] concensus: issue 76: Alt CoA should not be > > used whentraversingIPv4 NAT > > > > Pascal, all, > > > > There's been a lot of emails on this issue so I think WG members are > > fully informed now about what this issue involves. I will > > ask a simple > > question and I'd like people to choose one of the options below. To > > avoid any confusion I'm keeping the question simple and clear. > > > > Leaving the checksum option and integrity issue aside > > (because I know we > > can fix it and I'm writing a separate issue for it) please > > let give me > > an answer to the following question: > > > > Do you agree that the MN does not include the Alt-CoA option > > in the BU > > when it is located in an IPv4-only network? > > > > 1. Yes > > 2. No > > > > Please include a brief reason for you answer, Pascal already did so I > > don't expect another one :). As I said, ignore the checksum > > issue, this > > will be handled separately. > > > > FWIW, I choose 1) above because it's the only way to make > > sure that the > > HA can detect the presence of a NAT by comparing the outer > > v4 addresses > > with the IPv6 header. > > > > Hesham > > > > > > > -----Original Message----- > > > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] > > > Sent: Tuesday, October 31, 2006 4:12 AM > > > To: Soliman, Hesham; mip6@ietf.org > > > Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used > > > when traversingIPv4 NAT > > > > > > Hi Hesham: > > > > > > I agree: > > > > > > 1) with relaxing the requirement in RFC 3775 to include an Alt CoA > > > option all the time. > > > > > > 2) that the MN should omit it, as opposed to the HA > > filtering it out. > > > The Alt CoA is the real address at which the MN is > > reachable, that is > > > what HAs implement today, that is what all people in the art > > > understand. > > > I want to stay simple and keep it that way. I'd hate to > > > have rules like > > > "this is A but then if there is also that then this is B > > which is the > > > opposite of A", etc... we are not lawyers! > > > > > > 3) that we have to find an alternate way to endure that the MN is > > > reachable at the CoA, defined as the source of the packet > > when the HA > > > gets it. > > > > > > I'd also agree that: > > > > > > 4) UDP is used all the time in IPv4 roaming situation, > > regardless on > > > whether NAT is detected or not. That's not really in the > > > mail but since > > > you fixed the message format in the thread to add UDP, I > > > take advantage > > > of the exchange to raise that point again. > > > > > > I disagree: > > > > > > 5) to jump too quickly on the conclusion that the checksum > > > is the way to > > > go. I understand that it has value in certain scenarios that you > > > mention. But it fails to guarantee that the MN is reachable > > > at the CoA > > > in another common case that is NAT; and it does not > > protect against a > > > rogue DHCP server assigning you an IPv4 DoS'ed address, > > which could > > > easily happen in the IPv4 world. > > > > > > So when you call for consensus, please leave open the > > > solution to 3) so > > > we can see if there's a preferable alternative. I, for one, > > > would favor > > > an approach like 2 BU flows in row, which would emulate a 3 way > > > handshake and guarantee the reachability of the MN in all cases. > > > > > > Pascal > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > > > >Sent: Thursday, October 19, 2006 6:19 PM > > > >To: mip6@ietf.org > > > >Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used when > > > traversingIPv4 NAT > > > > > > > >Folks, > > > > > > > >This issue was revived mainly due to Vijay points on the > > > need for the > > > >checksum option when the alt-CoA is not used. Let me > > summarise the > > > >issues first then propose a way forward. > > > > > > > >Summary: > > > >-------- > > > > > > > >The initial resolution for the issue suggested that we add > > > a checksum > > > >option that includes a checksum on the src and dst > > addresses in the > > > IPv6 > > > >header. This was suggested to be used when the alt-coa is > > > not present > > > to > > > >maintain the integrity of the src address when ESP is used. > > > I want to > > > >emphasise that this is only needed when ESP is used, not with AH. > > > > > > > >Now the point that Vijay raised is also quite valid: With NAT > > > traversal, > > > >the outer IPv4 header is vulnerable, yet it is needed > > because the HA > > > >responds to that address and sets up the UDP tunnel to the outer > > > >(natted) IPv4 src address in the packet containing the BU. > > > There is no > > > >way we can secure that address, yet, it essentially acts > > as another > > > >binding, which if modified maliciously, would redirect the > > > MN's packets > > > >to another IPv4 address. To be clear, here is the packet format: > > > >BU packet received by HA after passing through NAT: > > > > IPv4 HDR (src=natted-v4, dst=HA-addr) > > > > UDP > > > > IPv6 HDR (src=v4-mapped-v6, dst=HA-addr) > > > > ESP > > > > DST-OPT > > > > MH (BU) > > > > > > > >The HA responds with a similar packet including the BA and > > > forwards all > > > >future packets in the UDP tunnel, with the dst address > > in the IPv4 > > > >header being the "natted-v4" address above. > > > >So essentially protecting the BU does not protect the MN from > > > >redirection attacks in this case because the IPv4 header is > > > vulnerable. > > > >This is an inherent problem with NAT traversal. There is > > practically > > > >nothing we can do about it. > > > > > > > >So the remaining question is: Is it worth worrying about > > > the integrity > > > >of the BU in this case? IMHO I think the answer is yes. > > > Why? Two main > > > >reasons: > > > > > > > >1. There can be cases where the BU is sent to a local HA and the > > > >operator can guarantee that no NATs are in the path. In > > this case we > > > >would lose integrity for no reason, i.e. the BU becomes > > the weakest > > > >link. This is not unusual really because an operator may > > > decide that it > > > >will only provide the HA function within its domain, which > > > happens to > > > >not include NATs between the MN and the HA. > > > > > > > >2. We have precedence with MIPv4 and NAT traversal where > > the RREQ is > > > >still secure despite the UNSAF NAT traversal. > > > > > > > >Note that the answer to 1) above may be "Use AH", but I > > > prefer to not > > > >force that on implementations that do not do it today > > > (although I would > > > >personally prefer AH in general for the BU). > > > > > > > >For these reasons, and there may be more, I prefer to not > > > take this big > > > >decision to lose the integrity for the BU. > > > > > > > >Way forward: > > > >------------ > > > > > > > >This issue is now closed, we all agree on it, but there may be > > > >disagreement on the checksum part. So I suggest that I > > > generate a new > > > >issue for this discussion. Until the new issue is resolved, > > > I won't add > > > >the checksum option to the draft. > > > > > > > >Feel free to send comments. > > > > > > > >Hesham > > > > > > > >_______________________________________________ > > > >Mip6 mailing list > > > >Mip6@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 06:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfaaR-0007LU-Op; Thu, 02 Nov 2006 06:18:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfaaQ-0007LK-Ba for mip6@ietf.org; Thu, 02 Nov 2006 06:18:18 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfaaK-00048E-Si for mip6@ietf.org; Thu, 02 Nov 2006 06:18:18 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Nov 2006 12:17:39 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANhNSUWQ/uCKY2dsb2JhbACMQBQPKg X-IronPort-AV: i="4.09,380,1157320800"; d="scan'208"; a="117020089:sNHT5334968740" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2BHcst015297; Thu, 2 Nov 2006 12:17:38 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA2BHcmf024306; Thu, 2 Nov 2006 12:17:38 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 12:17:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhentraversingIPv4 NAT Date: Thu, 2 Nov 2006 12:17:01 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02EE84CB@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] concensus: issue 76: Alt CoA should not be usedwhentraversingIPv4 NAT Thread-Index: AcbuKRTePQYFgB62S8u2UMKyCITDHgAaLNXAAABwFpABQRjqkAIq1qwgACpqkBAAVx8ygAAIHlOA From: "Pascal Thubert \(pthubert\)" To: "Soliman, Hesham" , X-OriginalArrivalTime: 02 Nov 2006 11:17:12.0180 (UTC) FILETIME=[7191A340:01C6FE70] DKIM-Signature: a=rsa-sha1; q=dns; l=11242; t=1162466258; x=1163330258; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[Mip6]=20concensus=3A=20issue=2076=3A=20Alt=20CoA=20should=20not =20be=20usedwhentraversingIPv4=20NAT; X=v=3Dcisco.com=3B=20h=3DDut/vtJZYeggbkrrfzSElKPZypM=3D; b=aee5znKnqsq3WhaVDBnGXVgEwoRxckYQZHz95IPHXEjsbJ9x77PTQLnCZoHaTvM42U8g+72w XJ06CIesQkS6gUzVWPffkq7fWVsjYcz5wMFohN+fqt8yX30EwDwNyCOI; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham: Can't we can start the discussion right now on the list so that we are already advanced for the meeting? I'm afraid I will not attend IETF this time so I will not be able to defend the following proposal myself.=20 Proposal: --------- The proposal aims at checking whether the MN is actually reachable at the COA, regardless on whether the CoA is IPv6, IPv4 or IPv4/NAT, before accepting a BU. Another objective is to minimize the changes on existing protocols and implementations. 1) The proposed way of doing so is a new, optional 3-way handshake. This is achieved by ways of 2 Binding Update flows in a row. 2) The handshake is optional. The HA decides to use it whenever its policy requires. It is recommended to use it at least if the CoA in the Binding Update changes and if the alt COA option is not present, though it might also be used if the alt CoA option is present, for instance if the visited network is not trusted for owning its prefixes. 3) The HA signals to the MN that it wants to use the optional 3-way handshake by responding with a new "additional BU required" flag in the Binding Ack. The Binding Ack is sent to the new CoA, as found in the source of the BU packet or in the alt CoA field if present. The Binding Ack also contains Binding Refresh Advice with the Refresh Interval set to 0. (alternate, what about using a status code?). 4) The HA store that new CoA as "proposed" in the BCE but waits for an additional BU with a valid sequence counter to apply the updates associated to the BU.=20 5) Upon a Binding Ack with the new "additional BU required" flag, the MN updates its sequence counter and triggers a new BU immediately. 6) If the CoA in a valid BU matches the current CoA or the proposed CoA in the BCE, the HA applies the changes associated to the BU and responds as mandated by the protocol, without the "additional BU required" flag set. What do you think? =09 Pascal=20 =20 >-----Original Message----- >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com]=20 >Sent: Thursday, November 02, 2006 7:43 AM >To: mip6@ietf.org >Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be=20 >usedwhentraversingIPv4 NAT > >Hi all, > >On the question I posted below, we got the following answer:=20 > >Yes: 5 >No: 1 > >Other (Yes and No): 1. This was Ryuji's comment where he said=20 >he would go for "Yes" if integrity is ensured. > >We have concensus on removing the Alt-CoA and I will post a=20 >separate issue on the security aspect of this. Hopefully we=20 >can resolve the security issue during IETF week.=20 > >This issue is now closed. Thanks for your feedback. > >Hesham > > > -----Original Message----- > > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] >=20 >Sent: Wednesday, November 01, 2006 12:11 AM > To: Pascal=20 >Thubert (pthubert); mip6@ietf.org > Subject: [Mip6]=20 >concensus: issue 76: Alt CoA should not be > used=20 >whentraversingIPv4 NAT > > Pascal, all, > > There's been a=20 >lot of emails on this issue so I think WG members are > fully=20 >informed now about what this issue involves. I will > ask a=20 >simple > question and I'd like people to choose one of the=20 >options below. To > avoid any confusion I'm keeping the=20 >question simple and clear.=20 > > > > Leaving the checksum option and integrity issue aside >=20 >(because I know we > can fix it and I'm writing a separate=20 >issue for it) please > let give me > an answer to the=20 >following question:=20 > > > > Do you agree that the MN does not include the Alt-CoA=20 >option > in the BU > when it is located in an IPv4-only network?=20 > > > > 1. Yes > > 2. No > > > > Please include a brief reason for you answer, Pascal=20 >already did so I > don't expect another one :). As I said,=20 >ignore the checksum > issue, this > will be handled separately. > > > > FWIW, I choose 1) above because it's the only way to make =20 >> sure that the > HA can detect the presence of a NAT by=20 >comparing the outer > v4 addresses > with the IPv6 header.=20 > > > > Hesham > > > > > > > -----Original Message----- > > > From: Pascal Thubert (pthubert)=20 >[mailto:pthubert@cisco.com] > > Sent: Tuesday, October 31,=20 >2006 4:12 AM > > To: Soliman, Hesham; mip6@ietf.org > >=20 >Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used =20 >> > when traversingIPv4 NAT > > > > Hi Hesham: > > > > > > I agree: > > > > > > 1) with relaxing the requirement in RFC 3775 to include=20 >an Alt CoA > > option all the time. > > > > > > 2) that the MN should omit it, as opposed to the HA >=20 >filtering it out. > > > The Alt CoA is the real address at which the MN is >=20 >reachable, that is > > what HAs implement today, that is=20 >what all people in the art > > understand. > > > I want to stay simple and keep it that way. I'd hate to=20 > > > have rules like > > "this is A but then if there is=20 >also that then this is B > which is the > > opposite of A",=20 >etc... we are not lawyers!=20 > > > > > > 3) that we have to find an alternate way to endure that=20 >the MN is > > reachable at the CoA, defined as the source of=20 >the packet > when the HA > > gets it. > > > > > > I'd also agree that: > > > > > > 4) UDP is used all the time in IPv4 roaming situation, =20 >> regardless on > > whether NAT is detected or not. That's=20 >not really in the > > mail but since > > you fixed the=20 >message format in the thread to add UDP, I > > take=20 >advantage > > of the exchange to raise that point again. > > > > > > I disagree: > > > > > > 5) to jump too quickly on the conclusion that the=20 >checksum > > is the way to > > go. I understand that it=20 >has value in certain scenarios that you > > mention. But it=20 >fails to guarantee that the MN is reachable > > at the CoA =20 >> > in another common case that is NAT; and it does not >=20 >protect against a > > rogue DHCP server assigning you an=20 >IPv4 DoS'ed address, > which could > > easily happen in the=20 >IPv4 world.=20 > > > > > > So when you call for consensus, please leave open the >=20 > > solution to 3) so > > we can see if there's a preferable=20 >alternative. I, for one, > > would favor > > an approach=20 >like 2 BU flows in row, which would emulate a 3 way > >=20 >handshake and guarantee the reachability of the MN in all cases.=20 > > > > > > Pascal > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] >=20 > > >Sent: Thursday, October 19, 2006 6:19 PM > > >To:=20 >mip6@ietf.org > > >Subject: RE: [Mip6] RE: issue 76: Alt CoA=20 >should not be used when > > traversingIPv4 NAT > > > > >=20 >>Folks, > > > > > >This issue was revived mainly due to=20 >Vijay points on the > > need for the > > >checksum option=20 >when the alt-CoA is not used. Let me > summarise the > >=20 >>issues first then propose a way forward. > > > > > > > >Summary: > > > >-------- > > > > > > > >The initial resolution for the issue suggested that we=20 >add > > a checksum > > >option that includes a checksum on=20 >the src and dst > addresses in the > > IPv6 > > >header.=20 >This was suggested to be used when the alt-coa is > > not=20 >present > > to > > >maintain the integrity of the src=20 >address when ESP is used.=20 > > > I want to > > > >emphasise that this is only needed when ESP is used,=20 >not with AH. > > > > > > > >Now the point that Vijay raised is also quite valid:=20 >With NAT > > traversal, > > >the outer IPv4 header is=20 >vulnerable, yet it is needed > because the HA > > >responds=20 >to that address and sets up the UDP tunnel to the outer > >=20 >>(natted) IPv4 src address in the packet containing the BU.=20 > > > There is no > > > >way we can secure that address, yet, it essentially=20 >acts > as another > > >binding, which if modified=20 >maliciously, would redirect the > > MN's packets > > >to=20 >another IPv4 address. To be clear, here is the packet format: > > > >BU packet received by HA after passing through NAT: > > > > IPv4 HDR (src=3Dnatted-v4, dst=3DHA-addr) > > > > UDP > > > > IPv6 HDR (src=3Dv4-mapped-v6, dst=3DHA-addr) > > > > ESP > > > > DST-OPT > > > > MH (BU) > > > > > > > >The HA responds with a similar packet including the BA=20 >and > > forwards all > > >future packets in the UDP=20 >tunnel, with the dst address > in the IPv4 > > >header=20 >being the "natted-v4" address above. > > > >So essentially protecting the BU does not protect the=20 >MN from > > >redirection attacks in this case because the=20 >IPv4 header is > > vulnerable. > > > >This is an inherent problem with NAT traversal. There=20 >is > practically > > >nothing we can do about it. > > > > > > > >So the remaining question is: Is it worth worrying=20 >about > > the integrity > > >of the BU in this case? IMHO=20 >I think the answer is yes.=20 > > > Why? Two main > > > >reasons: > > > > > > > >1. There can be cases where the BU is sent to a local=20 >HA and the > > >operator can guarantee that no NATs are in=20 >the path. In > this case we > > >would lose integrity for=20 >no reason, i.e. the BU becomes > the weakest > > >link.=20 >This is not unusual really because an operator may > >=20 >decide that it > > >will only provide the HA function within=20 >its domain, which > > happens to > > >not include NATs=20 >between the MN and the HA. > > > > > > > >2. We have precedence with MIPv4 and NAT traversal=20 >where > the RREQ is > > >still secure despite the UNSAF NAT=20 >traversal. > > > > > > > >Note that the answer to 1) above may be "Use AH", but I=20 > > > prefer to not > > >force that on implementations that=20 >do not do it today > > (although I would > > >personally=20 >prefer AH in general for the BU). > > > > > > > >For these reasons, and there may be more, I prefer to=20 >not > > take this big > > >decision to lose the integrity=20 >for the BU. > > > > > > > >Way forward: > > > >------------ > > > > > > > >This issue is now closed, we all agree on it, but there=20 >may be > > >disagreement on the checksum part. So I suggest=20 >that I > > generate a new > > >issue for this discussion.=20 >Until the new issue is resolved, > > I won't add > > >the=20 >checksum option to the draft. > > > > > > > >Feel free to send comments. > > > > > > > >Hesham > > > > > > > >_______________________________________________ > > > >Mip6 mailing list > > > >Mip6@ietf.org > > > >https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 06:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfacU-0008BK-B8; Thu, 02 Nov 2006 06:20:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfacT-00087r-7x for mip6@ietf.org; Thu, 02 Nov 2006 06:20:25 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfacR-0004RM-6v for mip6@ietf.org; Thu, 02 Nov 2006 06:20:25 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA2BKLAi022238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Nov 2006 03:20:22 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.na.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA2BKK1E003651; Thu, 2 Nov 2006 03:20:21 -0800 (PST) Received: from sanexcas01.na.qualcomm.com ([172.30.36.175]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 03:20:20 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 03:20:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhentraversingIPv4 NAT Date: Thu, 2 Nov 2006 03:20:13 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF40368E0@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] concensus: issue 76: Alt CoA should not be usedwhentraversingIPv4 NAT Thread-Index: AcbuKRTePQYFgB62S8u2UMKyCITDHgAaLNXAAABwFpABQRjqkAIq1qwgACpqkBAAVx8ygAAIHlOAAAGzLkA= From: "Soliman, Hesham" To: "Pascal Thubert \(pthubert\)" , X-OriginalArrivalTime: 02 Nov 2006 11:20:20.0196 (UTC) FILETIME=[E1A29A40:01C6FE70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Pascal,=20 Of course the discussions and concensus will happen on the list, but it's unavoidable that this can be discussed in the meeting. Get onto jabber :) Hesham=20 > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > Sent: Thursday, November 02, 2006 10:17 PM > To: Soliman, Hesham; mip6@ietf.org > Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not=20 > be usedwhentraversingIPv4 NAT >=20 > Hi Hesham: >=20 > Can't we can start the discussion right now on the list so=20 > that we are > already advanced for the meeting? > I'm afraid I will not attend IETF this time so I will not be able to > defend the following proposal myself.=20 >=20 > Proposal: > --------- >=20 > The proposal aims at checking whether the MN is actually reachable at > the COA, regardless on whether the CoA is IPv6, IPv4 or=20 > IPv4/NAT, before > accepting a BU. Another objective is to minimize the changes=20 > on existing > protocols and implementations. >=20 > 1) The proposed way of doing so is a new, optional 3-way=20 > handshake. This > is achieved by ways of 2 Binding Update flows in a row. >=20 > 2) The handshake is optional. The HA decides to use it whenever its > policy requires. It is recommended to use it at least if the=20 > CoA in the > Binding Update changes and if the alt COA option is not=20 > present, though > it might also be used if the alt CoA option is present, for=20 > instance if > the visited network is not trusted for owning its prefixes. >=20 > 3) The HA signals to the MN that it wants to use the optional 3-way > handshake by responding with a new "additional BU required"=20 > flag in the > Binding Ack. The Binding Ack is sent to the new CoA, as found in the > source of the BU packet or in the alt CoA field if present.=20 > The Binding > Ack also contains Binding Refresh Advice with the Refresh=20 > Interval set > to 0. (alternate, what about using a status code?). >=20 > 4) The HA store that new CoA as "proposed" in the BCE but=20 > waits for an > additional BU with a valid sequence counter to apply the updates > associated to the BU.=20 >=20 > 5) Upon a Binding Ack with the new "additional BU required"=20 > flag, the MN > updates its sequence counter and triggers a new BU immediately. >=20 > 6) If the CoA in a valid BU matches the current CoA or the=20 > proposed CoA > in the BCE, the HA applies the changes associated to the BU=20 > and responds > as mandated by the protocol, without the "additional BU=20 > required" flag > set. >=20 >=20 >=20 >=20 > What do you think? > =09 > Pascal=20 >=20 > =20 >=20 > >-----Original Message----- > >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com]=20 > >Sent: Thursday, November 02, 2006 7:43 AM > >To: mip6@ietf.org > >Subject: RE: [Mip6] concensus: issue 76: Alt CoA should not be=20 > >usedwhentraversingIPv4 NAT > > > >Hi all, > > > >On the question I posted below, we got the following answer:=20 > > > >Yes: 5 > >No: 1 > > > >Other (Yes and No): 1. This was Ryuji's comment where he said=20 > >he would go for "Yes" if integrity is ensured. > > > >We have concensus on removing the Alt-CoA and I will post a=20 > >separate issue on the security aspect of this. Hopefully we=20 > >can resolve the security issue during IETF week.=20 > > > >This issue is now closed. Thanks for your feedback. > > > >Hesham > > > > > -----Original Message----- > > > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] >=20 > >Sent: Wednesday, November 01, 2006 12:11 AM > To: Pascal=20 > >Thubert (pthubert); mip6@ietf.org > Subject: [Mip6]=20 > >concensus: issue 76: Alt CoA should not be > used=20 > >whentraversingIPv4 NAT > > Pascal, all, > > There's been a=20 > >lot of emails on this issue so I think WG members are > fully=20 > >informed now about what this issue involves. I will > ask a=20 > >simple > question and I'd like people to choose one of the=20 > >options below. To > avoid any confusion I'm keeping the=20 > >question simple and clear.=20 > > > > > > Leaving the checksum option and integrity issue aside >=20 > >(because I know we > can fix it and I'm writing a separate=20 > >issue for it) please > let give me > an answer to the=20 > >following question:=20 > > > > > > Do you agree that the MN does not include the Alt-CoA=20 > >option > in the BU > when it is located in an IPv4-only network?=20 > > > > > > 1. Yes > > > 2. No > > > > > > Please include a brief reason for you answer, Pascal=20 > >already did so I > don't expect another one :). As I said,=20 > >ignore the checksum > issue, this > will be handled separately. > > > > > > FWIW, I choose 1) above because it's the only way to make =20 > >> sure that the > HA can detect the presence of a NAT by=20 > >comparing the outer > v4 addresses > with the IPv6 header.=20 > > > > > > Hesham > > > > > > > > > > -----Original Message----- > > > > From: Pascal Thubert (pthubert)=20 > >[mailto:pthubert@cisco.com] > > Sent: Tuesday, October 31,=20 > >2006 4:12 AM > > To: Soliman, Hesham; mip6@ietf.org > >=20 > >Subject: RE: [Mip6] RE: issue 76: Alt CoA should not be used =20 > >> > when traversingIPv4 NAT > > > > Hi Hesham: > > > > > > > > I agree: > > > > > > > > 1) with relaxing the requirement in RFC 3775 to include=20 > >an Alt CoA > > option all the time. > > > > > > > > 2) that the MN should omit it, as opposed to the HA >=20 > >filtering it out. > > > > The Alt CoA is the real address at which the MN is >=20 > >reachable, that is > > what HAs implement today, that is=20 > >what all people in the art > > understand. > > > > I want to stay simple and keep it that way. I'd hate to=20 > > > > have rules like > > "this is A but then if there is=20 > >also that then this is B > which is the > > opposite of A",=20 > >etc... we are not lawyers!=20 > > > > > > > > 3) that we have to find an alternate way to endure that=20 > >the MN is > > reachable at the CoA, defined as the source of=20 > >the packet > when the HA > > gets it. > > > > > > > > I'd also agree that: > > > > > > > > 4) UDP is used all the time in IPv4 roaming situation, =20 > >> regardless on > > whether NAT is detected or not. That's=20 > >not really in the > > mail but since > > you fixed the=20 > >message format in the thread to add UDP, I > > take=20 > >advantage > > of the exchange to raise that point again. > > > > > > > > I disagree: > > > > > > > > 5) to jump too quickly on the conclusion that the=20 > >checksum > > is the way to > > go. I understand that it=20 > >has value in certain scenarios that you > > mention. But it=20 > >fails to guarantee that the MN is reachable > > at the CoA =20 > >> > in another common case that is NAT; and it does not >=20 > >protect against a > > rogue DHCP server assigning you an=20 > >IPv4 DoS'ed address, > which could > > easily happen in the=20 > >IPv4 world.=20 > > > > > > > > So when you call for consensus, please leave open the >=20 > > > solution to 3) so > > we can see if there's a preferable=20 > >alternative. I, for one, > > would favor > > an approach=20 > >like 2 BU flows in row, which would emulate a 3 way > >=20 > >handshake and guarantee the reachability of the MN in all cases.=20 > > > > > > > > Pascal > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] >=20 > > > >Sent: Thursday, October 19, 2006 6:19 PM > > >To:=20 > >mip6@ietf.org > > >Subject: RE: [Mip6] RE: issue 76: Alt CoA=20 > >should not be used when > > traversingIPv4 NAT > > > > >=20 > >>Folks, > > > > > >This issue was revived mainly due to=20 > >Vijay points on the > > need for the > > >checksum option=20 > >when the alt-CoA is not used. Let me > summarise the > >=20 > >>issues first then propose a way forward. > > > > > > > > > >Summary: > > > > >-------- > > > > > > > > > >The initial resolution for the issue suggested that we=20 > >add > > a checksum > > >option that includes a checksum on=20 > >the src and dst > addresses in the > > IPv6 > > >header.=20 > >This was suggested to be used when the alt-coa is > > not=20 > >present > > to > > >maintain the integrity of the src=20 > >address when ESP is used.=20 > > > > I want to > > > > >emphasise that this is only needed when ESP is used,=20 > >not with AH. > > > > > > > > > >Now the point that Vijay raised is also quite valid:=20 > >With NAT > > traversal, > > >the outer IPv4 header is=20 > >vulnerable, yet it is needed > because the HA > > >responds=20 > >to that address and sets up the UDP tunnel to the outer > >=20 > >>(natted) IPv4 src address in the packet containing the BU.=20 > > > > There is no > > > > >way we can secure that address, yet, it essentially=20 > >acts > as another > > >binding, which if modified=20 > >maliciously, would redirect the > > MN's packets > > >to=20 > >another IPv4 address. To be clear, here is the packet format: > > > > >BU packet received by HA after passing through NAT: > > > > > IPv4 HDR (src=3Dnatted-v4, dst=3DHA-addr) > > > > > UDP > > > > > IPv6 HDR (src=3Dv4-mapped-v6, dst=3DHA-addr) > > > > > ESP > > > > > DST-OPT > > > > > MH (BU) > > > > > > > > > >The HA responds with a similar packet including the BA=20 > >and > > forwards all > > >future packets in the UDP=20 > >tunnel, with the dst address > in the IPv4 > > >header=20 > >being the "natted-v4" address above. > > > > >So essentially protecting the BU does not protect the=20 > >MN from > > >redirection attacks in this case because the=20 > >IPv4 header is > > vulnerable. > > > > >This is an inherent problem with NAT traversal. There=20 > >is > practically > > >nothing we can do about it. > > > > > > > > > >So the remaining question is: Is it worth worrying=20 > >about > > the integrity > > >of the BU in this case? IMHO=20 > >I think the answer is yes.=20 > > > > Why? Two main > > > > >reasons: > > > > > > > > > >1. There can be cases where the BU is sent to a local=20 > >HA and the > > >operator can guarantee that no NATs are in=20 > >the path. In > this case we > > >would lose integrity for=20 > >no reason, i.e. the BU becomes > the weakest > > >link.=20 > >This is not unusual really because an operator may > >=20 > >decide that it > > >will only provide the HA function within=20 > >its domain, which > > happens to > > >not include NATs=20 > >between the MN and the HA. > > > > > > > > > >2. We have precedence with MIPv4 and NAT traversal=20 > >where > the RREQ is > > >still secure despite the UNSAF NAT=20 > >traversal. > > > > > > > > > >Note that the answer to 1) above may be "Use AH", but I=20 > > > > prefer to not > > >force that on implementations that=20 > >do not do it today > > (although I would > > >personally=20 > >prefer AH in general for the BU). > > > > > > > > > >For these reasons, and there may be more, I prefer to=20 > >not > > take this big > > >decision to lose the integrity=20 > >for the BU. > > > > > > > > > >Way forward: > > > > >------------ > > > > > > > > > >This issue is now closed, we all agree on it, but there=20 > >may be > > >disagreement on the checksum part. So I suggest=20 > >that I > > generate a new > > >issue for this discussion.=20 > >Until the new issue is resolved, > > I won't add > > >the=20 > >checksum option to the draft. > > > > > > > > > >Feel free to send comments. > > > > > > > > > >Hesham > > > > > > > > > >_______________________________________________ > > > > >Mip6 mailing list > > > > >Mip6@ietf.org > > > > >https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 06:31:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfamy-0001Yu-LT; Thu, 02 Nov 2006 06:31:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfamx-0001Yp-DA for mip6@ietf.org; Thu, 02 Nov 2006 06:31:15 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfamq-0006pY-Mv for mip6@ietf.org; Thu, 02 Nov 2006 06:31:15 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA2BV6jB002898 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Nov 2006 03:31:07 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.141.78]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA2BV4kj011427; Thu, 2 Nov 2006 03:31:06 -0800 (PST) Received: from SANEXCAS02.na.qualcomm.com ([172.30.36.176]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 03:31:04 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 03:31:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Nov 2006 03:30:59 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF40368E2@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? Thread-Index: Acb+E1e0PWYzwdbTTfmQcnJA+r7F0QAK7g7wAAw1a8A= From: "Soliman, Hesham" To: "Narayanan, Vidya" , "Vijay Devarapalli" X-OriginalArrivalTime: 02 Nov 2006 11:31:04.0391 (UTC) FILETIME=[619AF570:01C6FE72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: mip6@ietf.org Subject: [Mip6] RE: What are we protecting over IPv4 in DS-MIP6? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya and Vijay, =20 Vijay wrote:=20 > > ok. stepping back a bit, I will let the WG decide whether we=20 > > want to add a return routability check for the IPv4 CoA. it=20 > > will work of course. > >=20 > > my preference would be not to add this since it adds a round=20 > > trip, making it two round trips every time you send a BU. =3D> I tend to agree with that, for this reason and IMO another stronger reason below. Vidya wrote: > >=20 >=20 > That is not the question. The question is whether it is=20 > important to protect against redirection attacks while=20 > traversing IPv4 networks.=20 =3D> This is 100% correct. This is the right question that should be = asked IMO. I believe it is.=20 =3D> I'm not too sure about this one :). I agree with you that the = attack is valid and one would think that if we're starting the Internet today we should fix it. But let's look at this from an Internet security point of view. If you're interested in avoiding additional vulnerabilities introduced on the Internet, then I'm afraid it's a bit late to do that now. I find the "do no harm" concept that we used with MIPv6 very useful here. The attack you're referring is obviously specific to IPv4 and NAT. It is also doable today with existing MIPv4 and NAT traversal, right? So we're not adding threats that do not exist today, we're simply adapting what was done in MIPv4 to MIPv6 in private v4 networks.=20 In other words, if we want to stick to "accepted" and "documented" threats, then we don't need the reachability check here if it was not done elsewhere. I believe this is an acceptable approach, but I'm open to counter arguments of course. Hesham _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 07:36:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfbnI-0001tL-2X; Thu, 02 Nov 2006 07:35:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfbnG-0001nW-QI for mip6@ietf.org; Thu, 02 Nov 2006 07:35:38 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfbnD-0000Lo-4b for mip6@ietf.org; Thu, 02 Nov 2006 07:35:38 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Nov 2006 13:35:34 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANhNSUWQ/uCLY2dsb2JhbACMQBQPKg X-IronPort-AV: i="4.09,380,1157320800"; d="scan'208"; a="117034856:sNHT30360128" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2CZXqu026389; Thu, 2 Nov 2006 13:35:33 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA2CZWmd025729; Thu, 2 Nov 2006 13:35:32 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 13:35:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Thu, 2 Nov 2006 13:35:24 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02F8ABAD@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb95SWhkkgu6VW7RnKRTucSOtYxxAAAQElwACSsR2A= From: "Pascal Thubert \(pthubert\)" To: "Narayanan, Vidya" , "Vijay Devarapalli" X-OriginalArrivalTime: 02 Nov 2006 12:35:32.0730 (UTC) FILETIME=[6350A5A0:01C6FE7B] DKIM-Signature: a=rsa-sha1; q=dns; l=3395; t=1162470933; x=1163334933; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20What=20are=20we=20protecting=20over=20IPv4=20in=20DS-MIP6?=20(RE =3A=20[Mip6]=20concensus=3A=20issue=2076=3A=20Alt=20CoA=20should=20not=20be =20usedwhen=09traversingIPv4=20NAT); X=v=3Dcisco.com=3B=20h=3DKsaCfokeTao80uTL0s7Oque8avM=3D; b=W3p/8J5ObAt5jvPnjVRuk5iYgd7J+DxRXiv3YDv8T8z5Qf7x3PLi1bMfR/wrVFJfNVOA8+a2 HXjS9t0u3ZUBrdqSrqNlvLxvWKDusq6IR1Rc5ahX5yrfYT6/E+esI6yT; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya Even with MIP6, as long as SeND is not deployed throughout, a visitor can always be fooled by a rogue visited network into forming an address from a victim network's prefix, thus the MN would unknowingly register an address that is not there and causing DoS against the victim's access network. Thus the discussions about an RR test for the HA. IPv4 makes it somewhat worse since the rogue can be a mobile DHCP server assigning the MN a victim's address over a public wlan, thus enabling DoS against that specific address; and there's no SeND; and of course, there's the NAT issue for which we drop the alt CoA shield. So the issue exists at different degrees in all protocols. Thus I'm with you on the conclusion to propose an optional reachability check. Whether to add that proposal in MIPTRANS or as a separate draft can be debated.=20 Please have a look at the proposal I made at the end of the consensus thread. =09 Pascal >-----Original Message----- >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >Sent: Wednesday, November 01, 2006 8:09 PM >To: Vijay Devarapalli >Cc: Soliman, Hesham; mip6@ietf.org; Pascal Thubert (pthubert) >Subject: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should >not be usedwhen traversingIPv4 NAT) > > >All, >This is something I should've raised yesterday when I read all the >emails, but after sleeping over it and some other discussions, I'm still >confused - so, figured I should raise it now :) > >First, I don't believe that an AltCoA option (v4 or v6) buys anything. >Let's look at this. > >In IPv4, the outer IP address is always up for modifications and there >is no way to distinguish an adversary modifying it from a NAT modifying >it. And, if the outer IPv4 source address is different from the inner IP >address, there is no way for the HA to figure out whether the >modification is due to a NAT or an adversary. Such is the truth with >NATs and there is nothing that can be done about it. Even if the outer >and inner IP addresses are the same, there is no way to figure out that >they are the same because there is no NAT or because a NAT-ed IP address >in the outer header has been modified back to equal the inner IP address >by an adversary. This is quite feasible, especially when the inner >packet is not encrypted and totally depends on the intention of the >attacker. > >The presence of the Alt-CoA option buys nothing exactly for the same >reasons. The fact that the Alt-CoA option is integrity protected means >nothing, since the HA still must use the outer IP address as the CoA - >and there is no guarantee about that being intact. > >We cannot pick and choose what attacks we like and what we don't. Either >we protect against redirection attacks or we don't. At this point, I'm >saying that integrity protection of the actual CoA alone proves nothing. >Reachability checks have more value than integrity protection of a field >that is allowed to be modified. Reachability checks too, in the absence >of confidentiality on the inner packet, does not guarantee that an >attacker is not on the path - but, it at least proves that the MN is >reachable at that address. > >So, my vote would be to perform an optional reachability check and >document the vulnerability that may still exist. > >Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 09:08:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdEK-0004zP-2S; Thu, 02 Nov 2006 09:07:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdEI-0004zK-El for mip6@ietf.org; Thu, 02 Nov 2006 09:07:38 -0500 Received: from wx-out-0506.google.com ([66.249.82.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfdEB-0006d4-4r for mip6@ietf.org; Thu, 02 Nov 2006 09:07:38 -0500 Received: by wx-out-0506.google.com with SMTP id t4so147721wxc for ; Thu, 02 Nov 2006 06:07:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=dOqWU5LNS7QRSe5JkuiI9yb+sHBVtQ775VhrI0qklno8gdHB86WtFV0CxL7ohTQKkphgz0TgGnTxFoFb5TL+wA7XMpH7sj4HgEDqgrKHtP3BfgYBB1JqB+7CXdUJ7jQ4zcY9Na7ZhTU0yuz8Z+bEgFzBdgsCVaPoNfoAGyXuj6w= Received: by 10.70.48.15 with SMTP id v15mr667718wxv.1162476450741; Thu, 02 Nov 2006 06:07:30 -0800 (PST) Received: from ?203.178.143.168? ( [203.178.143.168]) by mx.google.com with ESMTP id i39sm3100200wxd.2006.11.02.06.07.27; Thu, 02 Nov 2006 06:07:30 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Thu, 2 Nov 2006 23:07:18 +0900 To: "Narayanan, Vidya" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya RR check can be one solution, but as other people pointed out, this causes additional round trip. In addition, if there is no NAT, we can simply protect CoA by ACoA option. If HA detects that the CoA is different between IPv4 header and ACoA, it can operate your RR check. Otherwise, it should be skipped. A new message BA-ack may be sufficient. i.e. An acknowledgment of BA sent back from MN. ryuji On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > All, > This is something I should've raised yesterday when I read all the > emails, but after sleeping over it and some other discussions, I'm > still > confused - so, figured I should raise it now :) > > First, I don't believe that an AltCoA option (v4 or v6) buys anything. > Let's look at this. > > In IPv4, the outer IP address is always up for modifications and there > is no way to distinguish an adversary modifying it from a NAT > modifying > it. And, if the outer IPv4 source address is different from the > inner IP > address, there is no way for the HA to figure out whether the > modification is due to a NAT or an adversary. Such is the truth with > NATs and there is nothing that can be done about it. Even if the outer > and inner IP addresses are the same, there is no way to figure out > that > they are the same because there is no NAT or because a NAT-ed IP > address > in the outer header has been modified back to equal the inner IP > address > by an adversary. This is quite feasible, especially when the inner > packet is not encrypted and totally depends on the intention of the > attacker. > > The presence of the Alt-CoA option buys nothing exactly for the same > reasons. The fact that the Alt-CoA option is integrity protected means > nothing, since the HA still must use the outer IP address as the CoA - > and there is no guarantee about that being intact. > > We cannot pick and choose what attacks we like and what we don't. > Either > we protect against redirection attacks or we don't. At this point, I'm > saying that integrity protection of the actual CoA alone proves > nothing. > Reachability checks have more value than integrity protection of a > field > that is allowed to be modified. Reachability checks too, in the > absence > of confidentiality on the inner packet, does not guarantee that an > attacker is not on the path - but, it at least proves that the MN is > reachable at that address. > > So, my vote would be to perform an optional reachability check and > document the vulnerability that may still exist. > > Vidya > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 09:23:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdTc-0002dP-1q; Thu, 02 Nov 2006 09:23:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfdTa-0002dC-SF for mip6@ietf.org; Thu, 02 Nov 2006 09:23:26 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfdTM-0001sB-Jl for mip6@ietf.org; Thu, 02 Nov 2006 09:23:26 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA2EN6ko001368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 2 Nov 2006 06:23:07 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.na.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA2ELsrm021325; Thu, 2 Nov 2006 06:23:05 -0800 (PST) Received: from sanexcas01.na.qualcomm.com ([172.30.36.175]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 06:22:11 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 06:22:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Thu, 2 Nov 2006 06:22:04 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF40368FB@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTcNJd8I4UIvTiGoVA+lu7BnqwAAMpjw From: "Soliman, Hesham" To: "RYUJI WAKIKAWA" , "Narayanan, Vidya" X-OriginalArrivalTime: 02 Nov 2006 14:22:10.0539 (UTC) FILETIME=[48B4D3B0:01C6FE8A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > RR check can be one solution, but as other people pointed out, this =20 > causes additional round trip. > In addition, if there is no NAT, we can simply protect CoA by ACoA =20 > option. =3D> This is not the issue being raised, the issue is the insecurity of the IPv4 header when a NAT exists. The outer header is obviously unprotected and vulnerable to redirection attacks (an attacker acting as a NAT bascially). I don't think we need to solve that problem as I indicated in a previous email. Hesham > If HA detects that the CoA is different between IPv4 header=20 > and ACoA, =20 > it can operate your RR check. > Otherwise, it should be skipped. > A new message BA-ack may be sufficient. i.e. An=20 > acknowledgment of BA =20 > sent back from MN. >=20 > ryuji >=20 > On 2006/11/02, at 4:08, Narayanan, Vidya wrote: >=20 > > > > All, > > This is something I should've raised yesterday when I read all the > > emails, but after sleeping over it and some other=20 > discussions, I'm =20 > > still > > confused - so, figured I should raise it now :) > > > > First, I don't believe that an AltCoA option (v4 or v6)=20 > buys anything. > > Let's look at this. > > > > In IPv4, the outer IP address is always up for=20 > modifications and there > > is no way to distinguish an adversary modifying it from a NAT =20 > > modifying > > it. And, if the outer IPv4 source address is different from the =20 > > inner IP > > address, there is no way for the HA to figure out whether the > > modification is due to a NAT or an adversary. Such is the=20 > truth with > > NATs and there is nothing that can be done about it. Even=20 > if the outer > > and inner IP addresses are the same, there is no way to=20 > figure out =20 > > that > > they are the same because there is no NAT or because a NAT-ed IP =20 > > address > > in the outer header has been modified back to equal the inner IP =20 > > address > > by an adversary. This is quite feasible, especially when the inner > > packet is not encrypted and totally depends on the intention of the > > attacker. > > > > The presence of the Alt-CoA option buys nothing exactly=20 > for the same > > reasons. The fact that the Alt-CoA option is integrity=20 > protected means > > nothing, since the HA still must use the outer IP address=20 > as the CoA - > > and there is no guarantee about that being intact. > > > > We cannot pick and choose what attacks we like and what we don't. =20 > > Either > > we protect against redirection attacks or we don't. At=20 > this point, I'm > > saying that integrity protection of the actual CoA alone proves =20 > > nothing. > > Reachability checks have more value than integrity=20 > protection of a =20 > > field > > that is allowed to be modified. Reachability checks too, in the =20 > > absence > > of confidentiality on the inner packet, does not guarantee that an > > attacker is not on the path - but, it at least proves that=20 > the MN is > > reachable at that address. > > > > So, my vote would be to perform an optional reachability check and > > document the vulnerability that may still exist. > > > > Vidya > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 10:03:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfe5w-00030n-Pu; Thu, 02 Nov 2006 10:03:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfe5v-000301-5z for mip6@ietf.org; Thu, 02 Nov 2006 10:03:03 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gfe5r-0001Jc-QJ for mip6@ietf.org; Thu, 02 Nov 2006 10:03:03 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1162479497!3556865!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15148 invoked from network); 2 Nov 2006 14:58:17 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-128.messagelabs.com with SMTP; 2 Nov 2006 14:58:17 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kA2EwH0J024967; Thu, 2 Nov 2006 07:58:17 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id kA2EwG7O008047; Thu, 2 Nov 2006 08:58:16 -0600 (CST) Message-ID: <454A0787.8070600@motorola.com> Date: Thu, 02 Nov 2006 15:58:15 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) References: <2309978910A6A6478C2C7585692B0AF40368FB@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF40368FB@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: >> RR check can be one solution, but as other people pointed out, this >> causes additional round trip. In addition, if there is no NAT, we >> can simply protect CoA by ACoA option. > > => This is not the issue being raised, the issue is the insecurity of > the IPv4 header when a NAT exists. The outer header is obviously > unprotected and vulnerable to redirection attacks (an attacker acting > as a NAT bascially). IKE has features for NAT traversal. Can that disturb DS-MIPv6' and MIP4 NAT Traversal? > I don't think we need to solve that problem as I indicated in a > previous email. Keeping the spec simpler - I'm in favor. Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 10:10:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeC9-0005qh-DL; Thu, 02 Nov 2006 10:09:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfeC8-0005om-3b for mip6@ietf.org; Thu, 02 Nov 2006 10:09:28 -0500 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfeC0-0002OZ-PJ for mip6@ietf.org; Thu, 02 Nov 2006 10:09:28 -0500 Received: by wx-out-0506.google.com with SMTP id t4so167021wxc for ; Thu, 02 Nov 2006 07:09:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=nmwTMQqClpx602NUeC0wMAVUaZCRzE7Lfkc3rmmRwpdN1QFLFPmGXWI0nlx6e2ScHg+vzhfJFwwM7C34WoJq8lgEho/IJWhzfhWQwXW7MjT6Nz6OixmuY+IN4TV7lqVokRrhPC372XQOwd8WBrgGUAf3yEXFgU1ftrTZP2/7OI0= Received: by 10.70.14.9 with SMTP id 9mr947860wxn.1162480159995; Thu, 02 Nov 2006 07:09:19 -0800 (PST) Received: from ?203.178.143.168? ( [203.178.143.168]) by mx.google.com with ESMTP id h11sm2658931wxd.2006.11.02.07.09.18; Thu, 02 Nov 2006 07:09:19 -0800 (PST) In-Reply-To: <2309978910A6A6478C2C7585692B0AF40368FB@NAEX16.na.qualcomm.com> References: <2309978910A6A6478C2C7585692B0AF40368FB@NAEX16.na.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7703E184-862D-49DB-8CBC-C78B3C7CC590@gmail.com> Content-Transfer-Encoding: 7bit From: RYUJI WAKIKAWA Subject: Re: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Fri, 3 Nov 2006 00:09:09 +0900 To: "Soliman, Hesham" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham Yes, I agree. I don't want to have RR for MIP6TRANS, but if somebody wants, please do not make this mandatory. That's my intention:-) regards ryuji On 2006/11/02, at 23:22, Soliman, Hesham wrote: > >> RR check can be one solution, but as other people pointed out, this >> causes additional round trip. >> In addition, if there is no NAT, we can simply protect CoA by ACoA >> option. > > => This is not the issue being raised, the issue is the insecurity of > the IPv4 header when a NAT exists. The outer header is obviously > unprotected and vulnerable to redirection attacks (an attacker > acting as > a NAT bascially). I don't think we need to solve that problem as I > indicated in a previous email. > > Hesham > > > >> If HA detects that the CoA is different between IPv4 header >> and ACoA, >> it can operate your RR check. >> Otherwise, it should be skipped. >> A new message BA-ack may be sufficient. i.e. An >> acknowledgment of BA >> sent back from MN. >> >> ryuji >> >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: >> >>> >>> All, >>> This is something I should've raised yesterday when I read all the >>> emails, but after sleeping over it and some other >> discussions, I'm >>> still >>> confused - so, figured I should raise it now :) >>> >>> First, I don't believe that an AltCoA option (v4 or v6) >> buys anything. >>> Let's look at this. >>> >>> In IPv4, the outer IP address is always up for >> modifications and there >>> is no way to distinguish an adversary modifying it from a NAT >>> modifying >>> it. And, if the outer IPv4 source address is different from the >>> inner IP >>> address, there is no way for the HA to figure out whether the >>> modification is due to a NAT or an adversary. Such is the >> truth with >>> NATs and there is nothing that can be done about it. Even >> if the outer >>> and inner IP addresses are the same, there is no way to >> figure out >>> that >>> they are the same because there is no NAT or because a NAT-ed IP >>> address >>> in the outer header has been modified back to equal the inner IP >>> address >>> by an adversary. This is quite feasible, especially when the inner >>> packet is not encrypted and totally depends on the intention of the >>> attacker. >>> >>> The presence of the Alt-CoA option buys nothing exactly >> for the same >>> reasons. The fact that the Alt-CoA option is integrity >> protected means >>> nothing, since the HA still must use the outer IP address >> as the CoA - >>> and there is no guarantee about that being intact. >>> >>> We cannot pick and choose what attacks we like and what we don't. >>> Either >>> we protect against redirection attacks or we don't. At >> this point, I'm >>> saying that integrity protection of the actual CoA alone proves >>> nothing. >>> Reachability checks have more value than integrity >> protection of a >>> field >>> that is allowed to be modified. Reachability checks too, in the >>> absence >>> of confidentiality on the inner packet, does not guarantee that an >>> attacker is not on the path - but, it at least proves that >> the MN is >>> reachable at that address. >>> >>> So, my vote would be to perform an optional reachability check and >>> document the vulnerability that may still exist. >>> >>> Vidya >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 11:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfftr-0003Cb-9k; Thu, 02 Nov 2006 11:58:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfftq-0003CW-Gi for mip6@ietf.org; Thu, 02 Nov 2006 11:58:42 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gffth-0006jQ-PX for mip6@ietf.org; Thu, 02 Nov 2006 11:58:42 -0500 Received: from [10.1.210.1] ([10.1.210.1]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 08:58:33 -0800 Message-ID: <454A23BE.3090909@azairenet.com> Date: Thu, 02 Nov 2006 08:58:38 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Soliman, Hesham" References: <2309978910A6A6478C2C7585692B0AF40368E2@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF40368E2@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2006 16:58:33.0201 (UTC) FILETIME=[21356E10:01C6FEA0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mip6@ietf.org Subject: [Mip6] Re: What are we protecting over IPv4 in DS-MIP6? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > => I'm not too sure about this one :). I agree with you that the attack > is valid and one would think that if we're starting the Internet today > we should fix it. But let's look at this from an Internet security point > of view. If you're interested in avoiding additional vulnerabilities > introduced on the Internet, then I'm afraid it's a bit late to do that > now. I find the "do no harm" concept that we used with MIPv6 very useful > here. The attack you're referring is obviously specific to IPv4 and NAT. > It is also doable today with existing MIPv4 and NAT traversal, right? So > we're not adding threats that do not exist today, we're simply adapting > what was done in MIPv4 to MIPv6 in private v4 networks. > > In other words, if we want to stick to "accepted" and "documented" > threats, then we don't need the reachability check here if it was not > done elsewhere. I believe this is an acceptable approach, but I'm open > to counter arguments of course. I agree. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 11:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfft9-0002YC-DR; Thu, 02 Nov 2006 11:57:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfft7-0002XL-H9 for mip6@ietf.org; Thu, 02 Nov 2006 11:57:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfft3-0006gS-Rj for mip6@ietf.org; Thu, 02 Nov 2006 11:57:57 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Nov 2006 17:57:33 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANhNSUWQ/uCLY2dsb2JhbACMQBQPKg X-IronPort-AV: i="4.09,381,1157320800"; d="scan'208"; a="117082988:sNHT53459756488" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2GvTOo002627; Thu, 2 Nov 2006 17:57:29 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA2GvMmj014636; Thu, 2 Nov 2006 17:57:29 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 17:57:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Date: Thu, 2 Nov 2006 17:57:14 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02F8AD6B@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Thread-Index: Acb+ksJzzFuUgcfNTyS/bHCaLg7b0QACUKag From: "Pascal Thubert \(pthubert\)" To: "RYUJI WAKIKAWA" , "Soliman, Hesham" X-OriginalArrivalTime: 02 Nov 2006 16:57:24.0844 (UTC) FILETIME=[F876FAC0:01C6FE9F] DKIM-Signature: a=rsa-sha1; q=dns; l=5305; t=1162486649; x=1163350649; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20What=20are=20we=20protecting=20over=20IPv4=20in=20DS-MIP6?=20(RE =3A=20[Mip6]concensus=3A=20issue=2076=3A=20Alt=20CoA=20should=20not=20beuse dwhen=09traversingIPv4=20NAT); X=v=3Dcisco.com=3B=20h=3DOhKMtaQMu5SleSU4AOEIvgWgGX4=3D; b=r/1jNQ3wA6vfXKFyZyHmcGkzeH/3Gt0o1GpY7jBMq4Mz3mqpEt/+mM3Bh45JplEelDn+E3LZ 9h5ghBJ2iQ1wzlE5+cZ9FhWieq6773iryyTgaUiqDFe/mopLnM/EShb3; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ryuji: I agree on your intention. This should be an option. We need to be able to disable the feature completely, and maybe (TBD) we can work out a solution that enables a HA or a MN to stay compatible even if one of the 2 does not support the feature. If it can be lightweight and still provide the service of giving MIP6 equivalent security then I believe we should provide a reachability test, because MIPTRANS inherit from MIP6 and thus come with a MIP6 equivalent level of expectation (in that I slightly disagree with Hesham).=20 It is very true, as you point out, that the 3 way handshake adds to the latency. It is also true that is many case, roaming in IPv4 will be much slower than in IPv6, so maybe the added latency is relatively small and thus affordable. There's also the issue of the added complexity to the protocol and the deployment. We need to come up with a simple increment to the protocol, and propose workable default behavior. I believe that the double BU proposal achieves all this with a default configuration to do the 3 way handshake automatically whenever the alt CoA is missing. =09 Is that already too much? Pascal >-----Original Message----- >From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >Sent: Thursday, November 02, 2006 4:09 PM >To: Soliman, Hesham >Cc: mip6@ietf.org; Pascal Thubert (pthubert) >Subject: Re: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA >should not beusedwhen traversingIPv4 NAT) > >Hi Hesham > >Yes, I agree. >I don't want to have RR for MIP6TRANS, but >if somebody wants, please do not make this mandatory. >That's my intention:-) > >regards >ryuji > > >On 2006/11/02, at 23:22, Soliman, Hesham wrote: > >> >>> RR check can be one solution, but as other people pointed out, this >>> causes additional round trip. >>> In addition, if there is no NAT, we can simply protect CoA by ACoA >>> option. >> >> =3D> This is not the issue being raised, the issue is the insecurity = of >> the IPv4 header when a NAT exists. The outer header is obviously >> unprotected and vulnerable to redirection attacks (an attacker >> acting as >> a NAT bascially). I don't think we need to solve that problem as I >> indicated in a previous email. >> >> Hesham >> >> >> >>> If HA detects that the CoA is different between IPv4 header >>> and ACoA, >>> it can operate your RR check. >>> Otherwise, it should be skipped. >>> A new message BA-ack may be sufficient. i.e. An >>> acknowledgment of BA >>> sent back from MN. >>> >>> ryuji >>> >>> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: >>> >>>> >>>> All, >>>> This is something I should've raised yesterday when I read all the >>>> emails, but after sleeping over it and some other >>> discussions, I'm >>>> still >>>> confused - so, figured I should raise it now :) >>>> >>>> First, I don't believe that an AltCoA option (v4 or v6) >>> buys anything. >>>> Let's look at this. >>>> >>>> In IPv4, the outer IP address is always up for >>> modifications and there >>>> is no way to distinguish an adversary modifying it from a NAT >>>> modifying >>>> it. And, if the outer IPv4 source address is different from the >>>> inner IP >>>> address, there is no way for the HA to figure out whether the >>>> modification is due to a NAT or an adversary. Such is the >>> truth with >>>> NATs and there is nothing that can be done about it. Even >>> if the outer >>>> and inner IP addresses are the same, there is no way to >>> figure out >>>> that >>>> they are the same because there is no NAT or because a NAT-ed IP >>>> address >>>> in the outer header has been modified back to equal the inner IP >>>> address >>>> by an adversary. This is quite feasible, especially when the inner >>>> packet is not encrypted and totally depends on the intention of the >>>> attacker. >>>> >>>> The presence of the Alt-CoA option buys nothing exactly >>> for the same >>>> reasons. The fact that the Alt-CoA option is integrity >>> protected means >>>> nothing, since the HA still must use the outer IP address >>> as the CoA - >>>> and there is no guarantee about that being intact. >>>> >>>> We cannot pick and choose what attacks we like and what we don't. >>>> Either >>>> we protect against redirection attacks or we don't. At >>> this point, I'm >>>> saying that integrity protection of the actual CoA alone proves >>>> nothing. >>>> Reachability checks have more value than integrity >>> protection of a >>>> field >>>> that is allowed to be modified. Reachability checks too, in the >>>> absence >>>> of confidentiality on the inner packet, does not guarantee that an >>>> attacker is not on the path - but, it at least proves that >>> the MN is >>>> reachable at that address. >>>> >>>> So, my vote would be to perform an optional reachability check and >>>> document the vulnerability that may still exist. >>>> >>>> Vidya >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 11:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfftr-0003Cb-9k; Thu, 02 Nov 2006 11:58:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfftq-0003CW-Gi for mip6@ietf.org; Thu, 02 Nov 2006 11:58:42 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gffth-0006jQ-PX for mip6@ietf.org; Thu, 02 Nov 2006 11:58:42 -0500 Received: from [10.1.210.1] ([10.1.210.1]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 08:58:33 -0800 Message-ID: <454A23BE.3090909@azairenet.com> Date: Thu, 02 Nov 2006 08:58:38 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Soliman, Hesham" References: <2309978910A6A6478C2C7585692B0AF40368E2@NAEX16.na.qualcomm.com> In-Reply-To: <2309978910A6A6478C2C7585692B0AF40368E2@NAEX16.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Nov 2006 16:58:33.0201 (UTC) FILETIME=[21356E10:01C6FEA0] X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: mip6@ietf.org Subject: [Mip6] Re: What are we protecting over IPv4 in DS-MIP6? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Soliman, Hesham wrote: > => I'm not too sure about this one :). I agree with you that the attack > is valid and one would think that if we're starting the Internet today > we should fix it. But let's look at this from an Internet security point > of view. If you're interested in avoiding additional vulnerabilities > introduced on the Internet, then I'm afraid it's a bit late to do that > now. I find the "do no harm" concept that we used with MIPv6 very useful > here. The attack you're referring is obviously specific to IPv4 and NAT. > It is also doable today with existing MIPv4 and NAT traversal, right? So > we're not adding threats that do not exist today, we're simply adapting > what was done in MIPv4 to MIPv6 in private v4 networks. > > In other words, if we want to stick to "accepted" and "documented" > threats, then we don't need the reachability check here if it was not > done elsewhere. I believe this is an acceptable approach, but I'm open > to counter arguments of course. I agree. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 11:58:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfft9-0002YC-DR; Thu, 02 Nov 2006 11:57:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfft7-0002XL-H9 for mip6@ietf.org; Thu, 02 Nov 2006 11:57:57 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gfft3-0006gS-Rj for mip6@ietf.org; Thu, 02 Nov 2006 11:57:57 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Nov 2006 17:57:33 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANhNSUWQ/uCLY2dsb2JhbACMQBQPKg X-IronPort-AV: i="4.09,381,1157320800"; d="scan'208"; a="117082988:sNHT53459756488" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA2GvTOo002627; Thu, 2 Nov 2006 17:57:29 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA2GvMmj014636; Thu, 2 Nov 2006 17:57:29 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 17:57:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Date: Thu, 2 Nov 2006 17:57:14 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02F8AD6B@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Thread-Index: Acb+ksJzzFuUgcfNTyS/bHCaLg7b0QACUKag From: "Pascal Thubert \(pthubert\)" To: "RYUJI WAKIKAWA" , "Soliman, Hesham" X-OriginalArrivalTime: 02 Nov 2006 16:57:24.0844 (UTC) FILETIME=[F876FAC0:01C6FE9F] DKIM-Signature: a=rsa-sha1; q=dns; l=5305; t=1162486649; x=1163350649; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20What=20are=20we=20protecting=20over=20IPv4=20in=20DS-MIP6?=20(RE =3A=20[Mip6]concensus=3A=20issue=2076=3A=20Alt=20CoA=20should=20not=20beuse dwhen=09traversingIPv4=20NAT); X=v=3Dcisco.com=3B=20h=3DOhKMtaQMu5SleSU4AOEIvgWgGX4=3D; b=r/1jNQ3wA6vfXKFyZyHmcGkzeH/3Gt0o1GpY7jBMq4Mz3mqpEt/+mM3Bh45JplEelDn+E3LZ 9h5ghBJ2iQ1wzlE5+cZ9FhWieq6773iryyTgaUiqDFe/mopLnM/EShb3; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ryuji: I agree on your intention. This should be an option. We need to be able to disable the feature completely, and maybe (TBD) we can work out a solution that enables a HA or a MN to stay compatible even if one of the 2 does not support the feature. If it can be lightweight and still provide the service of giving MIP6 equivalent security then I believe we should provide a reachability test, because MIPTRANS inherit from MIP6 and thus come with a MIP6 equivalent level of expectation (in that I slightly disagree with Hesham).=20 It is very true, as you point out, that the 3 way handshake adds to the latency. It is also true that is many case, roaming in IPv4 will be much slower than in IPv6, so maybe the added latency is relatively small and thus affordable. There's also the issue of the added complexity to the protocol and the deployment. We need to come up with a simple increment to the protocol, and propose workable default behavior. I believe that the double BU proposal achieves all this with a default configuration to do the 3 way handshake automatically whenever the alt CoA is missing. =09 Is that already too much? Pascal >-----Original Message----- >From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >Sent: Thursday, November 02, 2006 4:09 PM >To: Soliman, Hesham >Cc: mip6@ietf.org; Pascal Thubert (pthubert) >Subject: Re: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA >should not beusedwhen traversingIPv4 NAT) > >Hi Hesham > >Yes, I agree. >I don't want to have RR for MIP6TRANS, but >if somebody wants, please do not make this mandatory. >That's my intention:-) > >regards >ryuji > > >On 2006/11/02, at 23:22, Soliman, Hesham wrote: > >> >>> RR check can be one solution, but as other people pointed out, this >>> causes additional round trip. >>> In addition, if there is no NAT, we can simply protect CoA by ACoA >>> option. >> >> =3D> This is not the issue being raised, the issue is the insecurity = of >> the IPv4 header when a NAT exists. The outer header is obviously >> unprotected and vulnerable to redirection attacks (an attacker >> acting as >> a NAT bascially). I don't think we need to solve that problem as I >> indicated in a previous email. >> >> Hesham >> >> >> >>> If HA detects that the CoA is different between IPv4 header >>> and ACoA, >>> it can operate your RR check. >>> Otherwise, it should be skipped. >>> A new message BA-ack may be sufficient. i.e. An >>> acknowledgment of BA >>> sent back from MN. >>> >>> ryuji >>> >>> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: >>> >>>> >>>> All, >>>> This is something I should've raised yesterday when I read all the >>>> emails, but after sleeping over it and some other >>> discussions, I'm >>>> still >>>> confused - so, figured I should raise it now :) >>>> >>>> First, I don't believe that an AltCoA option (v4 or v6) >>> buys anything. >>>> Let's look at this. >>>> >>>> In IPv4, the outer IP address is always up for >>> modifications and there >>>> is no way to distinguish an adversary modifying it from a NAT >>>> modifying >>>> it. And, if the outer IPv4 source address is different from the >>>> inner IP >>>> address, there is no way for the HA to figure out whether the >>>> modification is due to a NAT or an adversary. Such is the >>> truth with >>>> NATs and there is nothing that can be done about it. Even >>> if the outer >>>> and inner IP addresses are the same, there is no way to >>> figure out >>>> that >>>> they are the same because there is no NAT or because a NAT-ed IP >>>> address >>>> in the outer header has been modified back to equal the inner IP >>>> address >>>> by an adversary. This is quite feasible, especially when the inner >>>> packet is not encrypted and totally depends on the intention of the >>>> attacker. >>>> >>>> The presence of the Alt-CoA option buys nothing exactly >>> for the same >>>> reasons. The fact that the Alt-CoA option is integrity >>> protected means >>>> nothing, since the HA still must use the outer IP address >>> as the CoA - >>>> and there is no guarantee about that being intact. >>>> >>>> We cannot pick and choose what attacks we like and what we don't. >>>> Either >>>> we protect against redirection attacks or we don't. At >>> this point, I'm >>>> saying that integrity protection of the actual CoA alone proves >>>> nothing. >>>> Reachability checks have more value than integrity >>> protection of a >>>> field >>>> that is allowed to be modified. Reachability checks too, in the >>>> absence >>>> of confidentiality on the inner packet, does not guarantee that an >>>> attacker is not on the path - but, it at least proves that >>> the MN is >>>> reachable at that address. >>>> >>>> So, my vote would be to perform an optional reachability check and >>>> document the vulnerability that may still exist. >>>> >>>> Vidya >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >>> > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 12:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgEN-0004Pc-UY; Thu, 02 Nov 2006 12:19:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgEN-0004PX-0t for mip6@ietf.org; Thu, 02 Nov 2006 12:19:55 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfgEK-0000rB-T9 for mip6@ietf.org; Thu, 02 Nov 2006 12:19:55 -0500 Received: by ug-out-1314.google.com with SMTP id 72so158580ugd for ; Thu, 02 Nov 2006 09:19:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hU0EJp1USjYKZAnb86HFqRCsgPQdmmBHh1Tu35IWBY74F57n0ucv4cHB0erkf60Tmi5lhz8wA3IPzAcL5frD1ikcBPLLygK/zDp7X1S1xy+sPAHSD8P1OKth4FYUR53nepPR9sO2Y1f6C/meqSFlQnoFySRlTUh7oM3GwGKVWwo= Received: by 10.67.117.2 with SMTP id u2mr1000934ugm.1162487991415; Thu, 02 Nov 2006 09:19:51 -0800 (PST) Received: by 10.66.243.16 with HTTP; Thu, 2 Nov 2006 09:19:51 -0800 (PST) Message-ID: Date: Thu, 2 Nov 2006 18:19:51 +0100 From: "Gerardo Giaretta" To: "Yoshihiro Ohba" Subject: Re: [Mip6] WG LC: Yoshihiro Ohba's review In-Reply-To: <20061031193214.GF17201@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061010133810.GA1208@ipv6-3.int-evry.fr> <20061031193214.GF17201@steelhead> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Julien Bournelle , Basavaraj Patil , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Yoshi, > > > > This is not present in any bootstrapping solution specified in MIP6 WG > > even though it may possible in some deployment scenarios. > > I thought that operators may want to let AAAH assign home > address/prefix dedicated to a particular user. But if no one cares > this scenario, I would not care. > The operator requirement is to be able to assign a static HoA or home prefix based on the user profile. One way to do that is to have the AAAH assignign it. However this may imply that we cannot re-use Diameter EAP application as it is since we need this extra functionality. What do others think? Should we add such a requirement? > > > > > >- In the integrated case, whether the AAA server for the AAA-HA > > >interface and the AAA server for the AAA-NAS interface can be > > >different. > > > > > > > Isn't this related to the discussion? Maybe we can add a goal stating > > that in integrated scenario the AAA server authenticating the network > > access may be different from the AAA server authenticating the > > mobility service and the solution must support this. Is it ok? > > Yes, this works for me for the second part. What about the first part > about separation of authentication and authorization? In general, > separation of authentication and authorization is good for being > flexibile in providing services. For example, in a particular > scenario it is possible that an IKEv2 certificate without EAP is used > for authenticating MN, but a AAA protocol is used for authorizing the > MN. Note that authorization does not necessary imply home > address/prefix assignment by AAAH, it can be just a binary result > (approved/denied). > I see the separation of authentication and authorization as a design choice that we have done in DIME WG and not a requirement. Therefore, I would not be in favor of adding any requirement related to auth/authz split in this draft. > > > > > > > >8. Security Considerations > > > > > > As stated in Section 5.1 the AAA-HA interface must provide mutual > > > authentication, integrity and replay protection. Furthermore, if > > > security parameters (e.g., IKE pre-shared key) are transferred > > > through this interface, confidentiality is strongly recommended to be > > > supported. However note that AAA protocols does not support this > > > unless it exists a direct connection between corresponding entities. > > > > > >YO: Is there any scenario in which security parameters are not > > >transferred through this interface? > > > > > > > What do you mean by security parameters here? > > I meant IKE pre-shared key because it is the only security parameter > mentioned in the text. > ok, I can think of several scenarios in which the IKE PSK is sent to the HA by the AAAH (as specified in my bootstrapping proposal based on EAP) but we don't have this in any MIP6 official document. Regards, --Gerardo > > > > Anyway, the text si not fully correct since there is not any official > > solution in MIP6 WG so far that implies that a pre-shared key is > > transferred through this interface. However, there are some proposals > > on this approach and I think the text in the sec cons can be kept. > > In the authorization-only scenario I mentioned above, no IKE > pre-shared key would be transferred. > > Regards, > Yoshihiro Ohba > > > > > > --Gerardo > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 12:21:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgG5-00050v-UE; Thu, 02 Nov 2006 12:21:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgG4-0004xn-Tc for mip6@ietf.org; Thu, 02 Nov 2006 12:21:40 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfgFs-00011S-BC for mip6@ietf.org; Thu, 02 Nov 2006 12:21:40 -0500 Received: by ug-out-1314.google.com with SMTP id 72so158929ugd for ; Thu, 02 Nov 2006 09:21:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=mDyDLs5r1Cdn6rOChK3aEzBgJJ/AP2FDAySr16REYuUBZrIvg9EGRsFkIRmwbXZx3txy3VDR4X4A0PdPl76Q3UPIbNh28HSzSNdEpfuoSPfw2S10RWG+X4I1HOSCM89dTL1M4FARI3iUmRyQA8FD2Af9lXcC1aIdEAsFYddXlS0= Received: by 10.67.117.2 with SMTP id u2mr1003397ugm.1162488087278; Thu, 02 Nov 2006 09:21:27 -0800 (PST) Received: by 10.66.243.16 with HTTP; Thu, 2 Nov 2006 09:21:27 -0800 (PST) Message-ID: Date: Thu, 2 Nov 2006 18:21:27 +0100 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Mip6] WG LC: Yoshihiro Ohba's review In-Reply-To: <45480357.2030601@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061010133810.GA1208@ipv6-3.int-evry.fr> <45480357.2030601@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, both are "MUST be able to indicate" and not "MUST indicate". So I would be in favor of keeping a MUST. --Gerardo On 11/1/06, Vijay Devarapalli wrote: > Gerardo Giaretta wrote: > > >> G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > >> authorized to autoconfigure its Home Address. > >> > >> YO: Why this is not "MUST be able to"? > >> > > > > I'll fix it. > > this might be specific to the home agent. basically > the AAAH might not care whether the HA assigns the > home address or if the HA allows the MN to > autoconfigure the home address. so I don't think we > should have a "MUST" here. > > >> G6.2 The NAS SHOULD be able to notify that it supports the > >> functionalities described in [4]. > >> > >> YO: The NAS notifies to whom? I guess the NAS notifies AAAH server of > >> the functionalities. If so, please explicitly mention it. Also why > >> this is not "MUST be able to"? > >> > > > > ok, I'll fix it > > again, should this be a MUST? I don't think we > should be requiring the NAS to be able to tell the > AAAH that it can support this functionality. Kuntal? > > Vijay > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 12:22:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgHF-00072w-DL; Thu, 02 Nov 2006 12:22:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfgHE-00072r-Aq for mip6@ietf.org; Thu, 02 Nov 2006 12:22:52 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfgH4-0001AF-US for mip6@ietf.org; Thu, 02 Nov 2006 12:22:52 -0500 Received: by ug-out-1314.google.com with SMTP id 72so159184ugd for ; Thu, 02 Nov 2006 09:22:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=TRWeCormCxKtLCey6/5PjSFMEHNvOR2SPLDPGRqbsh+Kb6d3qOCGcfBti9FfGfauuv3mqTkmHBbqAKVn/jPYaixfs71RK/C5QcdEiGtcEQzhTJDqSoVPgjRHKZF3/7MvCtsrzRnO8hDdQ7IZadrNMQohcyUiG/04EoxtsguXzTc= Received: by 10.66.242.20 with SMTP id p20mr1011674ugh.1162488161814; Thu, 02 Nov 2006 09:22:41 -0800 (PST) Received: by 10.66.243.16 with HTTP; Thu, 2 Nov 2006 09:22:41 -0800 (PST) Message-ID: Date: Thu, 2 Nov 2006 18:22:41 +0100 From: "Gerardo Giaretta" To: "Vijay Devarapalli" Subject: Re: [Mip6] WG LC: Yoshihiro Ohba's review In-Reply-To: <4548C250.9050207@azairenet.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061010133810.GA1208@ipv6-3.int-evry.fr> <45480357.2030601@azairenet.com> <20061101024039.GB22250@steelhead> <4548C250.9050207@azairenet.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > What I meant in my comment was that these requirements seem to > > indicate "mandatory-to-support and optional-to-use" features, and thus > > I thought it is better to say "MUST be able to" than "SHOULD be able > > to". Perhaps we could simply say: > > > > G5.2 The AAAH MAY indicate to the HA if the MN is authorized to > > autoconfigure its Home Address. > > > > G6.2 The NAS MAY notify that it supports the functionalities described > > in [4]. > > sounds good to me. > Not sure MAY is the right key word. MUST be able is clear that is mandatory to support and optional to use so I still prefer it. --Gerardo > Vijay > > > > > Yoshihiro Ohba > > > > > > On Tue, Oct 31, 2006 at 06:15:51PM -0800, Vijay Devarapalli wrote: > >> Gerardo Giaretta wrote: > >> > >>>> G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > >>>> authorized to autoconfigure its Home Address. > >>>> > >>>> YO: Why this is not "MUST be able to"? > >>>> > >>> I'll fix it. > >> this might be specific to the home agent. basically > >> the AAAH might not care whether the HA assigns the > >> home address or if the HA allows the MN to > >> autoconfigure the home address. so I don't think we > >> should have a "MUST" here. > >> > >>>> G6.2 The NAS SHOULD be able to notify that it supports the > >>>> functionalities described in [4]. > >>>> > >>>> YO: The NAS notifies to whom? I guess the NAS notifies AAAH server of > >>>> the functionalities. If so, please explicitly mention it. Also why > >>>> this is not "MUST be able to"? > >>>> > >>> ok, I'll fix it > >> again, should this be a MUST? I don't think we > >> should be requiring the NAS to be able to tell the > >> AAAH that it can support this functionality. Kuntal? > >> > >> Vijay > >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 13:33:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhMi-0006Z6-5B; Thu, 02 Nov 2006 13:32:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhMg-0006X7-TM for mip6@ietf.org; Thu, 02 Nov 2006 13:32:34 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfhH2-00005j-1A for mip6@ietf.org; Thu, 02 Nov 2006 13:26:45 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kA2IPtqB062021; Thu, 2 Nov 2006 13:25:56 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Thu, 2 Nov 2006 13:26:01 -0500 To: Gerardo Giaretta Subject: Re: [Mip6] WG LC: Yoshihiro Ohba's review Message-ID: <20061102182601.GB3934@steelhead> References: <20061010133810.GA1208@ipv6-3.int-evry.fr> <20061031193214.GF17201@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 33 X-Spam-Score: -2.4 (--) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Julien Bournelle , Yoshihiro Ohba , Basavaraj Patil , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Thu, Nov 02, 2006 at 06:19:51PM +0100, Gerardo Giaretta wrote: > >> > > >> >8. Security Considerations > >> > > >> > As stated in Section 5.1 the AAA-HA interface must provide mutual > >> > authentication, integrity and replay protection. Furthermore, if > >> > security parameters (e.g., IKE pre-shared key) are transferred > >> > through this interface, confidentiality is strongly recommended to be > >> > supported. However note that AAA protocols does not support this > >> > unless it exists a direct connection between corresponding entities. > >> > > >> >YO: Is there any scenario in which security parameters are not > >> >transferred through this interface? > >> > > >> > >> What do you mean by security parameters here? > > > >I meant IKE pre-shared key because it is the only security parameter > >mentioned in the text. > > > > ok, I can think of several scenarios in which the IKE PSK is sent to > the HA by the AAAH (as specified in my bootstrapping proposal based on > EAP) but we don't have this in any MIP6 official document. OK, then it would be more appropriate to mention EAP MSK, which would be used for signing IKEv2 AUTH payload after EAP authentication, rather than IKE pre-shared key which seems to imply the key used for IKEv2 PSK mode authentication. Yoshihiro Ohba _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 02 13:38:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhSG-0001F5-PX; Thu, 02 Nov 2006 13:38:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfhSF-0001Ev-2L for mip6@ietf.org; Thu, 02 Nov 2006 13:38:19 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfhS9-00020S-Gz for mip6@ietf.org; Thu, 02 Nov 2006 13:38:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG LC: Yoshihiro Ohba's review Date: Thu, 2 Nov 2006 10:34:23 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] WG LC: Yoshihiro Ohba's review Thread-Index: Acb+o1WhBNd9XbgoRqGRmz6fxKaVpwACghgg From: "Vijay Devarapalli" To: "Gerardo Giaretta" X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org "MUST be able to indicate" imposes the solution to=20 support the requirement. so its not fine. Vijay > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > Sent: Thursday, November 02, 2006 9:21 AM > To: Vijay Devarapalli > Cc: Chowdhury, Kuntal; Yoshihiro Ohba; mip6@ietf.org > Subject: Re: [Mip6] WG LC: Yoshihiro Ohba's review >=20 > Vijay, >=20 > both are "MUST be able to indicate" and not "MUST indicate". So I > would be in favor of keeping a MUST. >=20 > --Gerardo >=20 > On 11/1/06, Vijay Devarapalli wrote: > > Gerardo Giaretta wrote: > > > > >> G5.2 The AAAH SHOULD be able to indicate to the HA=20 > if the MN is > > >> authorized to autoconfigure its Home Address. > > >> > > >> YO: Why this is not "MUST be able to"? > > >> > > > > > > I'll fix it. > > > > this might be specific to the home agent. basically > > the AAAH might not care whether the HA assigns the > > home address or if the HA allows the MN to > > autoconfigure the home address. so I don't think we > > should have a "MUST" here. > > > > >> G6.2 The NAS SHOULD be able to notify that it supports the > > >> functionalities described in [4]. > > >> > > >> YO: The NAS notifies to whom? I guess the NAS notifies=20 > AAAH server of > > >> the functionalities. If so, please explicitly mention=20 > it. Also why > > >> this is not "MUST be able to"? > > >> > > > > > > ok, I'll fix it > > > > again, should this be a MUST? I don't think we > > should be requiring the NAS to be able to tell the > > AAAH that it can support this functionality. Kuntal? > > > > Vijay > > >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 03 09:07:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfzgB-0007LK-Ka; Fri, 03 Nov 2006 09:05:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfzgA-0007Ht-OB for mip6@ietf.org; Fri, 03 Nov 2006 09:05:54 -0500 Received: from outbound-dub.frontbridge.com ([213.199.154.16] helo=outbound2-dub-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfzW1-0007yv-6f for mip6@ietf.org; Fri, 03 Nov 2006 08:55:30 -0500 Received: from outbound2-dub.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-dub-R.bigfish.com (Postfix) with ESMTP id 5DA65648049; Fri, 3 Nov 2006 13:55:24 +0000 (UTC) Received: from mail46-dub-R.bigfish.com (unknown [10.5.252.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound2-dub.bigfish.com (Postfix) with ESMTP id 4AADA1930043; Fri, 3 Nov 2006 13:55:24 +0000 (UTC) Received: from mail46-dub (localhost.localdomain [127.0.0.1]) by mail46-dub-R.bigfish.com (Postfix) with ESMTP id 2550E1C1822E; Fri, 3 Nov 2006 13:55:24 +0000 (UTC) X-BigFish: V Received: by mail46-dub (MessageSwitch) id 1162562124100921_29608; Fri, 3 Nov 2006 13:55:24 +0000 (UCT) Received: from smtpgw6.it.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by mail46-dub.bigfish.com (Postfix) with ESMTP id B5A161BD0057; Fri, 3 Nov 2006 13:55:23 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw6.it.sprintspectrum.com (8.12.11.Beta0/8.12.8) with ESMTP id kA3DtMFY004502; Fri, 3 Nov 2006 07:55:22 -0600 (CST) Received: from pdawg05a.ad.sprint.com (PDAWG05A.corp.sprint.com [10.122.2.38]) by mailhost.sprintspectrum.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kA3DtMfL022433; Fri, 3 Nov 2006 07:55:22 -0600 (CST) Received: from PLSWB09C.ad.sprint.com ([208.10.70.239]) by pdawg05a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 07:55:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Date: Fri, 3 Nov 2006 07:55:12 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Thread-Index: Acb+iTcNJd8I4UIvTiGoVA+lu7BnqwAAMpjwADDOmtA= From: "Zhang, Qiang [NTK]" To: "Soliman, Hesham" , "RYUJI WAKIKAWA" , "Narayanan, Vidya" X-OriginalArrivalTime: 03 Nov 2006 13:55:22.0341 (UTC) FILETIME=[B48F0950:01C6FF4F] X-Spam-Score: 0.1 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hesham,=20 I would agree the MITM attack will not compromise the security provided = via Ipsec ESP but rather a DoS is possible if indeed the attacker got in = the routing path/redirect. Just a hypothesis that the issue can only be = resolved through hop-hop security, RR will not help on the DoS, no? Qiang -----Original Message----- From: Soliman, Hesham [mailto:hsoliman@qualcomm.com]=20 Sent: Thursday, November 02, 2006 9:22 AM To: RYUJI WAKIKAWA; Narayanan, Vidya Cc: mip6@ietf.org; Pascal Thubert (pthubert) Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: = [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 = NAT) > RR check can be one solution, but as other people pointed out, this = > causes additional round trip. > In addition, if there is no NAT, we can simply protect CoA by ACoA > = option. =3D> This is not the issue being raised, the issue is the insecurity of = the IPv4 header when a NAT exists. The outer header is obviously = unprotected and vulnerable to redirection attacks (an attacker acting as = a NAT bascially). I don't think we need to solve that problem as I = indicated in a previous email. Hesham > If HA detects that the CoA is different between IPv4 header > and = ACoA, > it can operate your RR check. > Otherwise, it should be skipped. > A new message BA-ack may be sufficient. i.e. An > acknowledgment of = BA > sent back from MN. > > ryuji > > On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > > > All, > > This is something I should've raised yesterday when I read all the = > > emails, but after sleeping over it and some other > discussions, = I'm > > still > > confused - so, figured I should raise it now :) > > = > > First, I don't believe that an AltCoA option (v4 or v6) > buys = anything. > > Let's look at this. > > > > In IPv4, the outer IP address is always up for > modifications and = there > > is no way to distinguish an adversary modifying it from a NAT = > > modifying > > it. And, if the outer IPv4 source address is = different from the > > inner IP > > address, there is no way for the = HA to figure out whether the > > modification is due to a NAT or an = adversary. Such is the > truth with > > NATs and there is nothing that = can be done about it. Even > if the outer > > and inner IP addresses = are the same, there is no way to > figure out > > that > > they are = the same because there is no NAT or because a NAT-ed IP > > address > = > in the outer header has been modified back to equal the inner IP > > = address > > by an adversary. This is quite feasible, especially when = the inner > > packet is not encrypted and totally depends on the = intention of the > > attacker. > > > > The presence of the Alt-CoA option buys nothing exactly > for the = same > > reasons. The fact that the Alt-CoA option is integrity > = protected means > > nothing, since the HA still must use the outer IP = address > as the CoA - > > and there is no guarantee about that being = intact. > > > > We cannot pick and choose what attacks we like and what we don't. =20 > > Either > > we protect against redirection attacks or we don't. At > this = point, I'm > > saying that integrity protection of the actual CoA alone = proves > > nothing. > > Reachability checks have more value than integrity > protection of = a > > field > > that is allowed to be modified. Reachability checks = too, in the > > absence > > of confidentiality on the inner packet, = does not guarantee that an > > attacker is not on the path - but, it at = least proves that > the MN is > > reachable at that address. > > > > So, my vote would be to perform an optional reachability check and = > > document the vulnerability that may still exist. > > > > Vidya > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 03 09:07:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gfzgp-0007gN-KO; Fri, 03 Nov 2006 09:06:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfzgI-0007N3-TF for mip6@ietf.org; Fri, 03 Nov 2006 09:06:02 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfzSk-0007WW-E9 for mip6@ietf.org; Fri, 03 Nov 2006 08:52:06 -0500 Received: by ug-out-1314.google.com with SMTP id 72so366347ugd for ; Fri, 03 Nov 2006 05:52:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Q4qNS/PxyNW1TxAnT1CcrTNDsKXk7INLC7z8qP+q0buDndwkBac7ly3i7B7CmT+mDFuvl8gDiQLmXnAl5sRklnnaMwdiirpdI7fx8hKnaiPH+tetm03rlbaWqNOQOq/IPfEsLKT9faJt9l1+pNXp3O5vMs83h+zzot1tlSMtwMA= Received: by 10.67.121.18 with SMTP id y18mr2691688ugm.1162561919808; Fri, 03 Nov 2006 05:51:59 -0800 (PST) Received: by 10.66.243.16 with HTTP; Fri, 3 Nov 2006 05:51:59 -0800 (PST) Message-ID: Date: Fri, 3 Nov 2006 14:51:59 +0100 From: "Gerardo Giaretta" To: "Hannes Tschofenig" Subject: Re: [Mip6] Comments for draft-ietf-mip6-aaa-ha-goals-03 In-Reply-To: <4549206E.4060601@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4549206E.4060601@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hannes, thanks for the review. Please see below.. > The requirements should then be phrased in such a way that they refer to > the design of the protocol rather its usage. > > The following example shows what I mean: > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > Home Address allocated to the MN (e.g., for allowing the AAAH > server to perform a DNS update on behalf of the MN). > > Here, I think the AAA protocol extension MUST allow Home Address to be > communicated from the HA to the MN. It is, however, not necessary to use > it. > Are you suggesting to rephrase all requirements in terms of "the AAA protocol MUST allow...". That is fine with me. What do others think? > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > authorized to autoconfigure its Home Address. > > The same here. The protocol must support a way to allow the AAAH to > indicate whether autoconfigure the HoA. It obviously does not need to > use it. > > The same is true for G2.2, G2.3, G5.1, G5.2, G6.2, and G6.3. > > Requirement G6.3 should use the terms AAAH and NAS instead of > ASP/MSP/MSA. > > I am not sure whether you agree with me but see it in the following way: > If I don't implement SHOULD and MAY requirements I don't think I can > design an interoperable protocol. > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > Identifier (NAI) to identify the user. > > Why "SHOULD" instead of "MUST"? > What identifier would you like to use instead of a NAI? > > There are still some minor typos and editorial issues in the document. I > will not describe them here. > > I would replace the term "interface" with "protocol" and "goals" with > "requirements" to get the document more inline with other IETF > requirements documents. > Some people were against the usage of requirements. I don't have a strong opinion on this. --Gerardo > Ciao > Hannes > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 03 09:33:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg06k-0004P1-S2; Fri, 03 Nov 2006 09:33:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg04L-0003cN-Sw for mip6@ietf.org; Fri, 03 Nov 2006 09:30:53 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg03K-0003zi-L0 for mip6@ietf.org; Fri, 03 Nov 2006 09:29:54 -0500 Received: by ug-out-1314.google.com with SMTP id 72so375422ugd for ; Fri, 03 Nov 2006 06:29:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JtjgNHsA6zH60iDpPK/H5d34blJFTi2wd5alU0zF1URD2RgyBH1rxTj2L6nNO7Hy85vjWWAZofznX0X+chgKyxKWMLKeUONm1GSUsOwthQZ1ppVNGnAPSiz48F3vyJ0mrQH3C6NQRE9QAfh2mLle8P4UKWqa2cnaF+qSm1Ivj+k= Received: by 10.67.121.18 with SMTP id y18mr2758409ugm.1162564189528; Fri, 03 Nov 2006 06:29:49 -0800 (PST) Received: by 10.66.243.16 with HTTP; Fri, 3 Nov 2006 06:29:49 -0800 (PST) Message-ID: Date: Fri, 3 Nov 2006 15:29:49 +0100 From: "Gerardo Giaretta" To: "Madjid Nakhjiri" Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-Reply-To: <001c01c6eca2$215232d0$2f01a8c0@huawei6cc10c70> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001c01c6eca2$215232d0$2f01a8c0@huawei6cc10c70> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Cc: mip6@ietf.org, dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Madjid, thanks for the review. Most comments are editorial and I'll fix them in next version. Just one more detailed question below. > > 5.1. General goals > > G1.1 The AAAH server and the HA MUST be able to authenticate each > other (mutual authentication) in order to prevent the installation > of unauthorized state on the HA. In some deployment scenarios, it > may not be feasible for HA and AAAH to mutually authenticate each > other. For example, let us consider the case where MSP is not the > MSA. In such a case, several AAA intermediate proxies could > forward MIP6 bootstrapping information back and forth between HA > and AAA. Thus, to prevent the installation of unauthorized state > on the HA, the path between HA and AAAH should be trustworthy>/ > > > Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing > into something that is more of a > > AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing end > point authentication and AAA > > signaling security all in one requirement. Mutual authentication of HA and > home AAA is one thing, protecting > > bootstrapping info over AAA messaging is another. This should be broken into > two requirements. I believe you > > have text on confidentiality in G1.4. The AAA signaling security issue is > that of a AAA client in visited > > AAA domain dealing with a home AAA domain are well known. for instance if > you don't like the transitive > > trust provided by the hop by hop security in RADIUS, so you need external > ways to cure the transitive trust > > problem. On the other hand providing a mutual authentication procedure > between HA and home AAA server > > without intervention of AAA intermediaries in a whole different problem. So > we need to be careful, otherwise > > we may end up ruling RADIUS out of here. Is that the intention? > > I would simply state the well known issues in the security consideration > section. > sorry but I cannot get your point clearly. which is your suggestion? Removing the requirement? Rephrasing it? Can you please provide some text? Thanks, --Gerardo > > Giaretta, et al. Expires March 16, 2007 [Page 6] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > G1.2 The AAA-HA interface MUST provide integrity protection in order > to prevent any alteration of exchanged data (e.g., Mobile IPv6 > configuration parameters). > > G1.3 The AAA-HA interface MUST provide replay protection. > > G1.4 The AAA-HA interface SHOULD provide confidentiality since it > may be used to transfer keying material (e.g., shared key > generated during EAP method authentication). > > Madjid>>same comment as that on security in G1.1. > > G1.5 The AAA-HA interface SHOULD support inactive peer detection. > This functionality can be used by the AAAH server to maintain a > list of active HAs. > > > 5.2. Service Authorization > > Madjid>>Typically authorization follows a successful authentication. It > seems that the burden of the making > > sure the MN is authenticated falls into the lap of the HA, should we not > have a requirement on this? > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > Identifier (NAI) to identify the user. > > Madjid>>I believe for the split scenario. We were saying that the > Diameter_EAP and Diameter-MIP need to use > > the same ID. does this cover that? Is NAI always the ID used for EAP? > > G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile > IPv6 service authorization for the mobile node. > > G2.3 The AAAH server MAY assign explicit operational limitations and > authorization restrictions on the HA (e.g., packet filters, QoS > parameters). > > G2.4 The AAAH server MUST be able to send an authorization lifetime > to the HA to limit Mobile IPv6 session duration for the MN. > > G2.5 The HA MUST be able to request to the AAAH server an extension > of the authorization lifetime granted to the MN. > > G2.6 The AAAH server MUST be able to force the HA to terminate an > active Mobile IPv6 session for authorization policy reasons (e.g., > credit exhaustion). > > > 5.3. Accounting > > G3.1 The AAA-HA interface MUST support the transfer of accounting > records needed for service control and charging. These include > (but may not be limited to): time of binding cache entry creation > and deletion, octets sent and received by the mobile node in bi- > directional tunneling, etc. > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 7] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > 5.4. Mobile Node Authentication > > G4.1 The AAA-HA interface MUST support pass-through EAP > authentication with the HA working as EAP authenticator operating > in pass-through mode and the AAAH server working as back-end > authentication server. > > Madjid>>Does this really have to be a MUST? > > 5.5. Provisioning of Configuration Parameters > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > Home Address allocated to the MN (e.g., for allowing the AAAH > server to perform a DNS update on behalf of the MN). > > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > authorized to autoconfigure its Home Address. > > > > 6. Goals for the Integrated Scenario > > In the integrated scenario, the AAA server provides the HA > information to the NAS as part of the whole AAA operations for > network access. Next goals are considered in addition to those > described in section Section 5. > > G6.1 The AAAH server MUST be able to communicate the Home Agent > Information (IP Address or FQDN) to the NAS. > > G6.2 The NAS SHOULD be able to notify that it supports the > functionalities described in [4]. > > G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can > allocate a Home Agent to the MN. > > G6.4 The AAA server of the MSA MUST be able to indicate to the NAS > whether the MN is authorized to use a local Home Agent (i.e. a > Home Agent in the ASP/MSP) > > > > Giaretta, et al. Expires March 16, 2007 [Page 8] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > 8. Security Considerations > > As stated in Section 5.1 the AAA-HA interface must provide mutual > authentication, integrity and replay protection. Furthermore, if > security parameters (e.g., IKE pre-shared key) are transferred > through this interface, confidentiality is strongly recommended to be > supported. However note that AAA protocols does not support this > unless it exists a direct connection between corresponding entities. > > Madjid>> Diameter supports this. should say "some AAA protocols". > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, October 03, 2006 8:13 AM > To: dime@ietf.org > Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > FYI, please review the document. > > --Gerardo > > ---------- Forwarded message ---------- > From: Basavaraj Patil > Date: Oct 3, 2006 4:49 PM > Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > To: mip6@ietf.org > > > > Hello, > > This is a Working group last call for the WG I-D: AAA Goals for Mobile > IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve > as the AAA requirements for Mobile IPv6. > > Please review the I-D and submit your comments to the authors or to > the list directly. > > The WGLC expires on Oct 18th, 06. > > The I-D is intended to be published as an Informational RFC. > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 03 09:36:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg09M-0005ip-75; Fri, 03 Nov 2006 09:36:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg04l-0003ml-0F for mip6@ietf.org; Fri, 03 Nov 2006 09:31:19 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfzuY-0004Tn-6L for mip6@ietf.org; Fri, 03 Nov 2006 09:20:53 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA3EKLe7031324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Nov 2006 06:20:21 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA3EKJod027301; Fri, 3 Nov 2006 06:20:20 -0800 (PST) Received: from sanexcas01.na.qualcomm.com ([172.30.36.175]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 06:20:18 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 06:20:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Date: Fri, 3 Nov 2006 06:20:17 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF40369ED@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Thread-Index: Acb+iTcNJd8I4UIvTiGoVA+lu7BnqwAAMpjwADDOmtAAAWeDAA== From: "Soliman, Hesham" To: "Zhang, Qiang [NTK]" , "RYUJI WAKIKAWA" , "Narayanan, Vidya" X-OriginalArrivalTime: 03 Nov 2006 14:20:19.0329 (UTC) FILETIME=[30D54710:01C6FF53] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > I would agree the MITM attack will not compromise the=20 > security provided via Ipsec ESP but rather a DoS is possible=20 > if indeed the attacker got in the routing path/redirect.=20 > Just a hypothesis that the issue can only be resolved=20 > through hop-hop security, RR will not help on the DoS, no? =3D> RR would certainly not help with DoS, it doesn't help with DoS = today. But more importantly, DoS can be done today on other protocols doing NAT traversal and even on any normal communication that doesn't involve MIP or NAT traversal. So solving it for this draft doesn't add anything to Internet security in general.=20 Hesham >=20 > Qiang > -----Original Message----- > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com]=20 > Sent: Thursday, November 02, 2006 9:22 AM > To: RYUJI WAKIKAWA; Narayanan, Vidya > Cc: mip6@ietf.org; Pascal Thubert (pthubert) > Subject: RE: What are we protecting over IPv4 in DS-MIP6?=20 > (RE: [Mip6]concensus: issue 76: Alt CoA should not=20 > beusedwhen traversingIPv4 NAT) >=20 >=20 > > RR check can be one solution, but as other people pointed=20 > out, this > causes additional round trip. > > In addition, if there is no NAT, we can simply protect=20 > CoA by ACoA > option. >=20 > =3D> This is not the issue being raised, the issue is the=20 > insecurity of the IPv4 header when a NAT exists. The outer=20 > header is obviously unprotected and vulnerable to=20 > redirection attacks (an attacker acting as a NAT bascially).=20 > I don't think we need to solve that problem as I indicated=20 > in a previous email. >=20 > Hesham >=20 >=20 >=20 > > If HA detects that the CoA is different between IPv4=20 > header > and ACoA, > it can operate your RR check. > > Otherwise, it should be skipped. > > A new message BA-ack may be sufficient. i.e. An >=20 > acknowledgment of BA > sent back from MN. > > > > ryuji > > > > On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > > > > > > All, > > > This is something I should've raised yesterday when I=20 > read all the > > emails, but after sleeping over it and=20 > some other > discussions, I'm > > still > > confused -=20 > so, figured I should raise it now :) > > > > First, I=20 > don't believe that an AltCoA option (v4 or v6) > buys anything. > > > Let's look at this. > > > > > > In IPv4, the outer IP address is always up for >=20 > modifications and there > > is no way to distinguish an=20 > adversary modifying it from a NAT > > modifying > > it.=20 > And, if the outer IPv4 source address is different from the =20 > > > inner IP > > address, there is no way for the HA to=20 > figure out whether the > > modification is due to a NAT or=20 > an adversary. Such is the > truth with > > NATs and there=20 > is nothing that can be done about it. Even > if the outer =20 > > > and inner IP addresses are the same, there is no way to =20 > > figure out > > that > > they are the same because there=20 > is no NAT or because a NAT-ed IP > > address > > in the=20 > outer header has been modified back to equal the inner IP >=20 > > address > > by an adversary. This is quite feasible,=20 > especially when the inner > > packet is not encrypted and=20 > totally depends on the intention of the > > attacker. > > > > > > The presence of the Alt-CoA option buys nothing exactly=20 > > for the same > > reasons. The fact that the Alt-CoA=20 > option is integrity > protected means > > nothing, since=20 > the HA still must use the outer IP address > as the CoA - =20 > > > and there is no guarantee about that being intact. > > > > > > We cannot pick and choose what attacks we like and what=20 > we don't. =20 > > > Either > > > we protect against redirection attacks or we don't. At =20 > > this point, I'm > > saying that integrity protection of=20 > the actual CoA alone proves > > nothing. > > > Reachability checks have more value than integrity >=20 > protection of a > > field > > that is allowed to be=20 > modified. Reachability checks too, in the > > absence > >=20 > of confidentiality on the inner packet, does not guarantee=20 > that an > > attacker is not on the path - but, it at least=20 > proves that > the MN is > > reachable at that address. > > > > > > So, my vote would be to perform an optional=20 > reachability check and > > document the vulnerability that=20 > may still exist. > > > > > > Vidya > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 03 10:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0tf-0001JL-1R; Fri, 03 Nov 2006 10:23:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg0td-0001J5-T6 for mip6@ietf.org; Fri, 03 Nov 2006 10:23:53 -0500 Received: from [2001:418:1403:0:212:17ff:fe52:7811] (helo=toshi17.tari.toshiba.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg0tY-0007it-Bo for mip6@ietf.org; Fri, 03 Nov 2006 10:23:53 -0500 Received: from localhost (toshi17.tari.toshiba.com [172.30.24.10]) by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id kA3FMu9Q065638; Fri, 3 Nov 2006 10:22:56 -0500 (EST) (envelope-from yohba@tari.toshiba.com) Date: Fri, 3 Nov 2006 10:22:53 -0500 To: Gerardo Giaretta Subject: Re: [Mip6] Comments for draft-ietf-mip6-aaa-ha-goals-03 Message-ID: <20061103152253.GA8892@steelhead> References: <4549206E.4060601@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) From: Yoshihiro Ohba X-Dispatcher: imput version 20050308(IM148) Lines: 9 X-Spam-Score: -2.4 (--) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Fri, Nov 03, 2006 at 02:51:59PM +0100, Gerardo Giaretta wrote: > > Are you suggesting to rephrase all requirements in terms of "the AAA > protocol MUST allow...". That is fine with me. What do others think? Agreed. Yoshihiro Ohba _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 03 11:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg1Se-0006SP-Fr; Fri, 03 Nov 2006 11:00:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg1Sd-0006SK-D6 for mip6@ietf.org; Fri, 03 Nov 2006 11:00:03 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg1SZ-00081Y-PT for mip6@ietf.org; Fri, 03 Nov 2006 11:00:03 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA3FxstB010780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Nov 2006 07:59:55 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA3Fxr3r029420; Fri, 3 Nov 2006 07:59:54 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Nov 2006 07:59:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Fri, 3 Nov 2006 07:59:52 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4g From: "Narayanan, Vidya" To: "RYUJI WAKIKAWA" X-OriginalArrivalTime: 03 Nov 2006 15:59:53.0260 (UTC) FILETIME=[1992CEC0:01C6FF61] X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: mip6@ietf.org, "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Ryuji, I think this is missing the threat model. Let's look at two possible scenarios.=20 1. MN --- (Attacker) --- HA 2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA ( ) indicates that an attacker may be present.=20 If the HA received a BU with the inner and outer addresses the same, it has no way of telling it was due to case 1 with no attacker or case 2 with Attacker 2 who changed a NAT'ed outer address back to equal the inner address.=20 So, there is no use in saying that the check is done when the HA detects a NAT.=20 But, we can document this issue and say that we don't protect against on-path attackers in IPv4, because it is complicated and not worth it. I guess that's what Vijay and Hesham are saying - I could be convinced of that, although, I don't see why we can't make the RR optional and leave it at that.=20 Vidya > -----Original Message----- > From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com]=20 > Sent: Thursday, November 02, 2006 6:07 AM > To: Narayanan, Vidya > Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert=20 > (pthubert); Soliman, Hesham > Subject: Re: What are we protecting over IPv4 in DS-MIP6?=20 > (RE: [Mip6] concensus: issue 76: Alt CoA should not be=20 > usedwhen traversingIPv4 NAT) >=20 > Hi Vidya >=20 > RR check can be one solution, but as other people pointed=20 > out, this causes additional round trip. > In addition, if there is no NAT, we can simply protect CoA by=20 > ACoA option. > If HA detects that the CoA is different between IPv4 header=20 > and ACoA, it can operate your RR check. > Otherwise, it should be skipped. > A new message BA-ack may be sufficient. i.e. An=20 > acknowledgment of BA sent back from MN. >=20 > ryuji >=20 > On 2006/11/02, at 4:08, Narayanan, Vidya wrote: >=20 > > > > All, > > This is something I should've raised yesterday when I read all the=20 > > emails, but after sleeping over it and some other discussions, I'm=20 > > still confused - so, figured I should raise it now :) > > > > First, I don't believe that an AltCoA option (v4 or v6)=20 > buys anything. > > Let's look at this. > > > > In IPv4, the outer IP address is always up for=20 > modifications and there=20 > > is no way to distinguish an adversary modifying it from a NAT=20 > > modifying it. And, if the outer IPv4 source address is=20 > different from=20 > > the inner IP address, there is no way for the HA to figure=20 > out whether=20 > > the modification is due to a NAT or an adversary. Such is the truth=20 > > with NATs and there is nothing that can be done about it.=20 > Even if the=20 > > outer and inner IP addresses are the same, there is no way=20 > to figure=20 > > out that they are the same because there is no NAT or=20 > because a NAT-ed=20 > > IP address in the outer header has been modified back to equal the=20 > > inner IP address by an adversary. This is quite feasible,=20 > especially=20 > > when the inner packet is not encrypted and totally depends on the=20 > > intention of the attacker. > > > > The presence of the Alt-CoA option buys nothing exactly for=20 > the same=20 > > reasons. The fact that the Alt-CoA option is integrity=20 > protected means=20 > > nothing, since the HA still must use the outer IP address=20 > as the CoA -=20 > > and there is no guarantee about that being intact. > > > > We cannot pick and choose what attacks we like and what we don't. =20 > > Either > > we protect against redirection attacks or we don't. At this=20 > point, I'm=20 > > saying that integrity protection of the actual CoA alone proves=20 > > nothing. > > Reachability checks have more value than integrity protection of a=20 > > field that is allowed to be modified. Reachability checks=20 > too, in the=20 > > absence of confidentiality on the inner packet, does not guarantee=20 > > that an attacker is not on the path - but, it at least=20 > proves that the=20 > > MN is reachable at that address. > > > > So, my vote would be to perform an optional reachability check and=20 > > document the vulnerability that may still exist. > > > > Vidya > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 13:16:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQ3D-0007oc-1a; Sat, 04 Nov 2006 13:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQ3B-0007mx-Nx; Sat, 04 Nov 2006 13:15:25 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgQ3A-0004Sa-Et; Sat, 04 Nov 2006 13:15:25 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-1.cisco.com with ESMTP; 04 Nov 2006 10:15:24 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="754773795:sNHT47107000" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA4IFNFA009175; Sat, 4 Nov 2006 10:15:23 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id kA4IFMOW008542; Sat, 4 Nov 2006 10:15:23 -0800 (PST) Date: Sat, 4 Nov 2006 10:15:22 -0800 (PST) From: Sri Gundavelli To: Julien Laganier In-Reply-To: <200611041705.55706.julien.IETF@laposte.net> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com> <200611041705.55706.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=933; t=1162664123; x=1163528123; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:Sri=20Gundavelli=20 |Subject:Re=3A=20[netlmm]=20Re=3A=20Why=20is=20PMIP=20a=20superior=20solution=20f or=20NETLMMrequireiments?; X=v=3Dcisco.com=3B=20h=3DOUhZa3bekLxEHDY5+wZoQxrMonc=3D; b=Mkzlwq5ANIb+7IgOPHvxD9frPYky1hRM42Myg/mAHkX9E0V9niHsBKkNz04kGmaj4d8wsnRd YNboy/6I1rKt39avO9kNxQIDUtPUFBIqwlX9KDsGgQZYeR8VttZJY6ag; Authentication-Results: sj-dkim-7.cisco.com; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Sat, 4 Nov 2006, Julien Laganier wrote: >> To me proxy/relay >> DAD is not a trivial function. Its quite a bit of >> work to implement that. The home agent code will >> bloat significantly to get that in place. IMHO. > > From my experience proxy/relay DAD is trivial to > implement. > Hi Julien, Trivial or complex, my word against your word. The point is that pmip does not need this function, in the per-mn-prefix mode of operation. Simplifies the implementation to certain extent. I was comparing the implementation complexity between the two addressing modes. This meets the pmip design goals of leveraging the MIPv6 infrastructure, signalling and with "minimal" changes to the Home Agent. I relate this mode to the NEMO's MNP allocation in the explicit mode, to show minimal HA's involvment in cases where a prefix follows the mobile. Regards Sri PS: Moving the thread to the MIP6 ML. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 13:24:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQBN-00081i-O3; Sat, 04 Nov 2006 13:23:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQBM-00081Q-AJ for mip6@ietf.org; Sat, 04 Nov 2006 13:23:52 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgQBM-0005kF-7u for mip6@ietf.org; Sat, 04 Nov 2006 13:23:52 -0500 Received: from py-out-1112.google.com ([64.233.166.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GgQBK-0005ui-Qc for mip6@ietf.org; Sat, 04 Nov 2006 13:23:52 -0500 Received: by py-out-1112.google.com with SMTP id d32so557751pye for ; Sat, 04 Nov 2006 10:22:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Dyizgj+JmIaXZsvwDIMsvY5LvJSbl+LEvmrVc3brMyIbKjWZ0c/1m4sIsbOYNrKdU/wymBJf/EaLx7GmaHoDM2OBLveN1idVv7fYP5X51bs/u4SJkwmkwHCddGjoFdTrC7N3HStfGTo5TdjRkP+sByJ4FvCAQ+HT3yBHpDfJcFk= Received: by 10.35.66.1 with SMTP id t1mr6224852pyk.1162664570240; Sat, 04 Nov 2006 10:22:50 -0800 (PST) Received: from ?198.18.100.75? ( [68.164.47.60]) by mx.google.com with ESMTP id 20sm9249458nzp.2006.11.04.10.22.49; Sat, 04 Nov 2006 10:22:49 -0800 (PST) From: Julien Laganier To: Sri Gundavelli Date: Sat, 4 Nov 2006 10:22:25 -0800 User-Agent: KMail/1.8.2 References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com> <200611041705.55706.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611041022.26090.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, On Saturday 04 November 2006 10:15, Sri Gundavelli wrote: > On Sat, 4 Nov 2006, Julien Laganier wrote: > >> To me proxy/relay > >> DAD is not a trivial function. Its quite a bit of > >> work to implement that. The home agent code will > >> bloat significantly to get that in place. IMHO. > > > > From my experience proxy/relay DAD is trivial to > > implement. > > Trivial or complex, my word against your word. Fair enough. > The point is that pmip does not need this function, > in the per-mn-prefix mode of operation. The function isn't required to avoid duplicates of global addresses (since each MN has a different prefix for its global addresses.) But what about avoidance of link-locals addresses duplicates (e.g. with the AR, or with another MN when shared links are used.) ? How do you do that if you do not relay/proxy DAD across the domain when a collision occurs? > Simplifies the implementation to certain extent. I > was comparing the implementation complexity between > the two addressing modes. I'd agree about the simplification if the function wasn't required, but I think it is (see above) Best, --julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 13:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQZH-00054t-H2; Sat, 04 Nov 2006 13:48:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgQZF-00054Y-O1; Sat, 04 Nov 2006 13:48:33 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgQZE-0001Oo-E0; Sat, 04 Nov 2006 13:48:33 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-6.cisco.com with ESMTP; 04 Nov 2006 10:48:27 -0800 X-IronPort-AV: i="4.09,387,1157353200"; d="scan'208"; a="85514459:sNHT48970863" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA4ImRo3014743; Sat, 4 Nov 2006 10:48:27 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA4ImIbG022475; Sat, 4 Nov 2006 10:48:27 -0800 (PST) Date: Sat, 4 Nov 2006 10:48:18 -0800 (PST) From: Sri Gundavelli To: Julien Laganier In-Reply-To: <200611041022.26090.julien.IETF@laposte.net> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com> <200611041705.55706.julien.IETF@laposte.net> <200611041022.26090.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1965; t=1162666107; x=1163530107; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:Sri=20Gundavelli=20 |Subject:Re=3A=20[netlmm]=20Re=3A=20Why=20is=20PMIP=20a=20superior=20solution=20f or=20NETLMMrequireiments?; X=v=3Dcisco.com=3B=20h=3DOUhZa3bekLxEHDY5+wZoQxrMonc=3D; b=qu0Z1lyejEKygElKkXyVVjV54zxYVdD7/XqWXMgEYWH06LDai7Sj8OCYjzzEAnyIgxhZ537P lwsj3IHWHnYpQgFqbUXY2EV3zkD7LMUUNjfGatmcp6wZs0Zr6t09BDOb; Authentication-Results: sj-dkim-7.cisco.com; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Julien, On Sat, 4 Nov 2006, Julien Laganier wrote: > Hi Sri, > > On Saturday 04 November 2006 10:15, Sri Gundavelli > wrote: >> On Sat, 4 Nov 2006, Julien Laganier wrote: >>>> To me proxy/relay >>>> DAD is not a trivial function. Its quite a bit of >>>> work to implement that. The home agent code will >>>> bloat significantly to get that in place. IMHO. >>> >>> From my experience proxy/relay DAD is trivial to >>> implement. >> >> Trivial or complex, my word against your word. > > Fair enough. > >> The point is that pmip does not need this function, >> in the per-mn-prefix mode of operation. > > The function isn't required to avoid duplicates of > global addresses (since each MN has a different prefix > for its global addresses.) > Hi Julien, Even for the link-local address duplicate detection, in the given shared link scenario, the resolution happens on that access link and all the visiting nodes on that link can do the resolution with out the need for the messages to go beyond the link. Lets assume host "A" and "B" are using the same LLA: FE80::2AA:FF:FE22:2222 and both will register for the corresponding solicited-node multicast address FF02::1:FF22:2222. The link is not a split link and LLA uniqueness have to be to contained to that link. Why do I need across domain resolution or DAD or Relay-DAD ? The link/prefix is following the mobile. Regards Sri > But what about avoidance of link-locals addresses > duplicates (e.g. with the AR, or with another MN when > shared links are used.) ? How do you do that if you do > not relay/proxy DAD across the domain when a collision > occurs? > >> Simplifies the implementation to certain extent. I >> was comparing the implementation complexity between >> the two addressing modes. > > I'd agree about the simplification if the function > wasn't required, but I think it is (see above) > > Best, > > --julien > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 17:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgTnF-0004ZW-43; Sat, 04 Nov 2006 17:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgTnD-0004ZJ-Nr; Sat, 04 Nov 2006 17:15:11 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgTnD-0006Bd-5V; Sat, 04 Nov 2006 17:15:11 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8800HBS8C36R@usaga01-in.huawei.com>; Sat, 04 Nov 2006 14:12:03 -0800 (PST) Received: from N737011 ([10.192.25.84]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J88002248BYSP@usaga01-in.huawei.com>; Sat, 04 Nov 2006 14:12:03 -0800 (PST) Date: Sat, 04 Nov 2006 14:15:02 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-reply-to: To: 'Gerardo Giaretta' Message-id: <001401c7005e$ac712310$5419c00a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: Acb/VStGDKC68u7AQ+2UxwfvSqUwGwBAsp1w X-Spam-Score: 0.0 (/) X-Scan-Signature: 918f4bd8440e8de4700bcf6d658bc801 Cc: mip6@ietf.org, dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The doc calls itself AAA-HA goals, so We need to see what we need to accomplish by the document 1) define AAA function requirements on HA and on HA-AAA server protocol? 2) what is vendor required to put inside MIP6 HA to support AAA interaction. If the goal is 1) and you are not careful, you can unintentionally rule out RADIUS. Plus some of the requirements are beyond the scope of those for AAA client (HA) and AAA protocols. I am just pointing out that unless trying to set up a set of goals for the Dime drafts, we need to be careful about the side-effect of ruling out use of RADIUS for MIP6. Let me go through the goal > G1.1 The AAAH server and the HA MUST be able to authenticate each > other (mutual authentication) in order to prevent the installation > of unauthorized state on the HA. In some deployment scenarios, it > may not be feasible for HA and AAAH to mutually authenticate each > other. For example, let us consider the case where MSP is not the > MSA. In such a case, several AAA intermediate proxies could > forward MIP6 bootstrapping information back and forth between HA > and AAA. Thus, to prevent the installation of unauthorized state > on the HA, the path between HA and AAAH should be trustworthy>/ > Madjid>>I am going to assume HA is AAA client, not sure, if authentication between a AAA client and a AAA is an explicit requirement in any of the AAA protocols. First it means a direct SA between the HA and AAAH. If there are proxies on the AAA path, RADIUS for one does not support the end to end SA directly, let alone the act of end to end authentication. I understand that sending keys from AAAH to HA requires tight security, but this is not a "AAA requirement", since it may not be covered by some AAA protocols, it is part of security provisioning for the entire HA design. You may want to bring this up in "security consideration section". You already seem to have this part of security consideration, so not sure why it is also mentioned as AAA-HA goal, unless the goal of the doc is the (2) mentioned above. I hope I have been helpful. R, Madjid -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Friday, November 03, 2006 6:30 AM To: Madjid Nakhjiri Cc: dime@ietf.org; mip6@ietf.org; Julien Bournelle Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 Hi Madjid, thanks for the review. Most comments are editorial and I'll fix them in next version. Just one more detailed question below. > > 5.1. General goals > > G1.1 The AAAH server and the HA MUST be able to authenticate each > other (mutual authentication) in order to prevent the installation > of unauthorized state on the HA. In some deployment scenarios, it > may not be feasible for HA and AAAH to mutually authenticate each > other. For example, let us consider the case where MSP is not the > MSA. In such a case, several AAA intermediate proxies could > forward MIP6 bootstrapping information back and forth between HA > and AAA. Thus, to prevent the installation of unauthorized state > on the HA, the path between HA and AAAH should be trustworthy>/ > > > Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing > into something that is more of a > > AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing end > point authentication and AAA > > signaling security all in one requirement. Mutual authentication of HA and > home AAA is one thing, protecting > > bootstrapping info over AAA messaging is another. This should be broken into > two requirements. I believe you > > have text on confidentiality in G1.4. The AAA signaling security issue is > that of a AAA client in visited > > AAA domain dealing with a home AAA domain are well known. for instance if > you don't like the transitive > > trust provided by the hop by hop security in RADIUS, so you need external > ways to cure the transitive trust > > problem. On the other hand providing a mutual authentication procedure > between HA and home AAA server > > without intervention of AAA intermediaries in a whole different problem. So > we need to be careful, otherwise > > we may end up ruling RADIUS out of here. Is that the intention? > > I would simply state the well known issues in the security consideration > section. > sorry but I cannot get your point clearly. which is your suggestion? Removing the requirement? Rephrasing it? Can you please provide some text? Thanks, --Gerardo > > Giaretta, et al. Expires March 16, 2007 [Page 6] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > G1.2 The AAA-HA interface MUST provide integrity protection in order > to prevent any alteration of exchanged data (e.g., Mobile IPv6 > configuration parameters). > > G1.3 The AAA-HA interface MUST provide replay protection. > > G1.4 The AAA-HA interface SHOULD provide confidentiality since it > may be used to transfer keying material (e.g., shared key > generated during EAP method authentication). > > Madjid>>same comment as that on security in G1.1. > > G1.5 The AAA-HA interface SHOULD support inactive peer detection. > This functionality can be used by the AAAH server to maintain a > list of active HAs. > > > 5.2. Service Authorization > > Madjid>>Typically authorization follows a successful authentication. It > seems that the burden of the making > > sure the MN is authenticated falls into the lap of the HA, should we not > have a requirement on this? > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > Identifier (NAI) to identify the user. > > Madjid>>I believe for the split scenario. We were saying that the > Diameter_EAP and Diameter-MIP need to use > > the same ID. does this cover that? Is NAI always the ID used for EAP? > > G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile > IPv6 service authorization for the mobile node. > > G2.3 The AAAH server MAY assign explicit operational limitations and > authorization restrictions on the HA (e.g., packet filters, QoS > parameters). > > G2.4 The AAAH server MUST be able to send an authorization lifetime > to the HA to limit Mobile IPv6 session duration for the MN. > > G2.5 The HA MUST be able to request to the AAAH server an extension > of the authorization lifetime granted to the MN. > > G2.6 The AAAH server MUST be able to force the HA to terminate an > active Mobile IPv6 session for authorization policy reasons (e.g., > credit exhaustion). > > > 5.3. Accounting > > G3.1 The AAA-HA interface MUST support the transfer of accounting > records needed for service control and charging. These include > (but may not be limited to): time of binding cache entry creation > and deletion, octets sent and received by the mobile node in bi- > directional tunneling, etc. > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 7] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > 5.4. Mobile Node Authentication > > G4.1 The AAA-HA interface MUST support pass-through EAP > authentication with the HA working as EAP authenticator operating > in pass-through mode and the AAAH server working as back-end > authentication server. > > Madjid>>Does this really have to be a MUST? > > 5.5. Provisioning of Configuration Parameters > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > Home Address allocated to the MN (e.g., for allowing the AAAH > server to perform a DNS update on behalf of the MN). > > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > authorized to autoconfigure its Home Address. > > > > 6. Goals for the Integrated Scenario > > In the integrated scenario, the AAA server provides the HA > information to the NAS as part of the whole AAA operations for > network access. Next goals are considered in addition to those > described in section Section 5. > > G6.1 The AAAH server MUST be able to communicate the Home Agent > Information (IP Address or FQDN) to the NAS. > > G6.2 The NAS SHOULD be able to notify that it supports the > functionalities described in [4]. > > G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can > allocate a Home Agent to the MN. > > G6.4 The AAA server of the MSA MUST be able to indicate to the NAS > whether the MN is authorized to use a local Home Agent (i.e. a > Home Agent in the ASP/MSP) > > > > Giaretta, et al. Expires March 16, 2007 [Page 8] > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > 8. Security Considerations > > As stated in Section 5.1 the AAA-HA interface must provide mutual > authentication, integrity and replay protection. Furthermore, if > security parameters (e.g., IKE pre-shared key) are transferred > through this interface, confidentiality is strongly recommended to be > supported. However note that AAA protocols does not support this > unless it exists a direct connection between corresponding entities. > > Madjid>> Diameter supports this. should say "some AAA protocols". > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, October 03, 2006 8:13 AM > To: dime@ietf.org > Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > FYI, please review the document. > > --Gerardo > > ---------- Forwarded message ---------- > From: Basavaraj Patil > Date: Oct 3, 2006 4:49 PM > Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > To: mip6@ietf.org > > > > Hello, > > This is a Working group last call for the WG I-D: AAA Goals for Mobile > IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve > as the AAA requirements for Mobile IPv6. > > Please review the I-D and submit your comments to the authors or to > the list directly. > > The WGLC expires on Oct 18th, 06. > > The I-D is intended to be published as an Informational RFC. > > -Raj > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 19:23:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVmw-0003ro-Ry; Sat, 04 Nov 2006 19:23:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVmv-0003rV-9c for mip6@ietf.org; Sat, 04 Nov 2006 19:23:01 -0500 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgVmt-0004Gq-Un for mip6@ietf.org; Sat, 04 Nov 2006 19:23:01 -0500 Received: by py-out-1112.google.com with SMTP id d32so608061pye for ; Sat, 04 Nov 2006 16:22:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=kkj4kuibZvySGSPzHpU024AYtVE1PASUmR6izHe0NwV/o02oWPYUeP5kHB0OiadZSI/felGJuoanOd6RZfn7LZx6C5fVVYmkgvhZROoi5NoN2Ic7Gd+Omt1oXaQK2x0on1+dcbNOfSi1r+7vneGL2Im9xEjWycDCrBcctP82wl8= Received: by 10.35.112.3 with SMTP id p3mr6761845pym.1162686143894; Sat, 04 Nov 2006 16:22:23 -0800 (PST) Received: from ?198.18.100.75? ( [68.164.47.60]) by mx.google.com with ESMTP id f75sm2869633pye.2006.11.04.16.22.23; Sat, 04 Nov 2006 16:22:23 -0800 (PST) From: Julien Laganier To: Sri Gundavelli Date: Sat, 4 Nov 2006 16:21:59 -0800 User-Agent: KMail/1.8.2 References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com> <200611041022.26090.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611041621.59661.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Saturday 04 November 2006 10:48, Sri Gundavelli wrote: > Hi Julien, > > On Sat, 4 Nov 2006, Julien Laganier wrote: > > Hi Sri, > > > > On Saturday 04 November 2006 10:15, Sri Gundavelli > > > > wrote: > >> On Sat, 4 Nov 2006, Julien Laganier wrote: > >>>> To me proxy/relay > >>>> DAD is not a trivial function. Its quite a bit > >>>> of work to implement that. The home agent code > >>>> will bloat significantly to get that in place. > >>>> IMHO. > >>> > >>> From my experience proxy/relay DAD is trivial to > >>> implement. > >> > >> Trivial or complex, my word against your word. > > > > Fair enough. > > > >> The point is that pmip does not need this > >> function, in the per-mn-prefix mode of operation. > > > > The function isn't required to avoid duplicates of > > global addresses (since each MN has a different > > prefix for its global addresses.) > > Hi Julien, > > Even for the link-local address duplicate detection, > in the given shared link scenario, the resolution > happens on that access link and all the visiting > nodes on that link can do the resolution with out > the need for the messages to go beyond the link. Just to make sure: I did not say that address resolution should occur across links, only that DAD traffic should be relayed across link *when* a collision occurs. > Lets assume host "A" and "B" are using the same > LLA: FE80::2AA:FF:FE22:2222 and both will register > for the corresponding solicited-node multicast > address FF02::1:FF22:2222. The link is not a split > link and LLA uniqueness have to be to contained to > that link. Why do I need across domain resolution > or DAD or Relay-DAD ? [again I am not saying that we should have domain-wide address resolution] Let's take the following example: one host H and two access routers AR1 and AR2 on two different links (link1 and link2). H is attached to AR1. Suppose that H and AR2 happens to configure the same link-local address. H will do DAD on link1 and won't detect a collision, AR2 will do DAD on link2 and won't detect a collision. Now what happens if H moves to link2: there's a collision of link local addresses of H and AR2. That can be avoided by relaying/proxying DAD messages *when* a collision occurs (the anchor point knows when.) --julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 19:33:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVwa-00064V-76; Sat, 04 Nov 2006 19:33:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgVwY-000648-SH for mip6@ietf.org; Sat, 04 Nov 2006 19:32:58 -0500 Received: from py-out-1112.google.com ([64.233.166.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgVwX-0005hU-Ir for mip6@ietf.org; Sat, 04 Nov 2006 19:32:58 -0500 Received: by py-out-1112.google.com with SMTP id d32so609421pye for ; Sat, 04 Nov 2006 16:32:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=kkj4kuibZvySGSPzHpU024AYtVE1PASUmR6izHe0NwV/o02oWPYUeP5kHB0OiadZSI/felGJuoanOd6RZfn7LZx6C5fVVYmkgvhZROoi5NoN2Ic7Gd+Omt1oXaQK2x0on1+dcbNOfSi1r+7vneGL2Im9xEjWycDCrBcctP82wl8= Received: by 10.35.112.3 with SMTP id p3mr6761845pym.1162686143894; Sat, 04 Nov 2006 16:22:23 -0800 (PST) Received: from ?198.18.100.75? ( [68.164.47.60]) by mx.google.com with ESMTP id f75sm2869633pye.2006.11.04.16.22.23; Sat, 04 Nov 2006 16:22:23 -0800 (PST) From: Julien Laganier To: Sri Gundavelli Date: Sat, 4 Nov 2006 16:21:59 -0800 User-Agent: KMail/1.8.2 References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com> <200611041022.26090.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611041621.59661.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Saturday 04 November 2006 10:48, Sri Gundavelli wrote: > Hi Julien, > > On Sat, 4 Nov 2006, Julien Laganier wrote: > > Hi Sri, > > > > On Saturday 04 November 2006 10:15, Sri Gundavelli > > > > wrote: > >> On Sat, 4 Nov 2006, Julien Laganier wrote: > >>>> To me proxy/relay > >>>> DAD is not a trivial function. Its quite a bit > >>>> of work to implement that. The home agent code > >>>> will bloat significantly to get that in place. > >>>> IMHO. > >>> > >>> From my experience proxy/relay DAD is trivial to > >>> implement. > >> > >> Trivial or complex, my word against your word. > > > > Fair enough. > > > >> The point is that pmip does not need this > >> function, in the per-mn-prefix mode of operation. > > > > The function isn't required to avoid duplicates of > > global addresses (since each MN has a different > > prefix for its global addresses.) > > Hi Julien, > > Even for the link-local address duplicate detection, > in the given shared link scenario, the resolution > happens on that access link and all the visiting > nodes on that link can do the resolution with out > the need for the messages to go beyond the link. Just to make sure: I did not say that address resolution should occur across links, only that DAD traffic should be relayed across link *when* a collision occurs. > Lets assume host "A" and "B" are using the same > LLA: FE80::2AA:FF:FE22:2222 and both will register > for the corresponding solicited-node multicast > address FF02::1:FF22:2222. The link is not a split > link and LLA uniqueness have to be to contained to > that link. Why do I need across domain resolution > or DAD or Relay-DAD ? [again I am not saying that we should have domain-wide address resolution] Let's take the following example: one host H and two access routers AR1 and AR2 on two different links (link1 and link2). H is attached to AR1. Suppose that H and AR2 happens to configure the same link-local address. H will do DAD on link1 and won't detect a collision, AR2 will do DAD on link2 and won't detect a collision. Now what happens if H moves to link2: there's a collision of link local addresses of H and AR2. That can be avoided by relaying/proxying DAD messages *when* a collision occurs (the anchor point knows when.) --julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 19:47:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgWAO-0008IO-4H; Sat, 04 Nov 2006 19:47:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgWAM-0008E6-2F; Sat, 04 Nov 2006 19:47:14 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgWAK-0007hz-Ny; Sat, 04 Nov 2006 19:47:14 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 04 Nov 2006 16:47:10 -0800 X-IronPort-AV: i="4.09,388,1157353200"; d="scan'208"; a="85613423:sNHT49585158" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA50l9NT005410; Sat, 4 Nov 2006 16:47:09 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA50l9Ap015216; Sat, 4 Nov 2006 16:47:09 -0800 (PST) Date: Sat, 4 Nov 2006 16:47:09 -0800 (PST) From: Sri Gundavelli To: Julien Laganier In-Reply-To: <200611041621.59661.julien.IETF@laposte.net> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com> <200611041022.26090.julien.IETF@laposte.net> <200611041621.59661.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2150; t=1162687630; x=1163551630; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:Sri=20Gundavelli=20 |Subject:Re=3A=20[netlmm]=20Re=3A=20Why=20is=20PMIP=20a=20superior=20solution=20f or=20NETLMMrequireiments?; X=v=3Dcisco.com=3B=20h=3DOUhZa3bekLxEHDY5+wZoQxrMonc=3D; b=q4RxV+s95AXZDrSQVD8fVetvBYPPdZ4bOVLKDSAti9qAQVDqgXDz+qX/zOotkckKe3D93T0c 4jrGSt/u2OsXs1UUEq1vhvJkKS2i2NUCdx5lIB5uRsmY9NvyyaPy2wcg; Authentication-Results: sj-dkim-4.cisco.com; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Julien, Please see inline .. On Sat, 4 Nov 2006, Julien Laganier wrote: >> Hi Julien, >> >> Even for the link-local address duplicate detection, >> in the given shared link scenario, the resolution >> happens on that access link and all the visiting >> nodes on that link can do the resolution with out >> the need for the messages to go beyond the link. > > Just to make sure: I did not say that address > resolution should occur across links, only that DAD > traffic should be relayed across link *when* a > collision occurs. > >> Lets assume host "A" and "B" are using the same >> LLA: FE80::2AA:FF:FE22:2222 and both will register >> for the corresponding solicited-node multicast >> address FF02::1:FF22:2222. The link is not a split >> link and LLA uniqueness have to be to contained to >> that link. Why do I need across domain resolution >> or DAD or Relay-DAD ? > > [again I am not saying that we should have domain-wide > address resolution] > > Let's take the following example: one host H and two > access routers AR1 and AR2 on two different links > (link1 and link2). H is attached to AR1. > > Suppose that H and AR2 happens to configure the same > link-local address. H will do DAD on link1 and won't > detect a collision, AR2 will do DAD on link2 and won't > detect a collision. > > Now what happens if H moves to link2: there's a > collision of link local addresses of H and AR2. > When H moves to link2, it will do a DAD on that link and detect the collision. The collision is very much on that link and will be detected right after the host H moves to that link and starts the address configuration. The collision is on the link, why do these messages need to go out of the link ? Why do we need Proxy or Relay DAD ? Why is this scenario any special ? This is a normal IPv6 DAD scenario and ND will very much take care of that. Again, this is not a split link, we are not bridging traffic between links in this case. Regards Sri > That can be avoided by relaying/proxying DAD messages > *when* a collision occurs (the anchor point knows > when.) > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 20:15:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgWb2-0006ng-OH; Sat, 04 Nov 2006 20:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgWb1-0006ke-3c for mip6@ietf.org; Sat, 04 Nov 2006 20:14:47 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgWaz-0003HA-Mq for mip6@ietf.org; Sat, 04 Nov 2006 20:14:47 -0500 Received: by ug-out-1314.google.com with SMTP id 72so564948ugd for ; Sat, 04 Nov 2006 17:14:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=N1Q4mRgJRrzg8HGo/5txlK8xtyYIsnKbFyTLZjLMRSV+NG8/JLfHUGs4LLaIySmQShFjTRa6cstmWSDxBUwt/46QgDD3rU7L3GMBKO7k8UDD7b09morPrvCNGUNrpHbSOffd6tB6Q9NBZMXA2owp0uQwJwEKZkjt2uomAYSGbX8= Received: by 10.67.117.2 with SMTP id u2mr5006450ugm.1162689284573; Sat, 04 Nov 2006 17:14:44 -0800 (PST) Received: from ?198.18.100.75? ( [68.164.47.60]) by mx.google.com with ESMTP id c1sm2722946ugf.2006.11.04.17.14.42; Sat, 04 Nov 2006 17:14:44 -0800 (PST) From: Julien Laganier To: Sri Gundavelli Date: Sat, 4 Nov 2006 17:14:17 -0800 User-Agent: KMail/1.8.2 References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com> <200611041621.59661.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611041714.17857.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, Please find my answer inlined below: On Saturday 04 November 2006 16:47, Sri Gundavelli wrote: > > On Sat, 4 Nov 2006, Julien Laganier wrote: > >> > >> Even for the link-local address duplicate > >> detection, in the given shared link scenario, the > >> resolution happens on that access link and all > >> the visiting nodes on that link can do the > >> resolution with out the need for the messages to > >> go beyond the link. > > > > Just to make sure: I did not say that address > > resolution should occur across links, only that > > DAD traffic should be relayed across link *when* a > > collision occurs. > > > >> Lets assume host "A" and "B" are using the same > >> LLA: FE80::2AA:FF:FE22:2222 and both will > >> register for the corresponding solicited-node > >> multicast address FF02::1:FF22:2222. The link is > >> not a split link and LLA uniqueness have to be to > >> contained to that link. Why do I need across > >> domain resolution or DAD or Relay-DAD ? > > > > [again I am not saying that we should have > > domain-wide address resolution] > > > > Let's take the following example: one host H and > > two access routers AR1 and AR2 on two different > > links (link1 and link2). H is attached to AR1. > > > > Suppose that H and AR2 happens to configure the > > same link-local address. H will do DAD on link1 > > and won't detect a collision, AR2 will do DAD on > > link2 and won't detect a collision. > > > > Now what happens if H moves to link2: there's a > > collision of link local addresses of H and AR2. > > When H moves to link2, it will do a DAD on that > link and detect the collision. I was assuming that the host implements DNAv6. Under that scenario, when the host get a Link_up indication, it will sollicit a router by sending an RS, and receive from the new router a RA with the same prefix, thus making it believe that it did not change link (I am intentionally omitting the subtleties of DNA link change determination, e.g. the use of a landmark prefix) The default behavior for a host would then to not redo DAD, and hence not detect the collision. (The host might however be forced to redo DAD even though DNA determined that the link did not changed if DNASameLinkDADFlag is set to True) > The collision is > very much on that link and will be detected right > after the host H moves to that link and starts > the address configuration. See above -- It won't be detected by a DNA node with default configuration. > The collision is on the link, why do these messages > need to go out of the link ? Why do we need Proxy > or Relay DAD ? Why is this scenario any special ? This scenario is special because you are hiding the change of network prefix from one AR to another, thus hiding the link change to DNA, which in effect disable DAD upon link change in the same domain. > This is a normal IPv6 DAD scenario and ND will very > much take care of that. See above. > Again, this is not a split link, we are not bridging > traffic between links in this case. Again, and just to be sure, I never talked about split link or IP-layer bridging across different links. Best, --julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 20:48:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgX7g-0000i4-M4; Sat, 04 Nov 2006 20:48:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgX7f-0000hm-5E; Sat, 04 Nov 2006 20:48:31 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgX7c-0004Rb-QY; Sat, 04 Nov 2006 20:48:31 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 04 Nov 2006 17:48:28 -0800 X-IronPort-AV: i="4.09,388,1157353200"; d="scan'208"; a="339536661:sNHT51652836" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA51mSaw031122; Sat, 4 Nov 2006 17:48:28 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA51mRW5007068; Sat, 4 Nov 2006 17:48:27 -0800 (PST) Date: Sat, 4 Nov 2006 17:48:26 -0800 (PST) From: Sri Gundavelli To: Julien Laganier In-Reply-To: <200611041714.17857.julien.IETF@laposte.net> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com> <200611041621.59661.julien.IETF@laposte.net> <200611041714.17857.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=2346; t=1162691308; x=1163555308; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:Sri=20Gundavelli=20 |Subject:Re=3A=20[netlmm]=20Re=3A=20Why=20is=20PMIP=20a=20superior=20solution=20f or=20NETLMMrequireiments?; X=v=3Dcisco.com=3B=20h=3DOUhZa3bekLxEHDY5+wZoQxrMonc=3D; b=h7cJ8sKlHWd0twP7AS1kOGzcsOGVg1AwhjTEhFPoO4yrDtb3Zi5X0QTUUy5uTLrStJ5Iktkz 8o9vVIXhvCk7M+pyPm+HLH/kCttTrbBuQsrESMaRaZKVZ1SXoeZjdoQ1; Authentication-Results: sj-dkim-1.cisco.com; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Julien, On Sat, 4 Nov 2006, Julien Laganier wrote: > Hi Sri, > > Please find my answer inlined below: > > > I was assuming that the host implements DNAv6. Under > that scenario, when the host get a Link_up indication, > it will sollicit a router by sending an RS, and > receive from the new router a RA with the same prefix, > thus making it believe that it did not change link (I > am intentionally omitting the subtleties of DNA link > change determination, e.g. the use of a landmark > prefix) > > The default behavior for a host would then to not redo > DAD, and hence not detect the collision. (The host > might however be forced to redo DAD even though DNA > determined that the link did not changed if > DNASameLinkDADFlag is set to True) > PMIP did not make any assumption with respect to the node's capability of DNAv6, DNAv6 is still a draft. A native IPv6 host will certainly do a DAD after detecting a link flap and there is no question of DAD not getting triggered there. Now, with the new DNAv6 draft(s), assuming they get standardised and get into the IPv6 host stack, its a config option as you have pointed out, that will force the host to do DAD after link flap and still detecting the same-link with out having a need for pre-establishing LLA uniqueness across the domain. Thanks for the discussion. Regards Sri >> The collision is >> very much on that link and will be detected right >> after the host H moves to that link and starts >> the address configuration. > > See above -- It won't be detected by a DNA node with > default configuration. > >> The collision is on the link, why do these messages >> need to go out of the link ? Why do we need Proxy >> or Relay DAD ? Why is this scenario any special ? > > This scenario is special because you are hiding the > change of network prefix from one AR to another, thus > hiding the link change to DNA, which in effect disable > DAD upon link change in the same domain. > >> This is a normal IPv6 DAD scenario and ND will very >> much take care of that. > > See above. > >> Again, this is not a split link, we are not bridging >> traffic between links in this case. > > Again, and just to be sure, I never talked about split > link or IP-layer bridging across different links. > Ok. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 22:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgYoj-0000AN-3e; Sat, 04 Nov 2006 22:37:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgYoi-0000AA-AK for mip6@ietf.org; Sat, 04 Nov 2006 22:37:04 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgYog-0002k2-RH for mip6@ietf.org; Sat, 04 Nov 2006 22:37:04 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA53b0Uk007060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 4 Nov 2006 19:37:01 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA53ax7i005980; Sat, 4 Nov 2006 19:36:59 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 4 Nov 2006 19:36:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 4 Nov 2006 19:37:01 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some comments on draft-ietf-mip6-aaa-ha-goals-03 Thread-Index: Acbm+xRlUsbSjFLuEduFIgARJNUNiAZhNxkg From: "Narayanan, Vidya" To: "Basavaraj Patil" , X-OriginalArrivalTime: 05 Nov 2006 03:36:59.0162 (UTC) FILETIME=[A62AB7A0:01C7008B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: Subject: [Mip6] Some comments on draft-ietf-mip6-aaa-ha-goals-03 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org All, I know this is a few weeks late, given the WG LC has expired, but hopefully, it is not too late :)=20 I found the draft to be well written and quite complete. A few comments below.=20 1. In the integrated scenario, it seems to be assumed that the NAS gets the MIP6 parameters. I'm not sure that the NAS and DHCP relay agent need to be collocated. The NAS, where EAP is used for network access, for instance, could be the L2 entity, while the DHCP relay agent is located in the AR. So, is there any reason to tie the two entities? I would suggest changing "NAS" to "DHCP Relay Agent in the ASA" or something to that effect.=20 2. Section 4.1 states "Note that even if EAP is used, the MN authenticates the HA using public key based authentication." With double EAP authentication for IKEv2 being defined, why does this have to be the case? In other words, no need to preclude a double EAP, is there?=20 3. Section 4.1 further states "Note that the AAA exchange between the HA and the AAA server is normally terminated before the HA receives the Binding Update message. The reason is that the authentication has succeeded if the Mobile Node is able to send the BU." I'm confused by what this means.=20 4. Section 4.2 states "In both cases, it is assumed that the AAA server in the home domain (AAAH) authorizes both network access service and mobility service." The HOKEY WG is defining the capability to perform EAP re-authentication in visited domains. The mobility service may still be under the home domain control. So, is there a need to have this restriction? I suppose it can be viewed as the AAAH still authorizing the network access during the first full EAP authentication, but I'm not sure if that's what it means. Also, I can think of cases where, say, the MN is using a local access (e.g., prepaid service in the local network). 5. "The HA SHOULD be able to query the AAAH server to verify Mobile IPv6 service authorization for the mobile node." Why would this not be a MUST?=20 6. The security considerations alludes to an IKE PSK being sent from the AAAH to HA - I guess this is referring to the MSK - IKEv2 doesn't quite consider this as the PSK. For instance, an IKEv2 PSK can be used multiple times - i.e., to authenticate several IKEv2 exchanges. The EAP MSK is only used once, in accordance with RFC4306 (the language is vague, but that's the present case - the MSK is deleted after one use). So, it is not quite the same as a PSK.=20 Thanks, Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 04 23:11:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgZLh-0004AC-8w; Sat, 04 Nov 2006 23:11:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgZLf-00049S-Rd; Sat, 04 Nov 2006 23:11:07 -0500 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgZLe-0005U3-Ct; Sat, 04 Nov 2006 23:11:07 -0500 Message-ID: <005f01c70090$62d279c0$506015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Sri Gundavelli" , "Julien Laganier" References: <39C363776A4E8C4A94691D2BD9D1C9A10177444A@XCH-NW-7V2.nw.nos.boeing.com><200611041022.26090.julien.IETF@laposte.net><200611041621.59661.julien.IETF@laposte.net> Date: Sat, 4 Nov 2006 20:10:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution forNETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Guys, The PMIP proposal in draft-sgundave-mipv6-proxymipv6-00 gets around the link local uniqueness problem by turning off DAD and using DHCP address allocation exclusively. The link between the mobile node and the MIPv6 FA (aka proxy mobile node) is a virtual point to point link. See Section 7.3. I don't know how this problem is handled in the PMIP proposal in draft-chowdhury-netmip6-01.txt, I assume by the use of the unique identifier assigned by the network using IPCP, whether or not PPP is used, but the draft says nothing about whether DAD is used (it won't be if PPP is). I don't think these approaches are unique to PMIP, however. jak ----- Original Message ----- From: "Sri Gundavelli" To: "Julien Laganier" Cc: ; "Templin, Fred L" ; Sent: Saturday, November 04, 2006 4:47 PM Subject: Re: [netlmm] Re: Why is PMIP a superior solution forNETLMMrequireiments? > > Hi Julien, > > Please see inline .. > > > On Sat, 4 Nov 2006, Julien Laganier wrote: > >>> Hi Julien, >>> >>> Even for the link-local address duplicate detection, >>> in the given shared link scenario, the resolution >>> happens on that access link and all the visiting >>> nodes on that link can do the resolution with out >>> the need for the messages to go beyond the link. >> >> Just to make sure: I did not say that address >> resolution should occur across links, only that DAD >> traffic should be relayed across link *when* a >> collision occurs. >> >>> Lets assume host "A" and "B" are using the same >>> LLA: FE80::2AA:FF:FE22:2222 and both will register >>> for the corresponding solicited-node multicast >>> address FF02::1:FF22:2222. The link is not a split >>> link and LLA uniqueness have to be to contained to >>> that link. Why do I need across domain resolution >>> or DAD or Relay-DAD ? >> >> [again I am not saying that we should have domain-wide >> address resolution] >> >> Let's take the following example: one host H and two >> access routers AR1 and AR2 on two different links >> (link1 and link2). H is attached to AR1. >> >> Suppose that H and AR2 happens to configure the same >> link-local address. H will do DAD on link1 and won't >> detect a collision, AR2 will do DAD on link2 and won't >> detect a collision. >> >> Now what happens if H moves to link2: there's a >> collision of link local addresses of H and AR2. >> > > When H moves to link2, it will do a DAD on that > link and detect the collision. The collision is > very much on that link and will be detected right > after the host H moves to that link and starts > the address configuration. > > The collision is on the link, why do these messages > need to go out of the link ? Why do we need Proxy or Relay DAD ? Why is > this scenario any special ? This > is a normal IPv6 DAD scenario and ND will very much > take care of that. Again, this is not a split link, > we are not bridging traffic between links in this > case. > > > Regards > Sri > > >> That can be avoided by relaying/proxying DAD messages >> *when* a collision occurs (the anchor point knows >> when.) >> > > > _______________________________________________ > netlmm mailing list > netlmm@ietf.org > https://www1.ietf.org/mailman/listinfo/netlmm _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 05 13:41:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggmu7-0007Ax-7o; Sun, 05 Nov 2006 13:39:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggmu5-0007Am-Hg for mip6@ietf.org; Sun, 05 Nov 2006 13:39:33 -0500 Received: from ug-out-1314.google.com ([66.249.92.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggmu3-0001Jp-0o for mip6@ietf.org; Sun, 05 Nov 2006 13:39:33 -0500 Received: by ug-out-1314.google.com with SMTP id 72so620365ugd for ; Sun, 05 Nov 2006 10:39:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Lf4/eFDqmX/mmRvyKmImfZ+LQMthhmVjqVOMzjLZyukX6QFe2bCyUCw0xCBXQbMYFvViOFbl3td+NTmUBHk0dYEHdybI8yXY96tgdklG87jvQfyZXl9XSyLS4CEk4IFLYfdxTyZgnRYdF0n9EtaIEYyYwSnxrfcMXB1mALdWjC0= Received: by 10.67.21.11 with SMTP id y11mr6083628ugi.1162751969400; Sun, 05 Nov 2006 10:39:29 -0800 (PST) Received: by 10.66.243.16 with HTTP; Sun, 5 Nov 2006 10:39:29 -0800 (PST) Message-ID: Date: Sun, 5 Nov 2006 19:39:29 +0100 From: "Gerardo Giaretta" To: "Narayanan, Vidya" Subject: Re: [Mip6] Some comments on draft-ietf-mip6-aaa-ha-goals-03 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, thanks for your feedback. Please find my comments below. > All, > I know this is a few weeks late, given the WG LC has expired, but > hopefully, it is not too late :) > > I found the draft to be well written and quite complete. A few comments > below. > > 1. In the integrated scenario, it seems to be assumed that the NAS gets > the MIP6 parameters. I'm not sure that the NAS and DHCP relay agent need > to be collocated. The NAS, where EAP is used for network access, for > instance, could be the L2 entity, while the DHCP relay agent is located > in the AR. So, is there any reason to tie the two entities? I would > suggest changing "NAS" to "DHCP Relay Agent in the ASA" or something to > that effect. > I would like Kuntal or Alper to answer on this. I think the co-location of the NAS and the DHCP Relay Agent is an assumption of the integrated scenario solution based on DHCP. In any case, from a functional point of view, we are talking about a "AAA interface" so I think that the correct functional entity to terminate the communication with the AAA server is the NAS. Then, I agree with you that this information must be transferred to the DHCP Relay if the NAS and the DHCP Relay are not co-located, but the AAA server knows the NAS unless we want to make the DHCP Relay an AAA client. > 2. Section 4.1 states "Note that even if EAP is used, the MN > authenticates the HA using public key based authentication." With double > EAP authentication for IKEv2 being defined, why does this have to be the > case? In other words, no need to preclude a double EAP, is there? > I agree. The text was written to be fully in line with rfc4306. But I'm fully in favour of the double EAP authentication here, therefore I agree we can avoid this text. > 3. Section 4.1 further states "Note that the AAA exchange between the HA > and the AAA server is normally terminated before the HA receives the > Binding Update message. The reason is that the authentication has > succeeded if the Mobile Node is able to send the BU." I'm confused by > what this means. > The point is that the authentication step is performed during IKEv2 exchange, so during the bootstraping phase. When the first BU is received by the HA, the actual user authentication has already been performed by the AAA server. I hope now it's clearer, let me know if you think we should re-phrase the text. Note that this is discussed also in DIME WG because there are some open issues about how the HA and AAAH should authorize e.g. address autoconfiguration. > 4. Section 4.2 states "In both cases, it is assumed that the AAA server > in the home domain (AAAH) authorizes both network access service and > mobility service." The HOKEY WG is defining the capability to perform > EAP re-authentication in visited domains. The mobility service may still > be under the home domain control. So, is there a need to have this > restriction? I suppose it can be viewed as the AAAH still authorizing > the network access during the first full EAP authentication, but I'm not > sure if that's what it means. Also, I can think of cases where, say, the > MN is using a local access (e.g., prepaid service in the local network). > We can re-phrase stating that the first full EAP authentication and the authorization for network access and mobility service are performed in the home domain. Does it sound good? > > 5. "The HA SHOULD be able to query the AAAH server to verify Mobile IPv6 > service authorization for the mobile node." Why would this not be a > MUST? > Right, it's a MUST. > 6. The security considerations alludes to an IKE PSK being sent from the > AAAH to HA - I guess this is referring to the MSK - IKEv2 doesn't quite > consider this as the PSK. For instance, an IKEv2 PSK can be used > multiple times - i.e., to authenticate several IKEv2 exchanges. The EAP > MSK is only used once, in accordance with RFC4306 (the language is > vague, but that's the present case - the MSK is deleted after one use). > So, it is not quite the same as a PSK. > The idea behind this statement was not the usage of MSK as PSK. There have been some proposals to derive a key from the EAP authentication for network access and use it as PSK in IKEv2 (I think there are two individual drafts available on this topic right now): the statement was introduced in order to give a pointer to this approach. --Gerardo > Thanks, > Vidya > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 05 14:38:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggnoo-0006IT-Ig; Sun, 05 Nov 2006 14:38:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggnom-0006He-OH for mip6@ietf.org; Sun, 05 Nov 2006 14:38:08 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ggnol-0006KS-Eq for mip6@ietf.org; Sun, 05 Nov 2006 14:38:08 -0500 Received: from [10.1.210.11] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 11:38:06 -0800 Message-ID: <454E3CB0.1020503@azairenet.com> Date: Sun, 05 Nov 2006 11:34:08 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] Some comments on draft-ietf-mip6-aaa-ha-goals-03 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Nov 2006 19:38:06.0365 (UTC) FILETIME=[EA7F94D0:01C70111] X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Narayanan, Vidya wrote: > 2. Section 4.1 states "Note that even if EAP is used, the MN > authenticates the HA using public key based authentication." I wonder if we should have this sentence in the draft at all. RFC 4306 is already explicit about this. > With double > EAP authentication for IKEv2 being defined, why does this have to be the > case? In other words, no need to preclude a double EAP, is there? what is "double EAP authentication"? > 6. The security considerations alludes to an IKE PSK being sent from the > AAAH to HA - I guess this is referring to the MSK - IKEv2 doesn't quite > consider this as the PSK. For instance, an IKEv2 PSK can be used > multiple times - i.e., to authenticate several IKEv2 exchanges. The EAP > MSK is only used once, in accordance with RFC4306 (the language is > vague, but that's the present case - the MSK is deleted after one use). > So, it is not quite the same as a PSK. this is valid if we talk about EAP alone. but I think the HA-AAAH interface can be used to even transfer keys that *can* be used as IKEv2 PSKs. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 05 18:38:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgrZ1-0004sj-M4; Sun, 05 Nov 2006 18:38:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgrZ0-0004sU-Fb for mip6@ietf.org; Sun, 05 Nov 2006 18:38:06 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgrYw-0003FN-4l for mip6@ietf.org; Sun, 05 Nov 2006 18:38:06 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA5Nbv8L021613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 5 Nov 2006 15:37:57 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-101.qualcomm.com [10.50.72.101]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA5NbtE1014609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 5 Nov 2006 15:37:56 -0800 (PST) Message-Id: <7.0.1.0.2.20061105152947.0593aec0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 05 Nov 2006 15:37:48 -0800 To: Vijay Devarapalli , "Narayanan, Vidya" From: Lakshminath Dondeti Subject: Re: [Mip6] Some comments on draft-ietf-mip6-aaa-ha-goals-03 In-Reply-To: <454E3CB0.1020503@azairenet.com> References: <454E3CB0.1020503@azairenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org At 11:34 AM 11/5/2006, Vijay Devarapalli wrote: >what is "double EAP authentication"? Perhaps the reference is to draft-eronen-ipsec-ikev2-eap-auth-05; IMO "double EAP" authentication at this point is a misnomer for that draft. There is only one EAP authentication :). Does that change anything for application of that protocol to the MIP6 scenario? regards, Lakshminath _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 05 19:01:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggrva-0000Iq-TR; Sun, 05 Nov 2006 19:01:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgrvZ-0000Ig-P4 for mip6@ietf.org; Sun, 05 Nov 2006 19:01:25 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgrvX-0006L5-Em for mip6@ietf.org; Sun, 05 Nov 2006 19:01:25 -0500 Received: from [10.1.210.11] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 5 Nov 2006 16:01:22 -0800 Message-ID: <454E7A67.4040109@azairenet.com> Date: Sun, 05 Nov 2006 15:57:27 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Mip6] Some comments on draft-ietf-mip6-aaa-ha-goals-03 References: <454E3CB0.1020503@azairenet.com> <7.0.1.0.2.20061105152947.0593aec0@qualcomm.com> In-Reply-To: <7.0.1.0.2.20061105152947.0593aec0@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 00:01:22.0269 (UTC) FILETIME=[B19740D0:01C70136] X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Lakshminath Dondeti wrote: > At 11:34 AM 11/5/2006, Vijay Devarapalli wrote: >> what is "double EAP authentication"? > > Perhaps the reference is to draft-eronen-ipsec-ikev2-eap-auth-05; IMO > "double EAP" authentication at this point is a misnomer for that draft. > There is only one EAP authentication :). > > Does that change anything for application of that protocol to the MIP6 > scenario? draft-ietf-mip6-aaa-ha-goals-03 should not talk about this at all. draft-eronen-ipsec-ikev2-eap-auth-05 has an impact only on draft-ietf-mip6-ikev2-ipsec. version 4 of draft-ietf-mip6-ikev2-ipsec had the following text. The IKEv2 specification [4] requires that public key based mechanism be used to authenticate the home agent to the mobile node, when EAP is used. This should be used by default by the mobile node and the home agent. If the EAP method that is used, supports mutual authentication and key generation, then the mobile node MAY use EAP itself to authenticate the home agent. The mobile node can request this by including the EAP_ONLY_AUTHENTICATION notification payload [8] in message 3. If the home agent supports the EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP, it omits the public key based AUTH and CERT payloads in message 4. If the home agent does not support this mechanism, it rejects it by including an AUTH payload in message 4. More details can be found in [8]. but it was decided to remove this text because the status for draft-eronen-ipsec-ikev2-eap-auth was unknown. has that changed? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 03:30:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzqZ-0005K3-Af; Mon, 06 Nov 2006 03:28:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgzqY-0005EZ-5j for mip6@ietf.org; Mon, 06 Nov 2006 03:28:46 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgzqW-00042l-DD for mip6@ietf.org; Mon, 06 Nov 2006 03:28:45 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA68SeGE021194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 00:28:41 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-39.qualcomm.com [10.50.77.39]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA68ScUu011577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 6 Nov 2006 00:28:39 -0800 (PST) Message-Id: <7.0.1.0.2.20061106002216.064e8de0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 06 Nov 2006 00:28:30 -0800 To: Vijay Devarapalli From: Lakshminath Dondeti Subject: Re: [Mip6] Some comments on draft-ietf-mip6-aaa-ha-goals-03 In-Reply-To: <454E7A67.4040109@azairenet.com> References: <454E3CB0.1020503@azairenet.com> <7.0.1.0.2.20061105152947.0593aec0@qualcomm.com> <454E7A67.4040109@azairenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org At 03:57 PM 11/5/2006, Vijay Devarapalli wrote: >Lakshminath Dondeti wrote: >>At 11:34 AM 11/5/2006, Vijay Devarapalli wrote: >>>what is "double EAP authentication"? >>Perhaps the reference is to draft-eronen-ipsec-ikev2-eap-auth-05; >>IMO "double EAP" authentication at this point is a misnomer for that draft. >>There is only one EAP authentication :). >>Does that change anything for application of that protocol to the >>MIP6 scenario? > >draft-ietf-mip6-aaa-ha-goals-03 should not talk about >this at all. draft-eronen-ipsec-ikev2-eap-auth-05 has >an impact only on draft-ietf-mip6-ikev2-ipsec. > >version 4 of draft-ietf-mip6-ikev2-ipsec had the >following text. > > The IKEv2 specification [4] requires that public key based mechanism > be used to authenticate the home agent to the mobile node, when EAP > is used. This should be used by default by the mobile node and the > home agent. If the EAP method that is used, supports mutual > authentication and key generation, then the mobile node MAY use EAP > itself to authenticate the home agent. The mobile node can request > this by including the EAP_ONLY_AUTHENTICATION notification payload > [8] in message 3. If the home agent supports the > EAP_ONLY_AUTHENTICATION notification payload and agrees to use EAP, > it omits the public key based AUTH and CERT payloads in message 4. > If the home agent does not support this mechanism, it rejects it by > including an AUTH payload in message 4. More details can be found in > [8]. > >but it was decided to remove this text because the >status for draft-eronen-ipsec-ikev2-eap-auth was >unknown. has that changed? No the status of that draft has not "changed." It is still in "ID Exists" state. Coming back to the issue at hand, I am curious about the group's opinion (we can discuss the status of draft-eronen-ipsec-ikev2-eap-auth-05 separately). If the MN and the HA MUST mutually authenticate each other, then well 4306 applies. With the removal of the paragraph you included above, that's what it defaults to. This is my preference. If HA authentication can be indirect (similar to that of a pass-through NAS in the EAP model), draft-eronen-ipsec-ikev2-eap-auth-05 could apply if there is consensus around it. I would like to hear the case for this, if any. Lakshminath >Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 06:15:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh2Qx-0004Q2-Oe; Mon, 06 Nov 2006 06:14:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh2Qx-0004Pw-Dm for mip6@ietf.org; Mon, 06 Nov 2006 06:14:31 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh2Qv-0001tC-Nn for mip6@ietf.org; Mon, 06 Nov 2006 06:14:31 -0500 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 06 Nov 2006 12:14:18 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FANinTkWQ/uCKY2dsb2JhbACMPxQPKg X-IronPort-AV: i="4.09,390,1157320800"; d="scan'208"; a="117452633:sNHT227933124" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6BEImN016203; Mon, 6 Nov 2006 12:14:18 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6BEH4Z014384; Mon, 6 Nov 2006 12:14:17 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 12:14:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 12:14:12 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02F8B7D6@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2A= From: "Pascal Thubert \(pthubert\)" To: "Narayanan, Vidya" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 06 Nov 2006 11:14:17.0680 (UTC) FILETIME=[B3360D00:01C70194] DKIM-Signature: a=rsa-sha1; q=dns; l=6037; t=1162811658; x=1163675658; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20What=20are=20we=20protecting=20over=20IPv4=20in=20DS-MIP6?=20(RE =3A=20[Mip6]=20concensus=3A=20issue=2076=3A=20Alt=20CoA=20should=20not=20be =20usedwhen=09traversingIPv4=20NAT); X=v=3Dcisco.com=3B=20h=3DKsaCfokeTao80uTL0s7Oque8avM=3D; b=IAy1UDYcmyp4vdzOy7gAX2MsGjeICTJw/vTj3GR+XwpioskgXHh5XIdrNgwbwHE/pR+uJVxh rbm+zzgQiXpakeB1tThwihiUqGDWFNk4gY8NDNFqUgcb5hLZsKc0STK1; Authentication-Results: ams-dkim-1; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya I'm with you on that.=20 The options we have are so far: 1) do nothing. If the MN roams in IPv4, the source is not protected. There is a potential of an attack, but that is a difficult one, in an IPv4 world where so many other attacks are possible anyway. 2) provide the source IPv4 address one way or another. This approach includes Hesham's checksum. This seems to provide an IPv6 equivalent security in the absence of NAT. I'd argue that it does not really, because it is still the IPv4 world, and with IPv4 it much easier to fool a visiting MN into using, as CoA, an address that belongs to an attacked server.=20 3) propose an optional RR test. The test verifies that the MN is reachable at the CoA, so it protects even against NAT and rogue router in the visited network.=20 I think we have to consider the whole picture, thus I favor 3. I could do with 1, and then we'd propose the optional RR test as a separate draft, which would be valid for all declinations of MIP6, should the WG decide that the RR test is not specific to this draft. I have trouble with 2. People who do not really understand what it does might get a false sense of security, which can be even more dangerous. Once this option is in, it will be hard to take it out, even when the RR test is available and actually provides a better security. Pascal=20 >-----Original Message----- >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >Sent: Friday, November 03, 2006 5:00 PM >To: RYUJI WAKIKAWA >Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert (pthubert); Soliman, Hesham >Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA >should not be usedwhen traversingIPv4 NAT) > >Hi Ryuji, >I think this is missing the threat model. Let's look at two possible >scenarios. > >1. MN --- (Attacker) --- HA > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA > >( ) indicates that an attacker may be present. > >If the HA received a BU with the inner and outer addresses the same, it >has no way of telling it was due to case 1 with no attacker or case 2 >with Attacker 2 who changed a NAT'ed outer address back to equal the >inner address. > >So, there is no use in saying that the check is done when the HA detects >a NAT. > >But, we can document this issue and say that we don't protect against >on-path attackers in IPv4, because it is complicated and not worth it. I >guess that's what Vijay and Hesham are saying - I could be convinced of >that, although, I don't see why we can't make the RR optional and leave >it at that. > >Vidya > > >> -----Original Message----- >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] >> Sent: Thursday, November 02, 2006 6:07 AM >> To: Narayanan, Vidya >> Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert >> (pthubert); Soliman, Hesham >> Subject: Re: What are we protecting over IPv4 in DS-MIP6? >> (RE: [Mip6] concensus: issue 76: Alt CoA should not be >> usedwhen traversingIPv4 NAT) >> >> Hi Vidya >> >> RR check can be one solution, but as other people pointed >> out, this causes additional round trip. >> In addition, if there is no NAT, we can simply protect CoA by >> ACoA option. >> If HA detects that the CoA is different between IPv4 header >> and ACoA, it can operate your RR check. >> Otherwise, it should be skipped. >> A new message BA-ack may be sufficient. i.e. An >> acknowledgment of BA sent back from MN. >> >> ryuji >> >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: >> >> > >> > All, >> > This is something I should've raised yesterday when I read all the >> > emails, but after sleeping over it and some other discussions, I'm >> > still confused - so, figured I should raise it now :) >> > >> > First, I don't believe that an AltCoA option (v4 or v6) >> buys anything. >> > Let's look at this. >> > >> > In IPv4, the outer IP address is always up for >> modifications and there >> > is no way to distinguish an adversary modifying it from a NAT >> > modifying it. And, if the outer IPv4 source address is >> different from >> > the inner IP address, there is no way for the HA to figure >> out whether >> > the modification is due to a NAT or an adversary. Such is the truth >> > with NATs and there is nothing that can be done about it. >> Even if the >> > outer and inner IP addresses are the same, there is no way >> to figure >> > out that they are the same because there is no NAT or >> because a NAT-ed >> > IP address in the outer header has been modified back to equal the >> > inner IP address by an adversary. This is quite feasible, >> especially >> > when the inner packet is not encrypted and totally depends on the >> > intention of the attacker. >> > >> > The presence of the Alt-CoA option buys nothing exactly for >> the same >> > reasons. The fact that the Alt-CoA option is integrity >> protected means >> > nothing, since the HA still must use the outer IP address >> as the CoA - >> > and there is no guarantee about that being intact. >> > >> > We cannot pick and choose what attacks we like and what we don't. >> > Either >> > we protect against redirection attacks or we don't. At this >> point, I'm >> > saying that integrity protection of the actual CoA alone proves >> > nothing. >> > Reachability checks have more value than integrity protection of a >> > field that is allowed to be modified. Reachability checks >> too, in the >> > absence of confidentiality on the inner packet, does not guarantee >> > that an attacker is not on the path - but, it at least >> proves that the >> > MN is reachable at that address. >> > >> > So, my vote would be to perform an optional reachability check and >> > document the vulnerability that may still exist. >> > >> > Vidya >> > >> > _______________________________________________ >> > Mip6 mailing list >> > Mip6@ietf.org >> > https://www1.ietf.org/mailman/listinfo/mip6 >> >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 08:01:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh454-00006Y-Hd; Mon, 06 Nov 2006 08:00:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh452-0008VT-Vy for mip6@ietf.org; Mon, 06 Nov 2006 08:00:00 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh44z-0004xi-A5 for mip6@ietf.org; Mon, 06 Nov 2006 08:00:00 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 06 Nov 2006 13:59:56 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAE2/TkWQ/uCLY2dsb2JhbACMQRQPKg X-IronPort-AV: i="4.09,391,1157320800"; d="scan'208"; a="117470665:sNHT34831876" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6CxujM002980; Mon, 6 Nov 2006 13:59:56 +0100 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA6Cxt4Z028585; Mon, 6 Nov 2006 13:59:55 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 13:59:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 13:59:49 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02F8B8E3@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Thread-Index: Acb+iTcNJd8I4UIvTiGoVA+lu7BnqwAAMpjwADDOmtAAAWeDAACTVSHQ From: "Pascal Thubert \(pthubert\)" To: "Soliman, Hesham" , "Zhang, Qiang [NTK]" , "RYUJI WAKIKAWA" , "Narayanan, Vidya" X-OriginalArrivalTime: 06 Nov 2006 12:59:55.0487 (UTC) FILETIME=[74D6A6F0:01C701A3] DKIM-Signature: a=rsa-sha1; q=dns; l=6389; t=1162817996; x=1163681996; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20What=20are=20we=20protecting=20over=20IPv4=20in=20DS-MIP6?=20(RE =3A=20[Mip6]concensus=3A=20issue=2076=3A=20Alt=20CoA=20should=20not=20beuse dwhen=09traversingIPv4=20NAT); X=v=3Dcisco.com=3B=20h=3DOhKMtaQMu5SleSU4AOEIvgWgGX4=3D; b=P3jmzbIJgsvhbZlMFTKMsA07Sw8KVaGocaYEny+g5yvsSv2P269RlIwZWXCFwItSsuoCbH51 djoqZ9PPruDd9d9R9cJrGfp9q1Bxmh2xvjnc9OAhSNBd/4GTudxHCLuX; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham: =20 This is getting confusing, maybe because of the RR term. As you very well know: - What we are really talking about here is enabling the HA to check that the MN can be reached at the CoA, which causes an extra latency when roaming but does not involve the complexity of the test by the MN. - What it mitigates is the redirection attack which can be used to bomb an attacked server. Such a DoS attack is difficult in IPv6 because in most cases, the MN will autoconf its address. So the bombing can only be done against (the access of) an attacked network, not a specific host. =09 =20 - There can still be a MITM. But it needs to be able to forward the BA to the MN, so it is on the way of its own attack. Combined with ESP, this leaves little room for an attacker. In other words, we are trying to have better locks than the neighbors :) =20 My point is this. We can make a simple and optional addition to the protocol where the HA asks the MN to send a second BU. If this provides an interesting improvement in the security level of the solution, why not just do it? =09 =09 Pascal >-----Original Message----- >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] >Sent: Friday, November 03, 2006 3:20 PM >To: Zhang, Qiang [NTK]; RYUJI WAKIKAWA; Narayanan, Vidya >Cc: mip6@ietf.org; Pascal Thubert (pthubert) >Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA >should not beusedwhen traversingIPv4 NAT) > > > > > I would agree the MITM attack will not compromise the > > security provided via Ipsec ESP but rather a DoS is possible > > if indeed the attacker got in the routing path/redirect. > > Just a hypothesis that the issue can only be resolved > > through hop-hop security, RR will not help on the DoS, no? > >=3D> RR would certainly not help with DoS, it doesn't help with DoS today. >But more importantly, DoS can be done today on other protocols doing NAT >traversal and even on any normal communication that doesn't involve MIP >or NAT traversal. So solving it for this draft doesn't add anything to >Internet security in general. > >Hesham > > > > > Qiang > > -----Original Message----- > > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > > Sent: Thursday, November 02, 2006 9:22 AM > > To: RYUJI WAKIKAWA; Narayanan, Vidya > > Cc: mip6@ietf.org; Pascal Thubert (pthubert) > > Subject: RE: What are we protecting over IPv4 in DS-MIP6? > > (RE: [Mip6]concensus: issue 76: Alt CoA should not > > beusedwhen traversingIPv4 NAT) > > > > > > > RR check can be one solution, but as other people pointed > > out, this > causes additional round trip. > > > In addition, if there is no NAT, we can simply protect > > CoA by ACoA > option. > > > > =3D> This is not the issue being raised, the issue is the > > insecurity of the IPv4 header when a NAT exists. The outer > > header is obviously unprotected and vulnerable to > > redirection attacks (an attacker acting as a NAT bascially). > > I don't think we need to solve that problem as I indicated > > in a previous email. > > > > Hesham > > > > > > > > > If HA detects that the CoA is different between IPv4 > > header > and ACoA, > it can operate your RR check. > > > Otherwise, it should be skipped. > > > A new message BA-ack may be sufficient. i.e. An > > > acknowledgment of BA > sent back from MN. > > > > > > ryuji > > > > > > On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > > > > > > > > > All, > > > > This is something I should've raised yesterday when I > > read all the > > emails, but after sleeping over it and > > some other > discussions, I'm > > still > > confused - > > so, figured I should raise it now :) > > > > First, I > > don't believe that an AltCoA option (v4 or v6) > buys anything. > > > > Let's look at this. > > > > > > > > In IPv4, the outer IP address is always up for > > > modifications and there > > is no way to distinguish an > > adversary modifying it from a NAT > > modifying > > it. > > And, if the outer IPv4 source address is different from the > > > > inner IP > > address, there is no way for the HA to > > figure out whether the > > modification is due to a NAT or > > an adversary. Such is the > truth with > > NATs and there > > is nothing that can be done about it. Even > if the outer > > > > and inner IP addresses are the same, there is no way to > > > figure out > > that > > they are the same because there > > is no NAT or because a NAT-ed IP > > address > > in the > > outer header has been modified back to equal the inner IP > > > > address > > by an adversary. This is quite feasible, > > especially when the inner > > packet is not encrypted and > > totally depends on the intention of the > > attacker. > > > > > > > > The presence of the Alt-CoA option buys nothing exactly > > > for the same > > reasons. The fact that the Alt-CoA > > option is integrity > protected means > > nothing, since > > the HA still must use the outer IP address > as the CoA - > > > > and there is no guarantee about that being intact. > > > > > > > > We cannot pick and choose what attacks we like and what > > we don't. > > > > Either > > > > we protect against redirection attacks or we don't. At > > > this point, I'm > > saying that integrity protection of > > the actual CoA alone proves > > nothing. > > > > Reachability checks have more value than integrity > > > protection of a > > field > > that is allowed to be > > modified. Reachability checks too, in the > > absence > > > > of confidentiality on the inner packet, does not guarantee > > that an > > attacker is not on the path - but, it at least > > proves that > the MN is > > reachable at that address. > > > > > > > > So, my vote would be to perform an optional > > reachability check and > > document the vulnerability that > > may still exist. > > > > > > > > Vidya > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 12:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7uV-0007hp-7Z; Mon, 06 Nov 2006 12:05:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7uT-0007hS-IY for mip6@ietf.org; Mon, 06 Nov 2006 12:05:21 -0500 Received: from outbound-fra.frontbridge.com ([62.209.45.174] helo=outbound1-fra-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7uN-00042k-3C for mip6@ietf.org; Mon, 06 Nov 2006 12:05:20 -0500 Received: from outbound1-fra.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound1-fra-R.bigfish.com (Postfix) with ESMTP id A6A6E809FE8; Mon, 6 Nov 2006 17:05:14 +0000 (UTC) Received: from mail10-fra-R.bigfish.com (unknown [10.4.252.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound1-fra.bigfish.com (Postfix) with ESMTP id A324CA78068; Mon, 6 Nov 2006 17:05:14 +0000 (UTC) Received: from mail10-fra (localhost.localdomain [127.0.0.1]) by mail10-fra-R.bigfish.com (Postfix) with ESMTP id 2DFC4870153; Mon, 6 Nov 2006 17:05:14 +0000 (UTC) X-BigFish: V Received: by mail10-fra (MessageSwitch) id 1162832714125016_17673; Mon, 6 Nov 2006 17:05:14 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail10-fra.bigfish.com (Postfix) with ESMTP id D298F89805F; Mon, 6 Nov 2006 17:05:13 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw8.it.sprintspectrum.com [207.40.65.56]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id kA6H57a2008844; Mon, 6 Nov 2006 11:05:09 -0600 (CST) Received: from plswg02a.ad.sprint.com (PLSWG02A.corp.sprint.com [10.214.11.48]) by mailhost.sprintspectrum.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kA6Gxhi9001501; Mon, 6 Nov 2006 10:59:50 -0600 (CST) Received: from PLSWB09C.ad.sprint.com ([208.10.70.239]) by plswg02a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:59:50 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 10:59:49 -0600 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Thread-Index: Acb+iTcNJd8I4UIvTiGoVA+lu7BnqwAAMpjwADDOmtAAAWeDAACTVSHQAAT9cMA= From: "Zhang, Qiang [NTK]" To: "Pascal Thubert \(pthubert\)" , "Soliman, Hesham" , "RYUJI WAKIKAWA" , "Narayanan, Vidya" X-OriginalArrivalTime: 06 Nov 2006 16:59:50.0993 (UTC) FILETIME=[F93A8C10:01C701C4] X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Pascal,=20 I think it is fine to have optional RR as long as there is = implementation that can benefit.=20 Can we get the thread models summarized in the RR draft, I see=20 1. RR can mitigate the "redirect" of HA outbound traffic to victim = server 2. No authenticity for the route (RR will help) 3. MITM NAT can selectively drop packets creating retransmissions, = or DoS toward MN (of coz, MITM NAT can shut down the MN anyway). RR will = not help on these 4. changing of the inner CoA, so to redirect the HA->MN traffic = from the MITM NAT gateway (say from the packet size etc, NAT gw can = fingerprint the traffic pattern, So to let the BU/BA etc go through but = reroute the other packets) more? Also on the issue to ease the aCOA requirement, I think both 3775 and = 3776 need to be eased as both have the context regarding the aCOA option Qiang -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Monday, November 06, 2006 8:00 AM To: Soliman, Hesham; Zhang, Qiang [NTK]; RYUJI WAKIKAWA; Narayanan, = Vidya Cc: mip6@ietf.org Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: = [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 = NAT) Hi Hesham: =20 This is getting confusing, maybe because of the RR term. As you very = well know: - What we are really talking about here is enabling the HA to check that = the MN can be reached at the CoA, which causes an extra latency when = roaming but does not involve the complexity of the test by the MN. - What it mitigates is the redirection attack which can be used to bomb = an attacked server. Such a DoS attack is difficult in IPv6 because in = most cases, the MN will autoconf its address. So the bombing can only be done against (the access of) an attacked network, not a specific host. =09 =20 - There can still be a MITM. But it needs to be able to forward the BA = to the MN, so it is on the way of its own attack. Combined with ESP, = this leaves little room for an attacker. In other words, we are trying = to have better locks than the neighbors :) =20 My point is this. We can make a simple and optional addition to the = protocol where the HA asks the MN to send a second BU. If this provides = an interesting improvement in the security level of the solution, why = not just do it? =09 =09 Pascal >-----Original Message----- >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] >Sent: Friday, November 03, 2006 3:20 PM >To: Zhang, Qiang [NTK]; RYUJI WAKIKAWA; Narayanan, Vidya >Cc: mip6@ietf.org; Pascal Thubert (pthubert) >Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA >should not beusedwhen traversingIPv4 NAT) > > > > > I would agree the MITM attack will not compromise the security=20 > > provided via Ipsec ESP but rather a DoS is possible if indeed the=20 > > attacker got in the routing path/redirect. > > Just a hypothesis that the issue can only be resolved through=20 > > hop-hop security, RR will not help on the DoS, no? > >=3D> RR would certainly not help with DoS, it doesn't help with DoS today. >But more importantly, DoS can be done today on other protocols doing NAT >traversal and even on any normal communication that doesn't involve MIP = >or NAT traversal. So solving it for this draft doesn't add anything to=20 >Internet security in general. > >Hesham > > > > > Qiang > > -----Original Message----- > > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > > Sent: Thursday, November 02, 2006 9:22 AM > > To: RYUJI WAKIKAWA; Narayanan, Vidya > > Cc: mip6@ietf.org; Pascal Thubert (pthubert) > > Subject: RE: What are we protecting over IPv4 in DS-MIP6? > > (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen=20 > > traversingIPv4 NAT) > > > > > > > RR check can be one solution, but as other people pointed out,=20 > > this > causes additional round trip. > > > In addition, if there is no NAT, we can simply protect CoA by=20 > > ACoA > option. > > > > =3D> This is not the issue being raised, the issue is the insecurity = > > of the IPv4 header when a NAT exists. The outer header is obviously=20 > > unprotected and vulnerable to redirection attacks (an attacker=20 > > acting as a NAT bascially). > > I don't think we need to solve that problem as I indicated in a=20 > > previous email. > > > > Hesham > > > > > > > > > If HA detects that the CoA is different between IPv4 header >=20 > > and ACoA, > it can operate your RR check. > > > Otherwise, it should be skipped. > > > A new message BA-ack may be sufficient. i.e. An > acknowledgment = > > of BA > sent back from MN. > > > > > > ryuji > > > > > > On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > > > > > > > > > All, > > > > This is something I should've raised yesterday when I read all=20 > > the > > emails, but after sleeping over it and some other >=20 > > discussions, I'm > > still > > confused - so, figured I should=20 > > raise it now :) > > > > First, I don't believe that an AltCoA=20 > > option (v4 or v6) > buys anything. > > > > Let's look at this. > > > > > > > > In IPv4, the outer IP address is always up for > modifications = > > and there > > is no way to distinguish an adversary modifying it=20 > > from a NAT > > modifying > > it. > > And, if the outer IPv4 source address is different from the > > > > inner IP > > address, there is no way for the HA to > > figure out whether the > > modification is due to a NAT or an=20 > > adversary. Such is the > truth with > > NATs and there is nothing=20 > > that can be done about it. Even > if the outer > > > > and inner IP addresses are the same, there is no way to > > > figure out > > that > > they are the same because there > > is no NAT or because a NAT-ed IP > > address > > in the outer=20 > > header has been modified back to equal the inner IP > > > > address > > by an adversary. This is quite feasible, > > especially when the inner > > packet is not encrypted and totally=20 > > depends on the intention of the > > attacker. > > > > > > > > The presence of the Alt-CoA option buys nothing exactly > for=20 > > the same > > reasons. The fact that the Alt-CoA option is integrity = =20 > > > protected means > > nothing, since the HA still must use the=20 > > outer IP address > as the CoA - > > > > and there is no guarantee about that being intact. > > > > > > > > We cannot pick and choose what attacks we like and what we=20 > > don't. > > > > Either > > > > we protect against redirection attacks or we don't. At > > > this point, I'm > > saying that integrity protection of > > the actual CoA alone proves > > nothing. > > > > Reachability checks have more value than integrity >=20 > > protection of a > > field > > that is allowed to be modified.=20 > > Reachability checks too, in the > > absence > > of confidentiality = > > on the inner packet, does not guarantee that an > > attacker is not = > > on the path - but, it at least proves that > the MN is > >=20 > > reachable at that address. > > > > > > > > So, my vote would be to perform an optional reachability check=20 > > and > > document the vulnerability that may still exist. > > > > > > > > Vidya > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 12:46:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8YD-0002vv-Ut; Mon, 06 Nov 2006 12:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8YC-0002vm-FM for mip6@ietf.org; Mon, 06 Nov 2006 12:46:24 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=moe.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8YB-0001F2-5z for mip6@ietf.org; Mon, 06 Nov 2006 12:46:24 -0500 Received: from [10.1.201.12] ([66.92.223.6]) by moe.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 09:46:21 -0800 Message-ID: <454F73FE.1030308@azairenet.com> Date: Mon, 06 Nov 2006 09:42:22 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Zhang, Qiang [NTK]" Subject: Re: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Nov 2006 17:46:21.0206 (UTC) FILETIME=[78534360:01C701CB] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello Qiang, Zhang, Qiang [NTK] wrote: > Also on the issue to ease the aCOA requirement, I think both 3775 and 3776 need to be eased as both have the context regarding the aCOA option in the context of MIPv6, as defined in RFC 3775, where the access network and the home network are IPv6, the use of AltCoA option is required. we shouldn't relax the MIPv6 specs. DS-MIPv6 can relax that requirement for mobile nodes that are attached to an IPv4 access network. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 12:57:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8iN-0001lC-QV; Mon, 06 Nov 2006 12:56:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8iM-0001l5-DZ for mip6@ietf.org; Mon, 06 Nov 2006 12:56:54 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8iI-0002ad-P1 for mip6@ietf.org; Mon, 06 Nov 2006 12:56:54 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6Hugba008095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 09:56:43 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.141.78]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6HldJs025263; Mon, 6 Nov 2006 09:56:42 -0800 (PST) Received: from SANEXCAS02.na.qualcomm.com ([172.30.36.176]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 09:55:04 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 09:55:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 09:55:02 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF4036B66@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2AADt0eIA== From: "Soliman, Hesham" To: "Pascal Thubert \(pthubert\)" , "Narayanan, Vidya" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 06 Nov 2006 17:55:04.0113 (UTC) FILETIME=[B0008A10:01C701CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Pascal, =20 The options you list below are mixing two different problems together.=20 There were two issues discussed: A. Integrity of the CoA in the IPv6 packet B. Integrity of the IPv4 header.=20 Option 2) below is intended for A) above and option 3) was discussed to address B. I hope it's clear that the options you list below are not alternatives as they address different problems. Hesham > I'm with you on that.=20 >=20 > The options we have are so far: >=20 > 1) do nothing. If the MN roams in IPv4, the source is not protected. > There is a potential of an attack, but that is a difficult one, in an > IPv4 world where so many other attacks are possible anyway. >=20 > 2) provide the source IPv4 address one way or another. This approach > includes Hesham's checksum. This seems to provide an IPv6 equivalent > security in the absence of NAT. I'd argue that it does not really, > because it is still the IPv4 world, and with IPv4 it much=20 > easier to fool > a visiting MN into using, as CoA, an address that belongs to=20 > an attacked > server.=20 >=20 > 3) propose an optional RR test. The test verifies that the MN is > reachable at the CoA, so it protects even against NAT and=20 > rogue router > in the visited network.=20 >=20 > I think we have to consider the whole picture, thus I favor=20 > 3. I could > do with 1, and then we'd propose the optional RR test as a separate > draft, which would be valid for all declinations of MIP6,=20 > should the WG > decide that the RR test is not specific to this draft. >=20 > I have trouble with 2. People who do not really understand=20 > what it does > might get a false sense of security, which can be even more=20 > dangerous. > Once this option is in, it will be hard to take it out, even=20 > when the RR > test is available and actually provides a better security. >=20 > Pascal=20 >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >Sent: Friday, November 03, 2006 5:00 PM > >To: RYUJI WAKIKAWA > >Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert (pthubert); > Soliman, Hesham > >Subject: RE: What are we protecting over IPv4 in DS-MIP6?=20 > (RE: [Mip6] > concensus: issue 76: Alt CoA > >should not be usedwhen traversingIPv4 NAT) > > > >Hi Ryuji, > >I think this is missing the threat model. Let's look at two possible > >scenarios. > > > >1. MN --- (Attacker) --- HA > > > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA > > > >( ) indicates that an attacker may be present. > > > >If the HA received a BU with the inner and outer addresses=20 > the same, it > >has no way of telling it was due to case 1 with no attacker=20 > or case 2 > >with Attacker 2 who changed a NAT'ed outer address back to equal the > >inner address. > > > >So, there is no use in saying that the check is done when the HA > detects > >a NAT. > > > >But, we can document this issue and say that we don't=20 > protect against > >on-path attackers in IPv4, because it is complicated and=20 > not worth it. > I > >guess that's what Vijay and Hesham are saying - I could be=20 > convinced of > >that, although, I don't see why we can't make the RR=20 > optional and leave > >it at that. > > > >Vidya > > > > > >> -----Original Message----- > >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > >> Sent: Thursday, November 02, 2006 6:07 AM > >> To: Narayanan, Vidya > >> Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert > >> (pthubert); Soliman, Hesham > >> Subject: Re: What are we protecting over IPv4 in DS-MIP6? > >> (RE: [Mip6] concensus: issue 76: Alt CoA should not be > >> usedwhen traversingIPv4 NAT) > >> > >> Hi Vidya > >> > >> RR check can be one solution, but as other people pointed > >> out, this causes additional round trip. > >> In addition, if there is no NAT, we can simply protect CoA by > >> ACoA option. > >> If HA detects that the CoA is different between IPv4 header > >> and ACoA, it can operate your RR check. > >> Otherwise, it should be skipped. > >> A new message BA-ack may be sufficient. i.e. An > >> acknowledgment of BA sent back from MN. > >> > >> ryuji > >> > >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > >> > >> > > >> > All, > >> > This is something I should've raised yesterday when I=20 > read all the > >> > emails, but after sleeping over it and some other=20 > discussions, I'm > >> > still confused - so, figured I should raise it now :) > >> > > >> > First, I don't believe that an AltCoA option (v4 or v6) > >> buys anything. > >> > Let's look at this. > >> > > >> > In IPv4, the outer IP address is always up for > >> modifications and there > >> > is no way to distinguish an adversary modifying it from a NAT > >> > modifying it. And, if the outer IPv4 source address is > >> different from > >> > the inner IP address, there is no way for the HA to figure > >> out whether > >> > the modification is due to a NAT or an adversary. Such=20 > is the truth > >> > with NATs and there is nothing that can be done about it. > >> Even if the > >> > outer and inner IP addresses are the same, there is no way > >> to figure > >> > out that they are the same because there is no NAT or > >> because a NAT-ed > >> > IP address in the outer header has been modified back=20 > to equal the > >> > inner IP address by an adversary. This is quite feasible, > >> especially > >> > when the inner packet is not encrypted and totally=20 > depends on the > >> > intention of the attacker. > >> > > >> > The presence of the Alt-CoA option buys nothing exactly for > >> the same > >> > reasons. The fact that the Alt-CoA option is integrity > >> protected means > >> > nothing, since the HA still must use the outer IP address > >> as the CoA - > >> > and there is no guarantee about that being intact. > >> > > >> > We cannot pick and choose what attacks we like and what=20 > we don't. > >> > Either > >> > we protect against redirection attacks or we don't. At this > >> point, I'm > >> > saying that integrity protection of the actual CoA alone proves > >> > nothing. > >> > Reachability checks have more value than integrity=20 > protection of a > >> > field that is allowed to be modified. Reachability checks > >> too, in the > >> > absence of confidentiality on the inner packet, does=20 > not guarantee > >> > that an attacker is not on the path - but, it at least > >> proves that the > >> > MN is reachable at that address. > >> > > >> > So, my vote would be to perform an optional=20 > reachability check and > >> > document the vulnerability that may still exist. > >> > > >> > Vidya > >> > > >> > _______________________________________________ > >> > Mip6 mailing list > >> > Mip6@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 13:01:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8mP-0004Kw-Is; Mon, 06 Nov 2006 13:01:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8mO-0004J0-Rh for mip6@ietf.org; Mon, 06 Nov 2006 13:01:04 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8mM-00039N-4P for mip6@ietf.org; Mon, 06 Nov 2006 13:01:04 -0500 Received: by ug-out-1314.google.com with SMTP id 72so802485ugd for ; Mon, 06 Nov 2006 10:01:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LUyRU0Ky1VeMhQddqpNifqZ6um/0WD3Nm2GYWn2MjYQ7X2VoCt3wRGhTkJKndB3T5mVWNVGLn0mh5zAw4AQWve/qQjOidGBGaniLRRrRcF3H7FcyEDtgctYx2B6gQMg0gSe4h4dDSfWbEhn9830T6LGsSI4bksS78RFjNM1EU6A= Received: by 10.66.232.11 with SMTP id e11mr7745895ugh.1162836060611; Mon, 06 Nov 2006 10:01:00 -0800 (PST) Received: by 10.66.243.16 with HTTP; Mon, 6 Nov 2006 10:01:00 -0800 (PST) Message-ID: Date: Mon, 6 Nov 2006 10:01:00 -0800 From: "Gerardo Giaretta" To: "Madjid Nakhjiri" Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-Reply-To: <001401c7005e$ac712310$5419c00a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <001401c7005e$ac712310$5419c00a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2b3349545af520ba354ccdc9e1a03fc1 Cc: mip6@ietf.org, dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Madjid, On 11/4/06, Madjid Nakhjiri wrote: > The doc calls itself AAA-HA goals, so We need to see what we need to > accomplish by the document > > 1) define AAA function requirements on HA and on HA-AAA server protocol? > > > 2) what is vendor required to put inside MIP6 HA to support AAA interaction. > > If the goal is 1) and you are not careful, you can unintentionally rule out > RADIUS. Plus some of the requirements are beyond the scope of those for AAA > client (HA) and AAA protocols. I am just pointing out that unless trying to > set up a set of goals for the Dime drafts, we need to be careful about the > side-effect of ruling out use of RADIUS for MIP6. > > Let me go through the goal > > > G1.1 The AAAH server and the HA MUST be able to authenticate each > > other (mutual authentication) in order to prevent the installation > > of unauthorized state on the HA. In some deployment scenarios, it > > may not be feasible for HA and AAAH to mutually authenticate each > > other. For example, let us consider the case where MSP is not the > > MSA. In such a case, several AAA intermediate proxies could > > forward MIP6 bootstrapping information back and forth between HA > > and AAA. Thus, to prevent the installation of unauthorized state > > on the HA, the path between HA and AAAH should be trustworthy>/ > > > > Madjid>>I am going to assume HA is AAA client, not sure, if authentication > between a AAA client and a AAA is an explicit requirement in any of the AAA > protocols. First it means a direct SA between the HA and AAAH. If there are > proxies on the AAA path, RADIUS for one does not support the end to end SA > directly, let alone the act of end to end authentication. > I understand that sending keys from AAAH to HA requires tight security, but > this is not a "AAA requirement", since it may not be covered by some AAA > protocols, it is part of security provisioning for the entire HA design. You > may want to bring this up in "security consideration section". > > You already seem to have this part of security consideration, so not sure > why it is also mentioned as AAA-HA goal, unless the goal of the doc is the > (2) mentioned above. > ok, now I get your point. However in the goal text we have already added this sentence: In some deployment scenarios, it may not be feasible for HA and AAAH to mutually authenticate each other. For example, let us consider the case where MSP is not the MSA. In such a case, several AAA intermediate proxies could forward MIP6 bootstrapping information back and forth between HA and AAA. Thus, to prevent the installation of unauthorized state on the HA, the path between HA and AAAH should be trustworthy. This was added exactly for RADIUS. Doesn't this text solve your issue? --Gerardo > I hope I have been helpful. > > R, > > Madjid > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Friday, November 03, 2006 6:30 AM > To: Madjid Nakhjiri > Cc: dime@ietf.org; mip6@ietf.org; Julien Bournelle > Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: > draft-ietf-mip6-aaa-ha-goals-03 > > Hi Madjid, > > thanks for the review. Most comments are editorial and I'll fix them > in next version. Just one more detailed question below. > > > > > > 5.1. General goals > > > > G1.1 The AAAH server and the HA MUST be able to authenticate each > > other (mutual authentication) in order to prevent the installation > > of unauthorized state on the HA. In some deployment scenarios, it > > may not be feasible for HA and AAAH to mutually authenticate each > > other. For example, let us consider the case where MSP is not the > > MSA. In such a case, several AAA intermediate proxies could > > forward MIP6 bootstrapping information back and forth between HA > > and AAA. Thus, to prevent the installation of unauthorized state > > on the HA, the path between HA and AAAH should be trustworthy>/ > > > > > > Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing > > into something that is more of a > > > > AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing > end > > point authentication and AAA > > > > signaling security all in one requirement. Mutual authentication of HA and > > home AAA is one thing, protecting > > > > bootstrapping info over AAA messaging is another. This should be broken > into > > two requirements. I believe you > > > > have text on confidentiality in G1.4. The AAA signaling security issue is > > that of a AAA client in visited > > > > AAA domain dealing with a home AAA domain are well known. for instance if > > you don't like the transitive > > > > trust provided by the hop by hop security in RADIUS, so you need external > > ways to cure the transitive trust > > > > problem. On the other hand providing a mutual authentication procedure > > between HA and home AAA server > > > > without intervention of AAA intermediaries in a whole different problem. > So > > we need to be careful, otherwise > > > > we may end up ruling RADIUS out of here. Is that the intention? > > > > I would simply state the well known issues in the security consideration > > section. > > > > sorry but I cannot get your point clearly. > > which is your suggestion? Removing the requirement? Rephrasing it? Can > you please provide some text? > > Thanks, > --Gerardo > > > > > Giaretta, et al. Expires March 16, 2007 [Page 6] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > G1.2 The AAA-HA interface MUST provide integrity protection in order > > to prevent any alteration of exchanged data (e.g., Mobile IPv6 > > configuration parameters). > > > > G1.3 The AAA-HA interface MUST provide replay protection. > > > > G1.4 The AAA-HA interface SHOULD provide confidentiality since it > > may be used to transfer keying material (e.g., shared key > > generated during EAP method authentication). > > > > Madjid>>same comment as that on security in G1.1. > > > > G1.5 The AAA-HA interface SHOULD support inactive peer detection. > > This functionality can be used by the AAAH server to maintain a > > list of active HAs. > > > > > > 5.2. Service Authorization > > > > Madjid>>Typically authorization follows a successful authentication. It > > seems that the burden of the making > > > > sure the MN is authenticated falls into the lap of the HA, should we not > > have a requirement on this? > > > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > > Identifier (NAI) to identify the user. > > > > Madjid>>I believe for the split scenario. We were saying that the > > Diameter_EAP and Diameter-MIP need to use > > > > the same ID. does this cover that? Is NAI always the ID used for EAP? > > > > G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile > > IPv6 service authorization for the mobile node. > > > > G2.3 The AAAH server MAY assign explicit operational limitations and > > authorization restrictions on the HA (e.g., packet filters, QoS > > parameters). > > > > G2.4 The AAAH server MUST be able to send an authorization lifetime > > to the HA to limit Mobile IPv6 session duration for the MN. > > > > G2.5 The HA MUST be able to request to the AAAH server an extension > > of the authorization lifetime granted to the MN. > > > > G2.6 The AAAH server MUST be able to force the HA to terminate an > > active Mobile IPv6 session for authorization policy reasons (e.g., > > credit exhaustion). > > > > > > 5.3. Accounting > > > > G3.1 The AAA-HA interface MUST support the transfer of accounting > > records needed for service control and charging. These include > > (but may not be limited to): time of binding cache entry creation > > and deletion, octets sent and received by the mobile node in bi- > > directional tunneling, etc. > > > > > > > > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 7] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > 5.4. Mobile Node Authentication > > > > G4.1 The AAA-HA interface MUST support pass-through EAP > > authentication with the HA working as EAP authenticator operating > > in pass-through mode and the AAAH server working as back-end > > authentication server. > > > > Madjid>>Does this really have to be a MUST? > > > > 5.5. Provisioning of Configuration Parameters > > > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > > Home Address allocated to the MN (e.g., for allowing the AAAH > > server to perform a DNS update on behalf of the MN). > > > > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > > authorized to autoconfigure its Home Address. > > > > > > > > 6. Goals for the Integrated Scenario > > > > In the integrated scenario, the AAA server provides the HA > > information to the NAS as part of the whole AAA operations for > > network access. Next goals are considered in addition to those > > described in section Section 5. > > > > G6.1 The AAAH server MUST be able to communicate the Home Agent > > Information (IP Address or FQDN) to the NAS. > > > > G6.2 The NAS SHOULD be able to notify that it supports the > > functionalities described in [4]. > > > > G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can > > allocate a Home Agent to the MN. > > > > G6.4 The AAA server of the MSA MUST be able to indicate to the NAS > > whether the MN is authorized to use a local Home Agent (i.e. a > > Home Agent in the ASP/MSP) > > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 8] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > 8. Security Considerations > > > > As stated in Section 5.1 the AAA-HA interface must provide mutual > > authentication, integrity and replay protection. Furthermore, if > > security parameters (e.g., IKE pre-shared key) are transferred > > through this interface, confidentiality is strongly recommended to be > > supported. However note that AAA protocols does not support this > > unless it exists a direct connection between corresponding entities. > > > > Madjid>> Diameter supports this. should say "some AAA protocols". > > > > > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Tuesday, October 03, 2006 8:13 AM > > To: dime@ietf.org > > Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > > > FYI, please review the document. > > > > --Gerardo > > > > ---------- Forwarded message ---------- > > From: Basavaraj Patil > > Date: Oct 3, 2006 4:49 PM > > Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > To: mip6@ietf.org > > > > > > > > Hello, > > > > This is a Working group last call for the WG I-D: AAA Goals for Mobile > > IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve > > as the AAA requirements for Mobile IPv6. > > > > Please review the I-D and submit your comments to the authors or to > > the list directly. > > > > The WGLC expires on Oct 18th, 06. > > > > The I-D is intended to be published as an Informational RFC. > > > > -Raj > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 13:02:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8nm-000508-8C; Mon, 06 Nov 2006 13:02:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh8nl-0004zv-1v for mip6@ietf.org; Mon, 06 Nov 2006 13:02:29 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh8nd-0003IW-5j for mip6@ietf.org; Mon, 06 Nov 2006 13:02:29 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6I2Fpn000982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 10:02:17 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6I1YUq013702; Mon, 6 Nov 2006 10:02:14 -0800 (PST) Received: from SANEXCAS02.na.qualcomm.com ([172.30.36.176]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:02:06 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by SANEXCAS02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:02:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 10:02:05 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF4036B67@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6]concensus: issue 76: Alt CoA should not beusedwhen traversingIPv4 NAT) Thread-Index: Acb+iTcNJd8I4UIvTiGoVA+lu7BnqwAAMpjwADDOmtAAAWeDAACTVSHQAAsitiA= From: "Soliman, Hesham" To: "Pascal Thubert \(pthubert\)" , "Zhang, Qiang [NTK]" , "RYUJI WAKIKAWA" , "Narayanan, Vidya" X-OriginalArrivalTime: 06 Nov 2006 18:02:06.0814 (UTC) FILETIME=[ABF397E0:01C701CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > =20 > This is getting confusing, maybe because of the RR term. As you very > well know: >=20 > - What we are really talking about here is enabling the HA=20 > to check that > the MN can be reached at the CoA, which causes an extra latency when > roaming but does not involve the complexity of the test by the MN. >=20 > - What it mitigates is the redirection attack which can be=20 > used to bomb > an attacked server. Such a DoS attack is difficult in IPv6 because in > most cases, the MN will autoconf its address. So the bombing=20 > can only be > done against (the access of) an attacked network, not a=20 > specific host. =09 > =20 > - There can still be a MITM. But it needs to be able to=20 > forward the BA > to the MN, so it is on the way of its own attack. Combined with ESP, > this leaves little room for an attacker. In other words, we=20 > are trying > to have better locks than the neighbors :) > =20 > My point is this. We can make a simple and optional addition to the > protocol where the HA asks the MN to send a second BU. If=20 > this provides > an interesting improvement in the security level of the solution, why > not just do it? =3D> Because it adds nothing to Internet security in general. As I said = in an earlier email, these attacks are already doable today in an IPv4 Internet. So what gain to Internet security do we add by making this protocol ultra secure? This is the equivalent of installing a steel door in a glass house IMO.=20 The key principle I'm trying to follow here is "do no harm". If there are new vulnerabilities introduced that don't exist today then I agree we need to solve them, however, if those vulnerabilities already exist, then adding this would only confuse people and give a false sense of security.=20 My goal is to keep the MIPv6 packet as secure as it is today, but I don't see the benefit in designing the only secure NAT traversal mechanism (aqssuming the reachability check will actually make it secure).=20 Hesham > =09 > =09 > Pascal >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > >Sent: Friday, November 03, 2006 3:20 PM > >To: Zhang, Qiang [NTK]; RYUJI WAKIKAWA; Narayanan, Vidya > >Cc: mip6@ietf.org; Pascal Thubert (pthubert) > >Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: > [Mip6]concensus: issue 76: Alt CoA > >should not beusedwhen traversingIPv4 NAT) > > > > > > > > > I would agree the MITM attack will not compromise the > > > security provided via Ipsec ESP but rather a DoS is possible > > > if indeed the attacker got in the routing path/redirect. > > > Just a hypothesis that the issue can only be resolved > > > through hop-hop security, RR will not help on the DoS, no? > > > >=3D> RR would certainly not help with DoS, it doesn't help with DoS > today. > >But more importantly, DoS can be done today on other protocols doing > NAT > >traversal and even on any normal communication that doesn't=20 > involve MIP > >or NAT traversal. So solving it for this draft doesn't add=20 > anything to > >Internet security in general. > > > >Hesham > > > > > > > > Qiang > > > -----Original Message----- > > > From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] > > > Sent: Thursday, November 02, 2006 9:22 AM > > > To: RYUJI WAKIKAWA; Narayanan, Vidya > > > Cc: mip6@ietf.org; Pascal Thubert (pthubert) > > > Subject: RE: What are we protecting over IPv4 in DS-MIP6? > > > (RE: [Mip6]concensus: issue 76: Alt CoA should not > > > beusedwhen traversingIPv4 NAT) > > > > > > > > > > RR check can be one solution, but as other people pointed > > > out, this > causes additional round trip. > > > > In addition, if there is no NAT, we can simply protect > > > CoA by ACoA > option. > > > > > > =3D> This is not the issue being raised, the issue is the > > > insecurity of the IPv4 header when a NAT exists. The outer > > > header is obviously unprotected and vulnerable to > > > redirection attacks (an attacker acting as a NAT bascially). > > > I don't think we need to solve that problem as I indicated > > > in a previous email. > > > > > > Hesham > > > > > > > > > > > > > If HA detects that the CoA is different between IPv4 > > > header > and ACoA, > it can operate your RR check. > > > > Otherwise, it should be skipped. > > > > A new message BA-ack may be sufficient. i.e. An > > > > acknowledgment of BA > sent back from MN. > > > > > > > > ryuji > > > > > > > > On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > > > > > > > > > > > > All, > > > > > This is something I should've raised yesterday when I > > > read all the > > emails, but after sleeping over it and > > > some other > discussions, I'm > > still > > confused - > > > so, figured I should raise it now :) > > > > First, I > > > don't believe that an AltCoA option (v4 or v6) > buys anything. > > > > > Let's look at this. > > > > > > > > > > In IPv4, the outer IP address is always up for > > > > modifications and there > > is no way to distinguish an > > > adversary modifying it from a NAT > > modifying > > it. > > > And, if the outer IPv4 source address is different from the > > > > > inner IP > > address, there is no way for the HA to > > > figure out whether the > > modification is due to a NAT or > > > an adversary. Such is the > truth with > > NATs and there > > > is nothing that can be done about it. Even > if the outer > > > > > and inner IP addresses are the same, there is no way to > > > > figure out > > that > > they are the same because there > > > is no NAT or because a NAT-ed IP > > address > > in the > > > outer header has been modified back to equal the inner IP > > > > > address > > by an adversary. This is quite feasible, > > > especially when the inner > > packet is not encrypted and > > > totally depends on the intention of the > > attacker. > > > > > > > > > > The presence of the Alt-CoA option buys nothing exactly > > > > for the same > > reasons. The fact that the Alt-CoA > > > option is integrity > protected means > > nothing, since > > > the HA still must use the outer IP address > as the CoA - > > > > > and there is no guarantee about that being intact. > > > > > > > > > > We cannot pick and choose what attacks we like and what > > > we don't. > > > > > Either > > > > > we protect against redirection attacks or we don't. At > > > > this point, I'm > > saying that integrity protection of > > > the actual CoA alone proves > > nothing. > > > > > Reachability checks have more value than integrity > > > > protection of a > > field > > that is allowed to be > > > modified. Reachability checks too, in the > > absence > > > > > of confidentiality on the inner packet, does not guarantee > > > that an > > attacker is not on the path - but, it at least > > > proves that > the MN is > > reachable at that address. > > > > > > > > > > So, my vote would be to perform an optional > > > reachability check and > > document the vulnerability that > > > may still exist. > > > > > > > > > > Vidya > > > > > > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 13:36:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9K0-0004oy-RN; Mon, 06 Nov 2006 13:35:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9Jz-0004oc-NB for mip6@ietf.org; Mon, 06 Nov 2006 13:35:47 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9Jw-0007SE-02 for mip6@ietf.org; Mon, 06 Nov 2006 13:35:47 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6IZZh0015192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 10:35:35 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6IX9eB014020; Mon, 6 Nov 2006 10:35:34 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:35:19 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 10:35:08 -0800 Message-ID: In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC02F8B7D6@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2AAEFFj0A== From: "Narayanan, Vidya" To: "Pascal Thubert \(pthubert\)" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 06 Nov 2006 18:35:19.0334 (UTC) FILETIME=[4F960460:01C701D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: mip6@ietf.org, "Soliman, Hesham" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I agree on all the points. I'm not sure if we need to do RR in a separate draft essentially though... But, if we decide to live with 1, that is a moot point.=20 Vidya=20 > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 > Sent: Monday, November 06, 2006 3:14 AM > To: Narayanan, Vidya; RYUJI WAKIKAWA > Cc: Vijay Devarapalli; mip6@ietf.org; Soliman, Hesham > Subject: RE: What are we protecting over IPv4 in DS-MIP6?=20 > (RE: [Mip6] concensus: issue 76: Alt CoA should not be=20 > usedwhen traversingIPv4 NAT) >=20 > Hi Vidya >=20 > I'm with you on that.=20 >=20 > The options we have are so far: >=20 > 1) do nothing. If the MN roams in IPv4, the source is not protected. > There is a potential of an attack, but that is a difficult one, in an > IPv4 world where so many other attacks are possible anyway. >=20 > 2) provide the source IPv4 address one way or another. This=20 > approach includes Hesham's checksum. This seems to provide an=20 > IPv6 equivalent security in the absence of NAT. I'd argue=20 > that it does not really, because it is still the IPv4 world,=20 > and with IPv4 it much easier to fool a visiting MN into=20 > using, as CoA, an address that belongs to an attacked server.=20 >=20 > 3) propose an optional RR test. The test verifies that the MN=20 > is reachable at the CoA, so it protects even against NAT and=20 > rogue router in the visited network.=20 >=20 > I think we have to consider the whole picture, thus I favor=20 > 3. I could do with 1, and then we'd propose the optional RR=20 > test as a separate draft, which would be valid for all=20 > declinations of MIP6, should the WG decide that the RR test=20 > is not specific to this draft. >=20 > I have trouble with 2. People who do not really understand=20 > what it does might get a false sense of security, which can=20 > be even more dangerous. > Once this option is in, it will be hard to take it out, even=20 > when the RR test is available and actually provides a better security. >=20 > Pascal=20 >=20 >=20 >=20 >=20 > >-----Original Message----- > >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >Sent: Friday, November 03, 2006 5:00 PM > >To: RYUJI WAKIKAWA > >Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert (pthubert); > Soliman, Hesham > >Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] > concensus: issue 76: Alt CoA > >should not be usedwhen traversingIPv4 NAT) > > > >Hi Ryuji, > >I think this is missing the threat model. Let's look at two possible=20 > >scenarios. > > > >1. MN --- (Attacker) --- HA > > > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA > > > >( ) indicates that an attacker may be present. > > > >If the HA received a BU with the inner and outer addresses=20 > the same, it=20 > >has no way of telling it was due to case 1 with no attacker=20 > or case 2=20 > >with Attacker 2 who changed a NAT'ed outer address back to equal the=20 > >inner address. > > > >So, there is no use in saying that the check is done when the HA > detects > >a NAT. > > > >But, we can document this issue and say that we don't=20 > protect against=20 > >on-path attackers in IPv4, because it is complicated and not=20 > worth it. > I > >guess that's what Vijay and Hesham are saying - I could be=20 > convinced of=20 > >that, although, I don't see why we can't make the RR=20 > optional and leave=20 > >it at that. > > > >Vidya > > > > > >> -----Original Message----- > >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > >> Sent: Thursday, November 02, 2006 6:07 AM > >> To: Narayanan, Vidya > >> Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert (pthubert);=20 > >> Soliman, Hesham > >> Subject: Re: What are we protecting over IPv4 in DS-MIP6? > >> (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen=20 > >> traversingIPv4 NAT) > >> > >> Hi Vidya > >> > >> RR check can be one solution, but as other people pointed=20 > out, this=20 > >> causes additional round trip. > >> In addition, if there is no NAT, we can simply protect CoA by ACoA=20 > >> option. > >> If HA detects that the CoA is different between IPv4=20 > header and ACoA,=20 > >> it can operate your RR check. > >> Otherwise, it should be skipped. > >> A new message BA-ack may be sufficient. i.e. An=20 > acknowledgment of BA=20 > >> sent back from MN. > >> > >> ryuji > >> > >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > >> > >> > > >> > All, > >> > This is something I should've raised yesterday when I=20 > read all the=20 > >> > emails, but after sleeping over it and some other=20 > discussions, I'm=20 > >> > still confused - so, figured I should raise it now :) > >> > > >> > First, I don't believe that an AltCoA option (v4 or v6) > >> buys anything. > >> > Let's look at this. > >> > > >> > In IPv4, the outer IP address is always up for > >> modifications and there > >> > is no way to distinguish an adversary modifying it from a NAT=20 > >> > modifying it. And, if the outer IPv4 source address is > >> different from > >> > the inner IP address, there is no way for the HA to figure > >> out whether > >> > the modification is due to a NAT or an adversary. Such=20 > is the truth=20 > >> > with NATs and there is nothing that can be done about it. > >> Even if the > >> > outer and inner IP addresses are the same, there is no way > >> to figure > >> > out that they are the same because there is no NAT or > >> because a NAT-ed > >> > IP address in the outer header has been modified back to=20 > equal the=20 > >> > inner IP address by an adversary. This is quite feasible, > >> especially > >> > when the inner packet is not encrypted and totally=20 > depends on the=20 > >> > intention of the attacker. > >> > > >> > The presence of the Alt-CoA option buys nothing exactly for > >> the same > >> > reasons. The fact that the Alt-CoA option is integrity > >> protected means > >> > nothing, since the HA still must use the outer IP address > >> as the CoA - > >> > and there is no guarantee about that being intact. > >> > > >> > We cannot pick and choose what attacks we like and what we don't. > >> > Either > >> > we protect against redirection attacks or we don't. At this > >> point, I'm > >> > saying that integrity protection of the actual CoA alone proves=20 > >> > nothing. > >> > Reachability checks have more value than integrity=20 > protection of a=20 > >> > field that is allowed to be modified. Reachability checks > >> too, in the > >> > absence of confidentiality on the inner packet, does not=20 > guarantee=20 > >> > that an attacker is not on the path - but, it at least > >> proves that the > >> > MN is reachable at that address. > >> > > >> > So, my vote would be to perform an optional reachability=20 > check and=20 > >> > document the vulnerability that may still exist. > >> > > >> > Vidya > >> > > >> > _______________________________________________ > >> > Mip6 mailing list > >> > Mip6@ietf.org > >> > https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 13:36:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9L8-0005Nq-SV; Mon, 06 Nov 2006 13:36:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9L8-0005Nk-5t for mip6@ietf.org; Mon, 06 Nov 2006 13:36:58 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9L4-0007at-HE for mip6@ietf.org; Mon, 06 Nov 2006 13:36:58 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6IamcV005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 10:36:49 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6IaAxg027319; Mon, 6 Nov 2006 10:36:47 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:35:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 10:35:39 -0800 Message-ID: In-Reply-To: <2309978910A6A6478C2C7585692B0AF4036B66@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2AADt0eIAABfSeg From: "Narayanan, Vidya" To: "Soliman, Hesham" , "Pascal Thubert \(pthubert\)" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 06 Nov 2006 18:35:53.0045 (UTC) FILETIME=[63ADE850:01C701D2] X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > -----Original Message----- > From: Soliman, Hesham=20 > Sent: Monday, November 06, 2006 9:55 AM > To: Pascal Thubert (pthubert); Narayanan, Vidya; RYUJI WAKIKAWA > Cc: Vijay Devarapalli; mip6@ietf.org > Subject: RE: What are we protecting over IPv4 in DS-MIP6?=20 > (RE: [Mip6] concensus: issue 76: Alt CoA should not be=20 > usedwhen traversingIPv4 NAT) >=20 > Hi Pascal, =20 >=20 > The options you list below are mixing two different problems=20 > together.=20 >=20 > There were two issues discussed: >=20 > A. Integrity of the CoA in the IPv6 packet What is this buying you, when the HA must be using the outer one anyway? Vidya >=20 > B. Integrity of the IPv4 header.=20 >=20 > Option 2) below is intended for A) above and option 3) was=20 > discussed to address B. I hope it's clear that the options=20 > you list below are not alternatives as they address different=20 > problems. >=20 > Hesham >=20 >=20 > > I'm with you on that.=20 > > > > The options we have are so far: > > > > 1) do nothing. If the MN roams in IPv4, the source is not=20 > protected. > > There is a potential of an attack, but that is a difficult=20 > one, in an > IPv4 world where so many other attacks are=20 > possible anyway. > > > > 2) provide the source IPv4 address one way or another.=20 > This approach > includes Hesham's checksum. This seems to=20 > provide an IPv6 equivalent > security in the absence of NAT.=20 > I'd argue that it does not really, > because it is still the=20 > IPv4 world, and with IPv4 it much > easier to fool > a=20 > visiting MN into using, as CoA, an address that belongs to >=20 > an attacked > server.=20 > > > > 3) propose an optional RR test. The test verifies that the=20 > MN is > reachable at the CoA, so it protects even against=20 > NAT and > rogue router > in the visited network.=20 > > > > I think we have to consider the whole picture, thus I=20 > favor > 3. I could > do with 1, and then we'd propose the=20 > optional RR test as a separate > draft, which would be valid=20 > for all declinations of MIP6, > should the WG > decide that=20 > the RR test is not specific to this draft. > > > > I have trouble with 2. People who do not really understand=20 > > what it does > might get a false sense of security, which=20 > can be even more > dangerous. > > Once this option is in, it will be hard to take it out,=20 > even > when the RR > test is available and actually=20 > provides a better security. > > > > Pascal > > > > > > > > > > >-----Original Message----- > > >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >=20 > >Sent: Friday, November 03, 2006 5:00 PM > >To: RYUJI=20 > WAKIKAWA > >Cc: Vijay Devarapalli; mip6@ietf.org; Pascal=20 > Thubert (pthubert); > Soliman, Hesham > >Subject: RE: What=20 > are we protecting over IPv4 in DS-MIP6?=20 > > (RE: [Mip6] > > concensus: issue 76: Alt CoA > > >should not be usedwhen traversingIPv4 NAT) > > > >Hi=20 > Ryuji, > >I think this is missing the threat model. Let's=20 > look at two possible > >scenarios. > > > > > >1. MN --- (Attacker) --- HA > > > > > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA > >=20 > > >( ) indicates that an attacker may be present. > > > > > >If the HA received a BU with the inner and outer=20 > addresses > the same, it > >has no way of telling it was=20 > due to case 1 with no attacker > or case 2 > >with Attacker=20 > 2 who changed a NAT'ed outer address back to equal the >=20 > >inner address. > > > > > >So, there is no use in saying that the check is done when=20 > the HA > detects > >a NAT. > > > > > >But, we can document this issue and say that we don't >=20 > protect against > >on-path attackers in IPv4, because it is=20 > complicated and > not worth it. > > I > > >guess that's what Vijay and Hesham are saying - I could=20 > be > convinced of > >that, although, I don't see why we=20 > can't make the RR > optional and leave > >it at that. > > > > > >Vidya > > > > > > > > >> -----Original Message----- > > >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] =20 > > >> Sent: Thursday, November 02, 2006 6:07 AM > >> To:=20 > Narayanan, Vidya > >> Cc: Vijay Devarapalli; mip6@ietf.org;=20 > Pascal Thubert > >> (pthubert); Soliman, Hesham > >>=20 > Subject: Re: What are we protecting over IPv4 in DS-MIP6? > > >> (RE: [Mip6] concensus: issue 76: Alt CoA should not be =20 > > >> usedwhen traversingIPv4 NAT) > >> > >> Hi Vidya > >> =20 > > >> RR check can be one solution, but as other people=20 > pointed > >> out, this causes additional round trip. > > >> In addition, if there is no NAT, we can simply protect=20 > CoA by > >> ACoA option. > > >> If HA detects that the CoA is different between IPv4=20 > header > >> and ACoA, it can operate your RR check. > > >> Otherwise, it should be skipped. > > >> A new message BA-ack may be sufficient. i.e. An > >>=20 > acknowledgment of BA sent back from MN. > > >> > > >> ryuji > > >> > > >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > >> > > >> > > > >> > All, > > >> > This is something I should've raised yesterday when I=20 > > read all the > >> > emails, but after sleeping over it=20 > and some other > discussions, I'm > >> > still confused -=20 > so, figured I should raise it now :) > >> > > >> > First, I=20 > don't believe that an AltCoA option (v4 or v6) > >> buys anything. > > >> > Let's look at this. > > >> > > > >> > In IPv4, the outer IP address is always up for > >>=20 > modifications and there > >> > is no way to distinguish an=20 > adversary modifying it from a NAT > >> > modifying it. And,=20 > if the outer IPv4 source address is > >> different from >=20 > >> > the inner IP address, there is no way for the HA to=20 > figure > >> out whether > >> > the modification is due to a=20 > NAT or an adversary. Such > is the truth > >> > with NATs=20 > and there is nothing that can be done about it. > > >> Even if the > > >> > outer and inner IP addresses are the same, there is=20 > no way > >> to figure > >> > out that they are the same=20 > because there is no NAT or > >> because a NAT-ed > >> > IP=20 > address in the outer header has been modified back > to=20 > equal the > >> > inner IP address by an adversary. This is=20 > quite feasible, > >> especially > >> > when the inner=20 > packet is not encrypted and totally > depends on the > >> >=20 > intention of the attacker. > > >> > > > >> > The presence of the Alt-CoA option buys nothing=20 > exactly for > >> the same > >> > reasons. The fact that the=20 > Alt-CoA option is integrity > >> protected means > >> >=20 > nothing, since the HA still must use the outer IP address >=20 > >> as the CoA - > >> > and there is no guarantee about that=20 > being intact. > > >> > > > >> > We cannot pick and choose what attacks we like and=20 > what > we don't. > > >> > Either > > >> > we protect against redirection attacks or we don't.=20 > At this > >> point, I'm > >> > saying that integrity=20 > protection of the actual CoA alone proves > >> > nothing. > > >> > Reachability checks have more value than integrity >=20 > protection of a > >> > field that is allowed to be modified.=20 > Reachability checks > >> too, in the > >> > absence of=20 > confidentiality on the inner packet, does > not guarantee >=20 > >> > that an attacker is not on the path - but, it at least =20 > > >> proves that the > >> > MN is reachable at that address. > > >> > > > >> > So, my vote would be to perform an optional >=20 > reachability check and > >> > document the vulnerability=20 > that may still exist. > > >> > > > >> > Vidya > > >> > > > >> > _______________________________________________ > > >> > Mip6 mailing list > > >> > Mip6@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/mip6 > > >> > > >> > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 14:14:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9ua-0003lh-PP; Mon, 06 Nov 2006 14:13:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh9nZ-0000HB-5T for mip6@ietf.org; Mon, 06 Nov 2006 14:06:21 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh9jH-0001Rs-4C for mip6@ietf.org; Mon, 06 Nov 2006 14:01:56 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6J1VVD019701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 11:01:33 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.na.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6J0YnI024732; Mon, 6 Nov 2006 11:01:30 -0800 (PST) Received: from sanexcas01.na.qualcomm.com ([172.30.36.175]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:59:38 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 10:59:38 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 10:59:36 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF4059C33@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2AADt0eIAABfSegAADGrcA= From: "Soliman, Hesham" To: "Narayanan, Vidya" , "Pascal Thubert \(pthubert\)" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 06 Nov 2006 18:59:38.0042 (UTC) FILETIME=[B50B31A0:01C701D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > There were two issues discussed: > >=20 > > A. Integrity of the CoA in the IPv6 packet >=20 > What is this buying you, when the HA must be using the outer=20 > one anyway?=20 =3D> Well, DSMIP is not limited to be used when NATs are available. It = can be used in public IPv4 networks where no NATs exist, or where no NAT exist between the MN and an HA in the same domain. So, what this buys is the same security as MIPv6 when no NATs exist.=20 Hesham >=20 > Vidya >=20 >=20 > >=20 > > B. Integrity of the IPv4 header.=20 > >=20 > > Option 2) below is intended for A) above and option 3) was=20 > > discussed to address B. I hope it's clear that the options=20 > > you list below are not alternatives as they address different=20 > > problems. > >=20 > > Hesham > >=20 > >=20 > > > I'm with you on that.=20 > > > > > > The options we have are so far: > > > > > > 1) do nothing. If the MN roams in IPv4, the source is not=20 > > protected. > > > There is a potential of an attack, but that is a difficult=20 > > one, in an > IPv4 world where so many other attacks are=20 > > possible anyway. > > > > > > 2) provide the source IPv4 address one way or another.=20 > > This approach > includes Hesham's checksum. This seems to=20 > > provide an IPv6 equivalent > security in the absence of NAT.=20 > > I'd argue that it does not really, > because it is still the=20 > > IPv4 world, and with IPv4 it much > easier to fool > a=20 > > visiting MN into using, as CoA, an address that belongs to >=20 > > an attacked > server.=20 > > > > > > 3) propose an optional RR test. The test verifies that the=20 > > MN is > reachable at the CoA, so it protects even against=20 > > NAT and > rogue router > in the visited network.=20 > > > > > > I think we have to consider the whole picture, thus I=20 > > favor > 3. I could > do with 1, and then we'd propose the=20 > > optional RR test as a separate > draft, which would be valid=20 > > for all declinations of MIP6, > should the WG > decide that=20 > > the RR test is not specific to this draft. > > > > > > I have trouble with 2. People who do not really understand=20 > > > what it does > might get a false sense of security, which=20 > > can be even more > dangerous. > > > Once this option is in, it will be hard to take it out,=20 > > even > when the RR > test is available and actually=20 > > provides a better security. > > > > > > Pascal > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >=20 > > >Sent: Friday, November 03, 2006 5:00 PM > >To: RYUJI=20 > > WAKIKAWA > >Cc: Vijay Devarapalli; mip6@ietf.org; Pascal=20 > > Thubert (pthubert); > Soliman, Hesham > >Subject: RE: What=20 > > are we protecting over IPv4 in DS-MIP6?=20 > > > (RE: [Mip6] > > > concensus: issue 76: Alt CoA > > > >should not be usedwhen traversingIPv4 NAT) > > > >Hi=20 > > Ryuji, > >I think this is missing the threat model. Let's=20 > > look at two possible > >scenarios. > > > > > > > >1. MN --- (Attacker) --- HA > > > > > > > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA > >=20 > > > >( ) indicates that an attacker may be present. > > > > > > > >If the HA received a BU with the inner and outer=20 > > addresses > the same, it > >has no way of telling it was=20 > > due to case 1 with no attacker > or case 2 > >with Attacker=20 > > 2 who changed a NAT'ed outer address back to equal the >=20 > > >inner address. > > > > > > > >So, there is no use in saying that the check is done when=20 > > the HA > detects > >a NAT. > > > > > > > >But, we can document this issue and say that we don't >=20 > > protect against > >on-path attackers in IPv4, because it is=20 > > complicated and > not worth it. > > > I > > > >guess that's what Vijay and Hesham are saying - I could=20 > > be > convinced of > >that, although, I don't see why we=20 > > can't make the RR > optional and leave > >it at that. > > > > > > > >Vidya > > > > > > > > > > > >> -----Original Message----- > > > >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] =20 > > > >> Sent: Thursday, November 02, 2006 6:07 AM > >> To:=20 > > Narayanan, Vidya > >> Cc: Vijay Devarapalli; mip6@ietf.org;=20 > > Pascal Thubert > >> (pthubert); Soliman, Hesham > >>=20 > > Subject: Re: What are we protecting over IPv4 in DS-MIP6? > > > >> (RE: [Mip6] concensus: issue 76: Alt CoA should not be =20 > > > >> usedwhen traversingIPv4 NAT) > >> > >> Hi Vidya > >> =20 > > > >> RR check can be one solution, but as other people=20 > > pointed > >> out, this causes additional round trip. > > > >> In addition, if there is no NAT, we can simply protect=20 > > CoA by > >> ACoA option. > > > >> If HA detects that the CoA is different between IPv4=20 > > header > >> and ACoA, it can operate your RR check. > > > >> Otherwise, it should be skipped. > > > >> A new message BA-ack may be sufficient. i.e. An > >>=20 > > acknowledgment of BA sent back from MN. > > > >> > > > >> ryuji > > > >> > > > >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > >> > > > >> > > > > >> > All, > > > >> > This is something I should've raised yesterday when I=20 > > > read all the > >> > emails, but after sleeping over it=20 > > and some other > discussions, I'm > >> > still confused -=20 > > so, figured I should raise it now :) > >> > > >> > First, I=20 > > don't believe that an AltCoA option (v4 or v6) > >> buys anything. > > > >> > Let's look at this. > > > >> > > > > >> > In IPv4, the outer IP address is always up for > >>=20 > > modifications and there > >> > is no way to distinguish an=20 > > adversary modifying it from a NAT > >> > modifying it. And,=20 > > if the outer IPv4 source address is > >> different from >=20 > > >> > the inner IP address, there is no way for the HA to=20 > > figure > >> out whether > >> > the modification is due to a=20 > > NAT or an adversary. Such > is the truth > >> > with NATs=20 > > and there is nothing that can be done about it. > > > >> Even if the > > > >> > outer and inner IP addresses are the same, there is=20 > > no way > >> to figure > >> > out that they are the same=20 > > because there is no NAT or > >> because a NAT-ed > >> > IP=20 > > address in the outer header has been modified back > to=20 > > equal the > >> > inner IP address by an adversary. This is=20 > > quite feasible, > >> especially > >> > when the inner=20 > > packet is not encrypted and totally > depends on the > >> >=20 > > intention of the attacker. > > > >> > > > > >> > The presence of the Alt-CoA option buys nothing=20 > > exactly for > >> the same > >> > reasons. The fact that the=20 > > Alt-CoA option is integrity > >> protected means > >> >=20 > > nothing, since the HA still must use the outer IP address >=20 > > >> as the CoA - > >> > and there is no guarantee about that=20 > > being intact. > > > >> > > > > >> > We cannot pick and choose what attacks we like and=20 > > what > we don't. > > > >> > Either > > > >> > we protect against redirection attacks or we don't.=20 > > At this > >> point, I'm > >> > saying that integrity=20 > > protection of the actual CoA alone proves > >> > nothing. > > > >> > Reachability checks have more value than integrity >=20 > > protection of a > >> > field that is allowed to be modified.=20 > > Reachability checks > >> too, in the > >> > absence of=20 > > confidentiality on the inner packet, does > not guarantee >=20 > > >> > that an attacker is not on the path - but, it at least =20 > > > >> proves that the > >> > MN is reachable at that address. > > > >> > > > > >> > So, my vote would be to perform an optional >=20 > > reachability check and > >> > document the vulnerability=20 > > that may still exist. > > > >> > > > > >> > Vidya > > > >> > > > > >> > _______________________________________________ > > > >> > Mip6 mailing list > > > >> > Mip6@ietf.org > > > >> > https://www1.ietf.org/mailman/listinfo/mip6 > > > >> > > > >> > > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 14:32:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhACO-0006mX-5O; Mon, 06 Nov 2006 14:32:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhACM-0006mS-PL for mip6@ietf.org; Mon, 06 Nov 2006 14:31:58 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhACL-0005HJ-4f for mip6@ietf.org; Mon, 06 Nov 2006 14:31:58 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6JVjD5013216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 11:31:47 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6JUoTa004790; Mon, 6 Nov 2006 11:31:44 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:31:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 11:31:26 -0800 Message-ID: In-Reply-To: <2309978910A6A6478C2C7585692B0AF4059C33@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2AADt0eIAABfSegAADGrcAAAR+i8A== From: "Narayanan, Vidya" To: "Soliman, Hesham" , "Pascal Thubert \(pthubert\)" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 06 Nov 2006 19:31:33.0428 (UTC) FILETIME=[2AB3E740:01C701DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 >=20 > > > There were two issues discussed: > > > > > > A. Integrity of the CoA in the IPv6 packet > > What is=20 > this buying you, when the HA must be using the outer > one anyway?=20 >=20 > =3D> Well, DSMIP is not limited to be used when NATs are=20 > available. It can be used in public IPv4 networks where no=20 > NATs exist, or where no NAT exist between the MN and an HA in=20 > the same domain. So, what this buys is the same security as=20 > MIPv6 when no NATs exist.=20 >=20 No, it doesn't, since there is no way to figure out whether there were NATs + an attacker or just NATs or no NATs. Please see my response to Ryuji where I explained this with an illustration.=20 Vidya > Hesham >=20 > > > > Vidya > > > > > > > > > > B. Integrity of the IPv4 header.=20 > > > > > > Option 2) below is intended for A) above and option 3)=20 > was > > discussed to address B. I hope it's clear that the=20 > options > > you list below are not alternatives as they=20 > address different > > problems. > > > > > > Hesham > > > > > > > > > > I'm with you on that.=20 > > > > > > > > The options we have are so far: > > > > > > > > 1) do nothing. If the MN roams in IPv4, the source is=20 > not > > protected. > > > > There is a potential of an attack, but that is a=20 > difficult > > one, in an > IPv4 world where so many other=20 > attacks are > > possible anyway. > > > > > > > > 2) provide the source IPv4 address one way or another.=20 > > > This approach > includes Hesham's checksum. This seems=20 > to > > provide an IPv6 equivalent > security in the absence of NAT.=20 > > > I'd argue that it does not really, > because it is=20 > still the > > IPv4 world, and with IPv4 it much > easier to=20 > fool > a > > visiting MN into using, as CoA, an address=20 > that belongs to > > > an attacked > server.=20 > > > > > > > > 3) propose an optional RR test. The test verifies=20 > that the > > MN is > reachable at the CoA, so it protects=20 > even against > > NAT and > rogue router > in the visited network.=20 > > > > > > > > I think we have to consider the whole picture, thus I=20 > > > favor > 3. I could > do with 1, and then we'd propose=20 > the > > optional RR test as a separate > draft, which would=20 > be valid > > for all declinations of MIP6, > should the WG =20 > > decide that > > the RR test is not specific to this draft. > > > > > > > > I have trouble with 2. People who do not really=20 > understand > > > what it does > might get a false sense of=20 > security, which > > can be even more > dangerous. > > > > Once this option is in, it will be hard to take it=20 > out, > > even > when the RR > test is available and=20 > actually > > provides a better security. > > > > > > > > Pascal > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] =20 > > > > >Sent: Friday, November 03, 2006 5:00 PM > >To: RYUJI=20 > > > WAKIKAWA > >Cc: Vijay Devarapalli; mip6@ietf.org;=20 > Pascal > > Thubert (pthubert); > Soliman, Hesham >=20 > >Subject: RE: What > > are we protecting over IPv4 in DS-MIP6?=20 > > > > (RE: [Mip6] > > > > concensus: issue 76: Alt CoA > > > > >should not be usedwhen traversingIPv4 NAT) > > >=20 > >Hi > > Ryuji, > >I think this is missing the threat model.=20 > Let's > > look at two possible > >scenarios. > > > > > > > > > >1. MN --- (Attacker) --- HA > > > > > > > > > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA=20 > > > > > > >( ) indicates that an attacker may be present. > > > > > > > > > >If the HA received a BU with the inner and outer >=20 > > addresses > the same, it > >has no way of telling it was =20 > > > due to case 1 with no attacker > or case 2 > >with=20 > Attacker > > 2 who changed a NAT'ed outer address back to=20 > equal the > > > >inner address. > > > > > > > > > >So, there is no use in saying that the check is done=20 > when > > the HA > detects > >a NAT. > > > > > > > > > >But, we can document this issue and say that we=20 > don't > > > protect against > >on-path attackers in IPv4,=20 > because it is > > complicated and > not worth it. > > > > I > > > > >guess that's what Vijay and Hesham are saying - I=20 > could > > be > convinced of > >that, although, I don't see=20 > why we > > can't make the RR > optional and leave > >it at that. > > > > > > > > > >Vidya > > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: RYUJI WAKIKAWA=20 > [mailto:ryuji.wakikawa@gmail.com] > > > >> Sent: Thursday,=20 > November 02, 2006 6:07 AM > >> To:=20 > > > Narayanan, Vidya > >> Cc: Vijay Devarapalli;=20 > mip6@ietf.org; > > Pascal Thubert > >> (pthubert); Soliman,=20 > Hesham > >> > > Subject: Re: What are we protecting over=20 > IPv4 in DS-MIP6? > > > > >> (RE: [Mip6] concensus: issue 76: Alt CoA should=20 > not be > > > >> usedwhen traversingIPv4 NAT) > >> > >> Hi=20 > Vidya > >> > > > >> RR check can be one solution, but as=20 > other people > > pointed > >> out, this causes additional=20 > round trip. > > > > >> In addition, if there is no NAT, we can simply=20 > protect > > CoA by > >> ACoA option. > > > > >> If HA detects that the CoA is different between=20 > IPv4 > > header > >> and ACoA, it can operate your RR check. > > > > >> Otherwise, it should be skipped. > > > > >> A new message BA-ack may be sufficient. i.e. An >=20 > >> > > acknowledgment of BA sent back from MN. > > > > >> > > > > >> ryuji > > > > >> > > > > >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > > >> > > > > >> > > > > > >> > All, > > > > >> > This is something I should've raised yesterday=20 > when I > > > read all the > >> > emails, but after=20 > sleeping over it > > and some other > discussions, I'm >=20 > >> > still confused - > > so, figured I should raise it now=20 > :) > >> > > >> > First, I > > don't believe that an AltCoA=20 > option (v4 or v6) > >> buys anything. > > > > >> > Let's look at this. > > > > >> > > > > > >> > In IPv4, the outer IP address is always up for =20 > > >> > > modifications and there > >> > is no way to=20 > distinguish an > > adversary modifying it from a NAT > >> >=20 > modifying it. And, > > if the outer IPv4 source address is =20 > > >> different from > > > >> > the inner IP address, there=20 > is no way for the HA to > > figure > >> out whether > >> >=20 > the modification is due to a > > NAT or an adversary. Such =20 > > is the truth > >> > with NATs > > and there is nothing=20 > that can be done about it. > > > > >> Even if the > > > > >> > outer and inner IP addresses are the same, there=20 > is > > no way > >> to figure > >> > out that they are the=20 > same > > because there is no NAT or > >> because a NAT-ed =20 > > >> > IP > > address in the outer header has been modified=20 > back > to > > equal the > >> > inner IP address by an=20 > adversary. This is > > quite feasible, > >> especially >=20 > >> > when the inner > > packet is not encrypted and totally =20 > > depends on the > >> > > > intention of the attacker. > > > > >> > > > > > >> > The presence of the Alt-CoA option buys nothing =20 > > > exactly for > >> the same > >> > reasons. The fact that=20 > the > > Alt-CoA option is integrity > >> protected means >=20 > >> > > > nothing, since the HA still must use the outer IP=20 > address > > > >> as the CoA - > >> > and there is no=20 > guarantee about that > > being intact. > > > > >> > > > > > >> > We cannot pick and choose what attacks we like=20 > and > > what > we don't. > > > > >> > Either > > > > >> > we protect against redirection attacks or we don't.=20 > > > At this > >> point, I'm > >> > saying that integrity =20 > > > protection of the actual CoA alone proves > >> > nothing. > > > > >> > Reachability checks have more value than=20 > integrity > > > protection of a > >> > field that is=20 > allowed to be modified.=20 > > > Reachability checks > >> too, in the > >> > absence of=20 > > > confidentiality on the inner packet, does > not=20 > guarantee > > > >> > that an attacker is not on the path -=20 > but, it at least > > > >> proves that the > >> > MN is=20 > reachable at that address. > > > > >> > > > > > >> > So, my vote would be to perform an optional > =20 > > > reachability check and > >> > document the vulnerability=20 > > > that may still exist. > > > > >> > > > > > >> > Vidya > > > > >> > > > > > >> > _______________________________________________ > > > > >> > Mip6 mailing list > > > > >> > Mip6@ietf.org > > > > >> > https://www1.ietf.org/mailman/listinfo/mip6 > > > > >> > > > > >> > > > > > > > > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 14:51:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAUj-0004DI-WD; Mon, 06 Nov 2006 14:50:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhAUj-0004D7-8E for mip6@ietf.org; Mon, 06 Nov 2006 14:50:57 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhAUg-0007L6-Gr for mip6@ietf.org; Mon, 06 Nov 2006 14:50:57 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6JojOS028796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 11:50:46 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6JoCsk016690; Mon, 6 Nov 2006 11:50:39 -0800 (PST) Received: from sanexcas01.na.qualcomm.com ([172.30.36.175]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:50:25 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 11:50:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 11:50:23 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF4059C43@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2AADt0eIAABfSegAADGrcAAAR+i8AAAl82Q From: "Soliman, Hesham" To: "Narayanan, Vidya" , "Pascal Thubert \(pthubert\)" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 06 Nov 2006 19:50:25.0120 (UTC) FILETIME=[CD3E6600:01C701DC] X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > > =3D> Well, DSMIP is not limited to be used when NATs are=20 > > available. It can be used in public IPv4 networks where no=20 > > NATs exist, or where no NAT exist between the MN and an HA in=20 > > the same domain. So, what this buys is the same security as=20 > > MIPv6 when no NATs exist.=20 > >=20 >=20 > No, it doesn't, since there is no way to figure out whether=20 > there were NATs + an attacker or just NATs or no NATs.=20 > Please see my response to Ryuji where I explained this with=20 > an illustration.=20 =3D> Yes I read all emails about the draft. The point is, we're making = the v6 packet as secure as MIPv6. Now, the receiver (HA/MAP) can use the fact that the v6 packet is secure for their advantage. For instance, if the receiver *knows* that no NATs exist, then it can trust the v6 information. If it doesn't then it won't be able to do that. So I see no harm in keeping the v6 packet secure, it can only be a benefit/requirement. Why should we not secure the v6 packet? Hesham >=20 > Vidya >=20 >=20 > > Hesham > >=20 > > > > > > Vidya > > > > > > > > > > > > > > B. Integrity of the IPv4 header.=20 > > > > > > > > Option 2) below is intended for A) above and option 3)=20 > > was > > discussed to address B. I hope it's clear that the=20 > > options > > you list below are not alternatives as they=20 > > address different > > problems. > > > > > > > > Hesham > > > > > > > > > > > > > I'm with you on that.=20 > > > > > > > > > > The options we have are so far: > > > > > > > > > > 1) do nothing. If the MN roams in IPv4, the source is=20 > > not > > protected. > > > > > There is a potential of an attack, but that is a=20 > > difficult > > one, in an > IPv4 world where so many other=20 > > attacks are > > possible anyway. > > > > > > > > > > 2) provide the source IPv4 address one way or another.=20 > > > > This approach > includes Hesham's checksum. This seems=20 > > to > > provide an IPv6 equivalent > security in the=20 > absence of NAT.=20 > > > > I'd argue that it does not really, > because it is=20 > > still the > > IPv4 world, and with IPv4 it much > easier to=20 > > fool > a > > visiting MN into using, as CoA, an address=20 > > that belongs to > > > an attacked > server.=20 > > > > > > > > > > 3) propose an optional RR test. The test verifies=20 > > that the > > MN is > reachable at the CoA, so it protects=20 > > even against > > NAT and > rogue router > in the=20 > visited network.=20 > > > > > > > > > > I think we have to consider the whole picture, thus I=20 > > > > favor > 3. I could > do with 1, and then we'd propose=20 > > the > > optional RR test as a separate > draft, which would=20 > > be valid > > for all declinations of MIP6, > should the WG =20 > > > decide that > > the RR test is not specific to this draft. > > > > > > > > > > I have trouble with 2. People who do not really=20 > > understand > > > what it does > might get a false sense of=20 > > security, which > > can be even more > dangerous. > > > > > Once this option is in, it will be hard to take it=20 > > out, > > even > when the RR > test is available and=20 > > actually > > provides a better security. > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] =20 > > > > > >Sent: Friday, November 03, 2006 5:00 PM > >To: RYUJI=20 > > > > WAKIKAWA > >Cc: Vijay Devarapalli; mip6@ietf.org;=20 > > Pascal > > Thubert (pthubert); > Soliman, Hesham >=20 > > >Subject: RE: What > > are we protecting over IPv4 in DS-MIP6?=20 > > > > > (RE: [Mip6] > > > > > concensus: issue 76: Alt CoA > > > > > >should not be usedwhen traversingIPv4 NAT) > > >=20 > > >Hi > > Ryuji, > >I think this is missing the threat model.=20 > > Let's > > look at two possible > >scenarios. > > > > > > > > > > > >1. MN --- (Attacker) --- HA > > > > > > > > > > > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA=20 > > > > > > > >( ) indicates that an attacker may be present. > > > > > > > > > > > >If the HA received a BU with the inner and outer >=20 > > > addresses > the same, it > >has no way of telling it was =20 > > > > due to case 1 with no attacker > or case 2 > >with=20 > > Attacker > > 2 who changed a NAT'ed outer address back to=20 > > equal the > > > >inner address. > > > > > > > > > > > >So, there is no use in saying that the check is done=20 > > when > > the HA > detects > >a NAT. > > > > > > > > > > > >But, we can document this issue and say that we=20 > > don't > > > protect against > >on-path attackers in IPv4,=20 > > because it is > > complicated and > not worth it. > > > > > I > > > > > >guess that's what Vijay and Hesham are saying - I=20 > > could > > be > convinced of > >that, although, I don't see=20 > > why we > > can't make the RR > optional and leave > >it at that. > > > > > > > > > > > >Vidya > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: RYUJI WAKIKAWA=20 > > [mailto:ryuji.wakikawa@gmail.com] > > > >> Sent: Thursday,=20 > > November 02, 2006 6:07 AM > >> To:=20 > > > > Narayanan, Vidya > >> Cc: Vijay Devarapalli;=20 > > mip6@ietf.org; > > Pascal Thubert > >> (pthubert); Soliman,=20 > > Hesham > >> > > Subject: Re: What are we protecting over=20 > > IPv4 in DS-MIP6? > > > > > >> (RE: [Mip6] concensus: issue 76: Alt CoA should=20 > > not be > > > >> usedwhen traversingIPv4 NAT) > >> > >> Hi=20 > > Vidya > >> > > > >> RR check can be one solution, but as=20 > > other people > > pointed > >> out, this causes additional=20 > > round trip. > > > > > >> In addition, if there is no NAT, we can simply=20 > > protect > > CoA by > >> ACoA option. > > > > > >> If HA detects that the CoA is different between=20 > > IPv4 > > header > >> and ACoA, it can operate your RR check. > > > > > >> Otherwise, it should be skipped. > > > > > >> A new message BA-ack may be sufficient. i.e. An >=20 > > >> > > acknowledgment of BA sent back from MN. > > > > > >> > > > > > >> ryuji > > > > > >> > > > > > >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > > > >> > > > > > >> > > > > > > >> > All, > > > > > >> > This is something I should've raised yesterday=20 > > when I > > > read all the > >> > emails, but after=20 > > sleeping over it > > and some other > discussions, I'm >=20 > > >> > still confused - > > so, figured I should raise it now=20 > > :) > >> > > >> > First, I > > don't believe that an AltCoA=20 > > option (v4 or v6) > >> buys anything. > > > > > >> > Let's look at this. > > > > > >> > > > > > > >> > In IPv4, the outer IP address is always up for =20 > > > >> > > modifications and there > >> > is no way to=20 > > distinguish an > > adversary modifying it from a NAT > >> >=20 > > modifying it. And, > > if the outer IPv4 source address is =20 > > > >> different from > > > >> > the inner IP address, there=20 > > is no way for the HA to > > figure > >> out whether > >> >=20 > > the modification is due to a > > NAT or an adversary. Such =20 > > > is the truth > >> > with NATs > > and there is nothing=20 > > that can be done about it. > > > > > >> Even if the > > > > > >> > outer and inner IP addresses are the same, there=20 > > is > > no way > >> to figure > >> > out that they are the=20 > > same > > because there is no NAT or > >> because a NAT-ed =20 > > > >> > IP > > address in the outer header has been modified=20 > > back > to > > equal the > >> > inner IP address by an=20 > > adversary. This is > > quite feasible, > >> especially >=20 > > >> > when the inner > > packet is not encrypted and totally =20 > > > depends on the > >> > > > intention of the attacker. > > > > > >> > > > > > > >> > The presence of the Alt-CoA option buys nothing =20 > > > > exactly for > >> the same > >> > reasons. The fact that=20 > > the > > Alt-CoA option is integrity > >> protected means >=20 > > >> > > > nothing, since the HA still must use the outer IP=20 > > address > > > >> as the CoA - > >> > and there is no=20 > > guarantee about that > > being intact. > > > > > >> > > > > > > >> > We cannot pick and choose what attacks we like=20 > > and > > what > we don't. > > > > > >> > Either > > > > > >> > we protect against redirection attacks or we don't.=20 > > > > At this > >> point, I'm > >> > saying that integrity =20 > > > > protection of the actual CoA alone proves > >> > nothing. > > > > > >> > Reachability checks have more value than=20 > > integrity > > > protection of a > >> > field that is=20 > > allowed to be modified.=20 > > > > Reachability checks > >> too, in the > >> > absence of=20 > > > > confidentiality on the inner packet, does > not=20 > > guarantee > > > >> > that an attacker is not on the path -=20 > > but, it at least > > > >> proves that the > >> > MN is=20 > > reachable at that address. > > > > > >> > > > > > > >> > So, my vote would be to perform an optional > =20 > > > > reachability check and > >> > document the vulnerability=20 > > > > that may still exist. > > > > > >> > > > > > > >> > Vidya > > > > > >> > > > > > > >> > _______________________________________________ > > > > > >> > Mip6 mailing list > > > > > >> > Mip6@ietf.org > > > > > >> > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > >> > > > > > >> > > > > > > > > > > > >=20 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 17:27:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCvO-0000sv-4U; Mon, 06 Nov 2006 17:26:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCvN-0000sl-0A for mip6@ietf.org; Mon, 06 Nov 2006 17:26:37 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCvI-0005x3-7Z for mip6@ietf.org; Mon, 06 Nov 2006 17:26:36 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kA6MQP05022922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 14:26:26 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.141.78]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kA6MQMIp013809; Mon, 6 Nov 2006 14:26:24 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 14:26:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Mon, 6 Nov 2006 14:26:21 -0800 Message-ID: In-Reply-To: <2309978910A6A6478C2C7585692B0AF4059C43@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2AADt0eIAABfSegAADGrcAAAR+i8AAAl82QAAUDXOA= From: "Narayanan, Vidya" To: "Soliman, Hesham" , "Pascal Thubert \(pthubert\)" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 06 Nov 2006 22:26:24.0100 (UTC) FILETIME=[97A16A40:01C701F2] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org =20 > -----Original Message----- > From: Soliman, Hesham=20 > Sent: Monday, November 06, 2006 11:50 AM > To: Narayanan, Vidya; 'Pascal Thubert (pthubert)'; 'RYUJI WAKIKAWA' > Cc: 'Vijay Devarapalli'; 'mip6@ietf.org' > Subject: RE: What are we protecting over IPv4 in DS-MIP6?=20 > (RE: [Mip6] concensus: issue 76: Alt CoA should not be=20 > usedwhen traversingIPv4 NAT) >=20 >=20 > > > =3D> Well, DSMIP is not limited to be used when NATs are =20 > > > available. It can be used in public IPv4 networks where=20 > no > > NATs exist, or where no NAT exist between the MN and=20 > an HA in > > the same domain. So, what this buys is the same=20 > security as > > MIPv6 when no NATs exist.=20 > > > > > > > No, it doesn't, since there is no way to figure out=20 > whether > there were NATs + an attacker or just NATs or no NATs.=20 > > Please see my response to Ryuji where I explained this=20 > with > an illustration.=20 >=20 > =3D> Yes I read all emails about the draft. The point is, we're=20 > making the v6 packet as secure as MIPv6.=20 In fact, no. In MIP6, it is truly secure, because when the Alt-CoA option is present, that is always used as the CoA by the HA. In this case, the HA has no choice but to use the outer IP address as the CoA - if it is different from the inner CoA, it thinks there is a NAT; if it is not different, it doesn't make a difference. But, the HA can never be able to tell exactly what the case was. So, it is the outer IP address the HA uses, period.=20 So, protection of the inner IP address buys nothing, as far as I can see.=20 > Now, the receiver=20 > (HA/MAP) can use the fact that the v6 packet is secure for=20 > their advantage. For instance, if the receiver *knows* that=20 > no NATs exist, then it can trust the v6 information.=20 What do you mean that the receiver *knows* that no NATs exist? You mean, administratively (via configuration or what not) knows that? If so, first, I'd ask how practical is that? Second, the HA behavior would then be different based on whether or not the HA knows this via configuration?=20 > If it=20 > doesn't then it won't be able to do that. > So I see no harm in keeping the v6 packet secure, it can only=20 > be a benefit/requirement. Why should we not secure the v6 packet? >=20 Let's answer the above questions and then talk about this. I want to understand what scenario you have in mind first.=20 Vidya > Hesham >=20 > > > > Vidya > > > > > > > Hesham > > > > > > > > > > > Vidya > > > > > > > > > > > > > > > > > > B. Integrity of the IPv4 header.=20 > > > > > > > > > > Option 2) below is intended for A) above and option=20 > 3) > > was > > discussed to address B. I hope it's clear=20 > that the > > options > > you list below are not=20 > alternatives as they > > address different > > problems. > > > > > > > > > > Hesham > > > > > > > > > > > > > > > > I'm with you on that.=20 > > > > > > > > > > > > The options we have are so far: > > > > > > > > > > > > 1) do nothing. If the MN roams in IPv4, the=20 > source is > > not > > protected. > > > > > > There is a potential of an attack, but that is a=20 > > > difficult > > one, in an > IPv4 world where so many=20 > other > > attacks are > > possible anyway. > > > > > > > > > > > > 2) provide the source IPv4 address one way or another.=20 > > > > > This approach > includes Hesham's checksum. This=20 > seems > > to > > provide an IPv6 equivalent > security in=20 > the > absence of NAT.=20 > > > > > I'd argue that it does not really, > because it is=20 > > > still the > > IPv4 world, and with IPv4 it much >=20 > easier to > > fool > a > > visiting MN into using, as CoA,=20 > an address > > that belongs to > > > an attacked > server.=20 > > > > > > > > > > > > 3) propose an optional RR test. The test=20 > verifies > > that the > > MN is > reachable at the CoA, so=20 > it protects > > even against > > NAT and > rogue router >=20 > in the > visited network.=20 > > > > > > > > > > > > I think we have to consider the whole picture,=20 > thus I > > > > favor > 3. I could > do with 1, and then=20 > we'd propose > > the > > optional RR test as a separate >=20 > draft, which would > > be valid > > for all declinations of=20 > MIP6, > should the WG > > > decide that > > the RR test is=20 > not specific to this draft. > > > > > > > > > > > > I have trouble with 2. People who do not really =20 > > > understand > > > what it does > might get a false=20 > sense of > > security, which > > can be even more > dangerous. > > > > > > Once this option is in, it will be hard to take=20 > it > > out, > > even > when the RR > test is available=20 > and > > actually > > provides a better security. > > > > > > > > > > > > Pascal > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From:=20 > Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > > >=20 > >Sent: Friday, November 03, 2006 5:00 PM > >To: RYUJI > > =20 > > > WAKIKAWA > >Cc: Vijay Devarapalli; mip6@ietf.org; > >=20 > Pascal > > Thubert (pthubert); > Soliman, Hesham > > >=20 > >Subject: RE: What > > are we protecting over IPv4 in DS-MIP6?=20 > > > > > > (RE: [Mip6] > > > > > > concensus: issue 76: Alt CoA > > > > >=20 > >should not be usedwhen traversingIPv4 NAT) > > > > > >Hi =20 > > > Ryuji, > >I think this is missing the threat model.=20 > > > Let's > > look at two possible > >scenarios. > > > > > > > > > > > > > >1. MN --- (Attacker) --- HA > > > > > > > >=20 > > > > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA=20 > > > > > > > > >( ) indicates that an attacker may be present. > > > > > > > > > > > > > >If the HA received a BU with the inner and=20 > outer > > > > addresses > the same, it > >has no way of=20 > telling it was > > > > due to case 1 with no attacker > or=20 > case 2 > >with > > Attacker > > 2 who changed a NAT'ed=20 > outer address back to > > equal the > > > >inner address. > > > > > > > > > > > > > >So, there is no use in saying that the check is=20 > done > > when > > the HA > detects > >a NAT. > > > > > > > > > > > > > >But, we can document this issue and say that we=20 > > > don't > > > protect against > >on-path attackers in=20 > IPv4, > > because it is > > complicated and > not worth it. > > > > > > I > > > > > > >guess that's what Vijay and Hesham are saying -=20 > I > > could > > be > convinced of > >that, although, I=20 > don't see > > why we > > can't make the RR > optional and=20 > leave > >it at that. > > > > > > > > > > > > > >Vidya > > > > > > > > > > > > > > > > > > > > >> -----Original Message----- > > > > > >>=20 > From: RYUJI WAKIKAWA > > [mailto:ryuji.wakikawa@gmail.com] =20 > > > > >> Sent: Thursday, > > November 02, 2006 6:07 AM > >> To:=20 > > > > > Narayanan, Vidya > >> Cc: Vijay Devarapalli; > >=20 > mip6@ietf.org; > > Pascal Thubert > >> (pthubert); Soliman,=20 > > > Hesham > >> > > Subject: Re: What are we protecting=20 > over > > IPv4 in DS-MIP6? > > > > > > >> (RE: [Mip6] concensus: issue 76: Alt CoA=20 > should > > not be > > > >> usedwhen traversingIPv4 NAT) >=20 > >> > >> Hi > > Vidya > >> > > > >> RR check can be one=20 > solution, but as > > other people > > pointed > >> out,=20 > this causes additional > > round trip. > > > > > > >> In addition, if there is no NAT, we can=20 > simply > > protect > > CoA by > >> ACoA option. > > > > > > >> If HA detects that the CoA is different=20 > between > > IPv4 > > header > >> and ACoA, it can operate=20 > your RR check. > > > > > > >> Otherwise, it should be skipped. > > > > > > >> A new message BA-ack may be sufficient. i.e.=20 > An > > > >> > > acknowledgment of BA sent back from MN. > > > > > > >> > > > > > > >> ryuji > > > > > > >> > > > > > > >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > > > > > >> > > > > > > >> > > > > > > > >> > All, > > > > > > >> > This is something I should've raised=20 > yesterday > > when I > > > read all the > >> > emails,=20 > but after > > sleeping over it > > and some other >=20 > discussions, I'm > > > >> > still confused - > > so,=20 > figured I should raise it now > > :) > >> > > >> > First,=20 > I > > don't believe that an AltCoA > > option (v4 or v6) >=20 > >> buys anything. > > > > > > >> > Let's look at this. > > > > > > >> > > > > > > > >> > In IPv4, the outer IP address is always up=20 > for > > > >> > > modifications and there > >> > is no way=20 > to > > distinguish an > > adversary modifying it from a NAT=20 > > >> > > > modifying it. And, > > if the outer IPv4 source=20 > address is > > > >> different from > > > >> > the inner IP=20 > address, there > > is no way for the HA to > > figure > >>=20 > out whether > >> > > > the modification is due to a > >=20 > NAT or an adversary. Such > > > is the truth > >> > with=20 > NATs > > and there is nothing > > that can be done about it. > > > > > > >> Even if the > > > > > > >> > outer and inner IP addresses are the same,=20 > there > > is > > no way > >> to figure > >> > out that=20 > they are the > > same > > because there is no NAT or > >>=20 > because a NAT-ed > > > >> > IP > > address in the outer=20 > header has been modified > > back > to > > equal the > >>=20 > > inner IP address by an > > adversary. This is > > quite=20 > feasible, > >> especially > > > >> > when the inner > >=20 > packet is not encrypted and totally > > > depends on the >=20 > >> > > > intention of the attacker. > > > > > > >> > > > > > > > >> > The presence of the Alt-CoA option buys=20 > nothing > > > > exactly for > >> the same > >> > reasons.=20 > The fact that > > the > > Alt-CoA option is integrity > >>=20 > protected means > > > >> > > > nothing, since the HA still=20 > must use the outer IP > > address > > > >> as the CoA - >=20 > >> > and there is no > > guarantee about that > > being intact. > > > > > > >> > > > > > > > >> > We cannot pick and choose what attacks we=20 > like > > and > > what > we don't. > > > > > > >> > Either > > > > > > >> > we protect against redirection attacks or we don't.=20 > > > > > At this > >> point, I'm > >> > saying that=20 > integrity > > > > protection of the actual CoA alone proves =20 > > >> > nothing. > > > > > > >> > Reachability checks have more value than >=20 > > integrity > > > protection of a > >> > field that is >=20 > > allowed to be modified.=20 > > > > > Reachability checks > >> too, in the > >> >=20 > absence of > > > > confidentiality on the inner packet,=20 > does > not > > guarantee > > > >> > that an attacker is=20 > not on the path - > > but, it at least > > > >> proves that=20 > the > >> > MN is > > reachable at that address. > > > > > > >> > > > > > > > >> > So, my vote would be to perform an optional=20 > > > > > > reachability check and > >> > document the=20 > vulnerability > > > > that may still exist. > > > > > > >> > > > > > > > >> > Vidya > > > > > > >> > > > > > > > >> > _______________________________________________ > > > > > > >> > Mip6 mailing list > > > > > > >> > Mip6@ietf.org > > > > > > >> > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 17:27:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCwa-00023j-1e; Mon, 06 Nov 2006 17:27:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCwY-00020z-DU; Mon, 06 Nov 2006 17:27:50 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCwW-000698-PL; Mon, 06 Nov 2006 17:27:50 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8B00EGVY97BC@usaga01-in.huawei.com>; Mon, 06 Nov 2006 14:24:43 -0800 (PST) Received: from N737011 (dhcp70-96.ietf67.org [130.129.70.96]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8B00AHPY929V@usaga01-in.huawei.com>; Mon, 06 Nov 2006 14:24:43 -0800 (PST) Date: Mon, 06 Nov 2006 14:27:43 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 In-reply-to: To: 'Gerardo Giaretta' Message-id: <002e01c701f2$c6dceff0$60468182@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccBzisFShQSWSVATZ28r33lstjelwAJBHNA X-Spam-Score: 0.0 (/) X-Scan-Signature: e06437eb72f6703f11713d345be8298a Cc: mip6@ietf.org, dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Monday, November 06, 2006 10:01 AM To: Madjid Nakhjiri Cc: dime@ietf.org; mip6@ietf.org; Julien Bournelle Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 Hi Madjid, On 11/4/06, Madjid Nakhjiri wrote: > The doc calls itself AAA-HA goals, so We need to see what we need to > accomplish by the document > > 1) define AAA function requirements on HA and on HA-AAA server protocol? > > > 2) what is vendor required to put inside MIP6 HA to support AAA interaction. > > If the goal is 1) and you are not careful, you can unintentionally rule out > RADIUS. Plus some of the requirements are beyond the scope of those for AAA > client (HA) and AAA protocols. I am just pointing out that unless trying to > set up a set of goals for the Dime drafts, we need to be careful about the > side-effect of ruling out use of RADIUS for MIP6. > > Let me go through the goal > > > G1.1 The AAAH server and the HA MUST be able to authenticate each > > other (mutual authentication) in order to prevent the installation > > of unauthorized state on the HA. In some deployment scenarios, it > > may not be feasible for HA and AAAH to mutually authenticate each > > other. For example, let us consider the case where MSP is not the > > MSA. In such a case, several AAA intermediate proxies could > > forward MIP6 bootstrapping information back and forth between HA > > and AAA. Thus, to prevent the installation of unauthorized state > > on the HA, the path between HA and AAAH should be trustworthy>/ > > > > Madjid>>I am going to assume HA is AAA client, not sure, if authentication > between a AAA client and a AAA is an explicit requirement in any of the AAA > protocols. First it means a direct SA between the HA and AAAH. If there are > proxies on the AAA path, RADIUS for one does not support the end to end SA > directly, let alone the act of end to end authentication. > I understand that sending keys from AAAH to HA requires tight security, but > this is not a "AAA requirement", since it may not be covered by some AAA > protocols, it is part of security provisioning for the entire HA design. You > may want to bring this up in "security consideration section". > > You already seem to have this part of security consideration, so not sure > why it is also mentioned as AAA-HA goal, unless the goal of the doc is the > (2) mentioned above. > ok, now I get your point. However in the goal text we have already added this sentence: In some deployment scenarios, it may not be feasible for HA and AAAH to mutually authenticate each other. For example, let us consider the case where MSP is not the MSA. In such a case, several AAA intermediate proxies could forward MIP6 bootstrapping information back and forth between HA and AAA. Thus, to prevent the installation of unauthorized state on the HA, the path between HA and AAAH should be trustworthy. This was added exactly for RADIUS. Doesn't this text solve your issue? Madjid>>Yes, hence my comments, you are raising a well-known issue for RADIUS in a "AAA requirement section". Everybody knows RADIUS has this issue, so are trying to say RADIUS cannot/should not be used. If this is not your intentention (I don't think it is), you should simply remove the entire comment into the security section. It does not belong as a "AAA requirement". Madjid --Gerardo > I hope I have been helpful. > > R, > > Madjid > > > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Friday, November 03, 2006 6:30 AM > To: Madjid Nakhjiri > Cc: dime@ietf.org; mip6@ietf.org; Julien Bournelle > Subject: Re: [Dime] Fwd: [Mip6] WG LC for I-d: > draft-ietf-mip6-aaa-ha-goals-03 > > Hi Madjid, > > thanks for the review. Most comments are editorial and I'll fix them > in next version. Just one more detailed question below. > > > > > > 5.1. General goals > > > > G1.1 The AAAH server and the HA MUST be able to authenticate each > > other (mutual authentication) in order to prevent the installation > > of unauthorized state on the HA. In some deployment scenarios, it > > may not be feasible for HA and AAAH to mutually authenticate each > > other. For example, let us consider the case where MSP is not the > > MSA. In such a case, several AAA intermediate proxies could > > forward MIP6 bootstrapping information back and forth between HA > > and AAA. Thus, to prevent the installation of unauthorized state > > on the HA, the path between HA and AAAH should be trustworthy>/ > > > > > > Madjid>>again MSP versus MSA terminology issue. Plus the text is venturing > > into something that is more of a > > > > AAA infrastructure issue than an HA-AAAH issue. Also the text is mixing > end > > point authentication and AAA > > > > signaling security all in one requirement. Mutual authentication of HA and > > home AAA is one thing, protecting > > > > bootstrapping info over AAA messaging is another. This should be broken > into > > two requirements. I believe you > > > > have text on confidentiality in G1.4. The AAA signaling security issue is > > that of a AAA client in visited > > > > AAA domain dealing with a home AAA domain are well known. for instance if > > you don't like the transitive > > > > trust provided by the hop by hop security in RADIUS, so you need external > > ways to cure the transitive trust > > > > problem. On the other hand providing a mutual authentication procedure > > between HA and home AAA server > > > > without intervention of AAA intermediaries in a whole different problem. > So > > we need to be careful, otherwise > > > > we may end up ruling RADIUS out of here. Is that the intention? > > > > I would simply state the well known issues in the security consideration > > section. > > > > sorry but I cannot get your point clearly. > > which is your suggestion? Removing the requirement? Rephrasing it? Can > you please provide some text? > > Thanks, > --Gerardo > > > > > Giaretta, et al. Expires March 16, 2007 [Page 6] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > G1.2 The AAA-HA interface MUST provide integrity protection in order > > to prevent any alteration of exchanged data (e.g., Mobile IPv6 > > configuration parameters). > > > > G1.3 The AAA-HA interface MUST provide replay protection. > > > > G1.4 The AAA-HA interface SHOULD provide confidentiality since it > > may be used to transfer keying material (e.g., shared key > > generated during EAP method authentication). > > > > Madjid>>same comment as that on security in G1.1. > > > > G1.5 The AAA-HA interface SHOULD support inactive peer detection. > > This functionality can be used by the AAAH server to maintain a > > list of active HAs. > > > > > > 5.2. Service Authorization > > > > Madjid>>Typically authorization follows a successful authentication. It > > seems that the burden of the making > > > > sure the MN is authenticated falls into the lap of the HA, should we not > > have a requirement on this? > > > > G2.1 The AAA-HA interface SHOULD allow the use of Network Access > > Identifier (NAI) to identify the user. > > > > Madjid>>I believe for the split scenario. We were saying that the > > Diameter_EAP and Diameter-MIP need to use > > > > the same ID. does this cover that? Is NAI always the ID used for EAP? > > > > G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile > > IPv6 service authorization for the mobile node. > > > > G2.3 The AAAH server MAY assign explicit operational limitations and > > authorization restrictions on the HA (e.g., packet filters, QoS > > parameters). > > > > G2.4 The AAAH server MUST be able to send an authorization lifetime > > to the HA to limit Mobile IPv6 session duration for the MN. > > > > G2.5 The HA MUST be able to request to the AAAH server an extension > > of the authorization lifetime granted to the MN. > > > > G2.6 The AAAH server MUST be able to force the HA to terminate an > > active Mobile IPv6 session for authorization policy reasons (e.g., > > credit exhaustion). > > > > > > 5.3. Accounting > > > > G3.1 The AAA-HA interface MUST support the transfer of accounting > > records needed for service control and charging. These include > > (but may not be limited to): time of binding cache entry creation > > and deletion, octets sent and received by the mobile node in bi- > > directional tunneling, etc. > > > > > > > > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 7] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > 5.4. Mobile Node Authentication > > > > G4.1 The AAA-HA interface MUST support pass-through EAP > > authentication with the HA working as EAP authenticator operating > > in pass-through mode and the AAAH server working as back-end > > authentication server. > > > > Madjid>>Does this really have to be a MUST? > > > > 5.5. Provisioning of Configuration Parameters > > > > G5.1 The HA SHOULD be able to communicate to the AAAH server the > > Home Address allocated to the MN (e.g., for allowing the AAAH > > server to perform a DNS update on behalf of the MN). > > > > G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is > > authorized to autoconfigure its Home Address. > > > > > > > > 6. Goals for the Integrated Scenario > > > > In the integrated scenario, the AAA server provides the HA > > information to the NAS as part of the whole AAA operations for > > network access. Next goals are considered in addition to those > > described in section Section 5. > > > > G6.1 The AAAH server MUST be able to communicate the Home Agent > > Information (IP Address or FQDN) to the NAS. > > > > G6.2 The NAS SHOULD be able to notify that it supports the > > functionalities described in [4]. > > > > G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can > > allocate a Home Agent to the MN. > > > > G6.4 The AAA server of the MSA MUST be able to indicate to the NAS > > whether the MN is authorized to use a local Home Agent (i.e. a > > Home Agent in the ASP/MSP) > > > > > > > > Giaretta, et al. Expires March 16, 2007 [Page 8] > > > > > > Internet-Draft AAA Goals for Mobile IPv6 September 2006 > > > > > > 8. Security Considerations > > > > As stated in Section 5.1 the AAA-HA interface must provide mutual > > authentication, integrity and replay protection. Furthermore, if > > security parameters (e.g., IKE pre-shared key) are transferred > > through this interface, confidentiality is strongly recommended to be > > supported. However note that AAA protocols does not support this > > unless it exists a direct connection between corresponding entities. > > > > Madjid>> Diameter supports this. should say "some AAA protocols". > > > > > > > > -----Original Message----- > > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > > Sent: Tuesday, October 03, 2006 8:13 AM > > To: dime@ietf.org > > Subject: [Dime] Fwd: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > > > FYI, please review the document. > > > > --Gerardo > > > > ---------- Forwarded message ---------- > > From: Basavaraj Patil > > Date: Oct 3, 2006 4:49 PM > > Subject: [Mip6] WG LC for I-d: draft-ietf-mip6-aaa-ha-goals-03 > > To: mip6@ietf.org > > > > > > > > Hello, > > > > This is a Working group last call for the WG I-D: AAA Goals for Mobile > > IPv6 (draft-ietf-mip6-aaa-ha-goals-03). The draft is intended to serve > > as the AAA requirements for Mobile IPv6. > > > > Please review the I-D and submit your comments to the authors or to > > the list directly. > > > > The WGLC expires on Oct 18th, 06. > > > > The I-D is intended to be published as an Informational RFC. > > > > -Raj > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > DiME mailing list > > DiME@ietf.org > > https://www1.ietf.org/mailman/listinfo/dime > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 17:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD1q-00052o-NV; Mon, 06 Nov 2006 17:33:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhD1o-00052D-WE; Mon, 06 Nov 2006 17:33:17 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhD1l-0006rL-IW; Mon, 06 Nov 2006 17:33:16 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/SMTPOUT) with ESMTP id kA6MXBV5001975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 6 Nov 2006 14:33:11 -0800 (PST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id kA6MXBRw013657; Mon, 6 Nov 2006 14:33:11 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id kA6MX9Nc013622; Mon, 6 Nov 2006 14:33:10 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 14:33:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Nov 2006 14:33:09 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774464@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? Thread-Index: AccAfH4TIFnCB3WWRBa7rdIYjwTipQBdlOEA From: "Templin, Fred L" To: "Sri Gundavelli" , "Julien Laganier" X-OriginalArrivalTime: 06 Nov 2006 22:33:10.0362 (UTC) FILETIME=[89C813A0:01C701F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: mip6@ietf.org, netlmm@ietf.org Subject: [Mip6] RE: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I'm coming into this late, but I'm not sure about having the MN re-DAD its link-locals every time its link flaps when the link flaps could be happening constantly (e.g., when a MN is on the cusp btw the coverage regions of multiple access points). Wouldn't that be a concern in terms of stability, e.g., if the MN is constantly marking its LL's as tentative and rerunning DAD? Fred fred.l.templin@boeing.com =20 -----Original Message----- From: Sri Gundavelli [mailto:sgundave@cisco.com]=20 Sent: Saturday, November 04, 2006 5:48 PM To: Julien Laganier Cc: netlmm@ietf.org; mip6@ietf.org; Templin, Fred L Subject: Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? Hi Julien, On Sat, 4 Nov 2006, Julien Laganier wrote: > Hi Sri, > > Please find my answer inlined below: > > > I was assuming that the host implements DNAv6. Under > that scenario, when the host get a Link_up indication, > it will sollicit a router by sending an RS, and > receive from the new router a RA with the same prefix, > thus making it believe that it did not change link (I > am intentionally omitting the subtleties of DNA link > change determination, e.g. the use of a landmark > prefix) > > The default behavior for a host would then to not redo > DAD, and hence not detect the collision. (The host > might however be forced to redo DAD even though DNA > determined that the link did not changed if > DNASameLinkDADFlag is set to True) > PMIP did not make any assumption with respect to the node's capability of DNAv6, DNAv6 is still a draft. A native IPv6 host will certainly do a DAD after detecting a link flap and there is no question of DAD not getting triggered there. Now, with the new DNAv6 draft(s), assuming they get standardised and get into the IPv6 host stack, its a config option as you have pointed out, that will force the host to do DAD after link flap and still detecting the same-link with out having a need for pre-establishing LLA uniqueness across the domain. Thanks for the discussion. Regards Sri >> The collision is >> very much on that link and will be detected right >> after the host H moves to that link and starts >> the address configuration. > > See above -- It won't be detected by a DNA node with > default configuration. > >> The collision is on the link, why do these messages >> need to go out of the link ? Why do we need Proxy >> or Relay DAD ? Why is this scenario any special ? > > This scenario is special because you are hiding the > change of network prefix from one AR to another, thus > hiding the link change to DNA, which in effect disable > DAD upon link change in the same domain. > >> This is a normal IPv6 DAD scenario and ND will very >> much take care of that. > > See above. > >> Again, this is not a split link, we are not bridging >> traffic between links in this case. > > Again, and just to be sure, I never talked about split > link or IP-layer bridging across different links. > Ok. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 17:42:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhDAe-00028r-DJ; Mon, 06 Nov 2006 17:42:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhCb8-0001nB-Ou for mip6@ietf.org; Mon, 06 Nov 2006 17:05:42 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhCb7-0002Lg-Ih for mip6@ietf.org; Mon, 06 Nov 2006 17:05:42 -0500 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id kA6M5XJd012654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 7 Nov 2006 00:05:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id kA6M5W0V018490; Tue, 7 Nov 2006 00:05:32 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17743.45484.327116.817303@fireball.kivinen.iki.fi> Date: Tue, 7 Nov 2006 00:05:32 +0200 From: Tero Kivinen To: mip6@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 3 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 X-Mailman-Approved-At: Mon, 06 Nov 2006 17:42:22 -0500 Cc: Francis.Dupont@point6.net, mip6-ads@tools.ietf.org, mip6-chairs@tools.ietf.org Subject: [Mip6] Review of the draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org > Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture > draft-ietf-mip6-ikev2-ipsec-07.txt ... > 1. Introduction > > RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used > with Mobile IPv6 [2] to protect the signaling messages. It also > illustrates examples of Security Policy Database and Security > Association Database entries that can be used to protect Mobile IPv6 > signaling messages. > > The IPsec architecture has been revised in RFC 4301 [5]. Among the > many changes, the list of selectors has been expanded to include the > Mobility Header message type. This has an impact on how security > policies and security associations are configured for protecting > mobility header messages. It becomes easier to differentiate between > the various Mobility Header messages based on the type value instead > of checking if a particular mobility header message is being sent on > a tunnel interface between the mobile node and the home agent, as it > was in RFC 3776. The revised IPsec architecture specification also > includes ICMP message type and code as selectors. This makes it > possible to protect Mobile Prefix Discovery messages without applying > the same security associations to all ICMPv6 messages. > > This document discusses new requirements for the home agent and the > mobile node to use the revised IPsec architecture and IKEv2. > Section 4 lists the requirements. Section 6 and Section 7 describe > the required Security Policy Database (SPD) and Security Association > Database (SAD) entries. > > The Internet Key Exchange (IKE) has also been substantially revised > and simplified [4]. Section 7.2 of this document describes how IKEv2 > can be used to setup security associations for Mobile IPv6. > > The use of EAP within IKEv2 is allowed to authenticate the mobile > node to the home agent. This is described in Section 8. A method > for dynamically configuring a home address from the home agent using > the Configuration Payload in IKEv2 is described in Section 9. This should probably also talk about MOBIKE, as MOBIKE can offer some more building blocks for the MIP6 which will make it easier to use IKEv2 when addresses changes. > 4. Requirements ... > 4.4. Dynamic Keying Requirements ... > o If the home agent has used IKEv2 to establish security > associations with the mobile node, it should follow the procedures > discussed in Section 10.3.1 and 10.3.2 of the base specification > [2] to determine whether the IKE endpoints can be moved or if the > IKE SA has to be re-established. I do not know exactly what the RFC3775 specifies how to detect whether the SA can be moved or not, but if MOBIKE was supported by both ends when the IKEv2 SA was created, then SAs can always be updated with MOBIKE ADDRESS_UPDATE notify. > 7.1. Security Policy Database Entries ... > In the examples shown below, the identity of the user of the mobile > node is assumed to be user_1, the home address of the mobile node is > assumed to be home_address_1, he primary care-of address of the ^^^ > mobile node is assumed to be care_of_address_1 and the IPv6 address > of the Home Agent is assumed to be home_agent_1. Typo. > 7.2. Security Association negotiation using IKEv2 ... > When the mobile node uses its home address in the IDi field, > implementations are required to match the source address in the > outermost IP header with the IP address in the IDi field [8]. This > verification step, however, should be configurable [8]. With Mobile > IPv6, this verification step will always fail because the source > address in the IP header is the care-of address and the IP address in > the IDi field is the home address. Therefore, this verification step > MUST be disabled. Actually RFC 4306 section 3.1 says: Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. I.e the outer IP addresses are not used to verify IDi/IDr fields. RFC4718 (IKEv2 Clarifications and Implementation Guidelines) says this explicitly in section 7.1: Furthermore, IKEv2 does not require that the addresses in ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the IKE packets. However, other specifications may place additional requirements regarding this. For example, [PKI4IPsec] requires that implementation must be capable of comparing the addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the IKE packets, and this comparison must be enabled by default. So it would be enough here to say that you follow IKEv2 way of not matching the outer IP addresses with the ID payloads, and not follow the pki4ipsec profile about the IKEv1 (pki4ipsec is mostly for IKEv1 in any case). Also PKI4IPsec WG is now thinking whether they should say that section 3 of the draft-ietf-pki4ipsec-ikecert-profile-11.txt is only used for IKEv1 or for both IKEv1 and IKEv2. It would be better not to refer the pki4ipsec draft at all in this point, as it just adds confusion. > > 7.3. Movements and Dynamic Keying > > If the mobile node moves and its care-of address changes, the IKEv2 > SA might not be valid. RFC 3775 defines a mechanism based on the > successful exchange of Binding Update and Binding Acknowledgement > messages. The mobile node establishes the IKE SA with the home agent > using its primary care-of address. The IKE SA endpoints are updated > on the home agent when it receives the Binding Update from the mobile > node's new care-of address and on the mobile node when it sends the > Binding Update to the home agent or when it receives the Binding > acknowledgement sent by the home agent. This capability to change > IKE endpoints is indicated through setting the Key Management > Capability (K) flag [2] in the Binding Update and Binding > Acknowledgement messages. If the mobile node or the home agent does > not support this capability, and has no other means to update the > addresses, then an IKEv2 exchange MUST be initiated to re-establish a > new IKE SA. Again MOBIKE should probably be mentioned here. > 8. The use of EAP authentication ... > When EAP is used, the identity presented by the mobile node in the > IDi field may not be the actual identity of the mobile node. It > could be set to an identity that is used only for AAA routing > purposes and selecting the right EAP method. The actual identity is > carried inside EAP payloads that is not visible to the home agent. > The home agent MUST acquire the mobile node's identity from the > corresponding AAA server. More details can be found in [13]. Actually the rfc4718 does not mention anything about this. The RFC4306 says that the EAP Identity requests SHOULD NOT be sent (section 3.16): Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them. I.e the EAP exchange does not include EAP Identity request and reply, as that information has already been passed inside the ID payloads of the IKE exchange, and those same IDs are used as EAP identities when talking to the AAA server. So the actual identity is visible to the home agent as it is sent inside the ID payload. > 9. Dynamic Home Address Configuration ... > When the home agent receives a configuration payload with a > CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home > address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in > the CFG_REPLY contains the prefix length of the home prefix in > addition to a 128 bit home address. The home agent could use a local > database or contact a DHCPv6 server on the home link to allocate a > home address. The Home Agent should also include an > INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the > duration for which the dynamically allocated home address is valid. RFC4718 says: ---------------------------------------------------------------------- 6.7. INTERNAL_ADDRESS_EXPIRY Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as "Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one of these attributes MAY be present in the reply." Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when the client has gone away. However, in IKEv2 this is known, and the gateway can simply free the address when the IKE_SA is deleted. Also, Section 4 says that supporting renewals is not mandatory. Given that this functionality is usually not needed, we recommend that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. (And since this attribute does not seem to make much sense for CFG_REQUESTs, clients should not send it either.) Note that according to Section 4, clients are required to understand INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation would use the value to limit the lifetime of the IKE_SA. ---------------------------------------------------------------------- So, I would suggest you do recommend NOT to use INTERNAL_ADDRESS_EXPIRY at all, and simply get the address lifetime from the lifetime of the IKEv2 SA, i.e. the server will keep on renewing (if needed, in most cases the IP addresses are allocated from the local pool, so there is no needs to do renewals) the IP address as long as client keeps the IKEv2 SA up, and in case the address for some reason cannot be renewed, or is changed, deletes the IKEv2 SA forcing the client to get new IP address. As we are talking about home address here, there should not really be any problems with the address changing or not being able to renew it. -- kivinen@safenet-inc.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 19:25:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhElr-0003nl-Qf; Mon, 06 Nov 2006 19:24:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhElq-0003nE-B0 for mip6@ietf.org; Mon, 06 Nov 2006 19:24:54 -0500 Received: from nz-out-0102.google.com ([64.233.162.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhElo-0001CK-3o for mip6@ietf.org; Mon, 06 Nov 2006 19:24:54 -0500 Received: by nz-out-0102.google.com with SMTP id 13so1066770nzn for ; Mon, 06 Nov 2006 16:24:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=OTKqdr/HRGMZAmdsBYCumD7xYBDYGiukKauQy8vxyGE7YBEwyp1NSre5HGRgignOAQKsM4iB9IW8G196OpbOD3o0rUsfsDzfTdENBleSDf2V5qQH2MWz9YHPuYKSaKssXCnY/aZiFn91UHfJj2IdoPz2HqzjLx1gQu0cuEHy7BU= Received: by 10.65.239.13 with SMTP id q13mr6690056qbr.1162859091525; Mon, 06 Nov 2006 16:24:51 -0800 (PST) Received: from dhcp71-133.ietf67.org ( [130.129.71.133]) by mx.google.com with ESMTP id e11sm7718793qbc.2006.11.06.16.24.50; Mon, 06 Nov 2006 16:24:51 -0800 (PST) From: Julien Laganier To: Sri Gundavelli Date: Mon, 6 Nov 2006 16:24:28 -0800 User-Agent: KMail/1.8.2 References: <39C363776A4E8C4A94691D2BD9D1C9A101774464@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200611061624.28853.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, On Monday 06 November 2006 14:59, Sri Gundavelli wrote: > Hi Fred, > > The point is the default IPv6 host behaviour is > assumed for PMIP to work. With respect to the host > having the DNAv6 support, we need to see how that > impacts the DAD. Also, the point to note is the > current assumption of PMIP is a p2p MN-AR link and > the whole issue about LLA uniqueness on the access > link is when shared link is assumed. I don't thing the LLA uniqueness issue is limited to the shared link case. I think the concern apply even when links are point-to-point and the only neighbor to a MN is the provider's router. If a MN happens to move to a link where the router has a colliding link-local address, and the MN doesn't re-run DAD (as per default DNA behavior) then a collision will occur and won't be detected. That's orthogonal to the link type, be it point-to-point or shared, I think. Best, --julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 19:37:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhExL-0008JH-Sx; Mon, 06 Nov 2006 19:36:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEh0-0002OO-2E; Mon, 06 Nov 2006 19:19:54 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEav-0005ry-5b; Mon, 06 Nov 2006 19:13:49 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 06 Nov 2006 14:59:40 -0800 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAFteT0WrRApY/2dsb2JhbAA X-IronPort-AV: i="4.09,392,1157353200"; d="scan'208"; a="1862399537:sNHT408080352" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA6MxewS019928; Mon, 6 Nov 2006 14:59:40 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kA6MxdbG026512; Mon, 6 Nov 2006 14:59:39 -0800 (PST) Date: Mon, 6 Nov 2006 14:59:39 -0800 (PST) From: Sri Gundavelli To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774464@XCH-NW-7V2.nw.nos.boeing.com> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A101774464@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=3701; t=1162853980; x=1163717980; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:Sri=20Gundavelli=20 |Subject:RE=3A=20[netlmm]=20Re=3A=20Why=20is=20PMIP=20a=20superior=20solution=20f or=20NETLMMrequireiments?; X=v=3Dcisco.com=3B=20h=3Djb+yC8ZgPWktujsSMgBT7SpQW8s=3D; b=lMPoG2Otm7YjMMHuo/AoOpg3ppwdbPFOYSMtIAqY9bm4xOTFsA+a8W7i4BruZCtX06Hwlhux eKc1NNq0NSDplyCZhRGErAHw/D7MEkYnNqGAL+LYEtLBbh2L0kL8cYEH; Authentication-Results: sj-dkim-7.cisco.com; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: mip6@ietf.org, netlmm@ietf.org Subject: [Mip6] RE: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Fred, The point is the default IPv6 host behaviour is assumed for PMIP to work. With respect to the host having the DNAv6 support, we need to see how that impacts the DAD. Also, the point to note is the current assumption of PMIP is a p2p MN-AR link and the whole issue about LLA uniqueness on the access link is when shared link is assumed. In any case, ensuring domain-wide uniqueness for a LLA comes at it own cost and we want to avoid that. Sri On Mon, 6 Nov 2006, Templin, Fred L wrote: > I'm coming into this late, but I'm not sure about having the > MN re-DAD its link-locals every time its link flaps when the > link flaps could be happening constantly (e.g., when a MN is > on the cusp btw the coverage regions of multiple access > points). Wouldn't that be a concern in terms of stability, > e.g., if the MN is constantly marking its LL's as tentative > and rerunning DAD? > > Fred > fred.l.templin@boeing.com > > -----Original Message----- > From: Sri Gundavelli [mailto:sgundave@cisco.com] > Sent: Saturday, November 04, 2006 5:48 PM > To: Julien Laganier > Cc: netlmm@ietf.org; mip6@ietf.org; Templin, Fred L > Subject: Re: [netlmm] Re: Why is PMIP a superior solution for > NETLMMrequireiments? > > > Hi Julien, > > > On Sat, 4 Nov 2006, Julien Laganier wrote: > >> Hi Sri, >> >> Please find my answer inlined below: >> >> >> I was assuming that the host implements DNAv6. Under >> that scenario, when the host get a Link_up indication, >> it will sollicit a router by sending an RS, and >> receive from the new router a RA with the same prefix, >> thus making it believe that it did not change link (I >> am intentionally omitting the subtleties of DNA link >> change determination, e.g. the use of a landmark >> prefix) >> >> The default behavior for a host would then to not redo >> DAD, and hence not detect the collision. (The host >> might however be forced to redo DAD even though DNA >> determined that the link did not changed if >> DNASameLinkDADFlag is set to True) >> > > > PMIP did not make any assumption with respect to the > node's capability of DNAv6, DNAv6 is still a draft. > A native IPv6 host will certainly do a DAD after > detecting a link flap and there is no question of > DAD not getting triggered there. Now, with the new > DNAv6 draft(s), assuming they get standardised and > get into the IPv6 host stack, its a config option > as you have pointed out, that will force the host > to do DAD after link flap and still detecting the > same-link with out having a need for pre-establishing > LLA uniqueness across the domain. > > Thanks for the discussion. > > Regards > Sri > > > >>> The collision is >>> very much on that link and will be detected right >>> after the host H moves to that link and starts >>> the address configuration. >> >> See above -- It won't be detected by a DNA node with >> default configuration. >> >>> The collision is on the link, why do these messages >>> need to go out of the link ? Why do we need Proxy >>> or Relay DAD ? Why is this scenario any special ? >> >> This scenario is special because you are hiding the >> change of network prefix from one AR to another, thus >> hiding the link change to DNA, which in effect disable >> DAD upon link change in the same domain. >> >>> This is a normal IPv6 DAD scenario and ND will very >>> much take care of that. >> >> See above. >> >>> Again, this is not a split link, we are not bridging >>> traffic between links in this case. >> >> Again, and just to be sure, I never talked about split >> link or IP-layer bridging across different links. >> > > Ok. > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 20:04:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFNb-0002XT-B8; Mon, 06 Nov 2006 20:03:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFFE-0003Y7-AJ; Mon, 06 Nov 2006 19:55:16 -0500 Received: from dhcp68-116.ietf67.org ([130.129.68.116] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFFD-0005iu-1v; Mon, 06 Nov 2006 19:55:16 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EE0CFE0035; Mon, 6 Nov 2006 19:55:01 -0500 (EST) From: Sam Hartman To: , Francis.Dupont@point6.net, mip6@ietf.org, vijay.devarapalli@azairenet.com References: Date: Mon, 06 Nov 2006 19:55:01 -0500 In-Reply-To: (Pasi Eronen's message of "Tue, 7 Nov 2006 02:09:53 +0200") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Mon, 06 Nov 2006 20:03:53 -0500 Cc: Subject: [Mip6] Re: Last call comments for draft-ietf-mip6-ikev2-ipsec-07 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >>>>> "p" == writes: p> 6) Section 7.1: These SPD entries do not follow anything in p> RFC4301; instead, they mix information that would be present in p> PAD as well. This section should also definitely consider PAD, p> as it is the part of RFC4301 that prevents one MN for creating p> SAs for another MN's home address. Make absolutely sure that your document gets SPD and PAD entries right in a manner consistent with RFC 4301 or one of the security ADs will hold a discuss. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 20:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFNs-0002wZ-8N; Mon, 06 Nov 2006 20:04:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFNq-0002tu-0p; Mon, 06 Nov 2006 20:04:10 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhFNo-0006u4-O9; Mon, 06 Nov 2006 20:04:09 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 17:04:08 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86417669:sNHT45467388" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7148jv005422; Mon, 6 Nov 2006 17:04:08 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA7147Ap004533; Mon, 6 Nov 2006 17:04:07 -0800 (PST) Date: Mon, 6 Nov 2006 17:04:07 -0800 (PST) From: Sri Gundavelli To: Julien Laganier In-Reply-To: <200611061624.28853.julien.IETF@laposte.net> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A101774464@XCH-NW-7V2.nw.nos.boeing.com> <200611061624.28853.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=755; t=1162861448; x=1163725448; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:Sri=20Gundavelli=20 |Subject:Re=3A=20[netlmm]=20Re=3A=20Why=20is=20PMIP=20a=20superior=20solution=20f or=20NETLMMrequireiments?; X=v=3Dcisco.com=3B=20h=3DOUhZa3bekLxEHDY5+wZoQxrMonc=3D; b=s91r/C438zYUib2BBxSNFXd47hroD5PN57ngeAmt+90OBVHviyRl5ZAQNhFOejNyJLj+uCSw O+zVIcfcApr6mB0He5TBu5Er892w4wTB/DIMfz5Rfvx3JtV0HMVxJr8U; Authentication-Results: sj-dkim-1.cisco.com; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Julien, On Mon, 6 Nov 2006, Julien Laganier wrote: > > I don't thing the LLA uniqueness issue is limited to > the shared link case. I think the concern apply even > when links are point-to-point and the only neighbor to > a MN is the provider's router. > > If a MN happens to move to a link where the router has > a colliding link-local address, and the MN doesn't > re-run DAD (as per default DNA behavior) then a > collision will occur and won't be detected. > When the mobile moves to a new link, the home detection logic happens after it reseives an RA from the access router. The RA will be sent using the LLA and if there is a collision, the mobile will detect it right there and triggers a DAD procedure. Regards Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 20:04:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhFNb-0002X7-24; Mon, 06 Nov 2006 20:03:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhEhE-0002Qs-NV; Mon, 06 Nov 2006 19:20:08 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhEXN-0004yZ-ON; Mon, 06 Nov 2006 19:10:25 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA709q3e025928; Tue, 7 Nov 2006 02:09:52 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 02:09:52 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 02:09:52 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Nov 2006 02:09:53 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-ietf-mip6-ikev2-ipsec-07 Thread-Index: AccCAQx19xpcVcxsRV6VJrYtk3BG5w== From: To: X-OriginalArrivalTime: 07 Nov 2006 00:09:52.0298 (UTC) FILETIME=[0C0140A0:01C70201] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061107020952-5FFFFBB0-03821334/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a X-Mailman-Approved-At: Mon, 06 Nov 2006 20:03:53 -0500 Cc: Francis.Dupont@point6.net, mip6@ietf.org Subject: [Mip6] Last call comments for draft-ietf-mip6-ikev2-ipsec-07 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Some comments about draft-ietf-mip6-ikev2-ipsec-07: 1) Section 4 says "The home agent MAY use the Peer Authorization Database (PAD) [5] to store per-mobile node state." In RFC4301 the PAD is not some optional component of IPsec that may or may not be used; it is always present and always used (although in some cases it might not contain per-MN state). 2) Section 3 says "In case the mobile node reverse tunnels all traffic including Mobile IPv6 signaling messages exchanged between the mobile node and the home agent, then the Home Address Option is not required to be present in the messages sent to the home agent." (and continues to give an example of Binding Update without Home Address Option), but Section 4.2 says "The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations". Is this a contradiction or just confusion? 3) Section 4.2 says "RFC 3776 required configuration of the security policies per interface in order to be able to differentiate between mobility header messages sent to the home agent and tunneled through the home agent to the correspondent node. Since the Mobility Header message type is a selector, it is now easy to differentiate between HoTi and HoT messages from other mobility header messages. Therefore per-interface configuration of security policies is not required." This is only partially true. RFC 3776 like virtual interfaces would probably still be required if link-layer addresses are used (e.g. for MLD or DHCPv6). If this is the case, it might be a good idea to explicitly mention that the mechanisms described in this document support payload data protection only for traffic originating/terminating at the home address. 4) Section 4.3, "The home agent and mobile node SHOULD support Mobility Header message type as an IPsec selector." and "The home agent and mobile node SHOULD support ICMPv6 message type as an IPsec selector." If an implementation doesn't support them, it's not RFC4301 compliant anyway. Similarly, Section 5 says "IPsec implementations are compatible with this document even if they do not support fine grain selectors such as the Mobility Header message type and ICMPv6 message type." However, such implementations are not compliant with RFC4301; this should be said explicitly. 5) Section 4.3, "Similarly, the home agent starts to expect the new source address in the tunnel packets received from the mobile node." An RFC4301 IPsec implementation does not use the outer source address in tunnel mode packets for anything, so it doesn't "expect" anything. Similarly, Section 5 says "Typical IPsec processing does not check the outer source address.". More correctly, this is not part of IPsec processing as described in RFC 4301. 6) Section 7.1: These SPD entries do not follow anything in RFC4301; instead, they mix information that would be present in PAD as well. This section should also definitely consider PAD, as it is the=20 part of RFC4301 that prevents one MN for creating SAs for another=20 MN's home address. 7) Section 9: "The Home Agent should also include an INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the duration for which the dynamically allocated home address is valid." In RFC 4718 (IKEv2 clarifications) we strongly recommend=20 against using the INTERNAL_ADDRESS_EXPIRY attribute. (Note: I'm not subscribed to the MIP6 list, so keep in in Cc line of any replies :-) Best regards, Pasi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 06 21:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGY6-0005XC-Md; Mon, 06 Nov 2006 21:18:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGY5-0005Sy-RI for mip6@ietf.org; Mon, 06 Nov 2006 21:18:49 -0500 Received: from nz-out-0102.google.com ([64.233.162.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGU3-0006jm-0d for mip6@ietf.org; Mon, 06 Nov 2006 21:14:44 -0500 Received: by nz-out-0102.google.com with SMTP id 13so1088944nzn for ; Mon, 06 Nov 2006 18:14:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-disposition:content-type:content-transfer-encoding:message-id:sender; b=UHZISbEZZ6AdpQRzvawqvWuYjYrM7EreJfgxpauRi/kp922lBdUJ94LHzftclNzMuR5BTaPV9GmvEQrwPk5UrNZ3Yu9XQDRSI5WmXyjZJ3HYPMHKJv1JD+DgQcp8p6O0sM45M3kdlmcyXCBfqCwZX8YYyEs62c5a6yggy+ipfAA= Received: by 10.35.112.3 with SMTP id p3mr11928597pym.1162865678337; Mon, 06 Nov 2006 18:14:38 -0800 (PST) Received: from dhcp67-14.ietf67.org ( [130.129.67.14]) by mx.google.com with ESMTP id 7sm21118504nzn.2006.11.06.18.14.37; Mon, 06 Nov 2006 18:14:38 -0800 (PST) From: Julien Laganier To: Sri Gundavelli Date: Mon, 6 Nov 2006 18:14:15 -0800 User-Agent: KMail/1.8.2 References: <39C363776A4E8C4A94691D2BD9D1C9A101774464@XCH-NW-7V2.nw.nos.boeing.com> <200611061624.28853.julien.IETF@laposte.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200611061814.15758.julien.IETF@laposte.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Sri, On Monday 06 November 2006 17:04, Sri Gundavelli wrote: > > On Mon, 6 Nov 2006, Julien Laganier wrote: > > I don't thing the LLA uniqueness issue is limited > > to the shared link case. I think the concern apply > > even when links are point-to-point and the only > > neighbor to a MN is the provider's router. > > > > If a MN happens to move to a link where the router > > has a colliding link-local address, and the MN > > doesn't re-run DAD (as per default DNA behavior) > > then a collision will occur and won't be detected. > > When the mobile moves to a new link, the home > detection logic happens after it reseives an RA from > the access router. The RA will be sent using the LLA > and if there is a collision, the mobile will detect > it right there and triggers a DAD procedure. I haven't seen this behavior (trigger DAD after observing a duplicate) specified in RFC 2461, 2462 or their revision (bis.) Best, --julien _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 07 11:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTY7-0006ci-2H; Tue, 07 Nov 2006 11:11:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGx4-0002FP-2y for mip6@ietf.org; Mon, 06 Nov 2006 21:44:38 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGx2-0003B6-P9 for mip6@ietf.org; Mon, 06 Nov 2006 21:44:38 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 18:44:36 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86440629:sNHT52489629" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72iafD009162; Mon, 6 Nov 2006 18:44:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA72iZin010767; Mon, 6 Nov 2006 18:44:35 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:44:35 -0800 Received: from [12.105.247.158] ([10.21.98.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:44:34 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57E61A6C-DFFC-4AC1-91A7-2D359162ABCF@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Mon, 6 Nov 2006 18:44:30 -0800 To: Basavaraj Patil , Gopal Dommety X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Nov 2006 02:44:35.0128 (UTC) FILETIME=[A900B380:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=526; t=1162867476; x=1163731476; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Review=20of=20draft-ietf-v6ops-802-16-deployment-scenarios; X=v=3Dcisco.com=3B=20h=3Dst+XSuTY1V8nEBgDWCZV5/7OOWk=3D; b=o8ZYuZ58Z1i3xmmApJChr8fnVaprJkm579SEuo3VBqH+Nu1hAR1tAAl5Vi5bfYoQ+6OQ6EWz vSIgSTLMrLyNna23ufgOVwTuoTeT47ohzfj9qPwsqeSgxcmxoAQxntzx; Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Tue, 07 Nov 2006 11:11:41 -0500 Cc: v6ops@ops.ietf.org, David Kessens , mip6@ietf.org Subject: [Mip6] Review of draft-ietf-v6ops-802-16-deployment-scenarios X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The v6ops working group is approaching a working group last call on draft-ietf-v6ops-802-16-deployment-scenarios within the coming few weeks. We would appreciate a review from your working group of this document before we do so. How that is done is up to you; you may designate one or more reviewers, or simply conduct the review on your mailing list, or whatever else suits you. But please respond to the authors copying v6ops within the coming four weeks if you would. Thank you for your help in this. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 07 11:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTFrom mip6-bounces@ietf.org Tue Nov 07 11:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTY7-0006ci-2H; Tue, 07 Nov 2006 11:11:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGx4-0002FP-2y for mip6@ietf.org; Mon, 06 Nov 2006 21:44:38 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGx2-0003B6-P9 for mip6@ietf.org; Mon, 06 Nov 2006 21:44:38 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2006 18:44:36 -0800 X-IronPort-AV: i="4.09,393,1157353200"; d="scan'208"; a="86440629:sNHT52489629" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA72iafD009162; Mon, 6 Nov 2006 18:44:36 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA72iZin010767; Mon, 6 Nov 2006 18:44:35 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:44:35 -0800 Received: from [12.105.247.158] ([10.21.98.107]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 18:44:34 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <57E61A6C-DFFC-4AC1-91A7-2D359162ABCF@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Date: Mon, 6 Nov 2006 18:44:30 -0800 To: Basavaraj Patil , Gopal Dommety X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 07 Nov 2006 02:44:35.0128 (UTC) FILETIME=[A900B380:01C70216] DKIM-Signature: a=rsa-sha1; q=dns; l=526; t=1162867476; x=1163731476; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fred@cisco.com; z=From:Fred=20Baker=20 |Subject:Review=20of=20draft-ietf-v6ops-802-16-deployment-scenarios; X=v=3Dcisco.com=3B=20h=3Dst+XSuTY1V8nEBgDWCZV5/7OOWk=3D; b=o8ZYuZ58Z1i3xmmApJChr8fnVaprJkm579SEuo3VBqH+Nu1hAR1tAAl5Vi5bfYoQ+6OQ6EWz vSIgSTLMrLyNna23ufgOVwTuoTeT47ohzfj9qPwsqeSgxcmxoAQxntzx; Authentication-Results: sj-dkim-3.cisco.com; header.From=fred@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Tue, 07 Nov 2006 11:11:41 -0500 Cc: v6ops@ops.ietf.org, David Kessens , mip6@ietf.org Subject: [Mip6] Review of draft-ietf-v6ops-802-16-deployment-scenarios X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The v6ops working group is approaching a working group last call on draft-ietf-v6ops-802-16-deployment-scenarios within the coming few weeks. We would appreciate a review from your working group of this document before we do so. How that is done is up to you; you may designate one or more reviewers, or simply conduct the review on your mailing list, or whatever else suits you. But please respond to the authors copying v6ops within the coming four weeks if you would. Thank you for your help in this. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 07 11:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhTY6-0006cA-Oe; Tue, 07 Nov 2006 11:11:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGD1-0000A7-QS for mip6@ietf.org; Mon, 06 Nov 2006 20:57:03 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGCx-0004dc-H3 for mip6@ietf.org; Mon, 06 Nov 2006 20:57:03 -0500 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id kA71urK8025500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Nov 2006 03:56:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id kA71ur5r016842; Tue, 7 Nov 2006 03:56:53 +0200 (EET) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <17743.59361.605502.492488@fireball.kivinen.iki.fi> Resent-Date: Tue, 7 Nov 2006 03:56:49 +0200 Resent-To: mip6@ietf.org Message-ID: <17743.45484.327116.817303@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Tero Kivinen To: mip6@ietf.org Date: Tue, 7 Nov 2006 00:05:32 +0200 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 X-Mailman-Approved-At: Tue, 07 Nov 2006 11:11:41 -0500 Cc: Francis.Dupont@point6.net, mip6-ads@tools.ietf.org, mip6-chairs@tools.ietf.org Subject: [Mip6] Review of the draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Resent-Date: Tue, 07 Nov 2006 11:11:42 -0500 > Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture > draft-ietf-mip6-ikev2-ipsec-07.txt ... > 1. Introduction > > RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used > with Mobile IPv6 [2] to protect the signaling messages. It also > illustrates examples of Security Policy Database and Security > Association Database entries that can be used to protect Mobile IPv6 > signaling messages. > > The IPsec architecture has been revised in RFC 4301 [5]. Among the > many changes, the list of selectors has been expanded to include the > Mobility Header message type. This has an impact on how security > policies and security associations are configured for protecting > mobility header messages. It becomes easier to differentiate between > the various Mobility Header messages based on the type value instead > of checking if a particular mobility header message is being sent on > a tunnel interface between the mobile node and the home agent, as it > was in RFC 3776. The revised IPsec architecture specification also > includes ICMP message type and code as selectors. This makes it > possible to protect Mobile Prefix Discovery messages without applying > the same security associations to all ICMPv6 messages. > > This document discusses new requirements for the home agent and the > mobile node to use the revised IPsec architecture and IKEv2. > Section 4 lists the requirements. Section 6 and Section 7 describe > the required Security Policy Database (SPD) and Security Association > Database (SAD) entries. > > The Internet Key Exchange (IKE) has also been substantially revised > and simplified [4]. Section 7.2 of this document describes how IKEv2 > can be used to setup security associations for Mobile IPv6. > > The use of EAP within IKEv2 is alloY6-0006cA-Oe; Tue, 07 Nov 2006 11:11:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhGD1-0000A7-QS for mip6@ietf.org; Mon, 06 Nov 2006 20:57:03 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhGCx-0004dc-H3 for mip6@ietf.org; Mon, 06 Nov 2006 20:57:03 -0500 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id kA71urK8025500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 7 Nov 2006 03:56:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id kA71ur5r016842; Tue, 7 Nov 2006 03:56:53 +0200 (EET) Resent-From: kivinen@iki.fi X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f Resent-Message-ID: <17743.59361.605502.492488@fireball.kivinen.iki.fi> Resent-Date: Tue, 7 Nov 2006 03:56:49 +0200 Resent-To: mip6@ietf.org Message-ID: <17743.45484.327116.817303@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 From: Tero Kivinen To: mip6@ietf.org Date: Tue, 7 Nov 2006 00:05:32 +0200 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Edit-Time: 0 min X-Total-Time: 0 min X-Spam-Score: 0.1 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 X-Mailman-Approved-At: Tue, 07 Nov 2006 11:11:41 -0500 Cc: Francis.Dupont@point6.net, mip6-ads@tools.ietf.org, mip6-chairs@tools.ietf.org Subject: [Mip6] Review of the draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org Resent-Date: Tue, 07 Nov 2006 11:11:42 -0500 > Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture > draft-ietf-mip6-ikev2-ipsec-07.txt ... > 1. Introduction > > RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used > with Mobile IPv6 [2] to protect the signaling messages. It also > illustrates examples of Security Policy Database and Security > Association Database entries that can be used to protect Mobile IPv6 > signaling messages. > > The IPsec architecture has been revised in RFC 4301 [5]. Among the > many changes, the list of selectors has been expanded to include the > Mobility Header message type. This has an impact on how security > policies and security associations are configured for protecting > mobility header messages. It becomes easier to differentiate between > the various Mobility Header messages based on the type value instead > of checking if a particular mobility header message is being sent on > a tunnel interface between the mobile node and the home agent, as it > was in RFC 3776. The revised IPsec architecture specification also > includes ICMP message type and code as selectors. This makes it > possible to protect Mobile Prefix Discovery messages without applying > the same security associations to all ICMPv6 messages. > > This document discusses new requirements for the home agent and the > mobile node to use the revised IPsec architecture and IKEv2. > Section 4 lists the requirements. Section 6 and Section 7 describe > the required Security Policy Database (SPD) and Security Association > Database (SAD) entries. > > The Internet Key Exchange (IKE) has also been substantially revised > and simplified [4]. Section 7.2 of this document describes how IKEv2 > can be used to setup security associations for Mobile IPv6. > > The use of EAP within IKEv2 is allowed to authenticate the mobile > node to the home agent. This is described in Section 8. A method > for dynamically configuring a home address from the home agent using > the Configuration Payload in IKEv2 is described in Section 9. This should probably also talk about MOBIKE, as MOBIKE can offer some more building blocks for the MIP6 which will make it easier to use IKEv2 when addresses changes. > 4. Requirements ... > 4.4. Dynamic Keying Requirements ... > o If the home agent has used IKEv2 to establish security > associations with the mobile node, it should follow the procedures > discussed in Section 10.3.1 and 10.3.2 of the base specification > [2] to determine whether the IKE endpoints can be moved or if the > IKE SA has to be re-established. I do not know exactly what the RFC3775 specifies how to detect whether the SA can be moved or not, but if MOBIKE was supported by both ends when the IKEv2 SA was created, then SAs can always be updated with MOBIKE ADDRESS_UPDATE notify. > 7.1. Security Policy Database Entries ... > In the examples shown below, the identity of the user of the mobile > node is assumed to be user_1, the home address of the mobile node is > assumed to be home_address_1, he primary care-of address of the ^^^ > mobile node is assumed to be care_of_address_1 and the IPv6 address > of the Home Agent is assumed to be home_agent_1. Typo. > 7.2. Security Association negotiation using IKEv2 ... > When the mobile node uses its home address in the IDi field, > implementations are required to match the source address in the > outermost IP header with the IP address in the IDi field [8]. This > verification step, however, should be configurable [8]. With Mobile > IPv6, this verification step will always fail because the source > address in the IP header is the care-of address and the IP address in > the IDi field is the home address. Therefore, this verification step > MUST be disabled. Actually RFC 4306 section 3.1 says: Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. I.e the outer IP addresses are not used to verify IDi/IDr fields. RFC4718 (IKEv2 Clarifications and Implementation Guidelines) says this explicitly in section 7.1: Furthermore, IKEv2 does not require that the addresses in ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the IKE packets. However, other specifications may place additional requirements regarding this. For example, [PKI4IPsec] requires that implementation must be capable of comparing the addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the IKE packets, and this comparison must be enabled by default. So it would be enough here to say that you follow IKEv2 way of not matching the outer IP addresses with the ID payloads, and not follow the pki4ipsec profile about the IKEv1 (pki4ipsec is mostly for IKEv1 in any case). Also PKI4IPsec WG is now thinking whether they should say that section 3 of the draft-ietf-pki4ipsec-ikecert-profile-11.txt is only used for IKEv1 or for both IKEv1 and IKEv2. It would be better not to refer the pki4ipsec draft at all in this point, as it just adds confusion. > > 7.3. Movements and Dynamic Keying > > If the mobile node moves and its care-of address changes, the IKEv2 > SA might not be valid. RFC 3775 defines a mechanism based on the > successful exchange of Binding Update and Binding Acknowledgement > messages. The mobile node establishes the IKE SA with the home agent > using its primary care-of address. The IKE SA endpoints are updated > on the home agent when it receives the Binding Update from the mobile > node's new care-of address and on the mobile node when it sends the > Binding Update to the home agent or when it receives the Binding > acknowledgement sent by the home agent. This capabilitwed to authenticate the mobile > node to the home agent. This is described in Section 8. A method > for dynamically configuring a home address from the home agent using > the Configuration Payload in IKEv2 is described in Section 9. This should probably also talk about MOBIKE, as MOBIKE can offer some more building blocks for the MIP6 which will make it easier to use IKEv2 when addresses changes. > 4. Requirements ... > 4.4. Dynamic Keying Requirements ... > o If the home agent has used IKEv2 to establish security > associations with the mobile node, it should follow the procedures > discussed in Section 10.3.1 and 10.3.2 of the base specification > [2] to determine whether the IKE endpoints can be moved or if the > IKE SA has to be re-established. I do not know exactly what the RFC3775 specifies how to detect whether the SA can be moved or not, but if MOBIKE was supported by both ends when the IKEv2 SA was created, then SAs can always be updated with MOBIKE ADDRESS_UPDATE notify. > 7.1. Security Policy Database Entries ... > In the examples shown below, the identity of the user of the mobile > node is assumed to be user_1, the home address of the mobile node is > assumed to be home_address_1, he primary care-of address of the ^^^ > mobile node is assumed to be care_of_address_1 and the IPv6 address > of the Home Agent is assumed to be home_agent_1. Typo. > 7.2. Security Association negotiation using IKEv2 ... > When the mobile node uses its home address in the IDi field, > implementations are required to match the source address in the > outermost IP header with the IP address in the IDi field [8]. This > verification step, however, should be configurable [8]. With Mobile > IPv6, this verification step will always fail because the source > address in the IP header is the care-of address and the IP address in > the IDi field is the home address. Therefore, this verification step > MUST be disabled. Actually RFC 4306 section 3.1 says: Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. I.e the outer IP addresses are not used to verify IDi/IDr fields. RFC4718 (IKEv2 Clarifications and Implementation Guidelines) says this explicitly in section 7.1: Furthermore, IKEv2 does not require that the addresses in ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the IKE packets. However, other specifications may place additional requirements regarding this. For example, [PKI4IPsec] requires that implementation must be capable of comparing the addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the IKE packets, and this comparison must be enabled by default. So it would be enough here to say that you follow IKEv2 way of not matching the outer IP addresses with the ID payloads, and not follow the pki4ipsec profile about the IKEv1 (pki4ipsec is mostly for IKEv1 in any case). Also PKI4IPsec WG is now thinking whether they should say that section 3 of the draft-ietf-pki4ipsec-ikecert-profile-11.txt is only used for IKEv1 or for both IKEv1 and IKEv2. It would be better not to refer the pki4ipsec draft at all in this point, as it just adds confusion. > > 7.3. Movements and Dynamic Keying > > If the mobile node moves and its care-of address changes, the IKEv2 > SA might not be valid. RFC 3775 defines a mechanism based on the > successful exchange of Binding Update and Binding Acknowledgement > messages. The mobile node establishes the IKE SA with the home agent > using its primary care-of address. The IKE SA endpoints are updated > on the home agent when it receives the Binding Update from the mobile > node's new care-of address and on the mobile node when it sends the > Binding Update to the home agent or when it receives the Binding > acknowledgement sent by the home agent. This capability to change > IKE endpoints is indicated through setting the Key Management > Capability (K) flag [2] in the Binding Update and Binding > Acknowledgement messages. If the mobile node or the home agent does > not support this capability, and has no other means to update the > addresses, then an IKEv2 exchange MUST be initiated to re-establish a > new IKE SA. Again MOBIKE should probably be mentioned here. > 8. The use of EAP authentication ... > When EAP is used, the identity presented by the mobile node in the > IDi field may not be the actual identity of the mobile node. It > could be set to an identity that is used only for AAA routing > purposes and selecting the right EAP method. The actual identity is > carried inside EAP payloads that is not visible to the home agent. > The home agent MUST acquire the mobile node's identity from the > corresponding AAA server. More details can be found in [13]. Actually the rfc4718 does not mention anything about this. The RFC4306 says that the EAP Identity requests SHOULD NOT be sent (section 3.16): Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them. I.e the EAP exchange does not include EAP Identity request and reply, as that information has already been passed inside the ID payloads of the IKE exchange, and those same IDs are used as EAP identities when talking to the AAA server. So the actual identity is visible to the home agent as it is sent inside the ID payload. > 9. Dynamic Home Address Configuration ... > When the home agent receives a configuration payload with a > CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home > address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in > the CFG_REPLY contains the prefix length of the home prefix in > addition to a 128 bit home address. The home agent could use a local > database or contact a DHCPv6 server on the home link to allocate a > home address. The Home Agent should also include an > INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the > duration for which the dynamically allocated home address is valid. RFC4718 says: ---------------------------------------------------------------------- 6.7. INTERNAL_ADDRESS_EXPIRY Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as "Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one of these attributes MAY be present in the reply." Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when the client has gone away. However, in IKEv2 this is known, and the gateway can simply free the address when the IKE_SA is deleted. Also, Section 4 says that supporting renewals is not mandatory. Given that this functionality is usually not needed, we recommend that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. (And since this attribute does not seem to make much sense for CFG_REQUESTs, clients should not send it either.) Note that according to Section 4, clients are required to understand INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation would use the value to limit the lifetime of the IKE_SA. ---------------------------------------------------------------------- So, I would suggest you do recommend NOT to use INTERNAL_ADDRESS_EXPIRY at all, and simply get the address lifetime from the lifetime of the IKEv2 SA, i.e. the server will keep on renewing (if needed, in most cases the IP addresses are allocated from the local pool, so there is no needs to do renewals) the IP address as long as client keeps the IKEv2 SA up, and in case the address for some reason cannot be renewed, or is changed, deletes the IKEv2 SA forcing the client to gey to change > IKE endpoints is indicated through setting the Key Management > Capability (K) flag [2] in the Binding Update and Binding > Acknowledgement messages. If the mobile node or the home agent does > not support this capability, and has no other means to update the > addresses, then an IKEv2 exchange MUST be initiated to re-establish a > new IKE SA. Again MOBIKE should probably be mentioned here. > 8. The use of EAP authentication ... > When EAP is used, the identity presented by the mobile node in the > IDi field may not be the actual identity of the mobile node. It > could be set to an identity that is used only for AAA routing > purposes and selecting the right EAP method. The actual identity is > carried inside EAP payloads that is not visible to the home agent. > The home agent MUST acquire the mobile node's identity from the > corresponding AAA server. More details can be found in [13]. Actually the rfc4718 does not mention anything about this. The RFC4306 says that the EAP Identity requests SHOULD NOT be sent (section 3.16): Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them. I.e the EAP exchange does not include EAP Identity request and reply, as that information has already been passed inside the ID payloads of the IKE exchange, and those same IDs are used as EAP identities when talking to the AAA server. So the actual identity is visible to the home agent as it is sent inside the ID payload. > 9. Dynamic Home Address Configuration ... > When the home agent receives a configuration payload with a > CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home > address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in > the CFG_REPLY contains the prefix length of the home prefix in > addition to a 128 bit home address. The home agent could use a local > database or contact a DHCPv6 server on the home link to allocate a > home address. The Home Agent should also include an > INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the > duration for which the dynamically allocated home address is valid. RFC4718 says: ---------------------------------------------------------------------- 6.7. INTERNAL_ADDRESS_EXPIRY Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as "Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one of these attributes MAY be present in the reply." Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when the client has gone away. However, in IKEv2 this is known, and the gateway can simply free the address when the IKE_SA is deleted. Also, Section 4 says that supporting renewals is not mandatory. Given that this functionality is usually not needed, we recommend that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. (And since this attribute does not seem to make much sense for CFG_REQUESTs, clients should not send it either.) Note that according to Section 4, clients are required to understand INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation would use the value to limit the lifetime of the IKE_SA. ---------------------------------------------------------------------- So, I would suggest you do recommend NOT to use INTERNAL_ADDRESS_EXPIRY at all, and simply get the address lifetime from the lifetime of the IKEv2 SA, i.e. the server will keep on renewing (if needed, in most cases the IP addresses are allocated from the local pool, so there is no needs to do renewals) the IP address as long as client keeps the IKEv2 SA up, and in case the address for some reason cannot be renewed, or is changed, deletes the IKEv2 SA forcing the client to get new IP address. As we are talking about home address here, there should not really be any problems with the address changing or not being able to renew it. -- kivinen@safenet-inc.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 t new IP address. As we are talking about home address here, there should not really be any problems with the address changing or not being able to renew it. -- kivinen@safenet-inc.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 07 14:57:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhX4K-0006By-IY; Tue, 07 Nov 2006 14:57:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhX4I-00069F-8G; Tue, 07 Nov 2006 14:57:10 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhX4G-0004wq-Vk; Tue, 07 Nov 2006 14:57:10 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2006 11:57:08 -0800 X-IronPort-AV: i="4.09,397,1157353200"; d="scan'208"; a="448751331:sNHT46850660" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA7Jv8LD018793; Tue, 7 Nov 2006 11:57:08 -0800 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kA7Jv7W5011025; Tue, 7 Nov 2006 11:57:08 -0800 (PST) Date: Tue, 7 Nov 2006 11:57:07 -0800 (PST) From: Sri Gundavelli To: Julien Laganier In-Reply-To: <200611061814.15758.julien.IETF@laposte.net> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A101774464@XCH-NW-7V2.nw.nos.boeing.com> <200611061624.28853.julien.IETF@laposte.net> <200611061814.15758.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=959; t=1162929428; x=1163793428; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sgundave@cisco.com; z=From:Sri=20Gundavelli=20 |Subject:Re=3A=20[netlmm]=20Re=3A=20Why=20is=20PMIP=20a=20superior=20solution=20f or=20NETLMMrequireiments?; X=v=3Dcisco.com=3B=20h=3DOUhZa3bekLxEHDY5+wZoQxrMonc=3D; b=L6+FBHpglRBG0XYLfvyIZA45Jef3yauZ30o/+jVCSMWpYHKtyx4UUs3SzDiYLxvXRly7Y9yR CADCsKW1ZyoM1b+DOyBal1KVYCa/Y4m4go7xXEJlI7Prx68ndMbQ/G3P; Authentication-Results: sj-dkim-3.cisco.com; header.From=sgundave@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: mip6@ietf.org, "Templin, Fred L" , netlmm@ietf.org Subject: [Mip6] Re: [netlmm] Re: Why is PMIP a superior solution for NETLMMrequireiments? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Julien, On Mon, 6 Nov 2006, Julien Laganier wrote: > Hi Sri, >> >> When the mobile moves to a new link, the home >> detection logic happens after it reseives an RA from >> the access router. The RA will be sent using the LLA >> and if there is a collision, the mobile will detect >> it right there and triggers a DAD procedure. > > I haven't seen this behavior (trigger DAD after > observing a duplicate) specified in RFC 2461, 2462 or > their revision (bis.) > If the node will not do the DAD after detecting a RA with its own LLA, you think it will create a new neighbor cache entry or the default-router entry with its own LLA ? The whole expensive DAD procedure is for detecting duplicate, I'd expect the IPv6 protocol host stack to check the address before it adds it to its data structures. I will check our implementation. To me, this appears to be too implicit to even be mentioned in 2461 or the bis. Regards Sri _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 07 19:01:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhasP-0004yT-At; Tue, 07 Nov 2006 19:01:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhasO-0004yH-5A for mip6@ietf.org; Tue, 07 Nov 2006 19:01:08 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghas6-0003FL-8E for mip6@ietf.org; Tue, 07 Nov 2006 19:01:08 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA800kBn018378 for ; Wed, 8 Nov 2006 02:00:49 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 02:00:46 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 18:00:45 -0600 Received: from 10.241.59.129 ([10.241.59.129]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 8 Nov 2006 00:00:45 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Tue, 07 Nov 2006 17:44:35 -0600 From: Basavaraj Patil To: Message-ID: Thread-Topic: WG meeting slides now available Thread-Index: AccCxq4J7J5B+G65EduDDAARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Nov 2006 00:00:45.0989 (UTC) FILETIME=[F0CADD50:01C702C8] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061108020049-3CB23BB0-51CF122A/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Mip6] WG meeting slides now available X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The slides that will be used for the MIP6 WG meeting today (Nov 7th) are now at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 07 21:54:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdVG-0001Mn-PH; Tue, 07 Nov 2006 21:49:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhdVE-00017W-Ng for mip6@ietf.org; Tue, 07 Nov 2006 21:49:24 -0500 Received: from dsl092-223-006.sfo1.dsl.speakeasy.net ([66.92.223.6] helo=mail2.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhdHY-0005SE-Ge for mip6@ietf.org; Tue, 07 Nov 2006 21:35:17 -0500 Received: from [10.1.210.13] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Nov 2006 18:35:15 -0800 Message-ID: <45514262.4070009@azairenet.com> Date: Tue, 07 Nov 2006 18:35:14 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2006 02:35:15.0296 (UTC) FILETIME=[85BADE00:01C702DE] X-Spam-Score: 0.1 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Mip6] [Fwd: Last call comments for draft-ietf-mip6-ikev2-ipsec-07] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org FYI -------- Original Message -------- Subject: Last call comments for draft-ietf-mip6-ikev2-ipsec-07 Date: Tue, 7 Nov 2006 02:09:53 +0200 From: To: CC: , , Some comments about draft-ietf-mip6-ikev2-ipsec-07: 1) Section 4 says "The home agent MAY use the Peer Authorization Database (PAD) [5] to store per-mobile node state." In RFC4301 the PAD is not some optional component of IPsec that may or may not be used; it is always present and always used (although in some cases it might not contain per-MN state). 2) Section 3 says "In case the mobile node reverse tunnels all traffic including Mobile IPv6 signaling messages exchanged between the mobile node and the home agent, then the Home Address Option is not required to be present in the messages sent to the home agent." (and continues to give an example of Binding Update without Home Address Option), but Section 4.2 says "The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations". Is this a contradiction or just confusion? 3) Section 4.2 says "RFC 3776 required configuration of the security policies per interface in order to be able to differentiate between mobility header messages sent to the home agent and tunneled through the home agent to the correspondent node. Since the Mobility Header message type is a selector, it is now easy to differentiate between HoTi and HoT messages from other mobility header messages. Therefore per-interface configuration of security policies is not required." This is only partially true. RFC 3776 like virtual interfaces would probably still be required if link-layer addresses are used (e.g. for MLD or DHCPv6). If this is the case, it might be a good idea to explicitly mention that the mechanisms described in this document support payload data protection only for traffic originating/terminating at the home address. 4) Section 4.3, "The home agent and mobile node SHOULD support Mobility Header message type as an IPsec selector." and "The home agent and mobile node SHOULD support ICMPv6 message type as an IPsec selector." If an implementation doesn't support them, it's not RFC4301 compliant anyway. Similarly, Section 5 says "IPsec implementations are compatible with this document even if they do not support fine grain selectors such as the Mobility Header message type and ICMPv6 message type." However, such implementations are not compliant with RFC4301; this should be said explicitly. 5) Section 4.3, "Similarly, the home agent starts to expect the new source address in the tunnel packets received from the mobile node." An RFC4301 IPsec implementation does not use the outer source address in tunnel mode packets for anything, so it doesn't "expect" anything. Similarly, Section 5 says "Typical IPsec processing does not check the outer source address.". More correctly, this is not part of IPsec processing as described in RFC 4301. 6) Section 7.1: These SPD entries do not follow anything in RFC4301; instead, they mix information that would be present in PAD as well. This section should also definitely consider PAD, as it is the part of RFC4301 that prevents one MN for creating SAs for another MN's home address. 7) Section 9: "The Home Agent should also include an INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the duration for which the dynamically allocated home address is valid." In RFC 4718 (IKEv2 clarifications) we strongly recommend against using the INTERNAL_ADDRESS_EXPIRY attribute. (Note: I'm not subscribed to the MIP6 list, so keep in in Cc line of any replies :-) Best regards, Pasi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 08 00:56:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhgP7-0007nL-D1; Wed, 08 Nov 2006 00:55:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhgP6-0007n8-AX for mip6@ietf.org; Wed, 08 Nov 2006 00:55:16 -0500 Received: from consign.cs.umd.edu ([128.8.128.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhgP3-0004ch-TI for mip6@ietf.org; Wed, 08 Nov 2006 00:55:16 -0500 Received: from delegate.pc.cs.umd.edu (exchange.cs.umd.edu [128.8.130.248]) by consign.cs.umd.edu (8.13.1/8.12.5) with ESMTP id kA85tAW0016403 for ; Wed, 8 Nov 2006 00:55:10 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Nov 2006 00:55:05 -0500 Message-ID: <5B211F0A44261848B86EC460096A555A1BAC7E@delegate.pc.cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CFP NetCri-07 Thread-Index: AccC+nBo9MA8rSEVTv2F+WzOqf01lA== From: "Elsharnouby, Tamer" To: X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.44, required 5, ALL_TRUSTED -1.44) X-CSD-MailScanner-From: sharno@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Subject: [Mip6] CFP NetCri-07 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org [Apologies for multiple postings] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Call for Papers NetCri 07 The First International Workshop on=20 Research Challenges in Next Generation Networks for=20 First Responders and Critical Infrastructures http://www.cs.umd.edu/~sharno/NetCri07 = =20 In Conjunction with=20 IEEE IPCCC 2007, New Orleans, Louisiana, April 11-13 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D As advances in pervasive computing, wireless communication and sensor = networks continue, more opportunities are open to first responders and critical = infra- structures to benefit from these technologies. Providing first = responders with the best possible technology, infrastructure and services help save the = lives of the general public and the first responders as well. One of the main = challenges to the operations of first responders and critical = infrastructures is to deploy a communication network that is dependable, secure, and = rapidly deployable. In order to operate effectively, the deployed network = supports services such as location determination, audio and video communication, = and in site and remote sensing. Another key feature for first responders and = critical infrastructures networks is to support interactions among multiple = heterogen- eous networks.=20 =20 This workshop provides a forum for researchers, industry, and government = agencies to discuss the challenges facing the design, deployment and = operation- al issues for next generation network support for first responders and = critical infrastructure. The workshop will identify and define fundamental = concepts and=20 techniques, resolve conflicts between different approaches in the area, = and=20 provide a common ground for an advanced research and development agenda. = Topics of interest include, but are not limited to: - Smart environments (buildings, roads, vehicles, etc.)=20 - Fast roaming in heterogonous network environment - Localization and time synchronization=20 - Rapidly deployable and self configuring services and networks - Security, dependability, privacy, and performance trade-offs - QoS in heterogeneous wireless networks - Sensor and actuator networks for information gathering and real-time = control - Network and system support for augmented reality and visual = analytics - Simulation studies of first responders and critical infrastructures' = networks - Novel and adaptive communication protocols to support first = responders and critical infrastructure' operation - Resource management and allocation - Power control management - Admission, load and flow control - Performance analysis and experimentation of heterogeneous wireless = networks - Security techniques and methods for heterogeneous wireless networks - Interoperability among WLANs, Cellular, WSN and wired networks - Metrics and measurements on heterogeneous networks - Mobility models and traffic patterns in disaster areas - Cross-layer design - Testbeds Paper Submission Papers should describe original, previously unpublished work, not = currently=20 under review by another conference, workshop, or journal. Authors are = invited to submit a maximum of 6 pages papers including the abstract, figures = and=20 references. Papers should include the title, author(s), authors' = affiliation and an abstract. The formatting should be according to IEEE rules. = Papers=20 should be submitted in a PDF format using the EDAS submission system. Accepted papers will be accessible through the IEEE digital library and = are=20 included in the conference proceedings. =20 Important Dates Submission deadline: November 30, 2006 Notification of acceptance: January 5, 2007 Camera ready version: January 26, 2007 Workshop Organizing Committee Program Co-Chairs Mohamed Eltoweissy, Virginia Tech, USA Moustafa Youssef, University of Maryland, USA=20 Publicity Co-Chairs Tamer Elsharnouby, Microsoft Corporation, USA James Joshi, University of Pittsburg, USA Technical Program Committee=20 Arup Acharya, IBM, USA Ashok Agrawala, University of Maryland, USA Jonathan Agre, Fujitsu Lab, USA Mustaque Ahamad, Georgia Tech, USA Nils Aschenbruck, University of Bonn, Germany Farag Azzedine, King Fahd University, Saudi Arabia Doreen Cheng, Samsung Research, USA Nagwa Elmakky, Alexandria University, Egypt Mohamed Gouda, University of Texas, USA Elena Guara, Coventry University, UK Wendi Heinzelman, University of Rochester, USA James Joshi, University of Pittsburgh, USA P. Krishnan, Avaya Labs, USA Scott Midkiff, Virginia Tech, USA Tamer Nadeem, Siemens Research, USA Dragos Niculescu, NEC Labs, USA Stephan Olariu, Old Dominion University, USA Krishna Sivalingam, University of Maryland at BC, USA Stephen D. Wolthusen, University of London, USA Mohamed Younis, University of Maryland at BC, USA Adel Youssef, Google, USA _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 08 05:54:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghl3L-0006RB-2r; Wed, 08 Nov 2006 05:53:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghl3J-0006Pt-9I for mip6@ietf.org; Wed, 08 Nov 2006 05:53:05 -0500 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghl3H-0002qs-IK for mip6@ietf.org; Wed, 08 Nov 2006 05:53:05 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 08 Nov 2006 11:53:03 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAMpDUUWQ/uCLcmdsb2JhbACMSgEJDyo X-IronPort-AV: i="4.09,400,1157320800"; d="scan'208"; a="118040314:sNHT47419016" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA8Ar2Ej021344; Wed, 8 Nov 2006 11:53:02 +0100 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA8Aqs4d005053; Wed, 8 Nov 2006 11:53:01 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 11:52:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Date: Wed, 8 Nov 2006 11:52:54 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC02FD2862@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA should not be usedwhen traversingIPv4 NAT) Thread-Index: Acb+iTuAbG1CXdxsRpGV4mwy2OMyAAAx5R4gAJAEy2AADt0eIABTkryw From: "Pascal Thubert \(pthubert\)" To: "Soliman, Hesham" , "Narayanan, Vidya" , "RYUJI WAKIKAWA" X-OriginalArrivalTime: 08 Nov 2006 10:52:59.0638 (UTC) FILETIME=[0E43D160:01C70324] DKIM-Signature: a=rsa-sha1; q=dns; l=8817; t=1162983182; x=1163847182; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20What=20are=20we=20protecting=20over=20IPv4=20in=20DS- MIP6?=20(RE=3A=20[Mip6]=20concensus=3A=20issue=2076=3A=20Alt=20CoA=20shoul d=20not=20be=20usedwhen=09traversingIPv4=20NAT) |Sender:; X=v=3Dcisco.com=3B=20h=3DKsaCfokeTao80uTL0s7Oque8avM=3D; b=E4vuqVJ0RbpJtcrw40/49RtH2uX8nIlwRQqBo/FoxNcjyMjrb+4j+CzcFLQMNQnQphFPWK7+ xX2XYAH50ZBWp4FKKjOHT8SJPVLdkuqmgqh2LvmpxLDtBFzjoqimLtgK; Authentication-Results: ams-dkim-2; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Hesham: To be honest I do not mind which integrity 2) tests because to my best knowledge, it is only useful when the source IPv4 address matches the mapped one in the Ipv6 CoA. If that's so and you could test either address, you're done, aren't you? But that's not the issue because integrity is not the final goal. The final goal is to prove that the MN is reachable at the CoA, because at the end of the day, the protocol is about binding an identity (the HoA) with the location where it can be reached (the CoA). The integrity check of the CoA verifies that the (TRUSTED) MN (BELIEVES THAT IT) owns that address, so it is an only indirect proof of reachability, based on other assumptions which are difficult to assert for sure (trust and belief). I agree that the Internet in between will not change in a day, and that we can not prevent a MITM attack from destroying some or all packets between MN and HA, just the way one can not prevent a good willing public access to provide too little bandwidth for instance.=20 Yet IPSec coupled with RR test verifies the integrity of the data and actually proves the validity of the end points, making the Internet a safer place to roam. Pascal >-----Original Message----- >From: Soliman, Hesham [mailto:hsoliman@qualcomm.com] >Sent: Monday, November 06, 2006 6:55 PM >To: Pascal Thubert (pthubert); Narayanan, Vidya; RYUJI WAKIKAWA >Cc: Vijay Devarapalli; mip6@ietf.org >Subject: RE: What are we protecting over IPv4 in DS-MIP6? (RE: [Mip6] concensus: issue 76: Alt CoA >should not be usedwhen traversingIPv4 NAT) > >Hi Pascal, > >The options you list below are mixing two different problems together. > >There were two issues discussed: > >A. Integrity of the CoA in the IPv6 packet > >B. Integrity of the IPv4 header. > >Option 2) below is intended for A) above and option 3) was discussed to >address B. I hope it's clear that the options you list below are not >alternatives as they address different problems. > >Hesham > > > > I'm with you on that. > > > > The options we have are so far: > > > > 1) do nothing. If the MN roams in IPv4, the source is not protected. > > There is a potential of an attack, but that is a difficult one, in an > > IPv4 world where so many other attacks are possible anyway. > > > > 2) provide the source IPv4 address one way or another. This approach > > includes Hesham's checksum. This seems to provide an IPv6 equivalent > > security in the absence of NAT. I'd argue that it does not really, > > because it is still the IPv4 world, and with IPv4 it much > > easier to fool > > a visiting MN into using, as CoA, an address that belongs to > > an attacked > > server. > > > > 3) propose an optional RR test. The test verifies that the MN is > > reachable at the CoA, so it protects even against NAT and > > rogue router > > in the visited network. > > > > I think we have to consider the whole picture, thus I favor > > 3. I could > > do with 1, and then we'd propose the optional RR test as a separate > > draft, which would be valid for all declinations of MIP6, > > should the WG > > decide that the RR test is not specific to this draft. > > > > I have trouble with 2. People who do not really understand > > what it does > > might get a false sense of security, which can be even more > > dangerous. > > Once this option is in, it will be hard to take it out, even > > when the RR > > test is available and actually provides a better security. > > > > Pascal > > > > > > > > > > >-----Original Message----- > > >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > >Sent: Friday, November 03, 2006 5:00 PM > > >To: RYUJI WAKIKAWA > > >Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert (pthubert); > > Soliman, Hesham > > >Subject: RE: What are we protecting over IPv4 in DS-MIP6? > > (RE: [Mip6] > > concensus: issue 76: Alt CoA > > >should not be usedwhen traversingIPv4 NAT) > > > > > >Hi Ryuji, > > >I think this is missing the threat model. Let's look at two possible > > >scenarios. > > > > > >1. MN --- (Attacker) --- HA > > > > > >2. MN --- (Attacker1) --- NAT --- (Attacker2) --- HA > > > > > >( ) indicates that an attacker may be present. > > > > > >If the HA received a BU with the inner and outer addresses > > the same, it > > >has no way of telling it was due to case 1 with no attacker > > or case 2 > > >with Attacker 2 who changed a NAT'ed outer address back to equal the > > >inner address. > > > > > >So, there is no use in saying that the check is done when the HA > > detects > > >a NAT. > > > > > >But, we can document this issue and say that we don't > > protect against > > >on-path attackers in IPv4, because it is complicated and > > not worth it. > > I > > >guess that's what Vijay and Hesham are saying - I could be > > convinced of > > >that, although, I don't see why we can't make the RR > > optional and leave > > >it at that. > > > > > >Vidya > > > > > > > > >> -----Original Message----- > > >> From: RYUJI WAKIKAWA [mailto:ryuji.wakikawa@gmail.com] > > >> Sent: Thursday, November 02, 2006 6:07 AM > > >> To: Narayanan, Vidya > > >> Cc: Vijay Devarapalli; mip6@ietf.org; Pascal Thubert > > >> (pthubert); Soliman, Hesham > > >> Subject: Re: What are we protecting over IPv4 in DS-MIP6? > > >> (RE: [Mip6] concensus: issue 76: Alt CoA should not be > > >> usedwhen traversingIPv4 NAT) > > >> > > >> Hi Vidya > > >> > > >> RR check can be one solution, but as other people pointed > > >> out, this causes additional round trip. > > >> In addition, if there is no NAT, we can simply protect CoA by > > >> ACoA option. > > >> If HA detects that the CoA is different between IPv4 header > > >> and ACoA, it can operate your RR check. > > >> Otherwise, it should be skipped. > > >> A new message BA-ack may be sufficient. i.e. An > > >> acknowledgment of BA sent back from MN. > > >> > > >> ryuji > > >> > > >> On 2006/11/02, at 4:08, Narayanan, Vidya wrote: > > >> > > >> > > > >> > All, > > >> > This is something I should've raised yesterday when I > > read all the > > >> > emails, but after sleeping over it and some other > > discussions, I'm > > >> > still confused - so, figured I should raise it now :) > > >> > > > >> > First, I don't believe that an AltCoA option (v4 or v6) > > >> buys anything. > > >> > Let's look at this. > > >> > > > >> > In IPv4, the outer IP address is always up for > > >> modifications and there > > >> > is no way to distinguish an adversary modifying it from a NAT > > >> > modifying it. And, if the outer IPv4 source address is > > >> different from > > >> > the inner IP address, there is no way for the HA to figure > > >> out whether > > >> > the modification is due to a NAT or an adversary. Such > > is the truth > > >> > with NATs and there is nothing that can be done about it. > > >> Even if the > > >> > outer and inner IP addresses are the same, there is no way > > >> to figure > > >> > out that they are the same because there is no NAT or > > >> because a NAT-ed > > >> > IP address in the outer header has been modified back > > to equal the > > >> > inner IP address by an adversary. This is quite feasible, > > >> especially > > >> > when the inner packet is not encrypted and totally > > depends on the > > >> > intention of the attacker. > > >> > > > >> > The presence of the Alt-CoA option buys nothing exactly for > > >> the same > > >> > reasons. The fact that the Alt-CoA option is integrity > > >> protected means > > >> > nothing, since the HA still must use the outer IP address > > >> as the CoA - > > >> > and there is no guarantee about that being intact. > > >> > > > >> > We cannot pick and choose what attacks we like and what > > we don't. > > >> > Either > > >> > we protect against redirection attacks or we don't. At this > > >> point, I'm > > >> > saying that integrity protection of the actual CoA alone proves > > >> > nothing. > > >> > Reachability checks have more value than integrity > > protection of a > > >> > field that is allowed to be modified. Reachability checks > > >> too, in the > > >> > absence of confidentiality on the inner packet, does > > not guarantee > > >> > that an attacker is not on the path - but, it at least > > >> proves that the > > >> > MN is reachable at that address. > > >> > > > >> > So, my vote would be to perform an optional > > reachability check and > > >> > document the vulnerability that may still exist. > > >> > > > >> > Vidya > > >> > > > >> > _______________________________________________ > > >> > Mip6 mailing list > > >> > Mip6@ietf.org > > >> > https://www1.ietf.org/mailman/listinfo/mip6 > > >> > > >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 08 20:14:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyTp-0005h0-C3; Wed, 08 Nov 2006 20:13:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhyTn-0005fg-Vj; Wed, 08 Nov 2006 20:13:19 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhyTl-00054n-Ll; Wed, 08 Nov 2006 20:13:19 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id kA91DH5G030486; Wed, 8 Nov 2006 20:13:17 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kA91DGG8325112; Wed, 8 Nov 2006 18:13:16 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kA91DGcH017843; Wed, 8 Nov 2006 18:13:16 -0700 Received: from cichlid.raleigh.ibm.com (wecm-9-67-79-142.wecm.ibm.com [9.67.79.142]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kA91DFA5017819; Wed, 8 Nov 2006 18:13:16 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.7/8.12.5) with ESMTP id kA91CtM5021694; Wed, 8 Nov 2006 17:12:56 -0800 Message-Id: <200611090112.kA91CtM5021694@cichlid.raleigh.ibm.com> To: netlmm@ietf.org, mip6@ietf.org Date: Wed, 08 Nov 2006 17:12:55 -0800 From: Thomas Narten X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Mip6] 3GPP2 Correspondence to IETF on netlmm X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org The IETF has just received a formal correspondence from 3GPP2 TSG-X concerning network based mobility. The statement is short and says: > 3GPP2 has made a decision to use the Proxy Mobile IP concept as a > network based mobility management solution. We appreciate your help > to progress the related work in IETF Mobile IP working groups. (It will appear on the liaison statements page in a few days.) Thomas (IETF Liaison to 3GPP2) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 09 20:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiL2H-0000ya-3H; Thu, 09 Nov 2006 20:18:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiL2F-0000pc-E2 for mip6@ietf.org; Thu, 09 Nov 2006 20:18:23 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiL21-00031x-ET for mip6@ietf.org; Thu, 09 Nov 2006 20:18:23 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8H00HOMR6MGP@szxga02-in.huawei.com> for mip6@ietf.org; Fri, 10 Nov 2006 09:37:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8H00GVLR6LZD@szxga02-in.huawei.com> for mip6@ietf.org; Fri, 10 Nov 2006 09:37:34 +0800 (CST) Received: from lenovof5e5390a ([10.164.5.13]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8H00C6KQWCA5@szxml04-in.huawei.com> for mip6@ietf.org; Fri, 10 Nov 2006 09:31:25 +0800 (CST) Date: Fri, 10 Nov 2006 09:17:26 +0800 From: wenson Subject: Re: [Mip6] On a network-mobility solution based on Mobile IPv6 To: Jean-Michel Combes Message-id: <00a201c70465$fbdbc300$0d05a40a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <255498EAB77FB240B3951466AD2340D5DDA655@scsmsx414.amr.corp.intel.com> <069f01c6de6c$272aabe0$526015ac@dcml.docomolabsusa.com> <45142FB4.2030801@azairenet.com> <729b68be0609250436u20f92871w34c7efdac2360d55@mail.gmail.com> <729b68be0609250448k2ebae46etc39794a59399166@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Since SEND only secure IP address of SEND Node and ND proxy should delegate any Node on the same local link to send packets with link local address of this Node as source IP address and ProxyNode'Mac address as source Mac Address. It seems ND proxy could not be used to in conjunction with SEND. BTW, Does proxy ND have relay functionality,e.g.,ND relay? If do, Is there any difference between them? ----- Original Message ----- From: "Jean-Michel Combes" To: "Vijay Devarapalli" Cc: ; "James Kempf" Sent: Monday, September 25, 2006 7:48 PM Subject: Re: [Mip6] On a network-mobility solution based on Mobile IPv6 > Additionnal comment. > > 2006/9/25, Jean-Michel Combes : >> 2006/9/22, Vijay Devarapalli : >> > hi Jim, >> > >> >> [snip] >> >> > >> > James Kempf wrote: >> >> [snip] >> >> > > In addition, from a service provider standpoint, I think PMIP is the >> > > wrong solution for the Internet, >> > >> > I don't think anybody pitched it as a solution that can be >> > deployed on the Internet as a general purpose mobility >> > management protocol. all network-based mobility management >> > protocol don't work if the HA (LMA) and the AR (MAG) are in >> > different domains. they also work very poorly if there is >> > a handoff across heterogeneous access technologies. >> > host-based mobility is what make sense in a handoff that >> > involves different access technologies. >> >> I agree with Vijay. >> >> There are needs of strong trust between the MIPv6 proxies and the HA. >> Such a strong trust, generally, only exists when the HA and the MIPv6 >> proxies are in the same administrative domain. > > Or an AAA infrastructure may be used to bring security material to set > up this trust. But there is not such a infrastructure in all the > access networks. > > Best regards. > > JMC. > >> And so, IMO, we are in >> the NetLMM scenario (i.e. s/MIPv6 proxy/MAG and s/HA/LMA). >> >> Now, if PMIPv6 is needed by SDOs, I think that the right WG is NetLMM >> and so people have to ask why PMIPv6 proposal has been rejected. >> >> [snip] >> >> Best regards. >> >> JMC. >> >> > >> > Vijay >> > >> > _______________________________________________ >> > Mip6 mailing list >> > Mip6@ietf.org >> > https://www1.ietf.org/mailman/listinfo/mip6 >> > >> > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 10 11:34:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZJ4-0001uN-ED; Fri, 10 Nov 2006 11:32:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiZJ3-0001tm-5S for mip6@ietf.org; Fri, 10 Nov 2006 11:32:41 -0500 Received: from wx-out-0506.google.com ([66.249.82.230]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiZJ1-0003pd-Vd for mip6@ietf.org; Fri, 10 Nov 2006 11:32:41 -0500 Received: by wx-out-0506.google.com with SMTP id h29so554233wxd for ; Fri, 10 Nov 2006 08:32:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=GjNudsBk7OF3X5HJivtDvMSRjf6b6Gead/ANbk6IBSwqK/tGkbueogQDAYaP1rBQxVYelz5Hx0G4GS9RKKMRVHHoM0uzpc1hgZfEEdl1bQ0KwFqocas6iM5KztttIfLvvCbGUhmrUFoyjRs5tdRJHU9xQ7aYqd5T1gvLMYsGkq4= Received: by 10.70.109.4 with SMTP id h4mr3357370wxc.1163176359361; Fri, 10 Nov 2006 08:32:39 -0800 (PST) Received: by 10.70.15.8 with HTTP; Fri, 10 Nov 2006 08:32:39 -0800 (PST) Message-ID: <90eccf9f0611100832u3464c6c9pb71ed89f9d40e7a4@mail.gmail.com> Date: Fri, 10 Nov 2006 22:02:39 +0530 From: "Rohan Sen" To: mip6@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.7 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Mip6] Sample packet capture X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0572571169==" Errors-To: mip6-bounces@ietf.org --===============0572571169== Content-Type: multipart/alternative; boundary="----=_Part_68364_17193963.1163176359085" ------=_Part_68364_17193963.1163176359085 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, I am currently in the process of implementing a mobile ipv6 MN. I intend to use mipl for compatibility but I would really appreciate if some one could help me in finding ethereal capture of mobile ipv 6 session. thanks and best regards, Rohan Sen ------=_Part_68364_17193963.1163176359085 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All,

I am currently in the process of implementing a mobile ipv6 MN. I intend to use mipl for compatibility but I would really appreciate if some one could help me in finding ethereal capture of mobile ipv 6 session.

thanks and best regards,
Rohan Sen
------=_Part_68364_17193963.1163176359085-- --===============0572571169== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0572571169==-- From mip6-bounces@ietf.org Sat Nov 11 13:45:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gixpn-00059v-FN; Sat, 11 Nov 2006 13:44:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gixpl-00059p-Jl for mip6@ietf.org; Sat, 11 Nov 2006 13:44:05 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gixpj-0002jR-5d for mip6@ietf.org; Sat, 11 Nov 2006 13:44:05 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 11 Nov 2006 10:44:03 -0800 X-IronPort-AV: i="4.09,413,1157353200"; d="scan'208,217"; a="343249832:sNHT91421524" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kABIi204015329 for ; Sat, 11 Nov 2006 10:44:02 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kABIi2io028298 for ; Sat, 11 Nov 2006 10:44:02 -0800 (PST) Received: from xmb-sjc-224.amer.cisco.com ([128.107.191.98]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 10:44:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sat, 11 Nov 2006 10:44:00 -0800 Message-ID: <28CEA477BE98ED48AF08A0B637A74BF402954CE6@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTw== From: "Gopal Dommety \(gdommety\)" To: X-OriginalArrivalTime: 11 Nov 2006 18:44:02.0046 (UTC) FILETIME=[5B3649E0:01C705C1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3884; t=1163270642; x=1164134642; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gdommety@cisco.com; z=From:=20=22Gopal=20Dommety=20\(gdommety\)=22=20 |Subject:=20Should=20we=20add=20the=20requirements=20that=20arise=20from= 20=20RFC=204285=20in=20the=20draft-ietf-mip6-aaa-ha-goals-03? |Sender:=20; bh=BEWq03I8k7GpgkqQp7lKtwwADmWGjDCmVdxmZ3hRSfw=; b=dWqNpjBHE8m6xK752R4hdftFW/8xJBtk55ozQr77IiWvQAs4gcDLiKwqaXC0/0laDnu+mcEv YZPjNZJZo0o0LLfWEKjgC6y86+ClFfnNiP1wm0JaK44awJYG1hkQChn0; Authentication-Results: sj-dkim-1; header.From=gdommety@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Subject: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0748566521==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0748566521== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C705C1.5B1CC817" This is a multi-part message in MIME format. ------_=_NextPart_001_01C705C1.5B1CC817 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 Cheers, Gopal and Raj ------_=_NextPart_001_01C705C1.5B1CC817 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello=20 All,
 
    Wanted to get the MIP6 = Working=20 groups preference on whether we should we add the = requirements that arise from RFC 4285 in the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We = would like to=20 hear the Working Groups opinion of the following = question:
 
Should we = add the=20 requirements that arise from RFC 4285 in the =20 draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please answer "yes"=20 or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" = and 5 for=20 "No".
 
Cheers,
Gopal = and=20 Raj
------_=_NextPart_001_01C705C1.5B1CC817-- --===============0748566521== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0748566521==-- From mip6-bounces@ietf.org Sat Nov 11 16:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj027-00067m-44; Sat, 11 Nov 2006 16:04:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gj025-00066E-7I for mip6@ietf.org; Sat, 11 Nov 2006 16:04:57 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gj022-0008Eg-Ut for mip6@ietf.org; Sat, 11 Nov 2006 16:04:57 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kABL4R4X001638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 11 Nov 2006 13:04:28 -0800 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kABL4RO4027694; Sat, 11 Nov 2006 13:04:27 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 11 Nov 2006 13:04:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Sat, 11 Nov 2006 13:04:26 -0800 Message-ID: In-Reply-To: <28CEA477BE98ED48AF08A0B637A74BF402954CE6@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwC8eS6A From: "Narayanan, Vidya" To: "Gopal Dommety \(gdommety\)" , X-OriginalArrivalTime: 11 Nov 2006 21:04:26.0493 (UTC) FILETIME=[F892E2D0:01C705D4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0971927655==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0971927655== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C705D4.F86B877A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C705D4.F86B877A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Even though draft-ietf-mip6-aaa-ha-goals-03 is slated to only becoming an informational RFC, I suppose we will looking for a PS document that really provides the AAA solution based on these goals. Having said that, it would be a problem to have a normative reference to RFC4285 in those AAA solution documents anyway. =20 =20 Aside from that, I vote "no" at the moment. There are many issues with RFC4285 and I'm not really sure we want to go down the path of fixing those. And, without fixing those, it doesn't quite make sense to do more work based on that.=20 =20 Vidya ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 10:44 AM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 =09 =09 Cheers, Gopal and Raj ------_=_NextPart_001_01C705D4.F86B877A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Even though draft-ietf-mip6-aaa-ha-goals-03 is = slated to=20 only becoming an informational RFC, I suppose we will looking for a PS = document=20 that really provides the AAA solution based on these goals. Having said=20 that, it would be a problem to have a normative reference to = RFC4285=20 in those AAA solution documents anyway.  
 
Aside from that, I vote "no" at the moment. = There are many=20 issues with RFC4285 and I'm not really sure we want to go down the path = of=20 fixing those. And, without fixing those, it doesn't quite make sense to = do more=20 work based on that.
 
Vidya


From: Gopal Dommety (gdommety)=20 [mailto:gdommety@cisco.com]
Sent: Saturday, November 11, = 2006 10:44=20 AM
To: mip6@ietf.org
Subject: [Mip6] Should we add = the=20 requirements that arise from RFC 4285 inthe=20 draft-ietf-mip6-aaa-ha-goals-03?

Hello=20 All,
 
    Wanted to get the MIP6 = Working=20 groups preference on whether we should we add the = requirements that arise from RFC 4285 in = the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We = would like to=20 hear the Working Groups opinion of the following = question:
 
Should we = add the=20 requirements that arise from RFC 4285 in the =20 = draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please answer=20 "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for = "yes"=20 and 5 for "No".
 
Cheers,
Gopal and=20 Raj
------_=_NextPart_001_01C705D4.F86B877A-- --===============0971927655== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0971927655==-- From mip6-bounces@ietf.org Sun Nov 12 10:40:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjHQ4-0000se-I6; Sun, 12 Nov 2006 10:38:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjHQ2-0000pI-Ov for mip6@ietf.org; Sun, 12 Nov 2006 10:38:50 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjHLR-0002Fa-W4 for mip6@ietf.org; Sun, 12 Nov 2006 10:34:07 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kACFX1427723; Sun, 12 Nov 2006 10:33:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Sun, 12 Nov 2006 09:32:44 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711167D714@zrc2hxm2.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwC8eS6AACan40A= From: "Ahmad Muhanna" To: "Narayanan, Vidya" , "Gopal Dommety \(gdommety\)" , X-Spam-Score: 0.2 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1760640898==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1760640898== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7066F.CD30D16D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7066F.CD30D16D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Vidya, =20 It is probably a good idea if you highlight these issues related to RFC4285. I am personally interested. Many thanks.=20 Regards,=20 Ahmad=20 =20 ________________________________ From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 Sent: Saturday, November 11, 2006 3:04 PM To: Gopal Dommety (gdommety); mip6@ietf.org Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Even though draft-ietf-mip6-aaa-ha-goals-03 is slated to only becoming an informational RFC, I suppose we will looking for a PS document that really provides the AAA solution based on these goals. Having said that, it would be a problem to have a normative reference to RFC4285 in those AAA solution documents anyway. =20 =20 Aside from that, I vote "no" at the moment. There are many issues with RFC4285 and I'm not really sure we want to go down the path of fixing those. And, without fixing those, it doesn't quite make sense to do more work based on that.=20 =20 Vidya ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 10:44 AM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 =09 =09 Cheers, Gopal and Raj ------_=_NextPart_001_01C7066F.CD30D16D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Vidya,
 
It is=20 probably a good idea if you highlight these issues related to RFC4285. = I am=20 personally interested.
Many=20 thanks. 

Regards, =
Ahmad

 


From: Narayanan, Vidya=20 [mailto:vidyan@qualcomm.com]
Sent: Saturday, November 11, = 2006 3:04=20 PM
To: Gopal Dommety (gdommety); = mip6@ietf.org
Subject:=20 RE: [Mip6] Should we add the requirements that arise from RFC 4285 = inthe=20 draft-ietf-mip6-aaa-ha-goals-03?

Even though draft-ietf-mip6-aaa-ha-goals-03 = is slated to=20 only becoming an informational RFC, I suppose we will looking for a PS = document that really provides the AAA solution based on these goals. = Having=20 said that, it would be a problem to have a normative = reference to=20 RFC4285 in those AAA solution documents anyway. =  
 
Aside from that, I vote "no" at the moment. = There are=20 many issues with RFC4285 and I'm not really sure we want to go down = the path=20 of fixing those. And, without fixing those, it doesn't quite make = sense to do=20 more work based on that.
 
Vidya


From: Gopal Dommety (gdommety)=20 [mailto:gdommety@cisco.com]
Sent: Saturday, November 11, = 2006=20 10:44 AM
To: mip6@ietf.org
Subject: [Mip6] = Should we add=20 the requirements that arise from RFC 4285 inthe=20 draft-ietf-mip6-aaa-ha-goals-03?

Hello=20 All,
 
    Wanted to get the MIP6 = Working=20 groups preference on whether we should we add the = requirements that arise from RFC 4285 in = the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We = would like to=20 hear the Working Groups opinion of the following=20 question:
 
Should = we add the=20 requirements that arise from RFC 4285 in the =20 = draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please answer=20 "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people = for "yes"=20 and 5 for "No".
 
Cheers,
Gopal and=20 Raj
------_=_NextPart_001_01C7066F.CD30D16D-- --===============1760640898== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1760640898==-- From mip6-bounces@ietf.org Mon Nov 13 10:33:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdnW-0003GP-JI; Mon, 13 Nov 2006 10:32:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdnV-0003FP-1H for mip6@ietf.org; Mon, 13 Nov 2006 10:32:33 -0500 Received: from outbound-sin.frontbridge.com ([207.46.51.80] helo=outbound2-sin-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjdnS-00024X-8o for mip6@ietf.org; Mon, 13 Nov 2006 10:32:33 -0500 Received: from outbound2-sin.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-sin-R.bigfish.com (Postfix) with ESMTP id E9B7713F9846 for ; Mon, 13 Nov 2006 15:25:19 +0000 (UTC) Received: from mail16-sin-R.bigfish.com (unknown [10.3.252.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by outbound2-sin.bigfish.com (Postfix) with ESMTP id 3037C528051 for ; Mon, 13 Nov 2006 15:25:19 +0000 (UTC) Received: from mail16-sin (localhost.localdomain [127.0.0.1]) by mail16-sin-R.bigfish.com (Postfix) with ESMTP id 9C86B16A80C3 for ; Mon, 13 Nov 2006 15:25:18 +0000 (UTC) X-BigFish: V Received: by mail16-sin (MessageSwitch) id 1163431518577682_8359; Mon, 13 Nov 2006 15:25:18 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail16-sin.bigfish.com (Postfix) with ESMTP id D5C081D18069 for ; Mon, 13 Nov 2006 15:25:17 +0000 (UTC) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.10/8.12.8) with ESMTP id kADFPGWp019199 for ; Mon, 13 Nov 2006 09:25:16 -0600 (CST) Received: from pdawg06a.ad.sprint.com (PDAWG06A.corp.sprint.com [10.122.2.33]) by mailhost.sprintspectrum.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kADFPGFg015503 for ; Mon, 13 Nov 2006 09:25:16 -0600 (CST) Received: from PLSWB09C.ad.sprint.com ([208.10.70.239]) by pdawg06a.ad.sprint.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Nov 2006 09:25:16 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Mon, 13 Nov 2006 09:25:14 -0600 Message-ID: <38586DE67CB335498A0E9BA99201311B0956C5D3@PLSWB09C.ad.sprint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwC8eS6AAFkG1gA= From: "Hirschman, Brent B [CTO]" To: X-OriginalArrivalTime: 13 Nov 2006 15:25:16.0306 (UTC) FILETIME=[EBBE4720:01C70737] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2f0065339d489fe5a2873ea9ad776d1a X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2051943775==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============2051943775== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70737.EB98CF66" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70737.EB98CF66 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Vidya, =20 I support including consideration of RFC 4285 in the informational = aspects of this work. Auth. Protocol is used by both 3GPP2 and WiMAX = and I feel it is important to keep it up-to-date in the goals document. =20 Brent Hirschman=20 Technology Development Strategist III=20 Global Technology Standards=20 KSOPHD0504-5D178=20 6220 Sprint Parkway, Overland Park, KS 66251=20 Voice 913-794-4271 FAX 913-794-0420=20 PCS 913-593-6221=20 Brent.Hirschman@sprint.com=20 IMPORTANT: This message (including any attachments) may contain = material, non-public information or proprietary information and is for = the intended recipients only. If you are not the intended recipient, you = should notify the sender and delete this message. Any disclosure, = copying, or use of this information is strictly prohibited and may = subject you to legal liability.=20 ________________________________ From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 Sent: Saturday, November 11, 2006 3:04 PM To: Gopal Dommety (gdommety); mip6@ietf.org Subject: RE: [Mip6] Should we add the requirements that arise from RFC = 4285inthe draft-ietf-mip6-aaa-ha-goals-03? =20 Even though draft-ietf-mip6-aaa-ha-goals-03 is slated to only becoming = an informational RFC, I suppose we will looking for a PS document that = really provides the AAA solution based on these goals. Having said that, = it would be a problem to have a normative reference to RFC4285 in those = AAA solution documents anyway. =20 =20 Aside from that, I vote "no" at the moment. There are many issues with = RFC4285 and I'm not really sure we want to go down the path of fixing = those. And, without fixing those, it doesn't quite make sense to do more = work based on that.=20 =20 Vidya =20 =09 ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 10:44 AM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 = inthe draft-ietf-mip6-aaa-ha-goals-03? Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we = should we add the requirements that arise from RFC 4285 in the = draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following = question: =20 Should we add the requirements that arise from RFC 4285 in the = draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were = 14 people for "yes" and 5 for "No". =20 Cheers, Gopal and Raj ------_=_NextPart_001_01C70737.EB98CF66 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Vidya,

 

I support including consideration = of RFC 4285 in the informational aspects of this work.  Auth. Protocol is = used by both 3GPP2 and WiMAX and I feel it is important to keep it up-to-date in the = goals document.

 

Brent = Hirschman
Technology Development Strategist = III
Global Technology = Standards
KSOPHD0504-5D178
6220 Sprint Parkway, Overland Park, KS = 66251

Voice 913-794-4271  FAX = 913-794-0420
PCS 913-593-6221
Brent.Hirschman@sprint.com<= font color=3Dnavy>
IMPORTANT: This message (including any attachments) may contain material, non-public information or proprietary information and is for the intended recipients only. If you are not the intended recipient, you should notify the sender and delete this = message. Any disclosure, copying, or use of this information is strictly prohibited = and may subject you to legal liability.


From: = Narayanan, Vidya [mailto:vidyan@qualcomm.com]
Sent: Saturday, November = 11, 2006 3:04 PM
To: Gopal Dommety = (gdommety); mip6@ietf.org
Subject: RE: [Mip6] = Should we add the requirements that arise from RFC 4285inthe = draft-ietf-mip6-aaa-ha-goals-03?

 

Even though draft-ietf-mip6-aaa-ha-goals-03 is slated to only becoming an = informational RFC, I suppose we will looking for a PS document that really provides = the AAA solution based on these goals. Having said that, it would be a problem to have a normative reference to RFC4285 in those AAA solution documents anyway.  

 

Aside from that, I vote = "no" at the moment. There are many issues with RFC4285 and I'm not really sure = we want to go down the path of fixing those. And, without fixing those, it = doesn't quite make sense to do more work based on that.

 

Vidya

 


From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]
Sent: Saturday, November = 11, 2006 10:44 AM
To: mip6@ietf.org
Subject: [Mip6] Should we = add the requirements that arise from RFC 4285 inthe = draft-ietf-mip6-aaa-ha-goals-03?

Hello All,

 

    Wanted to get the MIP6 Working = groups preference on whether we should we add the requirements that arise from = RFC 4285 in the   draft-ietf-mip6-aaa-ha-goals-03

 

We would like to hear the Working Groups opinion of = the following question:

 

Should we add the requirements that arise from RFC = 4285 in the  draft-ietf-mip6-aaa-ha-goals-03?

 

 Please answer "yes" or "no" = PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 = for "No".

 

Cheers,

Gopal and Raj

------_=_NextPart_001_01C70737.EB98CF66-- --===============2051943775== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2051943775==-- From mip6-bounces@ietf.org Mon Nov 13 16:18:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjBQ-0006wd-HI; Mon, 13 Nov 2006 16:17:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjBO-0006wI-M4 for mip6@ietf.org; Mon, 13 Nov 2006 16:17:34 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjjBN-0001yc-8A for mip6@ietf.org; Mon, 13 Nov 2006 16:17:34 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kADLFw207593; Mon, 13 Nov 2006 16:15:58 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Nov 2006 15:15:55 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA4371117060EF@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA43710B1A840A@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Reposting: Using the last Accepted Sequence Number in BA Thread-Index: AcZ6hxXS0AZCoNWpSGqLC1sx6fPZryM3RSHA From: "Ahmad Muhanna" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: dbj@cs.rice.edu, Vijay Devarapalli , jari.arkko@ericsson.com, "Charles E. Perkins" Subject: [Mip6] Reposting: Using the last Accepted Sequence Number in BA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0997797358==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0997797358== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70768.E8C0186D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70768.E8C0186D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, After discussing this issue with some folks at IETF67, I am reposting it one more time hoping that we will get consensus to address it fundamentally. The way that RFC3775 addresses this issue is by allowing HA to insert the last accepted sequence number in the BA sequence number field, where this field should have been populated by copying the sequence number from the corresponding BU. However, some of the logics behind not fixing this issue at the time was as follows: * MN has only one outstanding BU at a time. * Only happens in a rare scenario when the MN reboots, * IPsec is mandatory and its replay protection suffices in this case. On the other hand, I believe the proper way of handling this issue is to copy the sequence number from the BU to the sequence number field in the BA and at the same time to communicate the last accepted sequence number via a new option "Last accepted sequence number" for example. In my opinion, this issue becomes critical when using Proxy MIPv6, since the Proxy agent will have many outstanding BUs at the a time and the sequence number in the BA is used to find the matching BU. Please let me know of your thoughts. Many thanks in advance. Regards, Ahmad > _____________________________________________=20 > From: Muhanna, Ahmad [RICH2:2Q30:EXCH] =20 > Sent: Thursday, May 18, 2006 9:27 AM > To: 'mip6@ietf.org' > Cc: 'dbj@cs.rice.edu'; 'Charles E. Perkins'; > 'jari.arkko@ericsson.com'; Khalil, Mohamed [RICH2:2S20:EXCH]; > 'Basavaraj Patil'; 'Gopal Dommety' > Subject: MIPv6: Using the last Accepted Sequence Number in BA >=20 >=20 > Hi all, >=20 > In response to a Binding Update which contains an out of range > sequence number, as per sections 9.5.1 and 11.7.1, the CN or HA is > allowed to send a Binding Acknowledgement with a status of 135 after > inserting the last accepted sequence number received in the last valid > Binding Update in the sequence number field (Different from the > sequence number received in the outstanding BU) >=20 > According to MN processing of the Binding Acknowledgement as specified > under section 11.7.3., the MN will silently discard the received BA > rather than picking the last accepted sequence number and then > generate a new sequence number.=20 >=20 > I think the intention was to allow the HA or CN to communicate back to > the MN the last accepted sequence number, however, we are breaking the > protocol by using this mechanism. >=20 > Could you please comment on this and let me know if I am on the right > track. > Thanks. >=20 > Regards, > Ahmad >=20 ------_=_NextPart_001_01C70768.E8C0186D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Reposting: Using the last Accepted Sequence Number in BA

Hi All,

After discussing this = issue with some folks at IETF67, I am reposting it one more time hoping = that we will get consensus to address it fundamentally.

The way that RFC3775 = addresses this issue is by allowing HA to insert the last accepted = sequence number in the BA sequence number field, where this field should = have been populated by copying the sequence number from the = corresponding BU. However, some of the logics behind not fixing this = issue at the time was as follows:

  • MN has only one = outstanding BU at a time.
  • Only happens in a = rare scenario when the MN reboots,
  • IPsec is mandatory = and its replay protection suffices in this case.

On the other hand, I = believe the proper way of handling this issue is to copy the sequence = number from the BU to the sequence number field in the BA and at the = same time to communicate the last accepted sequence number via a new = option "Last accepted sequence number" for example. In my = opinion, this issue becomes critical when using Proxy MIPv6, since the = Proxy agent will have many outstanding BUs at the a time and the = sequence number in the BA is used to find the matching BU.

Please let me know of = your thoughts.

Many thanks in = advance.

Regards,
Ahmad


    _____________________________________________
    From:   Muhanna, Ahmad [RICH2:2Q30:EXCH] 
    Sent:   Thursday, May 18, 2006 9:27 AM
    To:     'mip6@ietf.org'
    Cc:     'dbj@cs.rice.edu'; 'Charles E. Perkins'; = 'jari.arkko@ericsson.com'; Khalil, Mohamed [RICH2:2S20:EXCH]; 'Basavaraj = Patil'; 'Gopal Dommety'

    Subject:       = MIPv6: Using the last Accepted = Sequence Number in BA


    Hi all,

    In response to a Binding Update = which contains an out of range sequence number, as per sections 9.5.1 = and 11.7.1, the CN or HA is allowed to send a Binding Acknowledgement = with a status of 135 after inserting the last accepted sequence number = received in the last valid Binding Update in the sequence number field = (Different from the sequence number received in the outstanding = BU)

    According to MN processing of the = Binding Acknowledgement as specified under section 11.7.3., the MN will = silently discard the received BA rather than picking the last accepted = sequence number and then generate a new sequence number.

    I think the intention was to = allow the HA or CN to communicate back to the MN the last accepted = sequence number, however, we are breaking the protocol by using this = mechanism.

    Could you please comment on this = and let me know if I am on the right track.
    Thanks.

    Regards,
    Ahmad

------_=_NextPart_001_01C70768.E8C0186D-- --===============0997797358== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0997797358==-- From mip6-bounces@ietf.org Mon Nov 13 16:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjbT-0005kw-Dy; Mon, 13 Nov 2006 16:44:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjbR-0005kn-SZ for mip6@ietf.org; Mon, 13 Nov 2006 16:44:29 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjjbQ-0005Rr-HY for mip6@ietf.org; Mon, 13 Nov 2006 16:44:29 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kADLha214046; Mon, 13 Nov 2006 16:43:36 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Mon, 13 Nov 2006 15:43:22 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F678C@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA437111706171@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwC8eS6AACan40AAP2pHUAAAJ3ig From: "Mohamed Khalil" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Cc: gdommety@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1853471794==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1853471794== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7076C.BDCD6565" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7076C.BDCD6565 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support. ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 10:44 AM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 =09 =09 Cheers, Gopal and Raj ------_=_NextPart_001_01C7076C.BDCD6565 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 support.

From: Gopal Dommety (gdommety)=20 [mailto:gdommety@cisco.com]
Sent: Saturday, November 11, = 2006 10:44=20 AM
To: mip6@ietf.org
Subject: [Mip6] Should we add = the=20 requirements that arise from RFC 4285 inthe=20 draft-ietf-mip6-aaa-ha-goals-03?

Hello=20 All,
 
    Wanted to get the = MIP6 Working=20 groups preference on whether we should we add the = requirements that arise from RFC 4285 in = the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We would like=20 to hear the Working Groups opinion of the following=20 question:
 
Should we add the=20 requirements that arise from RFC 4285 in the =20 = draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please answer=20 "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people = for=20 "yes" and 5 for "No".
 
Cheers,
Gopal and=20 = Raj
=00 ------_=_NextPart_001_01C7076C.BDCD6565-- --===============1853471794== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1853471794==-- From mip6-bounces@ietf.org Tue Nov 14 11:31:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1BF-0007cT-Ed; Tue, 14 Nov 2006 11:30:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1BE-0007cA-Ev for mip6@ietf.org; Tue, 14 Nov 2006 11:30:36 -0500 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk1B9-0005QK-OY for mip6@ietf.org; Tue, 14 Nov 2006 11:30:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 8BB261E0298 for ; Tue, 14 Nov 2006 11:30:27 -0500 (EST) Received: from mx0.starentnetworks.com ([127.0.0.1]) by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25577-04 for ; Tue, 14 Nov 2006 11:30:23 -0500 (EST) Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com [12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Tue, 14 Nov 2006 11:30:23 -0500 (EST) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by exchtewks1.starentnetworks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 11:30:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Tue, 14 Nov 2006 11:30:22 -0500 Message-ID: <7CCD07160348804497EF29E9EA5560D7FBD4E0@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFKJRMQ From: "Chowdhury, Kuntal" To: "Gopal Dommety (gdommety)" , X-OriginalArrivalTime: 14 Nov 2006 16:30:23.0078 (UTC) FILETIME=[2EC62060:01C7080A] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1400824110==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1400824110== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7080A.2EA54208" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7080A.2EA54208 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Yes. =20 ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 12:44 PM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? =20 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 Cheers, Gopal and Raj ------_=_NextPart_001_01C7080A.2EA54208 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Yes.

 


From: Gopal = Dommety (gdommety) [mailto:gdommety@cisco.com]
Sent: Saturday, November = 11, 2006 12:44 PM
To: mip6@ietf.org
Subject: [Mip6] Should we = add the requirements that arise from RFC 4285 inthe = draft-ietf-mip6-aaa-ha-goals-03?

 

Hello All,

 

    Wanted to get the MIP6 Working = groups preference on whether we should we add the requirements that arise from = RFC 4285 in the   = draft-ietf-mip6-aaa-ha-goals-03

 

We would like to hear the Working Groups opinion of = the following question:

 

Should we add the requirements that arise from RFC = 4285 in the  draft-ietf-mip6-aaa-ha-goals-03?

 

 Please answer "yes" or "no" = PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 = for "No".

 

Cheers,

Gopal and Raj

------_=_NextPart_001_01C7080A.2EA54208-- --===============1400824110== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1400824110==-- From mip6-bounces@ietf.org Tue Nov 14 12:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1vI-0003HK-Ji; Tue, 14 Nov 2006 12:18:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk1vG-0003HF-Kv for mip6@ietf.org; Tue, 14 Nov 2006 12:18:10 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk1vF-0003xV-C8 for mip6@ietf.org; Tue, 14 Nov 2006 12:18:10 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAEHI6A22900; Tue, 14 Nov 2006 12:18:06 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Date: Tue, 14 Nov 2006 11:18:00 -0600 Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA437111761289@zrc2hxm2.corp.nortel.com> In-Reply-To: <28CEA477BE98ED48AF08A0B637A74BF402954CE6@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFLzXUA From: "Ahmad Muhanna" To: "Gopal Dommety \(gdommety\)" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485681318==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0485681318== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70810.D62D27AD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70810.D62D27AD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YES. Regards,=20 Ahmad=20 =20 ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 12:44 PM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 =09 =09 Cheers, Gopal and Raj ------_=_NextPart_001_01C70810.D62D27AD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
YES.

Regards, =
Ahmad

 


From: Gopal Dommety (gdommety)=20 [mailto:gdommety@cisco.com]
Sent: Saturday, November 11, = 2006 12:44=20 PM
To: mip6@ietf.org
Subject: [Mip6] Should we add = the=20 requirements that arise from RFC 4285 in the=20 draft-ietf-mip6-aaa-ha-goals-03?

Hello=20 All,
 
    Wanted to get the MIP6 = Working=20 groups preference on whether we should we add the = requirements that arise from RFC 4285 in = the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We = would like to=20 hear the Working Groups opinion of the following = question:
 
Should we = add the=20 requirements that arise from RFC 4285 in the =20 = draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please answer=20 "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for = "yes"=20 and 5 for "No".
 
Cheers,
Gopal and=20 Raj
------_=_NextPart_001_01C70810.D62D27AD-- --===============0485681318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0485681318==-- From mip6-bounces@ietf.org Tue Nov 14 12:41:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2H7-0005sb-Mj; Tue, 14 Nov 2006 12:40:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2H3-0005ms-OQ for mip6@ietf.org; Tue, 14 Nov 2006 12:40:41 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2H2-0007BS-Cf for mip6@ietf.org; Tue, 14 Nov 2006 12:40:41 -0500 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAEHebsj023930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Nov 2006 09:40:38 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAEHdvIO008253; Tue, 14 Nov 2006 09:40:37 -0800 (PST) Received: from sanexcas01.na.qualcomm.com ([172.30.36.175]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 09:40:36 -0800 Received: from NAEX16.na.qualcomm.com ([10.47.6.158]) by sanexcas01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 09:40:35 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Tue, 14 Nov 2006 09:40:16 -0800 Message-ID: <2309978910A6A6478C2C7585692B0AF405A23D@NAEX16.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifA From: "Tsirtsis, George" To: "Gopal Dommety \(gdommety\)" , X-OriginalArrivalTime: 14 Nov 2006 17:40:35.0479 (UTC) FILETIME=[FD8F8270:01C70813] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gopal, I am not sure I understand the question. RFC4285 defines a = mechanism/solution and an associated applicability statement. What is it = that you propose to "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what = form? I would also appreciate if people voting "yes" or "no" on this (or any) = issue, say something about why they vote one way or the other. Regards George ________________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 1:44 PM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 = inthe draft-ietf-mip6-aaa-ha-goals-03? Hello All, =A0 =A0=A0=A0 Wanted to get the MIP6 Working groups preference on whether we = should we add the requirements that arise from RFC 4285 in the =A0 = draft-ietf-mip6-aaa-ha-goals-03 =A0 We would like to hear the Working Groups opinion of the following = question: =A0 Should we add the requirements that arise from RFC 4285 in the=A0 = draft-ietf-mip6-aaa-ha-goals-03? =A0 =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there = were 14 people for "yes" and 5 for "No". =A0 Cheers, Gopal and Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 14 13:26:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2yX-0001Cd-QD; Tue, 14 Nov 2006 13:25:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk2yW-0001As-2U for mip6@ietf.org; Tue, 14 Nov 2006 13:25:36 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk2yS-0004gU-Nm for mip6@ietf.org; Tue, 14 Nov 2006 13:25:36 -0500 Received: from [10.1.201.6] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 10:25:31 -0800 Message-ID: <455A0A1B.1000600@azairenet.com> Date: Tue, 14 Nov 2006 10:25:31 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Gopal Dommety (gdommety)" Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? References: <28CEA477BE98ED48AF08A0B637A74BF402954CE6@xmb-sjc-224.amer.cisco.com> In-Reply-To: <28CEA477BE98ED48AF08A0B637A74BF402954CE6@xmb-sjc-224.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 18:25:31.0604 (UTC) FILETIME=[44938940:01C7081A] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Gopal, lets step back a bit. what is the point of adding of 4285-specific requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic 4285 operation where the HA-AAAH interface is used for MN authentication? or does it include bootstrapping for 4285 too? will the requirements be added to draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in one place with no binding to develop any solutions yet? other bootstrapping related questions, do we want to standardize bootstrapping solutions for 4285 too? has the DIME WG agreed to developing solutions for 4285-based MIP6 operation? Vijay Gopal Dommety (gdommety) wrote: > Hello All, > > Wanted to get the MIP6 Working groups preference on whether we > should we add the requirements that arise from RFC 4285 in the > draft-ietf-mip6-aaa-ha-goals-03 > > We would like to hear the Working Groups opinion of the following question: > > Should we add the requirements that arise from RFC 4285 in the > draft-ietf-mip6-aaa-ha-goals-03? > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were > 14 people for "yes" and 5 for "No". > > Cheers, > Gopal and Raj > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 14 15:09:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4a5-0008RN-4i; Tue, 14 Nov 2006 15:08:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4a3-0008Nr-O8 for mip6@ietf.org; Tue, 14 Nov 2006 15:08:27 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4a1-0003vm-Ng for mip6@ietf.org; Tue, 14 Nov 2006 15:08:27 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 14 Nov 2006 12:08:24 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id kAEK8OUi018088; Tue, 14 Nov 2006 12:08:24 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kAEK8Oin019387; Tue, 14 Nov 2006 12:08:24 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 12:08:24 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? Date: Tue, 14 Nov 2006 12:08:23 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202DFB8A3@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccIHFSSBlUgJtl+SoWX2OC6YWqsAwADB4JA From: "Kent Leung \(kleung\)" To: "Vijay Devarapalli" , "Gopal Dommety \(gdommety\)" X-OriginalArrivalTime: 14 Nov 2006 20:08:24.0201 (UTC) FILETIME=[A3BB1790:01C70828] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2134; t=1163534904; x=1164398904; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20\(kleung\)=22=20 |Subject:=20RE=3A=20[Mip6]=20Should=20we=20add=20the=20requirements=20tha t=20arise=20from=20RFC=204285in=09the=20draft-ietf-mip6-aaa-ha-goals-03? |Sender:=20; bh=3Yxoc4YyzVHQ9RicVHW7N3kLds4Zs4lDibIhtIOkAXc=; b=mdS5MHBR4zlTEuE3qQtcyHSlwZTegV7QqQ01+LEXluHPEwoHq5CDTTiwYeDjHLBDAWVUhh+0 aJ6wPBrLxHQgZqpVMlyR/kbr0wmN89KjLeNQNKjNRPOecOA569sQHNIo; Authentication-Results: sj-dkim-4; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org My vote is YES. I assume this question is intended for HA-AAA interface support for RFC 4285. But it would be definitely nice to have standards-based AAA attributes for bootstrapping in terms of completeness. =20 Kent -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 Sent: Tuesday, November 14, 2006 10:26 AM To: Gopal Dommety (gdommety) Cc: mip6@ietf.org Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? Gopal, lets step back a bit. what is the point of adding of 4285-specific requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic 4285 operation where the HA-AAAH interface is used for MN authentication? or does it include bootstrapping for 4285 too? will the requirements be added to draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in one place with no binding to develop any solutions yet? other bootstrapping related questions, do we want to standardize bootstrapping solutions for 4285 too? has the DIME WG agreed to developing solutions for 4285-based MIP6 operation? Vijay Gopal Dommety (gdommety) wrote: > Hello All, > =20 > Wanted to get the MIP6 Working groups preference on whether we=20 > should we add the requirements that arise from RFC 4285 in the =20 > draft-ietf-mip6-aaa-ha-goals-03 > =20 > We would like to hear the Working Groups opinion of the following question: > =20 > Should we add the requirements that arise from RFC 4285 in the=20 > draft-ietf-mip6-aaa-ha-goals-03? > =20 > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there=20 > were > 14 people for "yes" and 5 for "No". > =20 > Cheers, > Gopal and Raj >=20 >=20 > ---------------------------------------------------------------------- > -- >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 14 15:18:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4ju-0005ma-U4; Tue, 14 Nov 2006 15:18:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4jt-0005mC-5W for mip6@ietf.org; Tue, 14 Nov 2006 15:18:37 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4jr-0005SV-PZ for mip6@ietf.org; Tue, 14 Nov 2006 15:18:37 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAEKIH917973; Tue, 14 Nov 2006 15:18:18 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Date: Tue, 14 Nov 2006 14:17:02 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFLzXUAAACTHlAAAAP/AAAEyi5wAADhBAA= From: "Haseeb Akhtar" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2004559463==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============2004559463== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70829.D89BB77B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70829.D89BB77B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YES. =20 Regards, =20 Haseeb=20 ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 12:44 PM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 =09 =09 Cheers, Gopal and Raj ------_=_NextPart_001_01C70829.D89BB77B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
YES.
 
Regards,
 
Haseeb 

From: Gopal Dommety (gdommety)=20 [mailto:gdommety@cisco.com]
Sent: Saturday, November = 11, 2006=20 12:44 PM
To: mip6@ietf.org
Subject: [Mip6] = Should we=20 add the requirements that arise from RFC 4285 in the=20 draft-ietf-mip6-aaa-ha-goals-03?

Hello=20 All,
 
    Wanted to get the = MIP6 Working=20 groups preference on whether we should we add the = requirements that arise from RFC 4285 in = the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We would like=20 to hear the Working Groups opinion of the following=20 question:
 
Should we add the=20 requirements that arise from RFC 4285 in the =20 = draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please answer=20 "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people = for=20 "yes" and 5 for "No".
 
Cheers,
Gopal and=20 = Raj
=00 ------_=_NextPart_001_01C70829.D89BB77B-- --===============2004559463== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2004559463==-- From mip6-bounces@ietf.org Tue Nov 14 15:19:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4kB-0005qB-Se; Tue, 14 Nov 2006 15:18:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4kA-0005q0-SI for mip6@ietf.org; Tue, 14 Nov 2006 15:18:54 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4k9-0005XT-GR for mip6@ietf.org; Tue, 14 Nov 2006 15:18:54 -0500 Received: from [10.1.210.8] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 12:18:52 -0800 Message-ID: <455A24A9.9060000@azairenet.com> Date: Tue, 14 Nov 2006 12:18:49 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? References: <2979E38DD6FC6544B789C8DAD7BAFC5202DFB8A3@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5202DFB8A3@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 20:18:52.0072 (UTC) FILETIME=[19F89A80:01C7082A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Gopal Dommety \(gdommety\)" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org instead of assuming things, it would be good to figure out what exactly we want to add to draft-ietf-mip6-aaa-ha-goals. :) Gopal? Vijay Kent Leung (kleung) wrote: > My vote is YES. > > I assume this question is intended for HA-AAA interface support for RFC > 4285. But it would be definitely nice to have standards-based AAA > attributes for bootstrapping in terms of completeness. > > Kent > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, November 14, 2006 10:26 AM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > Gopal, > > lets step back a bit. what is the point of adding of 4285-specific > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used for MN > authentication? or does it include bootstrapping for 4285 too? > > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > one place with no binding to develop any solutions yet? > > other bootstrapping related questions, do we want to standardize > bootstrapping solutions for 4285 too? has the DIME WG agreed to > developing solutions for 4285-based MIP6 operation? > > Vijay > > Gopal Dommety (gdommety) wrote: >> Hello All, >> >> Wanted to get the MIP6 Working groups preference on whether we >> should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03 >> >> We would like to hear the Working Groups opinion of the following > question: >> >> Should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03? >> >> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there >> were >> 14 people for "yes" and 5 for "No". >> >> Cheers, >> Gopal and Raj >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 14 15:38:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk523-0004AZ-IH; Tue, 14 Nov 2006 15:37:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk521-00046A-CD for mip6@ietf.org; Tue, 14 Nov 2006 15:37:21 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4zN-0007Yq-76 for mip6@ietf.org; Tue, 14 Nov 2006 15:34:39 -0500 Received: from zrc2hxm2.corp.nortel.com (zrc2hxm2.corp.nortel.com [47.103.123.73]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAEKYJ922744; Tue, 14 Nov 2006 15:34:19 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Tue, 14 Nov 2006 14:34:08 -0600 Message-ID: <62B9B0847CC47543B6B3B5E26BD268E60B5F679B@zrc2hxm2.corp.nortel.com> In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F678C@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwC8eS6AACan40AAP2pHUAAAJ3igAC/ng6A= From: "Mohamed Khalil" To: "Mohamed Khalil" , X-Spam-Score: 0.6 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Cc: gdommety@cisco.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0463408692==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0463408692== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7082C.3C4F7EFD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7082C.3C4F7EFD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable clarification is for the HA-AAA interface support for RFC 4285. -----Original Message----- From: Khalil, Mohamed (RICH2:2S20)=20 Sent: Monday, November 13, 2006 3:43 PM To: mip6@ietf.org Cc: gdommety@cisco.com Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? =09 =09 I support. ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 10:44 AM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 =09 =09 Cheers, Gopal and Raj ------_=_NextPart_001_01C7082C.3C4F7EFD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
clarification is for the HA-AAA interface = support for RFC=20 4285.
-----Original Message-----
From: = Khalil, Mohamed=20 (RICH2:2S20)
Sent: Monday, November 13, 2006 3:43 = PM
To:=20 mip6@ietf.org
Cc: gdommety@cisco.com
Subject: RE: = [Mip6]=20 Should we add the requirements that arise from RFC 4285 inthe=20 draft-ietf-mip6-aaa-ha-goals-03?

I=20 support.

From: Gopal Dommety (gdommety)=20 [mailto:gdommety@cisco.com]
Sent: Saturday, November 11, = 2006=20 10:44 AM
To: mip6@ietf.org
Subject: [Mip6] = Should we add=20 the requirements that arise from RFC 4285 inthe=20 draft-ietf-mip6-aaa-ha-goals-03?

Hello=20 All,
 
    Wanted to get the = MIP6=20 Working groups preference on whether we should we add the = requirements that arise = from RFC=20 4285 in the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We would=20 like to hear the Working Groups opinion of the following=20 question:
 
Should we add the=20 requirements that arise from RFC 4285 in the =20 = draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please=20 answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were = 14=20 people for "yes" and 5 for=20 "No".
 
Cheers,
Gopal and=20 = Raj
=00 ------_=_NextPart_001_01C7082C.3C4F7EFD-- --===============0463408692== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0463408692==-- From mip6-bounces@ietf.org Tue Nov 14 18:07:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7MQ-0000fO-DD; Tue, 14 Nov 2006 18:06:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7MP-0000ez-1K for mip6@ietf.org; Tue, 14 Nov 2006 18:06:33 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7MM-0008U0-N2 for mip6@ietf.org; Tue, 14 Nov 2006 18:06:33 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8Q003JITIR0F@usaga01-in.huawei.com> for mip6@ietf.org; Tue, 14 Nov 2006 15:06:27 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8Q00J41TIM1U@usaga01-in.huawei.com> for mip6@ietf.org; Tue, 14 Nov 2006 15:06:27 -0800 (PST) Date: Tue, 14 Nov 2006 15:06:24 -0800 From: Madjid Nakhjiri Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: <2309978910A6A6478C2C7585692B0AF405A23D@NAEX16.na.qualcomm.com> To: "'Tsirtsis, George'" , "'Gopal Dommety (gdommety)'" , mip6@ietf.org Message-id: <000f01c70841$81fbae80$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAAAuBu8A= X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I second George on this. Should we not find out what these requirements = are before doing a yes/no vote. In the absence of clear requirements, I will = say no. Which one of you buys a car without seeing it?? Madjid -----Original Message----- From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 Sent: Tuesday, November 14, 2006 9:40 AM To: Gopal Dommety (gdommety); mip6@ietf.org Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Gopal, I am not sure I understand the question. RFC4285 defines a mechanism/solution and an associated applicability statement. What is it that you propose to "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what form? I would also appreciate if people voting "yes" or "no" on this (or any) issue, say something about why they vote one way or the other. Regards George ________________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 1:44 PM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Hello All, =A0 =A0=A0=A0 Wanted to get the MIP6 Working groups preference on whether we = should we add the requirements that arise from RFC 4285 in the =A0 draft-ietf-mip6-aaa-ha-goals-03 =A0 We would like to hear the Working Groups opinion of the following = question: =A0 Should we add the requirements that arise from RFC 4285 in the=A0 draft-ietf-mip6-aaa-ha-goals-03? =A0 =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there = were 14 people for "yes" and 5 for "No". =A0 Cheers, Gopal and Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 14 18:11:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7Qg-0002JE-TX; Tue, 14 Nov 2006 18:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7Qg-0002J6-80 for mip6@ietf.org; Tue, 14 Nov 2006 18:10:58 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7Qd-0000mD-TB for mip6@ietf.org; Tue, 14 Nov 2006 18:10:58 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8Q0033BTQ70F@usaga01-in.huawei.com> for mip6@ietf.org; Tue, 14 Nov 2006 15:10:55 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8Q00JHDTQ21U@usaga01-in.huawei.com> for mip6@ietf.org; Tue, 14 Nov 2006 15:10:55 -0800 (PST) Date: Tue, 14 Nov 2006 15:10:52 -0800 From: Madjid Nakhjiri Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: <2979E38DD6FC6544B789C8DAD7BAFC5202DFB8A3@xmb-sjc-235.amer.cisco.com> To: "'Kent Leung (kleung)'" , 'Vijay Devarapalli' , "'Gopal Dommety (gdommety)'" Message-id: <001001c70842$21da8020$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccIHFSSBlUgJtl+SoWX2OC6YWqsAwADB4JAAAZYETA= X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Personally, I suspect that 4285 support simply needs a bunch of attributes. I suggest people propose a couple of requirements related to 4285 support and after that we could easily see if those can be added to the current set of goals. Once we did that we can simply say the HA-AAAH support 4285. Madjid -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: Tuesday, November 14, 2006 12:08 PM To: Vijay Devarapalli; Gopal Dommety (gdommety) Cc: mip6@ietf.org Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? My vote is YES. I assume this question is intended for HA-AAA interface support for RFC 4285. But it would be definitely nice to have standards-based AAA attributes for bootstrapping in terms of completeness. Kent -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] Sent: Tuesday, November 14, 2006 10:26 AM To: Gopal Dommety (gdommety) Cc: mip6@ietf.org Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? Gopal, lets step back a bit. what is the point of adding of 4285-specific requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic 4285 operation where the HA-AAAH interface is used for MN authentication? or does it include bootstrapping for 4285 too? will the requirements be added to draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in one place with no binding to develop any solutions yet? other bootstrapping related questions, do we want to standardize bootstrapping solutions for 4285 too? has the DIME WG agreed to developing solutions for 4285-based MIP6 operation? Vijay Gopal Dommety (gdommety) wrote: > Hello All, > > Wanted to get the MIP6 Working groups preference on whether we > should we add the requirements that arise from RFC 4285 in the > draft-ietf-mip6-aaa-ha-goals-03 > > We would like to hear the Working Groups opinion of the following question: > > Should we add the requirements that arise from RFC 4285 in the > draft-ietf-mip6-aaa-ha-goals-03? > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > were > 14 people for "yes" and 5 for "No". > > Cheers, > Gopal and Raj > > > ---------------------------------------------------------------------- > -- > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 14 18:11:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7Re-0002WG-Ol; Tue, 14 Nov 2006 18:11:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7Rd-0002W9-G9 for mip6@ietf.org; Tue, 14 Nov 2006 18:11:57 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7Rb-0000x6-2F for mip6@ietf.org; Tue, 14 Nov 2006 18:11:57 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAENBbuA026452; Wed, 15 Nov 2006 01:11:49 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 01:11:09 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 17:11:04 -0600 Received: from 10.241.59.212 ([10.241.59.212]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Nov 2006 23:10:54 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Tue, 14 Nov 2006 17:11:07 -0600 From: Basavaraj Patil To: Message-ID: Thread-Topic: Design team for working on MIP6 firewall solution Thread-Index: AccIQioRaGPcFHQ1EdugbgARJNUNiA== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 23:11:05.0193 (UTC) FILETIME=[28FDBD90:01C70842] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [Mip6] Design team for working on MIP6 firewall solution X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hello, One of the MIP6 charter items is : " - Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. " And a milestone of: " Apr 2007 Submit I-D 'Mobile IPv6 Operation with Firewalls' to IESG for publication as Informational." At IETF67 the design approaches were discussed at the WG meeting. We agreed to form a design team to consider various approaches. Hannes Tschofenig ( Hannes.Tschofenig@gmx.net ) has agreed to lead this DT. If you are interested in working on this design team, please contact Hannes. -Raj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 14 18:13:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7TJ-0002vM-VN; Tue, 14 Nov 2006 18:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7TH-0002uY-Ru for mip6@ietf.org; Tue, 14 Nov 2006 18:13:39 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7TG-0001H6-CD for mip6@ietf.org; Tue, 14 Nov 2006 18:13:39 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8Q003HATUP0F@usaga01-in.huawei.com> for mip6@ietf.org; Tue, 14 Nov 2006 15:13:38 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8Q00JSJTUL1U@usaga01-in.huawei.com> for mip6@ietf.org; Tue, 14 Nov 2006 15:13:37 -0800 (PST) Date: Tue, 14 Nov 2006 15:13:34 -0800 From: Madjid Nakhjiri Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: To: "'Gopal Dommety (gdommety)'" , mip6@ietf.org Message-id: <001401c70842$829253c0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Thread-index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwC8eS6AAJu2ESA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1116060720==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1116060720== Content-type: multipart/alternative; boundary="Boundary_(ID_P+IHKBn2JsIanjQoijVdyg)" This is a multi-part message in MIME format. --Boundary_(ID_P+IHKBn2JsIanjQoijVdyg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT I disagree with this. I don't really think there are "issues" with 4285. I just want the group to go through the exercise of defining the related requirements (which I think would be only support for related attributes) and then make the decision based on those explicit requirements. Madjid _____ From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] Sent: Saturday, November 11, 2006 1:04 PM To: Gopal Dommety (gdommety); mip6@ietf.org Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Even though draft-ietf-mip6-aaa-ha-goals-03 is slated to only becoming an informational RFC, I suppose we will looking for a PS document that really provides the AAA solution based on these goals. Having said that, it would be a problem to have a normative reference to RFC4285 in those AAA solution documents anyway. Aside from that, I vote "no" at the moment. There are many issues with RFC4285 and I'm not really sure we want to go down the path of fixing those. And, without fixing those, it doesn't quite make sense to do more work based on that. Vidya _____ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] Sent: Saturday, November 11, 2006 10:44 AM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Hello All, Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 We would like to hear the Working Groups opinion of the following question: Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". Cheers, Gopal and Raj --Boundary_(ID_P+IHKBn2JsIanjQoijVdyg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

I disagree with this. I don’t really think there are “issues” with 4285. I just want the group to go through the exercise of defining the related requirements (which I think would be only support for related attributes) and then make the decision based on those explicit requirements.

 

Madjid

 


From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]
Sent: Saturday, November 11, 2006 1:04 PM
To: Gopal Dommety (gdommety); mip6@ietf.org
Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03?

 

Even though draft-ietf-mip6-aaa-ha-goals-03 is slated to only becoming an informational RFC, I suppose we will looking for a PS document that really provides the AAA solution based on these goals. Having said that, it would be a problem to have a normative reference to RFC4285 in those AAA solution documents anyway.  

 

Aside from that, I vote "no" at the moment. There are many issues with RFC4285 and I'm not really sure we want to go down the path of fixing those. And, without fixing those, it doesn't quite make sense to do more work based on that.

 

Vidya

 


From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]
Sent: Saturday, November 11, 2006 10:44 AM
To: mip6@ietf.org
Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03?

Hello All,

 

    Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the   draft-ietf-mip6-aaa-ha-goals-03

 

We would like to hear the Working Groups opinion of the following question:

 

Should we add the requirements that arise from RFC 4285 in the  draft-ietf-mip6-aaa-ha-goals-03?

 

 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No".

 

Cheers,

Gopal and Raj

--Boundary_(ID_P+IHKBn2JsIanjQoijVdyg)-- --===============1116060720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1116060720==-- From mip6-bounces@ietf.org Tue Nov 14 18:30:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7jq-0001q5-Qj; Tue, 14 Nov 2006 18:30:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk7jp-0001ox-K3 for mip6@ietf.org; Tue, 14 Nov 2006 18:30:45 -0500 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk7jn-000499-VE for mip6@ietf.org; Tue, 14 Nov 2006 18:30:45 -0500 Received: by ug-out-1314.google.com with SMTP id 72so1299095ugd for ; Tue, 14 Nov 2006 15:30:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FjbxBXVabymGqz/FkFXgwbH3e5Pcx/ZDDuOX+0y2sJfMhKJ+3iQRl+jacis3ECRnDWqzOYBcU2H39B29XtA/e+ypEcW3WThPTZVDpwPEJa7Lil3sxN2oFyEVgL6l/Fm7Jbn+qDnCWLGzbpGLJYbcGNmyBBvkMcUKb1Na4MWnClA= Received: by 10.67.117.2 with SMTP id u2mr1700066ugm.1163547042359; Tue, 14 Nov 2006 15:30:42 -0800 (PST) Received: by 10.66.243.16 with HTTP; Tue, 14 Nov 2006 15:30:42 -0800 (PST) Message-ID: Date: Tue, 14 Nov 2006 18:30:42 -0500 From: "Gerardo Giaretta" To: "Madjid Nakhjiri" Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-Reply-To: <001001c70842$21da8020$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2979E38DD6FC6544B789C8DAD7BAFC5202DFB8A3@xmb-sjc-235.amer.cisco.com> <001001c70842$21da8020$2f01a8c0@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: "Gopal Dommety \(gdommety\)" , mip6@ietf.org, "Kent Leung \(kleung\)" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Current work in DIME WG is based on rfc3775/3776 and on the IPsec bootstrapping solution. This has lead so far to a re-use of rfc4072 for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR re-use for the session management. This means that in case rfc4285 is used, the Diameter application we are designing cannot be used. The session management and authorization part can be kept the same, but there would be a need to specify how the HA authenticates the BUs in case of dynamic keying (something similar to MIP4 approach). So the question is: should the AAA requirements doc (and consequently the DIME solution - but this is a question for DIME WG) list also that the HA-AAA communication may be able to bootstrap and authenticate rfc4285 security associations? I hope this clarifies. --Gerardo On 11/14/06, Madjid Nakhjiri wrote: > Personally, I suspect that 4285 support simply needs a bunch of attributes. > I suggest people propose a couple of requirements related to 4285 support > and after that we could easily see if those can be added to the current set > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > Madjid > > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, November 14, 2006 12:08 PM > To: Vijay Devarapalli; Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > My vote is YES. > > I assume this question is intended for HA-AAA interface support for RFC > 4285. But it would be definitely nice to have standards-based AAA > attributes for bootstrapping in terms of completeness. > > Kent > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, November 14, 2006 10:26 AM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > Gopal, > > lets step back a bit. what is the point of adding of 4285-specific > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used for MN > authentication? or does it include bootstrapping for 4285 too? > > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > one place with no binding to develop any solutions yet? > > other bootstrapping related questions, do we want to standardize > bootstrapping solutions for 4285 too? has the DIME WG agreed to > developing solutions for 4285-based MIP6 operation? > > Vijay > > Gopal Dommety (gdommety) wrote: > > Hello All, > > > > Wanted to get the MIP6 Working groups preference on whether we > > should we add the requirements that arise from RFC 4285 in the > > draft-ietf-mip6-aaa-ha-goals-03 > > > > We would like to hear the Working Groups opinion of the following > question: > > > > Should we add the requirements that arise from RFC 4285 in the > > draft-ietf-mip6-aaa-ha-goals-03? > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > were > > 14 people for "yes" and 5 for "No". > > > > Cheers, > > Gopal and Raj > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 06:25:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkIrV-00041f-Sd; Wed, 15 Nov 2006 06:23:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkIrV-0003wv-2C for mip6@ietf.org; Wed, 15 Nov 2006 06:23:25 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkIkY-0007yO-3J for mip6@ietf.org; Wed, 15 Nov 2006 06:16:15 -0500 X-VirusChecked: Checked X-Env-Sender: vishnu@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1163589278!1863283!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 27193 invoked from network); 15 Nov 2006 11:14:38 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with SMTP; 15 Nov 2006 11:14:38 -0000 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kAFBEbTG013369 for ; Wed, 15 Nov 2006 04:14:37 -0700 (MST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id kAFBEaFs018955 for ; Wed, 15 Nov 2006 05:14:37 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Wed, 15 Nov 2006 19:14:33 +0800 Message-ID: In-Reply-To: <28CEA477BE98ED48AF08A0B637A74BF402954CE6@xmb-sjc-224.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? thread-index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFxX/Bw From: "Ram O V Vishnu-A14676" To: "Gopal Dommety \(gdommety\)" , X-Spam-Score: 0.2 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0011498936==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============0011498936== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C708A7.3A4A271C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C708A7.3A4A271C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 yes. Regards, Vishnu. Motorola +91 9844178052 [*] General [] Motorola Internal Use Only -----Original Message----- From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Sunday, November 12, 2006 12:14 AM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 =09 =09 Cheers, Gopal and Raj ------_=_NextPart_001_01C708A7.3A4A271C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
yes.

Regards,
Vishnu.

Motorola
+91 = 9844178052
[*]=20 General
[] Motorola Internal Use Only

-----Original Message-----
From: = Gopal Dommety=20 (gdommety) [mailto:gdommety@cisco.com]
Sent: Sunday, = November 12,=20 2006 12:14 AM
To: mip6@ietf.org
Subject: [Mip6] = Should we=20 add the requirements that arise from RFC 4285 inthe=20 draft-ietf-mip6-aaa-ha-goals-03?

Hello=20 All,
 
    Wanted to get the MIP6 = Working=20 groups preference on whether we should we add the = requirements that arise from RFC 4285 in = the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We = would like to=20 hear the Working Groups opinion of the following = question:
 
Should we = add the=20 requirements that arise from RFC 4285 in the =20 = draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please answer=20 "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for = "yes"=20 and 5 for "No".
 
Cheers,
Gopal and=20 Raj
------_=_NextPart_001_01C708A7.3A4A271C-- --===============0011498936== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0011498936==-- From mip6-bounces@ietf.org Wed Nov 15 15:17:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRBZ-0007Bj-Fp; Wed, 15 Nov 2006 15:16:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRBY-0007BV-7S for mip6@ietf.org; Wed, 15 Nov 2006 15:16:40 -0500 Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRBU-0004y5-P7 for mip6@ietf.org; Wed, 15 Nov 2006 15:16:38 -0500 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id D381E38170; Wed, 15 Nov 2006 21:16:28 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id BC8BE37E48 for ; Wed, 15 Nov 2006 21:16:28 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id A7C9837E81 for ; Wed, 15 Nov 2006 21:16:28 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkRBK-0002Ul-JN for mip6@ietf.org; Wed, 15 Nov 2006 21:16:27 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 20:16:26 +0000 MIME-Version: 1.0 Message-Id: <1163621786.44.0.274376954002.issue79@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [Mip6] [issue79] Review by Lisa Dusseault X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : Comment: This document lacks many important references and definitions for an outsid= er to be able to figure out=20 what's going on. =20 - No reference for understanding where "Care of address" comes from -- thi= s is most devastating as=20 there is no reference or explanation to understand who gets the Care of add= ress in the course of MIP6=20 operation - In poking around, I found that draft-haddad-alien-privacy-terminology-01= .txt has a much better=20 definition for "location privacy" - MN is not expanded on first use or defined, I have to assume MN=3DMobile= Node - HoA never defined -- is this same as HA which I assume is Home Address - CN never defined -- hunting through the informative reference to draft-h= addad-momipriv-problem- statement-03.txt (also not helpfully named) I guess this is Correspondent N= ode? - ESP never defined - SIP never defined or referenced - Neither reference explains bidirectional tunneling, or reverse tunneling= (are these the same???) - All these terms and acronyms seem to be very inconsistently used Most fundamentally, the Conclusion -- that disclosing Care of address to a = correspondent and=20 disclosing Home address to an onlooker can compromise location privacy -- i= s not supported by this=20 document or its references. It's probably a reasonable statement if the WG= has reviewed the document,=20 but even if so, it's poorly explained and based on much material that's not= here even in reference form. ---------- category: Editorial draft: draft-ietf-mip6-location-privacy-ps messages: 267 nosy: admin priority: Should fix status: Pending title: Review by Lisa Dusseault _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 15:18:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRDJ-0007gS-Cp; Wed, 15 Nov 2006 15:18:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRDH-0007fI-W3 for mip6@ietf.org; Wed, 15 Nov 2006 15:18:27 -0500 Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRDF-0005RS-KS for mip6@ietf.org; Wed, 15 Nov 2006 15:18:27 -0500 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id 359CF38116; Wed, 15 Nov 2006 21:18:25 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id 1FAF837F41 for ; Wed, 15 Nov 2006 21:18:25 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 087AF37E4C for ; Wed, 15 Nov 2006 21:18:25 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkRDD-0005xc-VW for mip6@ietf.org; Wed, 15 Nov 2006 21:18:24 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 20:18:17 +0000 MIME-Version: 1.0 Message-Id: <1163621897.59.0.547679939062.issue80@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Mip6] [issue80] Review by Dan Romascanu X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : Comment: 'When the MN roams to another network, the location privacy problem consists of two parts: revealing information to its correspondents and to on-lookers.' I am wondering if this definition of the problem is not incomplete. I am mi= ssing any reference to the threat=20 of exposure of the location information via management interfaces. The edit= ors may consider adding=20 some clarification text mentioning the fact that adequate protection means = should be implemented to=20 avoid the exposure of the location information obtained by authorized corre= spondents or visited networks=20 ebtities via management interfaces or protocols. ---------- category: Editorial draft: draft-ietf-mip6-location-privacy-ps messages: 268 nosy: admin priority: Should fix status: Pending title: Review by Dan Romascanu _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 15:19:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRE9-0008Mw-T5; Wed, 15 Nov 2006 15:19:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRE8-0008L4-9f for mip6@ietf.org; Wed, 15 Nov 2006 15:19:20 -0500 Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRE4-0005bS-O1 for mip6@ietf.org; Wed, 15 Nov 2006 15:19:20 -0500 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id 5596F380F7; Wed, 15 Nov 2006 21:19:16 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3DFDC37E48 for ; Wed, 15 Nov 2006 21:19:16 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3106A37E80 for ; Wed, 15 Nov 2006 21:19:16 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkRE3-0007gZ-7R for mip6@ietf.org; Wed, 15 Nov 2006 21:19:16 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 20:19:15 +0000 MIME-Version: 1.0 Message-Id: <1163621955.08.0.113933878088.issue81@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Mip6] [issue81] Comment by Russ Housley X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : Comment: From the SecDir Review by Lakshminath Dondeti: > > The security considerations section is pretty light. It says in part=20 > that "solutions to provide location privacy ... must be secure=20 > ...." Even though this is a problem statement document, perhaps it=20 > is the place to explain the security criteria used in evaluating=20 > candidate solutions. For instance, the two types of solutions I can=20 > think of are 1) providing confidentiality of addresses by encrypting=20 > them and 2) making use of temporary addresses. There are=20 > implications to using either type of solution. > > Perhaps there are other ways to list the criteria too. ---------- category: Editorial draft: draft-ietf-mip6-location-privacy-ps messages: 269 nosy: admin priority: Should fix status: Pending title: Comment by Russ Housley _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 15:20:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkREw-00009Q-KH; Wed, 15 Nov 2006 15:20:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkREv-00009C-FM for mip6@ietf.org; Wed, 15 Nov 2006 15:20:09 -0500 Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkREt-0005lB-1e for mip6@ietf.org; Wed, 15 Nov 2006 15:20:09 -0500 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id A59DE37E52; Wed, 15 Nov 2006 21:20:06 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8EBA037E50 for ; Wed, 15 Nov 2006 21:20:06 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 7E41D37E5C for ; Wed, 15 Nov 2006 21:20:06 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkREo-0000sf-Bv for mip6@ietf.org; Wed, 15 Nov 2006 21:20:03 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 20:20:02 +0000 MIME-Version: 1.0 Message-Id: <1163622002.18.0.329783414839.issue82@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 1.2 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Mip6] [issue82] Secdir review of draft-mip6-location-privacy-ps-04 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : I have no major issues with this document. It appears that there are=20 editorial issues, ones that idnits complains about and some that the=20 RFC Ed might eventually catch. The notion of "location" is a bit fuzzy in the abstract and in the=20 beginning of the document. It is later clear that the context is IP=20 address location privacy with geographic information deduced perhaps=20 from mapping IP addresses to approximate geo-locations. Perhaps this=20 can be made clear in the abstract and in the Introduction. The security considerations section is pretty light. It says in part=20 that "solutions to provide location privacy ... must be secure=20 .=2E.." Even though this is a problem statement document, perhaps it=20 is the place to explain the security criteria used in evaluating=20 candidate solutions. For instance, the two types of solutions I can=20 think of are 1) providing confidentiality of addresses by encrypting=20 them and 2) making use of temporary addresses. There are=20 implications to using either type of solution. Perhaps there are other ways to list the criteria too. Hope that helps. best regards, Lakshminath ---------- category: Editorial draft: draft-ietf-mip6-location-privacy-ps messages: 270 nosy: admin priority: Should fix status: Pending title: Secdir review of draft-mip6-location-privacy-ps-04 _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 15:26:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRLK-0002qP-Fy; Wed, 15 Nov 2006 15:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRLJ-0002qJ-Il for mip6@ietf.org; Wed, 15 Nov 2006 15:26:45 -0500 Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRLI-0006pm-4d for mip6@ietf.org; Wed, 15 Nov 2006 15:26:45 -0500 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 45AF437F02; Wed, 15 Nov 2006 21:26:28 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 2DE5237E55 for ; Wed, 15 Nov 2006 21:26:28 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id CDC7037E71 for ; Wed, 15 Nov 2006 21:26:42 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkRLE-0007bu-IR for mip6@ietf.org; Wed, 15 Nov 2006 21:26:42 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 20:26:39 +0000 MIME-Version: 1.0 Message-Id: <1163622399.02.0.110079057476.issue83@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Mip6] [issue83] secdir review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : This is a security directorate review of draft-ietf-mip6-ikev2-ipsec-07.txt. Were I still an AD, I'd DEFER it, since to evaluate it properly I'd need to reread 3775 and 3776, and I don't have time to go through 200 pages more right now... One obvious problem: Section 4.1 notes that 3775 requires support for manual key management, and lists IKE support as a "MAY". However, 4107 -- a BCP which came out after 3775 -- establishes a strong presumption that automated key management automated key management be used. Accordingly, this draft should mandate support for IKEv2, as it does not appear to fall under any of the exceptions. 4=2E3 says that anti-replay is optional. However, Section 1 of 3776 says that anti-replay is required, though it notes that it can't be done properly without IKE. Assuming that IKEv2 is mandated here, anti-replay should be as well. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ---------- category: Editorial draft: draft-ietf-mip6-ikev2-ipsec messages: 271 nosy: admin priority: Should fix status: Pending title: secdir review of draft-ietf-mip6-ikev2-ipsec-07.txt _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 15:28:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRMc-0003EN-Fj; Wed, 15 Nov 2006 15:28:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRMa-0003E8-ST for mip6@ietf.org; Wed, 15 Nov 2006 15:28:04 -0500 Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRMZ-00070t-52 for mip6@ietf.org; Wed, 15 Nov 2006 15:28:04 -0500 Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id B5C7637EC2; Wed, 15 Nov 2006 21:28:02 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 9EE3137E51 for ; Wed, 15 Nov 2006 21:28:02 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8055837E61 for ; Wed, 15 Nov 2006 21:28:02 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkRMV-0007cP-OH for mip6@ietf.org; Wed, 15 Nov 2006 21:28:02 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 20:27:59 +0000 MIME-Version: 1.0 Message-Id: <1163622479.63.0.761185983475.issue84@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Mip6] [issue84] Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : I am the assigned Gen-ART reviewer for draft-ietf-mip6-ikev2-ipsec-07.txt For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mip6-ikev2-ipsec-07.txt Title: Mobile IPv6 Operation with IKEv2 and the revised IPSec Architecture Review Date: Nov. 14, 2006 IESG Telechat date: Nov. 16, 2006 Summary: This draft is ready for publication as a Proposed Standard RFC. The draft describes Mobile IPv6 operations with respect to the revised IPSec architecture [RFC4301] and IKEv2 [RFC4306]. These revisions contain enough changes in them to warrant an update to RFC3776, the RFC that this document updates. Some nits and additional feedback follows: 1) In S4, the authors state that "Many of the requirements are repeated from RFC3776 to make this document self-contained and complete." There are a fair number of requirements in subsequent sub-sections. It may help if the authors tag each requirement that was already present in RFC3776, so the reader can see which new requirement was generated by this draft. 2) Nit: S6.1, under heading "mobile node SPD-S:" s/=3DBU/=3D BU/ 3) In S9, first full paragraph of Page 22: "In case the home agent ... an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an INTERNAL_ADDRESS_FAILURE message, does it make sense to specify what should it do, if anything? Thanks, - vijay --=20 Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) ---------- category: Editorial draft: draft-ietf-mip6-ikev2-ipsec messages: 272 nosy: admin priority: Should fix status: Pending title: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 15:29:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRNr-0003vT-CR; Wed, 15 Nov 2006 15:29:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRNq-0003vN-9l for mip6@ietf.org; Wed, 15 Nov 2006 15:29:22 -0500 Received: from av8-1-sn3.vrr.skanova.net ([81.228.9.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRNn-00079I-Vg for mip6@ietf.org; Wed, 15 Nov 2006 15:29:22 -0500 Received: by av8-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 7CC7A38179; Wed, 15 Nov 2006 21:29:19 +0100 (CET) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 5FA6D3806F for ; Wed, 15 Nov 2006 21:29:19 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 52AB537E61 for ; Wed, 15 Nov 2006 21:29:19 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkRNk-0007cr-Mr for mip6@ietf.org; Wed, 15 Nov 2006 21:29:18 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 20:29:11 +0000 MIME-Version: 1.0 Message-Id: <1163622551.39.0.696265268451.issue85@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Mip6] [issue85] IANA review by Yoshiko Chong via RT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : IESG: The IANA has reviewed the following Internet-Draft which is in Last Call: draft-ietf-mip6-ikev2-ipsec-07.txt, and has the following comments/questions with regards to the publication of this document: As described in the IANA Considerations section, we understand this=20 document to have NO IANA Actions. Thank you. Yoshiko Chong (on behalf of IANA) ---------- category: Editorial draft: draft-ietf-mip6-ikev2-ipsec messages: 273 nosy: admin priority: May fix status: Pending title: IANA review by Yoshiko Chong via RT _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 15:32:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRQS-0005R5-4T; Wed, 15 Nov 2006 15:32:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRQQ-0005Q3-3o for mip6@ietf.org; Wed, 15 Nov 2006 15:32:02 -0500 Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRQN-0007cR-7y for mip6@ietf.org; Wed, 15 Nov 2006 15:32:02 -0500 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 882683817B; Wed, 15 Nov 2006 21:31:58 +0100 (CET) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 6E78637E71 for ; Wed, 15 Nov 2006 21:31:58 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 32FBB37E81 for ; Wed, 15 Nov 2006 21:31:58 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkRQJ-0007lJ-In for mip6@ietf.org; Wed, 15 Nov 2006 21:31:57 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 20:31:54 +0000 MIME-Version: 1.0 Message-Id: <1163622714.2.0.0128146112791.issue86@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Subject: [Mip6] [issue86] Review by Tero Kivinen X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : > Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture > draft-ietf-mip6-ikev2-ipsec-07.txt .=2E. > 1. Introduction >=20 > RFC 3776 describes how IPsec, as described in RFC 2401 [11], is used > with Mobile IPv6 [2] to protect the signaling messages. It also > illustrates examples of Security Policy Database and Security > Association Database entries that can be used to protect Mobile IPv6 > signaling messages. >=20 > The IPsec architecture has been revised in RFC 4301 [5]. Among the > many changes, the list of selectors has been expanded to include the > Mobility Header message type. This has an impact on how security > policies and security associations are configured for protecting > mobility header messages. It becomes easier to differentiate between > the various Mobility Header messages based on the type value instead > of checking if a particular mobility header message is being sent on > a tunnel interface between the mobile node and the home agent, as it > was in RFC 3776. The revised IPsec architecture specification also > includes ICMP message type and code as selectors. This makes it > possible to protect Mobile Prefix Discovery messages without applying > the same security associations to all ICMPv6 messages. >=20 > This document discusses new requirements for the home agent and the > mobile node to use the revised IPsec architecture and IKEv2. > Section 4 lists the requirements. Section 6 and Section 7 describe > the required Security Policy Database (SPD) and Security Association > Database (SAD) entries. >=20 > The Internet Key Exchange (IKE) has also been substantially revised > and simplified [4]. Section 7.2 of this document describes how IKEv2 > can be used to setup security associations for Mobile IPv6. >=20 > The use of EAP within IKEv2 is allowed to authenticate the mobile > node to the home agent. This is described in Section 8. A method > for dynamically configuring a home address from the home agent using > the Configuration Payload in IKEv2 is described in Section 9. This should probably also talk about MOBIKE, as MOBIKE can offer some more building blocks for the MIP6 which will make it easier to use IKEv2 when addresses changes.=20 > 4. Requirements .=2E. > 4.4. Dynamic Keying Requirements .=2E > o If the home agent has used IKEv2 to establish security > associations with the mobile node, it should follow the procedures > discussed in Section 10.3.1 and 10.3.2 of the base specification > [2] to determine whether the IKE endpoints can be moved or if the > IKE SA has to be re-established. I do not know exactly what the RFC3775 specifies how to detect whether the SA can be moved or not, but if MOBIKE was supported by both ends when the IKEv2 SA was created, then SAs can always be updated with MOBIKE ADDRESS_UPDATE notify. > 7.1. Security Policy Database Entries .=2E. > In the examples shown below, the identity of the user of the mobile > node is assumed to be user_1, the home address of the mobile node is > assumed to be home_address_1, he primary care-of address of the ^^^ > mobile node is assumed to be care_of_address_1 and the IPv6 address > of the Home Agent is assumed to be home_agent_1. Typo. > 7.2. Security Association negotiation using IKEv2 .=2E. > When the mobile node uses its home address in the IDi field, > implementations are required to match the source address in the > outermost IP header with the IP address in the IDi field [8]. This > verification step, however, should be configurable [8]. With Mobile > IPv6, this verification step will always fail because the source > address in the IP header is the care-of address and the IP address in > the IDi field is the home address. Therefore, this verification step > MUST be disabled. Actually RFC 4306 section 3.1 says: Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. I=2Ee the outer IP addresses are not used to verify IDi/IDr fields. RFC4718 (IKEv2 Clarifications and Implementation Guidelines) says this explicitly in section 7.1: Furthermore, IKEv2 does not require that the addresses in ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the IKE packets. However, other specifications may place additional requirements regarding this. For example, [PKI4IPsec] requires that implementation must be capable of comparing the addresses in the ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the IKE packets, and this comparison must be enabled by default. So it would be enough here to say that you follow IKEv2 way of not matching the outer IP addresses with the ID payloads, and not follow the pki4ipsec profile about the IKEv1 (pki4ipsec is mostly for IKEv1 in any case). Also PKI4IPsec WG is now thinking whether they should say that section 3 of the draft-ietf-pki4ipsec-ikecert-profile-11.txt is only used for IKEv1 or for both IKEv1 and IKEv2. It would be better not to refer the pki4ipsec draft at all in this point, as it just adds confusion.=20 >=20 > 7.3. Movements and Dynamic Keying >=20 > If the mobile node moves and its care-of address changes, the IKEv2 > SA might not be valid. RFC 3775 defines a mechanism based on the > successful exchange of Binding Update and Binding Acknowledgement > messages. The mobile node establishes the IKE SA with the home agent > using its primary care-of address. The IKE SA endpoints are updated > on the home agent when it receives the Binding Update from the mobile > node's new care-of address and on the mobile node when it sends the > Binding Update to the home agent or when it receives the Binding > acknowledgement sent by the home agent. This capability to change > IKE endpoints is indicated through setting the Key Management > Capability (K) flag [2] in the Binding Update and Binding > Acknowledgement messages. If the mobile node or the home agent does > not support this capability, and has no other means to update the > addresses, then an IKEv2 exchange MUST be initiated to re-establish a > new IKE SA. Again MOBIKE should probably be mentioned here. > 8. The use of EAP authentication .=2E. > When EAP is used, the identity presented by the mobile node in the > IDi field may not be the actual identity of the mobile node. It > could be set to an identity that is used only for AAA routing > purposes and selecting the right EAP method. The actual identity is > carried inside EAP payloads that is not visible to the home agent. > The home agent MUST acquire the mobile node's identity from the > corresponding AAA server. More details can be found in [13]. Actually the rfc4718 does not mention anything about this. The RFC4306 says that the EAP Identity requests SHOULD NOT be sent (section 3.16): Note that since IKE passes an indication of initiator identity in message 3 of the protocol, the responder SHOULD NOT send EAP Identity requests. The initiator SHOULD, however, respond to such requests if it receives them. I=2Ee the EAP exchange does not include EAP Identity request and reply, as that information has already been passed inside the ID payloads of the IKE exchange, and those same IDs are used as EAP identities when talking to the AAA server. So the actual identity is visible to the home agent as it is sent inside the ID payload.=20 > 9. Dynamic Home Address Configuration .=2E. > When the home agent receives a configuration payload with a > CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home > address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in > the CFG_REPLY contains the prefix length of the home prefix in > addition to a 128 bit home address. The home agent could use a local > database or contact a DHCPv6 server on the home link to allocate a > home address. The Home Agent should also include an > INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the > duration for which the dynamically allocated home address is valid. RFC4718 says: ---------------------------------------------------------------------- 6=2E7. INTERNAL_ADDRESS_EXPIRY Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as "Specifies the number of seconds that the host can use the internal IP address. The host MUST renew the IP address before this expiry time. Only one of these attributes MAY be present in the reply." Expiry times and explicit renewals are primarily useful in environments like DHCP, where the server cannot reliably know when the client has gone away. However, in IKEv2 this is known, and the gateway can simply free the address when the IKE_SA is deleted. Also, Section 4 says that supporting renewals is not mandatory. Given that this functionality is usually not needed, we recommend that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. (And since this attribute does not seem to make much sense for CFG_REQUESTs, clients should not send it either.) Note that according to Section 4, clients are required to understand INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation would use the value to limit the lifetime of the IKE_SA. ---------------------------------------------------------------------- So, I would suggest you do recommend NOT to use INTERNAL_ADDRESS_EXPIRY at all, and simply get the address lifetime from the lifetime of the IKEv2 SA, i.e. the server will keep on renewing (if needed, in most cases the IP addresses are allocated from the local pool, so there is no needs to do renewals) the IP address as long as client keeps the IKEv2 SA up, and in case the address for some reason cannot be renewed, or is changed, deletes the IKEv2 SA forcing the client to get new IP address. As we are talking about home address here, there should not really be any problems with the address changing or not being able to renew it. --=20 kivinen@safenet-inc.com ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 274 nosy: admin priority: Should fix status: Pending title: Review by Tero Kivinen _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 15:44:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRcT-0001YT-7g; Wed, 15 Nov 2006 15:44:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRcS-0001YN-2g for mip6@ietf.org; Wed, 15 Nov 2006 15:44:28 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRcQ-0001Dk-JC for mip6@ietf.org; Wed, 15 Nov 2006 15:44:28 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFKhxNe012929; Wed, 15 Nov 2006 22:44:22 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 22:44:19 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 14:44:15 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 20:44:14 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 14:44:29 -0600 Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? From: Basavaraj Patil To: "ext Tsirtsis, George" , Gopal Dommety , Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8= In-Reply-To: <2309978910A6A6478C2C7585692B0AF405A23D@NAEX16.na.qualcomm.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Nov 2006 20:44:15.0027 (UTC) FILETIME=[D022D830:01C708F6] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061115224423-2FE85BB0-74AE4E7F/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org George, Let me see if I can clarify the question to the WG w.r.t the aaa-ha-goals I-D: The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended to capture the AAA requirements for MIP6 deployment/operation. These requirements would be fed to the appropriate AAA WGs (DIME/Radext) for developing the actual solution= s or extensions. In some cases the MIP6 WG in conjunction with a AAA WG (such as Radext) can take up the work as illustrated by the I-D draft-ietf-mip6-radius but in others the DIME WG is working on the solution= s needed for MIP6. The current version of the goals/requirements I-D does not consider the cas= e when RFC4285 is used as the means for authenticating an MN to an HA. The AA= A requirements are based strictly on the use of IPsec between the MN and HA. The question to the WG was whether the AAA requirements/goals document should include the requirements that MIP6 operation with RFC4285 brings. Since the AAA goals document is intended to capture all the MIP6 AAA requirements and RFC4285 is a recognized mode of MIP6 operation, it makes sense to capture the additional requirements at this time. Is this clear now? -Raj On 11/14/06 11:40 AM, "ext Tsirtsis, George" wrote: > Gopal, >=20 > I am not sure I understand the question. RFC4285 defines a mechanism/solu= tion > and an associated applicability statement. What is it that you propose to > "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what form? >=20 > I would also appreciate if people voting "yes" or "no" on this (or any) i= ssue, > say something about why they vote one way or the other. >=20 > Regards > George > ________________________________________ > From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] > Sent: Saturday, November 11, 2006 1:44 PM > To: mip6@ietf.org > Subject: [Mip6] Should we add the requirements that arise from RFC 4285 i= nthe > draft-ietf-mip6-aaa-ha-goals-03? >=20 > Hello All, > =A0 > =A0=A0=A0 Wanted to get the MIP6 Working groups preference on whether we should= we > add the requirements that arise from RFC 4285 in the =A0 > draft-ietf-mip6-aaa-ha-goals-03 > =A0 > We would like to hear the Working Groups opinion of the following questio= n: > =A0 > Should we add the requirements that arise from RFC 4285 in the=A0 > draft-ietf-mip6-aaa-ha-goals-03? > =A0 > =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 1= 4 > people for "yes" and 5 for "No". > =A0 > Cheers, > Gopal and Raj >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:10:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkS1W-0007Qb-VN; Wed, 15 Nov 2006 16:10:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkS1V-0007Pt-BI for mip6@ietf.org; Wed, 15 Nov 2006 16:10:21 -0500 Received: from av9-1-sn2.hy.skanova.net ([81.228.8.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkS1G-0006Wa-7X for mip6@ietf.org; Wed, 15 Nov 2006 16:10:21 -0500 Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id AEB5838009; Wed, 15 Nov 2006 22:10:05 +0100 (CET) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id 975AD37E50 for ; Wed, 15 Nov 2006 22:10:05 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 7E06637E83 for ; Wed, 15 Nov 2006 22:10:05 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GkS1A-0001Aw-BK for mip6@ietf.org; Wed, 15 Nov 2006 22:10:05 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: admin Date: Wed, 15 Nov 2006 21:09:58 +0000 MIME-Version: 1.0 Message-Id: <1163624998.68.0.034124653954.issue87@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 1.2 (+) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Mip6] [issue87] Comment by Sam Hartman on I-D draft-ietf-mip6-location-privacy-ps X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from admin : Discuss: >Even when the binding between a user > identifier and the Home Address is unavailable, freely available > tools on the Internet can map the Home Address to the owner of the > Home Prefix, which can reveal that a user from a particular ISP > has roamed. =20 If the above is in scope, then the discussion of the problem is incomplete. Sending an esp packet from ISP B to one of ISP A's HAs really discloses as much information as the above paragraph implies. I think this draft does a bad job of explaining its scope and convincing me that the problem being solved is important to solve. For example why are IIDs out of scope? Why is the ESP corrilation I discuss above out of scope? If those attacks are out of scope, what real benefit remains to hiding roaming from onlookers? Finally, I do not understand what work is left to do in this space. This draft describes the problem and points out that encrypted tunnels and not using RO are a solution. What additional problems are being solved beyond that? What work is there for the IETF to do in this space? A problem statement should clearly articulate these points. Comment: I agree with Lisa that this document is unclear--not quite to the point of earning a discuss for lack of clarity--but unclear enough that if you haven't been reading mip6 documents for a while, you won't understand what is going on. It conflates profiling and location privacy, and describes more than supports its conclusions. ---------- category: Editorial draft: draft-ietf-mip6-location-privacy-ps messages: 275 nosy: admin priority: Should fix status: Pending title: Comment by Sam Hartman on I-D draft-ietf-mip6-location-privacy-ps _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:19:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSAC-0001Q7-BZ; Wed, 15 Nov 2006 16:19:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSAA-0001PS-V9; Wed, 15 Nov 2006 16:19:18 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSA6-0008D5-Ob; Wed, 15 Nov 2006 16:19:18 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8S002CBJ7ZHU@usaga01-in.huawei.com>; Wed, 15 Nov 2006 13:19:11 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8S002FOJ7T2B@usaga01-in.huawei.com>; Wed, 15 Nov 2006 13:19:11 -0800 (PST) Date: Wed, 15 Nov 2006 13:19:07 -0800 From: Madjid Nakhjiri Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: To: 'Gerardo Giaretta' Message-id: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AccIROjOnFtEd7gWRFmXGaLfZ/cAvgAswaVg X-Spam-Score: 0.6 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: "'Gopal Dommety \(gdommety\)'" , "'Kent Leung \(kleung\)'" , mip6@ietf.org, dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Gerardo, If you remember, the first time people asked this question, I said we should simply be careful about rubber stamping the Dime drafts as supporting 4285. Unless the HA-AAA goal doc includes specific requirements on supporting 4285, we should refrain from making the promise that Dime draft do too. If we design something based on a requirement that excludes support for 4285, then the solution has no obligation to support it either. I am going to reiterate all my points. 1) "AAA goal/requirement document" means requirements for both RADIUS and Diameter. Unless you want to change the name, we need to realize that this document can a) create requirements that RADIUS cannot meet and hence rule out RADIUS for MIP6 support (some of the current goals related to key transport fit that category) b) create requirement for all AAA functionality, i.e both requirements on AAA functionality within HA and on AAA protocol. This means if an HA works according to 4285, then the document needs to include requirement for supporting 4285 as well. Dime drafts can come and state whether they fulfill all requirements, including 4285 requirements. We already have two dime drafts for two different designs. Currently, the document seemed to be treated as "requirement for Dime bootstrapping drafts". Is that the intention? The answer seems to be yes from your email. So the HA-AAA goals is not a generic requirement goal for MIP6. The current HA-AAA goals document should specifically state that it is the requirements for Diameter EAP based solutions and not for 4285 to clear all the issues above. Personally I think support for 4285 is a lot simpler than people think, and might not require much more than some AVPs and look similar to 4004 for MIP4 support in case of CCOA, but I have not done a detail analysis. If that is true all 4285 needs in way of requirements is probably being allowed to have some new AVPs (or possibly same as those used in MIP4). The problem of excluding these from HA-AAA goal is that you may need a new Diameter MIP6 App ID for 4285, if the AVPs are brand new? Hope THIS clarifies some more :) Regards, Madjid -----Original Message----- From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] Sent: Tuesday, November 14, 2006 3:31 PM To: Madjid Nakhjiri Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); mip6@ietf.org Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Current work in DIME WG is based on rfc3775/3776 and on the IPsec bootstrapping solution. This has lead so far to a re-use of rfc4072 for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR re-use for the session management. This means that in case rfc4285 is used, the Diameter application we are designing cannot be used. The session management and authorization part can be kept the same, but there would be a need to specify how the HA authenticates the BUs in case of dynamic keying (something similar to MIP4 approach). So the question is: should the AAA requirements doc (and consequently the DIME solution - but this is a question for DIME WG) list also that the HA-AAA communication may be able to bootstrap and authenticate rfc4285 security associations? I hope this clarifies. --Gerardo On 11/14/06, Madjid Nakhjiri wrote: > Personally, I suspect that 4285 support simply needs a bunch of attributes. > I suggest people propose a couple of requirements related to 4285 support > and after that we could easily see if those can be added to the current set > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > Madjid > > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, November 14, 2006 12:08 PM > To: Vijay Devarapalli; Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > My vote is YES. > > I assume this question is intended for HA-AAA interface support for RFC > 4285. But it would be definitely nice to have standards-based AAA > attributes for bootstrapping in terms of completeness. > > Kent > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, November 14, 2006 10:26 AM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > Gopal, > > lets step back a bit. what is the point of adding of 4285-specific > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used for MN > authentication? or does it include bootstrapping for 4285 too? > > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > one place with no binding to develop any solutions yet? > > other bootstrapping related questions, do we want to standardize > bootstrapping solutions for 4285 too? has the DIME WG agreed to > developing solutions for 4285-based MIP6 operation? > > Vijay > > Gopal Dommety (gdommety) wrote: > > Hello All, > > > > Wanted to get the MIP6 Working groups preference on whether we > > should we add the requirements that arise from RFC 4285 in the > > draft-ietf-mip6-aaa-ha-goals-03 > > > > We would like to hear the Working Groups opinion of the following > question: > > > > Should we add the requirements that arise from RFC 4285 in the > > draft-ietf-mip6-aaa-ha-goals-03? > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > were > > 14 people for "yes" and 5 for "No". > > > > Cheers, > > Gopal and Raj > > > > > > ---------------------------------------------------------------------- > > -- > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:25:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSFY-0002ub-72; Wed, 15 Nov 2006 16:24:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSFW-0002uP-LT for mip6@ietf.org; Wed, 15 Nov 2006 16:24:50 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSFQ-0000tn-IK for mip6@ietf.org; Wed, 15 Nov 2006 16:24:50 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8S00282JH7HU@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 15 Nov 2006 13:24:44 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8S004JHJH0ZF@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 15 Nov 2006 13:24:43 -0800 (PST) Date: Wed, 15 Nov 2006 13:24:38 -0800 From: Madjid Nakhjiri Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: To: 'Basavaraj Patil' , "'ext Tsirtsis, George'" , 'Gopal Dommety' , mip6@ietf.org Message-id: <002b01c708fc$757c4e10$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8AAUvUMA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Thanks for the clarification. Based on your statements that 4285 is a recognized mode of operation and that AAA requirements goal needs to encompass Diameter/RADIUS and MIP6 operation, then my answer is Yes Having said that, can we agree that not every solution draft Has to meet = the 4285 requirement support. So basically "4285 support" Should not be = "MUST" Regards and thanks again for clarifying, Madjid -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 Sent: Wednesday, November 15, 2006 12:44 PM To: ext Tsirtsis, George; Gopal Dommety; mip6@ietf.org Subject: Re: [Mip6] Should we add the requirements that arise from RFC = 4285 in the draft-ietf-mip6-aaa-ha-goals-03? George, Let me see if I can clarify the question to the WG w.r.t the = aaa-ha-goals I-D: The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended to capture the = AAA requirements for MIP6 deployment/operation. These requirements would be = fed to the appropriate AAA WGs (DIME/Radext) for developing the actual = solutions or extensions. In some cases the MIP6 WG in conjunction with a AAA WG = (such as Radext) can take up the work as illustrated by the I-D draft-ietf-mip6-radius but in others the DIME WG is working on the = solutions needed for MIP6. The current version of the goals/requirements I-D does not consider the = case when RFC4285 is used as the means for authenticating an MN to an HA. The = AAA requirements are based strictly on the use of IPsec between the MN and = HA. The question to the WG was whether the AAA requirements/goals document should include the requirements that MIP6 operation with RFC4285 brings. Since the AAA goals document is intended to capture all the MIP6 AAA requirements and RFC4285 is a recognized mode of MIP6 operation, it = makes sense to capture the additional requirements at this time. Is this clear now? -Raj On 11/14/06 11:40 AM, "ext Tsirtsis, George" = wrote: > Gopal, >=20 > I am not sure I understand the question. RFC4285 defines a mechanism/solution > and an associated applicability statement. What is it that you propose = to > "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what form? >=20 > I would also appreciate if people voting "yes" or "no" on this (or = any) issue, > say something about why they vote one way or the other. >=20 > Regards > George > ________________________________________ > From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] > Sent: Saturday, November 11, 2006 1:44 PM > To: mip6@ietf.org > Subject: [Mip6] Should we add the requirements that arise from RFC = 4285 inthe > draft-ietf-mip6-aaa-ha-goals-03? >=20 > Hello All, > =A0 > =A0=A0=A0 Wanted to get the MIP6 Working groups preference on whether = we should we > add the requirements that arise from RFC 4285 in the =A0 > draft-ietf-mip6-aaa-ha-goals-03 > =A0 > We would like to hear the Working Groups opinion of the following question: > =A0 > Should we add the requirements that arise from RFC 4285 in the=A0 > draft-ietf-mip6-aaa-ha-goals-03? > =A0 > =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there = were 14 > people for "yes" and 5 for "No". > =A0 > Cheers, > Gopal and Raj >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:27:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSI7-0003e3-00; Wed, 15 Nov 2006 16:27:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSI5-0003dZ-T3 for mip6@ietf.org; Wed, 15 Nov 2006 16:27:29 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSI4-0001Lt-9Y for mip6@ietf.org; Wed, 15 Nov 2006 16:27:29 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFLRHbE011702; Wed, 15 Nov 2006 23:27:20 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 23:27:19 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:26:24 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 21:26:23 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 15:26:38 -0600 Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? From: Basavaraj Patil To: ext Vijay Devarapalli , Gopal Dommety Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccI/Lvd+j1QpnTvEdujfwARJNUNiA== In-Reply-To: <455A0A1B.1000600@azairenet.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 21:26:24.0252 (UTC) FILETIME=[B3ABF3C0:01C708FC] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061115232720-2D3E8BB0-386B4A2E/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay, Inline: On 11/14/06 12:25 PM, "ext Vijay Devarapalli" wrote: > Gopal, > > lets step back a bit. what is the point of adding > of 4285-specific requirements in > draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used > for MN authentication? or does it include > bootstrapping for 4285 too? Bootstrapping for RFC4285 is not in the scope of the MIP6 WG charter at this time and hence the AAA requirements are just for the basic 4285 operation. > > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture > all the requirements in one place with no binding > to develop any solutions yet? Yes. > > other bootstrapping related questions, do we want > to standardize bootstrapping solutions for 4285 > too? has the DIME WG agreed to developing > solutions for 4285-based MIP6 operation? We do not have consensus to develop bootstrapping solutions for RFC4285 mode of operation. The view is that we do not really need to standardize such a solution. People who are interested in using RFC4285 with MIP6 may have their own means for bootstrapping and hence the need for the WG to specify such bootstrapping is not essential. The DIME WG is working on bootstrapping solution based on the current bootstrapping solutions in the MIP6 WG which does not include bootstrapping for RFC4285. -Raj > > Vijay > > Gopal Dommety (gdommety) wrote: >> Hello All, >> >> Wanted to get the MIP6 Working groups preference on whether we >> should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03 >> >> We would like to hear the Working Groups opinion of the following question: >> >> Should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03? >> >> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were >> 14 people for "yes" and 5 for "No". >> >> Cheers, >> Gopal and Raj >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:29:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSJh-0004EL-VV; Wed, 15 Nov 2006 16:29:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSJh-0004EF-Am for mip6@ietf.org; Wed, 15 Nov 2006 16:29:09 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSJf-0001nq-7z for mip6@ietf.org; Wed, 15 Nov 2006 16:29:09 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFLSQh7012782; Wed, 15 Nov 2006 23:28:54 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 23:28:51 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:28:49 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 21:28:48 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 15:29:02 -0600 Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? From: Basavaraj Patil To: "Kent Leung (kleung)" , Vijay Devarapalli , Gopal Dommety Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccIHFSSBlUgJtl+SoWX2OC6YWqsAwADB4JAADUnxnY= In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5202DFB8A3@xmb-sjc-235.amer.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 21:28:49.0065 (UTC) FILETIME=[09FCA990:01C708FD] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Kent, I would just like to emphasize here that the requirements that we want to consider adding to the AAA-goals document has nothing to do with bootstrapping when using RFC4285 with MIP6. Rather, the requirements would be the ones that are limited to the interaction between the HA and the AAA when RFC4285 is used. -Raj On 11/14/06 2:08 PM, "ext Kent Leung (kleung)" wrote: > > My vote is YES. > > I assume this question is intended for HA-AAA interface support for RFC > 4285. But it would be definitely nice to have standards-based AAA > attributes for bootstrapping in terms of completeness. > > Kent > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, November 14, 2006 10:26 AM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > Gopal, > > lets step back a bit. what is the point of adding of 4285-specific > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used for MN > authentication? or does it include bootstrapping for 4285 too? > > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > one place with no binding to develop any solutions yet? > > other bootstrapping related questions, do we want to standardize > bootstrapping solutions for 4285 too? has the DIME WG agreed to > developing solutions for 4285-based MIP6 operation? > > Vijay > > Gopal Dommety (gdommety) wrote: >> Hello All, >> >> Wanted to get the MIP6 Working groups preference on whether we >> should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03 >> >> We would like to hear the Working Groups opinion of the following > question: >> >> Should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03? >> >> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there >> were >> 14 people for "yes" and 5 for "No". >> >> Cheers, >> Gopal and Raj >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:32:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSN3-0005Y9-Rt; Wed, 15 Nov 2006 16:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSN1-0005Xf-NZ for mip6@ietf.org; Wed, 15 Nov 2006 16:32:35 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSN0-0002WJ-5a for mip6@ietf.org; Wed, 15 Nov 2006 16:32:35 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFLWKA2016563; Wed, 15 Nov 2006 23:32:21 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 23:32:15 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:32:00 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 21:32:00 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 15:32:14 -0600 Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? From: Basavaraj Patil To: ext Madjid Nakhjiri , "Kent Leung (kleung)" , "'Vijay Devarapalli'" , Gopal Dommety Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccIHFSSBlUgJtl+SoWX2OC6YWqsAwADB4JAAAZYETAALuxRew== In-Reply-To: <001001c70842$21da8020$2f01a8c0@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 21:32:00.0909 (UTC) FILETIME=[7C55BBD0:01C708FD] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061115233223-3F764BB0-253D43CD/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Madjid, I agree that supporting RFC4285 may be just a matter fo ensuring that the appropriate attributes or AVPs exist. However if we were to capture the requirements, we would be able to point to existing attributes/AVPs that solve the problem or specify then if needed. At the MIP6 meeting, I think there was a comment that there may be a need for a new Diameter application in some case (don't remember which specific scenario). Maybe the requirements would flush out such a need if it exists. -Raj On 11/14/06 5:10 PM, "ext Madjid Nakhjiri" wrote: > Personally, I suspect that 4285 support simply needs a bunch of attributes. > I suggest people propose a couple of requirements related to 4285 support > and after that we could easily see if those can be added to the current set > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > Madjid > > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, November 14, 2006 12:08 PM > To: Vijay Devarapalli; Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > My vote is YES. > > I assume this question is intended for HA-AAA interface support for RFC > 4285. But it would be definitely nice to have standards-based AAA > attributes for bootstrapping in terms of completeness. > > Kent > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, November 14, 2006 10:26 AM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > Gopal, > > lets step back a bit. what is the point of adding of 4285-specific > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used for MN > authentication? or does it include bootstrapping for 4285 too? > > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > one place with no binding to develop any solutions yet? > > other bootstrapping related questions, do we want to standardize > bootstrapping solutions for 4285 too? has the DIME WG agreed to > developing solutions for 4285-based MIP6 operation? > > Vijay > > Gopal Dommety (gdommety) wrote: >> Hello All, >> >> Wanted to get the MIP6 Working groups preference on whether we >> should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03 >> >> We would like to hear the Working Groups opinion of the following > question: >> >> Should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03? >> >> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there >> were >> 14 people for "yes" and 5 for "No". >> >> Cheers, >> Gopal and Raj >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSRp-0007cZ-Pm; Wed, 15 Nov 2006 16:37:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSRo-0007c4-Qr for mip6@ietf.org; Wed, 15 Nov 2006 16:37:32 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSRm-0003Ol-LN for mip6@ietf.org; Wed, 15 Nov 2006 16:37:32 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFLaikN010842; Wed, 15 Nov 2006 23:37:14 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 23:36:55 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:36:50 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 21:36:49 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 15:37:04 -0600 Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? From: Basavaraj Patil To: ext Madjid Nakhjiri , "'ext Tsirtsis, George'" , Gopal Dommety , Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8AAUvUMAAAik5X In-Reply-To: <002b01c708fc$757c4e10$2f01a8c0@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Nov 2006 21:36:50.0522 (UTC) FILETIME=[28F52BA0:01C708FE] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061115233716-29566BB0-7A16E425/0-0/0-0 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Madjid, RFC4285 includes an IESG statement part of it which says: " Section 1.1 of this document provides an applicability statement for this RFC. The IESG recommends against the usage of this specification outside of environments that meet the conditions of that applicability statement. In addition the IESG recommends those considering deploying or implementing this specification conduct a sufficient security review to meet the conditions of the environments in which this RFC will be used. " So RFC4285 support is not a MUST. -Raj On 11/15/06 3:24 PM, "ext Madjid Nakhjiri" wrote: > Hi Raj, >=20 > Thanks for the clarification. Based on your statements that 4285 is a > recognized mode of operation and that AAA requirements goal needs to > encompass Diameter/RADIUS and MIP6 operation, then my answer is >=20 > Yes >=20 > Having said that, can we agree that not every solution draft Has to meet = the > 4285 requirement support. So basically "4285 support" Should not be "MUST= " >=20 > Regards and thanks again for clarifying, >=20 > Madjid >=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > Sent: Wednesday, November 15, 2006 12:44 PM > To: ext Tsirtsis, George; Gopal Dommety; mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC 42= 85 > in the draft-ietf-mip6-aaa-ha-goals-03? >=20 >=20 > George, >=20 > Let me see if I can clarify the question to the WG w.r.t the aaa-ha-goals > I-D: >=20 > The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended to capture the A= AA > requirements for MIP6 deployment/operation. These requirements would be f= ed > to the appropriate AAA WGs (DIME/Radext) for developing the actual soluti= ons > or extensions. In some cases the MIP6 WG in conjunction with a AAA WG (su= ch > as Radext) can take up the work as illustrated by the I-D > draft-ietf-mip6-radius but in others the DIME WG is working on the soluti= ons > needed for MIP6. >=20 > The current version of the goals/requirements I-D does not consider the c= ase > when RFC4285 is used as the means for authenticating an MN to an HA. The = AAA > requirements are based strictly on the use of IPsec between the MN and HA= . > The question to the WG was whether the AAA requirements/goals document > should include the requirements that MIP6 operation with RFC4285 brings. >=20 > Since the AAA goals document is intended to capture all the MIP6 AAA > requirements and RFC4285 is a recognized mode of MIP6 operation, it makes > sense to capture the additional requirements at this time. >=20 > Is this clear now? >=20 > -Raj >=20 >=20 >=20 > On 11/14/06 11:40 AM, "ext Tsirtsis, George" wrot= e: >=20 >> Gopal, >>=20 >> I am not sure I understand the question. RFC4285 defines a > mechanism/solution >> and an associated applicability statement. What is it that you propose t= o >> "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what form? >>=20 >> I would also appreciate if people voting "yes" or "no" on this (or any) > issue, >> say something about why they vote one way or the other. >>=20 >> Regards >> George >> ________________________________________ >> From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] >> Sent: Saturday, November 11, 2006 1:44 PM >> To: mip6@ietf.org >> Subject: [Mip6] Should we add the requirements that arise from RFC 4285 > inthe >> draft-ietf-mip6-aaa-ha-goals-03? >>=20 >> Hello All, >> =A0 >> =A0=A0=A0 Wanted to get the MIP6 Working groups preference on whether we shoul= d > we >> add the requirements that arise from RFC 4285 in the =A0 >> draft-ietf-mip6-aaa-ha-goals-03 >> =A0 >> We would like to hear the Working Groups opinion of the following > question: >> =A0 >> Should we add the requirements that arise from RFC 4285 in the=A0 >> draft-ietf-mip6-aaa-ha-goals-03? >> =A0 >> =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were = 14 >> people for "yes" and 5 for "No". >> =A0 >> Cheers, >> Gopal and Raj >>=20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:39:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSTO-000877-FI; Wed, 15 Nov 2006 16:39:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSTM-00086T-WD; Wed, 15 Nov 2006 16:39:09 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSTI-0003fV-5p; Wed, 15 Nov 2006 16:39:08 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kAFLctfx003698; Wed, 15 Nov 2006 22:38:55 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id kAFLcto0019772; Wed, 15 Nov 2006 22:38:55 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 22:38:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Wed, 15 Nov 2006 22:38:49 +0100 Message-ID: In-Reply-To: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccIROjOnFtEd7gWRFmXGaLfZ/cAvgAswaVgAAFngaA= From: "Tschofenig, Hannes" To: "Madjid Nakhjiri" , "Gerardo Giaretta" X-OriginalArrivalTime: 15 Nov 2006 21:38:55.0014 (UTC) FILETIME=[73292460:01C708FE] X-Spam-Score: 0.6 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: "Gopal Dommety \(gdommety\)" , mip6@ietf.org, "Kent Leung \(kleung\)" , dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Madjid,=20 you make things quite complicated. Gerardo and myself have asked the = following question to the MIP6 working group: Should = draft-ietf-mip6-aaa-ha-goals-03 say something about RFC 4285? Possible = answers are: a) Don't say anything about RFC 4285.=20 b) Explicitly rule out support for RFC 4285.=20 c) Explicitly support RFC 4285. =20 If draft-ietf-mip6-aaa-ha-goals-03 has to support both, RFC 4285 and = IKEv2/EAP based authentication, then that's fine with us. I know that = this is not difficult todo. We just need to get the documents written in = such a way. We just thought it is better to ask before we finish the = documents and suddently get told that this was not in the scope of our = work.=20 Furthermore, nobody said that draft-ietf-mip6-aaa-ha-goals-03 only = impacts the DIME work. It obviously also impacts the corresponding = RADIUS work since we are supposed to align the two designs. We just came = across this issue when we worked on the Diameter document.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Gesendet: Mittwoch, 15. November 2006 22:19 > An: 'Gerardo Giaretta' > Cc: 'Gopal Dommety (gdommety)'; 'Kent Leung (kleung)';=20 > mip6@ietf.org; dime@ietf.org > Betreff: [Dime] RE: [Mip6] Should we add the requirements=20 > that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Hi Gerardo, >=20 >=20 > If you remember, the first time people asked this question, I=20 > said we should > simply be careful about rubber stamping the Dime drafts as=20 > supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on=20 > supporting > 4285, we should refrain from making the promise that Dime=20 > draft do too. > If we design something based on a requirement that excludes=20 > support for > 4285, then the solution has no obligation to support it either.=20 >=20 > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for=20 > both RADIUS and > Diameter. Unless you want to change the name, we need to=20 > realize that this > document can=20 > a) create requirements that RADIUS cannot meet and hence rule=20 > out RADIUS for > MIP6 support (some of the current goals related to key=20 > transport fit that > category) > b) create requirement for all AAA functionality, i.e both=20 > requirements on > AAA functionality within HA and on AAA protocol. This means=20 > if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state=20 > whether they fulfill > all requirements, including 4285 requirements. We already=20 > have two dime > drafts for two different designs. >=20 > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer=20 > seems to be yes > from your email. So the HA-AAA goals is not a generic=20 > requirement goal for > MIP6. The current HA-AAA goals document should specifically=20 > state that it is > the requirements for Diameter EAP based solutions and not for=20 > 4285 to clear > all the issues above. >=20 > Personally I think support for 4285 is a lot simpler than=20 > people think, and > might not require much more than some AVPs and look similar=20 > to 4004 for MIP4 > support in case of CCOA, but I have not done a detail=20 > analysis. If that is > true all 4285 needs in way of requirements is probably being=20 > allowed to have > some new AVPs (or possibly same as those used in MIP4).=20 >=20 > The problem of excluding these from HA-AAA goal is that you=20 > may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? >=20 > Hope THIS clarifies some more :) >=20 > Regards, >=20 > Madjid >=20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. >=20 > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). >=20 > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? >=20 > I hope this clarifies. >=20 > --Gerardo >=20 > On 11/14/06, Madjid Nakhjiri wrote: > > Personally, I suspect that 4285 support simply needs a bunch of > attributes. > > I suggest people propose a couple of requirements related=20 > to 4285 support > > and after that we could easily see if those can be added to=20 > the current > set > > of goals. Once we did that we can simply say the HA-AAAH=20 > support 4285. > > > > Madjid > > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, November 14, 2006 12:08 PM > > To: Vijay Devarapalli; Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Should we add the requirements that=20 > arise from RFC > > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > > > > My vote is YES. > > > > I assume this question is intended for HA-AAA interface=20 > support for RFC > > 4285. But it would be definitely nice to have standards-based AAA > > attributes for bootstrapping in terms of completeness. > > > > Kent > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, November 14, 2006 10:26 AM > > To: Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Should we add the requirements that=20 > arise from RFC > > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > > > Gopal, > > > > lets step back a bit. what is the point of adding of 4285-specific > > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > > 4285 operation where the HA-AAAH interface is used for MN > > authentication? or does it include bootstrapping for 4285 too? > > > > will the requirements be added to > > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the=20 > requirements in > > one place with no binding to develop any solutions yet? > > > > other bootstrapping related questions, do we want to standardize > > bootstrapping solutions for 4285 too? has the DIME WG agreed to > > developing solutions for 4285-based MIP6 operation? > > > > Vijay > > > > Gopal Dommety (gdommety) wrote: > > > Hello All, > > > > > > Wanted to get the MIP6 Working groups preference on whether we > > > should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03 > > > > > > We would like to hear the Working Groups opinion of the following > > question: > > > > > > Should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03? > > > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > > were > > > 14 people for "yes" and 5 for "No". > > > > > > Cheers, > > > Gopal and Raj > > > > > > > > >=20 > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:42:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSWB-0001ZL-W0; Wed, 15 Nov 2006 16:42:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSWA-0001ZA-RG for mip6@ietf.org; Wed, 15 Nov 2006 16:42:02 -0500 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSW9-00043c-6R for mip6@ietf.org; Wed, 15 Nov 2006 16:42:02 -0500 Received: from mail1.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id kAFLfqlO006338; Wed, 15 Nov 2006 22:41:52 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id kAFLfqxC021479; Wed, 15 Nov 2006 22:41:52 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 22:41:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Wed, 15 Nov 2006 22:41:50 +0100 Message-ID: In-Reply-To: <002b01c708fc$757c4e10$2f01a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8AAUvUMAAApBqw From: "Tschofenig, Hannes" To: "Madjid Nakhjiri" , "Basavaraj Patil" , "ext Tsirtsis, George" , "Gopal Dommety" , X-OriginalArrivalTime: 15 Nov 2006 21:41:52.0084 (UTC) FILETIME=[DCB3E140:01C708FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Madjid,=20 the RFC 2119 language refers to the design of the protocol rather than = its usage. Either you consider the usage of RFC 4285 in the design of = the protocol or you don't. When the protocol is used then obviously you = don't want to mandatorily put RFC 4285 specific AVPs and attributes in = AAA messages.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Gesendet: Mittwoch, 15. November 2006 22:25 > An: 'Basavaraj Patil'; 'ext Tsirtsis, George'; 'Gopal=20 > Dommety'; mip6@ietf.org > Betreff: RE: [Mip6] Should we add the requirements that arise=20 > from RFC 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Hi Raj, >=20 > Thanks for the clarification. Based on your statements that 4285 is a > recognized mode of operation and that AAA requirements goal needs to > encompass Diameter/RADIUS and MIP6 operation, then my answer is >=20 > Yes >=20 > Having said that, can we agree that not every solution draft=20 > Has to meet the > 4285 requirement support. So basically "4285 support" Should=20 > not be "MUST" >=20 > Regards and thanks again for clarifying, >=20 > Madjid >=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > Sent: Wednesday, November 15, 2006 12:44 PM > To: ext Tsirtsis, George; Gopal Dommety; mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise=20 > from RFC 4285 > in the draft-ietf-mip6-aaa-ha-goals-03? >=20 >=20 > George, >=20 > Let me see if I can clarify the question to the WG w.r.t the=20 > aaa-ha-goals > I-D: >=20 > The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended to=20 > capture the AAA > requirements for MIP6 deployment/operation. These=20 > requirements would be fed > to the appropriate AAA WGs (DIME/Radext) for developing the=20 > actual solutions > or extensions. In some cases the MIP6 WG in conjunction with=20 > a AAA WG (such > as Radext) can take up the work as illustrated by the I-D > draft-ietf-mip6-radius but in others the DIME WG is working=20 > on the solutions > needed for MIP6. >=20 > The current version of the goals/requirements I-D does not=20 > consider the case > when RFC4285 is used as the means for authenticating an MN to=20 > an HA. The AAA > requirements are based strictly on the use of IPsec between=20 > the MN and HA. > The question to the WG was whether the AAA requirements/goals document > should include the requirements that MIP6 operation with=20 > RFC4285 brings. >=20 > Since the AAA goals document is intended to capture all the MIP6 AAA > requirements and RFC4285 is a recognized mode of MIP6=20 > operation, it makes > sense to capture the additional requirements at this time. >=20 > Is this clear now? >=20 > -Raj >=20 >=20 >=20 > On 11/14/06 11:40 AM, "ext Tsirtsis, George"=20 > wrote: >=20 > > Gopal, > >=20 > > I am not sure I understand the question. RFC4285 defines a > mechanism/solution > > and an associated applicability statement. What is it that=20 > you propose to > > "add" to draft-ietf-mip6-aaa-ha-goals-03 and in what form? > >=20 > > I would also appreciate if people voting "yes" or "no" on=20 > this (or any) > issue, > > say something about why they vote one way or the other. > >=20 > > Regards > > George > > ________________________________________ > > From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] > > Sent: Saturday, November 11, 2006 1:44 PM > > To: mip6@ietf.org > > Subject: [Mip6] Should we add the requirements that arise=20 > from RFC 4285 > inthe > > draft-ietf-mip6-aaa-ha-goals-03? > >=20 > > Hello All, > > =A0 > > =A0=A0=A0 Wanted to get the MIP6 Working groups preference on=20 > whether we should > we > > add the requirements that arise from RFC 4285 in the =A0 > > draft-ietf-mip6-aaa-ha-goals-03 > > =A0 > > We would like to hear the Working Groups opinion of the following > question: > > =A0 > > Should we add the requirements that arise from RFC 4285 in the=A0 > > draft-ietf-mip6-aaa-ha-goals-03? > > =A0 > > =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG=20 > meeting there were 14 > > people for "yes" and 5 for "No". > > =A0 > > Cheers, > > Gopal and Raj > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 16:45:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSZR-00020j-UZ; Wed, 15 Nov 2006 16:45:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSZQ-0001le-Ey for mip6@ietf.org; Wed, 15 Nov 2006 16:45:24 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSZO-0004aq-UW for mip6@ietf.org; Wed, 15 Nov 2006 16:45:24 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAFLjK8p031863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2006 13:45:21 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAFLgi95000956; Wed, 15 Nov 2006 13:45:20 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 13:44:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? Date: Wed, 15 Nov 2006 13:45:03 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8AAflzMA== From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Tsirtsis, George" , "Gopal Dommety" , X-OriginalArrivalTime: 15 Nov 2006 21:44:59.0394 (UTC) FILETIME=[4C591E20:01C708FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Raj, What is the purpose of the aaa-ha-goals document? Are the AAA solution = documents required to satisfy all the identified goals? Also, are the = AAA solution documents expected to be PS or Informational?=20 I think we need to answer the above questions before we can make a = decision on this particular topic.=20 Vidya=20 > -----Original Message----- > From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 > Sent: Wednesday, November 15, 2006 12:44 PM > To: Tsirtsis, George; Gopal Dommety; mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise=20 > from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? >=20 >=20 > George, >=20 > Let me see if I can clarify the question to the WG w.r.t the=20 > aaa-ha-goals > I-D: >=20 > The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended to=20 > capture the AAA requirements for MIP6 deployment/operation.=20 > These requirements would be fed to the appropriate AAA WGs=20 > (DIME/Radext) for developing the actual solutions or=20 > extensions. In some cases the MIP6 WG in conjunction with a=20 > AAA WG (such as Radext) can take up the work as illustrated=20 > by the I-D draft-ietf-mip6-radius but in others the DIME WG=20 > is working on the solutions needed for MIP6. >=20 > The current version of the goals/requirements I-D does not=20 > consider the case when RFC4285 is used as the means for=20 > authenticating an MN to an HA. The AAA requirements are based=20 > strictly on the use of IPsec between the MN and HA. > The question to the WG was whether the AAA requirements/goals=20 > document should include the requirements that MIP6 operation=20 > with RFC4285 brings. >=20 > Since the AAA goals document is intended to capture all the=20 > MIP6 AAA requirements and RFC4285 is a recognized mode of=20 > MIP6 operation, it makes sense to capture the additional=20 > requirements at this time. >=20 > Is this clear now? >=20 > -Raj >=20 >=20 >=20 > On 11/14/06 11:40 AM, "ext Tsirtsis, George"=20 > wrote: >=20 > > Gopal, > >=20 > > I am not sure I understand the question. RFC4285 defines a=20 > > mechanism/solution and an associated applicability=20 > statement. What is=20 > > it that you propose to "add" to=20 > draft-ietf-mip6-aaa-ha-goals-03 and in what form? > >=20 > > I would also appreciate if people voting "yes" or "no" on this (or=20 > > any) issue, say something about why they vote one way or the other. > >=20 > > Regards > > George > > ________________________________________ > > From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] > > Sent: Saturday, November 11, 2006 1:44 PM > > To: mip6@ietf.org > > Subject: [Mip6] Should we add the requirements that arise from RFC=20 > > 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? > >=20 > > Hello All, > > =A0 > > =A0=A0=A0 Wanted to get the MIP6 Working groups preference on = whether we=20 > > should we add the requirements that arise from RFC 4285 in the > > draft-ietf-mip6-aaa-ha-goals-03 > > =A0 > > We would like to hear the Working Groups opinion of the=20 > following question: > > =A0 > > Should we add the requirements that arise from RFC 4285 in the=20 > > draft-ietf-mip6-aaa-ha-goals-03? > > =A0 > > =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there = > > were 14 people for "yes" and 5 for "No". > > =A0 > > Cheers, > > Gopal and Raj > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 17:01:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSoi-0006J8-MZ; Wed, 15 Nov 2006 17:01:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSoh-0006Iw-H1 for mip6@ietf.org; Wed, 15 Nov 2006 17:01:11 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSof-0006rd-Ts for mip6@ietf.org; Wed, 15 Nov 2006 17:01:11 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFM0jSa030801; Thu, 16 Nov 2006 00:01:07 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 00:01:03 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 16:00:59 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 22:00:58 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 16:01:13 -0600 Subject: Re: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? From: Basavaraj Patil To: "ext Narayanan, Vidya" , "Tsirtsis, George" , Gopal Dommety , Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8AAflzMAAAtJrw In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Nov 2006 22:00:59.0419 (UTC) FILETIME=[88914EB0:01C70901] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, In case I was not clear enough in my earlier email (below), let me reiterat= e that the purpose of the aaa-ha-goals document is to capture all the AAA requirements that the MIP6 WG believes exist for MIP6 deployment and operation.=20 The AAA solutions developed in DIME or Radext or within the MIP6 WG (workin= g with the appropriate AAA WG) may or may not address all the requirements. And that is an acceptable situation. Of course I would think there would be some valid reasons why a requirement would not be addressed. The AAA solutions documents may be PS or Informational. I think that in several instances the solution would simply be a reference to existing AAA RFCs which already specify the attributes or AVPs and hence such documents could just be informational because they would only specify how MIP6 would work with a AAA framework and reuses existing specs. But in cases wherein there is new attributes, extensions, messages or applications defined, they would be considered for publication as ps docs. The issue of whether the docs would be ps or informational in this thread may not be a key factor IMO. -Raj On 11/15/06 3:45 PM, "ext Narayanan, Vidya" wrote: > Raj, > What is the purpose of the aaa-ha-goals document? Are the AAA solution > documents required to satisfy all the identified goals? Also, are the AAA > solution documents expected to be PS or Informational? >=20 > I think we need to answer the above questions before we can make a decisi= on on > this particular topic. >=20 > Vidya=20 >=20 >> -----Original Message----- >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >> Sent: Wednesday, November 15, 2006 12:44 PM >> To: Tsirtsis, George; Gopal Dommety; mip6@ietf.org >> Subject: Re: [Mip6] Should we add the requirements that arise >> from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? >>=20 >>=20 >> George, >>=20 >> Let me see if I can clarify the question to the WG w.r.t the >> aaa-ha-goals >> I-D: >>=20 >> The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended to >> capture the AAA requirements for MIP6 deployment/operation. >> These requirements would be fed to the appropriate AAA WGs >> (DIME/Radext) for developing the actual solutions or >> extensions. In some cases the MIP6 WG in conjunction with a >> AAA WG (such as Radext) can take up the work as illustrated >> by the I-D draft-ietf-mip6-radius but in others the DIME WG >> is working on the solutions needed for MIP6. >>=20 >> The current version of the goals/requirements I-D does not >> consider the case when RFC4285 is used as the means for >> authenticating an MN to an HA. The AAA requirements are based >> strictly on the use of IPsec between the MN and HA. >> The question to the WG was whether the AAA requirements/goals >> document should include the requirements that MIP6 operation >> with RFC4285 brings. >>=20 >> Since the AAA goals document is intended to capture all the >> MIP6 AAA requirements and RFC4285 is a recognized mode of >> MIP6 operation, it makes sense to capture the additional >> requirements at this time. >>=20 >> Is this clear now? >>=20 >> -Raj >>=20 >>=20 >>=20 >> On 11/14/06 11:40 AM, "ext Tsirtsis, George" >> wrote: >>=20 >>> Gopal, >>>=20 >>> I am not sure I understand the question. RFC4285 defines a >>> mechanism/solution and an associated applicability >> statement. What is >>> it that you propose to "add" to >> draft-ietf-mip6-aaa-ha-goals-03 and in what form? >>>=20 >>> I would also appreciate if people voting "yes" or "no" on this (or >>> any) issue, say something about why they vote one way or the other. >>>=20 >>> Regards >>> George >>> ________________________________________ >>> From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] >>> Sent: Saturday, November 11, 2006 1:44 PM >>> To: mip6@ietf.org >>> Subject: [Mip6] Should we add the requirements that arise from RFC >>> 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? >>>=20 >>> Hello All, >>> =A0 >>> =A0=A0=A0 Wanted to get the MIP6 Working groups preference on whether we >>> should we add the requirements that arise from RFC 4285 in the >>> draft-ietf-mip6-aaa-ha-goals-03 >>> =A0 >>> We would like to hear the Working Groups opinion of the >> following question: >>> =A0 >>> Should we add the requirements that arise from RFC 4285 in the >>> draft-ietf-mip6-aaa-ha-goals-03? >>> =A0 >>> =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there >>> were 14 people for "yes" and 5 for "No". >>> =A0 >>> Cheers, >>> Gopal and Raj >>>=20 >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>=20 >>=20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >>=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 17:05:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSso-000716-NH; Wed, 15 Nov 2006 17:05:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSsn-00070t-DQ; Wed, 15 Nov 2006 17:05:25 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSsm-0007J4-ML; Wed, 15 Nov 2006 17:05:25 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFM40Bi016890; Thu, 16 Nov 2006 00:05:07 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 00:03:27 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 16:03:23 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 22:03:23 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 16:03:37 -0600 Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? From: Basavaraj Patil To: ext Madjid Nakhjiri , "'Gerardo Giaretta'" Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccIROjOnFtEd7gWRFmXGaLfZ/cAvgAswaVgAAJ9x9A= In-Reply-To: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 22:03:23.0903 (UTC) FILETIME=[DEAFD0F0:01C70901] X-Nokia-AV: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: Gopal Dommety , mip6@ietf.org, "Kent Leung \(kleung\)" , dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I think Madjid has raised a good point here. To restate the MIP6 WGs charter objective: The AAA goals I-D is intended to capture requirements (or goals which is the terminology used here) for MIP6 that are generic, i.e the actual AAA solution may be based on Radius or Diameter. And there may be requirements that can be met only by Diameter (as Madjid has mentioned below), but that can be stated in the solution doc. But the requirements are not intended to be limited for consideration by the DIME WG only. -Raj On 11/15/06 3:19 PM, "ext Madjid Nakhjiri" wrote: > Hi Gerardo, > > > If you remember, the first time people asked this question, I said we should > simply be careful about rubber stamping the Dime drafts as supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on supporting > 4285, we should refrain from making the promise that Dime draft do too. > If we design something based on a requirement that excludes support for > 4285, then the solution has no obligation to support it either. > > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for both RADIUS and > Diameter. Unless you want to change the name, we need to realize that this > document can > a) create requirements that RADIUS cannot meet and hence rule out RADIUS for > MIP6 support (some of the current goals related to key transport fit that > category) > b) create requirement for all AAA functionality, i.e both requirements on > AAA functionality within HA and on AAA protocol. This means if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state whether they fulfill > all requirements, including 4285 requirements. We already have two dime > drafts for two different designs. > > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer seems to be yes > from your email. So the HA-AAA goals is not a generic requirement goal for > MIP6. The current HA-AAA goals document should specifically state that it is > the requirements for Diameter EAP based solutions and not for 4285 to clear > all the issues above. > > Personally I think support for 4285 is a lot simpler than people think, and > might not require much more than some AVPs and look similar to 4004 for MIP4 > support in case of CCOA, but I have not done a detail analysis. If that is > true all 4285 needs in way of requirements is probably being allowed to have > some new AVPs (or possibly same as those used in MIP4). > > The problem of excluding these from HA-AAA goal is that you may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? > > Hope THIS clarifies some more :) > > Regards, > > Madjid > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. > > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). > > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? > > I hope this clarifies. > > --Gerardo > > On 11/14/06, Madjid Nakhjiri wrote: >> Personally, I suspect that 4285 support simply needs a bunch of > attributes. >> I suggest people propose a couple of requirements related to 4285 support >> and after that we could easily see if those can be added to the current > set >> of goals. Once we did that we can simply say the HA-AAAH support 4285. >> >> Madjid >> >> -----Original Message----- >> From: Kent Leung (kleung) [mailto:kleung@cisco.com] >> Sent: Tuesday, November 14, 2006 12:08 PM >> To: Vijay Devarapalli; Gopal Dommety (gdommety) >> Cc: mip6@ietf.org >> Subject: RE: [Mip6] Should we add the requirements that arise from RFC >> 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >> >> >> My vote is YES. >> >> I assume this question is intended for HA-AAA interface support for RFC >> 4285. But it would be definitely nice to have standards-based AAA >> attributes for bootstrapping in terms of completeness. >> >> Kent >> >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Tuesday, November 14, 2006 10:26 AM >> To: Gopal Dommety (gdommety) >> Cc: mip6@ietf.org >> Subject: Re: [Mip6] Should we add the requirements that arise from RFC >> 4285in the draft-ietf-mip6-aaa-ha-goals-03? >> >> Gopal, >> >> lets step back a bit. what is the point of adding of 4285-specific >> requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic >> 4285 operation where the HA-AAAH interface is used for MN >> authentication? or does it include bootstrapping for 4285 too? >> >> will the requirements be added to >> draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in >> one place with no binding to develop any solutions yet? >> >> other bootstrapping related questions, do we want to standardize >> bootstrapping solutions for 4285 too? has the DIME WG agreed to >> developing solutions for 4285-based MIP6 operation? >> >> Vijay >> >> Gopal Dommety (gdommety) wrote: >>> Hello All, >>> >>> Wanted to get the MIP6 Working groups preference on whether we >>> should we add the requirements that arise from RFC 4285 in the >>> draft-ietf-mip6-aaa-ha-goals-03 >>> >>> We would like to hear the Working Groups opinion of the following >> question: >>> >>> Should we add the requirements that arise from RFC 4285 in the >>> draft-ietf-mip6-aaa-ha-goals-03? >>> >>> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there >>> were >>> 14 people for "yes" and 5 for "No". >>> >>> Cheers, >>> Gopal and Raj >>> >>> >>> ---------------------------------------------------------------------- >>> -- >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 17:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTan-0005ui-1A; Wed, 15 Nov 2006 17:50:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTal-0005u6-LY for mip6@ietf.org; Wed, 15 Nov 2006 17:50:51 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkTaf-0005GB-FT for mip6@ietf.org; Wed, 15 Nov 2006 17:50:51 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8S002WCNGKHU@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 15 Nov 2006 14:50:45 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8S002L3NGF2B@usaga01-in.huawei.com> for mip6@ietf.org; Wed, 15 Nov 2006 14:50:44 -0800 (PST) Date: Wed, 15 Nov 2006 14:50:41 -0800 From: Madjid Nakhjiri Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: To: 'Basavaraj Patil' , "'Kent Leung (kleung)'" , 'Vijay Devarapalli' , 'Gopal Dommety' Message-id: <003901c70908$7a7206b0$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Thread-index: AccIHFSSBlUgJtl+SoWX2OC6YWqsAwADB4JAAAZYETAALuxRewAClyNA X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, Please see below, Regards, Madjid -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] Sent: Wednesday, November 15, 2006 1:32 PM To: ext Madjid Nakhjiri; Kent Leung (kleung); 'Vijay Devarapalli'; Gopal Dommety Cc: mip6@ietf.org Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Hi Madjid, I agree that supporting RFC4285 may be just a matter fo ensuring that the appropriate attributes or AVPs exist. However if we were to capture the requirements, we would be able to point to existing attributes/AVPs that solve the problem or specify then if needed. Madjid>>I agree, I was saying that for the sake of better "requirement design", people should actually define what 4285 requirements are rather than simply saying 4285 should be supported. And my point was 4285 requirements are probably just one or two simple ones that should be added to the goal draft, so that we have a generic HA-AAA goal document. At the MIP6 meeting, I think there was a comment that there may be a need for a new Diameter application in some case (don't remember which specific scenario). Maybe the requirements would flush out such a need if it exists. Madjid>>that is very possible, if 4285 requires mandatory attributes (say for carrying keys/nonces) that are different from 4004 and whatever Dime drafts come up with, then we need a new Application, but that is not the concern of a generic requirement document, imho. -Raj On 11/14/06 5:10 PM, "ext Madjid Nakhjiri" wrote: > Personally, I suspect that 4285 support simply needs a bunch of attributes. > I suggest people propose a couple of requirements related to 4285 support > and after that we could easily see if those can be added to the current set > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > Madjid > > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, November 14, 2006 12:08 PM > To: Vijay Devarapalli; Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > My vote is YES. > > I assume this question is intended for HA-AAA interface support for RFC > 4285. But it would be definitely nice to have standards-based AAA > attributes for bootstrapping in terms of completeness. > > Kent > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, November 14, 2006 10:26 AM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > Gopal, > > lets step back a bit. what is the point of adding of 4285-specific > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used for MN > authentication? or does it include bootstrapping for 4285 too? > > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > one place with no binding to develop any solutions yet? > > other bootstrapping related questions, do we want to standardize > bootstrapping solutions for 4285 too? has the DIME WG agreed to > developing solutions for 4285-based MIP6 operation? > > Vijay > > Gopal Dommety (gdommety) wrote: >> Hello All, >> >> Wanted to get the MIP6 Working groups preference on whether we >> should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03 >> >> We would like to hear the Working Groups opinion of the following > question: >> >> Should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03? >> >> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there >> were >> 14 people for "yes" and 5 for "No". >> >> Cheers, >> Gopal and Raj >> >> >> ---------------------------------------------------------------------- >> -- >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 17:58:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkThe-0001GX-1u; Wed, 15 Nov 2006 17:57:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkThc-0001El-W3 for mip6@ietf.org; Wed, 15 Nov 2006 17:57:56 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkThb-0006Ky-DK for mip6@ietf.org; Wed, 15 Nov 2006 17:57:56 -0500 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAFMvrDH006794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2006 14:57:54 -0800 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAFMvHZG029098; Wed, 15 Nov 2006 14:57:53 -0800 (PST) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 14:57:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? Date: Wed, 15 Nov 2006 14:57:29 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8AAflzMAAAtJrwAAGXufA= From: "Narayanan, Vidya" To: "Basavaraj Patil" , "Tsirtsis, George" , "Gopal Dommety" , X-OriginalArrivalTime: 15 Nov 2006 22:57:39.0780 (UTC) FILETIME=[73573840:01C70909] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj, >=20 > Hi Vidya, >=20 > In case I was not clear enough in my earlier email (below),=20 > let me reiterate that the purpose of the aaa-ha-goals=20 > document is to capture all the AAA requirements that the MIP6=20 > WG believes exist for MIP6 deployment and operation.=20 > The AAA solutions developed in DIME or Radext or within the=20 > MIP6 WG (working with the appropriate AAA WG) may or may not=20 > address all the requirements. > And that is an acceptable situation. Of course I would think=20 > there would be some valid reasons why a requirement would not=20 > be addressed. >=20 This is somewhat ambiguous. I would imagine that the goals are written = to be met. Otherwise, there needs to be classifications in the goals = such that there is a set that a solution MUST meet in order for it to be = useful. Without that, there doesn't seem to be a way to evaluate the = solution.=20 > The AAA solutions documents may be PS or Informational. I=20 > think that in several instances the solution would simply be=20 > a reference to existing AAA RFCs which already specify the=20 > attributes or AVPs and hence such documents could just be=20 > informational because they would only specify how MIP6 would=20 > work with a AAA framework and reuses existing specs. But in=20 > cases wherein there is new attributes, extensions, messages=20 > or applications defined, they would be considered for=20 > publication as ps docs. This is also ambiguous. I don't think it matters whether the solution = document is pointing to a whole bunch of existing attributes or defining = new ones. It would make sense to be a PS, if that is required for MIP6 = operation in AAA-based networks.=20 > The issue of whether the docs would be ps or informational in=20 > this thread may not be a key factor IMO. >=20 Given the applicability statement in RFC4285, I would say that if the = solution document is meant to be a PS, it should not be discussing = solutions related to RFC4285.=20 Vidya > -Raj >=20 >=20 > On 11/15/06 3:45 PM, "ext Narayanan, Vidya"=20 > wrote: >=20 > > Raj, > > What is the purpose of the aaa-ha-goals document? Are the=20 > AAA solution=20 > > documents required to satisfy all the identified goals?=20 > Also, are the=20 > > AAA solution documents expected to be PS or Informational? > >=20 > > I think we need to answer the above questions before we can make a=20 > > decision on this particular topic. > >=20 > > Vidya > >=20 > >> -----Original Message----- > >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > >> Sent: Wednesday, November 15, 2006 12:44 PM > >> To: Tsirtsis, George; Gopal Dommety; mip6@ietf.org > >> Subject: Re: [Mip6] Should we add the requirements that arise from=20 > >> RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? > >>=20 > >>=20 > >> George, > >>=20 > >> Let me see if I can clarify the question to the WG w.r.t the=20 > >> aaa-ha-goals > >> I-D: > >>=20 > >> The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended=20 > to capture=20 > >> the AAA requirements for MIP6 deployment/operation. > >> These requirements would be fed to the appropriate AAA WGs > >> (DIME/Radext) for developing the actual solutions or=20 > extensions. In=20 > >> some cases the MIP6 WG in conjunction with a AAA WG (such=20 > as Radext)=20 > >> can take up the work as illustrated by the I-D=20 > draft-ietf-mip6-radius=20 > >> but in others the DIME WG is working on the solutions needed for=20 > >> MIP6. > >>=20 > >> The current version of the goals/requirements I-D does not=20 > consider=20 > >> the case when RFC4285 is used as the means for=20 > authenticating an MN=20 > >> to an HA. The AAA requirements are based strictly on the=20 > use of IPsec=20 > >> between the MN and HA. > >> The question to the WG was whether the AAA requirements/goals=20 > >> document should include the requirements that MIP6 operation with=20 > >> RFC4285 brings. > >>=20 > >> Since the AAA goals document is intended to capture all the > >> MIP6 AAA requirements and RFC4285 is a recognized mode of > >> MIP6 operation, it makes sense to capture the additional=20 > requirements=20 > >> at this time. > >>=20 > >> Is this clear now? > >>=20 > >> -Raj > >>=20 > >>=20 > >>=20 > >> On 11/14/06 11:40 AM, "ext Tsirtsis, George" > >> wrote: > >>=20 > >>> Gopal, > >>>=20 > >>> I am not sure I understand the question. RFC4285 defines a=20 > >>> mechanism/solution and an associated applicability > >> statement. What is > >>> it that you propose to "add" to > >> draft-ietf-mip6-aaa-ha-goals-03 and in what form? > >>>=20 > >>> I would also appreciate if people voting "yes" or "no" on this (or > >>> any) issue, say something about why they vote one way or=20 > the other. > >>>=20 > >>> Regards > >>> George > >>> ________________________________________ > >>> From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] > >>> Sent: Saturday, November 11, 2006 1:44 PM > >>> To: mip6@ietf.org > >>> Subject: [Mip6] Should we add the requirements that arise from RFC > >>> 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? > >>>=20 > >>> Hello All, > >>> =A0 > >>> =A0=A0=A0 Wanted to get the MIP6 Working groups preference on=20 > whether we=20 > >>> should we add the requirements that arise from RFC 4285 in the > >>> draft-ietf-mip6-aaa-ha-goals-03 > >>> =A0 > >>> We would like to hear the Working Groups opinion of the > >> following question: > >>> =A0 > >>> Should we add the requirements that arise from RFC 4285 in the=20 > >>> draft-ietf-mip6-aaa-ha-goals-03? > >>> =A0 > >>> =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG=20 > meeting there=20 > >>> were 14 people for "yes" and 5 for "No". > >>> =A0 > >>> Cheers, > >>> Gopal and Raj > >>>=20 > >>> _______________________________________________ > >>> Mip6 mailing list > >>> Mip6@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 > >>=20 > >> _______________________________________________ > >> Mip6 mailing list > >> Mip6@ietf.org > >> https://www1.ietf.org/mailman/listinfo/mip6 > >>=20 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 17:58:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkThw-0001gw-LU; Wed, 15 Nov 2006 17:58:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkThv-0001gE-CW; Wed, 15 Nov 2006 17:58:15 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkThs-0006Po-O5; Wed, 15 Nov 2006 17:58:15 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8S00261NT0HU@usaga01-in.huawei.com>; Wed, 15 Nov 2006 14:58:12 -0800 (PST) Received: from N737011 (pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8S005QQNST0A@usaga01-in.huawei.com>; Wed, 15 Nov 2006 14:58:12 -0800 (PST) Date: Wed, 15 Nov 2006 14:58:07 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: To: "'Tschofenig, Hannes'" , 'Gerardo Giaretta' Message-id: <003a01c70909$84de5f30$2f01a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AccIROjOnFtEd7gWRFmXGaLfZ/cAvgAswaVgAAFngaAAArx5wA== X-Spam-Score: 0.6 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Cc: "'Gopal Dommety \(gdommety\)'" , mip6@ietf.org, "'Kent Leung \(kleung\)'" , dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Well, NO pun intended, but I am not sure what is so complicated about = this, anybody who has gone through a product cycle does a requirement first = and then the design based on the requirements... I reacted to voting on whether Dime drafts/ designs should/must support 4285, without specifying what 4285 requirements are and without = including these requirements into the generic design document. That is poor salesmanship promising something that your product may or may not do. = Comes IESG review, this will come back and bite us. Then people started voting on support of 4285 in the requirements = without specifying what 4285 needs are. >From what I understood the intention of aaa-ha goal doc is (based on = Raj's comments), it is generic and should include 4285 support (as a SHOULD, = or whatever the applicability statement says). So none of your options = below:) Then the Dime drafts can simply say that they don't support that = "SHOULD" requirements. I don't have a strong opinion on whether 4285 is very important or not, = but I think we should follow a design process, we can answer for, later. Regards, Madjid -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Wednesday, November 15, 2006 1:39 PM To: Madjid Nakhjiri; Gerardo Giaretta Cc: Gopal Dommety (gdommety); Kent Leung (kleung); mip6@ietf.org; dime@ietf.org Subject: AW: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Hi Madjid,=20 you make things quite complicated. Gerardo and myself have asked the following question to the MIP6 working group: Should draft-ietf-mip6-aaa-ha-goals-03 say something about RFC 4285? Possible answers are: a) Don't say anything about RFC 4285.=20 b) Explicitly rule out support for RFC 4285.=20 c) Explicitly support RFC 4285. =20 If draft-ietf-mip6-aaa-ha-goals-03 has to support both, RFC 4285 and IKEv2/EAP based authentication, then that's fine with us. I know that = this is not difficult todo. We just need to get the documents written in such = a way. We just thought it is better to ask before we finish the documents = and suddently get told that this was not in the scope of our work.=20 Furthermore, nobody said that draft-ietf-mip6-aaa-ha-goals-03 only = impacts the DIME work. It obviously also impacts the corresponding RADIUS work = since we are supposed to align the two designs. We just came across this issue when we worked on the Diameter document.=20 Ciao Hannes > -----Urspr=FCngliche Nachricht----- > Von: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20 > Gesendet: Mittwoch, 15. November 2006 22:19 > An: 'Gerardo Giaretta' > Cc: 'Gopal Dommety (gdommety)'; 'Kent Leung (kleung)';=20 > mip6@ietf.org; dime@ietf.org > Betreff: [Dime] RE: [Mip6] Should we add the requirements=20 > that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Hi Gerardo, >=20 >=20 > If you remember, the first time people asked this question, I=20 > said we should > simply be careful about rubber stamping the Dime drafts as=20 > supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on=20 > supporting > 4285, we should refrain from making the promise that Dime=20 > draft do too. > If we design something based on a requirement that excludes=20 > support for > 4285, then the solution has no obligation to support it either.=20 >=20 > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for=20 > both RADIUS and > Diameter. Unless you want to change the name, we need to=20 > realize that this > document can=20 > a) create requirements that RADIUS cannot meet and hence rule=20 > out RADIUS for > MIP6 support (some of the current goals related to key=20 > transport fit that > category) > b) create requirement for all AAA functionality, i.e both=20 > requirements on > AAA functionality within HA and on AAA protocol. This means=20 > if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state=20 > whether they fulfill > all requirements, including 4285 requirements. We already=20 > have two dime > drafts for two different designs. >=20 > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer=20 > seems to be yes > from your email. So the HA-AAA goals is not a generic=20 > requirement goal for > MIP6. The current HA-AAA goals document should specifically=20 > state that it is > the requirements for Diameter EAP based solutions and not for=20 > 4285 to clear > all the issues above. >=20 > Personally I think support for 4285 is a lot simpler than=20 > people think, and > might not require much more than some AVPs and look similar=20 > to 4004 for MIP4 > support in case of CCOA, but I have not done a detail=20 > analysis. If that is > true all 4285 needs in way of requirements is probably being=20 > allowed to have > some new AVPs (or possibly same as those used in MIP4).=20 >=20 > The problem of excluding these from HA-AAA goal is that you=20 > may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? >=20 > Hope THIS clarifies some more :) >=20 > Regards, >=20 > Madjid >=20 > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]=20 > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? >=20 > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. >=20 > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). >=20 > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? >=20 > I hope this clarifies. >=20 > --Gerardo >=20 > On 11/14/06, Madjid Nakhjiri wrote: > > Personally, I suspect that 4285 support simply needs a bunch of > attributes. > > I suggest people propose a couple of requirements related=20 > to 4285 support > > and after that we could easily see if those can be added to=20 > the current > set > > of goals. Once we did that we can simply say the HA-AAAH=20 > support 4285. > > > > Madjid > > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, November 14, 2006 12:08 PM > > To: Vijay Devarapalli; Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Should we add the requirements that=20 > arise from RFC > > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > > > > My vote is YES. > > > > I assume this question is intended for HA-AAA interface=20 > support for RFC > > 4285. But it would be definitely nice to have standards-based AAA > > attributes for bootstrapping in terms of completeness. > > > > Kent > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, November 14, 2006 10:26 AM > > To: Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Should we add the requirements that=20 > arise from RFC > > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > > > Gopal, > > > > lets step back a bit. what is the point of adding of 4285-specific > > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > > 4285 operation where the HA-AAAH interface is used for MN > > authentication? or does it include bootstrapping for 4285 too? > > > > will the requirements be added to > > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the=20 > requirements in > > one place with no binding to develop any solutions yet? > > > > other bootstrapping related questions, do we want to standardize > > bootstrapping solutions for 4285 too? has the DIME WG agreed to > > developing solutions for 4285-based MIP6 operation? > > > > Vijay > > > > Gopal Dommety (gdommety) wrote: > > > Hello All, > > > > > > Wanted to get the MIP6 Working groups preference on whether we > > > should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03 > > > > > > We would like to hear the Working Groups opinion of the following > > question: > > > > > > Should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03? > > > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > > were > > > 14 people for "yes" and 5 for "No". > > > > > > Cheers, > > > Gopal and Raj > > > > > > > > >=20 > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 18:08:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTry-0003BG-O0; Wed, 15 Nov 2006 18:08:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTrx-0003B5-Le for mip6@ietf.org; Wed, 15 Nov 2006 18:08:37 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkTru-00084r-F0 for mip6@ietf.org; Wed, 15 Nov 2006 18:08:37 -0500 Received: from [10.1.210.17] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 15:08:31 -0800 Message-ID: <455B9CE1.3090901@azairenet.com> Date: Wed, 15 Nov 2006 15:04:01 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Basavaraj Patil Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Nov 2006 23:08:31.0859 (UTC) FILETIME=[F8029430:01C7090A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: Gopal Dommety , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org thanks for the clarification. allow me to rephrase Gopal's question to the mailing list then. Should we add the requirements that arise from the use RFC 4285 for Mobile IPv6 in draft-ietf-mip6-aaa-ha-goals-03? This does not include RFC 4285-based bootstrapping. my answer is Yes to the above question. Vijay Basavaraj Patil wrote: > Vijay, > > Inline: > > > On 11/14/06 12:25 PM, "ext Vijay Devarapalli" > wrote: > >> Gopal, >> >> lets step back a bit. what is the point of adding >> of 4285-specific requirements in >> draft-ietf-mip6-aaa-ha-goals? is it just for basic >> 4285 operation where the HA-AAAH interface is used >> for MN authentication? or does it include >> bootstrapping for 4285 too? > > Bootstrapping for RFC4285 is not in the scope of the MIP6 WG charter at this > time and hence the AAA requirements are just for the basic 4285 operation. > >> will the requirements be added to >> draft-ietf-mip6-aaa-ha-goals-03 just to capture >> all the requirements in one place with no binding >> to develop any solutions yet? > > Yes. > >> other bootstrapping related questions, do we want >> to standardize bootstrapping solutions for 4285 >> too? has the DIME WG agreed to developing >> solutions for 4285-based MIP6 operation? > > We do not have consensus to develop bootstrapping solutions for RFC4285 mode > of operation. The view is that we do not really need to standardize such a > solution. People who are interested in using RFC4285 with MIP6 may have > their own means for bootstrapping and hence the need for the WG to specify > such bootstrapping is not essential. > > The DIME WG is working on bootstrapping solution based on the current > bootstrapping solutions in the MIP6 WG which does not include bootstrapping > for RFC4285. > > -Raj > > >> Vijay >> >> Gopal Dommety (gdommety) wrote: >>> Hello All, >>> >>> Wanted to get the MIP6 Working groups preference on whether we >>> should we add the requirements that arise from RFC 4285 in the >>> draft-ietf-mip6-aaa-ha-goals-03 >>> >>> We would like to hear the Working Groups opinion of the following question: >>> >>> Should we add the requirements that arise from RFC 4285 in the >>> draft-ietf-mip6-aaa-ha-goals-03? >>> >>> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were >>> 14 people for "yes" and 5 for "No". >>> >>> Cheers, >>> Gopal and Raj >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 18:27:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkU9z-0007ZB-Lb; Wed, 15 Nov 2006 18:27:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkU9y-0007Z5-L1 for mip6@ietf.org; Wed, 15 Nov 2006 18:27:14 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkU9w-0002FO-6n for mip6@ietf.org; Wed, 15 Nov 2006 18:27:14 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kAFNRAsW010064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Nov 2006 15:27:11 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-128.qualcomm.com [10.50.68.128]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kAFNR90f022745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Nov 2006 15:27:10 -0800 Message-Id: <7.0.1.0.2.20061115142930.065253f8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 15 Nov 2006 15:27:08 -0800 To: Mip6 issue tracker , mip6@ietf.org From: Lakshminath Dondeti Subject: Re: [Mip6] [issue87] Comment by Sam Hartman on I-D draft-ietf-mip6-location-privacy-ps In-Reply-To: <1163624998.68.0.034124653954.issue87@mip4.org> References: <1163624998.68.0.034124653954.issue87@mip4.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.1 (+) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org I reviewed the document as part of a sec-dir assignment and thought that it can use some editing to make the problem statement more crisp, but overall looks ok. It appears that there are some inconsistencies as Sam points out that need to be fixed. In the interest of making things clearer, would the following be baseline requirements (let's park the solution discussion for a little while)? 1. Hiding the home domain information of a roaming user from eavesdroppers in a visited network 2. Make it difficult, if not impossible for someone in the visited network to be able to track a roaming user in so far as mobility protocols are concerned 3. Make it difficult, if not impossible for a correspondent node from knowing the current location of a roaming user In the solution space, yes there are some solutions that allude to addressing privacy considerations, but I don't know whether all of the above requirements are possible to achieve simultaneously. It would be good to achieve that or at least make it difficult to track a roaming user even if an eavesdropper and a CN are colluding. If indeed we can conclude that everything that can be solved in mip6 location privacy has been solved, well, that'd be cool. One less thing to do. :) regards, Lakshminath At 01:09 PM 11/15/2006, admin wrote: >New submission from admin : > >Discuss: > >Even when the binding between a user > > identifier and the Home Address is unavailable, freely available > > tools on the Internet can map the Home Address to the owner of the > > Home Prefix, which can reveal that a user from a particular ISP > > has roamed. > >If the above is in scope, then the discussion of the problem is >incomplete. Sending an esp packet from ISP B to one of ISP A's HAs >really discloses as much information as the above paragraph implies. > > >I think this draft does a bad job of explaining its scope and >convincing me that the problem being solved is important to solve. >For example why are IIDs out of scope? Why is the ESP corrilation I >discuss above out of scope? If those attacks are out of scope, what >real benefit remains to hiding roaming from onlookers? > > >Finally, I do not understand what work is left to do in this space. >This draft describes the problem and points out that encrypted tunnels >and not using RO are a solution. What additional problems are being >solved beyond that? What work is there for the IETF to do in this >space? A problem statement should clearly articulate these points. > >Comment: >I agree with Lisa that this document is unclear--not quite >to the point of earning a discuss for lack of clarity--but unclear >enough that if you haven't been reading mip6 documents for a while, >you won't understand what is going on. It conflates profiling and >location privacy, and describes more than supports its conclusions. > >---------- >category: Editorial >draft: draft-ietf-mip6-location-privacy-ps >messages: 275 >nosy: admin >priority: Should fix >status: Pending >title: Comment by Sam Hartman on I-D draft-ietf-mip6-location-privacy-ps > >_________________________________________________ >Mip6 issue tracker > >_________________________________________________ > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 18:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUAe-0007hW-4M; Wed, 15 Nov 2006 18:27:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUAd-0007hR-2N for mip6@ietf.org; Wed, 15 Nov 2006 18:27:55 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkUAb-0002JI-Ht for mip6@ietf.org; Wed, 15 Nov 2006 18:27:55 -0500 Received: by ug-out-1314.google.com with SMTP id 72so275577ugd for ; Wed, 15 Nov 2006 15:27:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZvFdisbWplIceyZuSSUSsBtZMgfTf1j5FTEfn55YEbiTMIPSM7ZXjFa2Rwa9SRz5gDVx207w+2eFPIlDfIi0BwaaQUbz0LeQsX5nCKHy7kQNbAhjurRJsrNffBTcabnBKx4osYXLGfBJaWaW/p5d8ulSqDqtojV9Thr9vq3uZeo= Received: by 10.66.243.4 with SMTP id q4mr116299ugh.1163633272473; Wed, 15 Nov 2006 15:27:52 -0800 (PST) Received: by 10.66.243.16 with HTTP; Wed, 15 Nov 2006 15:27:52 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 18:27:52 -0500 From: "Gerardo Giaretta" To: "Narayanan, Vidya" Subject: Re: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: Gopal Dommety , mip6@ietf.org, Basavaraj Patil X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vidya, just one comment below.. > > > The issue of whether the docs would be ps or informational in > > this thread may not be a key factor IMO. > > > > Given the applicability statement in RFC4285, I would say that if the solution document is meant to be a PS, it should not be discussing solutions related to RFC4285. > You can have two docs in DIME WG, one Informational and one PS if the main issue is the status of the rfc, with the Informational one specifying the rfc4285-specific AVPs. I agree with Raj this should not be the key factor in the decision. --Gerardo > Vidya > > > -Raj > > > > > > On 11/15/06 3:45 PM, "ext Narayanan, Vidya" > > wrote: > > > > > Raj, > > > What is the purpose of the aaa-ha-goals document? Are the > > AAA solution > > > documents required to satisfy all the identified goals? > > Also, are the > > > AAA solution documents expected to be PS or Informational? > > > > > > I think we need to answer the above questions before we can make a > > > decision on this particular topic. > > > > > > Vidya > > > > > >> -----Original Message----- > > >> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] > > >> Sent: Wednesday, November 15, 2006 12:44 PM > > >> To: Tsirtsis, George; Gopal Dommety; mip6@ietf.org > > >> Subject: Re: [Mip6] Should we add the requirements that arise from > > >> RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? > > >> > > >> > > >> George, > > >> > > >> Let me see if I can clarify the question to the WG w.r.t the > > >> aaa-ha-goals > > >> I-D: > > >> > > >> The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended > > to capture > > >> the AAA requirements for MIP6 deployment/operation. > > >> These requirements would be fed to the appropriate AAA WGs > > >> (DIME/Radext) for developing the actual solutions or > > extensions. In > > >> some cases the MIP6 WG in conjunction with a AAA WG (such > > as Radext) > > >> can take up the work as illustrated by the I-D > > draft-ietf-mip6-radius > > >> but in others the DIME WG is working on the solutions needed for > > >> MIP6. > > >> > > >> The current version of the goals/requirements I-D does not > > consider > > >> the case when RFC4285 is used as the means for > > authenticating an MN > > >> to an HA. The AAA requirements are based strictly on the > > use of IPsec > > >> between the MN and HA. > > >> The question to the WG was whether the AAA requirements/goals > > >> document should include the requirements that MIP6 operation with > > >> RFC4285 brings. > > >> > > >> Since the AAA goals document is intended to capture all the > > >> MIP6 AAA requirements and RFC4285 is a recognized mode of > > >> MIP6 operation, it makes sense to capture the additional > > requirements > > >> at this time. > > >> > > >> Is this clear now? > > >> > > >> -Raj > > >> > > >> > > >> > > >> On 11/14/06 11:40 AM, "ext Tsirtsis, George" > > >> wrote: > > >> > > >>> Gopal, > > >>> > > >>> I am not sure I understand the question. RFC4285 defines a > > >>> mechanism/solution and an associated applicability > > >> statement. What is > > >>> it that you propose to "add" to > > >> draft-ietf-mip6-aaa-ha-goals-03 and in what form? > > >>> > > >>> I would also appreciate if people voting "yes" or "no" on this (or > > >>> any) issue, say something about why they vote one way or > > the other. > > >>> > > >>> Regards > > >>> George > > >>> ________________________________________ > > >>> From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] > > >>> Sent: Saturday, November 11, 2006 1:44 PM > > >>> To: mip6@ietf.org > > >>> Subject: [Mip6] Should we add the requirements that arise from RFC > > >>> 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? > > >>> > > >>> Hello All, > > >>> > > >>> Wanted to get the MIP6 Working groups preference on > > whether we > > >>> should we add the requirements that arise from RFC 4285 in the > > >>> draft-ietf-mip6-aaa-ha-goals-03 > > >>> > > >>> We would like to hear the Working Groups opinion of the > > >> following question: > > >>> > > >>> Should we add the requirements that arise from RFC 4285 in the > > >>> draft-ietf-mip6-aaa-ha-goals-03? > > >>> > > >>> Please answer "yes" or "no" PS: In the IETF Mip6 WG > > meeting there > > >>> were 14 people for "yes" and 5 for "No". > > >>> > > >>> Cheers, > > >>> Gopal and Raj > > >>> > > >>> _______________________________________________ > > >>> Mip6 mailing list > > >>> Mip6@ietf.org > > >>> https://www1.ietf.org/mailman/listinfo/mip6 > > >> > > >> > > >> _______________________________________________ > > >> Mip6 mailing list > > >> Mip6@ietf.org > > >> https://www1.ietf.org/mailman/listinfo/mip6 > > >> > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 18:32:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUEP-0008Ju-Kd; Wed, 15 Nov 2006 18:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkUEN-0008I3-Ih for mip6@ietf.org; Wed, 15 Nov 2006 18:31:47 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkUEM-0002zg-SB for mip6@ietf.org; Wed, 15 Nov 2006 18:31:47 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAFNV05b007974; Thu, 16 Nov 2006 01:31:42 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 01:31:37 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 17:31:35 -0600 Received: from 172.19.244.84 ([172.19.244.84]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Wed, 15 Nov 2006 23:31:34 +0000 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Wed, 15 Nov 2006 17:31:49 -0600 Subject: Re: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? From: Basavaraj Patil To: "ext Narayanan, Vidya" , "Tsirtsis, George" , Gopal Dommety , Message-ID: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8AAflzMAAAtJrwAAGXufAAAZJO8A== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 15 Nov 2006 23:31:35.0291 (UTC) FILETIME=[30998CB0:01C7090E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Inline: On 11/15/06 4:57 PM, "ext Narayanan, Vidya" wrote: > Hi Raj, >=20 >>=20 >> Hi Vidya, >>=20 >> In case I was not clear enough in my earlier email (below), >> let me reiterate that the purpose of the aaa-ha-goals >> document is to capture all the AAA requirements that the MIP6 >> WG believes exist for MIP6 deployment and operation. >> The AAA solutions developed in DIME or Radext or within the >> MIP6 WG (working with the appropriate AAA WG) may or may not >> address all the requirements. >> And that is an acceptable situation. Of course I would think >> there would be some valid reasons why a requirement would not >> be addressed. >>=20 >=20 > This is somewhat ambiguous. I would imagine that the goals are written to= be > met. Otherwise, there needs to be classifications in the goals such that = there > is a set that a solution MUST meet in order for it to be useful. Without = that, > there doesn't seem to be a way to evaluate the solution. Hmmm... Not sure what you believe is ambiguous. Requirements are specified to be met. What I implied was that the requirements that this document will specify may already have solutions and in some cases the requirement may be invalid when analyzed by a AAA expert. The authors/editor of the document while making every effort to specify requirements that will be met may potentially also specify some which may o= r may not be met. But there is no reason why the rqeuirements specification have to foresee the solution and if and how it will be met. That would only hamper the development of the requirements. I don't think that we will have a problem in verifying if the solution meet= s the rqeuirement. At least from reading the current document, I don't see that as a problem.=20 >=20 >> The AAA solutions documents may be PS or Informational. I >> think that in several instances the solution would simply be >> a reference to existing AAA RFCs which already specify the >> attributes or AVPs and hence such documents could just be >> informational because they would only specify how MIP6 would >> work with a AAA framework and reuses existing specs. But in >> cases wherein there is new attributes, extensions, messages >> or applications defined, they would be considered for >> publication as ps docs. >=20 > This is also ambiguous. I don't think it matters whether the solution doc= ument > is pointing to a whole bunch of existing attributes or defining new ones.= It > would make sense to be a PS, if that is required for MIP6 operation in > AAA-based networks. Depends. If a document simply refers to an existing AAA specification and only explains how that is applied in the context of MIP6, it may be published as an Informational document. But we can decide what status a solution needs to be assigned at a later stage. >=20 >> The issue of whether the docs would be ps or informational in >> this thread may not be a key factor IMO. >>=20 >=20 > Given the applicability statement in RFC4285, I would say that if the sol= ution > document is meant to be a PS, it should not be discussing solutions relat= ed to > RFC4285.=20 There could be more than one solution document. And yes, if the solution document addresses RFC4285 requirements, then we do have the issue of pursuing it on the ps track. -Raj >=20 > Vidya >=20 >> -Raj >>=20 >>=20 >> On 11/15/06 3:45 PM, "ext Narayanan, Vidya" >> wrote: >>=20 >>> Raj, >>> What is the purpose of the aaa-ha-goals document? Are the >> AAA solution=20 >>> documents required to satisfy all the identified goals? >> Also, are the=20 >>> AAA solution documents expected to be PS or Informational? >>>=20 >>> I think we need to answer the above questions before we can make a >>> decision on this particular topic. >>>=20 >>> Vidya >>>=20 >>>> -----Original Message----- >>>> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com] >>>> Sent: Wednesday, November 15, 2006 12:44 PM >>>> To: Tsirtsis, George; Gopal Dommety; mip6@ietf.org >>>> Subject: Re: [Mip6] Should we add the requirements that arise from >>>> RFC4285 in the draft-ietf-mip6-aaa-ha-goals-03? >>>>=20 >>>>=20 >>>> George, >>>>=20 >>>> Let me see if I can clarify the question to the WG w.r.t the >>>> aaa-ha-goals >>>> I-D: >>>>=20 >>>> The MIP6 WG I-D draft-ietf-mip6-aaa-ha-goals is intended >> to capture=20 >>>> the AAA requirements for MIP6 deployment/operation. >>>> These requirements would be fed to the appropriate AAA WGs >>>> (DIME/Radext) for developing the actual solutions or >> extensions. In=20 >>>> some cases the MIP6 WG in conjunction with a AAA WG (such >> as Radext)=20 >>>> can take up the work as illustrated by the I-D >> draft-ietf-mip6-radius >>>> but in others the DIME WG is working on the solutions needed for >>>> MIP6. >>>>=20 >>>> The current version of the goals/requirements I-D does not >> consider=20 >>>> the case when RFC4285 is used as the means for >> authenticating an MN >>>> to an HA. The AAA requirements are based strictly on the >> use of IPsec=20 >>>> between the MN and HA. >>>> The question to the WG was whether the AAA requirements/goals >>>> document should include the requirements that MIP6 operation with >>>> RFC4285 brings. >>>>=20 >>>> Since the AAA goals document is intended to capture all the >>>> MIP6 AAA requirements and RFC4285 is a recognized mode of >>>> MIP6 operation, it makes sense to capture the additional >> requirements=20 >>>> at this time. >>>>=20 >>>> Is this clear now? >>>>=20 >>>> -Raj >>>>=20 >>>>=20 >>>>=20 >>>> On 11/14/06 11:40 AM, "ext Tsirtsis, George" >>>> wrote: >>>>=20 >>>>> Gopal, >>>>>=20 >>>>> I am not sure I understand the question. RFC4285 defines a >>>>> mechanism/solution and an associated applicability >>>> statement. What is >>>>> it that you propose to "add" to >>>> draft-ietf-mip6-aaa-ha-goals-03 and in what form? >>>>>=20 >>>>> I would also appreciate if people voting "yes" or "no" on this (or >>>>> any) issue, say something about why they vote one way or >> the other. >>>>>=20 >>>>> Regards >>>>> George >>>>> ________________________________________ >>>>> From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com] >>>>> Sent: Saturday, November 11, 2006 1:44 PM >>>>> To: mip6@ietf.org >>>>> Subject: [Mip6] Should we add the requirements that arise from RFC >>>>> 4285 inthe draft-ietf-mip6-aaa-ha-goals-03? >>>>>=20 >>>>> Hello All, >>>>> =A0 >>>>> =A0=A0=A0 Wanted to get the MIP6 Working groups preference on >> whether we=20 >>>>> should we add the requirements that arise from RFC 4285 in the >>>>> draft-ietf-mip6-aaa-ha-goals-03 >>>>> =A0 >>>>> We would like to hear the Working Groups opinion of the >>>> following question: >>>>> =A0 >>>>> Should we add the requirements that arise from RFC 4285 in the >>>>> draft-ietf-mip6-aaa-ha-goals-03? >>>>> =A0 >>>>> =A0Please answer "yes" or "no" PS: In the IETF Mip6 WG >> meeting there=20 >>>>> were 14 people for "yes" and 5 for "No". >>>>> =A0 >>>>> Cheers, >>>>> Gopal and Raj >>>>>=20 >>>>> _______________________________________________ >>>>> Mip6 mailing list >>>>> Mip6@ietf.org >>>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>>=20 >>=20 >>=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 15 23:44:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkZ5t-0002wB-8T; Wed, 15 Nov 2006 23:43:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkZ5q-0002tO-Kq for mip6@ietf.org; Wed, 15 Nov 2006 23:43:18 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkZ5p-0000U3-3A for mip6@ietf.org; Wed, 15 Nov 2006 23:43:18 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAG4h7KD027616; Thu, 16 Nov 2006 06:43:13 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 06:43:08 +0200 Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 06:43:08 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Should we add the requirements that arise from RFC4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Date: Thu, 16 Nov 2006 06:43:08 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC4285 inthe draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFMbifAADjkus8AAflzMAAOtFHg From: To: , X-OriginalArrivalTime: 16 Nov 2006 04:43:09.0003 (UTC) FILETIME=[B6EBA1B0:01C70939] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061116064313-6B61CBB0-6B932EC9/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vidya, >What is the purpose of the aaa-ha-goals document? Are the AAA=20 >solution documents required to satisfy all the identified=20 >goals? Also, are the AAA solution documents expected to be PS=20 >or Informational?=20 > >I think we need to answer the above questions before we can=20 >make a decision on this particular topic.=20 Speaking as DiME co-chair, we need a requirements document so=20 that we can be sure that we design a solution that meets the needs of the MIPv6 WG. The solution will be PS. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 17 10:21:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl5WF-0007SC-MI; Fri, 17 Nov 2006 10:20:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk4Zh-0008Bx-VB for mip6@ietf.org; Tue, 14 Nov 2006 15:08:05 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk4Zg-0003q9-4p for mip6@ietf.org; Tue, 14 Nov 2006 15:08:05 -0500 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAEK81309926; Tue, 14 Nov 2006 15:08:01 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Date: Tue, 14 Nov 2006 14:07:30 -0600 Message-ID: In-Reply-To: <62B9B0847CC47543B6B3B5E26BD268E60B5F6794@zrc2hxm2.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccC4YzvjU4CBanBTfaaDZOjY6wJTwFLzXUAAACTHlAAAAP/AAAEyi5w From: "Haseeb Akhtar" To: X-Spam-Score: 0.6 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 X-Mailman-Approved-At: Fri, 17 Nov 2006 10:20:41 -0500 Cc: Gopal Dommety X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1941947841==" Errors-To: mip6-bounces@ietf.org This is a multi-part message in MIME format. --===============1941947841== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70828.83D24CA8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70828.83D24CA8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable YES. =20 Regards, =20 Haseeb=20 ________________________________ From: Gopal Dommety (gdommety) [mailto:gdommety@cisco.com]=20 Sent: Saturday, November 11, 2006 12:44 PM To: mip6@ietf.org Subject: [Mip6] Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =09 =09 Hello All, =20 Wanted to get the MIP6 Working groups preference on whether we should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03 =20 We would like to hear the Working Groups opinion of the following question: =20 Should we add the requirements that arise from RFC 4285 in the draft-ietf-mip6-aaa-ha-goals-03? =20 Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people for "yes" and 5 for "No". =20 =09 =09 Cheers, Gopal and Raj ------_=_NextPart_001_01C70828.83D24CA8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
YES.
 
Regards,
 
Haseeb 

From: Gopal Dommety (gdommety)=20 [mailto:gdommety@cisco.com]
Sent: Saturday, November 11, = 2006=20 12:44 PM
To: mip6@ietf.org
Subject: [Mip6] = Should we add=20 the requirements that arise from RFC 4285 in the=20 draft-ietf-mip6-aaa-ha-goals-03?

Hello=20 All,
 
    Wanted to get the MIP6 = Working=20 groups preference on whether we should we add the = requirements that arise from RFC 4285 in = the  =20 draft-ietf-mip6-aaa-ha-goals-03
 
We = would like to=20 hear the Working Groups opinion of the following=20 question:
 
Should = we add the=20 requirements that arise from RFC 4285 in the =20 = draft-ietf-mip6-aaa-ha-goals-03?
=
 
 Please answer=20 "yes" or "no" PS: In the IETF Mip6 WG meeting there were 14 people = for "yes"=20 and 5 for "No".
 
Cheers,
Gopal and=20 Raj
=00 ------_=_NextPart_001_01C70828.83D24CA8-- --===============1941947841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1941947841==-- From mip6-bounces@ietf.org Fri Nov 17 11:01:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl68t-0003NB-HY; Fri, 17 Nov 2006 11:00:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl68r-0003MU-Dl for mip6@ietf.org; Fri, 17 Nov 2006 11:00:38 -0500 Received: from ug-out-1314.google.com ([66.249.92.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl68a-00068C-Pj for mip6@ietf.org; Fri, 17 Nov 2006 11:00:37 -0500 Received: by ug-out-1314.google.com with SMTP id 72so670042ugd for ; Fri, 17 Nov 2006 08:00:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=t/4/r5E7JlIVbvb4KLsojBXHiskW2NrJvPur4NB7Z5dsuufK0lXOfHMxPPnO3MRljSCXTspW2LneYJw+0tIWdfOwNOsDiygMMpedfuBTDXK/47gC4w1WdRlTY721ZnY4kM3H9wWz7A8AYMuhl0ffe9H7gmDgzFbiU5kB4k7EIXI= Received: by 10.66.221.6 with SMTP id t6mr2296225ugg.1163779217122; Fri, 17 Nov 2006 08:00:17 -0800 (PST) Received: by 10.66.216.9 with HTTP; Fri, 17 Nov 2006 08:00:16 -0800 (PST) Message-ID: <5e2406980611170800u625edd31x382ce18459c258fe@mail.gmail.com> Date: Fri, 17 Nov 2006 17:00:16 +0100 From: "Julien Bournelle" To: "Madjid Nakhjiri" Subject: Re: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-Reply-To: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002201c708fb$afef0840$2f01a8c0@china.huawei.com> X-Spam-Score: 0.6 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: "Gopal Dommety \(gdommety\)" , "Kent Leung \(kleung\)" , dime@ietf.org, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi madjid, all, On 11/15/06, Madjid Nakhjiri wrote: > Hi Gerardo, > > > If you remember, the first time people asked this question, I said we should > simply be careful about rubber stamping the Dime drafts as supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on supporting > 4285, we should refrain from making the promise that Dime draft do too. > If we design something based on a requirement that excludes support for > 4285, then the solution has no obligation to support it either. can't we have requirements for 4285 in aaa-ha-goals and have separate AAA solutions for IPsec and 4285 case ? > > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for both RADIUS and > Diameter. Unless you want to change the name, we need to realize that this > document can > a) create requirements that RADIUS cannot meet and hence rule out RADIUS for > MIP6 support (some of the current goals related to key transport fit that > category) what do you propose ? > b) create requirement for all AAA functionality, i.e both requirements on > AAA functionality within HA and on AAA protocol. This means if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state whether they fulfill > all requirements, including 4285 requirements. We already have two dime > drafts for two different designs. > > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer seems to be yes > from your email. So the HA-AAA goals is not a generic requirement goal for > MIP6. The current HA-AAA goals document should specifically state that it is > the requirements for Diameter EAP based solutions and not for 4285 to clear > all the issues above. this was not the intention. > > Personally I think support for 4285 is a lot simpler than people think, and > might not require much more than some AVPs and look similar to 4004 for MIP4 > support in case of CCOA, but I have not done a detail analysis. If that is > true all 4285 needs in way of requirements is probably being allowed to have > some new AVPs (or possibly same as those used in MIP4). > > The problem of excluding these from HA-AAA goal is that you may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? For the Diameter case, I think we may need another application to support 4285. But i don't think that the problem of the mip6 WG. I think we could have some requirements for 4285 in aaa-ha-goals and then it's up to related AAA groups to deal with that. regards, Julien > > Hope THIS clarifies some more :) > > Regards, > > Madjid > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. > > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). > > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? > > I hope this clarifies. > > --Gerardo > > On 11/14/06, Madjid Nakhjiri wrote: > > Personally, I suspect that 4285 support simply needs a bunch of > attributes. > > I suggest people propose a couple of requirements related to 4285 support > > and after that we could easily see if those can be added to the current > set > > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > > > Madjid > > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, November 14, 2006 12:08 PM > > To: Vijay Devarapalli; Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > > > > My vote is YES. > > > > I assume this question is intended for HA-AAA interface support for RFC > > 4285. But it would be definitely nice to have standards-based AAA > > attributes for bootstrapping in terms of completeness. > > > > Kent > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, November 14, 2006 10:26 AM > > To: Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > > > Gopal, > > > > lets step back a bit. what is the point of adding of 4285-specific > > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > > 4285 operation where the HA-AAAH interface is used for MN > > authentication? or does it include bootstrapping for 4285 too? > > > > will the requirements be added to > > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > > one place with no binding to develop any solutions yet? > > > > other bootstrapping related questions, do we want to standardize > > bootstrapping solutions for 4285 too? has the DIME WG agreed to > > developing solutions for 4285-based MIP6 operation? > > > > Vijay > > > > Gopal Dommety (gdommety) wrote: > > > Hello All, > > > > > > Wanted to get the MIP6 Working groups preference on whether we > > > should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03 > > > > > > We would like to hear the Working Groups opinion of the following > > question: > > > > > > Should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03? > > > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > > were > > > 14 people for "yes" and 5 for "No". > > > > > > Cheers, > > > Gopal and Raj > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 17 11:13:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6LO-0001Ei-DA; Fri, 17 Nov 2006 11:13:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl6LM-0001EU-W8; Fri, 17 Nov 2006 11:13:33 -0500 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl6LI-0007gk-5a; Fri, 17 Nov 2006 11:13:32 -0500 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J8V00KR7UED9V@usaga01-in.huawei.com>; Fri, 17 Nov 2006 08:13:25 -0800 (PST) Received: from N737011 (c-24-17-254-79.hsd1.mn.comcast.net [24.17.254.79]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J8V00BDQUE64C@usaga01-in.huawei.com>; Fri, 17 Nov 2006 08:13:25 -0800 (PST) Date: Fri, 17 Nov 2006 08:13:17 -0800 From: Madjid Nakhjiri Subject: RE: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? In-reply-to: <5e2406980611170800u625edd31x382ce18459c258fe@mail.gmail.com> To: 'Julien Bournelle' Message-id: <002301c70a63$4bc12e20$02fda8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AccKYX5G9ERyUGnZTcuPa2bxg1xEzQAAMVCQ X-Spam-Score: 0.6 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: "'Gopal Dommety \(gdommety\)'" , "'Kent Leung \(kleung\)'" , mip6@ietf.org, dime@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Julien, -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@gmail.com] Sent: Friday, November 17, 2006 8:00 AM To: Madjid Nakhjiri Cc: Gerardo Giaretta; Gopal Dommety (gdommety); Kent Leung (kleung); mip6@ietf.org; dime@ietf.org Subject: Re: [Dime] RE: [Mip6] Should we add the requirements that arise from RFC 4285inthe draft-ietf-mip6-aaa-ha-goals-03? Hi madjid, all, On 11/15/06, Madjid Nakhjiri wrote: > Hi Gerardo, > > > If you remember, the first time people asked this question, I said we should > simply be careful about rubber stamping the Dime drafts as supporting 4285. > Unless the HA-AAA goal doc includes specific requirements on supporting > 4285, we should refrain from making the promise that Dime draft do too. > If we design something based on a requirement that excludes support for > 4285, then the solution has no obligation to support it either. can't we have requirements for 4285 in aaa-ha-goals and have separate AAA solutions for IPsec and 4285 case ? Madjid>>Absolutely, especially if the requirement for 4285 support is not MUST, and from Raj that seems to be the case. However, the 4285 experts should add a few words about what these requirements are. > > I am going to reiterate all my points. > 1) "AAA goal/requirement document" means requirements for both RADIUS and > Diameter. Unless you want to change the name, we need to realize that this > document can > a) create requirements that RADIUS cannot meet and hence rule out RADIUS for > MIP6 support (some of the current goals related to key transport fit that > category) what do you propose ? Madjid>>I am proposing to the remove the goal that requires secure key transport (I had a discussion on that with Gerarado already, I believe it was called a general goal) and just leave the note in the security consideration section. That way, RADIUS is not ruled out unintentionally. > b) create requirement for all AAA functionality, i.e both requirements on > AAA functionality within HA and on AAA protocol. This means if an HA works > according to 4285, then the document needs to include requirement for > supporting 4285 as well. Dime drafts can come and state whether they fulfill > all requirements, including 4285 requirements. We already have two dime > drafts for two different designs. > > Currently, the document seemed to be treated as "requirement for Dime > bootstrapping drafts". Is that the intention? The answer seems to be yes > from your email. So the HA-AAA goals is not a generic requirement goal for > MIP6. The current HA-AAA goals document should specifically state that it is > the requirements for Diameter EAP based solutions and not for 4285 to clear > all the issues above. this was not the intention. Madjid>> seems to be the outcome:) > > Personally I think support for 4285 is a lot simpler than people think, and > might not require much more than some AVPs and look similar to 4004 for MIP4 > support in case of CCOA, but I have not done a detail analysis. If that is > true all 4285 needs in way of requirements is probably being allowed to have > some new AVPs (or possibly same as those used in MIP4). > > The problem of excluding these from HA-AAA goal is that you may need a new > Diameter MIP6 App ID for 4285, if the AVPs are brand new? For the Diameter case, I think we may need another application to support 4285. But i don't think that the problem of the mip6 WG. I think we could have some requirements for 4285 in aaa-ha-goals and then it's up to related AAA groups to deal with that. Madjid>>Again, I feel that only AVPs are needed, but I am not sure. We (people who want 4285) need to look closely and see whether these AVPs can be supported by 4004 or by the future RFCs supporting IKEv2 solutions. If it turns out we need mandatory AVPs that cannot be supported by these RFCs that we need a new Diameter application. And yes, all this means the work is to be done in Dime, if there is enough interest. Regards, Madjid regards, Julien > > Hope THIS clarifies some more :) > > Regards, > > Madjid > > -----Original Message----- > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com] > Sent: Tuesday, November 14, 2006 3:31 PM > To: Madjid Nakhjiri > Cc: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety); > mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > Current work in DIME WG is based on rfc3775/3776 and on the IPsec > bootstrapping solution. This has lead so far to a re-use of rfc4072 > for EAP packets transport between HA and AAAH and STR/STA/ASR/ASR > re-use for the session management. > > This means that in case rfc4285 is used, the Diameter application we > are designing cannot be used. The session management and authorization > part can be kept the same, but there would be a need to specify how > the HA authenticates the BUs in case of dynamic keying (something > similar to MIP4 approach). > > So the question is: should the AAA requirements doc (and consequently > the DIME solution - but this is a question for DIME WG) list also that > the HA-AAA communication may be able to bootstrap and authenticate > rfc4285 security associations? > > I hope this clarifies. > > --Gerardo > > On 11/14/06, Madjid Nakhjiri wrote: > > Personally, I suspect that 4285 support simply needs a bunch of > attributes. > > I suggest people propose a couple of requirements related to 4285 support > > and after that we could easily see if those can be added to the current > set > > of goals. Once we did that we can simply say the HA-AAAH support 4285. > > > > Madjid > > > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Tuesday, November 14, 2006 12:08 PM > > To: Vijay Devarapalli; Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Should we add the requirements that arise from RFC > > 4285inthe draft-ietf-mip6-aaa-ha-goals-03? > > > > > > My vote is YES. > > > > I assume this question is intended for HA-AAA interface support for RFC > > 4285. But it would be definitely nice to have standards-based AAA > > attributes for bootstrapping in terms of completeness. > > > > Kent > > > > -----Original Message----- > > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > > Sent: Tuesday, November 14, 2006 10:26 AM > > To: Gopal Dommety (gdommety) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > > 4285in the draft-ietf-mip6-aaa-ha-goals-03? > > > > Gopal, > > > > lets step back a bit. what is the point of adding of 4285-specific > > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > > 4285 operation where the HA-AAAH interface is used for MN > > authentication? or does it include bootstrapping for 4285 too? > > > > will the requirements be added to > > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements in > > one place with no binding to develop any solutions yet? > > > > other bootstrapping related questions, do we want to standardize > > bootstrapping solutions for 4285 too? has the DIME WG agreed to > > developing solutions for 4285-based MIP6 operation? > > > > Vijay > > > > Gopal Dommety (gdommety) wrote: > > > Hello All, > > > > > > Wanted to get the MIP6 Working groups preference on whether we > > > should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03 > > > > > > We would like to hear the Working Groups opinion of the following > > question: > > > > > > Should we add the requirements that arise from RFC 4285 in the > > > draft-ietf-mip6-aaa-ha-goals-03? > > > > > > Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there > > > were > > > 14 people for "yes" and 5 for "No". > > > > > > Cheers, > > > Gopal and Raj > > > > > > > > > ---------------------------------------------------------------------- > > > -- > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www1.ietf.org/mailman/listinfo/dime > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Nov 17 13:47:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8jD-0001uv-52; Fri, 17 Nov 2006 13:46:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl8jB-0001uk-Md for mip6@ietf.org; Fri, 17 Nov 2006 13:46:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl8iw-0001UD-2v for mip6@ietf.org; Fri, 17 Nov 2006 13:46:17 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2006 10:46:02 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id kAHIk1Nm017135; Fri, 17 Nov 2006 10:46:01 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kAHIjvj0023256; Fri, 17 Nov 2006 10:46:01 -0800 (PST) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Nov 2006 10:45:58 -0800 X-Mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? Date: Fri, 17 Nov 2006 10:45:56 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202DFC70F@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? Thread-Index: AccIHFSSBlUgJtl+SoWX2OC6YWqsAwADB4JAADUnxnYAXsybsA== From: "Kent Leung \(kleung\)" To: "Basavaraj Patil" , "Vijay Devarapalli" , "Gopal Dommety \(gdommety\)" X-OriginalArrivalTime: 17 Nov 2006 18:45:58.0526 (UTC) FILETIME=[9F1E39E0:01C70A78] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3434; t=1163789161; x=1164653161; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=20=22Kent=20Leung=20\(kleung\)=22=20 |Subject:=20RE=3A=20[Mip6]=20Should=20we=20add=20the=20requirements=20tha t=20arise=20from=20RFC=204285in=20the=20draft-ietf-mip6-aaa-ha-goals-03? |Sender:=20; bh=to4het4QgL4GAaN5NrCqFO0P1bFLwn/aYZUWb5RvLuI=; b=VXqz30o0za9bxCtspjAgNtB/0xiST28t9Chs2mdGIXneoYI0D1OniP/PU4ki9oI2MPcwushq ybflkhqhZ3pTgaXtZYrUjf959aom7KO5pfzeREXG1qPYLqPsvUmtLEoR; Authentication-Results: sj-dkim-3; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Raj. Just to clarify that the bootstrapping mechanism described in draft-devarapalli-mip6-authprotocol-bootstrap-01.txt does affect the HA-AAA interface. I agree that the requirements are limited to the HA-AAA interface, definitely. Kent -----Original Message----- From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]=20 Sent: Wednesday, November 15, 2006 1:29 PM To: Kent Leung (kleung); Vijay Devarapalli; Gopal Dommety (gdommety) Cc: mip6@ietf.org Subject: Re: [Mip6] Should we add the requirements that arise from RFC 4285in the draft-ietf-mip6-aaa-ha-goals-03? Kent, I would just like to emphasize here that the requirements that we want to consider adding to the AAA-goals document has nothing to do with bootstrapping when using RFC4285 with MIP6. Rather, the requirements would be the ones that are limited to the interaction between the HA and the AAA when RFC4285 is used. -Raj On 11/14/06 2:08 PM, "ext Kent Leung (kleung)" wrote: >=20 > My vote is YES. >=20 > I assume this question is intended for HA-AAA interface support for=20 > RFC 4285. But it would be definitely nice to have standards-based AAA > attributes for bootstrapping in terms of completeness. >=20 > Kent >=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, November 14, 2006 10:26 AM > To: Gopal Dommety (gdommety) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Should we add the requirements that arise from RFC > 4285in the draft-ietf-mip6-aaa-ha-goals-03? >=20 > Gopal, >=20 > lets step back a bit. what is the point of adding of 4285-specific=20 > requirements in draft-ietf-mip6-aaa-ha-goals? is it just for basic > 4285 operation where the HA-AAAH interface is used for MN=20 > authentication? or does it include bootstrapping for 4285 too? >=20 > will the requirements be added to > draft-ietf-mip6-aaa-ha-goals-03 just to capture all the requirements=20 > in one place with no binding to develop any solutions yet? >=20 > other bootstrapping related questions, do we want to standardize=20 > bootstrapping solutions for 4285 too? has the DIME WG agreed to=20 > developing solutions for 4285-based MIP6 operation? >=20 > Vijay >=20 > Gopal Dommety (gdommety) wrote: >> Hello All, >> =20 >> Wanted to get the MIP6 Working groups preference on whether we=20 >> should we add the requirements that arise from RFC 4285 in the >> draft-ietf-mip6-aaa-ha-goals-03 >> =20 >> We would like to hear the Working Groups opinion of the following > question: >> =20 >> Should we add the requirements that arise from RFC 4285 in the=20 >> draft-ietf-mip6-aaa-ha-goals-03? >> =20 >> Please answer "yes" or "no" PS: In the IETF Mip6 WG meeting there=20 >> were >> 14 people for "yes" and 5 for "No". >> =20 >> Cheers, >> Gopal and Raj >>=20 >>=20 >> --------------------------------------------------------------------- >> - >> -- >>=20 >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 18 00:17:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlIYb-0007RD-Vi; Sat, 18 Nov 2006 00:16:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlIYa-0007R6-Qs for mip6@ietf.org; Sat, 18 Nov 2006 00:16:00 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlIYW-0002b1-8z for mip6@ietf.org; Sat, 18 Nov 2006 00:16:00 -0500 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id kAI5FqWe005605 for ; Sat, 18 Nov 2006 13:15:53 +0800 (SGT) Received: from newpascal.lit.org.sg ([192.122.134.77]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id kAI5Fqob005579 for ; Sat, 18 Nov 2006 13:15:52 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.09 (built Dec 14 2004)) with ESMTP id <0J8W00CEKUMH7O30@mailhost.lit.org.sg> for mip6@ietf.org; Sat, 18 Nov 2006 13:15:53 +0800 (SGT) Received: from mailfe01.teak.local.net ([192.122.134.9]) by mailbe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 13:15:14 +0800 Received: from DELL9150 ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 13:15:14 +0800 Date: Sat, 18 Nov 2006 13:16:05 +0800 From: QIU Ying Subject: Re: [Mip6] [issue87] Comment by Sam Hartman on I-D draft-ietf-mip6-location-privacy-ps To: tracker-mip6@mip4.org, mip6@ietf.org Message-id: <0dac01c70ad0$a5bcaef0$ba89a8c0@DELL9150> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-OriginalArrivalTime: 18 Nov 2006 05:15:14.0491 (UTC) FILETIME=[876D48B0:01C70AD0] X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: "Qiu, Ying" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, My 2cents are inline > Discuss: >>Even when the binding between a user >> identifier and the Home Address is unavailable, freely available >> tools on the Internet can map the Home Address to the owner of the >> Home Prefix, which can reveal that a user from a particular ISP >> has roamed. > > If the above is in scope, then the discussion of the problem is > incomplete. Sending an esp packet from ISP B to one of ISP A's HAs > really discloses as much information as the above paragraph implies. Yes, it is. We proposed a scheme to protect the ESP's SPI in draft-irtf-mobopts-location-privacy-solutions. > > I think this draft does a bad job of explaining its scope and > convincing me that the problem being solved is important to solve. > For example why are IIDs out of scope? Why is the ESP corrilation I > discuss above out of scope? If those attacks are out of scope, what > real benefit remains to hiding roaming from onlookers? Maybe Rajeev is the right person to respond this question. But for my understanding, all of above mentioned attacks are considered in both -ps and -solutions drafts. For example, pseudo home address is used to hide the real home address, variable SPI is used to prevent the SPI profiling. > > Finally, I do not understand what work is left to do in this space. Woo, it left the following work to its brother, a 37-page ongoing document: draft-irtf-mobopts-location-privacy-solutions :-) > > This draft describes the problem and points out that encrypted tunnels > and not using RO are a solution. What additional problems are being > solved beyond that? What work is there for the IETF to do in this > space? A problem statement should clearly articulate these points. No, using encrypted tunnels does not mean to omit the RO. Protecting the location privacy in RO mode is the most important target of this issue. The encrypted tunneling scheme is used only when the CN is initiator and MN wants to hide its movement. > > Comment: > I agree with Lisa that this document is unclear--not quite > to the point of earning a discuss for lack of clarity--but unclear > enough that if you haven't been reading mip6 documents for a while, > you won't understand what is going on. It conflates profiling and > location privacy, and describes more than supports its conclusions. Profiling is large topic. Here we just limited our scope in IP layer. We try our best to prevent profiling attacks in IP layer, such as seq#, SPI, interval of binding update, etc. Any suggestion and comments on the profiling in IP layer are appreciated. Regards Qiu Ying > > ---------- > category: Editorial > draft: draft-ietf-mip6-location-privacy-ps > messages: 275 > nosy: admin > priority: Should fix > status: Pending > title: Comment by Sam Hartman on I-D draft-ietf-mip6-location-privacy-ps > ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 18 00:49:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlJ4V-0004oh-SL; Sat, 18 Nov 2006 00:48:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlJ4U-0004oc-JK for mip6@ietf.org; Sat, 18 Nov 2006 00:48:58 -0500 Received: from rodin.i2r.a-star.edu.sg ([192.122.139.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlJ4R-0003Yh-WF for mip6@ietf.org; Sat, 18 Nov 2006 00:48:58 -0500 Received: from rodin.i2r.a-star.edu.sg (localhost [127.0.0.1]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id kAI5mnrl013802 for ; Sat, 18 Nov 2006 13:48:49 +0800 (SGT) Received: from newpascal.lit.org.sg ([192.122.134.77]) by rodin.i2r.a-star.edu.sg (8.13.1/8.13.1) with ESMTP id kAI5mhg2013751 for ; Sat, 18 Nov 2006 13:48:48 +0800 (SGT) Received: from mailbe01.teak.local.net ([192.122.134.10]) by mailhost.lit.org.sg (Sun Java System Messaging Server 6.1 HotFix 0.09 (built Dec 14 2004)) with ESMTP id <0J8W00C0MW577P30@mailhost.lit.org.sg> for mip6@ietf.org; Sat, 18 Nov 2006 13:48:43 +0800 (SGT) Received: from mailfe01.teak.local.net ([192.122.134.9]) by mailbe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 13:48:05 +0800 Received: from DELL9150 ([192.168.137.186]) by mailfe01.teak.local.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 13:48:05 +0800 Date: Sat, 18 Nov 2006 13:48:56 +0800 From: QIU Ying Subject: Re: [Mip6] [issue87] Comment by Sam Hartman on I-D draft-ietf-mip6-location-privacy-ps To: ldondeti@qualcomm.com, mip6@ietf.org, tracker-mip6@mip4.org Message-id: <0dba01c70ad5$3c760db0$ba89a8c0@DELL9150> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=Windows-1252; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-OriginalArrivalTime: 18 Nov 2006 05:48:05.0256 (UTC) FILETIME=[1E182880:01C70AD5] X-Spam-Score: 1.1 (+) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi, Lakshminath Just for your interesting, your mentioned requirement is solved in draft-irtf-mobopts-location-privacy-solutions. 1. use pseudo home address to hiding the home domain information of a roaming user from eavesdroppers no mater the eavesdroppers is in the visiting network or in the traffic path. 2. no same (or expectable value) parameters appear in the clear text in any packets in order to make someone in the visited network not to be able to track a roaming user. 3. use security tunnel to make a correspondent node impossible to know the current location of a roaming user. If the CN does not have to know the MN's real ID, a pseudo HoA and RO mode can also meet the requirement. Regards Qiu Ying > Date: Wed, 15 Nov 2006 15:27:08 -0800 > From: Lakshminath Dondeti > Subject: Re: [Mip6] [issue87] Comment by Sam Hartman on I-D > draft-ietf-mip6-location-privacy-ps > To: Mip6 issue tracker , mip6@ietf.org > > I reviewed the document as part of a sec-dir assignment and thought > that it can use some editing to make the problem statement more > crisp, but overall looks ok. It appears that there are some > inconsistencies as Sam points out that need to be fixed. > > In the interest of making things clearer, would the following be > baseline requirements (let's park the solution discussion for a little > while)? > > 1. Hiding the home domain information of a roaming user from > eavesdroppers in a visited network > 2. Make it difficult, if not impossible for someone in the visited > network to be able to track a roaming user in so far as mobility > protocols are concerned > 3. Make it difficult, if not impossible for a correspondent node from > knowing the current location of a roaming user > > In the solution space, yes there are some solutions that allude to > addressing privacy considerations, but I don't know whether all of > the above requirements are possible to achieve simultaneously. It > would be good to achieve that or at least make it difficult to track > a roaming user even if an eavesdropper and a CN are colluding. > > If indeed we can conclude that everything that can be solved in mip6 > location privacy has been solved, well, that'd be cool. One less > thing to do. :) > > regards, > Lakshminath > > At 01:09 PM 11/15/2006, admin wrote: > >>New submission from admin : >> >>Discuss: >> >Even when the binding between a user >> > identifier and the Home Address is unavailable, freely available >> > tools on the Internet can map the Home Address to the owner of the >> > Home Prefix, which can reveal that a user from a particular ISP >> > has roamed. >> >>If the above is in scope, then the discussion of the problem is >>incomplete. Sending an esp packet from ISP B to one of ISP A's HAs >>really discloses as much information as the above paragraph implies. >> >> >>I think this draft does a bad job of explaining its scope and >>convincing me that the problem being solved is important to solve. >>For example why are IIDs out of scope? Why is the ESP corrilation I >>discuss above out of scope? If those attacks are out of scope, what >>real benefit remains to hiding roaming from onlookers? >> >> >>Finally, I do not understand what work is left to do in this space. >>This draft describes the problem and points out that encrypted tunnels >>and not using RO are a solution. What additional problems are being >>solved beyond that? What work is there for the IETF to do in this >>space? A problem statement should clearly articulate these points. >> >>Comment: >>I agree with Lisa that this document is unclear--not quite >>to the point of earning a discuss for lack of clarity--but unclear >>enough that if you haven't been reading mip6 documents for a while, >>you won't understand what is going on. It conflates profiling and >>location privacy, and describes more than supports its conclusions. >> >>---------- >>category: Editorial >>draft: draft-ietf-mip6-location-privacy-ps >>messages: 275 >>nosy: admin >>priority: Should fix >>status: Pending >>title: Comment by Sam Hartman on I-D draft-ietf-mip6-location-privacy-ps >> ------------ Institute For Infocomm Research - Disclaimer ------------- This email is confidential and may be privileged. If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you. -------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 20 05:43:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6cH-0005Ar-14; Mon, 20 Nov 2006 05:43:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm6cF-0005Al-8f for mip6@ietf.org; Mon, 20 Nov 2006 05:43:07 -0500 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm6cB-0005jz-K2 for mip6@ietf.org; Mon, 20 Nov 2006 05:43:07 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id D83EA1FAAD9 for ; Mon, 20 Nov 2006 11:43:02 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 18488-01-26 for ; Mon, 20 Nov 2006 11:43:02 +0100 (CET) Received: from [155.54.205.230] (inf-205-230.um.es [155.54.205.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.um.es (Postfix) with ESMTP id 9B6D61FAAE8 for ; Mon, 20 Nov 2006 11:42:54 +0100 (CET) Message-ID: <456186B1.5020908@dif.um.es> Date: Mon, 20 Nov 2006 11:42:57 +0100 From: "Pedro M. Ruiz" User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [Mip6] CFP: ACM MobiCom 2007, September 4-9 2007, Montreal, QC, Canada X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Apologies if you receive multiple copies of this message. CALL FOR PAPERS MobiCom 2007 The Thirteenth Annual International Conference on Mobile Computing and Networking September 9-14, 2007 Montreal, QC, Canada http://www.sigmobile.org/mobicom/2007/ Sponsored by ACM SIGMOBILE ACM MobiCom is the premier international conference dedicated to addressing the challenges in the areas of mobile computing and wireless and mobile networking. It has served as an exciting international forum since 1995, addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. MobiCom is a highly selective conference focusing on all issues in mobile computing and wireless and mobile networking at the link layer and above. New this year, Mobicom will be jointly held with ACM Mobihoc. The two conferences will run in parallel, and will have many joint plenary sessions (such as the keynote, panels, and welcoming reception). Authors are invited to submit full papers, challenges papers, student posters, and research demos and exhibits, presenting new research related to the theory or practice of mobile computing and/or wireless and mobile networking. All submissions must describe original research, not published or currently under review for another conference or journal. Areas of interest include, but are not limited to: * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, limited power and/or intermittent connectivity * Applications and services for mobile users * Cyber-physical computing and networking * Delay/disruption tolerant networks * Fundamental understanding of mobile computing and wireless networking * Implementations and experimental testbeds for mobile/wireless networks * Integration and interworking of wired and wireless networks * Modeling, measurement and simulation of mobile networks * Mobile ad hoc and sensor networks * Operating system and middleware support for mobile computing and networking * Performance evaluation of mobile and wireless networks and systems * Protocols exploiting dynamic spectrum, UWB, MIMO, directional antennas * Resource management and quality-of-service for real-time traffic support * Security, privacy, and fault-tolerance of mobile/wireless systems * Wireless access technologies (e.g., mesh networks, personal area networks) Submission Instructions Detailed instructions on how and where to submit your paper can be found at http://www.sigmobile.org/mobicom/2007/cfp.html Important Dates Abstracts submission due: February 23, 2007 Paper submissions due: March 2, 2007 Notification of acceptance: June 4, 2007 Camera-ready version due: June 29, 2007 General Chair: Evangelos Kranakis, kranakisscs.carleton.ca Technical Co-Chairs: Jennifer C. Hou, jhou@cs.uiuc.edu Ram Ramanathan, ramanath@bbn.com FOR MORE INFORMATION: Please contact the General Chair or Program Co-Chairs for more information. For information on ACM SIGMOBILE and the MobiCom series of conferences, see http://www.sigmobile.org/ or contact mobicom_info@acm.org. -- --------------------------------------------------------------------- Pedro M. Ruiz, Ph.D. E-mail: pedrom@dif.um.es Fac. Informatica, Univ. of Murcia Phone: +34968364335 Campus de Espinardo s/n Fax: +34968364151 E-30100, Espinardo, Murcia www: ants.dif.um.es/~pedrom/ SPAIN --------------------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 20 10:25:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB0X-0000dv-At; Mon, 20 Nov 2006 10:24:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB0V-0000db-0b; Mon, 20 Nov 2006 10:24:27 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmB0T-0007SR-O7; Mon, 20 Nov 2006 10:24:26 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1164036087!11146008!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 925 invoked from network); 20 Nov 2006 15:21:27 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-119.messagelabs.com with SMTP; 20 Nov 2006 15:21:27 -0000 Received: from il06exb01.corp.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kAKFHgL1009321; Mon, 20 Nov 2006 08:17:42 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exb01.corp.mot.com (8.13.1/8.13.0) with ESMTP id kAKFHfhe028694; Mon, 20 Nov 2006 09:17:41 -0600 (CST) Message-ID: <4561C714.1030309@motorola.com> Date: Mon, 20 Nov 2006 16:17:40 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thomas Narten References: <200611090112.kA91CtM5021694@cichlid.raleigh.ibm.com> In-Reply-To: <200611090112.kA91CtM5021694@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: mip6@ietf.org, netlmm@ietf.org Subject: [Mip6] Re: [netlmm] 3GPP2 Correspondence to IETF on netlmm X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org What is the appropriate action to be taken in relation to this liaison statement? Could such an action be to request from 3GPP2 TSG-X the description of the concept of Proxy Mobile IP? Or has this already been done, or probably available? (sorry if so) Alex Thomas Narten wrote: > The IETF has just received a formal correspondence from 3GPP2 TSG-X > concerning network based mobility. The statement is short and > says: > >> 3GPP2 has made a decision to use the Proxy Mobile IP concept as a >> network based mobility management solution. We appreciate your >> help to progress the related work in IETF Mobile IP working >> groups. > > (It will appear on the liaison statements page in a few days.) > > Thomas (IETF Liaison to 3GPP2) > > > _______________________________________________ netlmm mailing list > netlmm@ietf.org https://www1.ietf.org/mailman/listinfo/netlmm > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 21 13:11:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gma5I-0006Vc-5F; Tue, 21 Nov 2006 13:11:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gma5G-0006VO-Pc for mip6@ietf.org; Tue, 21 Nov 2006 13:11:02 -0500 Received: from smtp.elet.polimi.it ([131.175.120.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gma5D-0007FW-Ks for mip6@ietf.org; Tue, 21 Nov 2006 13:11:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.elet.polimi.it (Postfix) with ESMTP id EDB7F15DF12; Tue, 21 Nov 2006 19:10:58 +0100 (CET) X-Virus-Scanned: amavisd-new at elet.polimi.it Received: from smtp.elet.polimi.it ([127.0.0.1]) by localhost (smtp2.elet.polimi.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xno18u9JJ3Tp; Tue, 21 Nov 2006 19:10:58 +0100 (CET) Received: from laptopcapone (lap-capone.elet.polimi.it [131.175.123.211]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by smtp.elet.polimi.it (Postfix) with ESMTP id B73A315DF08; Tue, 21 Nov 2006 19:10:35 +0100 (CET) From: "Antonio Capone" To: Date: Tue, 21 Nov 2006 19:10:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 thread-index: AccNl2vwFXj8B9tWQEStH8LzRaSJLA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Message-Id: <20061121181035.B73A315DF08@smtp.elet.polimi.it> X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: Subject: [Mip6] Call for Papers: MOBIQUITOUS 2007 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: capone@elet.polimi.it List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Apologies if you receive multiple copies of this message. -- ======================================================================== CALL FOR PAPERS MOBIQUITOUS 2007 The 4th Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services http://www.mobiquitous.org August 6-10, 2007 - Philadelphia, PA ======================================================================== The combination of mobile and ubiquitous computing is emerging as a promising new paradigm. Through the use of mobile devices and devices embedded in the surrounding physical environments, users can be provided transparent computing and communication services at all times and in all places. The complexity of providing such services stems from the fact that the communication devices and the objects with which they interact may both be mobile. The implementation of such a paradigm requires advances in wireless network technologies and devices, development of infrastructures supporting cognitive environments, discovery and identification of ubiquitous computing applications and services, and an understanding of the cross-layer interactions between all of these components. The Fourth Annual International Conference on Mobile and Ubiquitous Systems: Computing, Networking and Services (Mobiquitous-07) will provide a forum where practitioners and researchers coming from many areas involved in ubiquitous solutions, design and deployment will be able to interact and exchange experiences needed to build successful ubiquitous systems. Areas addressed by the conference include applications, service-oriented computing, middleware, networking, agents, data management and services, all with special focus on mobility and ubiquitous computing. PAPERS: Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, are solicited. Technical papers clearly identifying how the specific contributions fit to an overall working solution are particularly of interest. Topics include, but are not limited to, the following feature topics as applied to mobile and ubiquitous environments: - Ubiquitous architectures, systems and applications - Wearable computing and personal area networks - Wireless technologies for mobile and ubiquitous (Bluetooth, ZigBee, 802.15.x, WiFi) - Wireless Internet access in ubiquitous systems - Ad hoc and sensor networks support for ubiquitous computing - Reconfigurability and personalization of wireless networks - Wireless/mobile service management and delivery - Security, privacy and social issues of mobile and ubiquitous systems - Service and knowledge discovery, matching and composition mechanisms - Location-based services and tracking in ubiquitous environments - Context- and location-aware applications - Agent technologies in ubiquitous, wearable, and mobile systems - Context modeling, services and frameworks - Toolkits, testbeds, development environments, and languages for ubiquitous computing - Rapid prototyping of ubiquitous applications - Ontologies for mobile and ubiquitous computing - Mobile and ubiquitous data management and processing - Data replication, migration and dissemination in ubiquitous environments - Queries, transactions and workflows in mobile and ubiquitous environments - Multimodal interfaces (speech, video kinetic, tactile) SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically (see the conference web page for details). Authors should prepare an Adobe Acrobat PDF version of their full paper. Papers must not exceed 8 pages double column (US Letter size, 8.5 x 11 inches) including text, figures and references. The font size must be at least 10 points. PUBLICATION: All submitted papers will be rigorously reviewed by the international technical program committee. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Mobile Networks and Applications (MONET) journal. WORKSHOPS: Four workshops will be run in conjunction with the conference. The purpose of these workshops is to discuss work in progress and explore opportunities for new research related to mobile and ubiquitous systems: computing, networking and services. Proposals for workshops should be at most four pages in length and should be submitted to Dr. Suman Banerjee by February 1, 2007. IMPORTANT DATES: Workshop Proposal Deadline: February 1, 2007 Paper Registration Deadline: March 13, 2007 Paper Submission Deadline: March 20, 2007 Notification of Acceptance: May 4, 2007 Camera-ready Manuscripts due: June 4, 2007 CONFERENCE ORGANIZING COMMITTEE: GENERAL CHAIR: Guohong Cao, The Pennsylvania State University TECHNICAL PROGRAM CHAIR: Robin Kravets, University of Illinois at Urbana-Champaign TECHNICAL PROGRAM CO-CHAIRS: Anind Dey, Carnegie Mellon University Hui Lei, IBM WORKSHOP CHAIR: Suman Banerjee, University of Wisconsin-Madison DEMO CHAIR: Hao Zhu, Florida International University POSTER CHAIR: Al Harris, Universita di Padova Dong Xuan, Ohio State University FINANCE CHAIR: Karen Decker, ICST PUBLICATION CHAIR: Cristina Nita-Rotaru, Purdue university PUBLICITY CHAIR: Antonio Capone, Politecnico di Milano Wensheng Zhang, Iowa State University LOCAL CHAIR: Zhen Jiang, West Chester University of Pennsylvania WEB CHAIR: Hui Song, Penn State University CONFERENCE COORDINATOR Anna Rieger, ICST STEERING COMMITTEE Imrich Chlamtac, Create-Net (chair) Fausto Giunchiglia, University of Trento Tom La Porta, Penn State University Chiara Petrioli, Universita di Roma "La Sapienza" Krishna Sivalingam, University of Maryland Baltimore County Michele Zorzi, Universita di Padova TECHNICAL PROGRAM COMMITTEE: See http://www.mobiquitous.org _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 22 21:01:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn3tE-0006kQ-SD; Wed, 22 Nov 2006 21:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn3tD-0006jz-6i for mip6@ietf.org; Wed, 22 Nov 2006 21:00:35 -0500 Received: from dispatch.cs.umd.edu ([128.8.128.60]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn3tB-0004Ku-T8 for mip6@ietf.org; Wed, 22 Nov 2006 21:00:35 -0500 Received: from delegate.pc.cs.umd.edu (exchange.cs.umd.edu [128.8.130.248]) by dispatch.cs.umd.edu (8.13.1/8.12.5) with ESMTP id kAN20VIX016939 for ; Wed, 22 Nov 2006 21:00:31 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 22 Nov 2006 21:00:26 -0500 Message-ID: <5B211F0A44261848B86EC460096A555A1BACA3@delegate.pc.cs.umd.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Papers IEEE NetCri 07 Thread-Index: AccOoyTVZ1uYok9vQ7mjC1n0OSSDFg== From: "Elsharnouby, Tamer" To: X-CSD-MailScanner-Information: Please email staff@cs.umd.edu for more information X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.44, required 5, ALL_TRUSTED -1.44) X-CSD-MailScanner-From: sharno@cs.umd.edu X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: [Mip6] Call for Papers IEEE NetCri 07 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org *** Our Apologies if you received this multiple times = *** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Call for Papers NetCri 07 The First International Workshop on=20 Research Challenges in Next Generation Networks for=20 First Responders and Critical Infrastructures http://www.cs.umd.edu/~sharno/NetCri07 In Conjunction with=20 IEEE IPCCC 2007, New Orleans, Louisiana, April 11-13 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D As advances in pervasive computing, wireless communication and sensor = networks continue, more opportunities are open to first responders and critical = infra- structures to benefit from these technologies. Providing first = responders with the best possible technology, infrastructure and services help save the = lives of the general public and the first responders as well. One of the main = challenges to the operations of first responders and critical = infrastructures is to deploy a communication network that is dependable, secure, and = rapidly deployable. In order to operate effectively, the deployed network = supports services such as location determination, audio and video communication, = and in site and remote sensing. Another key feature for first responders and = critical infrastructures networks is to support interactions among multiple = heterogen- eous networks.=20 =20 This workshop provides a forum for researchers, industry, and government = agencies to discuss the challenges facing the design, deployment and = operation- al issues for next generation network support for first responders and = critical infrastructure. The workshop will identify and define fundamental = concepts and=20 techniques, resolve conflicts between different approaches in the area, = and=20 provide a common ground for an advanced research and development agenda. = Topics of interest include, but are not limited to: - Smart environments (buildings, roads, vehicles, etc.)=20 - Fast roaming in heterogonous network environment - Localization and time synchronization=20 - Rapidly deployable and self configuring services and networks - Security, dependability, privacy, and performance trade-offs - QoS in heterogeneous wireless networks - Sensor and actuator networks for information gathering and real-time = control - Network and system support for augmented reality and visual = analytics - Simulation studies of first responders and critical infrastructures' = networks - Novel and adaptive communication protocols to support first = responders and critical infrastructure' operation - Resource management and allocation - Power control management - Admission, load and flow control - Performance analysis and experimentation of heterogeneous wireless = networks - Security techniques and methods for heterogeneous wireless networks - Interoperability among WLANs, Cellular, WSN and wired networks - Metrics and measurements on heterogeneous networks - Mobility models and traffic patterns in disaster areas - Cross-layer design - Testbeds Paper Submission Papers should describe original, previously unpublished work, not = currently=20 under review by another conference, workshop, or journal. Authors are = invited to submit a maximum of 6 pages papers including the abstract, figures = and=20 references. Papers should include the title, author(s), authors' = affiliation and an abstract. The formatting should be according to IEEE rules. = Papers=20 should be submitted in a PDF format using the EDAS submission system. Accepted papers will be accessible through the IEEE digital library and = are=20 included in the conference proceedings. Important Dates Submission deadline: November 30, 2006 Notification of acceptance: January 5, 2007 Camera ready version: January 26, 2007 Workshop Organizing Committee Program Co-Chairs Mohamed Eltoweissy, Virginia Tech, USA Moustafa Youssef, University of Maryland, USA=20 Publicity Co-Chairs Tamer Elsharnouby, Microsoft Corporation, USA James Joshi, University of Pittsburg, USA Technical Program Committee=20 Arup Acharya, IBM, USA Ashok Agrawala, University of Maryland, USA Jonathan Agre, Fujitsu Lab, USA Mustaque Ahamad, Georgia Tech, USA Nils Aschenbruck, University of Bonn, Germany Farag Azzedine, King Fahd University, Saudi Arabia Doreen Cheng, Samsung Research, USA Nagwa Elmakky, Alexandria University, Egypt Mohamed Gouda, University of Texas, USA Elena Guara, Coventry University, UK Wendi Heinzelman, University of Rochester, USA James Joshi, University of Pittsburgh, USA P. Krishnan, Avaya Labs, USA Scott Midkiff, Virginia Tech, USA Tamer Nadeem, Siemens Research, USA Dragos Niculescu, NEC Labs, USA Stephan Olariu, Old Dominion University, USA Krishna Sivalingam, University of Maryland at BC, USA Stephen D. Wolthusen, University of London, USA Mohamed Younis, University of Maryland at BC, USA Adel Youssef, Google, USA _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 25 15:38:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go4HZ-0005ok-96; Sat, 25 Nov 2006 15:37:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go4HX-0005oZ-HQ; Sat, 25 Nov 2006 15:37:51 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go4HW-0002DJ-7L; Sat, 25 Nov 2006 15:37:51 -0500 Received: from [10.1.210.5] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 12:37:44 -0800 Message-ID: <4568A997.7000204@azairenet.com> Date: Sat, 25 Nov 2006 12:37:43 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Vijay K. Gurbani" , mip6@ietf.org References: <455A47DB.3080005@lucent.com> In-Reply-To: <455A47DB.3080005@lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2006 20:37:45.0006 (UTC) FILETIME=[8FCBDCE0:01C710D1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: gen-art@ietf.org Subject: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org hi, thanks for the review. responses inline. Vijay K. Gurbani wrote: > 1) In S4, the authors state that "Many of the requirements are repeated > from RFC3776 to make this document self-contained and complete." > There are a fair number of requirements in subsequent sub-sections. > It may help if the authors tag each requirement that was already > present in RFC3776, so the reader can see which new requirement was > generated by this draft. we would like to keep this document self-contained, basically one needn't refer to RFC 3776 at all to implement this spec. the very initial versions of the document were written with only the new requirements listed, but folks didn't like it. > 2) Nit: S6.1, under heading "mobile node SPD-S:" > s/=BU/= BU/ fixed. > 3) In S9, first full paragraph of Page 22: "In case the home agent ... > an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an > INTERNAL_ADDRESS_FAILURE message, does it make sense to specify > what should it do, if anything? good catch. the mobile node has the following options. 1. it can attempt to auto-configure a home address as described in section 5.3.2 of draft-ietf-mip6-bootstrapping-split-03.txt. the sequence is a bit complicated though. it has to terminate the current IKE exchange and initiate a new one. in the new IKE_AUTH exchange, the MN should try to auto-configure a home address. 2. switch to another home agent (most home agent discovery mechanisms return more than one home agent). 3. throw an exception and report and error to the user. 2) seems to be simplest option. comments? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 25 15:49:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go4Rx-0001NS-Qq; Sat, 25 Nov 2006 15:48:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go4Rw-0001NL-9v for mip6@ietf.org; Sat, 25 Nov 2006 15:48:36 -0500 Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go4Ru-0003Gm-Qh for mip6@ietf.org; Sat, 25 Nov 2006 15:48:36 -0500 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 9814137F05; Sat, 25 Nov 2006 21:48:21 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 7C8D237EF4 for ; Sat, 25 Nov 2006 21:48:21 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 6464537E51 for ; Sat, 25 Nov 2006 21:48:21 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1Go4Rf-0002Cz-Dh for mip6@ietf.org; Sat, 25 Nov 2006 21:48:20 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Sat, 25 Nov 2006 20:48:17 +0000 MIME-Version: 1.0 Message-Id: <1164487697.56.0.357086067753.issue88@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Subject: [Mip6] [issue88] Security Directorate (Pasi Eronen) reivew X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from Vijay Devarapalli : Some comments about draft-ietf-mip6-ikev2-ipsec-07: 1) Section 4 says "The home agent MAY use the Peer Authorization Database (PAD) [5] to store per-mobile node state." In RFC4301 the PAD is not some optional component of IPsec that may or may not be used; it is always present and always used (although in some cases it might not contain per-MN state). 2) Section 3 says "In case the mobile node reverse tunnels all traffic including Mobile IPv6 signaling messages exchanged between the mobile node and the home agent, then the Home Address Option is not required to be present in the messages sent to the home agent." (and continues to give an example of Binding Update without Home Address Option), but Section 4.2 says "The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations". Is this a contradiction or just confusion? 3) Section 4.2 says "RFC 3776 required configuration of the security policies per interface in order to be able to differentiate between mobility header messages sent to the home agent and tunneled through the home agent to the correspondent node. Since the Mobility Header message type is a selector, it is now easy to differentiate between HoTi and HoT messages from other mobility header messages. Therefore per-interface configuration of security policies is not required." This is only partially true. RFC 3776 like virtual interfaces would probably still be required if link-layer addresses are used (e.g. for MLD or DHCPv6). If this is the case, it might be a good idea to explicitly mention that the mechanisms described in this document support payload data protection only for traffic originating/terminating at the home address. 4) Section 4.3, "The home agent and mobile node SHOULD support Mobility Header message type as an IPsec selector." and "The home agent and mobile node SHOULD support ICMPv6 message type as an IPsec selector." If an implementation doesn't support them, it's not RFC4301 compliant anyway. Similarly, Section 5 says "IPsec implementations are compatible with this document even if they do not support fine grain selectors such as the Mobility Header message type and ICMPv6 message type." However, such implementations are not compliant with RFC4301; this should be said explicitly. 5) Section 4.3, "Similarly, the home agent starts to expect the new source address in the tunnel packets received from the mobile node." An RFC4301 IPsec implementation does not use the outer source address in tunnel mode packets for anything, so it doesn't "expect" anything. Similarly, Section 5 says "Typical IPsec processing does not check the outer source address.". More correctly, this is not part of IPsec processing as described in RFC 4301. 6) Section 7.1: These SPD entries do not follow anything in RFC4301; instead, they mix information that would be present in PAD as well. This section should also definitely consider PAD, as it is the=20 part of RFC4301 that prevents one MN for creating SAs for another=20 MN's home address. 7) Section 9: "The Home Agent should also include an INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the duration for which the dynamically allocated home address is valid." In RFC 4718 (IKEv2 clarifications) we strongly recommend=20 against using the INTERNAL_ADDRESS_EXPIRY attribute. (Note: I'm not subscribed to the MIP6 list, so keep in in Cc line of any replies :-)=20 Best regards, Pasi ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 284 nosy: vijay priority: Must fix status: Pending title: Security Directorate (Pasi Eronen) reivew _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 25 16:06:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go4jO-0008SI-Rc; Sat, 25 Nov 2006 16:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go4jN-0008Nv-Rk; Sat, 25 Nov 2006 16:06:37 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go4jM-0005wB-HD; Sat, 25 Nov 2006 16:06:37 -0500 Received: from [10.1.210.5] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 13:06:35 -0800 Message-ID: <4568B059.4030401@azairenet.com> Date: Sat, 25 Nov 2006 13:06:33 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Steven M. Bellovin" References: <20061111151215.b54defd1.smb@cs.columbia.edu> In-Reply-To: <20061111151215.b54defd1.smb@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2006 21:06:35.0562 (UTC) FILETIME=[9749C0A0:01C710D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Francis.Dupont@point6.net, secdir@mit.edu, housley@vigilsec.com, mip6@ietf.org, iesg@ietf.org, hartmans-ietf@mit.edu, mip6-chairs@ietf.org Subject: [Mip6] Re: secdir review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org hi Steve, thanks for the review. Steven M. Bellovin wrote: > One obvious problem: Section 4.1 notes that 3775 requires support for > manual key management, and lists IKE support as a "MAY". However, 4107 -- > a BCP which came out after 3775 -- establishes a strong presumption that > automated key management automated key management be used. Accordingly, > this draft should mandate support for IKEv2, as it does not appear to fall > under any of the exceptions. this was discussed on the MIP6 mailing list. it was felt that this particular draft should not update this part of RFC 3775. draft-ietf-mip6-ikev2-ipsec only describes how IKEv2 should be used with MIPv6. not whether MIPv6 MUST use IKEv2. that belongs in the MIPv6 base specification. I think it is best handled when RFC 3775 is revised. > 4.3 says that anti-replay is optional. However, Section 1 of 3776 says > that anti-replay is required, though it notes that it can't be done > properly without IKE. Assuming that IKEv2 is mandated here, anti-replay > should be as well. the primary mechanism for anti-replay protection for the binding updates is the sequence number in the binding updates. the only time this fails is when the home agent looses the binding cache state (for e.g. it reboots). in this case, dynamic keying (through IKEv2) provides replay protection since a new security association for protecting the BU is negotiated automatically (since the home agent lost all state). any binding updates protected by the old IPsec SA will not be accepted. hope that clarifies the text. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Nov 25 16:36:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go5Bq-0003fJ-UJ; Sat, 25 Nov 2006 16:36:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go5Bo-0003af-9r; Sat, 25 Nov 2006 16:36:00 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go5Bn-0004Fd-0P; Sat, 25 Nov 2006 16:36:00 -0500 Received: from [10.1.210.5] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 13:35:58 -0800 Message-ID: <4568B73C.3090301@azairenet.com> Date: Sat, 25 Nov 2006 13:35:56 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Steven M. Bellovin" References: <20061111151215.b54defd1.smb@cs.columbia.edu> <4568B059.4030401@azairenet.com> <20061125211159.1912C3C0881@berkshire.machshav.com> In-Reply-To: <20061125211159.1912C3C0881@berkshire.machshav.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Nov 2006 21:35:58.0273 (UTC) FILETIME=[B1F21B10:01C710D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Francis.Dupont@point6.net, secdir@mit.edu, housley@vigilsec.com, mip6@ietf.org, iesg@ietf.org, hartmans-ietf@mit.edu, mip6-chairs@ietf.org Subject: [Mip6] Re: secdir review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org thanks for the quick response. Steven M. Bellovin wrote: > On Sat, 25 Nov 2006 13:06:33 -0800 >>> 4.3 says that anti-replay is optional. However, Section 1 of 3776 >>> says that anti-replay is required, though it notes that it can't be >>> done properly without IKE. Assuming that IKEv2 is mandated here, >>> anti-replay should be as well. >> the primary mechanism for anti-replay protection >> for the binding updates is the sequence number in >> the binding updates. the only time this fails is >> when the home agent looses the binding cache state >> (for e.g. it reboots). in this case, dynamic keying >> (through IKEv2) provides replay protection since a >> new security association for protecting the BU is >> negotiated automatically (since the home agent lost >> all state). any binding updates protected by the >> old IPsec SA will not be accepted. hope that >> clarifies the text. >> > Makes sense -- but similar text should be in the draft to clarify it. how about the following text in section 4.3 The use of sequence number in the ESP header to provide anti-replay protection is optional because the sequence numbers in the Binding Updates provide anti-replay protection. However, the anti-replay protection fails if the home agent looses the binding cache state, for example, due to a reboot. Since the IPsec security association state can be also be assumed to be lost, ESP cannot provide anti-replay protection in thise case. Complete anti- replay protection can only be provided by the use of a dynamic keying mechanism, like IKEv2. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 26 16:26:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoRVY-0000NT-Lt; Sun, 26 Nov 2006 16:25:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoRVW-0000NL-N0 for mip6@ietf.org; Sun, 26 Nov 2006 16:25:50 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoRVV-00005R-3Z for mip6@ietf.org; Sun, 26 Nov 2006 16:25:50 -0500 Received: from [10.1.210.5] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Nov 2006 13:25:47 -0800 Message-ID: <456A0655.5000401@azairenet.com> Date: Sun, 26 Nov 2006 13:25:41 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tero Kivinen References: <17743.45484.327116.817303@fireball.kivinen.iki.fi> In-Reply-To: <17743.45484.327116.817303@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2006 21:25:47.0795 (UTC) FILETIME=[707C4E30:01C711A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: mip6@ietf.org Subject: [Mip6] Re: Review of the draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Tero, thanks for the review. Tero Kivinen wrote: > This should probably also talk about MOBIKE, as MOBIKE can offer some > more building blocks for the MIP6 which will make it easier to use > IKEv2 when addresses changes. the use of MOBIKE and MIP6 between the mobile node and the home agent at the same time was discussed quite extensively on the MIP6 mailing list. the general thinking is that you shouldn't have two protocols trying to manage the tunnel between the mobile node and the home agent at the same time. with MIPv6, the tunnel is basically a MIP tunnel, sometimes protected by ESP in tunnel mode. the binding update/binding acknowledgment messages are used for updating the tunnel end-point whenever the mobile node moves, irrespective of whether the tunnel is protected by ESP or not. >> 4.4. Dynamic Keying Requirements > ... >> o If the home agent has used IKEv2 to establish security >> associations with the mobile node, it should follow the procedures >> discussed in Section 10.3.1 and 10.3.2 of the base specification >> [2] to determine whether the IKE endpoints can be moved or if the >> IKE SA has to be re-established. > > I do not know exactly what the RFC3775 specifies how to detect whether > the SA can be moved or not, but if MOBIKE was supported by both ends > when the IKEv2 SA was created, then SAs can always be updated with > MOBIKE ADDRESS_UPDATE notify. RFC 3775 describes the use of a flag (K) in the binding update/binding ack messages to signal the capability to update the IPsec SA when the MIP tunnel end point is updated. this document does not modify that. >> 7.2. Security Association negotiation using IKEv2 > ... >> When the mobile node uses its home address in the IDi field, >> implementations are required to match the source address in the >> outermost IP header with the IP address in the IDi field [8]. This >> verification step, however, should be configurable [8]. With Mobile >> IPv6, this verification step will always fail because the source >> address in the IP header is the care-of address and the IP address in >> the IDi field is the home address. Therefore, this verification step >> MUST be disabled. > > Actually RFC 4306 section 3.1 says: > > Information from the beginning of the packet through > the UDP header is largely ignored except that the IP addresses and > UDP ports from the headers are reversed and used for return > packets. > > I.e the outer IP addresses are not used to verify IDi/IDr fields. > RFC4718 (IKEv2 Clarifications and Implementation Guidelines) says this > explicitly in section 7.1: > > Furthermore, IKEv2 does not require that the addresses in > ID_IPV4_ADDR/ID_IPV6_ADDR match the address in the IP header of the > IKE packets. However, other specifications may place additional > requirements regarding this. For example, [PKI4IPsec] requires that > implementation must be capable of comparing the addresses in the > ID_IPV4_ADDR/ID_IPV6_ADDR with the addresses in the IP header of the > IKE packets, and this comparison must be enabled by default. > > So it would be enough here to say that you follow IKEv2 way of not > matching the outer IP addresses with the ID payloads, and not follow > the pki4ipsec profile about the IKEv1 (pki4ipsec is mostly for IKEv1 > in any case). Also PKI4IPsec WG is now thinking whether they should > say that section 3 of the draft-ietf-pki4ipsec-ikecert-profile-11.txt > is only used for IKEv1 or for both IKEv1 and IKEv2. > > It would be better not to refer the pki4ipsec draft at all in this > point, as it just adds confusion. agreed. here is the new text. When the mobile node uses its home address in the IDi field, implementations are not required to match the source address in the outermost IP header with the IP address in the IDi field. According to RFC 4306 [4], the IP header fields in the IKEv2 messages are ignored and used only in the IP headers for IKEv2 messages sent as replies. >> 8. The use of EAP authentication > ... >> When EAP is used, the identity presented by the mobile node in the >> IDi field may not be the actual identity of the mobile node. It >> could be set to an identity that is used only for AAA routing >> purposes and selecting the right EAP method. The actual identity is >> carried inside EAP payloads that is not visible to the home agent. >> The home agent MUST acquire the mobile node's identity from the >> corresponding AAA server. More details can be found in [13]. > > Actually the rfc4718 does not mention anything about this. agreed. RFC 4718 does not address how the IKEv2 responder can acquire the actual mobile node identity. > The RFC4306 > says that the EAP Identity requests SHOULD NOT be sent (section 3.16): > > Note that since IKE passes an indication of initiator identity in > message 3 of the protocol, the responder SHOULD NOT send EAP Identity > requests. The initiator SHOULD, however, respond to such requests if > it receives them. > > I.e the EAP exchange does not include EAP Identity request and reply, > as that information has already been passed inside the ID payloads of > the IKE exchange, and those same IDs are used as EAP identities when > talking to the AAA server. > > So the actual identity is visible to the home agent as it is sent > inside the ID payload. the current text is there to address scenarios where the identify in the IDi field is not the same identity sent in the EAP messages. section 3.5 of RFC 4718 does say that there could be such cases. it simplifies things if the IDi does contain the actual identify of the mobile node. I would be happy to remove the text. >> 9. Dynamic Home Address Configuration > ... >> When the home agent receives a configuration payload with a >> CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home >> address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in >> the CFG_REPLY contains the prefix length of the home prefix in >> addition to a 128 bit home address. The home agent could use a local >> database or contact a DHCPv6 server on the home link to allocate a >> home address. The Home Agent should also include an >> INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, the >> duration for which the dynamically allocated home address is valid. > > RFC4718 says: > ---------------------------------------------------------------------- > 6.7. INTERNAL_ADDRESS_EXPIRY > > Section 3.15.1 defines the INTERNAL_ADDRESS_EXPIRY attribute as > "Specifies the number of seconds that the host can use the internal > IP address. The host MUST renew the IP address before this expiry > time. Only one of these attributes MAY be present in the reply." > > Expiry times and explicit renewals are primarily useful in > environments like DHCP, where the server cannot reliably know when > the client has gone away. However, in IKEv2 this is known, and the > gateway can simply free the address when the IKE_SA is deleted. > > Also, Section 4 says that supporting renewals is not mandatory. > Given that this functionality is usually not needed, we recommend > that gateways should not send the INTERNAL_ADDRESS_EXPIRY attribute. > (And since this attribute does not seem to make much sense for > CFG_REQUESTs, clients should not send it either.) > > Note that according to Section 4, clients are required to understand > INTERNAL_ADDRESS_EXPIRY if they receive it. A minimum implementation > would use the value to limit the lifetime of the IKE_SA. > ---------------------------------------------------------------------- yes this make sense in IKEv2 context. however... > So, I would suggest you do recommend NOT to use > INTERNAL_ADDRESS_EXPIRY at all, and simply get the address lifetime > from the lifetime of the IKEv2 SA, i.e. the server will keep on > renewing (if needed, in most cases the IP addresses are allocated from > the local pool, so there is no needs to do renewals) the IP address as > long as client keeps the IKEv2 SA up, and in case the address for some > reason cannot be renewed, or is changed, deletes the IKEv2 SA forcing > the client to get new IP address. As we are talking about home address > here, there should not really be any problems with the address > changing or not being able to renew it. if we tie the home address lifetime to the IKE SA lifetime, then I am afraid that home address assignment through IKEv2 is not going to be popular. folks would use other mechanisms to assign the home address to the mobile node. a Mobile IP home address by definition is supposed to be a long lived address that does not change very often. if there is no restriction that the lifetime in INTERNAL_ADDRESS_EXPIRY attribute should always be less than the IKEv2 SA lifetime, perhaps MIPv6 could use the INTERNAL_ADDRESS_EXPIRY attribute. maybe we have found a use for the attribute. ;) Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 26 18:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoSy7-0002dp-1H; Sun, 26 Nov 2006 17:59:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoSy5-0002dS-7s; Sun, 26 Nov 2006 17:59:25 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoSy3-0006Mr-Nq; Sun, 26 Nov 2006 17:59:25 -0500 Received: from [10.1.210.5] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Nov 2006 14:59:11 -0800 Message-ID: <456A1C39.7030103@azairenet.com> Date: Sun, 26 Nov 2006 14:59:05 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Nov 2006 22:59:11.0223 (UTC) FILETIME=[7C639070:01C711AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Francis.Dupont@point6.net, mip6@ietf.org, iesg@ietf.org Subject: [Mip6] Re: Last call comments for draft-ietf-mip6-ikev2-ipsec-07 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org hi Pasi, thanks for the review. I will create a separate issue for the PAD and how the SPD entries are represented in this draft. I will respond to the rest of your comments on this email. Pasi.Eronen@nokia.com wrote: > 2) Section 3 says "In case the mobile node reverse tunnels all traffic > including Mobile IPv6 signaling messages exchanged between the > mobile node and the home agent, then the Home Address Option is not > required to be present in the messages sent to the home agent." > (and continues to give an example of Binding Update without Home > Address Option), but Section 4.2 says "The mobile node MUST use the > Home Address destination option in Binding Updates and Mobile > Prefix Solicitations". Is this a contradiction or just confusion? the text in section 4.2 needs to be fixed. o The mobile node MUST use the Home Address destination option in Binding Updates and Mobile Prefix Solicitations when transport mode IPsec protection is used, so that the home address is visible when the IPsec policy checks are made. > > 3) Section 4.2 says "RFC 3776 required configuration of the security > policies per interface in order to be able to differentiate between > mobility header messages sent to the home agent and tunneled > through the home agent to the correspondent node. Since the > Mobility Header message type is a selector, it is now easy to > differentiate between HoTi and HoT messages from other mobility > header messages. Therefore per-interface configuration of security > policies is not required." > > This is only partially true. RFC 3776 like virtual interfaces would > probably still be required if link-layer addresses are used > (e.g. for MLD or DHCPv6). agreed. If this is the case, it might be a good > idea to explicitly mention that the mechanisms described in this > document support payload data protection only for traffic > originating/terminating at the home address. what if I just modify the last sentence of the above paragraph? new text o RFC 3776 required configuration of the security policies per interface in order to be able to differentiate between mobility header messages sent to the home agent and tunneled through the home agent to the correspondent node. Since the Mobility Header message type is a selector, it is now easy to differentiate between HoTi and HoT messages from other mobility header messages. Therefore per-interface configuration of security policies is not required for protecting mobility header messages. > 4) Section 4.3, "The home agent and mobile node SHOULD support > Mobility Header message type as an IPsec selector." and "The home > agent and mobile node SHOULD support ICMPv6 message type as an > IPsec selector." If an implementation doesn't support them, it's > not RFC4301 compliant anyway. > > Similarly, Section 5 says "IPsec implementations are compatible > with this document even if they do not support fine grain selectors > such as the Mobility Header message type and ICMPv6 message type." > However, such implementations are not compliant with RFC4301; this > should be said explicitly. this text was added to address some concerns that not all IPsec implementations support all selectors. this was true in 2401 case at least. don't know about 4301 IPsec implementations. but we can add the note. IPsec implementations are compatible with this document even if they do not support fine grain selectors such as the Mobility Header message type and ICMPv6 message type. Note that such IPsec implementations are not compliant to RFC 4301 [5]. > 5) Section 4.3, "Similarly, the home agent starts to expect the new > source address in the tunnel packets received from the mobile > node." > > An RFC4301 IPsec implementation does not use the outer source > address in tunnel mode packets for anything, so it doesn't "expect" > anything. Similarly, Section 5 says "Typical IPsec processing does > not check the outer source address.". More correctly, this is not > part of IPsec processing as described in RFC 4301. that is correct. however, this check is mandated by RFC 3775. section 15.7 of RFC 3775 When receiving tunneled traffic, the home agent verifies that the outer IP address corresponds to the current location of the mobile node. This acts as a weak form of protection against spoofing packets that appear to come from the mobile node. This is particularly useful, if no end- to-end security is being applied between the mobile and correspondent nodes. The outer IP address check prevents attacks where the attacker is controlled by ingress filtering. > 7) Section 9: "The Home Agent should also include an > INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, > the duration for which the dynamically allocated home address is > valid." In RFC 4718 (IKEv2 clarifications) we strongly recommend > against using the INTERNAL_ADDRESS_EXPIRY attribute. Tero also had this comment. I agree the INTERNAL_ADDRESS_EXPIRY does not make sense in IKEv2 context. this is what I had written in response to Tero's comment. if we tie the home address lifetime to the IKE SA lifetime, then I am afraid that home address assignment through IKEv2 is not going to be popular. folks would use other mechanisms to assign the home address to the mobile node. a Mobile IP home address by definition is supposed to be a long lived address that does not change very often. if there is no restriction that the lifetime in INTERNAL_ADDRESS_EXPIRY attribute should always be less than the IKEv2 SA lifetime, perhaps MIPv6 could use the INTERNAL_ADDRESS_EXPIRY attribute. maybe we have found a use for the attribute. ;) Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 26 18:01:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoT0L-0002xS-GW; Sun, 26 Nov 2006 18:01:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoT0J-0002xN-Em for mip6@ietf.org; Sun, 26 Nov 2006 18:01:43 -0500 Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoT0I-0006gc-4X for mip6@ietf.org; Sun, 26 Nov 2006 18:01:43 -0500 Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 6DE6A387C1; Mon, 27 Nov 2006 00:01:39 +0100 (CET) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 52AB938778 for ; Mon, 27 Nov 2006 00:01:39 +0100 (CET) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 4508437E4B for ; Mon, 27 Nov 2006 00:01:39 +0100 (CET) Received: from shiraz.local.levkowetz.com ([192.168.3.14] helo=shiraz.levkowetz.com) by shiraz.levkowetz.com with esmtp (Exim 4.63) (envelope-from ) id 1GoT0B-0003j7-Na for mip6@ietf.org; Mon, 27 Nov 2006 00:01:38 +0100 Content-Type: text/plain; charset=utf-8 To: mip6@ietf.org From: Vijay Devarapalli Date: Sun, 26 Nov 2006 23:01:29 +0000 MIME-Version: 1.0 Message-Id: <1164582089.2.0.084459656172.issue89@mip4.org> X-Roundup-Name: Mip6 issue tracker X-Roundup-Loop: hello Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 192.168.3.14 X-SA-Exim-Mail-From: roundup-admin@mip4.org X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on shiraz.levkowetz.com X-Spam-Level: X-Spam-Status: No, score=-110.4 required=2.5 tests=ALL_TRUSTED,BAYES_00, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.7 X-SA-Exim-Version: 4.2.1 (built Mon, 27 Mar 2006 13:42:28 +0200) X-SA-Exim-Scanned: Yes (on shiraz.levkowetz.com) X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Mip6] [issue89] Use of PAD and SPD representation X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mip6 issue tracker List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org New submission from Vijay Devarapalli : Pasi Eronen wrote: 1) Section 4 says "The home agent MAY use the Peer Authorization Database (PAD) [5] to store per-mobile node state." In RFC4301 the PAD is not some optional component of IPsec that may or may not be used; it is always present and always used (although in some cases it might not contain per-MN state). 6) Section 7.1: These SPD entries do not follow anything in RFC4301; instead, they mix information that would be present in PAD as well. This section should also definitely consider PAD, as it is the=20 part of RFC4301 that prevents one MN for creating SAs for another=20 MN's home address. ---------- category: Technical draft: draft-ietf-mip6-ikev2-ipsec messages: 291 nosy: vijay priority: Must fix status: Pending title: Use of PAD and SPD representation _________________________________________________ Mip6 issue tracker _________________________________________________ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Nov 26 21:19:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoW54-00071K-1T; Sun, 26 Nov 2006 21:18:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoW52-000719-Ki for mip6@ietf.org; Sun, 26 Nov 2006 21:18:48 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoW4z-0001UV-Vz for mip6@ietf.org; Sun, 26 Nov 2006 21:18:48 -0500 Received: from [10.1.210.5] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 26 Nov 2006 18:18:44 -0800 Message-ID: <456A4B00.5030400@azairenet.com> Date: Sun, 26 Nov 2006 18:18:40 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Ahmad Muhanna References: <6FC4416DDE56C44DA0AEE67BC7CA4371117060EF@zrc2hxm2.corp.nortel.com> In-Reply-To: <6FC4416DDE56C44DA0AEE67BC7CA4371117060EF@zrc2hxm2.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2006 02:18:44.0616 (UTC) FILETIME=[5D165880:01C711CA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: mip6@ietf.org Subject: [Mip6] Re: Reposting: Using the last Accepted Sequence Number in BA X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org hi Ahmad, section 11.7.1 of RFC 3775 says If the sending mobile node has no knowledge of the correct Sequence Number value, it may start at any value. If the home agent rejects the value, it sends back a Binding Acknowledgement with a status code 135, and the last accepted sequence number in the Sequence Number field of the Binding Acknowledgement. The mobile node MUST store this information and use the next Sequence Number value for the next Binding Update it sends. > According to MN processing of the Binding Acknowledgement as > specified under section 11.7.3., the MN will silently discard the > received BA rather than picking the last accepted sequence number > and then generate a new sequence number. the latter has been the intention always. I agree that the text describing this is kind of "hidden" in RFC 3775. :) Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 10:34:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiUV-0002HW-Pf; Mon, 27 Nov 2006 10:33:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiUT-0002H9-P5 for mip6@ietf.org; Mon, 27 Nov 2006 10:33:53 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoiUQ-00021g-NA for mip6@ietf.org; Mon, 27 Nov 2006 10:33:53 -0500 Received: from [10.1.210.16] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 07:33:49 -0800 Message-ID: <456B055A.1050308@azairenet.com> Date: Mon, 27 Nov 2006 07:33:46 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Tero Kivinen References: <17743.45484.327116.817303@fireball.kivinen.iki.fi> <456A0655.5000401@azairenet.com> <17770.51501.10145.418178@fireball.kivinen.iki.fi> In-Reply-To: <17770.51501.10145.418178@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2006 15:33:49.0851 (UTC) FILETIME=[6F9F86B0:01C71239] X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Cc: mip6@ietf.org Subject: [Mip6] Re: Review of the draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Tero Kivinen wrote: > Vijay Devarapalli writes: >>> This should probably also talk about MOBIKE, as MOBIKE can offer some >>> more building blocks for the MIP6 which will make it easier to use >>> IKEv2 when addresses changes. >> the use of MOBIKE and MIP6 between the mobile node >> and the home agent at the same time was discussed >> quite extensively on the MIP6 mailing list. the >> general thinking is that you shouldn't have two >> protocols trying to manage the tunnel between the >> mobile node and the home agent at the same time. >> with MIPv6, the tunnel is basically a MIP tunnel, >> sometimes protected by ESP in tunnel mode. the >> binding update/binding acknowledgment messages are >> used for updating the tunnel end-point whenever the >> mobile node moves, irrespective of whether the >> tunnel is protected by ESP or not. > > Using MOBIKE would allow MIP6 to work on more implementations as I > guess MOBIKE will be implemented in most of the future IPsec client > style implementations. I.e. if MIP6 could be able to use standard > IPsec + MOBIKE combination, there would be no need for special support > for MIP6 inside the IPsec stack. IMHO, this is not sufficient to add a dependency to MOBIKE for MIPv6. moreover, the main problem with the use of MOBIKE is that it competes to manage the same tunnel as Mobile IP between the mobile node and the home agent. >> the current text is there to address scenarios >> where the identify in the IDi field is not the >> same identity sent in the EAP messages. section >> 3.5 of RFC 4718 does say that there could be >> such cases. it simplifies things if the IDi does >> contain the actual identify of the mobile node. >> I would be happy to remove the text. > > As by IKEv2 RFC we are not sending EAP identifies inside EAP exchange > when using EAP in IKEv2, the IDi field is used in the EAP. I was under the same impression, until Jari pointed out the text in RFC 4718 as part his AD review. this text was added then. would it be ok if I add some text warning that there are implementations out there where EAP implementations out there where the actual identity is carried inside the EAP exchange? >>> So, I would suggest you do recommend NOT to use >>> INTERNAL_ADDRESS_EXPIRY at all, and simply get the address lifetime >>> from the lifetime of the IKEv2 SA, i.e. the server will keep on >>> renewing (if needed, in most cases the IP addresses are allocated from >>> the local pool, so there is no needs to do renewals) the IP address as >>> long as client keeps the IKEv2 SA up, and in case the address for some >>> reason cannot be renewed, or is changed, deletes the IKEv2 SA forcing >>> the client to get new IP address. As we are talking about home address >>> here, there should not really be any problems with the address >>> changing or not being able to renew it. >> if we tie the home address lifetime to the IKE SA >> lifetime, then I am afraid that home address >> assignment through IKEv2 is not going to be popular. >> folks would use other mechanisms to assign the home >> address to the mobile node. a Mobile IP home address >> by definition is supposed to be a long lived address >> that does not change very often. >> >> if there is no restriction that the lifetime in >> INTERNAL_ADDRESS_EXPIRY attribute should always be >> less than the IKEv2 SA lifetime, perhaps MIPv6 could >> use the INTERNAL_ADDRESS_EXPIRY attribute. maybe we >> have found a use for the attribute. ;) > > Hmm... I have been thinking that most of the implementations do limit > the INTERNAL_ADDRESS_EXPIRY to be shorter time than the expected IKE > lifetime, but I do not think there is anything in the specifications > to limit it so. So in that sense it would be ok to specify much longer > time for the INTERNAL_ADDRESS_EXPIRY, but on the other hand as long as > the address is valid all the time during the IKEv2 exchnage there is > no need to give any INTERNAL_ADDRESS_EXPIRY times, as next time you > connect again and get new address, you of course propose the > previous address you already have. > > On the other hand why does the client need to know the time how long > the address is valid? If he has connection to the server (IKEv2 SA, or > MIP6 state) all the time, then the server will probably keep the > address reserved for him all that time, and changing it would cause > lots of problems. > > When client does not have any state with the server (i.e. no IKEv2 SA, > and no MIP6 state anymore), then when it first time connects it will > need to get the address for himself again anyways, and in that case it > can propose the old address, and the server can give it if it is free. > > Also in IPv6 I do not think we can claim that the server needs to > recycle addresses, so most of the time addresses are changed because > client requests so, not because server will run out of IP-addresses. ok. removed the INTERNAL_ADDRESS_EXPIRY attribute. the new text would be When the home agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY contains the prefix length of the home prefix in addition to a 128 bit home address. The home agent could use a local database or contact a DHCPv6 server on the home link to allocate a home address. The duration for which the home address is allocated to the mobile node is the same as the IKEv2 security association lifetime. there is text already in the following paragraph to say that the mobile node can request the same home address again. The mobile node could suggest a home address that it wants to use in the CFG_REQUEST. For example, this could be a home address that it was allocated before or could be an address the mobile node auto- configured from the IPv6 prefix on the home link. The Home Agent could let the mobile node use the same home address by setting the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same home address. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 10:55:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goip1-0000d4-7l; Mon, 27 Nov 2006 10:55:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goiow-0000Vz-AF; Mon, 27 Nov 2006 10:55:02 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Goiot-0000Yn-NK; Mon, 27 Nov 2006 10:55:02 -0500 Received: from [10.1.210.16] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 07:54:55 -0800 Message-ID: <456B0A4F.8080407@azairenet.com> Date: Mon, 27 Nov 2006 07:54:55 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2006 15:54:55.0944 (UTC) FILETIME=[6245FC80:01C7123C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: Francis.Dupont@point6.net, mip6@ietf.org, iesg@ietf.org Subject: [Mip6] Re: Last call comments for draft-ietf-mip6-ikev2-ipsec-07 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Pasi.Eronen@nokia.com wrote: > Vijay Devarapalli wrote: > >>> 3) Section 4.2 says "RFC 3776 required configuration of the security >>> policies per interface in order to be able to >>> differentiate between >>> mobility header messages sent to the home agent and tunneled >>> through the home agent to the correspondent node. Since the >>> Mobility Header message type is a selector, it is now easy to >>> differentiate between HoTi and HoT messages from other mobility >>> header messages. Therefore per-interface configuration >>> of security policies is not required." >>> >>> This is only partially true. RFC 3776 like virtual >>> interfaces would probably still be required if link-layer >>> addresses are used (e.g. for MLD or DHCPv6). >> agreed. >> >> If this is the case, it might be a good >>> idea to explicitly mention that the mechanisms described in this >>> document support payload data protection only for traffic >>> originating/terminating at the home address. >> what if I just modify the last sentence of the above >> paragraph? new text >> >> o RFC 3776 required configuration of the security policies per >> interface in order to be able to differentiate between mobility >> header messages sent to the home agent and tunneled through the >> home agent to the correspondent node. Since the >> Mobility Header message type is a selector, it is now easy >> to differentiate between HoTi and HoT messages from other >> mobility header messages. Therefore per-interface configuration > >> of security policies is not required for protecting mobility >> header messages. > > I don't think the average reader can infer from this text that > payload packet protection will not work the same way without > per-virtual-interface SPDs... so IMHO it would be worthwhile to > say so explicitly: something along the lines "Without per-interface > security policies, payload packet protection is limited to > packets originating/terminating at the home address, and > e.g. link-local traffic is not supported". ok. here is the new text. o RFC 3776 required configuration of the security policies per interface in order to be able to differentiate between mobility header messages sent to the home agent and tunneled through the home agent to the correspondent node. Since the Mobility Header message type is a selector, it is now easy to differentiate between HoTi and HoT messages from other mobility header messages. Therefore per-interface configuration of security policies is not required for protecting mobility header messages. Note that without per-interface security policies. payload packet protection is limited to packets originating/terminating at the home address. Traffic using link local address within the Mobile IP tunnel cannot be provided IPsec protection without per-interface security policies. >>> 7) Section 9: "The Home Agent should also include an >>> INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, >>> the duration for which the dynamically allocated home address is >>> valid." In RFC 4718 (IKEv2 clarifications) we strongly recommend >>> against using the INTERNAL_ADDRESS_EXPIRY attribute. >> Tero also had this comment. I agree the INTERNAL_ADDRESS_EXPIRY does >> not make sense in IKEv2 context. this is what I had written in >> response to Tero's comment. >> >> if we tie the home address lifetime to the IKE SA lifetime, then I >> am afraid that home address assignment through IKEv2 is not going to >> be popular. folks would use other mechanisms to assign the home >> address to the mobile node. a Mobile IP home address by definition >> is supposed to be a long lived address that does not change very >> often. > > Nothing prevents us from keeping the same home address through several > IKE_SAs: when the client connects again, it can request the same > home address it had previously. In other words: the lifetime > is not a single IKE_SA, but at home agents discreption, through > all IKE_SAs between the MN and home agent,. > >> if there is no restriction that the lifetime in >> INTERNAL_ADDRESS_EXPIRY attribute should always be less than the >> IKEv2 SA lifetime, perhaps MIPv6 could use the >> INTERNAL_ADDRESS_EXPIRY attribute. maybe we have found a use for the >> attribute. ;) > > Such a restriction does exist: RFC4306 says that "the requested > address is valid until the expiry time defined with the > INTERNAL_ADDRESS EXPIRY attribute or there are no IKE_SAs between the > peers." So even if INTERNAL_ADDRESS_EXPIRY value is very large, the > address is not valid after all the IKE_SAs are gone (it can become > again valid when new IKE_SA is established, though). ok. removed the INTERNAL_ADDRESS_EXPIRY attribute. the new text would be When the home agent receives a configuration payload with a CFG_REQUEST for INTERNAL_IP6_ADDRESS, it replies with a valid home address for the mobile node. The INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY contains the prefix length of the home prefix in addition to a 128 bit home address. The home agent could use a local database or contact a DHCPv6 server on the home link to allocate a home address. The duration for which the home address is allocated to the mobile node is the same as the IKEv2 security association lifetime. there is text already in the following paragraph to say that the mobile node can request the same home address again. The mobile node could suggest a home address that it wants to use in the CFG_REQUEST. For example, this could be a home address that it was allocated before or could be an address the mobile node auto- configured from the IPv6 prefix on the home link. The Home Agent could let the mobile node use the same home address by setting the INTERNAL_IP6_ADDRESS attribute in the CFG_REPLY payload to the same home address. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 11:05:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goiyo-0006CU-Os; Mon, 27 Nov 2006 11:05:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goiyn-0006C3-FF for mip6@ietf.org; Mon, 27 Nov 2006 11:05:13 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoiyW-0006yA-40 for mip6@ietf.org; Mon, 27 Nov 2006 11:05:13 -0500 Received: from [10.1.210.16] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 08:04:55 -0800 Message-ID: <456B0CA7.7060207@azairenet.com> Date: Mon, 27 Nov 2006 08:04:55 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: mip6@ietf.org Subject: Dealing with INTERNAL_ADDRESS_FAILURE (was Re: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt) References: <455A47DB.3080005@lucent.com> <4568A997.7000204@azairenet.com> In-Reply-To: <4568A997.7000204@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2006 16:04:55.0483 (UTC) FILETIME=[C7A060B0:01C7123D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org folks, any comments on the options below? Vijay Devarapalli wrote: >> 3) In S9, first full paragraph of Page 22: "In case the home agent ... >> an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an >> INTERNAL_ADDRESS_FAILURE message, does it make sense to specify >> what should it do, if anything? > > good catch. the mobile node has the following > options. > > 1. it can attempt to auto-configure a home address > as described in section 5.3.2 of > draft-ietf-mip6-bootstrapping-split-03.txt. the > sequence is a bit complicated though. it has to > terminate the current IKE exchange and initiate a > new one. in the new IKE_AUTH exchange, the MN > should try to auto-configure a home address. > 2. switch to another home agent (most home agent > discovery mechanisms return more than one home > agent). > 3. throw an exception and report and error to the > user. > > 2) seems to be simplest option. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 11:30:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojMW-0003is-8P; Mon, 27 Nov 2006 11:29:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojMT-0003ZB-CM for mip6@ietf.org; Mon, 27 Nov 2006 11:29:41 -0500 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GojHM-0002WT-FC for mip6@ietf.org; Mon, 27 Nov 2006 11:25:12 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1164644649!14079747!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 26116 invoked from network); 27 Nov 2006 16:24:09 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with SMTP; 27 Nov 2006 16:24:09 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id kARGO8Vm011782; Mon, 27 Nov 2006 09:24:08 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id kARGO70W013303; Mon, 27 Nov 2006 10:24:08 -0600 (CST) Message-ID: <456B1127.2040500@motorola.com> Date: Mon, 27 Nov 2006 17:24:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: Dealing with INTERNAL_ADDRESS_FAILURE (was Re: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt) References: <455A47DB.3080005@lucent.com> <4568A997.7000204@azairenet.com> <456B0CA7.7060207@azairenet.com> In-Reply-To: <456B0CA7.7060207@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > folks, > > any comments on the options below? Maybe cast a insecure DHAAD Request followed by a MPD Sol and then IKE again? Alex > > Vijay Devarapalli wrote: > >>> 3) In S9, first full paragraph of Page 22: "In case the home agent ... >>> an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an >>> INTERNAL_ADDRESS_FAILURE message, does it make sense to specify >>> what should it do, if anything? >> >> good catch. the mobile node has the following >> options. >> >> 1. it can attempt to auto-configure a home address >> as described in section 5.3.2 of >> draft-ietf-mip6-bootstrapping-split-03.txt. the >> sequence is a bit complicated though. it has to >> terminate the current IKE exchange and initiate a >> new one. in the new IKE_AUTH exchange, the MN >> should try to auto-configure a home address. >> 2. switch to another home agent (most home agent >> discovery mechanisms return more than one home >> agent). >> 3. throw an exception and report and error to the >> user. >> >> 2) seems to be simplest option. > > Vijay > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 12:48:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gokas-00015L-6O; Mon, 27 Nov 2006 12:48:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokaO-0000kk-LX for mip6@ietf.org; Mon, 27 Nov 2006 12:48:08 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GokXm-0007WM-1O for mip6@ietf.org; Mon, 27 Nov 2006 12:45:27 -0500 Received: from [10.1.201.0] ([66.92.223.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 09:45:24 -0800 Message-ID: <456B22F5.20202@azairenet.com> Date: Mon, 27 Nov 2006 09:40:05 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Dealing with INTERNAL_ADDRESS_FAILURE (was Re: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt) References: <455A47DB.3080005@lucent.com> <4568A997.7000204@azairenet.com> <456B0CA7.7060207@azairenet.com> <456B1127.2040500@motorola.com> In-Reply-To: <456B1127.2040500@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2006 17:45:24.0859 (UTC) FILETIME=[D16A24B0:01C7124B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> folks, >> >> any comments on the options below? > > Maybe cast a insecure DHAAD Request it does not matter which HA discovery is used. the question is more about whether we should start using another HA or try again with the current HA but this time with auto-configuration for the home address. > followed by a MPD Sol MPD cannot be run until the Mobile IP tunnel is up. Vijay and then IKE > again? > > Alex > >> >> Vijay Devarapalli wrote: >> >>>> 3) In S9, first full paragraph of Page 22: "In case the home agent ... >>>> an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an >>>> INTERNAL_ADDRESS_FAILURE message, does it make sense to specify >>>> what should it do, if anything? >>> >>> good catch. the mobile node has the following >>> options. >>> >>> 1. it can attempt to auto-configure a home address >>> as described in section 5.3.2 of >>> draft-ietf-mip6-bootstrapping-split-03.txt. the >>> sequence is a bit complicated though. it has to >>> terminate the current IKE exchange and initiate a >>> new one. in the new IKE_AUTH exchange, the MN >>> should try to auto-configure a home address. >>> 2. switch to another home agent (most home agent >>> discovery mechanisms return more than one home >>> agent). >>> 3. throw an exception and report and error to the >>> user. >>> >>> 2) seems to be simplest option. >> >> Vijay >> >> >> _______________________________________________ >> Mip6 mailing list >> Mip6@ietf.org >> https://www1.ietf.org/mailman/listinfo/mip6 >> > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 12:55:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gokgz-0006U3-RP; Mon, 27 Nov 2006 12:54:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gokgx-0006QV-PH for mip6@ietf.org; Mon, 27 Nov 2006 12:54:55 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gokgw-0000yz-E1 for mip6@ietf.org; Mon, 27 Nov 2006 12:54:55 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-7.tower-128.messagelabs.com!1164650050!4484336!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 29065 invoked from network); 27 Nov 2006 17:54:10 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-7.tower-128.messagelabs.com with SMTP; 27 Nov 2006 17:54:10 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id kARHs9r1027396; Mon, 27 Nov 2006 10:54:09 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id kARHs71J006837; Mon, 27 Nov 2006 11:54:08 -0600 (CST) Message-ID: <456B263F.4010003@motorola.com> Date: Mon, 27 Nov 2006 18:54:07 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: Dealing with INTERNAL_ADDRESS_FAILURE (was Re: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt) References: <455A47DB.3080005@lucent.com> <4568A997.7000204@azairenet.com> <456B0CA7.7060207@azairenet.com> <456B1127.2040500@motorola.com> <456B22F5.20202@azairenet.com> In-Reply-To: <456B22F5.20202@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> folks, >>> >>> any comments on the options below? >> >> Maybe cast a insecure DHAAD Request > > it does not matter which HA discovery is used. the > question is more about whether we should start using > another HA or try again with the current HA but this > time with auto-configuration for the home address. If the question is so, I'd say start using another HA (not try same HA but with auto-config). Just one oppinion. >> followed by a MPD Sol > > MPD cannot be run until the Mobile IP tunnel is up. (Not sure about that. 3775 says MPD should be ESPed. If we relax that and run IKE afterwards I don't see an inconvenient. You may disagree.) Alex > > Vijay > > > and then IKE >> again? >> >> Alex >> >>> >>> Vijay Devarapalli wrote: >>> >>>>> 3) In S9, first full paragraph of Page 22: "In case the home agent ... >>>>> an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an >>>>> INTERNAL_ADDRESS_FAILURE message, does it make sense to specify >>>>> what should it do, if anything? >>>> >>>> good catch. the mobile node has the following >>>> options. >>>> >>>> 1. it can attempt to auto-configure a home address >>>> as described in section 5.3.2 of >>>> draft-ietf-mip6-bootstrapping-split-03.txt. the >>>> sequence is a bit complicated though. it has to >>>> terminate the current IKE exchange and initiate a >>>> new one. in the new IKE_AUTH exchange, the MN >>>> should try to auto-configure a home address. >>>> 2. switch to another home agent (most home agent >>>> discovery mechanisms return more than one home >>>> agent). >>>> 3. throw an exception and report and error to the >>>> user. >>>> >>>> 2) seems to be simplest option. >>> >>> Vijay >>> >>> >>> _______________________________________________ >>> Mip6 mailing list >>> Mip6@ietf.org >>> https://www1.ietf.org/mailman/listinfo/mip6 >>> >> > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 13:00:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gokm3-0001ed-OE; Mon, 27 Nov 2006 13:00:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gokm2-0001eW-Bn for mip6@ietf.org; Mon, 27 Nov 2006 13:00:10 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gokm1-0001gx-0H for mip6@ietf.org; Mon, 27 Nov 2006 13:00:10 -0500 Received: from [10.1.201.0] ([66.92.223.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 10:00:07 -0800 Message-ID: <456B266E.6060503@azairenet.com> Date: Mon, 27 Nov 2006 09:54:54 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.7 (X11/20060927) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: Dealing with INTERNAL_ADDRESS_FAILURE (was Re: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt) References: <455A47DB.3080005@lucent.com> <4568A997.7000204@azairenet.com> <456B0CA7.7060207@azairenet.com> <456B1127.2040500@motorola.com> <456B22F5.20202@azairenet.com> <456B263F.4010003@motorola.com> In-Reply-To: <456B263F.4010003@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Nov 2006 18:00:07.0910 (UTC) FILETIME=[DFC10860:01C7124D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> Alexandru Petrescu wrote: >>> Vijay Devarapalli wrote: >>>> folks, >>>> >>>> any comments on the options below? >>> >>> Maybe cast a insecure DHAAD Request >> >> it does not matter which HA discovery is used. the >> question is more about whether we should start using >> another HA or try again with the current HA but this >> time with auto-configuration for the home address. > > If the question is so, I'd say start using another HA (not try same HA > but with auto-config). Just one oppinion. thats option 2 in my mail below. >>> followed by a MPD Sol >> >> MPD cannot be run until the Mobile IP tunnel is up. > > (Not sure about that. 3775 says MPD should be ESPed. right. but without running IKE an IPsec SA is not available for protecting the MPD messages. IKE_AUTH has already failed because the HA cannot give out a home address to the mobile node. Vijay If we relax > that and run IKE afterwards I don't see an inconvenient. You may > disagree.) > > Alex > >> >> Vijay >> >> >> and then IKE >>> again? >>> >>> Alex >>> >>>> >>>> Vijay Devarapalli wrote: >>>> >>>>>> 3) In S9, first full paragraph of Page 22: "In case the home agent >>>>>> ... >>>>>> an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an >>>>>> INTERNAL_ADDRESS_FAILURE message, does it make sense to specify >>>>>> what should it do, if anything? >>>>> >>>>> good catch. the mobile node has the following >>>>> options. >>>>> >>>>> 1. it can attempt to auto-configure a home address >>>>> as described in section 5.3.2 of >>>>> draft-ietf-mip6-bootstrapping-split-03.txt. the >>>>> sequence is a bit complicated though. it has to >>>>> terminate the current IKE exchange and initiate a >>>>> new one. in the new IKE_AUTH exchange, the MN >>>>> should try to auto-configure a home address. >>>>> 2. switch to another home agent (most home agent >>>>> discovery mechanisms return more than one home >>>>> agent). >>>>> 3. throw an exception and report and error to the >>>>> user. >>>>> >>>>> 2) seems to be simplest option. >>>> >>>> Vijay >>>> >>>> >>>> _______________________________________________ >>>> Mip6 mailing list >>>> Mip6@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>> >> >> > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 13:07:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoksP-0006IL-Mz; Mon, 27 Nov 2006 13:06:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoksO-0006G8-ME for mip6@ietf.org; Mon, 27 Nov 2006 13:06:44 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GoksL-0002fU-CA for mip6@ietf.org; Mon, 27 Nov 2006 13:06:44 -0500 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@motorola.com X-Msg-Ref: server-11.tower-128.messagelabs.com!1164650797!6414140!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 10816 invoked from network); 27 Nov 2006 18:06:37 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-11.tower-128.messagelabs.com with SMTP; 27 Nov 2006 18:06:37 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id kARI6b7h009550; Mon, 27 Nov 2006 11:06:37 -0700 (MST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id kARI6YJ1021120; Mon, 27 Nov 2006 12:06:36 -0600 (CST) Message-ID: <456B292A.2050205@motorola.com> Date: Mon, 27 Nov 2006 19:06:34 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: Dealing with INTERNAL_ADDRESS_FAILURE (was Re: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt) References: <455A47DB.3080005@lucent.com> <4568A997.7000204@azairenet.com> <456B0CA7.7060207@azairenet.com> <456B1127.2040500@motorola.com> <456B22F5.20202@azairenet.com> <456B263F.4010003@motorola.com> <456B266E.6060503@azairenet.com> In-Reply-To: <456B266E.6060503@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> Vijay Devarapalli wrote: >>> Alexandru Petrescu wrote: >>>> Vijay Devarapalli wrote: >>>>> folks, >>>>> >>>>> any comments on the options below? >>>> >>>> Maybe cast a insecure DHAAD Request >>> >>> it does not matter which HA discovery is used. the >>> question is more about whether we should start using >>> another HA or try again with the current HA but this >>> time with auto-configuration for the home address. >> >> If the question is so, I'd say start using another HA (not try same HA >> but with auto-config). Just one oppinion. > > thats option 2 in my mail below. SO we agree. >>>> followed by a MPD Sol >>> >>> MPD cannot be run until the Mobile IP tunnel is up. >> >> (Not sure about that. 3775 says MPD should be ESPed. > > right. but without running IKE an IPsec SA is not > available for protecting the MPD messages. (not true I run shared keys). Alex _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 15:18:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gomuy-0004j2-V6; Mon, 27 Nov 2006 15:17:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gomux-0004iq-0q for mip6@ietf.org; Mon, 27 Nov 2006 15:17:31 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gomuu-000630-M2 for mip6@ietf.org; Mon, 27 Nov 2006 15:17:31 -0500 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id kARKHNpP024412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 27 Nov 2006 12:17:23 -0800 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.141.78]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id kARKG7Qa030100; Mon, 27 Nov 2006 12:17:20 -0800 Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 12:16:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Re: Review of the draft-ietf-mip6-ikev2-ipsec-07.txt Date: Mon, 27 Nov 2006 12:16:50 -0800 Message-ID: In-Reply-To: <456A0655.5000401@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip6] Re: Review of the draft-ietf-mip6-ikev2-ipsec-07.txt Thread-Index: AccRpPiyG4M3wHzZRuG173Xznao6XwAuwJSg From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Tero Kivinen" X-OriginalArrivalTime: 27 Nov 2006 20:16:53.0948 (UTC) FILETIME=[FAEF0FC0:01C71260] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org >=20 > RFC 3775 describes the use of a flag (K) in the binding=20 > update/binding ack messages to signal the capability to=20 > update the IPsec SA when the MIP tunnel end point is updated.=20 > this document does not modify that. >=20 You mean the IKE_SA? I don't see any text in RFC3775 that describes updating the IPsec SA - I guess the assumption was that the IPsec SA is based on the HoA and it survives movements. However, when ESP is used in tunnel mode, this would imply changing the tunnel outer address. Is that captured anywhere?=20 Vidya _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Nov 27 19:23:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoqjY-0007yr-Bv; Mon, 27 Nov 2006 19:22:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoqjW-0007ym-PX for mip6@ietf.org; Mon, 27 Nov 2006 19:21:58 -0500 Received: from mail2.azairenet.com ([66.92.223.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoqjV-0007IW-A8 for mip6@ietf.org; Mon, 27 Nov 2006 19:21:58 -0500 Received: from [10.1.201.11] ([66.92.223.6]) by mail2.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 16:21:55 -0800 Message-ID: <456B811F.2070409@azairenet.com> Date: Mon, 27 Nov 2006 16:21:51 -0800 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip6] Re: Review of the draft-ietf-mip6-ikev2-ipsec-07.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2006 00:21:55.0220 (UTC) FILETIME=[35932540:01C71283] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: mip6@ietf.org, Tero Kivinen X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Narayanan, Vidya wrote: > > >> RFC 3775 describes the use of a flag (K) in the binding >> update/binding ack messages to signal the capability to >> update the IPsec SA when the MIP tunnel end point is updated. >> this document does not modify that. >> > > You mean the IKE_SA? I don't see any text in RFC3775 that describes > updating the IPsec SA - I guess the assumption was that the IPsec SA is > based on the HoA and it survives movements. However, when ESP is used in > tunnel mode, this would imply changing the tunnel outer address. Is that > captured anywhere? from RFC 3775 Key Management Mobility Capability (K) If this bit is cleared, the protocol used for establishing the IPsec security associations between the mobile node and the home agent does not survive movements. It may then have to be rerun. (Note that the IPsec security associations themselves are expected to survive movements.) If manual IPsec configuration is used, the bit MUST be cleared. the K bit has always been for the protocol that setup the IPsec security associations, which means IKEv2. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Nov 28 04:49:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goza2-0006gS-EA; Tue, 28 Nov 2006 04:48:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goza1-0006fd-7h for mip6@ietf.org; Tue, 28 Nov 2006 04:48:45 -0500 Received: from cluster-b.mailcontrol.com ([217.68.146.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GozZy-0000sk-NT for mip6@ietf.org; Tue, 28 Nov 2006 04:48:45 -0500 Received: from rly16b.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly16b.srv.mailcontrol.com (MailControl) with ESMTP id kAS9mcHF031374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Nov 2006 09:48:38 GMT Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly16b.srv.mailcontrol.com (MailControl) id kAS9mYK6031109 for mip6@ietf.org; Tue, 28 Nov 2006 09:48:34 GMT Received: from hhe500-02.hbg.de.pan.eu (gate.eu.panasonic.com [194.173.20.12]) by rly16b-eth0.srv.mailcontrol.com (envelope-sender Kilian.Weniger@eu.panasonic.com) (MIMEDefang) with ESMTP id kAS9mWMp031023; Tue, 28 Nov 2006 09:48:34 +0000 (GMT) Received: from eundadmi01.pan.eu(10.100.96.64) by hhe500-02.hbg.de.pan.eu via smtp id 3ebd_b458bb38_7ec1_11db_91e6_0030482aac25; Tue, 28 Nov 2006 10:20:35 +0100 Received: from VPN-MRelay-01.PRDCG.Panasonic.de ([10.100.176.55]) by eundadmi01.pan.eu (Lotus Domino Release 6.5.4FP3) with ESMTP id 2006112810482425-292597 ; Tue, 28 Nov 2006 10:48:24 +0100 X-Spam-Status: No, hits=0.0 required=4.5 tests=AWL: -0.250,BAYES_00: -1.665,TOTAL_SCORE: -1.915 X-Spam-Level: Received: from localhost ([127.0.0.1]) by VPN-MRelay-01.PRDCG.Panasonic.de; Tue, 28 Nov 2006 10:52:46 +0100 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: Dealing with INTERNAL_ADDRESS_FAILURE (was Re: [Mip6] Re: Gen-ARTreview of draft-ietf-mip6-ikev2-ipsec-07.txt) In-Reply-To: <456B0CA7.7060207@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dealing with INTERNAL_ADDRESS_FAILURE (was Re: [Mip6] Re: Gen-ARTreview of draft-ietf-mip6-ikev2-ipsec-07.txt) Thread-Index: AccSP5ftj9sclsNHShqTmmfEl1BujwAjE8iw To: "Vijay Devarapalli" Message-ID: <4D2F935F08D41A4C8866693F4F0D7C4F01084D64@lan-ex-01.panasonic.de> Date: Tue, 28 Nov 2006 10:47:31 +0100 From: "Kilian Weniger" Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MailControl A-07-06-80 (www.mailcontrol.com) on 10.66.1.126 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi Vijay, what are reasons for the INTERNAL_ADDRESS_FAILURE? Two reasons that come to my mind are that the home agent consults a DHCP server on the home link but the DHCP server is down or that the address pool of the DHCP server (or a pool internal in the home agent) is empty, i.e., all addresses are allocated. Any other reasons? If the new home agent uses the same DHCP server/address pool, option 2 wouldn't help, since the allocation would fail again. In contrast, option 1 should always work (unless the auto-configured address is duplicate). So depending on the deployment scenario, option 1 may have higher chances to succeed, in which case it would be better to go for option 1. Option 3 should be done if the allocation fails after multiple retries IMHO. My two cents. -Kilian > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Montag, 27. November 2006 17:05 > To: mip6@ietf.org > Subject: Dealing with INTERNAL_ADDRESS_FAILURE (was Re:=20 > [Mip6] Re: Gen-ARTreview of draft-ietf-mip6-ikev2-ipsec-07.txt) >=20 > folks, >=20 > any comments on the options below? >=20 > Vijay Devarapalli wrote: >=20 > >> 3) In S9, first full paragraph of Page 22: "In case the=20 > home agent ... > >> an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an > >> INTERNAL_ADDRESS_FAILURE message, does it make sense to specify > >> what should it do, if anything? > >=20 > > good catch. the mobile node has the following > > options. > >=20 > > 1. it can attempt to auto-configure a home address > > as described in section 5.3.2 of > > draft-ietf-mip6-bootstrapping-split-03.txt. the > > sequence is a bit complicated though. it has to > > terminate the current IKE exchange and initiate a > > new one. in the new IKE_AUTH exchange, the MN > > should try to auto-configure a home address. > > 2. switch to another home agent (most home agent > > discovery mechanisms return more than one home > > agent). > > 3. throw an exception and report and error to the > > user. > >=20 > > 2) seems to be simplest option. >=20 > Vijay >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Nov 29 17:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXpv-0004cy-Ja; Wed, 29 Nov 2006 17:23:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpXpu-0004ct-Sj for mip6@ietf.org; Wed, 29 Nov 2006 17:23:26 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GpXpt-0006qG-DJ for mip6@ietf.org; Wed, 29 Nov 2006 17:23:26 -0500 Received: (qmail invoked by alias); 29 Nov 2006 22:23:23 -0000 Received: from unknown (EHLO [172.16.68.1]) [83.210.8.3] by mail.gmx.net (mp036) with SMTP; 29 Nov 2006 23:23:23 +0100 X-Authenticated: #29516787 Message-ID: <456E0839.7070806@gmx.net> Date: Wed, 29 Nov 2006 23:22:49 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 1.5.0.8 (X11/20061025) MIME-Version: 1.0 To: mip6@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Mip6] MIP6 Firewall Traversal Design Team X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Hi all, This message, in accordance with IETF procedures, is to inform the MIP6 working group that the MIP6 co-chairs have commissioned a MIP6 Firewall Traversal design team. The purpose of this design team is to complete the following WG charter item: " Work on solutions to deal with firewalls and the problems that firewalls cause as identified in RFC 4487. " The output of the design team is one or more document(s) to the MIP6 working group. This design team will use a separate mailing list, conference calls and Jabber chats. Members of the design team are: Hannes Tschofenig: Hannes.Tschofenig@gmx.net Gabor Bajko: Gabor.Bajko@nokia.com Suresh Krishnan: suresh.krishnan@ericsson.com Hesham Soliman: solimanhs@gmail.com Yaron Sheffer: yaronf@checkpoint.com Qiu Ying: qiuying@i2r.a-star.edu.sg Ram Vishnu: vishnu@motorola.com Niklas Steinleitner: steinleitner@cs.uni-goettingen.de The following hat wearers are also take part: Basavaraj Patil: basavaraj.patil@nokia.com Gopal Dommety: gdommety@cisco.com Archives of this design team can be found here: http://zeke.ecotroph.net/pipermail/mip6-firewall/ As with any design team in the IETF, the output of this design team must be approved by the MIP6 working group nor carries any special consideration in development of MIP6 working group consensus. Ciao Hannes PS: I would like to thank Andy Newton for setting up the mailing list. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 30 13:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpquK-00020Q-LY; Thu, 30 Nov 2006 13:45:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go4ok-0006Xh-M4; Sat, 25 Nov 2006 16:12:10 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go4oi-0007KA-91; Sat, 25 Nov 2006 16:12:10 -0500 Received: by machshav.com (Postfix, from userid 512) id 963FFFB485; Sat, 25 Nov 2006 21:12:01 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9E8BDFB47E; Sat, 25 Nov 2006 21:12:00 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 1912C3C0881; Sat, 25 Nov 2006 16:11:59 -0500 (EST) Date: Sat, 25 Nov 2006 16:11:59 -0500 From: "Steven M. Bellovin" To: Vijay Devarapalli In-Reply-To: <4568B059.4030401@azairenet.com> References: <20061111151215.b54defd1.smb@cs.columbia.edu> <4568B059.4030401@azairenet.com> Organization: Columbia University X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061125211159.1912C3C0881@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Thu, 30 Nov 2006 13:45:15 -0500 Cc: Francis.Dupont@point6.net, secdir@mit.edu, housley@vigilsec.com, mip6@ietf.org, iesg@ietf.org, hartmans-ietf@mit.edu, mip6-chairs@ietf.org Subject: [Mip6] Re: secdir review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Sat, 25 Nov 2006 13:06:33 -0800 Vijay Devarapalli wrote: > hi Steve, > > thanks for the review. > > Steven M. Bellovin wrote: > > One obvious problem: Section 4.1 notes that 3775 requires support > > for manual key management, and lists IKE support as a "MAY". > > However, 4107 -- a BCP which came out after 3775 -- establishes a > > strong presumption that automated key management automated key > > management be used. Accordingly, this draft should mandate support > > for IKEv2, as it does not appear to fall under any of the > > exceptions. > > this was discussed on the MIP6 mailing list. it was > felt that this particular draft should not update > this part of RFC 3775. draft-ietf-mip6-ikev2-ipsec > only describes how IKEv2 should be used with MIPv6. > not whether MIPv6 MUST use IKEv2. that belongs in > the MIPv6 base specification. I think it is best > handled when RFC 3775 is revised. I'll leave that one to the IESG. > > > 4.3 says that anti-replay is optional. However, Section 1 of 3776 > > says that anti-replay is required, though it notes that it can't be > > done properly without IKE. Assuming that IKEv2 is mandated here, > > anti-replay should be as well. > > the primary mechanism for anti-replay protection > for the binding updates is the sequence number in > the binding updates. the only time this fails is > when the home agent looses the binding cache state > (for e.g. it reboots). in this case, dynamic keying > (through IKEv2) provides replay protection since a > new security association for protecting the BU is > negotiated automatically (since the home agent lost > all state). any binding updates protected by the > old IPsec SA will not be accepted. hope that > clarifies the text. > Makes sense -- but similar text should be in the draft to clarify it. --Steve Bellovin, http://www.cs.coluFrom mip6-bounces@ietf.org Thu Nov 30 13:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpquK-00020Q-LY; Thu, 30 Nov 2006 13:45:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go4ok-0006Xh-M4; Sat, 25 Nov 2006 16:12:10 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go4oi-0007KA-91; Sat, 25 Nov 2006 16:12:10 -0500 Received: by machshav.com (Postfix, from userid 512) id 963FFFB485; Sat, 25 Nov 2006 21:12:01 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9E8BDFB47E; Sat, 25 Nov 2006 21:12:00 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 1912C3C0881; Sat, 25 Nov 2006 16:11:59 -0500 (EST) Date: Sat, 25 Nov 2006 16:11:59 -0500 From: "Steven M. Bellovin" To: Vijay Devarapalli In-Reply-To: <4568B059.4030401@azairenet.com> References: <20061111151215.b54defd1.smb@cs.columbia.edu> <4568B059.4030401@azairenet.com> Organization: Columbia University X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061125211159.1912C3C0881@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Thu, 30 Nov 2006 13:45:15 -0500 Cc: Francis.Dupont@point6.net, secdir@mit.edu, housley@vigilsec.com, mip6@ietf.org, iesg@ietf.org, hartmans-ietf@mit.edu, mip6-chairs@ietf.org Subject: [Mip6] Re: secdir review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Sat, 25 Nov 2006 13:06:33 -0800 Vijay Devarapalli wrote: > hi Steve, > > thanks for the review. > > Steven M. Bellovin wrote: > > One obvious problem: Section 4.1 notes that 3775 requires support > > for manual key management, and lists IKE support as a "MAY". > > However, 4107 -- a BCP which came out after 3775 -- establishes a > > strong presumption that automated key management automated key > > management be used. Accordingly, this draft should mandate support > > for IKEv2, as it does not appear to fall under any of the > > exceptions. > > this was discussed on the MIP6 mailing list. it was > felt that this particular draft should not update > this part of RFC 3775. draft-ietf-mip6-ikev2-ipsec > only describes how IKEv2 should be used with MIPv6. > not whether MIPv6 MUST use IKEv2. that belongs in > the MIPv6 base specification. I think it is best > handled when RFC 3775 is revised. I'll leave that one to the IESG. > > > 4.3 says that anti-replay is optional. However, Section 1 of 3776 > > says that anti-replay is required, though it notes that it can't be > > done properly without IKE. Assuming that IKEv2 is mandated here, > > anti-replay should be as well. > > the primary mechanism for anti-replay protection > for the binding updates is the sequence number in > the binding updates. the only time this fails is > when the home agent looses the binding cache state > (for e.g. it reboots). in this case, dynamic keying > (through IKEv2) provides replay protection since a > new security association for protecting the BU is > negotiated automatically (since the home agent lost > all state). any binding updates protected by the > old IPsec SA will not be accepted. hope that > clarifies the text. > Makes sense -- but similar text should be in the draft to clarify it. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 30 13:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpquM-00021n-7s; Thu, 30 Nov 2006 13:45:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiPB-0007Ep-TI; Mon, 27 Nov 2006 10:28:25 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoiP9-00016i-IO; Mon, 27 Nov 2006 10:28:25 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kARFSLZF008858; Mon, 27 Nov 2006 09:28:21 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kARFSKC14281; Mon, 27 Nov 2006 09:28:20 -0600 (CST) Message-ID: <456B0414.6040905@lucent.com> Date: Mon, 27 Nov 2006 09:28:20 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <455A47DB.3080005@lucent.com> <4568A997.7000204@azairenet.com> In-Reply-To: <4568A997.7000204@azairenet.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 X-Mailman-Approved-At: Thu, 30 Nov 2006 13:45:15 -0500 Cc: mip6@ietf.org, gen-art@ietf.org Subject: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0906091368==" Errors-To: mip6-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0906091368== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010600050704000400060501" This is a cryptographically signed message in MIME format. --------------ms010600050704000400060501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> 1) In S4, the authors state that "Many of the requirements are repeated >> from RFC3776 to make this document self-contained and complete." >> There are a fair number of requirements in subsequent sub-sections. >> It may help if the authors tag each requirement that was already >> present in RFC3776, so the reader can see which new requirement was >> generated by this draft. > > we would like to keep this document self-contained, > basically one needn't refer to RFC 3776 at all to > implement this spec. the very initial versions of > the document were written with only the new > requirements listed, but folks didn't like it. OK. More inline. >> 3) In S9, first full paragraph of Page 22: "In case the home agent ... >> an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an >> INTERNAL_ADDRESS_FAILURE message, does it make sense to specify >> what should it do, if anything? > > good catch. the mobile node has the following > options. > > 1. it can attempt to auto-configure a home address > as described in section 5.3.2 of > draft-ietf-mip6-bootstrapping-split-03.txt. the > sequence is a bit complicated though. it has to > terminate the current IKE exchange and initiate a > new one. in the new IKE_AUTH exchange, the MN > should try to auto-configure a home address. > 2. switch to another home agent (most home agent >mbia.edu/~smb _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 30 13:46:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpquM-00021n-7s; Thu, 30 Nov 2006 13:45:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiPB-0007Ep-TI; Mon, 27 Nov 2006 10:28:25 -0500 Received: from ihemail1.lucent.com ([135.245.0.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoiP9-00016i-IO; Mon, 27 Nov 2006 10:28:25 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id kARFSLZF008858; Mon, 27 Nov 2006 09:28:21 -0600 (CST) Received: from [135.185.244.90] (il0015vkg1.ih.lucent.com [135.185.244.90]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id kARFSKC14281; Mon, 27 Nov 2006 09:28:20 -0600 (CST) Message-ID: <456B0414.6040905@lucent.com> Date: Mon, 27 Nov 2006 09:28:20 -0600 From: "Vijay K. Gurbani" Organization: Bell Labs Security Technology Research Group User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli References: <455A47DB.3080005@lucent.com> <4568A997.7000204@azairenet.com> In-Reply-To: <4568A997.7000204@azairenet.com> X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 X-Mailman-Approved-At: Thu, 30 Nov 2006 13:45:15 -0500 Cc: mip6@ietf.org, gen-art@ietf.org Subject: [Mip6] Re: Gen-ART review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0906091368==" Errors-To: mip6-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============0906091368== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010600050704000400060501" This is a cryptographically signed message in MIME format. --------------ms010600050704000400060501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >> 1) In S4, the authors state that "Many of the requirements are repeated >> from RFC3776 to make this document self-contained and complete." >> There are a fair number of requirements in subsequent sub-sections. >> It may help if the authors tag each requirement that was already >> present in RFC3776, so the reader can see which new requirement was >> generated by this draft. > > we would like to keep this document self-contained, > basically one needn't refer to RFC 3776 at all to > implement this spec. the very initial versions of > the document were written with only the new > requirements listed, but folks didn't like it. OK. More inline. >> 3) In S9, first full paragraph of Page 22: "In case the home agent ... >> an INTERNAL_ADDRESS_FAILURE message." If a mobile node gets an >> INTERNAL_ADDRESS_FAILURE message, does it make sense to specify >> what should it do, if anything? > > good catch. the mobile node has the following > options. > > 1. it can attempt to auto-configure a home address > as described in section 5.3.2 of > draft-ietf-mip6-bootstrapping-split-03.txt. the > sequence is a bit complicated though. it has to > terminate the current IKE exchange and initiate a > new one. in the new IKE_AUTH exchange, the MN > should try to auto-configure a home address. > 2. switch to another home agent (most home agent > discovery mechanisms return more than one home > agent). > 3. throw an exception and report and error to the > user. > > 2) seems to be simplest option. > > comments? I am viewing this from a generalist angle; so please filter what I write through your subject matter expert lens. It appears to me that (2) sounds reasonable, and if all the subsequent home agents should return an INTERNAL_ADDRESS_FAILURE (for whatever reason), then (3) should kick in. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms010600050704000400060501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIlPjCC Ch4wggkGoAMCAQICCh6WhFwAAAAACpUwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA2MDYyNjE2MTI1M1oXDTA4MDYyNjE2MjI1M1owQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsCokOtoH/zOzgQOoH5wBSXpXbUvvzpuM4u5y pSGFeBeTKuTzew3EvxcAB7r1gHMNTgMXvCaLs6o9VUkoQQKaWGNXXZqLkkkCbHr+KD82IAmO OXqKJtYvNOlraQahXTKlrG6+oT6VFa9BIza/uSZ2DKPcscoVSBBEmbC8Zoh7lH7/sl6BveFg j1e0rTrC4ml90zVnxFnz2ARTExawUx7hyVKLmWy84egc6yDh7sc5B+6NbJv1GdSJOASJbNcL LvxihE2wgD71nhRtWzMAdzg4nsd8yI9bshUGqYbiiKC9GrV9NN7AJ0WsLQtLYs+1dcuMNXlL caEyIxTCcmZwnYNsowIDAQABo4IGpDCCBqAwHQYDVR0OBBYEFNNWvr2U2hSbKzlP8W4ih6m5 pjNMMIH+BgNVHSMEgfYwgfOAFISfQVWcEIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJ KoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UE CBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBU ZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1 Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPy LGQBAQQFFgN2a2cwFwYKCZImiZPyLGQBLAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIF oDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcD BzCCAncGCCsGAQUFBwEBBIICaTCCAmUwgc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNl YXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZp Y2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAx LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZp Y2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHM BggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIIC gTCCAn0wgdaggdOggdCGgc1sZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2Nu PUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVy ZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDovL2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0 aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxp c3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB 0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRl Y2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRp b24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlz dDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR discovery mechanisms return more than one home > agent). > 3. throw an exception and report and error to the > user. > > 2) seems to be simplest option. > > comments? I am viewing this from a generalist angle; so please filter what I write through your subject matter expert lens. It appears to me that (2) sounds reasonable, and if all the subsequent home agents should return an INTERNAL_ADDRESS_FAILURE (for whatever reason), then (3) should kick in. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Bell Laboratories, Lucent Technologies, Inc. 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA) --------------ms010600050704000400060501 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIlPjCC Ch4wggkGoAMCAQICCh6WhFwAAAAACpUwDQYJKoZIhvcNAQEFBQAwgbIxJTAjBgkqhkiG9w0B CQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcg SmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xv Z2llczEzMDEGA1UEAxMqTHVjZW50IFRlY2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNl cyAxMB4XDTA2MDYyNjE2MTI1M1oXDTA4MDYyNjE2MjI1M1owQTEdMBsGCSqGSIb3DQEJARYO dmtnQGx1Y2VudC5jb20xIDAeBgNVBAMTF1ZpamF5IEsgR3VyYmFuaSAoVmlqYXkpMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsCokOtoH/zOzgQOoH5wBSXpXbUvvzpuM4u5y pSGFeBeTKuTzew3EvxcAB7r1gHMNTgMXvCaLs6o9VUkoQQKaWGNXXZqLkkkCbHr+KD82IAmO OXqKJtYvNOlraQahXTKlrG6+oT6VFa9BIza/uSZ2DKPcscoVSBBEmbC8Zoh7lH7/sl6BveFg j1e0rTrC4ml90zVnxFnz2ARTExawUx7hyVKLmWy84egc6yDh7sc5B+6NbJv1GdSJOASJbNcL LvxihE2wgD71nhRtWzMAdzg4nsd8yI9bshUGqYbiiKC9GrV9NN7AJ0WsLQtLYs+1dcuMNXlL caEyIxTCcmZwnYNsowIDAQABo4IGpDCCBqAwHQYDVR0OBBYEFNNWvr2U2hSbKzlP8W4ih6m5 pjNMMIH+BgNVHSMEgfYwgfOAFISfQVWcEIhPO03ThDp+IUtPSt/LoYHOpIHLMIHIMSUwIwYJ KoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UE CBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBU ZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1 Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHmCCmEMFx0AAAAAAAUwEwYKCZImiZPy LGQBAQQFFgN2a2cwFwYKCZImiZPyLGQBLAQJFgczNzA5NDM4MBEGCWCGSAGG+EIBAQQEAwIF oDALBgNVHQ8EBAMCA/gwJwYDVR0lBCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMEBggrBgEFBQcD BzCCAncGCCsGAQUFBwEBBIICaTCCAmUwgc4GCCsGAQUFBzAChoHBbGRhcDovL2xkYXAtdXNl YXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBDZXJ0aWZp Y2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1s dWNlbnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlm aWNhdGlvbkF1dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC5sdWNlbnQuY29t L2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAx LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZp Y2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHM BggrBgEFBQcwAoaBv2xkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2Vu dCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIICigYDVR0fBIIC gTCCAn0wgdaggdOggdCGgc1sZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2Nu PUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91 PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVy ZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MIHKoIHHoIHEhoHBbGRhcDovL2xkYXAubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBU ZWNobm9sb2dpZXMlMjBDZXJ0aWZpY2F0ZSUyMFNlcnZpY2VzJTIwMSxvdT1DZXJ0aWZpY2F0 aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxp c3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCB1KCB 0aCBzoaBy2xkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRl Y2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRp b24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlz dDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MA0GCSqG SIb3DQEBBQUAA4IBAQCZpf5cNwck4S9qjuX6Hfo+FWFtWTIPMPGVwsMVYz97hmEPKzxA8zMP aO0Z9+FD75ZBc2GkZsHQVGbAjrqkeOSfdt5MF2Qex0Z6o4jw0U/w2/EzGLogdBp7jC1DJ6Tm TqBLqRnjPsPs2NGazbTKmEoJX2isQOBUZyfzM44uCyVEY6Sk6FGqR7RDDCvr7VZvo/28d6at U9ueIa6rtdk+AxlXyqsJ6GBUL+ZBNJQ58L9xqynzPmikjntfM1TEhvkOATXLJ7wqf6ao4lKk gg5cqOxHPVMAje5K9f8V9hdUOtc9MNCR9nyTo8qNzMNyh8FR+1/qxFDtiJG5l6EArgfl2OGr MIIKHjCCCQagAwIBAgIKHpaEXAAAAAAKlTANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3 DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5l dyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5v bG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZp Y2VzIDEwHhcNMDYwNjI2MTYxMjUzWhcNMDgwNjI2MTYyMjUzWjBBMR0wGwYJKoZIhvcNAQkB Fg52a2dAbHVjZW50LmNvbTEgMB4GA1UEAxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwKiQ62gf/M7OBA6gfnAFJeldtS+/Om4zi 7nKlIYV4F5Mq5PN7DcS/FwAHuvWAcw1OAxe8Jouzqj1VSShBAppYY1ddmouSSQJsev4oPzYg CY45eoom1i806WtpBqFdMqWsbr6hPpUVr0EjNr+5JnYMo9yxyhVIEESZsLxmiHuUfv+yXoG9 4WCPV7StOsLiaX3TNWfEWfPYBFMTFrBTHuHJUouZbLzh6BzrIOHuxzkH7o1sm/UZ1Ik4BIls 1wsu/GKETbCAPvWeFG1bMwB3ODiex3zIj1uyFQaphuKIoL0atX003sAnRawtC0tiz7V1y4w1 eUtxoTIjFMJyZnCdg2yjAgMBAAGjggakMIIGoDAdBgNVHQ4EFgQU01a+vZTaFJsrOU/xbiKH qbmmM0wwgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcswgcgxJTAj BgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50 IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkGA1UEAxMi THVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTATBgoJkiaJ k/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4QgEBBAQD AgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQGCCsGAQUF BwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8vbGRhcC11 c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1Y2VudC5j b20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUy MDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRp ZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2Jp bmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKKBgNVHR8E ggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0 ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25B dXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmlj YXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9u bGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHU oIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIw VGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2VydGlmaWNh dGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25s aXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJ KoZIhvcNAQEFBQADggEBAJml/lw3ByThL2qO5fod+j4VYW1ZMg8w8ZXCwxVjP3uGYQ8rPEDz Mw9o7Rn34UPvlkFzYaRmwdBUZsCOuqR45J923kwXZB7HRnqjiPDRT/Db8TMYuiB0GnuMLUMn pOZOoEupGeM+w+zY0ZrNtMqYSglfaKxA4FRnJ/Mzji4LJURjpKToUapHtEMMK+vtVm+j/bx3 pq1T254hrqu12T4DGVfKqwnoYFQv5kE0lDnwv3GrKfM+aKSOe18zVMSG+Q4BNcsnvCp/pqji UqSCDlyo7Ec9UwCN7kr1/xX2F1Q61z0w0JH2fJOjyo3Mw3KHwVH7X+rEUO2IkbmXoQCuB+XY 4aswghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUwIwYJKoZI hvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMK TmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWN5MA0GCSqG SIb3DQEBBQUAA4IBAQCZpf5cNwck4S9qjuX6Hfo+FWFtWTIPMPGVwsMVYz97hmEPKzxA8zMP aO0Z9+FD75ZBc2GkZsHQVGbAjrqkeOSfdt5MF2Qex0Z6o4jw0U/w2/EzGLogdBp7jC1DJ6Tm TqBLqRnjPsPs2NGazbTKmEoJX2isQOBUZyfzM44uCyVEY6Sk6FGqR7RDDCvr7VZvo/28d6at U9ueIa6rtdk+AxlXyqsJ6GBUL+ZBNJQ58L9xqynzPmikjntfM1TEhvkOATXLJ7wqf6ao4lKk gg5cqOxHPVMAje5K9f8V9hdUOtc9MNCR9nyTo8qNzMNyh8FR+1/qxFDtiJG5l6EArgfl2OGr MIIKHjCCCQagAwIBAgIKHpaEXAAAAAAKlTANBgkqhkiG9w0BAQUFADCBsjElMCMGCSqGSIb3 DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNvbTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCk5l dyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBIaWxsMRwwGgYDVQQKExNMdWNlbnQgVGVjaG5v bG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVjaG5vbG9naWVzIENlcnRpZmljYXRlIFNlcnZp Y2VzIDEwHhcNMDYwNjI2MTYxMjUzWhcNMDgwNjI2MTYyMjUzWjBBMR0wGwYJKoZIhvcNAQkB Fg52a2dAbHVjZW50LmNvbTEgMB4GA1UEAxMXVmlqYXkgSyBHdXJiYW5pIChWaWpheSkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCwKiQ62gf/M7OBA6gfnAFJeldtS+/Om4zi 7nKlIYV4F5Mq5PN7DcS/FwAHuvWAcw1OAxe8Jouzqj1VSShBAppYY1ddmouSSQJsev4oPzYg CY45eoom1i806WtpBqFdMqWsbr6hPpUVr0EjNr+5JnYMo9yxyhVIEESZsLxmiHuUfv+yXoG9 4WCPV7StOsLiaX3TNWfEWfPYBFMTFrBTHuHJUouZbLzh6BzrIOHuxzkH7o1sm/UZ1Ik4BIls 1wsu/GKETbCAPvWeFG1bMwB3ODiex3zIj1uyFQaphuKIoL0atX003sAnRawtC0tiz7V1y4w1 eUtxoTIjFMJyZnCdg2yjAgMBAAGjggakMIIGoDAdBgNVHQ4EFgQU01a+vZTaFJsrOU/xbiKH qbmmM0wwgf4GA1UdIwSB9jCB84AUhJ9BVZwQiE87TdOEOn4hS09K38uhgc6kgcswgcgxJTAj BgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5jb20xCzAJBgNVBAYTAlVTMRMwEQYD VQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkgSGlsbDEcMBoGA1UEChMTTHVjZW50 IFRlY2hub2xvZ2llczEcMBoGA1UECxMTTHVjZW50IFRlY2hub2xvZ2llczErMCkGA1UEAxMi THVjZW50IFRlY2hub2xvZ2llcyBSb290IEF1dGhvcml0eYIKYQwXHQAAAAAABTATBgoJkiaJ k/IsZAEBBAUWA3ZrZzAXBgoJkiaJk/IsZAEsBAkWBzM3MDk0MzgwEQYJYIZIAYb4QgEBBAQD AgWgMAsGA1UdDwQEAwID+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwQGCCsGAQUF BwMHMIICdwYIKwYBBQUHAQEEggJpMIICZTCBzgYIKwYBBQUHMAKGgcFsZGFwOi8vbGRhcC11 c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMENlcnRp ZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxv PWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0 aWZpY2F0aW9uQXV0aG9yaXR5MIHCBggrBgEFBQcwAoaBtWxkYXA6Ly9sZGFwLmx1Y2VudC5j b20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUy MDEsb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRp ZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkw gcwGCCsGAQUFBzAChoG/bGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVj ZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2Vy dGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2Jp bmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwggKKBgNVHR8E ggKBMIICfTCB1qCB06CB0IaBzWxkYXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEs b3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0 ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25B dXRob3JpdHkwgcqggceggcSGgcFsZGFwOi8vbGRhcC5sdWNlbnQuY29tL2NuPUx1Y2VudCUy MFRlY2hub2xvZ2llcyUyMENlcnRpZmljYXRlJTIwU2VydmljZXMlMjAxLG91PUNlcnRpZmlj YXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9u bGlzdDtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHU oIHRoIHOhoHLbGRhcDovL2xkYXAtZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIw VGVjaG5vbG9naWVzJTIwQ2VydGlmaWNhdGUlMjBTZXJ2aWNlcyUyMDEsb3U9Q2VydGlmaWNh dGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25s aXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwDQYJ KoZIhvcNAQEFBQADggEBAJml/lw3ByThL2qO5fod+j4VYW1ZMg8w8ZXCwxVjP3uGYQ8rPEDz Mw9o7Rn34UPvlkFzYaRmwdBUZsCOuqR45J923kwXZB7HRnqjiPDRT/Db8TMYuiB0GnuMLUMn pOZOoEupGeM+w+zY0ZrNtMqYSglfaKxA4FRnJ/Mzji4LJURjpKToUapHtEMMK+vtVm+j/bx3 pq1T254hrqu12T4DGVfKqwnoYFQv5kE0lDnwv3GrKfM+aKSOe18zVMSG+Q4BNcsnvCp/pqji UqSCDlyo7Ec9UwCN7kr1/xX2F1Q61z0w0JH2fJOjyo3Mw3KHwVH7X+rEUO2IkbmXoQCuB+XY 4aswghD2MIIP3qADAgECAgphDBcdAAAAAAAFMA0GCSqGSIb3DQEBBQUAMIHIMSUwIwYJKoZI hvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMK TmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNo bm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2Vu dCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcNMTAxMjA2 MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNvbTELMAkG A1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBIaWxsMRww GgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVjaG5vbG9n aWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+JXW72361 5PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHEx5xRWAiO NeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJE3BGQTOX 0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46CZQsibysV efigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMBAAGjggz0 MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4hS09K38sw CwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/hK1C+quh9 NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNl bnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVy cmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRo b3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCBxoaBw2xk YXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9n aWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMs bz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2Jq ZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6Ly9sZGFw LXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9v dCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQu Y29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4dGVybmFs Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2 b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhv cml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlv biUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0 O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcqggceg gcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNo bm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/bGRhcDov L2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJv b3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50 LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJpdHkubHVj ZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYBBQUHMAKG gbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hu b2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0 aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xkYXAtdXN3 ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIw QXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/ Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZp Y2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5 P2Jhc2o bm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2VudCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2Vu dCBUZWNobm9sb2dpZXMgUm9vdCBBdXRob3JpdHkwHhcNMDAxMjA2MTYyNjQ1WhcNMTAxMjA2 MTYzNjQ1WjCBsjElMCMGCSqGSIb3DQEJARYWY2FAc2VjdXJpdHkubHVjZW50LmNvbTELMAkG A1UEBhMCVVMxEzARBgNVBAgTCk5ldyBKZXJzZXkxFDASBgNVBAcTC011cnJheSBIaWxsMRww GgYDVQQKExNMdWNlbnQgVGVjaG5vbG9naWVzMTMwMQYDVQQDEypMdWNlbnQgVGVjaG5vbG9n aWVzIENlcnRpZmljYXRlIFNlcnZpY2VzIDEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK AoIBAQCrbIc03eHms6QdVIh5h01zu8+SHMLFNRPuo3EVY8dgvQsy1pM5DSOtjDt+JXW72361 5PF8cVgDVUQGE4D9T9k5B2DP3DUhtrsvH3SEKJL6NceqgWDhLzgf0JjhNdid9IHEx5xRWAiO NeeLiRcScIZyRgANiokhSaM5VM2tZBctDFWrXkqxRUHvSSlWXMoXh7HYBOfEjhfJE3BGQTOX 0HOFKkCNS3CDh7ZAwNnw4Ntgkf+8bOqAzmX1ToyZbFLn7bZ9rNFg3gcDzyoFD46CZQsibysV efigRA57WfouqpbgZ8JzIAmXAeaJLSRgutALT5beOyx75TNPdglVhKlHg4MLAgMBAAGjggz0 MIIM8DAQBgkrBgEEAYI3FQEEAwIBADAdBgNVHQ4EFgQUhJ9BVZwQiE87TdOEOn4hS09K38sw CwYDVR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wggEEBgNVHSMEgfwwgfmAFG/hK1C+quh9 NWJpDO7LUuiSAjxdoYHOpIHLMIHIMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNl bnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVy cmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxHDAaBgNVBAsTE0x1Y2Vu dCBUZWNobm9sb2dpZXMxKzApBgNVBAMTIkx1Y2VudCBUZWNobm9sb2dpZXMgUm9vdCBBdXRo b3JpdHmCEFmZihipVMC2QAXNTB3ruM8wggXfBgNVHR8EggXWMIIF0jCBzKCByaCBxoaBw2xk YXA6Ly9sZGFwLXVzZWFzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9n aWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMs bz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2Jq ZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBzKCByaCBxoaBw2xkYXA6Ly9sZGFw LXVzd2VzdC5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9v dCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQu Y29tP2NlcnRpZmljYXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9 Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCByaCBxqCBw4aBwGxkYXA6Ly9sZGFwLmV4dGVybmFs Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0 eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmlj YXRlcmV2b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlv bkF1dGhvcml0eTCBz6CBzKCByYaBxmxkYXA6Ly9sZGFwLXVzY2VudHJhbC5wb3N0Lmx1Y2Vu dC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1D ZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NlcnRpZmljYXRlcmV2 b2NhdGlvbmxpc3Q7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhv cml0eTCByqCBx6CBxIaBwWxkYXA6Ly9sZGFwLWVtZWEucG9zdC5sdWNlbnQuY29tL2NuPUx1 Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlv biUyMEF1dGhvcml0aWVzLG89bHVjZW50LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0 O2JpbmFyeT9iYXNlP29iamVjdGNsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcqggceg gcSGgcFsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNo bm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3Jp dGllcyxvPWx1Y2VudC5jb20/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFz ZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHIoIHFoIHChoG/bGRhcDov L2xkYXAtYXAucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hub2xvZ2llcyUyMFJv b3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0aWVzLG89bHVjZW50 LmNvbT9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeT9iYXNlP29iamVjdGNsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwL6AtoCuGKWh0dHA6Ly93d3cuc2VjdXJpdHkubHVj ZW50LmNvbS9jYS9jYTEuY3JsMIIFsgYIKwYBBQUHAQEEggWkMIIFoDCBxAYIKwYBBQUHMAKG gbdsZGFwOi8vbGRhcC11c2Vhc3QucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRlY2hu b2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhvcml0 aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNsYXNz PWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcQGCCsGAQUFBzAChoG3bGRhcDovL2xkYXAtdXN3 ZXN0LnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIw QXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/ Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0 aG9yaXR5MIHBBggrBgEFBQcwAoaBtGxkYXA6Ly9sZGFwLmV4dGVybmFsLmx1Y2VudC5jb20v Y249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUyMEF1dGhvcml0eSxvdT1DZXJ0aWZp Y2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29tP2NhY2VydGlmaWNhdGU7YmluYXJ5 P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYBBQUHMAKG gbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRl Y2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhv cml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNs YXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDovL2xkYXAt ZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUy MEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29t P2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNv bS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggrBgEFBQcw AoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9s b2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGll cyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNlY3VyaXR5 Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5UrdsB2nOxTre kCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82gm7eZee7 lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13h4tgCPG3 WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biRZr61dWmQ WajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb1QUPqg8/ g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCBEowggRGAgEBMIHBMIGyMSUwIwYJKoZI hvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMK TmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNo bm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2Vy dmljZXMgMQIKHpaEXAAAAAAKlTAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMjcxNTI4MjBaMCMGCSqGSIb3DQEJBDEWBBSp gy3sgDSjSf0gOhspIqJxmNKEvDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB0gYJ KwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQu Y29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5 IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBU ZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKHpaEXAAAAAAKlTCB1AYLKoZI hvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5j b20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkg SGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVjZW50IFRl Y2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoeloRcAAAAAAqVMA0GCSqGSIb3 DQEBAQUABIIBAHyroJIMoiuZLMnwGNwiVC6DxIvkIJv14K1AZbBzlFYmcbpDTYPoTOt0Xv1V 0N2C602mZ75mCyMyAeizAEQ8SG4uBdEjYgkxlu+0Hmhk7MgmrVcjehSJz4xWnijVy22q2+O5 27lkYD0vuTMvmHfyv9hoidllATu2xUsQyVL9us8y5bWtxGsOLoNJgmRUvFWCveiaXRk0jzZ0 ulwPXS7E9itW4YuZzwjmJvtqCLydDHvXuxL6ErZ7W40lNQylhRmHj/6mkAOIJpva/A63Cx/J T+AhBFEnsp5eFzs4/Jxmdb5ucHj1y7mQmz/gqdNTFnlG9fcdgG0fnihQlafkhIrPefUAAAAA AAA= --------------ms010600050704000400060501-- --===============0906091368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0906091368==-- U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1dGhvcml0eTCBxwYIKwYBBQUHMAKG gbpsZGFwOi8vbGRhcC11c2NlbnRyYWwucG9zdC5sdWNlbnQuY29tL2NuPUx1Y2VudCUyMFRl Y2hub2xvZ2llcyUyMFJvb3QlMjBBdXRob3JpdHksb3U9Q2VydGlmaWNhdGlvbiUyMEF1dGhv cml0aWVzLG89bHVjZW50LmNvbT9jYWNlcnRpZmljYXRlO2JpbmFyeT9iYXNlP29iamVjdGNs YXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwgcIGCCsGAQUFBzAChoG1bGRhcDovL2xkYXAt ZW1lYS5wb3N0Lmx1Y2VudC5jb20vY249THVjZW50JTIwVGVjaG5vbG9naWVzJTIwUm9vdCUy MEF1dGhvcml0eSxvdT1DZXJ0aWZpY2F0aW9uJTIwQXV0aG9yaXRpZXMsbz1sdWNlbnQuY29t P2NhY2VydGlmaWNhdGU7YmluYXJ5P2Jhc2U/b2JqZWN0Y2xhc3M9Y2VydGlmaWNhdGlvbkF1 dGhvcml0eTCBwgYIKwYBBQUHMAKGgbVsZGFwOi8vbGRhcC1jYWxhLnBvc3QubHVjZW50LmNv bS9jbj1MdWNlbnQlMjBUZWNobm9sb2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRp ZmljYXRpb24lMjBBdXRob3JpdGllcyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5h cnk/YmFzZT9vYmplY3RjbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MIHABggrBgEFBQcw AoaBs2xkYXA6Ly9sZGFwLWFwLnBvc3QubHVjZW50LmNvbS9jbj1MdWNlbnQlMjBUZWNobm9s b2dpZXMlMjBSb290JTIwQXV0aG9yaXR5LG91PUNlcnRpZmljYXRpb24lMjBBdXRob3JpdGll cyxvPWx1Y2VudC5jb20/Y2FjZXJ0aWZpY2F0ZTtiaW5hcnk/YmFzZT9vYmplY3RjbGFzcz1j ZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDUGCCsGAQUFBzAChilodHRwOi8vd3d3LnNlY3VyaXR5 Lmx1Y2VudC5jb20vY2EvY2ExLmNydDANBgkqhkiG9w0BAQUFAAOCAQEAObP5UrdsB2nOxTre kCTXpBxKF4K0t8Doi/zHhUuupK+Bc5ppNu9dqYeGr1bKNLRbF/hccvzn4xuj3o82gm7eZee7 lssn9e6T/AjmHca+pCG9n5wZNgY6S0AJryUk6/hfyWc/7z1HfFHrkMM2zn9kqm13h4tgCPG3 WS86+WE4PO12sjAi0GYc43CszaxuU0GZoZ3cfapl5AzC8pMLltGyu/DqJLBk/biRZr61dWmQ WajF/dKhwrAtDiGc0PYZykl/Dg1mYD+eadv5qSKUdTuoa8idlief/sWnUUWbGkYb1QUPqg8/ g9UQcvBx+dgrnsf11X6GHq9gI+LKDBNLyWdEvTGCBEowggRGAgEBMIHBMIGyMSUwIwYJKoZI hvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQuY29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMK TmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNo bm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBUZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2Vy dmljZXMgMQIKHpaEXAAAAAAKlTAJBgUrDgMCGgUAoIICXTAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNjExMjcxNTI4MjBaMCMGCSqGSIb3DQEJBDEWBBSp gy3sgDSjSf0gOhspIqJxmNKEvDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB0gYJ KwYBBAGCNxAEMYHEMIHBMIGyMSUwIwYJKoZIhvcNAQkBFhZjYUBzZWN1cml0eS5sdWNlbnQu Y29tMQswCQYDVQQGEwJVUzETMBEGA1UECBMKTmV3IEplcnNleTEUMBIGA1UEBxMLTXVycmF5 IEhpbGwxHDAaBgNVBAoTE0x1Y2VudCBUZWNobm9sb2dpZXMxMzAxBgNVBAMTKkx1Y2VudCBU ZWNobm9sb2dpZXMgQ2VydGlmaWNhdGUgU2VydmljZXMgMQIKHpaEXAAAAAAKlTCB1AYLKoZI hvcNAQkQAgsxgcSggcEwgbIxJTAjBgkqhkiG9w0BCQEWFmNhQHNlY3VyaXR5Lmx1Y2VudC5j b20xCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtNdXJyYXkg SGlsbDEcMBoGA1UEChMTTHVjZW50IFRlY2hub2xvZ2llczEzMDEGA1UEAxMqTHVjZW50IFRl Y2hub2xvZ2llcyBDZXJ0aWZpY2F0ZSBTZXJ2aWNlcyAxAgoeloRcAAAAAAqVMA0GCSqGSIb3 DQEBAQUABIIBAHyroJIMoiuZLMnwGNwiVC6DxIvkIJv14K1AZbBzlFYmcbpDTYPoTOt0Xv1V 0N2C602mZ75mCyMyAeizAEQ8SG4uBdEjYgkxlu+0Hmhk7MgmrVcjehSJz4xWnijVy22q2+O5 27lkYD0vuTMvmHfyv9hoidllATu2xUsQyVL9us8y5bWtxGsOLoNJgmRUvFWCveiaXRk0jzZ0 ulwPXS7E9itW4YuZzwjmJvtqCLydDHvXuxL6ErZ7W40lNQylhRmHj/6mkAOIJpva/A63Cx/J T+AhBFEnsp5eFzs4/Jxmdb5ucHj1y7mQmz/gqdNTFnlG9fcdgG0fnihQlafkhIrPefUAAAAA AAA= --------------ms010600050704000400060501-- --===============0906091368== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0906091368==-- From mip6-bounces@ietf.org Thu Nov 30 13:46:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpquL-000217-LQ; Thu, 30 Nov 2006 13:45:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GobuG-0006or-VW; Mon, 27 Nov 2006 03:32:04 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GobuF-0006Er-Bk; Mon, 27 Nov 2006 03:32:04 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAR8VpXI001895; Mon, 27 Nov 2006 10:31:56 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 10:31:18 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 10:31:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Nov 2006 10:31:17 +0200 Message-ID: In-Reply-To: <456A1C39.7030103@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last call comments for draft-ietf-mip6-ikev2-ipsec-07 Thread-Index: AccRruFcJyXy2od0RVKP/IEU5VyNYwATZN7A From: To: X-OriginalArrivalTime: 27 Nov 2006 08:31:17.0831 (UTC) FILETIME=[68A44570:01C711FE] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-Mailman-Approved-At: Thu, 30 Nov 2006 13:45:15 -0500 Cc: Francis.Dupont@point6.net, mip6@ietf.org, iesg@ietf.org Subject: [Mip6] RE: Last call comments for draft-ietf-mip6-ikev2-ipsec-07 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli wrote: > > 3) Section 4.2 says "RFC 3776 required configuration of the security > > policies per interface in order to be able to=20 > > differentiate between > > mobility header messages sent to the home agent and tunneled > > through the home agent to the correspondent node. Since the > > Mobility Header message type is a selector, it is now easy to > > differentiate between HoTi and HoT messages from other mobility > > header messages. Therefore per-interface configuration=20 > > of security policies is not required." > >=20 > > This is only partially true. RFC 3776 like virtual=20 > > interfaces would probably still be required if link-layer=20 > > addresses are used (e.g. for MLD or DHCPv6).=20 >=20 > agreed. >=20 > If this is the case, it might be a good > > idea to explicitly mention that the mechanisms described in this > > document support payload data protection only for traffic > > originating/terminating at the home address. >=20 > what if I just modify the last sentence of the above > paragraph? new text >=20 > o RFC 3776 required configuration of the security policies per > interface in order to be able to differentiate between mobility > header messages sent to the home agent and tunneled through the > home agent to the correspondent node. Since the=20 > Mobility Header message type is a selector, it is now easy=20 > to differentiate between HoTi and HoT messages from other=20 > mobility header messages. Therefore per-interface configuration > of security policies is not required for protecting mobility=20 > header messages. I don't think the average reader can infer from this text that=20 payload packet protection will not work the same way without=20 per-virtual-interface SPDs... so IMHO it would be worthwhile to say so explicitly: something along the lines "Without per-interface security policies, payload packet protection is limited to packets originating/terminating at the home address, and=20 e.g. link-local traffic is not supported". > > 7) Section 9: "The Home Agent should also include an > > INTERNAL_ADDRESS_EXPIRY attribute to indicate to the mobile node, > > the duration for which the dynamically allocated home address is > > valid." In RFC 4718 (IKEv2 clarifications) we strongly recommend=20 > > against using the INTERNAL_ADDRESS_EXPIRY attribute. >=20 > Tero also had this comment. I agree the INTERNAL_ADDRESS_EXPIRY does > not make sense in IKEv2 context. this is what I had written in > response to Tero's comment. >=20 > if we tie the home address lifetime to the IKE SA lifetime, then I > am afraid that home address assignment through IKEv2 is not going to > be popular. folks would use other mechanisms to assign the home > address to the mobile node. a Mobile IP home address by definition > is supposed to be a long lived address that does not change very > often. Nothing prevents us from keeping the same home address through several IKE_SAs: when the client connects again, it can request the same home address it had previously. In other words: the lifetime is not a single IKE_SA, but at home agents discreption, through all IKE_SAs between the MN and home agent,. > if there is no restriction that the lifetime in > INTERNAL_ADDRESS_EXPIRY attribute should always be less than the > IKEv2 SA lifetime, perhaps MIPv6 could use the > INTERNAL_ADDRESS_EXPIRY attribute. maybe we have found a use for the > attribute. ;) Such a restriction does exist: RFC4306 says that "the requested address is valid until the expiry time defined with the INTERNAL_ADDRESS EXPIRY attribute or there are no IKE_SAs between the peers." So even if INTERNAL_ADDRESS_EXPIRY value is very large, the address is not valid after all the IKE_SAs are gone (it can become again valid when new IKE_SA is established, though). Best regards, Pasi _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 30 13:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpquL-00020l-Bn; Thu, 30 Nov 2006 13:45:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Go5ov-0004mR-5R; Sat, 25 Nov 2006 17:16:25 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Go5oq-0004P9-R2; Sat, 25 Nov 2006 17:16:25 -0500 Received: by machshav.com (Postfix, from userid 512) id 34979FB489; Sat, 25 Nov 2006 22:16:14 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 83908FB482; Sat, 25 Nov 2006 22:16:13 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 00D043C08CC; Sat, 25 Nov 2006 17:16:11 -0500 (EST) Date: Sat, 25 Nov 2006 17:16:11 -0500 From: "Steven M. Bellovin" To: Vijay Devarapalli In-Reply-To: <4568B73C.3090301@azairenet.com> References: <20061111151215.b54defd1.smb@cs.columbia.edu> <4568B059.4030401@azairenet.com> <20061125211159.1912C3C0881@berkshire.machshav.com> <4568B73C.3090301@azairenet.com> Organization: Columbia University X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061125221612.00D043C08CC@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Thu, 30 Nov 2006 13:45:15 -0500 Cc: Francis.Dupont@point6.net, secdir@mit.edu, housley@vigilsec.com, mip6@ietf.org, iesg@ietf.org, hartmans-ietf@mit.edu, mip6-chairs@ietf.org Subject: [Mip6] Re: secdir review of draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org On Sat, 25 Nov 2006 13:35:56 -0800 Vijay Devarapalli wrote: > > how about the following text in section 4.3 > > The > use of sequence number in the ESP header to provide anti-replay > protection is optional because the sequence numbers in the > Binding Updates provide anti-replay protection. However, the > anti-replay protection fails if the home agent looses the binding > cache state, for example, due to a reboot. Since the IPsec security > association state can be also be assumed to be lost, ESP cannot > provide anti-replay protection in thise case. Complete anti- > replay protection can only be provided by the use of a dynamic > keying mechanism, like IKEv2. > Perfect; thanks. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Nov 30 13:46:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpquL-00021S-UY; Thu, 30 Nov 2006 13:45:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoeU9-0000dW-D2 for mip6@ietf.org; Mon, 27 Nov 2006 06:17:17 -0500 Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoeU6-0007oo-LZ for mip6@ietf.org; Mon, 27 Nov 2006 06:17:17 -0500 Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.12.10) with ESMTP id kARBH2f4002523 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Nov 2006 13:17:02 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id kARBH12f018991; Mon, 27 Nov 2006 13:17:01 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17770.51501.10145.418178@fireball.kivinen.iki.fi> Date: Mon, 27 Nov 2006 13:17:01 +0200 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: <456A0655.5000401@azairenet.com> References: <17743.45484.327116.817303@fireball.kivinen.iki.fi> <456A0655.5000401@azairenet.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 13 min X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-Mailman-Approved-At: Thu, 30 Nov 2006 13:45:15 -0500 Cc: mip6@ietf.org Subject: [Mip6] Re: Review of the draft-ietf-mip6-ikev2-ipsec-07.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip6-bounces@ietf.org Vijay Devarapalli writes: > > This should probably also talk about MOBIKE, as MOBIKE can offer some > > more building blocks for the MIP6 which will make it easier to use > > IKEv2 when addresses changes. > > the use of MOBIKE and MIP6 between the mobile node > and the home agent at the same time was discussed > quite extensively on the MIP6 mailing list. the > general thinking is that you shouldn't have two > protocols trying to manage the tunnel between the > mobile node and the home agent at the same time. > with MIPv6, the tunnel is basically a MIP tunnel, > sometimes protected by ESP in tunnel mode. the > binding update/binding acknowledgment messages are > used for updating the tunnel end-point whenever the > mobile node moves, irrespective of whether the > tunnel is protected by ESP or not. Using MOBIKE would allow MIP6 to work on more implementations as I guess MOBIKE will be implemented in most of the future IPsec client style implementations. I.e. if MIP6 could be able to use standard IPsec + MOBIKE combination, there would be no need for special support for MIP6 inside the IPsec stack. > the current text is there to address scenarios > where the identify in the IDi field is not the > same identity sent in the EAP messages. section > 3.5 of RFC 4718 does say that there could be > such cases. it simplifies things if the IDi does > contain the actual identify of the mobile node. > I would be happy to remove the text. As by IKEv2 RFC we are not sending EAP identifies inside EAP exchange when using EAP in IKEv2, the IDi field is used in the EAP. > > So, I would suggest you do recommend NOT to use > > INTERNAL_ADDRESS_EXPIRY at all, and simply get the address lifetime > > from the lifetime of the IKEv2 SA, i.e. the server will keep on > > renewing (if needed, in most cases the IP addresses are allocated from > > the local pool, so there is no needs to do renewals) the IP address as > > long as client keeps the IKEv2 SA up, and in case the address for some > > reason cannot be renewed, or is changed, deletes the IKEv2 SA forcing > > the client to get new IP address. As we are talking about home address > > here, there should not really be any problems with the address > > changing or not being able to renew it. > > if we tie the home address lifetime to the IKE SA > lifetime, then I am afraid that home address > assignment through IKEv2 is not going to be popular. > folks would use other mechanisms to assign the home > address to the mobile node. a Mobile IP home address > by definition is supposed to be a long lived address > that does not change very often. > > if there is no restriction that the lifetime in > INTERNAL_ADDRESS_EXPIRY attribute should always be > less than the IKEv2 SA lifetime, perhaps MIPv6 could > use the INTERNAL_ADDRESS_EXPIRY attribute. maybe we > have found a use for the attribute. ;) Hmm... I have been thinking that most of the implementations do limit the INTERNAL_ADDRESS_EXPIRY to be shorter time than the expected IKE lifetime, but I do not think there is anything in the specifications to limit it so. So in that sense it would be ok to specify much longer time for the INTERNAL_ADDRESS_EXPIRY, but on the other hand as long as the address is valid all the time during the IKEv2 exchnage there is no need to give any INTERNAL_ADDRESS_EXPIRY times, as next time you connect again and get new address, you of course propose the previous address you already have. On the other hand why does the client need to know the time how long the address is valid? If he has connection to the server (IKEv2 SA, or MIP6 state) all the time, then the server will probably keep the address reserved for him all that time, and changing it would cause lots of problems. When client does not have any state with the server (i.e. no IKEv2 SA, and no MIP6 state anymore), then when it first time connects it will need to get the address for himself again anyways, and in that case it can propose the old address, and the server can give it if it is free. Also in IPv6 I do not think we can claim that the server needs to recycle addresses, so most of the time addresses are changed because client requests so, not because server will run out of IP-addresses. -- kivinen@safenet-inc.com _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6