From mip4-bounces@ietf.org Thu Jun 01 16:55:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FluCo-0007O3-3d; Thu, 01 Jun 2006 16:55:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FluCQ-0005Tt-LW for mip4@ietf.org; Thu, 01 Jun 2006 16:55:22 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FltzO-0000HJ-LK for mip4@ietf.org; Thu, 01 Jun 2006 16:41:55 -0400 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, 1 Jun 2006 16:41:29 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Issue with 3344bis Thread-Index: AcZoio5ofh8b6eBtRYqTq7REN4fSlAdMLN1Q From: "Avi Lior" To: "Mobile IPv4 Mailing List" X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Mip4] Issue with 3344bis X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org =20 Sorry for the lateness of this comment... Section 3.6 =20 "A mobile node MUST be configured with a netmask and a mobility security association for each of its home agents." =20 This seems to be a bad thing if we are talking about roaming and dynamic HA assignement. =20 Instead it should say that it MAY be configured with ..... =20 or MUST be configurable with.... =20 =20 =20 =20 =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Avi Lior =20 > Bridgewater Systems Corporation > Phone : +1 (613) 591-9104 x6417 > Cell : +1 (613) 796-4183 > E-mail : mailto:avi@bridgewatersystems.com=20 > > www.bridgewatersystems.com >=20 > =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 01 18:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvJq-0000jl-VK; Thu, 01 Jun 2006 18:07:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlvJp-0000QZ-3e for mip4@ietf.org; Thu, 01 Jun 2006 18:07:05 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlvJn-00028J-Qu for mip4@ietf.org; Thu, 01 Jun 2006 18:07:05 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 15:07:01 -0700 Message-ID: <447F64D0.3040108@azairenet.com> Date: Thu, 01 Jun 2006 15:06:08 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] Issue with 3344bis References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jun 2006 22:07:01.0936 (UTC) FILETIME=[B5A8C300:01C685C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Avi Lior wrote: > > Sorry for the lateness of this comment... > > Section 3.6 > > "A mobile node MUST be configured with a netmask and a mobility > security association for each of its home agents." > > This seems to be a bad thing if we are talking about roaming and > dynamic HA assignement. > I think this is ok. as far as 3344bis is concerned, at least the netmask for the home link and a mobility security association is required for the protocol to work. later specifications talk about how the protocol in 3344bis would work without having to pre-configere a netmask (RFC4433), or without having to pre-configure a mobility security association (for e.g. RFC 3957). since there is a plan to advance 3344bis to draft standard we don't want normative references to RFC 4433 or RFC 3957. Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 01 22:12:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flz9N-0004B1-IF; Thu, 01 Jun 2006 22:12:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flz9M-0004Aw-FP for mip4@ietf.org; Thu, 01 Jun 2006 22:12:32 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flz9L-0002dQ-7r for mip4@ietf.org; Thu, 01 Jun 2006 22:12:32 -0400 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: [Mip4] Issue with 3344bis Date: Thu, 1 Jun 2006 22:12:05 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Issue with 3344bis Thread-Index: AcaFyFd13QKZDTGmQvmK6CdXaKvnhgAISCew From: "Avi Lior" To: "Vijay Devarapalli" X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi ViJay, Sorry but I don't think I agree with the MUST. If I have a method for bootstrapping MN-HA why MUST the MN be configured with an MN-HA? I think we can come up with some text without specifically making a reference to 4433 and 3957. The problem is that the "MUST" requires that I configure at least one MN-HA to be compliant with 3344.=20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com]=20 > Sent: Thursday, June 01, 2006 6:06 PM > To: Avi Lior > Cc: Mobile IPv4 Mailing List > Subject: Re: [Mip4] Issue with 3344bis >=20 > Avi Lior wrote: > > =20 > > Sorry for the lateness of this comment... > >=20 > > Section 3.6 > > =20 > > "A mobile node MUST be configured with a netmask and a mobility > > security association for each of its home agents." > > =20 > > This seems to be a bad thing if we are talking about roaming and=20 > > dynamic HA assignement. > > =20 >=20 > I think this is ok. as far as 3344bis is concerned, at least=20 > the netmask for the home link and a mobility security=20 > association is required for the protocol to work. later=20 > specifications talk about how the protocol in 3344bis would=20 > work without having to pre-configere a netmask (RFC4433), or=20 > without having to pre-configure a mobility security=20 > association (for e.g. RFC 3957). >=20 > since there is a plan to advance 3344bis to draft standard we=20 > don't want normative references to RFC 4433 or RFC 3957. >=20 > Vijay >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 01 22:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flzkh-0003IV-Hm; Thu, 01 Jun 2006 22:51:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flzkg-0003Co-4l for mip4@ietf.org; Thu, 01 Jun 2006 22:51:06 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flzkc-0000KY-QR for mip4@ietf.org; Thu, 01 Jun 2006 22:51:06 -0400 Received: from [10.1.201.12] ([10.1.201.12]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 19:51:01 -0700 Message-ID: <447FA791.3060707@azairenet.com> Date: Thu, 01 Jun 2006 19:50:57 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] Issue with 3344bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 02:51:01.0230 (UTC) FILETIME=[61DEB0E0:01C685EF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Avi Lior wrote: > Hi ViJay, > > Sorry but I don't think I agree with the MUST. If I have a method for > bootstrapping MN-HA why MUST the MN be configured with an MN-HA? > > I think we can come up with some text without specifically making a > reference to 4433 and 3957. > > The problem is that the "MUST" requires that I configure at least one > MN-HA to be compliant with 3344. I don't see it that way. 3344bis says there MUST be a security association between the MN and the HA for the protocol to work. Since it does not specify a way to dynamically configure a security association it *has* to say that a security association MUST be configured on the MN. otherwise it cannot be standardized. I think the MUST is needed in the spec. perhaps we could add the following at the end of the paragraph. Future specifications may define mechanisms to dynamically assign a home agent to a mobile node and setup a mobility security association between them. In this case, the mobile node need not be manually configured with a netmask or a mobility security association with its home agent. Vijay > >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >> Sent: Thursday, June 01, 2006 6:06 PM >> To: Avi Lior >> Cc: Mobile IPv4 Mailing List >> Subject: Re: [Mip4] Issue with 3344bis >> >> Avi Lior wrote: >>> >>> Sorry for the lateness of this comment... >>> >>> Section 3.6 >>> >>> "A mobile node MUST be configured with a netmask and a mobility >>> security association for each of its home agents." >>> >>> This seems to be a bad thing if we are talking about roaming and >>> dynamic HA assignement. >>> >> I think this is ok. as far as 3344bis is concerned, at least >> the netmask for the home link and a mobility security >> association is required for the protocol to work. later >> specifications talk about how the protocol in 3344bis would >> work without having to pre-configere a netmask (RFC4433), or >> without having to pre-configure a mobility security >> association (for e.g. RFC 3957). >> >> since there is a plan to advance 3344bis to draft standard we >> don't want normative references to RFC 4433 or RFC 3957. >> >> Vijay >> -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 00:15:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm13r-0008EW-4c; Fri, 02 Jun 2006 00:14:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm13p-0008Bx-P1 for mip4@ietf.org; Fri, 02 Jun 2006 00:14:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm13o-00088y-B1 for mip4@ietf.org; Fri, 02 Jun 2006 00:14:57 -0400 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 k524EoJ9020953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 1 Jun 2006 21:14:51 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k524Eh6Z028431; Thu, 1 Jun 2006 21:14:44 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 21:14:42 -0700 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: [Mip4] Issue with 3344bis Date: Thu, 1 Jun 2006 21:14:36 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8490BE0E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Issue with 3344bis Thread-Index: AcaF73PdDR/wSKSQRj2SkGCqVq262gACyJKQ From: "Narayanan, Vidya" To: "Vijay Devarapalli" , "Avi Lior" X-OriginalArrivalTime: 02 Jun 2006 04:14:42.0670 (UTC) FILETIME=[12E1A0E0:01C685FB] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org >=20 > Avi Lior wrote: > > Hi ViJay, > >=20 > > Sorry but I don't think I agree with the MUST. If I have a=20 > method for=20 > > bootstrapping MN-HA why MUST the MN be configured with an MN-HA? > >=20 > > I think we can come up with some text without specifically making a=20 > > reference to 4433 and 3957. > >=20 > > The problem is that the "MUST" requires that I configure at=20 > least one=20 > > MN-HA to be compliant with 3344. >=20 > I don't see it that way. 3344bis says there MUST be a=20 > security association between the MN and the HA for the=20 > protocol to work. > Since it does not specify a way to dynamically configure a=20 > security association it *has* to say that a security=20 > association MUST be configured on the MN. otherwise it cannot=20 > be standardized. >=20 I agree with Avi on this. I don't see why there needs to be a MUST on this one. If you say that an MN-HA SA MUST be available to secure the RRQ/RRP, that makes sense - it does not make sense to say that this MUST be "configured" per say.=20 > I think the MUST is needed in the spec. >=20 > perhaps we could add the following at the end of the paragraph. >=20 > Future specifications may define mechanisms to dynamically > assign a home agent to a mobile node and setup a mobility > security association between them. In this case, the mobile > node need not be manually configured with a netmask or a > mobility security association with its home agent. >=20 But, we already have specifications that define this :) So, to keep our eyes closed to the fact that we already have ways of getting away from manual configuration does not seem to make sense to me.=20 If you want to say that in the absence of a dynamic mechanism to acquire an MN-HA SA, it MUST be configured on the MN, that would be fine.=20 Vidya > Vijay >=20 > >=20 > >> -----Original Message----- > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > >> Sent: Thursday, June 01, 2006 6:06 PM > >> To: Avi Lior > >> Cc: Mobile IPv4 Mailing List > >> Subject: Re: [Mip4] Issue with 3344bis > >> > >> Avi Lior wrote: > >>> =20 > >>> Sorry for the lateness of this comment... > >>> > >>> Section 3.6 > >>> =20 > >>> "A mobile node MUST be configured with a netmask and a mobility > >>> security association for each of its home agents." > >>> =20 > >>> This seems to be a bad thing if we are talking about roaming and=20 > >>> dynamic HA assignement. > >>> =20 > >> I think this is ok. as far as 3344bis is concerned, at least the=20 > >> netmask for the home link and a mobility security association is=20 > >> required for the protocol to work. later specifications talk about=20 > >> how the protocol in 3344bis would work without having to=20 > >> pre-configere a netmask (RFC4433), or without having to=20 > pre-configure=20 > >> a mobility security association (for e.g. RFC 3957). > >> > >> since there is a plan to advance 3344bis to draft standard=20 > we don't=20 > >> want normative references to RFC 4433 or RFC 3957. > >> > >> Vijay > >> >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 01:18:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm23A-0004mv-HO; Fri, 02 Jun 2006 01:18:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm238-0004ga-EZ for mip4@ietf.org; Fri, 02 Jun 2006 01:18:18 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm235-0005Yx-2q for mip4@ietf.org; Fri, 02 Jun 2006 01:18:18 -0400 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: [Mip4] Issue with 3344bis Date: Fri, 2 Jun 2006 01:17:38 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Issue with 3344bis Thread-Index: AcaF73PdDR/wSKSQRj2SkGCqVq262gACyJKQAAIpCQA= From: "Avi Lior" To: "Narayanan, Vidya" , "Vijay Devarapalli" X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org ViJay, My original emails suggested that perhaps we say: Instead it should say that it MAY be configured with ..... =20 or MUST be configurable with.... Either of those cases support the manual or static configuration and also the Dynamic configuration. The current wording only allows for static configuration of the MN-HA. I agree with Vidya about the comments regarding your additional text. It is not necessary.=20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Friday, June 02, 2006 12:15 AM > To: Vijay Devarapalli; Avi Lior > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] Issue with 3344bis >=20 >=20 > >=20 > > Avi Lior wrote: > > > Hi ViJay, > > >=20 > > > Sorry but I don't think I agree with the MUST. If I have a > > method for > > > bootstrapping MN-HA why MUST the MN be configured with an MN-HA? > > >=20 > > > I think we can come up with some text without=20 > specifically making a=20 > > > reference to 4433 and 3957. > > >=20 > > > The problem is that the "MUST" requires that I configure at > > least one > > > MN-HA to be compliant with 3344. > >=20 > > I don't see it that way. 3344bis says there MUST be a security=20 > > association between the MN and the HA for the protocol to work. > > Since it does not specify a way to dynamically configure a security=20 > > association it *has* to say that a security association MUST be=20 > > configured on the MN. otherwise it cannot be standardized. > >=20 >=20 > I agree with Avi on this. I don't see why there needs to be a=20 > MUST on this one. If you say that an MN-HA SA MUST be=20 > available to secure the RRQ/RRP, that makes sense - it does=20 > not make sense to say that this MUST be "configured" per say.=20 >=20 > > I think the MUST is needed in the spec. > >=20 > > perhaps we could add the following at the end of the paragraph. > >=20 > > Future specifications may define mechanisms to dynamically > > assign a home agent to a mobile node and setup a mobility > > security association between them. In this case, the mobile > > node need not be manually configured with a netmask or a > > mobility security association with its home agent. > >=20 >=20 > But, we already have specifications that define this :) So,=20 > to keep our eyes closed to the fact that we already have ways=20 > of getting away from manual configuration does not seem to=20 > make sense to me.=20 >=20 > If you want to say that in the absence of a dynamic mechanism=20 > to acquire an MN-HA SA, it MUST be configured on the MN, that=20 > would be fine.=20 >=20 > Vidya >=20 > > Vijay > >=20 > > >=20 > > >> -----Original Message----- > > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] > > >> Sent: Thursday, June 01, 2006 6:06 PM > > >> To: Avi Lior > > >> Cc: Mobile IPv4 Mailing List > > >> Subject: Re: [Mip4] Issue with 3344bis > > >> > > >> Avi Lior wrote: > > >>> =20 > > >>> Sorry for the lateness of this comment... > > >>> > > >>> Section 3.6 > > >>> =20 > > >>> "A mobile node MUST be configured with a netmask and a mobility > > >>> security association for each of its home agents." > > >>> =20 > > >>> This seems to be a bad thing if we are talking about=20 > roaming and=20 > > >>> dynamic HA assignement. > > >>> =20 > > >> I think this is ok. as far as 3344bis is concerned, at least the=20 > > >> netmask for the home link and a mobility security association is=20 > > >> required for the protocol to work. later specifications=20 > talk about=20 > > >> how the protocol in 3344bis would work without having to=20 > > >> pre-configere a netmask (RFC4433), or without having to > > pre-configure > > >> a mobility security association (for e.g. RFC 3957). > > >> > > >> since there is a plan to advance 3344bis to draft standard > > we don't > > >> want normative references to RFC 4433 or RFC 3957. > > >> > > >> Vijay > > >> > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 02:13:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2v1-0003JJ-Dk; Fri, 02 Jun 2006 02:13:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm2uy-00034K-45 for mip4@ietf.org; Fri, 02 Jun 2006 02:13:56 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm2uo-0002zj-87 for mip4@ietf.org; Fri, 02 Jun 2006 02:13:53 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 01 Jun 2006 23:13:45 -0700 X-IronPort-AV: i="4.05,202,1146466800"; d="scan'208"; a="1817808613:sNHT106077190" 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/8.12.11) with ESMTP id k526DjjO032123; Thu, 1 Jun 2006 23:13:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k526DiCU009192; Thu, 1 Jun 2006 23:13:44 -0700 (PDT) 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.211); Thu, 1 Jun 2006 23:13:44 -0700 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: [Mip4] Issue with 3344bis Date: Thu, 1 Jun 2006 23:13:43 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201E95D2C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Issue with 3344bis Thread-Index: AcaF73PdDR/wSKSQRj2SkGCqVq262gACyJKQAAIpCQAAAWZrgA== From: "Kent Leung \(kleung\)" To: "Avi Lior" , "Narayanan, Vidya" , "Vijay Devarapalli" X-OriginalArrivalTime: 02 Jun 2006 06:13:44.0577 (UTC) FILETIME=[B3CA2710:01C6860B] DKIM-Signature: a=rsa-sha1; q=dns; l=5419; t=1149228825; x=1150092825; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Issue=20with=203344bis; X=v=3Dcisco.com=3B=20h=3DGzsepBbuIK42aGbWOmYor+sOZ1U=3D; b=brFk975tVvnv/ozUcNC8As70hNHuznigbZv7TE9UDjSWeAqF2fscHMcMCiXqtfbH72349Otb 3nLCX3ZUGZ0J19uXlCcXvJc1JfoJ+baE451jpQEfKm92gCdjQiguKROj; Authentication-Results: sj-dkim-1.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Here's a proposal: Change: "A mobile node MUST be configured with a netmask and a mobility security association for each of its home agents." To: "A mobile node MUST have a netmask and a mobility security association for each of its home agents. The information can be obtained dynamically by or configured on the mobile node." Kent > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Thursday, June 01, 2006 10:18 PM > To: Narayanan, Vidya; Vijay Devarapalli > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] Issue with 3344bis >=20 > ViJay, >=20 > My original emails suggested that perhaps we say: >=20 > Instead it should say that it MAY be configured with ..... > =20 > or MUST be configurable with.... >=20 > Either of those cases support the manual or static=20 > configuration and also the Dynamic configuration. >=20 > The current wording only allows for static configuration of the MN-HA. >=20 > I agree with Vidya about the comments regarding your additional text. > It is not necessary.=20 >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Friday, June 02, 2006 12:15 AM > > To: Vijay Devarapalli; Avi Lior > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] Issue with 3344bis > >=20 > >=20 > > >=20 > > > Avi Lior wrote: > > > > Hi ViJay, > > > >=20 > > > > Sorry but I don't think I agree with the MUST. If I have a > > > method for > > > > bootstrapping MN-HA why MUST the MN be configured with an MN-HA? > > > >=20 > > > > I think we can come up with some text without > > specifically making a > > > > reference to 4433 and 3957. > > > >=20 > > > > The problem is that the "MUST" requires that I configure at > > > least one > > > > MN-HA to be compliant with 3344. > > >=20 > > > I don't see it that way. 3344bis says there MUST be a security=20 > > > association between the MN and the HA for the protocol to work. > > > Since it does not specify a way to dynamically configure=20 > a security=20 > > > association it *has* to say that a security association MUST be=20 > > > configured on the MN. otherwise it cannot be standardized. > > >=20 > >=20 > > I agree with Avi on this. I don't see why there needs to be=20 > a MUST on=20 > > this one. If you say that an MN-HA SA MUST be available to=20 > secure the=20 > > RRQ/RRP, that makes sense - it does not make sense to say that this=20 > > MUST be "configured" per say. > >=20 > > > I think the MUST is needed in the spec. > > >=20 > > > perhaps we could add the following at the end of the paragraph. > > >=20 > > > Future specifications may define mechanisms to dynamically > > > assign a home agent to a mobile node and setup a mobility > > > security association between them. In this case, the mobile > > > node need not be manually configured with a netmask or a > > > mobility security association with its home agent. > > >=20 > >=20 > > But, we already have specifications that define this :) So, to keep=20 > > our eyes closed to the fact that we already have ways of=20 > getting away=20 > > from manual configuration does not seem to make sense to me. > >=20 > > If you want to say that in the absence of a dynamic mechanism to=20 > > acquire an MN-HA SA, it MUST be configured on the MN, that would be=20 > > fine. > >=20 > > Vidya > >=20 > > > Vijay > > >=20 > > > >=20 > > > >> -----Original Message----- > > > >> From: Vijay Devarapalli=20 > [mailto:vijay.devarapalli@AzaireNet.com] > > > >> Sent: Thursday, June 01, 2006 6:06 PM > > > >> To: Avi Lior > > > >> Cc: Mobile IPv4 Mailing List > > > >> Subject: Re: [Mip4] Issue with 3344bis > > > >> > > > >> Avi Lior wrote: > > > >>> =20 > > > >>> Sorry for the lateness of this comment... > > > >>> > > > >>> Section 3.6 > > > >>> =20 > > > >>> "A mobile node MUST be configured with a netmask and=20 > a mobility > > > >>> security association for each of its home agents." > > > >>> =20 > > > >>> This seems to be a bad thing if we are talking about > > roaming and > > > >>> dynamic HA assignement. > > > >>> =20 > > > >> I think this is ok. as far as 3344bis is concerned, at=20 > least the=20 > > > >> netmask for the home link and a mobility security=20 > association is=20 > > > >> required for the protocol to work. later specifications > > talk about > > > >> how the protocol in 3344bis would work without having to=20 > > > >> pre-configere a netmask (RFC4433), or without having to > > > pre-configure > > > >> a mobility security association (for e.g. RFC 3957). > > > >> > > > >> since there is a plan to advance 3344bis to draft standard > > > we don't > > > >> want normative references to RFC 4433 or RFC 3957. > > > >> > > > >> Vijay > > > >> > > >=20 > > >=20 > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page:=20 > > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > >=20 > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 03:17:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3uJ-0007ZF-3Z; Fri, 02 Jun 2006 03:17:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3uI-0007ZA-Ci for mip4@ietf.org; Fri, 02 Jun 2006 03:17:18 -0400 Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm3uH-0001b2-2x for mip4@ietf.org; Fri, 02 Jun 2006 03:17:18 -0400 Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 194573874F; Fri, 2 Jun 2006 09:17:16 +0200 (CEST) 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 0AFC637FB6; Fri, 2 Jun 2006 09:17:16 +0200 (CEST) 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 C412C37E4B; Fri, 2 Jun 2006 09:17:15 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1Fm3uF-0005ea-3W; Fri, 02 Jun 2006 09:17:15 +0200 Message-ID: <447FE5FA.8060608@levkowetz.com> Date: Fri, 02 Jun 2006 09:17:14 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] Issue with 3344bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org on 2006-06-01 22:41 Avi Lior said the following: > > Sorry for the lateness of this comment... > > Section 3.6 > > "A mobile node MUST be configured with a netmask and a mobility > security association for each of its home agents." > > This seems to be a bad thing if we are talking about roaming and > dynamic HA assignement. > > Instead it should say that it MAY be configured with ..... > > or MUST be configurable with.... No. It requires there to be a security association and a netmask for *each of its home agents*. If you're dynamically assigning all home agents, you don't need anything at all as long as you have zero home agents assigned. But when you later have dynamically assigned home agents, each of them MUST have an associated netmask and a mobility security association. And this makes sense - having a HA without netmask or security association is unworkable. I think this is correct, and I see no problem with the text. Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 03:23:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm40k-0006W7-LK; Fri, 02 Jun 2006 03:23:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm40i-0006VD-SN for mip4@ietf.org; Fri, 02 Jun 2006 03:23:56 -0400 Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm40i-0001jQ-9P for mip4@ietf.org; Fri, 02 Jun 2006 03:23:56 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 5F835385EF; Fri, 2 Jun 2006 09:23:55 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 4E5E437EF8; Fri, 2 Jun 2006 09:23:55 +0200 (CEST) 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 929A637E52; Fri, 2 Jun 2006 09:23:50 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1Fm40a-00071P-JB; Fri, 02 Jun 2006 09:23:50 +0200 Message-ID: <447FE782.30708@levkowetz.com> Date: Fri, 02 Jun 2006 09:23:46 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] Issue with 3344bis References: <2979E38DD6FC6544B789C8DAD7BAFC5201E95D2C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201E95D2C@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: "Narayanan, Vidya" , Mobile IPv4 Mailing List , Vijay Devarapalli , 'Avi Lior' X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1167724344==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1167724344== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9EBF4D6413DAE24BA7DB45F7" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9EBF4D6413DAE24BA7DB45F7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kent, The proposed text is ok, but the change is unnecessary. The current text doesn't say that you have to have MSA and netmask before you have an assigned HA, even if Avi happened to mis-read it that way. Henrik on 2006-06-02 08:13 Kent Leung (kleung) said the following: > Here's a proposal: >=20 > Change: >=20 > "A mobile node MUST be configured with a netmask and a mobility > security association for each of its home agents." >=20 > To: >=20 > "A mobile node MUST have a netmask and a mobility > security association for each of its home agents. The information > can be obtained dynamically by or configured on the mobile node." >=20 > Kent >=20 >> -----Original Message----- >> From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 >> Sent: Thursday, June 01, 2006 10:18 PM >> To: Narayanan, Vidya; Vijay Devarapalli >> Cc: Mobile IPv4 Mailing List >> Subject: RE: [Mip4] Issue with 3344bis >>=20 >> ViJay, >>=20 >> My original emails suggested that perhaps we say: >>=20 >> Instead it should say that it MAY be configured with ..... >> =20 >> or MUST be configurable with.... >>=20 >> Either of those cases support the manual or static=20 >> configuration and also the Dynamic configuration. >>=20 >> The current wording only allows for static configuration of the MN-HA.= >>=20 >> I agree with Vidya about the comments regarding your additional text. >> It is not necessary.=20 >>=20 >> > -----Original Message----- >> > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >> > Sent: Friday, June 02, 2006 12:15 AM >> > To: Vijay Devarapalli; Avi Lior >> > Cc: Mobile IPv4 Mailing List >> > Subject: RE: [Mip4] Issue with 3344bis >> >=20 >> >=20 >> > >=20 >> > > Avi Lior wrote: >> > > > Hi ViJay, >> > > >=20 >> > > > Sorry but I don't think I agree with the MUST. If I have a meth= od for >> > > > bootstrapping MN-HA why MUST the MN be configured with an MN-HA?= >> > > >=20 >> > > > I think we can come up with some text without specifically makin= g a >> > > > reference to 4433 and 3957. >> > > >=20 >> > > > The problem is that the "MUST" requires that I configure at leas= t one >> > > > MN-HA to be compliant with 3344. >> > >=20 >> > > I don't see it that way. 3344bis says there MUST be a security=20 >> > > association between the MN and the HA for the protocol to work. >> > > Since it does not specify a way to dynamically configure a securi= ty=20 >> > > association it *has* to say that a security association MUST be=20 >> > > configured on the MN. otherwise it cannot be standardized. >> > >=20 >> >=20 >> > I agree with Avi on this. I don't see why there needs to be a MUST = on=20 >> > this one. If you say that an MN-HA SA MUST be available to secure t= he=20 >> > RRQ/RRP, that makes sense - it does not make sense to say that this = >> > MUST be "configured" per say. >> >=20 >> > > I think the MUST is needed in the spec. >> > >=20 >> > > perhaps we could add the following at the end of the paragraph. >> > >=20 >> > > Future specifications may define mechanisms to dynamically >> > > assign a home agent to a mobile node and setup a mobility >> > > security association between them. In this case, the mobile >> > > node need not be manually configured with a netmask or a >> > > mobility security association with its home agent. >> > >=20 >> >=20 >> > But, we already have specifications that define this :) So, to keep = >> > our eyes closed to the fact that we already have ways of getting aw= ay=20 >> > from manual configuration does not seem to make sense to me. >> >=20 >> > If you want to say that in the absence of a dynamic mechanism to=20 >> > acquire an MN-HA SA, it MUST be configured on the MN, that would be = >> > fine. >> >=20 >> > Vidya >> >=20 >> > > Vijay >> > >=20 >> > > >=20 >> > > >> -----Original Message----- >> > > >> From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.co= m] >> > > >> Sent: Thursday, June 01, 2006 6:06 PM >> > > >> To: Avi Lior >> > > >> Cc: Mobile IPv4 Mailing List >> > > >> Subject: Re: [Mip4] Issue with 3344bis >> > > >> >> > > >> Avi Lior wrote: >> > > >>> =20 >> > > >>> Sorry for the lateness of this comment... >> > > >>> >> > > >>> Section 3.6 >> > > >>> =20 >> > > >>> "A mobile node MUST be configured with a netmask and a mobil= ity >> > > >>> security association for each of its home agents." >> > > >>> =20 >> > > >>> This seems to be a bad thing if we are talking about roaming = and >> > > >>> dynamic HA assignement. >> > > >>> =20 >> > > >> I think this is ok. as far as 3344bis is concerned, at least t= he=20 >> > > >> netmask for the home link and a mobility security association = is=20 >> > > >> required for the protocol to work. later specifications talk ab= out >> > > >> how the protocol in 3344bis would work without having to=20 >> > > >> pre-configere a netmask (RFC4433), or without having to pre-con= figure >> > > >> a mobility security association (for e.g. RFC 3957). >> > > >> >> > > >> since there is a plan to advance 3344bis to draft standard we d= on't >> > > >> want normative references to RFC 4433 or RFC 3957. >> > > >> >> > > >> Vijay >> > > >> >> > >=20 >> > >=20 >> > > -- >> > > Mip4 mailing list: Mip4@ietf.org >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> > > Charter page: http://www.ietf.org/html.charters/mip4-charter= =2Ehtml >> > > Supplemental site: http://www.mip4.org/ >> > >=20 >> >=20 >>=20 >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html= >> Supplemental site: http://www.mip4.org/ >>=20 >=20 --------------enig9EBF4D6413DAE24BA7DB45F7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEf+eDeVhrtTJkXCMRAhd/AJ9z9K+QsLXR7F8qrLk2yxxZL4vMxACglIGa 88bthwpvTuIm/t0ABBHbkGk= =159R -----END PGP SIGNATURE----- --------------enig9EBF4D6413DAE24BA7DB45F7-- --===============1167724344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1167724344==-- From mip4-bounces@ietf.org Fri Jun 02 05:51:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6JF-0005M4-Gt; Fri, 02 Jun 2006 05:51:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm6JE-0005Lz-5y for mip4@ietf.org; Fri, 02 Jun 2006 05:51:12 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm6JC-0008Gm-Ug for mip4@ietf.org; Fri, 02 Jun 2006 05:51:12 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k529p98j025685; Fri, 2 Jun 2006 02:51:09 -0700 (MST) Received: from [10.161.194.78] (ZFR01-2117.ea.mot.com [10.161.194.78] (may be forged)) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k529p8NG013681; Fri, 2 Jun 2006 04:51:08 -0500 (CDT) Message-ID: <44800A0B.6080304@motorola.com> Date: Fri, 02 Jun 2006 11:51:07 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] Issue with 3344bis References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Avi Lior wrote: > > Sorry for the lateness of this comment... > > Section 3.6 > > "A mobile node MUST be configured with a netmask and a mobility > security association for each of its home agents." > > This seems to be a bad thing if we are talking about roaming and > dynamic HA assignement. > > Instead it should say that it MAY be configured with ..... I mainly agree it should be a MAY, not a MUST. For MN to know when it's at home or not, it may pre-configure its "home" netmask. That's one possibility. There are others, non-specified, which could also be MAYs. One particular example is if MN uses DHCP to dynamically configure addresses then it could pre-configure the address of the "home" DHCP Server (or of the "home" DHCP Relay) and thus know when it's at home or not, without pre-configuring a "home" netmask. Alex -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 09:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9nO-0004J6-He; Fri, 02 Jun 2006 09:34:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9nM-0004J1-RG for mip4@ietf.org; Fri, 02 Jun 2006 09:34:32 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm9nI-00076u-Iw for mip4@ietf.org; Fri, 02 Jun 2006 09:34:32 -0400 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: [Mip4] Issue with 3344bis Date: Fri, 2 Jun 2006 09:33:58 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Issue with 3344bis Thread-Index: AcaGFiKlDJSGFot0RbyQzRiUBefS1AAMr5Ng From: "Avi Lior" To: "Henrik Levkowetz" , "Kent Leung \(kleung\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Cc: "Narayanan, Vidya" , Mobile IPv4 Mailing List , Vijay Devarapalli X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Henrik, I am not disputing what you are saying at all. It is just that when we read that sentence it gives the impression that the HA must be statically provisioned with a netmask and an SA. Rewording would help....I like Kent's verbage. And I am not the only one mis-reading this. =20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Friday, June 02, 2006 3:24 AM > To: Kent Leung (kleung) > Cc: Narayanan, Vidya; Vijay Devarapalli; Mobile IPv4 Mailing=20 > List; Avi Lior > Subject: Re: [Mip4] Issue with 3344bis >=20 > Hi Kent, >=20 > The proposed text is ok, but the change is unnecessary. The=20 > current text doesn't say that you have to have MSA and=20 > netmask before you have an assigned HA, even if Avi happened=20 > to mis-read it that way. >=20 >=20 > Henrik >=20 >=20 > on 2006-06-02 08:13 Kent Leung (kleung) said the following: > > Here's a proposal: > >=20 > > Change: > >=20 > > "A mobile node MUST be configured with a netmask and a mobility > > security association for each of its home agents." > >=20 > > To: > >=20 > > "A mobile node MUST have a netmask and a mobility > > security association for each of its home agents. The=20 > information > > can be obtained dynamically by or configured on the=20 > mobile node." > >=20 > > Kent > >=20 > >> -----Original Message----- > >> From: Avi Lior [mailto:avi@bridgewatersystems.com] > >> Sent: Thursday, June 01, 2006 10:18 PM > >> To: Narayanan, Vidya; Vijay Devarapalli > >> Cc: Mobile IPv4 Mailing List > >> Subject: RE: [Mip4] Issue with 3344bis > >>=20 > >> ViJay, > >>=20 > >> My original emails suggested that perhaps we say: > >>=20 > >> Instead it should say that it MAY be configured with ..... > >> =20 > >> or MUST be configurable with.... > >>=20 > >> Either of those cases support the manual or static=20 > configuration and=20 > >> also the Dynamic configuration. > >>=20 > >> The current wording only allows for static configuration=20 > of the MN-HA. > >>=20 > >> I agree with Vidya about the comments regarding your=20 > additional text. > >> It is not necessary.=20 > >>=20 > >> > -----Original Message----- > >> > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >> > Sent: Friday, June 02, 2006 12:15 AM > >> > To: Vijay Devarapalli; Avi Lior > >> > Cc: Mobile IPv4 Mailing List > >> > Subject: RE: [Mip4] Issue with 3344bis > >> >=20 > >> >=20 > >> > >=20 > >> > > Avi Lior wrote: > >> > > > Hi ViJay, > >> > > >=20 > >> > > > Sorry but I don't think I agree with the MUST. If I have a=20 > >> > > > method for bootstrapping MN-HA why MUST the MN be=20 > configured with an MN-HA? > >> > > >=20 > >> > > > I think we can come up with some text without specifically=20 > >> > > > making a reference to 4433 and 3957. > >> > > >=20 > >> > > > The problem is that the "MUST" requires that I configure at=20 > >> > > > least one MN-HA to be compliant with 3344. > >> > >=20 > >> > > I don't see it that way. 3344bis says there MUST be a security=20 > >> > > association between the MN and the HA for the protocol to work. > >> > > Since it does not specify a way to dynamically configure a=20 > >> > > security association it *has* to say that a security=20 > association=20 > >> > > MUST be configured on the MN. otherwise it cannot be=20 > standardized. > >> > >=20 > >> >=20 > >> > I agree with Avi on this. I don't see why there needs to=20 > be a MUST=20 > >> > on this one. If you say that an MN-HA SA MUST be available to =20 > >> > secure the RRQ/RRP, that makes sense - it does not make sense to=20 > >> > say that this MUST be "configured" per say. > >> >=20 > >> > > I think the MUST is needed in the spec. > >> > >=20 > >> > > perhaps we could add the following at the end of the paragraph. > >> > >=20 > >> > > Future specifications may define mechanisms to dynamically > >> > > assign a home agent to a mobile node and setup a mobility > >> > > security association between them. In this case, the mobile > >> > > node need not be manually configured with a netmask or a > >> > > mobility security association with its home agent. > >> > >=20 > >> >=20 > >> > But, we already have specifications that define this :)=20 > So, to keep=20 > >> > our eyes closed to the fact that we already have ways of=20 > getting=20 > >> > away from manual configuration does not seem to make sense to me. > >> >=20 > >> > If you want to say that in the absence of a dynamic mechanism to=20 > >> > acquire an MN-HA SA, it MUST be configured on the MN,=20 > that would be=20 > >> > fine. > >> >=20 > >> > Vidya > >> >=20 > >> > > Vijay > >> > >=20 > >> > > >=20 > >> > > >> -----Original Message----- > >> > > >> From: Vijay Devarapalli =20 > >> > > >> [mailto:vijay.devarapalli@AzaireNet.com] > >> > > >> Sent: Thursday, June 01, 2006 6:06 PM > >> > > >> To: Avi Lior > >> > > >> Cc: Mobile IPv4 Mailing List > >> > > >> Subject: Re: [Mip4] Issue with 3344bis > >> > > >> > >> > > >> Avi Lior wrote: > >> > > >>> =20 > >> > > >>> Sorry for the lateness of this comment... > >> > > >>> > >> > > >>> Section 3.6 > >> > > >>> =20 > >> > > >>> "A mobile node MUST be configured with a netmask=20 > and a mobility > >> > > >>> security association for each of its home agents." > >> > > >>> =20 > >> > > >>> This seems to be a bad thing if we are talking=20 > about roaming=20 > >> > > >>> and dynamic HA assignement. > >> > > >>> =20 > >> > > >> I think this is ok. as far as 3344bis is concerned,=20 > at least=20 > >> > > >> the netmask for the home link and a mobility security =20 > >> > > >> association is required for the protocol to work. later=20 > >> > > >> specifications talk about how the protocol in 3344bis would=20 > >> > > >> work without having to pre-configere a netmask=20 > (RFC4433), or=20 > >> > > >> without having to pre-configure a mobility security=20 > association (for e.g. RFC 3957). > >> > > >> > >> > > >> since there is a plan to advance 3344bis to draft=20 > standard we=20 > >> > > >> don't want normative references to RFC 4433 or RFC 3957. > >> > > >> > >> > > >> Vijay > >> > > >> > >> > >=20 > >> > >=20 > >> > > -- > >> > > Mip4 mailing list: Mip4@ietf.org > >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> > > Charter page: =20 > >> > > http://www.ietf.org/html.charters/mip4-charter.html > >> > > Supplemental site: http://www.mip4.org/ > >> > >=20 > >> >=20 > >>=20 > >> -- > >> Mip4 mailing list: Mip4@ietf.org > >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> Charter page:=20 > >> http://www.ietf.org/html.charters/mip4-charter.html > >> Supplemental site: http://www.mip4.org/ > >>=20 > >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 10:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAyp-00047a-Fb; Fri, 02 Jun 2006 10:50:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAyn-00047V-IL for mip4@ietf.org; Fri, 02 Jun 2006 10:50:25 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmAyl-0005kn-NG for mip4@ietf.org; Fri, 02 Jun 2006 10:50:25 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id B070E90051 for ; Fri, 2 Jun 2006 10:50:19 -0400 (EDT) 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 14307-09 for ; Fri, 2 Jun 2006 10:50:18 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 2 Jun 2006 10:50:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Issue with 3344bis Date: Fri, 2 Jun 2006 10:47:43 -0400 Message-ID: <8A16DAD84432534FBFC19FD92B50512F05B97A94@ames.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Issue with 3344bis Thread-Index: AcaF73PdDR/wSKSQRj2SkGCqVq262gACyJKQAAIpCQAAAWZrgAASmZvQ From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" , "Avi Lior" , "Narayanan, Vidya" , "Vijay Devarapalli" X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi all, I think the source of the confusion is the word "configured". I think this word (to some) means statically configured. But, it can also be dynamically configured, right? So, if we just clarify that: "A mobile node MUST be statically or dynamically configured...." Won't that suffice? -Kuntal > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Friday, June 02, 2006 1:14 AM > To: Avi Lior; Narayanan, Vidya; Vijay Devarapalli > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] Issue with 3344bis >=20 > Here's a proposal: >=20 > Change: >=20 > "A mobile node MUST be configured with a netmask and a mobility > security association for each of its home agents." >=20 > To: >=20 > "A mobile node MUST have a netmask and a mobility > security association for each of its home agents. The information > can be obtained dynamically by or configured on the mobile node." >=20 > Kent >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Thursday, June 01, 2006 10:18 PM > > To: Narayanan, Vidya; Vijay Devarapalli > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] Issue with 3344bis > > > > ViJay, > > > > My original emails suggested that perhaps we say: > > > > Instead it should say that it MAY be configured with ..... > > > > or MUST be configurable with.... > > > > Either of those cases support the manual or static > > configuration and also the Dynamic configuration. > > > > The current wording only allows for static configuration of the MN-HA. > > > > I agree with Vidya about the comments regarding your additional text. > > It is not necessary. > > > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Friday, June 02, 2006 12:15 AM > > > To: Vijay Devarapalli; Avi Lior > > > Cc: Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] Issue with 3344bis > > > > > > > > > > > > > > Avi Lior wrote: > > > > > Hi ViJay, > > > > > > > > > > Sorry but I don't think I agree with the MUST. If I have a > > > > method for > > > > > bootstrapping MN-HA why MUST the MN be configured with an MN-HA? > > > > > > > > > > I think we can come up with some text without > > > specifically making a > > > > > reference to 4433 and 3957. > > > > > > > > > > The problem is that the "MUST" requires that I configure at > > > > least one > > > > > MN-HA to be compliant with 3344. > > > > > > > > I don't see it that way. 3344bis says there MUST be a security > > > > association between the MN and the HA for the protocol to work. > > > > Since it does not specify a way to dynamically configure > > a security > > > > association it *has* to say that a security association MUST be > > > > configured on the MN. otherwise it cannot be standardized. > > > > > > > > > > I agree with Avi on this. I don't see why there needs to be > > a MUST on > > > this one. If you say that an MN-HA SA MUST be available to > > secure the > > > RRQ/RRP, that makes sense - it does not make sense to say that this > > > MUST be "configured" per say. > > > > > > > I think the MUST is needed in the spec. > > > > > > > > perhaps we could add the following at the end of the paragraph. > > > > > > > > Future specifications may define mechanisms to dynamically > > > > assign a home agent to a mobile node and setup a mobility > > > > security association between them. In this case, the mobile > > > > node need not be manually configured with a netmask or a > > > > mobility security association with its home agent. > > > > > > > > > > But, we already have specifications that define this :) So, to keep > > > our eyes closed to the fact that we already have ways of > > getting away > > > from manual configuration does not seem to make sense to me. > > > > > > If you want to say that in the absence of a dynamic mechanism to > > > acquire an MN-HA SA, it MUST be configured on the MN, that would be > > > fine. > > > > > > Vidya > > > > > > > Vijay > > > > > > > > > > > > > >> -----Original Message----- > > > > >> From: Vijay Devarapalli > > [mailto:vijay.devarapalli@AzaireNet.com] > > > > >> Sent: Thursday, June 01, 2006 6:06 PM > > > > >> To: Avi Lior > > > > >> Cc: Mobile IPv4 Mailing List > > > > >> Subject: Re: [Mip4] Issue with 3344bis > > > > >> > > > > >> Avi Lior wrote: > > > > >>> > > > > >>> Sorry for the lateness of this comment... > > > > >>> > > > > >>> Section 3.6 > > > > >>> > > > > >>> "A mobile node MUST be configured with a netmask and > > a mobility > > > > >>> security association for each of its home agents." > > > > >>> > > > > >>> This seems to be a bad thing if we are talking about > > > roaming and > > > > >>> dynamic HA assignement. > > > > >>> > > > > >> I think this is ok. as far as 3344bis is concerned, at > > least the > > > > >> netmask for the home link and a mobility security > > association is > > > > >> required for the protocol to work. later specifications > > > talk about > > > > >> how the protocol in 3344bis would work without having to > > > > >> pre-configere a netmask (RFC4433), or without having to > > > > pre-configure > > > > >> a mobility security association (for e.g. RFC 3957). > > > > >> > > > > >> since there is a plan to advance 3344bis to draft standard > > > > we don't > > > > >> want normative references to RFC 4433 or RFC 3957. > > > > >> > > > > >> Vijay > > > > >> > > > > > > > > > > > > -- > > > > Mip4 mailing list: Mip4@ietf.org > > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > > Charter page: > > > http://www.ietf.org/html.charters/mip4-charter.html > > > > Supplemental site: http://www.mip4.org/ > > > > > > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 13:27:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDQR-00055l-RL; Fri, 02 Jun 2006 13:27:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDQP-0004xC-RB for mip4@ietf.org; Fri, 02 Jun 2006 13:27:05 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmDQO-00066f-9G for mip4@ietf.org; Fri, 02 Jun 2006 13:27:05 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 10:27:00 -0700 Message-ID: <448074B0.80304@azairenet.com> Date: Fri, 02 Jun 2006 10:26:08 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] Issue with 3344bis References: <2979E38DD6FC6544B789C8DAD7BAFC5201E95D2C@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201E95D2C@xmb-sjc-235.amer.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 17:27:00.0869 (UTC) FILETIME=[C1DB2350:01C68669] X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: "Narayanan, Vidya" , Mobile IPv4 Mailing List , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Kent Leung (kleung) wrote: > Here's a proposal: > > Change: > > "A mobile node MUST be configured with a netmask and a mobility > security association for each of its home agents." > > To: > > "A mobile node MUST have a netmask and a mobility > security association for each of its home agents. The information > can be obtained dynamically by or configured on the mobile node." this is fine with me. there is an additional 'by' in the above paragraph. Vijay > > Kent > > >>-----Original Message----- >>From: Avi Lior [mailto:avi@bridgewatersystems.com] >>Sent: Thursday, June 01, 2006 10:18 PM >>To: Narayanan, Vidya; Vijay Devarapalli >>Cc: Mobile IPv4 Mailing List >>Subject: RE: [Mip4] Issue with 3344bis >> >>ViJay, >> >>My original emails suggested that perhaps we say: >> >>Instead it should say that it MAY be configured with ..... >> >> or MUST be configurable with.... >> >>Either of those cases support the manual or static >>configuration and also the Dynamic configuration. >> >>The current wording only allows for static configuration of the MN-HA. >> >>I agree with Vidya about the comments regarding your additional text. >>It is not necessary. >> >> >>>-----Original Message----- >>>From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>>Sent: Friday, June 02, 2006 12:15 AM >>>To: Vijay Devarapalli; Avi Lior >>>Cc: Mobile IPv4 Mailing List >>>Subject: RE: [Mip4] Issue with 3344bis >>> >>> >>> >>>>Avi Lior wrote: >>>> >>>>>Hi ViJay, >>>>> >>>>>Sorry but I don't think I agree with the MUST. If I have a >>>> >>>>method for >>>> >>>>>bootstrapping MN-HA why MUST the MN be configured with an MN-HA? >>>>> >>>>>I think we can come up with some text without >>> >>>specifically making a >>> >>>>>reference to 4433 and 3957. >>>>> >>>>>The problem is that the "MUST" requires that I configure at >>>> >>>>least one >>>> >>>>>MN-HA to be compliant with 3344. >>>> >>>>I don't see it that way. 3344bis says there MUST be a security >>>>association between the MN and the HA for the protocol to work. >>>>Since it does not specify a way to dynamically configure >> >>a security >> >>>>association it *has* to say that a security association MUST be >>>>configured on the MN. otherwise it cannot be standardized. >>>> >>> >>>I agree with Avi on this. I don't see why there needs to be >> >>a MUST on >> >>>this one. If you say that an MN-HA SA MUST be available to >> >>secure the >> >>>RRQ/RRP, that makes sense - it does not make sense to say that this >>>MUST be "configured" per say. >>> >>> >>>>I think the MUST is needed in the spec. >>>> >>>>perhaps we could add the following at the end of the paragraph. >>>> >>>> Future specifications may define mechanisms to dynamically >>>> assign a home agent to a mobile node and setup a mobility >>>> security association between them. In this case, the mobile >>>> node need not be manually configured with a netmask or a >>>> mobility security association with its home agent. >>>> >>> >>>But, we already have specifications that define this :) So, to keep >>>our eyes closed to the fact that we already have ways of >> >>getting away >> >>>from manual configuration does not seem to make sense to me. >>> >>>If you want to say that in the absence of a dynamic mechanism to >>>acquire an MN-HA SA, it MUST be configured on the MN, that would be >>>fine. >>> >>>Vidya >>> >>> >>>>Vijay >>>> >>>> >>>>>>-----Original Message----- >>>>>>From: Vijay Devarapalli >> >>[mailto:vijay.devarapalli@AzaireNet.com] >> >>>>>>Sent: Thursday, June 01, 2006 6:06 PM >>>>>>To: Avi Lior >>>>>>Cc: Mobile IPv4 Mailing List >>>>>>Subject: Re: [Mip4] Issue with 3344bis >>>>>> >>>>>>Avi Lior wrote: >>>>>> >>>>>>> >>>>>>>Sorry for the lateness of this comment... >>>>>>> >>>>>>> Section 3.6 >>>>>>> >>>>>>> "A mobile node MUST be configured with a netmask and >> >>a mobility >> >>>>>>> security association for each of its home agents." >>>>>>> >>>>>>> This seems to be a bad thing if we are talking about >>> >>>roaming and >>> >>>>>>>dynamic HA assignement. >>>>>>> >>>>>> >>>>>>I think this is ok. as far as 3344bis is concerned, at >> >>least the >> >>>>>>netmask for the home link and a mobility security >> >>association is >> >>>>>>required for the protocol to work. later specifications >>> >>>talk about >>> >>>>>>how the protocol in 3344bis would work without having to >>>>>>pre-configere a netmask (RFC4433), or without having to >>>> >>>>pre-configure >>>> >>>>>>a mobility security association (for e.g. RFC 3957). >>>>>> >>>>>>since there is a plan to advance 3344bis to draft standard >>>> >>>>we don't >>>> >>>>>>want normative references to RFC 4433 or RFC 3957. >>>>>> >>>>>>Vijay >>>>>> >>>> >>>> >>>>-- >>>>Mip4 mailing list: Mip4@ietf.org >>>> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >>>> Charter page: >>> >>>http://www.ietf.org/html.charters/mip4-charter.html >>> >>>>Supplemental site: http://www.mip4.org/ >>>> >>> >>-- >>Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>Supplemental site: http://www.mip4.org/ >> -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 13:31:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDUx-0002A7-Q7; Fri, 02 Jun 2006 13:31:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDUw-0002A2-Lp for mip4@ietf.org; Fri, 02 Jun 2006 13:31:46 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmDUw-0006r3-6U for mip4@ietf.org; Fri, 02 Jun 2006 13:31:46 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 10:31:43 -0700 Message-ID: <448075CB.80403@azairenet.com> Date: Fri, 02 Jun 2006 10:30:51 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] Issue with 3344bis References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 17:31:43.0721 (UTC) FILETIME=[6A72ED90:01C6866A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Cc: "Narayanan, Vidya" , Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Avi Lior wrote: > ViJay, > > My original emails suggested that perhaps we say: > > Instead it should say that it MAY be configured with ..... for the HA discovery mechanism described in section 3.6.1.2 to work, the mobile node must be configured with the netmask. so a MAY wouldn't work. > or MUST be configurable with.... thats obvious. a mobile node must be configurable. Vijay > > Either of those cases support the manual or static configuration and > also the Dynamic configuration. > > The current wording only allows for static configuration of the MN-HA. > > I agree with Vidya about the comments regarding your additional text. > It is not necessary. > > >>-----Original Message----- >>From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>Sent: Friday, June 02, 2006 12:15 AM >>To: Vijay Devarapalli; Avi Lior >>Cc: Mobile IPv4 Mailing List >>Subject: RE: [Mip4] Issue with 3344bis >> >> >> >>>Avi Lior wrote: >>> >>>>Hi ViJay, >>>> >>>>Sorry but I don't think I agree with the MUST. If I have a >>> >>>method for >>> >>>>bootstrapping MN-HA why MUST the MN be configured with an MN-HA? >>>> >>>>I think we can come up with some text without >> >>specifically making a >> >>>>reference to 4433 and 3957. >>>> >>>>The problem is that the "MUST" requires that I configure at >>> >>>least one >>> >>>>MN-HA to be compliant with 3344. >>> >>>I don't see it that way. 3344bis says there MUST be a security >>>association between the MN and the HA for the protocol to work. >>>Since it does not specify a way to dynamically configure a security >>>association it *has* to say that a security association MUST be >>>configured on the MN. otherwise it cannot be standardized. >>> >> >>I agree with Avi on this. I don't see why there needs to be a >>MUST on this one. If you say that an MN-HA SA MUST be >>available to secure the RRQ/RRP, that makes sense - it does >>not make sense to say that this MUST be "configured" per say. >> >> >>>I think the MUST is needed in the spec. >>> >>>perhaps we could add the following at the end of the paragraph. >>> >>> Future specifications may define mechanisms to dynamically >>> assign a home agent to a mobile node and setup a mobility >>> security association between them. In this case, the mobile >>> node need not be manually configured with a netmask or a >>> mobility security association with its home agent. >>> >> >>But, we already have specifications that define this :) So, >>to keep our eyes closed to the fact that we already have ways >>of getting away from manual configuration does not seem to >>make sense to me. >> >>If you want to say that in the absence of a dynamic mechanism >>to acquire an MN-HA SA, it MUST be configured on the MN, that >>would be fine. >> >>Vidya >> >> >>>Vijay >>> >>> >>>>>-----Original Message----- >>>>>From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >>>>>Sent: Thursday, June 01, 2006 6:06 PM >>>>>To: Avi Lior >>>>>Cc: Mobile IPv4 Mailing List >>>>>Subject: Re: [Mip4] Issue with 3344bis >>>>> >>>>>Avi Lior wrote: >>>>> >>>>>> >>>>>>Sorry for the lateness of this comment... >>>>>> >>>>>> Section 3.6 >>>>>> >>>>>> "A mobile node MUST be configured with a netmask and a mobility >>>>>> security association for each of its home agents." >>>>>> >>>>>> This seems to be a bad thing if we are talking about >> >>roaming and >> >>>>>>dynamic HA assignement. >>>>>> >>>>> >>>>>I think this is ok. as far as 3344bis is concerned, at least the >>>>>netmask for the home link and a mobility security association is >>>>>required for the protocol to work. later specifications >> >>talk about >> >>>>>how the protocol in 3344bis would work without having to >>>>>pre-configere a netmask (RFC4433), or without having to >>> >>>pre-configure >>> >>>>>a mobility security association (for e.g. RFC 3957). >>>>> >>>>>since there is a plan to advance 3344bis to draft standard >>> >>>we don't >>> >>>>>want normative references to RFC 4433 or RFC 3957. >>>>> >>>>>Vijay >>>>> >>> >>> >>>-- >>>Mip4 mailing list: Mip4@ietf.org >>> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >>> Charter page: >> >>http://www.ietf.org/html.charters/mip4-charter.html >> >>>Supplemental site: http://www.mip4.org/ >>> >> -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 13:34:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDXv-0002RQ-NA; Fri, 02 Jun 2006 13:34:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDXv-0002RL-6q for mip4@ietf.org; Fri, 02 Jun 2006 13:34:51 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmDXt-0006yZ-QD for mip4@ietf.org; Fri, 02 Jun 2006 13:34:51 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 10:34:14 -0700 Message-ID: <44807662.9020203@azairenet.com> Date: Fri, 02 Jun 2006 10:33:22 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Mip4] Issue with 3344bis References: <2EBB8025B6D1BA41B567DB32C1D8DB8490BE0E@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8490BE0E@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jun 2006 17:34:14.0514 (UTC) FILETIME=[C4541D20:01C6866A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: Mobile IPv4 Mailing List , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Narayanan, Vidya wrote: >>perhaps we could add the following at the end of the paragraph. >> >> Future specifications may define mechanisms to dynamically >> assign a home agent to a mobile node and setup a mobility >> security association between them. In this case, the mobile >> node need not be manually configured with a netmask or a >> mobility security association with its home agent. > > But, we already have specifications that define this :) So, to keep our > eyes closed to the fact that we already have ways of getting away from > manual configuration does not seem to make sense to me. hmm.. specs need to be self-contained as much as possible. > If you want to say that in the absence of a dynamic mechanism to acquire > an MN-HA SA, it MUST be configured on the MN, that would be fine. what you say would require a normative reference to RFC 3957. Vijay > > Vidya > > >>Vijay >> >> >>>>-----Original Message----- >>>>From: Vijay Devarapalli [mailto:vijay.devarapalli@AzaireNet.com] >>>>Sent: Thursday, June 01, 2006 6:06 PM >>>>To: Avi Lior >>>>Cc: Mobile IPv4 Mailing List >>>>Subject: Re: [Mip4] Issue with 3344bis >>>> >>>>Avi Lior wrote: >>>> >>>>> >>>>>Sorry for the lateness of this comment... >>>>> >>>>> Section 3.6 >>>>> >>>>> "A mobile node MUST be configured with a netmask and a mobility >>>>> security association for each of its home agents." >>>>> >>>>> This seems to be a bad thing if we are talking about roaming and >>>>>dynamic HA assignement. >>>>> >>>> >>>>I think this is ok. as far as 3344bis is concerned, at least the >>>>netmask for the home link and a mobility security association is >>>>required for the protocol to work. later specifications talk about >>>>how the protocol in 3344bis would work without having to >>>>pre-configere a netmask (RFC4433), or without having to >> >>pre-configure >> >>>>a mobility security association (for e.g. RFC 3957). >>>> >>>>since there is a plan to advance 3344bis to draft standard >> >>we don't >> >>>>want normative references to RFC 4433 or RFC 3957. >>>> >>>>Vijay >>>> >> >> >>-- >>Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>Supplemental site: http://www.mip4.org/ >> -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 13:57:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDtO-0003Ej-1b; Fri, 02 Jun 2006 13:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmDtN-0003Bi-C8 for mip4@ietf.org; Fri, 02 Jun 2006 13:57:01 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmDtL-00010K-Dr for mip4@ietf.org; Fri, 02 Jun 2006 13:57:01 -0400 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 k52Hur85014303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 2 Jun 2006 10:56:54 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k52HufPJ008769; Fri, 2 Jun 2006 10:56:52 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 10:56:44 -0700 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: [Mip4] Issue with 3344bis Date: Fri, 2 Jun 2006 10:56:37 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8490BF1F@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Issue with 3344bis Thread-Index: AcaF73PdDR/wSKSQRj2SkGCqVq262gACyJKQAAIpCQAAAWZrgAAZQneg From: "Narayanan, Vidya" To: "Kent Leung \(kleung\)" , "Avi Lior" , "Vijay Devarapalli" X-OriginalArrivalTime: 02 Jun 2006 17:56:44.0994 (UTC) FILETIME=[E9470220:01C6866D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This text sounds good to me. Vidya=20 > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 > Sent: Thursday, June 01, 2006 11:14 PM > To: Avi Lior; Narayanan, Vidya; Vijay Devarapalli > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] Issue with 3344bis >=20 > Here's a proposal: >=20 > Change: >=20 > "A mobile node MUST be configured with a netmask and a mobility > security association for each of its home agents." >=20 > To: >=20 > "A mobile node MUST have a netmask and a mobility > security association for each of its home agents. The information > can be obtained dynamically by or configured on the mobile node." >=20 > Kent >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Thursday, June 01, 2006 10:18 PM > > To: Narayanan, Vidya; Vijay Devarapalli > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] Issue with 3344bis > >=20 > > ViJay, > >=20 > > My original emails suggested that perhaps we say: > >=20 > > Instead it should say that it MAY be configured with ..... > > =20 > > or MUST be configurable with.... > >=20 > > Either of those cases support the manual or static=20 > configuration and=20 > > also the Dynamic configuration. > >=20 > > The current wording only allows for static configuration of=20 > the MN-HA. > >=20 > > I agree with Vidya about the comments regarding your=20 > additional text. > > It is not necessary.=20 > >=20 > > > -----Original Message----- > > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > > Sent: Friday, June 02, 2006 12:15 AM > > > To: Vijay Devarapalli; Avi Lior > > > Cc: Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] Issue with 3344bis > > >=20 > > >=20 > > > >=20 > > > > Avi Lior wrote: > > > > > Hi ViJay, > > > > >=20 > > > > > Sorry but I don't think I agree with the MUST. If I have a > > > > method for > > > > > bootstrapping MN-HA why MUST the MN be configured=20 > with an MN-HA? > > > > >=20 > > > > > I think we can come up with some text without > > > specifically making a > > > > > reference to 4433 and 3957. > > > > >=20 > > > > > The problem is that the "MUST" requires that I configure at > > > > least one > > > > > MN-HA to be compliant with 3344. > > > >=20 > > > > I don't see it that way. 3344bis says there MUST be a security=20 > > > > association between the MN and the HA for the protocol to work. > > > > Since it does not specify a way to dynamically configure > > a security > > > > association it *has* to say that a security association MUST be=20 > > > > configured on the MN. otherwise it cannot be standardized. > > > >=20 > > >=20 > > > I agree with Avi on this. I don't see why there needs to be > > a MUST on > > > this one. If you say that an MN-HA SA MUST be available to > > secure the > > > RRQ/RRP, that makes sense - it does not make sense to say=20 > that this=20 > > > MUST be "configured" per say. > > >=20 > > > > I think the MUST is needed in the spec. > > > >=20 > > > > perhaps we could add the following at the end of the paragraph. > > > >=20 > > > > Future specifications may define mechanisms to dynamically > > > > assign a home agent to a mobile node and setup a mobility > > > > security association between them. In this case, the mobile > > > > node need not be manually configured with a netmask or a > > > > mobility security association with its home agent. > > > >=20 > > >=20 > > > But, we already have specifications that define this :)=20 > So, to keep=20 > > > our eyes closed to the fact that we already have ways of > > getting away > > > from manual configuration does not seem to make sense to me. > > >=20 > > > If you want to say that in the absence of a dynamic mechanism to=20 > > > acquire an MN-HA SA, it MUST be configured on the MN,=20 > that would be=20 > > > fine. > > >=20 > > > Vidya > > >=20 > > > > Vijay > > > >=20 > > > > >=20 > > > > >> -----Original Message----- > > > > >> From: Vijay Devarapalli > > [mailto:vijay.devarapalli@AzaireNet.com] > > > > >> Sent: Thursday, June 01, 2006 6:06 PM > > > > >> To: Avi Lior > > > > >> Cc: Mobile IPv4 Mailing List > > > > >> Subject: Re: [Mip4] Issue with 3344bis > > > > >> > > > > >> Avi Lior wrote: > > > > >>> =20 > > > > >>> Sorry for the lateness of this comment... > > > > >>> > > > > >>> Section 3.6 > > > > >>> =20 > > > > >>> "A mobile node MUST be configured with a netmask and > > a mobility > > > > >>> security association for each of its home agents." > > > > >>> =20 > > > > >>> This seems to be a bad thing if we are talking about > > > roaming and > > > > >>> dynamic HA assignement. > > > > >>> =20 > > > > >> I think this is ok. as far as 3344bis is concerned, at > > least the > > > > >> netmask for the home link and a mobility security > > association is > > > > >> required for the protocol to work. later specifications > > > talk about > > > > >> how the protocol in 3344bis would work without having to=20 > > > > >> pre-configere a netmask (RFC4433), or without having to > > > > pre-configure > > > > >> a mobility security association (for e.g. RFC 3957). > > > > >> > > > > >> since there is a plan to advance 3344bis to draft standard > > > > we don't > > > > >> want normative references to RFC 4433 or RFC 3957. > > > > >> > > > > >> Vijay > > > > >> > > > >=20 > > > >=20 > > > > -- > > > > Mip4 mailing list: Mip4@ietf.org > > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > > Charter page:=20 > > > http://www.ietf.org/html.charters/mip4-charter.html > > > > Supplemental site: http://www.mip4.org/ > > > >=20 > > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:10:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmE6G-0007jC-Aq; Fri, 02 Jun 2006 14:10:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmE6F-0007j7-4n for mip4@ietf.org; Fri, 02 Jun 2006 14:10:19 -0400 Received: from av9-2-sn2.hy.skanova.net ([81.228.8.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmE6C-0003C5-A3 for mip4@ietf.org; Fri, 02 Jun 2006 14:10:19 -0400 Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 5DCFD38040; Fri, 2 Jun 2006 20:10:15 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 4CD3037EAE; Fri, 2 Jun 2006 20:10:15 +0200 (CEST) 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 6E71837E42; Fri, 2 Jun 2006 20:10:14 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FmE68-0007br-S2; Fri, 02 Jun 2006 20:10:12 +0200 Message-ID: <44807F04.3040103@levkowetz.com> Date: Fri, 02 Jun 2006 20:10:12 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] Issue with 3344bis References: In-Reply-To: X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Cc: "Kent Leung \(kleung\)" , Mobile IPv4 Mailing List , "Narayanan, Vidya" , Vijay Devarapalli X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0627064630==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0627064630== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig44ABB649E27C93C55D3BE028" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig44ABB649E27C93C55D3BE028 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Avi, on 2006-06-02 15:33 Avi Lior said the following: > Hi Henrik, >=20 > I am not disputing what you are saying at all. Ok. > It is just that when we read that sentence it gives the impression that= > the HA must be statically provisioned with a netmask and an SA. Ok. I accept that you read it that way, but disagree that it actually gives that impression, as a general statement ;-) > Rewording would help....I like Kent's verbage. Ok. > And I am not the only one mis-reading this. =20 I'd like to hear from others, then... Regards, Henrik >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 >> Sent: Friday, June 02, 2006 3:24 AM >> To: Kent Leung (kleung) >> Cc: Narayanan, Vidya; Vijay Devarapalli; Mobile IPv4 Mailing=20 >> List; Avi Lior >> Subject: Re: [Mip4] Issue with 3344bis >>=20 >> Hi Kent, >>=20 >> The proposed text is ok, but the change is unnecessary. The=20 >> current text doesn't say that you have to have MSA and=20 >> netmask before you have an assigned HA, even if Avi happened=20 >> to mis-read it that way. >>=20 >>=20 >> Henrik >>=20 >>=20 >> on 2006-06-02 08:13 Kent Leung (kleung) said the following: >> > Here's a proposal: >> >=20 >> > Change: >> >=20 >> > "A mobile node MUST be configured with a netmask and a mobility >> > security association for each of its home agents." >> >=20 >> > To: >> >=20 >> > "A mobile node MUST have a netmask and a mobility >> > security association for each of its home agents. The=20 >> information >> > can be obtained dynamically by or configured on the=20 >> mobile node." >> >=20 >> > Kent >> >=20 >> >> -----Original Message----- >> >> From: Avi Lior [mailto:avi@bridgewatersystems.com] >> >> Sent: Thursday, June 01, 2006 10:18 PM >> >> To: Narayanan, Vidya; Vijay Devarapalli >> >> Cc: Mobile IPv4 Mailing List >> >> Subject: RE: [Mip4] Issue with 3344bis >> >>=20 >> >> ViJay, >> >>=20 >> >> My original emails suggested that perhaps we say: >> >>=20 >> >> Instead it should say that it MAY be configured with ..... >> >> =20 >> >> or MUST be configurable with.... >> >>=20 >> >> Either of those cases support the manual or static=20 >> configuration and=20 >> >> also the Dynamic configuration. >> >>=20 >> >> The current wording only allows for static configuration=20 >> of the MN-HA. >> >>=20 >> >> I agree with Vidya about the comments regarding your=20 >> additional text. >> >> It is not necessary.=20 >> >>=20 >> >> > -----Original Message----- >> >> > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >> >> > Sent: Friday, June 02, 2006 12:15 AM >> >> > To: Vijay Devarapalli; Avi Lior >> >> > Cc: Mobile IPv4 Mailing List >> >> > Subject: RE: [Mip4] Issue with 3344bis >> >> >=20 >> >> >=20 >> >> > >=20 >> >> > > Avi Lior wrote: >> >> > > > Hi ViJay, >> >> > > >=20 >> >> > > > Sorry but I don't think I agree with the MUST. If I have a=20 >> >> > > > method for bootstrapping MN-HA why MUST the MN be=20 >> configured with an MN-HA? >> >> > > >=20 >> >> > > > I think we can come up with some text without specifically=20 >> >> > > > making a reference to 4433 and 3957. >> >> > > >=20 >> >> > > > The problem is that the "MUST" requires that I configure at=20 >> >> > > > least one MN-HA to be compliant with 3344. >> >> > >=20 >> >> > > I don't see it that way. 3344bis says there MUST be a security = >> >> > > association between the MN and the HA for the protocol to work.= >> >> > > Since it does not specify a way to dynamically configure a=20 >> >> > > security association it *has* to say that a security=20 >> association=20 >> >> > > MUST be configured on the MN. otherwise it cannot be=20 >> standardized. >> >> > >=20 >> >> >=20 >> >> > I agree with Avi on this. I don't see why there needs to=20 >> be a MUST=20 >> >> > on this one. If you say that an MN-HA SA MUST be available to =20 >> >> > secure the RRQ/RRP, that makes sense - it does not make sense to = >> >> > say that this MUST be "configured" per say. >> >> >=20 >> >> > > I think the MUST is needed in the spec. >> >> > >=20 >> >> > > perhaps we could add the following at the end of the paragraph.= >> >> > >=20 >> >> > > Future specifications may define mechanisms to dynamically >> >> > > assign a home agent to a mobile node and setup a mobility >> >> > > security association between them. In this case, the mobile >> >> > > node need not be manually configured with a netmask or a >> >> > > mobility security association with its home agent. >> >> > >=20 >> >> >=20 >> >> > But, we already have specifications that define this :)=20 >> So, to keep=20 >> >> > our eyes closed to the fact that we already have ways of=20 >> getting=20 >> >> > away from manual configuration does not seem to make sense to me.= >> >> >=20 >> >> > If you want to say that in the absence of a dynamic mechanism to = >> >> > acquire an MN-HA SA, it MUST be configured on the MN,=20 >> that would be=20 >> >> > fine. >> >> >=20 >> >> > Vidya >> >> >=20 >> >> > > Vijay >> >> > >=20 >> >> > > >=20 >> >> > > >> -----Original Message----- >> >> > > >> From: Vijay Devarapalli =20 >> >> > > >> [mailto:vijay.devarapalli@AzaireNet.com] >> >> > > >> Sent: Thursday, June 01, 2006 6:06 PM >> >> > > >> To: Avi Lior >> >> > > >> Cc: Mobile IPv4 Mailing List >> >> > > >> Subject: Re: [Mip4] Issue with 3344bis >> >> > > >> >> >> > > >> Avi Lior wrote: >> >> > > >>> =20 >> >> > > >>> Sorry for the lateness of this comment... >> >> > > >>> >> >> > > >>> Section 3.6 >> >> > > >>> =20 >> >> > > >>> "A mobile node MUST be configured with a netmask=20 >> and a mobility >> >> > > >>> security association for each of its home agents." >> >> > > >>> =20 >> >> > > >>> This seems to be a bad thing if we are talking=20 >> about roaming=20 >> >> > > >>> and dynamic HA assignement. >> >> > > >>> =20 >> >> > > >> I think this is ok. as far as 3344bis is concerned,=20 >> at least=20 >> >> > > >> the netmask for the home link and a mobility security =20 >> >> > > >> association is required for the protocol to work. later=20 >> >> > > >> specifications talk about how the protocol in 3344bis would = >> >> > > >> work without having to pre-configere a netmask=20 >> (RFC4433), or=20 >> >> > > >> without having to pre-configure a mobility security=20 >> association (for e.g. RFC 3957). >> >> > > >> >> >> > > >> since there is a plan to advance 3344bis to draft=20 >> standard we=20 >> >> > > >> don't want normative references to RFC 4433 or RFC 3957. >> >> > > >> >> >> > > >> Vijay >> >> > > >> >> >> > >=20 >> >> > >=20 >> >> > > -- >> >> > > Mip4 mailing list: Mip4@ietf.org >> >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> >> > > Charter page: =20 >> >> > > http://www.ietf.org/html.charters/mip4-charter.html >> >> > > Supplemental site: http://www.mip4.org/ >> >> > >=20 >> >> >=20 >> >>=20 >> >> -- >> >> Mip4 mailing list: Mip4@ietf.org >> >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> >> Charter page:=20 >> >> http://www.ietf.org/html.charters/mip4-charter.html >> >> Supplemental site: http://www.mip4.org/ >> >>=20 >> >=20 >>=20 >>=20 >=20 --------------enig44ABB649E27C93C55D3BE028 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEgH8EeVhrtTJkXCMRAsOhAKDSyhfSmix5zYckuPwejOIwAHf9PACfRhFR UVXMKBIzyvBmWpEuD3F06BE= =muID -----END PGP SIGNATURE----- --------------enig44ABB649E27C93C55D3BE028-- --===============0627064630== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0627064630==-- From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067k-Kl; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flj3l-0003DO-Vc; Thu, 01 Jun 2006 05:01:41 -0400 Received: from smtp.irisa.fr ([131.254.254.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flj3k-00064p-Ah; Thu, 01 Jun 2006 05:01:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 0A1A7FAA9; Thu, 1 Jun 2006 11:01:39 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02418-09; Thu, 1 Jun 2006 11:01:37 +0200 (CEST) Received: from [131.254.10.213] (centocelle.irisa.fr [131.254.10.213]) by smtp.irisa.fr (Postfix) with ESMTP id 64DE1FA9E; Thu, 1 Jun 2006 11:01:37 +0200 (CEST) Message-ID: <447EACF1.7070105@irisa.fr> Date: Thu, 01 Jun 2006 11:01:37 +0200 From: Maria Gradinariu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tccc@cs.columbia.edu, csljc@ieee.org, computational.science@lists.optimalnumerics.com, podc@acm.org, ecoop-info@ecoop.org, mobisys@acm.org, tcgn@ieee.org, sigmetrics-members@acm.org, www-mobile@w3.org, mobicom@acm.org, SIGCOMM-MEMBERS@acm.org, tarot@hds.utc.fr, wg2@wireless-world-research.org, comm-theory@ieee.org, ifip-tc6@informatik.rwth-aachen.de, wg3@wireless-world-research.org, mip6@ietf.org, reres@laas.fr, dmanet@zpr.uni-koel.de, mip4@ietf.org, mipshop-bounces@ietf.org, TC-comswtc@comsoc.org, SENSORNET-request@LISTSERV.ACM.ORG, KUVS-L-request@LISTSERV.UNI-HEIDELBERG.DE, SIGMOB-request@LISTSERV.ACM.ORG, fokus-user@fokus.fraunhofer.de, types@cis.upenn.edu, comswtc@comsoc.org, coregrid-wp4@inria.fr, disc-announce@listes.epfl.ch, multicomm@comsoc.org, sigecom-talk@acm.org, adept@irisa.fr, paris@irisa.fr, aces@irisa.fr, caps@irisa.fr, armor@irisa.fr, liste-parall@lri.fr, grandlarge@lri.fr, arp@cines.fr, tccc@cs.columbia.edu, bahl@acm.org, www-mobile@w3.org, nrg-list@eecs.umich.edu, ns-announce@isi.edu, itc@i-teletraffic.org, wg7_3@cs.umass.edu, netnomics@listserver.tue.nl, mmb@ira.uka.de, itc@ieee.org, aaa-wg@merit.edu, cfp@mmlab.snu.ac.kr, dbworld@cs.wisc.edu, performance@msr.csm.ornl.gov, testnet@canarie.ca, zeroconf@merit.edu, ukubinet-announce-admin@doc.ic.ac.uk, multicomm@research.panasonic.com, comswtc@comsoc.org, coregrid-wp4@inria.fr, disc-announce@listes.epfl.ch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at irisa.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Subject: [Mip4] [CFP] Symposium on Stabilization, Safety, and Security of, Distributed Systems (SSS 2006) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [Please accept our apologies if you receive multiple copies of this message.] Eighth International Symposium on Stabilization, Safety, and Security of Distributed Systems (formerly Symposium on Self-stabilizing Systems) (SSS 2006) November 17th-19th, 2006 Dallas, Texas, USA http://www.irisa.fr/sss/2006/ ============================================================================== Selected papers will be published in a special issue of the ACM Transactions on Autonomous and Adaptive Systems (TAAS). ============================================================================== ============================================================================== Important Dates Paper Submission: July 7th, 2006 Notification to Authors: August 21st, 2006 Camera-ready: August 31st, 2006 Symposium: November 17th-19th, 2006 ============================================================================== The Symposium is a prestigious international forum for researchers and practitioners in the design and development of fault-tolerant distributed systems with self-* properties, such as self-stabilizing, self-configuring, self-organizing, self-managing, self-repairing, self-healing, self-optimizing, self-adaptive, and self-protecting. The theory of self-stabilization has been enriched in the last 25 years by high quality research contributions in the areas of algorithmic techniques, formal methodologies, model theoretic issues, and composition techniques. All these areas are essential to the understanding and maintenance of self-* properties in fault-tolerant distributed systems. Research in distributed systems is now at a crucial point in its evolution, marked by the importance of dynamic systems such as peer-to-peer networks, large-scale wireless sensor networks, mobile ad hoc networks, robotic networks, etc. Moreover, new applications such as grid and web services, banking and e-commerce, e-health and robotics, aerospace and avionics, automotive, industrial process control, etc. have joined the traditional applications of distributed systems. Now, more than ever, the theory of self-stabilization has tremendous impact in these areas. Therefore, this year, we are extending the scope of the symposium to cover all safety and security related aspects of self-* systems. The title of the conference has been changed to reflect this expansion. There will be three tracks: networking, safety and security, and self-* properties in static and dynamic systems. The symposium solicits contributions on all aspects of self-stabilization, safety and security, recovery oriented systems and programing, from theoretical contributions, to reports of the actual experience of applying the principles of self-stabilization to static and dynamic systems. Topics of interest include, but are not limited to: Stabilization: - self-stabilizing systems - self-managed, self-assembling, autonomic and adaptive systems - self-optimizing and self-protecting systems - self-* abstractions for implementing fundamental services in static and dynamic distributed systems - impossibility results and lower bounds for self-* systems - application of stabilizing algorithms and techniques in dynamic distributed systems - data and code stabilization - algorithms for self-* error detection/correction Safety: - safety critical systems - trust models and specifications - semantics of trust, distrust, mistrust, over-trust, cheat, risk and reputation - trust-related security and privacy - reliable and dependable systems - fault-tolerant systems, hardware redundancy, robustness, survivable systems, failure recovery Security: - security of network protocols - security of sensor and mobile networks protocols - secure architectures, frameworks, policy, intrusion detection/awareness - proactive security - self-* properties and their relation with classical fault-tolerance and security - security protocols for self-* systems Networks and Applications: - models of fault-tolerant communication - stochastic, physical, and biological models to analyze self-* properties - communication complexity - data structures for efficient communication - self-stabilizing hardware, software, and middleware - algorithms for high-speed networks, sensors, wireless and robots networks - mobile agents - peer-to-peer networks, sensor networks, MANETs, and wireless mesh networks - network topologies, overlays, and protocols - protocols for secure and reliable data transport and search in wireless mesh networks - information storage and sharing in wireless mesh networks Contributors are invited to submit a PDF file of their paper. Submissions should be no longer than 4800 words and should not exceed 12 pages on letter-size paper using at least 11 point font and reasonable margins (the page limit includes all figures, tables, and graphs). Submissions should include a cover page (that does not count towards the 12 page limit) that includes paper title, authors and affiliations, contact author's e-mail address, an abstract of the work in a few lines, and a few keywords. Submitted papers may have appendices beyond the 12 page limit, but reviewers are free to disregard any material beyond the 12 page limit. A paper submitted to SSS 2006 is expected to be original research not previously published; a submission may not be concurrently submitted or to any other conference, workshop, or journal. The proceedings of the conference will be published in the Springer Verlag Lecture Notes in Computer Science (LNCS) series. Selected papers will be published in a special issue of the ACM Transactions on Autonomous and Adaptive Systems (TAAS). General Chair: Mohamed Gouda, University of Texas at Austin, USA, gouda@cs.utexas.edu Program Co-chairs: Ajoy K Datta University of Nevada Las Vegas, USA, datta@cs.unlv.edu Maria Gradinariu, IRISA, France, mgradina@irisa.fr Local Arrangements Chair: Jorge Cobb, University of Texas at Dallas, USA, cobb@utdallas.edu Ravi Prakash, University of Texas at Dallas, USA, ravip@utdallas.edu Publicity and Web Chair: Florent Claerhout, IRISA, France, fclaerho@irisa.fr Steering Committee: Anish Arora, Ohio State University, USA, anish@cse.ohio-state.edu Ajoy K. Datta, University of Nevada Las Vegas, USA, datta@cs.unlv.edu Shlomi Dolev, Ben-Gurion University of the Negev, Israel, dolev@cs.bgu.ac.il Sukumar Ghosh, Chair, University of Iowa, USA, ghosh@cs.uiowa.edu Mohamed G. Gouda, University of Texas at Austin, USA, gouda@cs.utexas.edu Ted Herman, University of Iowa, USA, ted-herman@uiowa.edu Shing-Tsaan Huang, National Central University, Taiwan, sthuang@csie.ncu.edu.tw Toshimitsu Masuzawa, Osaka University, Japan, masuzawa@ist.osaka-u.ac.jp Vincent Villain, Universie de Picardie, France, villain@laria.u-picardie.fr -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067A-7D; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FldSY-0004CX-My; Wed, 31 May 2006 23:02:54 -0400 Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FldSY-0003N5-6S; Wed, 31 May 2006 23:02:54 -0400 Received: from hpn307pc2 (cpe-66-67-141-103.rochester.res.rr.com [66.67.141.103]) by ms-smtp-02.nyroc.rr.com (8.13.6/8.13.6) with SMTP id k5132pZE029500; Wed, 31 May 2006 23:02:52 -0400 (EDT) Message-ID: <006d01c68527$df5bec40$6701a8c0@hpn307pc2> From: "Wendi Heinzelman" To: , , , Date: Wed, 31 May 2006 23:02:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-02.nyroc.rr.com id k5132pZE029500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Wendi Heinzelman Subject: [Mip4] DCOSS 2006 Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org =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 PARTICIPATION =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 IEEE International Conference on Distributed Computing in Sensor Systems June 18 - 20, 2006 San Francisco, California, USA =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 WWW.DCOSS.ORG The 2006 International Conference on Distributed Computing in Sensor Syst= ems (DCOSS '06) will take place in San Francisco during June 18 - 20, 2006. DCOSS '06 will represent a merger of the DCOSS conference series and the IEEE International Workshops on Algorithms for Wireless, Mobile, Ad Hoc a= nd Sensor Networks (WMAN). The first DCOSS conference, held at Marina del Re= y on June 30-July 1, 2005, featured high quality research papers and interesti= ng invited and contributed poster/presentation sessions. DCOSS '06 is inten= ded to cover several aspects of distributed computing in sensor systems such = as high level abstractions, computational models, systematic design methodol= ogies, algorithms, analysis and applications. The conference will be co-located = with several closely related workshops, and will provide a forum for researche= rs and practitioners to present their contributions related to the above high-level aspects of distributed sensor systems. In addition to contribu= ted papers, the meeting will also include keynote addresses by leading resear= chers, a panel discussion, and a poster/presentation session. SPONSORED BY IEEE Computer Society Technical Committee on Parallel Processing (TCPP) IEEE Computer Society Technical Committee on Distributed Processing (TCDP= ) Held in co-operation with ACM SIGARCH ACM SIGBED European Association for Theoretical Computer Science (EATCS) IFIP WG 10.3 =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 CONFERENCE PROGRAM =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 SUNDAY, JUNE 18, 2006 Workshop: Euro-American Workshop on Middleware for Sensor Networks (EAWMS= ) Workshop: Mobility and Scalability in Wireless Sensor Networks (MSWSN) =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 MONDAY, JUNE 19, 2006 7:30 am - 8:20 am Continental Breakfast 8:20 am - 8:30 am Opening Remarks Jose Rolim (Steering Committee Chair, Univ. of Geneva, Switzerland) Viktor Prasanna (General Chair, Univ. of Southern California, USA) Phil Gibbons (Program Chair, Intel Research/CMU, USA) 8:30 am - 9:35 am KEYNOTE: "Structure Discovery and Information Brokerage in Sensor Networks" Leonidas Guibas (Stanford Univ., USA) -------------------------------------------------- 9:35 am - 9:50 am BREAK -------------------------------------------------- 9:50 am - 11:50 am Session 1: DISTRIBUTED ALGORITHMS & APPLICATIONS * Evaluating Local Contributions to Global Performance in Wireless Sensor and Actuator Networks Christopher Rozell, Don Johnson (Rice Univ., USA) * Roadmap Query for Sensor Network Assisted Navigation in Dynamic Environments Sangeeta Bhattacharya, Nuzhet Atay, Gazihan Alankus, Chenyang Lu, Burchan Bayazit, Gruia-Catalin Roman (Washington Univ. in St. Louis, USA) * Stabilizing Consensus in Mobile Networks Dana Angluin, Michael J. Fischer, Hong Jiang (Yale Univ.) * When Birds Die: Making Population Protocols Fault-Tolerant Carole Delporte-Gallet (Universite Paris); Hugues Fauconnier (LIAFA, Paris); Rachid Guerraoui (Swiss Federal Institute of Technology (EPFL)); Eric Ruppert (York Univ.) * Stochastically Consistent Caching and Dynamic Duty Cycling for Erratic Sensor Sources Shanzhong Zhu, Wei Wang, Chinya Ravishankar (Univ. of California at Riverside, USA) * Distributed Model-Free Stochastic Optimization in Wireless Sensor Netwo= rks Daniel Yagan, Chen Khong Tham (National Univ. of Singapore) -------------------------------------------------- 11:50 am - 1:15 pm LUNCH (on your own) -------------------------------------------------- 1:15 pm - 3:15 pm Session 2: PROGRAMMING SUPPORT & MIDDLEWARE * Agimone: Middleware Support for Seamless Integration of Sensor and IP Networks Gregory Hackmann, Chien-Liang Fok, Gruia-Catalin Roman, Chenyang Lu (Washington Univ. St. Louis) * Gossip Based Multi-Channel Reprogramming for Sensor Networks Limin Wang, Sandeep Kulkarni (Michigan State Univ.) * The Virtual Pheromone Communication Primitive Leo Szumel, John Owens (Univ. of California at Davis) * Logical Neighborhoods: A Programming Abstraction for Wireless Sensor Ne= tworks Luca Mottola, Gian Pietro Picco (Politecnico di Milano) * Y-Threads: Supporting Concurrency in Wireless Sensor Networks Christopher Nitta, Raju Pandey, Yann Ramin (Univ. of California at Davis) * Comparative Analysis of Push-Pull Query Strategies for Wireless Sensor = Networks Shyam Kapadia, Bhaskar Krishnamachari (Univ. of Southern California) -------------------------------------------------- 3:15 pm - 3:30 pm BREAK -------------------------------------------------- 3:30 pm - 5:30 pm Session 3: DATA AGGREGATION & DISSEMINATION * Using Data Aggregation to Prevent Traffic Analysis in Wireless Sensor Networks William Conner, Tarek Abdelzaher, Klara Nahrstedt (Univ. of Illinois at Urbana-Champaign) * Efficient and Robust Data Dissemination using Limited Extra Network Knowledge Ioannis Chatzigiannakis (Computer Technology Institute); Athanasios Kinalis, Sotiris Nikoletseas (Univ. of Patras and Computer Technology Institute) * Distance-Sensitive Information Brokerage in Sensor Networks Stefan Funke (Max-Planck-Institut f. Informatik); Leonidas Guibas, An Nguyen, Yusu Wang (Stanford) * Efficient In-Network Processing through Local Ad-hoc Information Coalescence Onur Savas, Murat Alanyali,Venkatesh Saligrama (Boston Univ.) * Distributed Optimal Estimation from Relative Measurements for Localizat= ion and Time Synchronization Prabir Barooah (UCSB); Neimar Da Silva (Federal Univ. of Rio de Janerio)= ; Joao Hespanha (UCSB) * GIST: Group-Independent Spanning Tree for Data Aggregation in Dense Sensor Networks Lujun Jia, Guevara Noubir, Rajmohan Rajaraman, Ravi Sundaram (Northeastern Univ.) -------------------------------------------------- 5:30 pm - 7:30 pm Poster Session and Reception Chair: Jim Reich (Palo Alto Research Center, USA) =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 TUESDAY, JUNE 20, 2006 8:00 am - 8:30 am Continental Breakfast 8:30 am - 9:35 am KEYNOTE: "In-network Adaptation of Sensor Node Location and Energy" William J. Kaiser (Univ. of California, Los Angeles) -------------------------------------------------- 9:35 am - 9:50 am BREAK -------------------------------------------------- 9:50 am - 10:50 am Session 4: SECURITY * Distributed User Access Control in Sensor Networks Haodong Wang, Qun Li (College of William and Mary) * Locating Compromised Sensor Nodes through Incremental Hashing Authentication Youtao Zhang (Univ. of Pittsburgh); Jun Yang, Lingling Jin (UC Riverside); Weijia Li (Univ. of Pittsburgh) * COTA: A Robust Multi-hop Localization Scheme in Wireless Sensor Network= s Yawen Wei, Zhen Yu, Yong Guan (Iowa State Univ.) 10:50 am - 11:50 am Session 5: INFORMATION FUSION * Contour Approximation in Sensor Networks Chiranjeeb Buragohain, Sorabh Gandhi (UCSB); John Hershberger (Mentor Graphics); Subhash Suri (UCSB) * A Distortion Aware Scheduling Approach for Wireless Sensor Networks Periklis Liaskovitis, Curt Schurgers (UCSD) * Optimal Placement and Selection of Camera Network Nodes for Target Localization Ali Ercan, Danny Yang, Abbas El Gamal, Leonidas Guibas (Stanford) -------------------------------------------------- 11:50 am - 1:15 pm LUNCH (on your own) -------------------------------------------------- 1:15 pm - 3:15 pm Session 6: LIFETIME MAXIMIZATION * An Optimal Data Propagation Algorithm for Maximizing the Lifespan of Sensor Networks Aubin Jarry, Pierre Leone, Olivier Powell, Jose Rolim (Univ. of Geneva) * Lifetime Maximization under Connectivity and k-Coverage Constraints in Wireless Sensor Networks Wei Mo, Daji Qiao, Zhengdao Wang (Iowa State Univ.) * Network Power Scheduling for TinyOS Applications Barbara Hohlt, Eric Brewer (UC Berkeley) * Algorithms for Scheduling Wireless Sensor Networks with Rate and Duty-Cycle Constraints over Interference Channels Rajgopal Kannan, Shuangqing Wei (Louisiana State Univ.) * MobiRoute: Routing towards a Mobile Sink for Improving Lifetime in Sensor Networks Jun Luo, Jacques Panchard, Michal Piorkowski, Matthias Grossglauser, Jean-Pierre Hubaux (Swiss Federal Institute of Technology (EPFL)) * SenCar: An Energy Efficient Data Gathering Mechanism for Large Scale Multihop Sensor Networks Ming Ma, Yuanyuan Yang (State Univ. of New York at Stony Brook) -------------------------------------------------- 3:15 pm - 3:30 pm BREAK -------------------------------------------------- 3:30 pm - 4:30 pm Session 7: LOCALIZATION * A Distributed Linear Least Squares Method for Precise Localization with Low Complexity in Wireless Sensor Networks Frank Reichenbach (University of Rostock) * Consistency-Based On-line Localization in Sensor Networks Jessica Feng, Miodrag Potkonjak (University of California at Los Angeles) * The Robustness of Localization Algorithms to Signal Strength Attacks: A Comparative Study Yingying Chen, Konstantin Kleisouris, Xiaoyan Li, Wade Trappe, Richard Martin (Rutgers University) -------------------------------------------------- 4:30 pm DCOSS 2006 CONCLUDES =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 WORKSHOP PROGRAMS =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 EURO-AMERICAN WORKSHOP ON MIDDLEWARE FOR SENSOR NETWORKS (EAWMS) =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 SUNDAY, JUNE 18, 2006 8:00 am - 9:00 am Continental Breakfast 9:00 am - 9:15 am Opening Remarks: Stefan Fischer (Chair) 9:15 am - 10:30 am Session 1 * FABRIC: Towards Data Type-centric Middleware Synthesis Dennis Pfisterer, Horst Hellbr?ck, Stefan Fischer (University of L?beck, Germany) * Rule-Oriented Programming for Wireless Sensor Networks Kirsten Terfloth, Georg Wittemburg, Joschen Schiller (Freie Universitdt Berlin, Germany) Discussion -------------------------------------------------- 10:30 am - 10:45 am BREAK -------------------------------------------------- 10:45 am - 12:00 pm Session 2 * Transiently Shared Tuple Spaces for Sensor Networks Amy L. Murphy (University of Lugano, Switzerland), Gian Pietro Picco (Politecnico di Milano, Italy) * Sensor Network Middleware for Managing a Cross-Layer Architecture Christophe J. Merlin, Wendi B. Heinzelman (University of Rochester, USA) Discussion -------------------------------------------------- 12:00 pm - 1:00 pm LUNCH (on your own) -------------------------------------------------- 1:00 pm - 2:15 pm Session 3 * Frugal Mobile Objects Benoit Garbinato (University of Lausanne, Switzerland), Rachid Guerraoui, Jarle Hulaas, Maxime Monod, Jesper H. Spring (EPFL, Switzerland) * Resource-Aware Service Architecture for Collaboration of Sensor Nodes Jan Blumenthal, Dirk Timmermann (University of Rostock, Germany) Discussion -------------------------------------------------- 2:15 pm - 2:30 pm BREAK -------------------------------------------------- 2:30 pm - 3:45 pm Session 4 * Distributed Mining of Spatio-Temporal Event-Pattern in Sensor Networks Kay Rfmer (ETHZ, Switzerland) * Middleware and Simulation Support for WSN Motion Control Agorithm Design and Analysis Norbert Luttenberger, Jochen Koberstein (University of Kiel, Germany) Discussion -------------------------------------------------- 3:45 pm - 4:00 pm BREAK -------------------------------------------------- 4:00 pm - 5:30 pm Session 5 * SensorBase.org - a Centralized Repository to Slog Sensor Network Data Kevin Chang, Nathan Yau, Mark Hansen, Deborah Estrin (University of California at Los Angeles, USA) * Pervasive Grids: Integrating Sensor Networks into the Fixed Grid Geoff Coulson (Lancaster University, England) Discussion Future Steps =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 WORKSHOP ON MOBILITY AND SCALABILITY IN WIRELESS SENSOR NETWORKS (MSWSN) =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 SUNDAY, JUNE 18, 2006 8:00 am - 8:45 am Continental Breakfast 8:45 am - 9:00 am Opening Remarks Christian Schindelhaer (Chair) 9:00 am - 11:00 am Session 1: MOBILITY * Invited Talk: Keith J. O'Hara (Georgia Institute of Technology, USA) Mobility and Pervasiveness in Physical Computing Systems joint work with Tucker Balch (Georgia Institute of Technology, USA) * Mobility Management in Sensor Networks Muneeb Ali (Lahore University of Management Sciences, Pakistan), Thiemo Voigt (Swedish Institute of Computer Science, Kista, Sweden), Zartash Afzal Uzmi (Lahore University of Management Sciences, Pakistan) * Autonomous Mobile Networks Overlaid on Public Transportation Networks G. Sampath (Rochester Institute of Technology, USA), J. TenEyck (Marist College, Poughkeepsie, USA) -------------------------------------------------- 11:00 am - 11:15 am BREAK -------------------------------------------------- 11:15 am - 12:30 pm Session 2: SCALABILITY * Invited Talk: S=E1ndor Fekete (Braunschweig University of Technology, G= ermany) Algorithmic Aspects of Large Sensor Networks joint work with Alexander Kr=FCller (Braunschweig University of Technology, Germany), Dennis Pfisterer, Stefan Fischer (University of L=FCbeck, Germany) * Intelligent Hierarchical Cluster-Based Routing Abdul W. Matin, Sajid Hussain (Jodrey School of Computer Science, Wolfville, Canada) -------------------------------------------------- 12:30 pm - 2:00 pm LUNCH (on your own) -------------------------------------------------- 2:00 pm - 4:00 pm Session 3: LIFETIME * Invited Talk: Sotiris Nikoletseas (Research Academic Computer Technology Institute, Patras, Greece) "Adaptive Power Saving for Heterogeneous Sensor Networks with Incremental Deployment" * Invited Talk: Jun Luo (School of Computer and Communication Sciences, Lausanne, Switzerland) "Mobility to Improve the Lifetime of Wireless Sensor Networks: A Theoretical Framework" joint work with Jean-Pierre Hubaux (School of Computer and Communication Sciences, Lausanne, Switzerland) -------------------------------------------------- 4:00 pm - 4:15 pm BREAK -------------------------------------------------- 4:15 pm - 5:30 pm PANEL DISCUSSION =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 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067S-Dz; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fldhe-0004Pc-HY; Wed, 31 May 2006 23:18:30 -0400 Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fldha-0004lz-6c; Wed, 31 May 2006 23:18:30 -0400 Received: from hpn307pc2 (cpe-66-67-141-103.rochester.res.rr.com [66.67.141.103]) by ms-smtp-01.nyroc.rr.com (8.13.6/8.13.6) with SMTP id k513IO9a012516; Wed, 31 May 2006 23:18:25 -0400 (EDT) Message-ID: <011401c6852a$0b36f6f0$6701a8c0@hpn307pc2> From: "Wendi Heinzelman" To: , Date: Wed, 31 May 2006 23:18:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Subject: [Mip4] SECON 2006 Call for Posters and Demos X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive this call multiple times.) *********************************************************************** CALL FOR POSTERS and DEMOS *Deadline: June 30, 2006, 5 pm EDT* IEEE SECON 2006 The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/2006/ Sponsored by IEEE Communications Society (www.comsoc.org) Technically Co-Sponsored by AFCEA (www.afcea.org) September 25-28, 2006 Reston, Virginia, USA (Near Washington DC's Dulles airport) ************************************************************************ To provide a forum for discussion and personal interaction between presenter and participants, IEEE SECON 2006 will include poster and demonstration sessions: works in progress, industry demonstrations of new applications and techniques, practical implementations, military, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. One of the key goals of this conference is to foster collaboration between industry, government agencies and academia. Hence, participation of researchers/developers from industry or governement agencies and posters/demonstrations reporting joint work are especially encouraged. Topics considered for posters and demo are, but not limited to: * New architectures and protocols to support communication, localization, time synchronization, routing, data dissemination, and other distributed services in heterogeneous, large-scale distributed, mesh networks and sensor networks * Novel algorithms and theories for management, supervisory control, and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Modeling and performance evaluation of large-scale distributed ad hoc and sensor networks, practical implementations and deployments, and real-world experiences * Theories and models on fundamental information and communication aspects of wireless mesh and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and mesh networks * Algorithms and protocols to support quality of service in mesh and sensor networks, including admission control, resource allocation and fairness, and capacity planning * Integration of sensors into engineered systems, including novel techniques for on-sensor renewable power sources, mechanisms for on-sensor self-calibration and self-testing, and efficient schemes to maximize accuracy and minimize false alarms * Hardware platforms incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware, and tools for mesh and sensor network applications development, deployment, and management Submissions should be in the form of a proposal describing the main contributions of the poster/demo and the merits of the proposed ideas. If available, preliminary results can also be included. Proposals will be evaluated mainly based on their potential to stimulate interesting discussions, exchange of ideas and promote collaborations. A prize will be awarded to the best demo by a jury composed of academic and/or venture capital participants. Submissions should not be more than three pages (preferably IEEE conference format, 2-column) in length. Demonstration submissions should include the space requirements and/or any other equipment-specific requirements. The documents must contain the authors' names, affiliations, and contact information and the designated corresponding author. Accepted authors of posters/demos will have a space in the poster/demo session room to display their posters or exhibit their demos and describe their work in discussions with interested attendees. IEEE Communications Society policy states that all accepted SECON 2006 posters/demos must have at least one registration at the regular rate. For authors co-authoring multiple posters/demos, one regular registration is valid for up to three presentations. Submission will be accepted until Friday, June 30th, 5 pm EDT for demos and for posters. Please send the submission material to the poster/demo chairs in pdf format, and make sure to include the first author name and either POSTER or DEMO in the name of the pdf file: Stefano Basagni Cedric Westphal Northeastern University Nokia basagni@ece.neu.edu cedric.westphal@nokia.com Notification of Poster/Demo decisions: July 21, 2006. Accepted Poster/Demo Presenters MUST register by August 31, 2006. ************************************************************************ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067k-Kl; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flj3l-0003DO-Vc; Thu, 01 Jun 2006 05:01:41 -0400 Received: from smtp.irisa.fr ([131.254.254.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flj3k-00064p-Ah; Thu, 01 Jun 2006 05:01:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 0A1A7FAA9; Thu, 1 Jun 2006 11:01:39 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02418-09; Thu, 1 Jun 2006 11:01:37 +0200 (CEST) Received: from [131.254.10.213] (centocelle.irisa.fr [131.254.10.213]) by smtp.irisa.fr (Postfix) with ESMTP id 64DE1FA9E; Thu, 1 Jun 2006 11:01:37 +0200 (CEST) Message-ID: <447EACF1.7070105@irisa.fr> Date: Thu, 01 Jun 2006 11:01:37 +0200 From: Maria Gradinariu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tccc@cs.columbia.edu, csljc@ieee.org, computational.science@lists.optimalnumerics.com, podc@acm.org, ecoop-info@ecoop.org, mobisys@acm.org, tcgn@ieee.org, sigmetrics-members@acm.org, www-mobile@w3.org, mobicom@acm.org, SIGCOMM-MEMBERS@acm.org, tarot@hds.utc.fr, wg2@wireless-world-research.org, comm-theory@ieee.org, ifip-tc6@informatik.rwth-aachen.de, wg3@wireless-world-research.org, mip6@ietf.org, reres@laas.fr, dmanet@zpr.uni-koel.de, mip4@ietf.org, mipshop-bounces@ietf.org, TC-comswtc@comsoc.org, SENSORNET-request@LISTSERV.ACM.ORG, KUVS-L-request@LISTSERV.UNI-HEIDELBERG.DE, SIGMOB-request@LISTSERV.ACM.ORG, fokus-user@fokus.fraunhofer.de, types@cis.upenn.edu, comswtc@comsoc.org, coregrid-wp4@inria.fr, disc-announce@listes.epfl.ch, multicomm@comsoc.org, sigecom-talk@acm.org, adept@irisa.fr, paris@irisa.fr, aces@irisa.fr, caps@irisa.fr, armor@irisa.fr, liste-parall@lri.fr, grandlarge@lri.fr, arp@cines.fr, tccc@cs.columbia.edu, bahl@acm.org, www-mobile@w3.org, nrg-list@eecs.umich.edu, ns-announce@isi.edu, itc@i-teletraffic.org, wg7_3@cs.umass.edu, netnomics@listserver.tue.nl, mmb@ira.uka.de, itc@ieee.org, aaa-wg@merit.edu, cfp@mmlab.snu.ac.kr, dbworld@cs.wisc.edu, performance@msr.csm.ornl.gov, testnet@canarie.ca, zeroconf@merit.edu, ukubinet-announce-admin@doc.ic.ac.uk, multicomm@research.panasonic.com, comswtc@comsoc.org, coregrid-wp4@inria.fr, disc-announce@listes.epfl.ch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at irisa.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Subject: [Mip4] [CFP] Symposium on Stabilization, Safety, and Security of, Distributed Systems (SSS 2006) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [Please accept our apologies if you receive multiple copies of this message.] Eighth International Symposium on Stabilization, Safety, and Security of Distributed Systems (formerly Symposium on Self-stabilizing Systems) (SSS 2006) November 17th-19th, 2006 Dallas, Texas, USA http://www.irisa.fr/sss/2006/ ============================================================================== Selected papers will be published in a special issue of the ACM Transactions on Autonomous and Adaptive Systems (TAAS). ============================================================================== =From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067k-Kl; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flj3l-0003DO-Vc; Thu, 01 Jun 2006 05:01:41 -0400 Received: from smtp.irisa.fr ([131.254.254.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flj3k-00064p-Ah; Thu, 01 Jun 2006 05:01:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id 0A1A7FAA9; Thu, 1 Jun 2006 11:01:39 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02418-09; Thu, 1 Jun 2006 11:01:37 +0200 (CEST) Received: from [131.254.10.213] (centocelle.irisa.fr [131.254.10.213]) by smtp.irisa.fr (Postfix) with ESMTP id 64DE1FA9E; Thu, 1 Jun 2006 11:01:37 +0200 (CEST) Message-ID: <447EACF1.7070105@irisa.fr> Date: Thu, 01 Jun 2006 11:01:37 +0200 From: Maria Gradinariu User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tccc@cs.columbia.edu, csljc@ieee.org, computational.science@lists.optimalnumerics.com, podc@acm.org, ecoop-info@ecoop.org, mobisys@acm.org, tcgn@ieee.org, sigmetrics-members@acm.org, www-mobile@w3.org, mobicom@acm.org, SIGCOMM-MEMBERS@acm.org, tarot@hds.utc.fr, wg2@wireless-world-research.org, comm-theory@ieee.org, ifip-tc6@informatik.rwth-aachen.de, wg3@wireless-world-research.org, mip6@ietf.org, reres@laas.fr, dmanet@zpr.uni-koel.de, mip4@ietf.org, mipshop-bounces@ietf.org, TC-comswtc@comsoc.org, SENSORNET-request@LISTSERV.ACM.ORG, KUVS-L-request@LISTSERV.UNI-HEIDELBERG.DE, SIGMOB-request@LISTSERV.ACM.ORG, fokus-user@fokus.fraunhofer.de, types@cis.upenn.edu, comswtc@comsoc.org, coregrid-wp4@inria.fr, disc-announce@listes.epfl.ch, multicomm@comsoc.org, sigecom-talk@acm.org, adept@irisa.fr, paris@irisa.fr, aces@irisa.fr, caps@irisa.fr, armor@irisa.fr, liste-parall@lri.fr, grandlarge@lri.fr, arp@cines.fr, tccc@cs.columbia.edu, bahl@acm.org, www-mobile@w3.org, nrg-list@eecs.umich.edu, ns-announce@isi.edu, itc@i-teletraffic.org, wg7_3@cs.umass.edu, netnomics@listserver.tue.nl, mmb@ira.uka.de, itc@ieee.org, aaa-wg@merit.edu, cfp@mmlab.snu.ac.kr, dbworld@cs.wisc.edu, performance@msr.csm.ornl.gov, testnet@canarie.ca, zeroconf@merit.edu, ukubinet-announce-admin@doc.ic.ac.uk, multicomm@research.panasonic.com, comswtc@comsoc.org, coregrid-wp4@inria.fr, disc-announce@listes.epfl.ch Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at irisa.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Subject: [Mip4] [CFP] Symposium on Stabilization, Safety, and Security of, Distributed Systems (SSS 2006) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org [Please accept our apologies if you receive multiple copies of this message.] Eighth International Symposium on Stabilization, Safety, and Security of Distributed Systems (formerly Symposium on Self-stabilizing Systems) (SSS 2006) November 17th-19th, 2006 Dallas, Texas, USA http://www.irisa.fr/sss/2006/ ============================================================================== Selected papers will be published in a special issue of the ACM Transactions on Autonomous and Adaptive Systems (TAAS). ============================================================================== ============================================================================== Important Dates Paper Submission: July 7th, 2006 Notification to Authors: August 21st, 2006 Camera-ready: August 31st, 2006 Symposium: November 17th-19th, 2006 ============================================================================== The Symposium is a prestigious international forum for researchers and practitioners in the design and development of fault-tolerant distributed systems with self-* properties, such as self-stabilizing, self-configuring, self-organizing, self-managing, self-repairing, self-healing, self-optimizing, self-adaptive, and self-protecting. The theory of self-stabilization has been enriched in the last 25 years by high quality research contributions in the areas of algorithmic techniques, formal methodologies, model theoretic issues, and composition techniques. All these areas are essential to the understanding and maintenance of self-* properties in fault-tolerant distributed systems. Research in distributed systems is now at a crucial point in its evolution, marked by the importance of dynamic systems such as peer-to-peer networks, large-scale wireless sensor networks, mobile ad hoc networks, robotic networks, etc. Moreover, new applications such as grid and web services, banking and e-commerce, e-health and robotics, aerospace and avionics, automotive, industrial process control, etc. have joined the traditional applications of distributed systems. Now, more than ever, the theory of self-stabilization has tremendous impact in these areas. Therefore, this year, we are extending the scope of the symposium to cover all safety and security related aspects of self-* systems. The title of the conference has been changed to reflect this expansion. There will be three tracks: networking, safety and security, and self-* properties in static and dynamic systems. The symposium solicits contributions on all aspects of self-stabilization, safety and security, recovery oriented systems and programing, from theoretical contributions, to reports of the actual experience of applying the principles of self-stabilization to static and dynamic systems. Topics of interest include, but are not limited to: Stabilization: - self-stabilizing systems - self-managed, self-assembling, autonomic and adaptive systems - self-optimizing and self-protecting systems - self-* abstractions for implementing fundamental services in static and dynamic distributed systems - impossibility results and lower bounds for self-* systems - application of stabilizing algorithms and techniques in dynamic distributed systems - data and code stabilization - algorithms for self-* error detection/correction Safety: - safety critical systems - trust models and specifications - semantics of trust, distrust, mistrust, over-trust, cheat, risk and reputation - trust-related security and privacy - reliable and dependable systems - fault-tolerant systems, hardware redundancy, robustness, survivable systems, failure recovery Security: - security of network protocols - security of sensor and mobile networks protocols - secure architectures, frameworks, policy, intrusion detection/awareness - proactive security - self-* properties and their relation with classical fault-tolerance and security - security protocols for self-* systems Networks and Applications: - models of fault-tolerant communication - stochastic, physical, and biological models to analyze self-* properties - communication complexity - data structures for efficient communication - self-stabilizing hardware, software, and middleware - algorithms for high-speed networks, sensors, wireless and robots networks - mobile agents - peer-to-peer networks, sensor networks, MANETs, and wireless mesh networks - network topologies, overlays, and protocols - protocols for secure and reliable data transport and search in wireless mesh networks - information storage and sharing in wireless mesh networks Contributors are invited to submit a PDF file of their paper============================================================================= Important Dates Paper Submission: July 7th, 2006 Notification to Authors: August 21st, 2006 Camera-ready: August 31st, 2006 Symposium: November 17th-19th, 2006 ============================================================================== The Symposium is a prestigious international forum for researchers and practitioners in the design and development of fault-tolerant distributed systems with self-* properties, such as self-stabilizing, self-configuring, self-organizing, self-managing, self-repairing, self-healing, self-optimizing, self-adaptive, and self-protecting. The theory of self-stabilization has been enriched in the last 25 years by high quality research contributions in the areas of algorithmic techniques, formal methodologies, model theoretic issues, and composition techniques. All these areas are essential to the understanding and maintenance of self-* properties in fault-tolerant distributed systems. Research in distributed systems is now at a crucial point in its evolution, marked by the importance of dynamic systems such as peer-to-peer networks, large-scale wireless sensor networks, mobile ad hoc networks, robotic networks, etc. Moreover, new applications such as grid and web services, banking and e-commerce, e-health and robotics, aerospace and avionics, automotive, industrial process control, etc. have joined the traditional applications of distributed systems. Now, more than ever, the theory of self-stabilization has tremendous impact in these areas. Therefore, this year, we are extending the scope of the symposium to cover all safety and security related aspects of self-* systems. The title of the conference has been changed to reflect this expansion. There will be three tracks: networking, safety and security, and self-* properties in static and dynamic systems. The symposium solicits contributions on all aspects of self-stabilization, safety and security, recovery oriented systems and programing, from theoretical contributions, to reports of the actual experience of applying the principles of self-stabilization to static and dynamic systems. Topics of interest include, but are not limited to: Stabilization: - self-stabilizing systems - self-managed, self-assembling, autonomic and adaptive systems - self-optimizing and self-protecting systems - self-* abstractions for implementing fundamental services in static and dynamic distributed systems - impossibility results and lower bounds for self-* systems - application of stabilizing algorithms and techniques in dynamic distributed systems - data and code stabilization - algorithms for self-* error detection/correction Safety: - safety critical systems - trust models and specifications - semantics of trust, distrust, mistrust, over-trust, cheat, risk and reputation - trust-related security and privacy - reliable and dependable systems - fault-tolerant systems, hardware redundancy, robustness, survivable systems, failure recovery Security: - security of network protocols - security of sensor and mobile networks protocols - secure architectures, frameworks, policy, intrusion detection/awareness - proactive security - self-* properties and their relation with classical fault-tolerance and security - security protocols for self-* systems Networks and Applications: - models of fault-tolerant communication - stochastic, physical, and biological models to analyze self-* properties - communication complexity - data structures for efficient communication - self-stabilizing hardware, software, and middleware - algorithms for high-speed networks, sensors, wireless and robots networks - mobile agents - peer-to-peer networks, sensor networks, MANETs, and wireless mesh networks - network topologies, overlays, and protocols - protocols for secure and reliable data transport and search in wireless mesh networks - information storage and sharing in wireless mesh networks Contributors are invited to submit a PDF file of their paper. Submissions should be no longer than 4800 words and should not exceed 12 pages on letter-size paper using at least 11 point font and reasonable margins (the page limit includes all figures, tables, and graphs). Submissions should include a cover page (that does not count towards the 12 page limit) that includes paper title, authors and affiliations, contact author's e-mail address, an abstract of the work in a few lines, and a few keywords. Submitted papers may have appendices beyond the 12 page limit, but reviewers are free to disregard any material beyond the 12 page limit. A paper submitted to SSS 2006 is expected to be original research not previously published; a submission may not be concurrently submitted or to any other conference, workshop, or journal. The proceedings of the conference will be published in the Springer Verlag Lecture Notes in Computer Science (LNCS) series. Selected papers will be published in a special issue of the ACM Transactions on Autonomous and Adaptive Systems (TAAS). General Chair: Mohamed Gouda, University of Texas at Austin, USA, gouda@cs.utexas.edu Program Co-chairs: Ajoy K Datta University of Nevada Las Vegas, USA, datta@cs.unlv.edu Maria Gradinariu, IRISA, France, mgradina@irisa.fr Local Arrangements Chair: Jorge Cobb, University of Texas at Dallas, USA, cobb@utdallas.edu Ravi Prakash, University of Texas at Dallas, USA, ravip@utdallas.edu Publicity and Web Chair: Florent Claerhout, IRISA, France, fclaerho@irisa.fr Steering Committee: Anish Arora, Ohio State University, USA, anish@cse.ohio-state.edu Ajoy K. Datta, University of Nevada Las Vegas, USA, datta@cs.unlv.edu Shlomi Dolev, Ben-Gurion University of the Negev, Israel, dolev@cs.bgu.ac.il Sukumar Ghosh, Chair, University of Iowa, USA, ghosh@cs.uiowa.edu Mohamed G. Gouda, University of Texas at Austin, USA, gouda@cs.utexas.edu Ted Herman, University of Iowa, USA, ted-herman@uiowa.edu Shing-Tsaan Huang, National Central University, Taiwan, sthuang@csie.ncu.edu.tw Toshimitsu Masuzawa, Osaka University, Japan, masuzawa@ist.osaka-u.ac.jp Vincent Villain, Universie de Picardie, France, villain@laria.u-picardie.fr -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067A-7D; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FldSY-0004CX-My; Wed, 31 May 2006 23:02:54 -0400 Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FldSY-0003N5-6S; Wed, 31 May 2006 23:02:54 -0400 Received: from hpn307pc2 (cpe-66-67-141-103.rochester.res.rr.com [66.67.141.103]) by ms-smtp-02.nyroc.rr.com (8.13.6/8.13.6) with SMTP id k5132pZE029500; Wed, 31 May 2006 23:02:52 -0400 (EDT) Message-ID: <006d01c68527$df5bec40$6701a8c0@hpn307pc2> From: "Wendi Heinzelman" To: , , , Date: Wed, 31 May 2006 23:02:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-02.nyroc.rr.com id k5132pZE029500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Wendi Heinzelman Subject: [Mip4] DCOSS 2006 Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobi. Submissions should be no longer than 4800 words and should not exceed 12 pages on letter-size paper using at least 11 point font and reasonable margins (the page limit includes all figures, tables, and graphs). Submissions should include a cover page (that does not count towards the 12 page limit) that includes paper title, authors and affiliations, contact author's e-mail address, an abstract of the work in a few lines, and a few keywords. Submitted papers may have appendices beyond the 12 page limit, but reviewers are free to disregard any material beyond the 12 page limit. A paper submitted to SSS 2006 is expected to be original research not previously published; a submission may not be concurrently submitted or to any other conference, workshop, or journal. The proceedings of the conference will be published in the Springer Verlag Lecture Notes in Computer Science (LNCS) series. Selected papers will be published in a special issue of the ACM Transactions on Autonomous and Adaptive Systems (TAAS). General Chair: Mohamed Gouda, University of Texas at Austin, USA, gouda@cs.utexas.edu Program Co-chairs: Ajoy K Datta University of Nevada Las Vegas, USA, datta@cs.unlv.edu Maria Gradinariu, IRISA, France, mgradina@irisa.fr Local Arrangements Chair: Jorge Cobb, University of Texas at Dallas, USA, cobb@utdallas.edu Ravi Prakash, University of Texas at Dallas, USA, ravip@utdallas.edu Publicity and Web Chair: Florent Claerhout, IRISA, France, fclaerho@irisa.fr Steering Committee: Anish Arora, Ohio State University, USA, anish@cse.ohio-state.edu Ajoy K. Datta, University of Nevada Las Vegas, USA, datta@cs.unlv.edu Shlomi Dolev, Ben-Gurion University of the Negev, Israel, dolev@cs.bgu.ac.il Sukumar Ghosh, Chair, University of Iowa, USA, ghosh@cs.uiowa.edu Mohamed G. Gouda, University of Texas at Austin, USA, gouda@cs.utexas.edu Ted Herman, University of Iowa, USA, ted-herman@uiowa.edu Shing-Tsaan Huang, National Central University, Taiwan, sthuang@csie.ncu.edu.tw Toshimitsu Masuzawa, Osaka University, Japan, masuzawa@ist.osaka-u.ac.jp Vincent Villain, Universie de Picardie, France, villain@laria.u-picardie.fr -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067A-7D; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FldSY-0004CX-My; Wed, 31 May 2006 23:02:54 -0400 Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FldSY-0003N5-6S; Wed, 31 May 2006 23:02:54 -0400 Received: from hpn307pc2 (cpe-66-67-141-103.rochester.res.rr.com [66.67.141.103]) by ms-smtp-02.nyroc.rr.com (8.13.6/8.13.6) with SMTP id k5132pZE029500; Wed, 31 May 2006 23:02:52 -0400 (EDT) Message-ID: <006d01c68527$df5bec40$6701a8c0@hpn307pc2> From: "Wendi Heinzelman" To: , , , Date: Wed, 31 May 2006 23:02:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: Symantec AntiVirus Scan Engine Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ms-smtp-02.nyroc.rr.com id k5132pZE029500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b6e18fadcfab41fa5e7faede753de4c2 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Wendi Heinzelman Subject: [Mip4] DCOSS 2006 Call for Participation X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org =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 PARTICIPATION =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 IEEE International Conference on Distributed Computing in Sensor Systems June 18 - 20, 2006 San Francisco, California, USA =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 WWW.DCOSS.ORG The 2006 International Conference on Distributed Computing in Sensor Syst= ems (DCOSS '06) will take place in San Francisco during June 18 - 20, 2006. DCOSS '06 will represent a merger of the DCOSS conference series and the IEEE International Workshops on Algorithms for Wireless, Mobile, Ad Hoc a= nd Sensor Networks (WMAN). The first DCOSS conference, held at Marina del Re= y on June 30-July 1, 2005, featured high quality research papers and interesti= ng invited and contributed poster/presentation sessions. DCOSS '06 is inten= ded to cover several aspects of distributed computing in sensor systems such = as high level abstractions, computational models, systematic design methodol= ogies, algorithms, analysis and applications. The conference will be co-located = with several closely related workshops, and will provide a forum for researche= rs and practitioners to present their contributions related to the above high-level aspects of distributed sensor systems. In addition to contribu= ted papers, the meeting will also include keynote addresses by leading resear= chers, a panel discussion, and a poster/presentation session. SPONSORED BY IEEE Computer Society Technical Committee on Parallel Processing (TCPP) IEEE Computer Society Technical Committee on Distributed Processing (TCDP= ) Held in co-operation with ACM SIGARCH ACM SIGBED European Association for Theoretical Computer Science (EATCS) IFIP WG 10.3 =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 CONFERENCE PROGRAM =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 SUNDAY, JUNE 18, 2006 Workshop: Euro-American Workshop on Middleware for Sensor Networks (EAWMS= ) Workshop: Mobility and Scalability in Wireless Sensor Networks (MSWSN) =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 MONDAY, JUNE 19, 2006 7:30 am - 8:20 am Continental Breakfast 8:20 am - 8:30 am Opening Remarks Jose Rolim (Steering Committee Chair, Univ. of Geneva, Switzerland) Viktor Prasanna (General Chair, Univ. of Southern California, USA) Phil Gibbons (Program Chair, Intel Research/CMU, USA) 8:30 am - 9:35 am KEYNOTE: "Structure Discovery and Information Brokerage in Sensor Networks" Leonidas Guibas (Stanford Univ., USA) -------------------------------------------------- 9:35 am - 9:50 am BREAK -------------------------------------------------- 9:50 am - 11:50 am Session 1: DISTRIBUTED ALGORITHMS & APPLICATIONS * Evaluating lity for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org =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 PARTICIPATION =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 IEEE International Conference on Distributed Computing in Sensor Systems June 18 - 20, 2006 San Francisco, California, USA =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 WWW.DCOSS.ORG The 2006 International Conference on Distributed Computing in Sensor Syst= ems (DCOSS '06) will take place in San Francisco during June 18 - 20, 2006. DCOSS '06 will represent a merger of the DCOSS conference series and the IEEE International Workshops on Algorithms for Wireless, Mobile, Ad Hoc a= nd Sensor Networks (WMAN). The first DCOSS conference, held at Marina del Re= y on June 30-July 1, 2005, featured high quality research papers and interesti= ng invited and contributed poster/presentation sessions. DCOSS '06 is inten= ded to cover several aspects of distributed computing in sensor systems such = as high level abstractions, computational models, systematic design methodol= ogies, algorithms, analysis and applications. The conference will be co-located = with several closely related workshops, and will provide a forum for researche= rs and practitioners to present their contributions related to the above high-level aspects of distributed sensor systems. In addition to contribu= ted papers, the meeting will also include keynote addresses by leading resear= chers, a panel discussion, and a poster/presentation session. SPONSORED BY IEEE Computer Society Technical Committee on Parallel Processing (TCPP) IEEE Computer Society Technical Committee on Distributed Processing (TCDP= ) Held in co-operation with ACM SIGARCH ACM SIGBED European Association for Theoretical Computer Science (EATCS) IFIP WG 10.3 =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 CONFERENCE PROGRAM =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 SUNDAY, JUNE 18, 2006 Workshop: Euro-American Workshop on Middleware for Sensor Networks (EAWMS= ) Workshop: Mobility and Scalability in Wireless Sensor Networks (MSWSN) =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 MONDAY, JUNE 19, 2006 7:30 am - 8:20 am Continental Breakfast 8:20 am - 8:30 am Opening Remarks Jose Rolim (Steering Committee Chair, Univ. of Geneva, Switzerland) Viktor Prasanna (General Chair, Univ. of Southern California, USA) Phil Gibbons (Program Chair, Intel Research/CMU, USA) 8:30 am - 9:35 am KEYNOTE: "Structure Discovery and Information Brokerage in Sensor Networks" Leonidas Guibas (Stanford Univ., USA) -------------------------------------------------- 9:35 am - 9:50 am BREAK -------------------------------------------------- 9:50 am - 11:50 am Session 1: DISTRIBUTED ALGORITHMS & APPLICATIONS * Evaluating Local Contributions to Global Performance in Wireless Sensor and Actuator Networks Christopher Rozell, Don Johnson (Rice Univ., USA) * Roadmap Query for Sensor Network Assisted Navigation in Dynamic Environments Sangeeta Bhattacharya, Nuzhet Atay, Gazihan Alankus, Chenyang Lu, Burchan Bayazit, Gruia-Catalin Roman (Washington Univ. in St. Louis, USA) * Stabilizing Consensus in Mobile Networks Dana Angluin, Michael J. Fischer, Hong Jiang (Yale Univ.) * When Birds Die: Making Population Protocols Fault-Tolerant Carole Delporte-Gallet (Universite Paris); Hugues Fauconnier (LIAFA, Paris); Rachid Guerraoui (Swiss Federal Institute of Technology (EPFL)); Eric Ruppert (York Univ.) * Stochastically Consistent Caching and Dynamic Duty Cycling for Erratic Sensor Sources Shanzhong Zhu, Wei Wang, Chinya Ravishankar (Univ. of California at Riverside, USA) * Distributed Model-Free Stochastic Optimization in Wireless Sensor Netwo= rks Daniel Yagan, Chen Khong Tham (National Univ. of Singapore) -------------------------------------------------- 11:50 am - 1:15 pm LUNCH (on your own) -------------------------------------------------- 1:15 pm - 3:15 pm Session 2: PROGRAMMING SUPPORT & MIDDLEWARE * Agimone: Middleware Support for Seamless Integration of Sensor and IP Networks Gregory Hackmann, Chien-Liang Fok, Gruia-Catalin Roman, Chenyang Lu (Washington Univ. St. Louis) * Gossip Based Multi-Channel Reprogramming for Sensor Networks Limin Wang, Sandeep Kulkarni (Michigan State Univ.) * The Virtual Pheromone Communication Primitive Leo Szumel, John Owens (Univ. of California at Davis) * Logical Neighborhoods: A Programming Abstraction for Wireless Sensor Ne= tworks Luca Mottola, Gian Pietro Picco (Politecnico di Milano) * Y-Threads: Supporting Concurrency in Wireless Sensor Networks Christopher Nitta, Raju Pandey, Yann Ramin (Univ. of California at Davis) * Comparative Analysis of Push-Pull Query Strategies for Wireless Sensor = Networks Shyam Kapadia, Bhaskar Krishnamachari (Univ. of Southern California) -------------------------------------------------- 3:15 pm - 3:30 pm BREAK -------------------------------------------------- 3:30 pm - 5:30 pm Session 3: DATA AGGREGATION & DISSEMINATION * Using Data Aggregation to Prevent Traffic Analysis in Wireless Sensor Networks William Conner, Tarek Abdelzaher, Klara Nahrstedt (Univ. of Illinois at Urbana-Champaign) * Efficient and Robust Data Dissemination using Limited Extra Network Knowledge Ioannis Chatzigiannakis (Computer Technology Institute); Athanasios Kinalis, Sotiris Nikoletseas (Univ. of Patras and Computer Technology Institute) * Distance-Sensitive Information Brokerage in Sensor Networks Stefan Funke (Max-Planck-Institut f. Informatik); Leonidas Guibas, An Nguyen, Yusu Wang (Stanford) * Efficient In-Network Processing through Local Ad-hoc Information Coalescence Onur Savas, Murat Alanyali,Venkatesh Saligrama (Boston Univ.) * Distributed Optimal Estimation from Relative Measurements for Localizat= ion and Time Synchronization Prabir Barooah (UCSB); Neimar Da Silva (Federal Univ. of Rio de Janerio)= ; Joao Hespanha (UCSB) * GIST: Group-Independent Spanning Tree for Data Aggregation in Dense Sensor Networks Lujun Jia, Guevara Noubir, Rajmohan Rajaraman, Ravi Sundaram (Northeastern Univ.) -------------------------------------------------- 5:30 pm - 7:30 pm Poster Session and Reception Chair: Jim Reich (Palo Alto Research Center, USA) =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 TUESDAY, JUNE 20, 2006 8:00 am - 8:30 am Continental Breakfast 8:30 am - 9:35 am KEYNOTE: "In-network Adaptation of Sensor Node Location and Energy" William J. Kaiser (Univ. of California, Los Angeles) -------------------------------------------------- 9:35 am - 9:50 am BREAK -------------------------------------------------- 9:50 am - 10:50 am Session 4: SECURITY * Distributed User Access Control in Sensor Networks HaLocal Contributions to Global Performance in Wireless Sensor and Actuator Networks Christopher Rozell, Don Johnson (Rice Univ., USA) * Roadmap Query for Sensor Network Assisted Navigation in Dynamic Environments Sangeeta Bhattacharya, Nuzhet Atay, Gazihan Alankus, Chenyang Lu, Burchan Bayazit, Gruia-Catalin Roman (Washington Univ. in St. Louis, USA) * Stabilizing Consensus in Mobile Networks Dana Angluin, Michael J. Fischer, Hong Jiang (Yale Univ.) * When Birds Die: Making Population Protocols Fault-Tolerant Carole Delporte-Gallet (Universite Paris); Hugues Fauconnier (LIAFA, Paris); Rachid Guerraoui (Swiss Federal Institute of Technology (EPFL)); Eric Ruppert (York Univ.) * Stochastically Consistent Caching and Dynamic Duty Cycling for Erratic Sensor Sources Shanzhong Zhu, Wei Wang, Chinya Ravishankar (Univ. of California at Riverside, USA) * Distributed Model-Free Stochastic Optimization in Wireless Sensor Netwo= rks Daniel Yagan, Chen Khong Tham (National Univ. of Singapore) -------------------------------------------------- 11:50 am - 1:15 pm LUNCH (on your own) -------------------------------------------------- 1:15 pm - 3:15 pm Session 2: PROGRAMMING SUPPORT & MIDDLEWARE * Agimone: Middleware Support for Seamless Integration of Sensor and IP Networks Gregory Hackmann, Chien-Liang Fok, Gruia-Catalin Roman, Chenyang Lu (Washington Univ. St. Louis) * Gossip Based Multi-Channel Reprogramming for Sensor Networks Limin Wang, Sandeep Kulkarni (Michigan State Univ.) * The Virtual Pheromone Communication Primitive Leo Szumel, John Owens (Univ. of California at Davis) * Logical Neighborhoods: A Programming Abstraction for Wireless Sensor Ne= tworks Luca Mottola, Gian Pietro Picco (Politecnico di Milano) * Y-Threads: Supporting Concurrency in Wireless Sensor Networks Christopher Nitta, Raju Pandey, Yann Ramin (Univ. of California at Davis) * Comparative Analysis of Push-Pull Query Strategies for Wireless Sensor = Networks Shyam Kapadia, Bhaskar Krishnamachari (Univ. of Southern California) -------------------------------------------------- 3:15 pm - 3:30 pm BREAK -------------------------------------------------- 3:30 pm - 5:30 pm Session 3: DATA AGGREGATION & DISSEMINATION * Using Data Aggregation to Prevent Traffic Analysis in Wireless Sensor Networks William Conner, Tarek Abdelzaher, Klara Nahrstedt (Univ. of Illinois at Urbana-Champaign) * Efficient and Robust Data Dissemination using Limited Extra Network Knowledge Ioannis Chatzigiannakis (Computer Technology Institute); Athanasios Kinalis, Sotiris Nikoletseas (Univ. of Patras and Computer Technology Institute) * Distance-Sensitive Information Brokerage in Sensor Networks Stefan Funke (Max-Planck-Institut f. Informatik); Leonidas Guibas, An Nguyen, Yusu Wang (Stanford) * Efficient In-Network Processing through Local Ad-hoc Information Coalescence Onur Savas, Murat Alanyali,Venkatesh Saligrama (Boston Univ.) * Distributed Optimal Estimation from Relative Measurements for Localizat= ion and Time Synchronization Prabir Barooah (UCSB); Neimar Da Silva (Federal Univ. of Rio de Janerio)= ; Joao Hespanha (UCSB) * GIST: Group-Independent Spanning Tree for Data Aggregation in Dense Sensor Networks Lujun Jia, Guevara Noubir, Rajmohan Rajaraman, Ravi Sundaram (Northeastern Univ.) -------------------------------------------------- 5:30 pm - 7:30 pm Poster Session and Reception Chair: Jim Reich (Palo Alto Research Center, USA) =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 TUESDAY, JUNE 20, 2006 8:00 am - 8:30 am Continental Breakfast 8:30 am - 9:35 am KEYNOTE: "In-network Adaptation of Sensor Node Location and Energy" William J. Kaiser (Univ. of California, Los Angeles) -------------------------------------------------- 9:35 am - 9:50 am BREAK -------------------------------------------------- 9:50 am - 10:50 am Session 4: SECURITY * Distributed User Access Control in Sensor Networks Haodong Wang, Qun Li (College of William and Mary) * Locating Compromised Sensor Nodes through Incremental Hashing Authentication Youtao Zhang (Univ. of Pittsburgh); Jun Yang, Lingling Jin (UC Riverside); Weijia Li (Univ. of Pittsburgh) * COTA: A Robust Multi-hop Localization Scheme in Wireless Sensor Network= s Yawen Wei, Zhen Yu, Yong Guan (Iowa State Univ.) 10:50 am - 11:50 am Session 5: INFORMATION FUSION * Contour Approximation in Sensor Networks Chiranjeeb Buragohain, Sorabh Gandhi (UCSB); John Hershberger (Mentor Graphics); Subhash Suri (UCSB) * A Distortion Aware Scheduling Approach for Wireless Sensor Networks Periklis Liaskovitis, Curt Schurgers (UCSD) * Optimal Placement and Selection of Camera Network Nodes for Target Localization Ali Ercan, Danny Yang, Abbas El Gamal, Leonidas Guibas (Stanford) -------------------------------------------------- 11:50 am - 1:15 pm LUNCH (on your own) -------------------------------------------------- 1:15 pm - 3:15 pm Session 6: LIFETIME MAXIMIZATION * An Optimal Data Propagation Algorithm for Maximizing the Lifespan of Sensor Networks Aubin Jarry, Pierre Leone, Olivier Powell, Jose Rolim (Univ. of Geneva) * Lifetime Maximization under Connectivity and k-Coverage Constraints in Wireless Sensor Networks Wei Mo, Daji Qiao, Zhengdao Wang (Iowa State Univ.) * Network Power Scheduling for TinyOS Applications Barbara Hohlt, Eric Brewer (UC Berkeley) * Algorithms for Scheduling Wireless Sensor Networks with Rate and Duty-Cycle Constraints over Interference Channels Rajgopal Kannan, Shuangqing Wei (Louisiana State Univ.) * MobiRoute: Routing towards a Mobile Sink for Improving Lifetime in Sensor Networks Jun Luo, Jacques Panchard, Michal Piorkowski, Matthias Grossglauser, Jean-Pierre Hubaux (Swiss Federal Institute of Technology (EPFL)) * SenCar: An Energy Efficient Data Gathering Mechanism for Large Scale Multihop Sensor Networks Ming Ma, Yuanyuan Yang (State Univ. of New York at Stony Brook) -------------------------------------------------- 3:15 pm - 3:30 pm BREAK -------------------------------------------------- 3:30 pm - 4:30 pm Session 7: LOCALIZATION * A Distributed Linear Least Squares Method for Precise Localization with Low Complexity in Wireless Sensor Networks Frank Reichenbach (University of Rostock) * Consistency-Based On-line Localization in Sensor Networks Jessica Feng, Miodrag Potkonjak (University of California at Los Angeles) * The Robustness of Localization Algorithms to Signal Strength Attacks: A Comparative Study Yingying Chen, Konstantin Kleisouris, Xiaoyan Li, Wade Trappe, Richard Martin (Rutgers University) -------------------------------------------------- 4:30 pm DCOSS 2006 CONCLUDES =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 WORKSHOP PROGRAMS =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 EURO-AMERICAN WORKSHOP ON MIDDLEWARE FOR SENSOR NETWORKS (EAWMS) =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 SUNDAY, JUNE 18, 2006 8:00 am - 9:00 am Continental Breakfast 9:00 am - 9:15 am Opening Remarks: Stefan Fischer (Chair) 9:15 am - 10:30 am Session 1 * FABRIC: Towards Data Type-centric Middleware Synthesis Dennis Pfisterer, Horst Hellbr?ck, Stefan Fischer (University of L?beck, Germany) * Rule-Oriented Programming for Wireless Sensor Networks Kirsten Terfloth, Georg Wittemburg, Joschen Schiller (Freie Universitdt Berlin, Germany) Discussion -------------------------------------------------- 10:30 am - 10:45 am BREAK -------------------------------------------------- 10:45 am - 12:00 pm Session 2 * Transiently Shared Tuple Spaces for Sensor Networks odong Wang, Qun Li (College of William and Mary) * Locating Compromised Sensor Nodes through Incremental Hashing Authentication Youtao Zhang (Univ. of Pittsburgh); Jun Yang, Lingling Jin (UC Riverside); Weijia Li (Univ. of Pittsburgh) * COTA: A Robust Multi-hop Localization Scheme in Wireless Sensor Network= s Yawen Wei, Zhen Yu, Yong Guan (Iowa State Univ.) 10:50 am - 11:50 am Session 5: INFORMATION FUSION * Contour Approximation in Sensor Networks Chiranjeeb Buragohain, Sorabh Gandhi (UCSB); John Hershberger (Mentor Graphics); Subhash Suri (UCSB) * A Distortion Aware Scheduling Approach for Wireless Sensor Networks Periklis Liaskovitis, Curt Schurgers (UCSD) * Optimal Placement and Selection of Camera Network Nodes for Target Localization Ali Ercan, Danny Yang, Abbas El Gamal, Leonidas Guibas (Stanford) -------------------------------------------------- 11:50 am - 1:15 pm LUNCH (on your own) -------------------------------------------------- 1:15 pm - 3:15 pm Session 6: LIFETIME MAXIMIZATION * An Optimal Data Propagation Algorithm for Maximizing the Lifespan of Sensor Networks Aubin Jarry, Pierre Leone, Olivier Powell, Jose Rolim (Univ. of Geneva) * Lifetime Maximization under Connectivity and k-Coverage Constraints in Wireless Sensor Networks Wei Mo, Daji Qiao, Zhengdao Wang (Iowa State Univ.) * Network Power Scheduling for TinyOS Applications Barbara Hohlt, Eric Brewer (UC Berkeley) * Algorithms for Scheduling Wireless Sensor Networks with Rate and Duty-Cycle Constraints over Interference Channels Rajgopal Kannan, Shuangqing Wei (Louisiana State Univ.) * MobiRoute: Routing towards a Mobile Sink for Improving Lifetime in Sensor Networks Jun Luo, Jacques Panchard, Michal Piorkowski, Matthias Grossglauser, Jean-Pierre Hubaux (Swiss Federal Institute of Technology (EPFL)) * SenCar: An Energy Efficient Data Gathering Mechanism for Large Scale Multihop Sensor Networks Ming Ma, Yuanyuan Yang (State Univ. of New York at Stony Brook) -------------------------------------------------- 3:15 pm - 3:30 pm BREAK -------------------------------------------------- 3:30 pm - 4:30 pm Session 7: LOCALIZATION * A Distributed Linear Least Squares Method for Precise Localization with Low Complexity in Wireless Sensor Networks Frank Reichenbach (University of Rostock) * Consistency-Based On-line Localization in Sensor Networks Jessica Feng, Miodrag Potkonjak (University of California at Los Angeles) * The Robustness of Localization Algorithms to Signal Strength Attacks: A Comparative Study Yingying Chen, Konstantin Kleisouris, Xiaoyan Li, Wade Trappe, Richard Martin (Rutgers University) -------------------------------------------------- 4:30 pm DCOSS 2006 CONCLUDES =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 WORKSHOP PROGRAMS =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 EURO-AMERICAN WORKSHOP ON MIDDLEWARE FOR SENSOR NETWORKS (EAWMS) =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 SUNDAY, JUNE 18, 2006 8:00 am - 9:00 am Continental Breakfast 9:00 am - 9:15 am Opening Remarks: Stefan Fischer (Chair) 9:15 am - 10:30 am Session 1 * FABRIC: Towards Data Type-centric Middleware Synthesis Dennis Pfisterer, Horst Hellbr?ck, Stefan Fischer (University of L?beck, Germany) * Rule-Oriented Programming for Wireless Sensor Networks Kirsten Terfloth, Georg Wittemburg, Joschen Schiller (Freie Universitdt Berlin, Germany) Discussion -------------------------------------------------- 10:30 am - 10:45 am BREAK -------------------------------------------------- 10:45 am - 12:00 pm Session 2 * Transiently Shared Tuple Spaces for Sensor Networks Amy L. Murphy (University of Lugano, Switzerland), Gian Pietro Picco (Politecnico di Milano, Italy) * Sensor Network Middleware for Managing a Cross-Layer Architecture Christophe J. Merlin, Wendi B. Heinzelman (University of Rochester, USA) Discussion -------------------------------------------------- 12:00 pm - 1:00 pm LUNCH (on your own) -------------------------------------------------- 1:00 pm - 2:15 pm Session 3 * Frugal Mobile Objects Benoit Garbinato (University of Lausanne, Switzerland), Rachid Guerraoui, Jarle Hulaas, Maxime Monod, Jesper H. Spring (EPFL, Switzerland) * Resource-Aware Service Architecture for Collaboration of Sensor Nodes Jan Blumenthal, Dirk Timmermann (University of Rostock, Germany) Discussion -------------------------------------------------- 2:15 pm - 2:30 pm BREAK -------------------------------------------------- 2:30 pm - 3:45 pm Session 4 * Distributed Mining of Spatio-Temporal Event-Pattern in Sensor Networks Kay Rfmer (ETHZ, Switzerland) * Middleware and Simulation Support for WSN Motion Control Agorithm Design and Analysis Norbert Luttenberger, Jochen Koberstein (University of Kiel, Germany) Discussion -------------------------------------------------- 3:45 pm - 4:00 pm BREAK -------------------------------------------------- 4:00 pm - 5:30 pm Session 5 * SensorBase.org - a Centralized Repository to Slog Sensor Network Data Kevin Chang, Nathan Yau, Mark Hansen, Deborah Estrin (University of California at Los Angeles, USA) * Pervasive Grids: Integrating Sensor Networks into the Fixed Grid Geoff Coulson (Lancaster University, England) Discussion Future Steps =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 WORKSHOP ON MOBILITY AND SCALABILITY IN WIRELESS SENSOR NETWORKS (MSWSN) =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 SUNDAY, JUNE 18, 2006 8:00 am - 8:45 am Continental Breakfast 8:45 am - 9:00 am Opening Remarks Christian Schindelhaer (Chair) 9:00 am - 11:00 am Session 1: MOBILITY * Invited Talk: Keith J. O'Hara (Georgia Institute of Technology, USA) Mobility and Pervasiveness in Physical Computing Systems joint work with Tucker Balch (Georgia Institute of Technology, USA) * Mobility Management in Sensor Networks Muneeb Ali (Lahore University of Management Sciences, Pakistan), Thiemo Voigt (Swedish Institute of Computer Science, Kista, Sweden), Zartash Afzal Uzmi (Lahore University of Management Sciences, Pakistan) * Autonomous Mobile Networks Overlaid on Public Transportation Networks G. Sampath (Rochester Institute of Technology, USA), J. TenEyck (Marist College, Poughkeepsie, USA) -------------------------------------------------- 11:00 am - 11:15 am BREAK -------------------------------------------------- 11:15 am - 12:30 pm Session 2: SCALABILITY * Invited Talk: S=E1ndor Fekete (Braunschweig University of Technology, G= ermany) Algorithmic Aspects of Large Sensor Networks joint work with Alexander Kr=FCller (Braunschweig University of Technology, Germany), Dennis Pfisterer, Stefan Fischer (University of L=FCbeck, Germany) * Intelligent Hierarchical Cluster-Based Routing Abdul W. Matin, Sajid Hussain (Jodrey School of Computer Science, Wolfville, Canada) -------------------------------------------------- 12:30 pm - 2:00 pm LUNCH (on your own) -------------------------------------------------- 2:00 pm - 4:00 pm Session 3: LIFETIME * Invited Talk: Sotiris Nikoletseas (Research Academic Computer Technology Institute, Patras, Greece) "Adaptive Power Saving for Heterogeneous Sensor Networks with Incremental Deployment" * Invited Talk: Jun Luo (School of Computer and Communication Sciences, Lausanne, Switzerland) "Mobility to Improve the Lifetime of Wi Amy L. Murphy (University of Lugano, Switzerland), Gian Pietro Picco (Politecnico di Milano, Italy) * Sensor Network Middleware for Managing a Cross-Layer Architecture Christophe J. Merlin, Wendi B. Heinzelman (University of Rochester, USA) Discussion -------------------------------------------------- 12:00 pm - 1:00 pm LUNCH (on your own) -------------------------------------------------- 1:00 pm - 2:15 pm Session 3 * Frugal Mobile Objects Benoit Garbinato (University of Lausanne, Switzerland), Rachid Guerraoui, Jarle Hulaas, Maxime Monod, Jesper H. Spring (EPFL, Switzerland) * Resource-Aware Service Architecture for Collaboration of Sensor Nodes Jan Blumenthal, Dirk Timmermann (University of Rostock, Germany) Discussion -------------------------------------------------- 2:15 pm - 2:30 pm BREAK -------------------------------------------------- 2:30 pm - 3:45 pm Session 4 * Distributed Mining of Spatio-Temporal Event-Pattern in Sensor Networks Kay Rfmer (ETHZ, Switzerland) * Middleware and Simulation Support for WSN Motion Control Agorithm Design and Analysis Norbert Luttenberger, Jochen Koberstein (University of Kiel, Germany) Discussion -------------------------------------------------- 3:45 pm - 4:00 pm BREAK -------------------------------------------------- 4:00 pm - 5:30 pm Session 5 * SensorBase.org - a Centralized Repository to Slog Sensor Network Data Kevin Chang, Nathan Yau, Mark Hansen, Deborah Estrin (University of California at Los Angeles, USA) * Pervasive Grids: Integrating Sensor Networks into the Fixed Grid Geoff Coulson (Lancaster University, England) Discussion Future Steps =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 WORKSHOP ON MOBILITY AND SCALABILITY IN WIRELESS SENSOR NETWORKS (MSWSN) =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 SUNDAY, JUNE 18, 2006 8:00 am - 8:45 am Continental Breakfast 8:45 am - 9:00 am Opening Remarks Christian Schindelhaer (Chair) 9:00 am - 11:00 am Session 1: MOBILITY * Invited Talk: Keith J. O'Hara (Georgia Institute of Technology, USA) Mobility and Pervasiveness in Physical Computing Systems joint work with Tucker Balch (Georgia Institute of Technology, USA) * Mobility Management in Sensor Networks Muneeb Ali (Lahore University of Management Sciences, Pakistan), Thiemo Voigt (Swedish Institute of Computer Science, Kista, Sweden), Zartash Afzal Uzmi (Lahore University of Management Sciences, Pakistan) * Autonomous Mobile Networks Overlaid on Public Transportation Networks G. Sampath (Rochester Institute of Technology, USA), J. TenEyck (Marist College, Poughkeepsie, USA) -------------------------------------------------- 11:00 am - 11:15 am BREAK -------------------------------------------------- 11:15 am - 12:30 pm Session 2: SCALABILITY * Invited Talk: S=E1ndor Fekete (Braunschweig University of Technology, G= ermany) Algorithmic Aspects of Large Sensor Networks joint work with Alexander Kr=FCller (Braunschweig University of Technology, Germany), Dennis Pfisterer, Stefan Fischer (University of L=FCbeck, Germany) * Intelligent Hierarchical Cluster-Based Routing Abdul W. Matin, Sajid Hussain (Jodrey School of Computer Science, Wolfville, Canada) -------------------------------------------------- 12:30 pm - 2:00 pm LUNCH (on your own) -------------------------------------------------- 2:00 pm - 4:00 pm Session 3: LIFETIME * Invited Talk: Sotiris Nikoletseas (Research Academic Computer Technology Institute, Patras, Greece) "Adaptive Power Saving for Heterogeneous Sensor Networks with Incremental Deployment" * Invited Talk: Jun Luo (School of Computer and Communication Sciences, Lausanne, Switzerland) "Mobility to Improve the Lifetime of Wireless Sensor Networks: A Theoretical Framework" joint work with Jean-Pierre Hubaux (School of Computer and Communication Sciences, Lausanne, Switzerland) -------------------------------------------------- 4:00 pm - 4:15 pm BREAK -------------------------------------------------- 4:15 pm - 5:30 pm PANEL DISCUSSION =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 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067S-Dz; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fldhe-0004Pc-HY; Wed, 31 May 2006 23:18:30 -0400 Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fldha-0004lz-6c; Wed, 31 May 2006 23:18:30 -0400 Received: from hpn307pc2 (cpe-66-67-141-103.rochester.res.rr.com [66.67.141.103]) by ms-smtp-01.nyroc.rr.com (8.13.6/8.13.6) with SMTP id k513IO9a012516; Wed, 31 May 2006 23:18:25 -0400 (EDT) Message-ID: <011401c6852a$0b36f6f0$6701a8c0@hpn307pc2> From: "Wendi Heinzelman" To: , Date: Wed, 31 May 2006 23:18:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Subject: [Mip4] SECON 2006 Call for Posters and Demos X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive this call multiple times.) *********************************************************************** CALL FOR POSTERS and DEMOS *Deadline: June 30, 2006, 5 pm EDT* IEEE SECON 2006 The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/2006/ Sponsored by IEEE Communications Society (www.comsoc.org) Technically Co-Sponsored by AFCEA (www.afcea.org) September 25-28, 2006 Reston, Virginia, USA (Near Washington DC's Dulles airport) ************************************************************************ To provide a forum for discussion and personal interaction between presenter and participants, IEEE SECON 2006 will include poster and demonstration sessions: works in progress, industry demonstrations of new applications and techniques, practical implementations, military, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensreless Sensor Networks: A Theoretical Framework" joint work with Jean-Pierre Hubaux (School of Computer and Communication Sciences, Lausanne, Switzerland) -------------------------------------------------- 4:00 pm - 4:15 pm BREAK -------------------------------------------------- 4:15 pm - 5:30 pm PANEL DISCUSSION =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 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-00067S-Dz; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fldhe-0004Pc-HY; Wed, 31 May 2006 23:18:30 -0400 Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fldha-0004lz-6c; Wed, 31 May 2006 23:18:30 -0400 Received: from hpn307pc2 (cpe-66-67-141-103.rochester.res.rr.com [66.67.141.103]) by ms-smtp-01.nyroc.rr.com (8.13.6/8.13.6) with SMTP id k513IO9a012516; Wed, 31 May 2006 23:18:25 -0400 (EDT) Message-ID: <011401c6852a$0b36f6f0$6701a8c0@hpn307pc2> From: "Wendi Heinzelman" To: , Date: Wed, 31 May 2006 23:18:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: Subject: [Mip4] SECON 2006 Call for Posters and Demos X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive this call multiple times.) *********************************************************************** CALL FOR POSTERS and DEMOS *Deadline: June 30, 2006, 5 pm EDT* IEEE SECON 2006 The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/2006/ Sponsored by IEEE Communications Society (www.comsoc.org) Technically Co-Sponsored by AFCEA (www.afcea.org) September 25-28, 2006 Reston, Virginia, USA (Near Washington DC's Dulles airport) ************************************************************************ To provide a forum for discussion and personal interaction between presenter and participants, IEEE SECON 2006 will include poster and demonstration sessions: works in progress, industry demonstrations of new applications and techniques, practical implementations, military, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. One of the key goals of this conference is to foster collaboration between industry, government agencies and academia. Hence, participation of researchers/developers from industry or governement agencies and posters/demonstrations reporting joint work are especially encouraged. Topics considered for posters and demo are, but not limited to: * New architectures and protocols to support communication, localization, time synchronization, routing, data dissemination, and other distributed services in heterogeneous, large-scale distributed, mesh networks and sensor networks * Novel algorithms and theories for management, supervisory control, and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Modeling and performance evaluation of large-scale distributed ad hoc and sensor networks, practical implementations and deployments, and real-world experiences * Theories and models on fundamental information and communication aspects of wireless mesh and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and mesh networks * Algorithms and protocols to support quality of service in mesh and sensor networks, including admission control, resource allocation and fairness, and capacity planning * Integration of sensors into engineered systems, including novel techniques for on-sensor renewable power sources, mechanisms for on-sensor self-calibration and self-testing, and efficient schemes to maximize accuracy and minimize false alarms * Hardware platforms incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware, and tools for mesh and sensor network applications development, deployment, and management Submissions should be in the form of a proposal describing the main contributions of the poster/demo and the merits of the proposed ideas. If available, preliminary results can also be included. Proposals will be evaluated mainly based on their potential to stimulate interesting discussions, exchange of ideas and promote collaborations. A prize will be awarded to the best demo by a jury composed of academic and/or venture capital participants. Submissions should not be more than three pages (preferably IEEE conference format, 2-column) in length. Demonstration submissions should include the space requirements and/or any other equipment-specific requirements. The documents must contain the authors' names, affiliations, and contact information and the designated corresponding author. Accepted authors of posters/demos will have a space in the poster/demo session room to display their posters or exhibit their demos and describe their work in discussions with interested attendees. IEEE Communications Society policy states that all accepted SECON 2006 posters/demos must have at least one registration at the regular rate. For authors co-authoring multiple posters/demos, one regular registration is valid for up to three presentations. Submission will be accepted until Friday, June 30th, 5 pm EDT for demos and for posters. Please send the submission material to the poster/demo chairs in pdf format, and make sure to include the first author name and either POSTER or DEMO in the name of the pdf file: Stefano Basagni Cedric Westphal Northeastern University Nokia basagni@ece.neu.edu cedric.westphal@nokia.com Notification of Poster/Demo decisions: July 21, 2006. Accepted Poster/Demo Presenters MUST register by August 31, 2006. ************************************************************************ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4or, mesh and ad hoc communications and networks. One of the key goals of this conference is to foster collaboration between industry, government agencies and academia. Hence, participation of researchers/developers from industry or governement agencies and posters/demonstrations reporting joint work are especially encouraged. Topics considered for posters and demo are, but not limited to: * New architectures and protocols to support communication, localization, time synchronization, routing, data dissemination, and other distributed services in heterogeneous, large-scale distributed, mesh networks and sensor networks * Novel algorithms and theories for management, supervisory control, and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Modeling and performance evaluation of large-scale distributed ad hoc and sensor networks, practical implementations and deployments, and real-world experiences * Theories and models on fundamental information and communication aspects of wireless mesh and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and mesh networks * Algorithms and protocols to support quality of service in mesh and sensor networks, including admission control, resource allocation and fairness, and capacity planning * Integration of sensors into engineered systems, including novel techniques for on-sensor renewable power sources, mechanisms for on-sensor self-calibration and self-testing, and efficient schemes to maximize accuracy and minimize false alarms * Hardware platforms incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware, and tools for mesh and sensor network applications development, deployment, and management Submissions should be in the form of a proposal describing the main contributions of the poster/demo and the merits of the proposed ideas. If available, preliminary results can also be included. Proposals will be evaluated mainly based on their potential to stimulate interesting discussions, exchange of ideas and promote collaborations. A prize will be awarded to the best demo by a jury composed of academic and/or venture capital participants. Submissions should not be more than three pages (preferably IEEE conference format, 2-column) in length. Demonstration submissions should include the space requirements and/or any other equipment-specific requirements. The documents must contain the authors' names, affiliations, and contact information and the designated corresponding author. Accepted authors of posters/demos will have a space in the poster/demo session room to display their posters or exhibit their demos and describe their work in discussions with interested attendees. IEEE Communications Society policy states that all accepted SECON 2006 posters/demos must have at least one registration at the regular rate. For authors co-authoring multiple posters/demos, one regular registration is valid for up to three presentations. Submission will be accepted until Friday, June 30th, 5 pm EDT for demos and for posters. Please send the submission material to the poster/demo chairs in pdf format, and make sure to include the first author name and either POSTER or DEMO in the name of the pdf file: Stefano Basagni Cedric Westphal Northeastern University Nokia basagni@ece.neu.edu cedric.westphal@nokia.com Notification of Poster/Demo decisions: July 21, 2006. Accepted Poster/Demo Presenters MUST register by August 31, 2006. ************************************************************************ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOY-00069I-4w; Fri, 02 Jun 2006 14:29:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm5AW-0005gW-Az for mip4@ietf.org; Fri, 02 Jun 2006 04:38:08 -0400 Received: from smtp.irisa.fr ([131.254.254.26]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm5AU-0001uz-Ch for mip4@ietf.org; Fri, 02 Jun 2006 04:38:08 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by localhost.irisa.fr (Postfix) with ESMTP id B327EFAC9 for ; Fri, 2 Jun 2006 10:38:05 +0200 (CEST) Received: from smtp.irisa.fr ([131.254.254.26]) by localhost (meli.irisa.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24097-01 for ; Fri, 2 Jun 2006 10:37:58 +0200 (CEST) Received: from CENTOCELLE (centocelle.irisa.fr [131.254.10.213]) by smtp.irisa.fr (Postfix) with SMTP id 1C841FAE1 for ; Fri, 2 Jun 2006 10:37:45 +0200 (CEST) Message-ID: <001801c6861f$d1ece7f0$d50afe83@irisa.fr> From: "Maria Gradinariu" To: Date: Thu, 1 Jun 2006 19:19:24 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: by amavisd-new at irisa.fr X-Spam-Score: 0.5 (/) X-Scan-Signature: ff67cea9f7df2d77f61a364cea0926e8 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Subject: [Mip4] [CFP] Symposium on Stabilization, Safety, and Security of, Distributed Systems (SSS 2006) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1812505169==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1812505169== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0101_01C685B0.4B4047C0" This is a multi-part message in MIME format. ------=_NextPart_000_0101_01C685B0.4B4047C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Please accept our apologies if you receive multiple copies of this = message.]=20 Eighth International Symposium on Stabilization, Safety, and Security of = Distributed Systems=20 (formerly Symposium on Self-stabilizing Systems) (SSS 2006)=20 November 17th-19th, 2006=20 Dallas, Texas, USA=20 http://www.irisa.fr/sss/2006/=20 =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=20 Selected papers will be published in a special issue of the ACM = Transactions=20 on Autonomous and Adaptive Systems (TAAS).=20 =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=20 =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=20 Important Dates=20 Paper Submission: July 7th, 2006=20 Notification to Authors: August 21st, 2006=20 Camera-ready: August 31st, 2006=20 Symposium: November 17th-19th, 2006=20 =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=20 The Symposium is a prestigious international forum for researchers and=20 practitioners in the design and development of fault-tolerant = distributed=20 systems with self-* properties, such as self-stabilizing, = self-configuring,=20 self-organizing, self-managing, self-repairing, self-healing, = self-optimizing,=20 self-adaptive, and self-protecting.=20 The theory of self-stabilization has been enriched in the last 25 years = by=20 high quality research contributions in the areas of algorithmic = techniques,=20 formal methodologies, model theoretic issues, and composition = techniques.=20 All these areas are essential to the understanding and maintenance of = self-*=20 properties in fault-tolerant distributed systems.=20 Research in distributed systems is now at a crucial point in its = evolution,=20 marked by the importance of dynamic systems such as peer-to-peer = networks,=20 large-scale wireless sensor networks, mobile ad hoc networks, robotic = networks,=20 etc. Moreover, new applications such as grid and web services, banking = and=20 e-commerce, e-health and robotics, aerospace and avionics, automotive,=20 industrial process control, etc. have joined the traditional = applications of=20 distributed systems.=20 Now, more than ever, the theory of self-stabilization has tremendous=20 impact in these areas. Therefore, this year, we are extending the scope = of=20 the symposium to cover all safety and security related aspects of self-* = systems. The title of the conference has been changed to reflect this=20 expansion. There will be three tracks: networking, safety and security, = and=20 self-* properties in static and dynamic systems.=20 The symposium solicits contributions on all aspects of = self-stabilization,=20 safety and security, recovery oriented systems and programing, from = theoretical=20 contributions, to reports of the actual experience of applying the = principles=20 of self-stabilization to static and dynamic systems.=20 Topics of interest include, but are not limited to:=20 Stabilization:=20 - self-stabilizing systems=20 - self-managed, self-assembling, autonomic and adaptive systems=20 - self-optimizing and self-protecting systems=20 - self-* abstractions for implementing fundamental services in static = and=20 dynamic distributed systems=20 - impossibility results and lower bounds for self-* systems=20 - application of stabilizing algorithms and techniques in dynamic = distributed=20 systems=20 - data and code stabilization=20 - algorithms for self-* error detection/correction=20 Safety:=20 - safety critical systems=20 - trust models and specifications=20 - semantics of trust, distrust, mistrust, over-trust, cheat, risk and=20 reputation=20 - trust-related security and privacy=20 - reliable and dependable systems=20 - fault-tolerant systems, hardware redundancy, robustness, survivable = systems,=20 failure recovery=20 Security:=20 - security of network protocols=20 - security of sensor and mobile networks protocols=20 - secure architectures, frameworks, policy, intrusion = detection/awareness=20 - proactive security=20 - self-* properties and their relation with classical fault-tolerance = and=20 security=20 - security protocols for self-* systems=20 Networks and Applications:=20 - models of fault-tolerant communication=20 - stochastic, physical, and biological models to analyze self-* = properties=20 - communication complexity=20 - data structures for efficient communication=20 - self-stabilizing hardware, software, and middleware=20 - algorithms for high-speed networks, sensors, wireless and robots = networks=20 - mobile agents=20 - peer-to-peer networks, sensor networks, MANETs, and wireless mesh = networks=20 - network topologies, overlays, and protocols=20 - protocols for secure and reliable data transport and search in = wireless mesh=20 networks=20 - information storage and sharing in wireless mesh networks=20 Contributors are invited to submit a PDF file of their paper. = Submissions=20 should be no longer than 4800 words and should not exceed 12 pages on=20 letter-size paper using at least 11 point font and reasonable margins = (the=20 page limit includes all figures, tables, and graphs). Submissions = should=20 include a cover page (that does not count towards the 12 page limit) = that=20 includes paper title, authors and affiliations, contact author's e-mail=20 address, an abstract of the work in a few lines, and a few keywords. = Submitted=20 papers may have appendices beyond the 12 page limit, but reviewers are = free to=20 disregard any material beyond the 12 page limit. A paper submitted to = SSS 2006=20 is expected to be original research not previously published; a = submission may=20 not be concurrently submitted or to any other conference, workshop, or = journal.=20 The proceedings of the conference will be published in the Springer = Verlag=20 Lecture Notes in Computer Science (LNCS) series. Selected papers will = be=20 published in a special issue of the ACM Transactions on Autonomous and = Adaptive=20 Systems (TAAS).=20 General Chair:=20 Mohamed Gouda, University of Texas at Austin, USA, gouda@cs.utexas.edu=20 Program Co-chairs:=20 Ajoy K Datta University of Nevada Las Vegas, USA, datta@cs.unlv.edu=20 Maria Gradinariu, IRISA, France, mgradina@irisa.fr=20 Local Arrangements Chair:=20 Jorge Cobb, University of Texas at Dallas, USA, cobb@utdallas.edu=20 Ravi Prakash, University of Texas at Dallas, USA, ravip@utdallas.edu=20 Publicity and Web Chair:=20 Florent Claerhout, IRISA, France, fclaerho@irisa.fr=20 Steering Committee:=20 Anish Arora, Ohio State University, USA, anish@cse.ohio-state.edu=20 Ajoy K. Datta, University of Nevada Las Vegas, USA, datta@cs.unlv.edu=20 Shlomi Dolev, Ben-Gurion University of the Negev, Israel, = dolev@cs.bgu.ac.il=20 Sukumar Ghosh, Chair, University of Iowa, USA, ghosh@cs.uiowa.edu=20 Mohamed G. Gouda, University of Texas at Austin, USA, = gouda@cs.utexas.edu=20 Ted Herman, University of Iowa, USA, ted-herman@uiowa.edu=20 Shing-Tsaan Huang, National Central University, Taiwan, = sthuang@csie.ncu.edu.tw=20 Toshimitsu Masuzawa, Osaka University, Japan, masuzawa@ist.osaka-u.ac.jp = Vincent Villain, Universie de Picardie, France, = villain@laria.u-picardie.fr ------=_NextPart_000_0101_01C685B0.4B4047C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
  [Please accept our apologies if = you=20 receive multiple copies of this message.]

Eighth = International=20 Symposium on Stabilization, Safety, and Security of
Distributed = Systems=20
(formerly Symposium on Self-stabilizing Systems) (SSS 2006)=20
November 17th-19th, 2006
Dallas, Texas, USA
http://www.irisa.fr/sss/2006/ =


=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=20
Selected papers will be published in a special issue of the = ACM=20 Transactions
on Autonomous and Adaptive Systems (TAAS).=20
=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=20

=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=20
Important Dates

Paper=20 Submission:        July 7th, 2006=20
Notification to Authors: August 21st, 2006=20
Camera-ready:         &n= bsp; =20 August 31st, 2006=20
Symposium:          = ;    =20 November 17th-19th, 2006=20
=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=20


The Symposium is a prestigious international forum for = researchers=20 and
practitioners in the design and development of fault-tolerant=20 distributed
systems with self-* properties, such as = self-stabilizing,=20 self-configuring,
self-organizing, self-managing, self-repairing,=20 self-healing, self-optimizing,
self-adaptive, and self-protecting.=20

The theory of self-stabilization has been enriched in the last = 25 years=20 by
high quality research contributions in the areas of algorithmic=20 techniques,
formal methodologies, model theoretic issues, and = composition=20 techniques.
All these areas are essential to the understanding and=20 maintenance of self-*
properties in fault-tolerant distributed = systems.=20

Research in distributed systems is now at a crucial point in its = evolution,
marked by the importance of dynamic systems such as = peer-to-peer=20 networks,
large-scale wireless sensor networks, mobile ad hoc = networks,=20 robotic networks,
etc.  Moreover, new applications such as grid = and web=20 services, banking and
e-commerce, e-health and robotics, aerospace = and=20 avionics, automotive,
industrial process control, etc. have joined = the=20 traditional applications of
distributed systems.

Now, more = than=20 ever, the theory of self-stabilization has tremendous
impact in = these=20 areas.  Therefore, this year, we are extending the scope of
the = symposium to cover all safety and security related aspects of self-*=20
systems.  The title of the conference has been changed to = reflect this=20
expansion.  There will be three tracks: networking, safety and=20 security, and
self-* properties in static and dynamic systems. =

The=20 symposium solicits contributions on all aspects of self-stabilization,=20
safety and security, recovery oriented systems and programing, from=20 theoretical
contributions, to reports of the actual experience of = applying=20 the principles
of self-stabilization to static and dynamic systems.=20

Topics of interest include, but are not limited to:=20

Stabilization:
- self-stabilizing systems
- = self-managed,=20 self-assembling, autonomic and adaptive systems
- self-optimizing = and=20 self-protecting systems
- self-* abstractions for implementing = fundamental=20 services in static and
dynamic distributed systems
- = impossibility=20 results and lower bounds for self-* systems
- application of = stabilizing=20 algorithms and techniques in dynamic distributed
systems
- data = and code=20 stabilization
- algorithms for self-* error detection/correction=20

Safety:
- safety critical systems
- trust models and=20 specifications
- semantics of trust, distrust, mistrust, over-trust, = cheat,=20 risk and
reputation
- trust-related security and privacy
- = reliable=20 and dependable systems
- fault-tolerant systems, hardware = redundancy,=20 robustness, survivable systems,
failure recovery

Security: =
-=20 security of network protocols
- security of sensor and mobile = networks=20 protocols
- secure architectures, frameworks, policy, intrusion=20 detection/awareness
- proactive security
- self-* properties and = their=20 relation with classical fault-tolerance and
security
- security=20 protocols for self-* systems

Networks and Applications:
- = models of=20 fault-tolerant communication
- stochastic, physical, and biological = models=20 to analyze self-* properties
- communication complexity
- data=20 structures for efficient communication
- self-stabilizing hardware,=20 software, and middleware
- algorithms for high-speed networks, = sensors,=20 wireless and robots networks
- mobile agents
- peer-to-peer = networks,=20 sensor networks, MANETs, and wireless mesh networks
- network = topologies,=20 overlays, and protocols
- protocols for secure and reliable data = transport=20 and search in wireless mesh
networks
- information storage and = sharing=20 in wireless mesh networks


Contributors are invited to submit = a PDF=20 file of their paper.  Submissions
should be no longer than 4800 = words=20 and should not exceed 12 pages on
letter-size paper using at least = 11 point=20 font and reasonable margins (the
page limit includes all figures, = tables,=20 and graphs).  Submissions should
include a cover page (that = does not=20 count towards the 12 page limit) that
includes paper title, authors = and=20 affiliations, contact author's e-mail
address, an abstract of the = work in a=20 few lines, and a few keywords.  Submitted
papers may have = appendices=20 beyond the 12 page limit, but reviewers are free to
disregard any = material=20 beyond the 12 page limit.  A paper submitted to SSS 2006
is = expected to=20 be original research not previously published; a submission may
not = be=20 concurrently submitted or to any other conference, workshop, or journal. =

The proceedings of the conference will be published in the = Springer=20 Verlag
Lecture Notes in Computer Science (LNCS) series.  = Selected=20 papers will be
published in a special issue of the ACM Transactions = on=20 Autonomous and Adaptive
Systems (TAAS).

General Chair: =
Mohamed=20 Gouda, University of Texas at Austin, USA, gouda@cs.utexas.edu =


Program=20 Co-chairs:
Ajoy K Datta University of Nevada Las Vegas, USA, datta@cs.unlv.edu
Maria = Gradinariu,=20 IRISA, France, mgradina@irisa.fr =


Local=20 Arrangements Chair:
Jorge Cobb, University of Texas at Dallas, USA, = cobb@utdallas.edu
Ravi = Prakash,=20 University of Texas at Dallas, USA, ravip@utdallas.edu =


Publicity=20 and Web Chair:
Florent Claerhout, IRISA, France, fclaerho@irisa.fr =


Steering=20 Committee:
Anish Arora, Ohio State University, USA, anish@cse.ohio-state.edu =
Ajoy K.=20 Datta, University of Nevada Las Vegas, USA, datta@cs.unlv.edu
Shlomi = Dolev,=20 Ben-Gurion University of the Negev, Israel, dolev@cs.bgu.ac.il
Sukumar = Ghosh,=20 Chair, University of Iowa, USA, ghosh@cs.uiowa.edu
Mohamed G. = Gouda,=20 University of Texas at Austin, USA, gouda@cs.utexas.edu
Ted = Herman,=20 University of Iowa, USA, ted-herman@uiowa.edu =
Shing-Tsaan=20 Huang, National Central University, Taiwan, sthuang@csie.ncu.edu.tw =
Toshimitsu=20 Masuzawa, Osaka University, Japan, masuzawa@ist.osaka-u.ac.jp= =20
Vincent Villain, Universie de Picardie, France, villain@laria.u-picardie.fr=20
------=_NextPart_000_0101_01C685B0.4B4047C0-- --===============1812505169== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1812505169==-- From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOW-00066X-Ov; Fri, 02 Jun 2006 14:29:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlJWP-0004if-GB for mip4@ietf.org; Wed, 31 May 2006 01:45:33 -0400 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 1FlJIQ-0002Hx-PC for mip4@ietf.org; Wed, 31 May 2006 01:31:06 -0400 Received: from wx-out-0102.google.com ([66.249.82.204]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FlJHD-0001Qg-W1 for mip4@ietf.org; Wed, 31 May 2006 01:29:59 -0400 Received: by wx-out-0102.google.com with SMTP id h28so388319wxd for ; Tue, 30 May 2006 22:29:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=V6yuNUqYI2poHGK1iA7aJSWccCeEsEE1uBQ2fdJQoWbLfsi/iTX4oPT/AyxC629jwTOLWtMsbiXy9cah4T2Tmc1y0X48cu5nIE249gIlaJkeQUqThSVu/t+FeN4Pb7e0yufUDNVDX6vs8NRBWlt/+GGO+JE5dk8T63/ya895zXU= Received: by 10.70.44.13 with SMTP id r13mr4502229wxr; Tue, 30 May 2006 22:29:48 -0700 (PDT) Received: by 10.70.105.1 with HTTP; Tue, 30 May 2006 22:29:48 -0700 (PDT) Message-ID: Date: Wed, 31 May 2006 13:29:48 +0800 From: "LAI OWEN" To: kleung@cisco.com MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: -2.5 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Cc: mip4@ietf.org Subject: [Mip4] Comments for your draft "draft-leung-mip4-proxy-mode-00.txt" X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Dear Kent, I read your draft "draft-leung-mip4-proxy-mode-00.txt", and have some comments for it. 1. How does MS get HoA? From local AAA in access network? or From AAA in the home network? 2. How can MS maintain its HoA after moving from one MPA to another MPA? There is no mechanism for IP address continuity. If the IP address of MS changes everytime after handover, then there should no IP session continuity betwwen MS and CN. Regards, Lai -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:29:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEOX-000682-Ry; Fri, 02 Jun 2006 14:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flz7J-0000e8-6K for mip4@ietf.org; Thu, 01 Jun 2006 22:10:25 -0400 Received: from nucleon.liquidweb.com ([64.91.224.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Flz7H-0002au-UI for mip4@ietf.org; Thu, 01 Jun 2006 22:10:25 -0400 Received: from c-69-181-8-85.hsd1.ca.comcast.net ([69.181.8.85]:3116 helo=Oana2) by nucleon.liquidweb.com with esmtpa (Exim 4.52) id 1Flz7F-0004l9-Kd for mip4@ietf.org; Thu, 01 Jun 2006 22:10:21 -0400 Message-ID: <10423792.1149214222031.JavaMail.Onitza@Oana2> Date: Thu, 1 Jun 2006 19:10:22 -0700 (PDT) From: invitation@iaria.org To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ClamAntiVirus-Scanner: This mail is clean X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - nucleon.liquidweb.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - iaria.org X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Fri, 02 Jun 2006 14:29:11 -0400 Subject: [Mip4] Deadline Extension: ICSNC 2006, ICSEA 2006 - Tahiti X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org By popular demand, we extended the submission deadline for ICSNC 2006 and ICSEA 2006. Please distribute the following calls to the groups you consider apropriate. Please also consider that your teams contribute to the conferences. Thanks for your cooperation, Petre =================================================== CALL FOR PAPERS International Conference on Software Engineering Advances, ICSEA 2006 October 29 -November 1, 2006, Tahiti. Call for Papers: http://www.iaria.org/conferences/CfPICSEA06.html Submission: Go to http://www.iaria.org/conferences/ICSEA06.html and click "Submit a paper" Deadlines: Submission deadline: June 11, 2006 Notification: July 1, 2006 Camera ready: July 15, 2006 The conference has the following tracks: Track 1 Advances in fundamentals for software development Track 2 Advanced mechanisms for software development Track 3 Advanced design tools for developing software Track 4 Advanced facilities for accessing software Track 5 Software performance Track 6 Software security, privacy, safeness Track 7 Advances in software testing Track 8 Specialized software advanced applications Track 9 Open source software Track 10 Agile software techniques Track 11 Software deployment and maintenance Track 12 Software economics, adoption, and education =================================================== =================================================== CALL FOR PAPERS International Conference on Systems and Networks Communications, ICSNC 2006 November 2 - November 4, 2006, Tahiti. Call for Papers: http://www.iaria.org/conferences/CfPICSNC06.html Submission: Go to http://www.iaria.org/conferences/ICSNC06.html and click "Submit a paper" Deadlines: Submission deadline: June 11, 2006 Notification: July 1, 2006 Camera ready: July 15, 2006 The conference has the following specialized topics (mini-conferences): WINET 2006 Wireless networks HSNET 2006 High speed networks SENET 2006 Sensor networks MHNET 2006 Mobile and Ad hoc networks SESYS 2006 Security systems MCSYS 2006 Multimedia communications systems POSYS 2006 Policy-based systems PESYS 2006 Pervasive education systems ================================================== Looking for your submissions. For more information: pdini@cisco.com --------------------------------------------------------------------------------------- To be removed from this announcement list, please reply to this email with UNSUBSCRIBE in the subject line. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 02 14:35:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEUx-0000g8-9n; Fri, 02 Jun 2006 14:35:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmEUw-0000g3-7Y for mip4@ietf.org; Fri, 02 Jun 2006 14:35:50 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmEUv-00053I-Jp for mip4@ietf.org; Fri, 02 Jun 2006 14:35:50 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 02 Jun 2006 11:35:50 -0700 X-IronPort-AV: i="4.05,204,1146466800"; d="scan'208"; a="324121085:sNHT36677172" 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 k52IZmCi027451; Fri, 2 Jun 2006 11:35:48 -0700 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 k52IZj9u008534; Fri, 2 Jun 2006 11:35:48 -0700 (PDT) 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.211); Fri, 2 Jun 2006 11:35:47 -0700 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: [Mip4] Issue with 3344bis Date: Fri, 2 Jun 2006 11:35:46 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201E95F11@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Issue with 3344bis Thread-Index: AcaGb9AbBBpgpAqdR5uguZaUoLcweAAArWSQ From: "Kent Leung \(kleung\)" To: "Henrik Levkowetz" , "Avi Lior" X-OriginalArrivalTime: 02 Jun 2006 18:35:47.0251 (UTC) FILETIME=[5D5F1030:01C68673] DKIM-Signature: a=rsa-sha1; q=dns; l=8708; t=1149273348; x=1150137348; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Issue=20with=203344bis; X=v=3Dcisco.com=3B=20h=3DXwu4CP4upbnzGBQE6E9QRVYsKXA=3D; b=KWQBcplb8CCnkFw/+0k3Ig9Syn+MLRh3QwmWsrZUThUvo4e91Rh8uVBdS2hpUBb6fn0Lz9HK vQzKm05jYy26msfgVm+jA1V1w7DiA+3rswHpiktU5BHQ8phSYNVfCAXT; Authentication-Results: sj-dkim-3.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Cc: "Narayanan, Vidya" , Mobile IPv4 Mailing List , Vijay Devarapalli X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Henrik. I've probably read that text a hundred times over the years. And probably have discussed it with other folks in the hallway. If I recall correctly, my very initial interpretation was similar to Avi's. Then after spending some more time digesting the text, I had concluded with Kuntal's observation. That's why adding a few more words for clarification won't hurt and likely helpful to get the right understanding for folks reading the specification their first time. Kent=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Friday, June 02, 2006 11:10 AM > To: Avi Lior > Cc: Kent Leung (kleung); Narayanan, Vidya; Vijay Devarapalli;=20 > Mobile IPv4 Mailing List > Subject: Re: [Mip4] Issue with 3344bis >=20 > Hi Avi, >=20 > on 2006-06-02 15:33 Avi Lior said the following: > > Hi Henrik, > >=20 > > I am not disputing what you are saying at all. >=20 > Ok. >=20 > > It is just that when we read that sentence it gives the impression=20 > > that the HA must be statically provisioned with a netmask and an SA. >=20 > Ok. I accept that you read it that way, but disagree that it=20 > actually gives that impression, as a general statement ;-) >=20 > > Rewording would help....I like Kent's verbage. >=20 > Ok. >=20 > > And I am not the only one mis-reading this. =20 >=20 > I'd like to hear from others, then... >=20 > Regards, >=20 > Henrik >=20 > >> -----Original Message----- > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > >> Sent: Friday, June 02, 2006 3:24 AM > >> To: Kent Leung (kleung) > >> Cc: Narayanan, Vidya; Vijay Devarapalli; Mobile IPv4 Mailing List;=20 > >> Avi Lior > >> Subject: Re: [Mip4] Issue with 3344bis > >>=20 > >> Hi Kent, > >>=20 > >> The proposed text is ok, but the change is unnecessary. =20 > The current=20 > >> text doesn't say that you have to have MSA and netmask before you=20 > >> have an assigned HA, even if Avi happened to mis-read it that way. > >>=20 > >>=20 > >> Henrik > >>=20 > >>=20 > >> on 2006-06-02 08:13 Kent Leung (kleung) said the following: > >> > Here's a proposal: > >> >=20 > >> > Change: > >> >=20 > >> > "A mobile node MUST be configured with a netmask and a mobility > >> > security association for each of its home agents." > >> >=20 > >> > To: > >> >=20 > >> > "A mobile node MUST have a netmask and a mobility > >> > security association for each of its home agents. The=20 > >> information > >> > can be obtained dynamically by or configured on the=20 > >> mobile node." > >> >=20 > >> > Kent > >> >=20 > >> >> -----Original Message----- > >> >> From: Avi Lior [mailto:avi@bridgewatersystems.com] > >> >> Sent: Thursday, June 01, 2006 10:18 PM > >> >> To: Narayanan, Vidya; Vijay Devarapalli > >> >> Cc: Mobile IPv4 Mailing List > >> >> Subject: RE: [Mip4] Issue with 3344bis > >> >>=20 > >> >> ViJay, > >> >>=20 > >> >> My original emails suggested that perhaps we say: > >> >>=20 > >> >> Instead it should say that it MAY be configured with ..... > >> >> =20 > >> >> or MUST be configurable with.... > >> >>=20 > >> >> Either of those cases support the manual or static=20 > >> configuration and=20 > >> >> also the Dynamic configuration. > >> >>=20 > >> >> The current wording only allows for static configuration=20 > >> of the MN-HA. > >> >>=20 > >> >> I agree with Vidya about the comments regarding your=20 > >> additional text. > >> >> It is not necessary.=20 > >> >>=20 > >> >> > -----Original Message----- > >> >> > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > >> >> > Sent: Friday, June 02, 2006 12:15 AM > >> >> > To: Vijay Devarapalli; Avi Lior > >> >> > Cc: Mobile IPv4 Mailing List > >> >> > Subject: RE: [Mip4] Issue with 3344bis > >> >> >=20 > >> >> >=20 > >> >> > >=20 > >> >> > > Avi Lior wrote: > >> >> > > > Hi ViJay, > >> >> > > >=20 > >> >> > > > Sorry but I don't think I agree with the MUST. =20 > If I have a=20 > >> >> > > > method for bootstrapping MN-HA why MUST the MN be=20 > >> configured with an MN-HA? > >> >> > > >=20 > >> >> > > > I think we can come up with some text without=20 > specifically=20 > >> >> > > > making a reference to 4433 and 3957. > >> >> > > >=20 > >> >> > > > The problem is that the "MUST" requires that I=20 > configure at=20 > >> >> > > > least one MN-HA to be compliant with 3344. > >> >> > >=20 > >> >> > > I don't see it that way. 3344bis says there MUST be=20 > a security=20 > >> >> > > association between the MN and the HA for the=20 > protocol to work. > >> >> > > Since it does not specify a way to dynamically configure a=20 > >> >> > > security association it *has* to say that a security=20 > >> association=20 > >> >> > > MUST be configured on the MN. otherwise it cannot be=20 > >> standardized. > >> >> > >=20 > >> >> >=20 > >> >> > I agree with Avi on this. I don't see why there needs to=20 > >> be a MUST=20 > >> >> > on this one. If you say that an MN-HA SA MUST be=20 > available to =20 > >> >> > secure the RRQ/RRP, that makes sense - it does not=20 > make sense to=20 > >> >> > say that this MUST be "configured" per say. > >> >> >=20 > >> >> > > I think the MUST is needed in the spec. > >> >> > >=20 > >> >> > > perhaps we could add the following at the end of=20 > the paragraph. > >> >> > >=20 > >> >> > > Future specifications may define mechanisms to=20 > dynamically > >> >> > > assign a home agent to a mobile node and setup a mobility > >> >> > > security association between them. In this case,=20 > the mobile > >> >> > > node need not be manually configured with a netmask or a > >> >> > > mobility security association with its home agent. > >> >> > >=20 > >> >> >=20 > >> >> > But, we already have specifications that define this :)=20 > >> So, to keep=20 > >> >> > our eyes closed to the fact that we already have ways of=20 > >> getting=20 > >> >> > away from manual configuration does not seem to make=20 > sense to me. > >> >> >=20 > >> >> > If you want to say that in the absence of a dynamic=20 > mechanism to=20 > >> >> > acquire an MN-HA SA, it MUST be configured on the MN,=20 > >> that would be=20 > >> >> > fine. > >> >> >=20 > >> >> > Vidya > >> >> >=20 > >> >> > > Vijay > >> >> > >=20 > >> >> > > >=20 > >> >> > > >> -----Original Message----- > >> >> > > >> From: Vijay Devarapalli =20 > >> >> > > >> [mailto:vijay.devarapalli@AzaireNet.com] > >> >> > > >> Sent: Thursday, June 01, 2006 6:06 PM > >> >> > > >> To: Avi Lior > >> >> > > >> Cc: Mobile IPv4 Mailing List > >> >> > > >> Subject: Re: [Mip4] Issue with 3344bis > >> >> > > >> > >> >> > > >> Avi Lior wrote: > >> >> > > >>> =20 > >> >> > > >>> Sorry for the lateness of this comment... > >> >> > > >>> > >> >> > > >>> Section 3.6 > >> >> > > >>> =20 > >> >> > > >>> "A mobile node MUST be configured with a netmask=20 > >> and a mobility > >> >> > > >>> security association for each of its home agents." > >> >> > > >>> =20 > >> >> > > >>> This seems to be a bad thing if we are talking=20 > >> about roaming=20 > >> >> > > >>> and dynamic HA assignement. > >> >> > > >>> =20 > >> >> > > >> I think this is ok. as far as 3344bis is concerned,=20 > >> at least=20 > >> >> > > >> the netmask for the home link and a mobility security =20 > >> >> > > >> association is required for the protocol to work. later=20 > >> >> > > >> specifications talk about how the protocol in=20 > 3344bis would=20 > >> >> > > >> work without having to pre-configere a netmask=20 > >> (RFC4433), or=20 > >> >> > > >> without having to pre-configure a mobility security=20 > >> association (for e.g. RFC 3957). > >> >> > > >> > >> >> > > >> since there is a plan to advance 3344bis to draft=20 > >> standard we=20 > >> >> > > >> don't want normative references to RFC 4433 or RFC 3957. > >> >> > > >> > >> >> > > >> Vijay > >> >> > > >> > >> >> > >=20 > >> >> > >=20 > >> >> > > -- > >> >> > > Mip4 mailing list: Mip4@ietf.org > >> >> > > Web interface:=20 > https://www1.ietf.org/mailman/listinfo/mip4 > >> >> > > Charter page: =20 > >> >> > > http://www.ietf.org/html.charters/mip4-charter.html > >> >> > > Supplemental site: http://www.mip4.org/ > >> >> > >=20 > >> >> >=20 > >> >>=20 > >> >> -- > >> >> Mip4 mailing list: Mip4@ietf.org > >> >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> >> Charter page:=20 > >> >> http://www.ietf.org/html.charters/mip4-charter.html > >> >> Supplemental site: http://www.mip4.org/ > >> >>=20 > >> >=20 > >>=20 > >>=20 > >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 05 09:38:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnFHT-0005Zn-Nz; Mon, 05 Jun 2006 09:38:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fn1P3-0003wR-Mh for mip4@ietf.org; Sun, 04 Jun 2006 18:49:01 -0400 Received: from mail.dc.ufscar.br ([200.18.99.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fn1P2-0002N0-SA for mip4@ietf.org; Sun, 04 Jun 2006 18:49:01 -0400 Received: from dc.ufscar.br (www.dc.ufscar.br [200.18.99.99]) by mail.dc.ufscar.br (Postfix) with ESMTP id 5C4C72F9A0 for ; Sun, 4 Jun 2006 19:49:02 -0300 (BRT) Received: from 201-0-100-175.dsl.telesp.net.br (201-0-100-175.dsl.telesp.net.br [201.0.100.175]) by webmail.dc.ufscar.br (Horde MIME library) with HTTP; Sun, 04 Jun 2006 19:54:14 -0300 Message-ID: <20060604195414.xcxd8zgzrk8484w4@webmail.dc.ufscar.br> Date: Sun, 04 Jun 2006 19:54:14 -0300 From: regina@dc.ufscar.br To: mip4@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.1) X-Spam-Score: 0.2 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 X-Mailman-Approved-At: Mon, 05 Jun 2006 09:38:06 -0400 Subject: [Mip4] CFP: 2nd ACM WMuNep, Spain 2006 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org =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 ACM WMuNeP 2006 Second ACM International Workhop on Wireless Multimedia Networking and Performance Modeling (WMuNeP '06) =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 To be held jointly with the 9th ACM MSWiM 2006 October 2-6th, 2006 Torremolinos, M=E1laga, Spain Submission Deadline: June 10th, 2006 =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 Selected papers will be published on a special issue of of ACM/Springer Multimedia Systems' Journal =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 The Second ACM International Workhop on Wireless Multimedia Networking and Performance Modeling (WMuNeP '06) will be a one-day workshop, held in conjunction with the 9th Annual ACM Symposium on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWiM=B406). The demand for wireless multimedia communications thrives in today's consumer and corporate market. The need to evolve multimedia applications and services, and their associated protocols for emerging networks is at a critical point given the proliferation and integration of wireless systems to intelligent and broadband networks, mobility of people, data/voice convergence and the integration of computing and communication in mobile devices. This workshop is devoted to cover different aspects of wireless multimedia networking and performance modeling for WLANs, WPANs, WMANs, WWANs, MANETs and sensor networks such as wireless video and wireless streaming, systematic design methodologies, algorithms, synchronization, analysis and performance modeling. The workshop will provide a forum for researchers and practitioners to present their contributions related to the above high-level aspects. Topics of interest include (but are not limited to): Wireless multimedia network management Wireless multimedia traffic modeling Middleware and reflective systems support for wireless multimedia Proxy-based systems for video transcoding and content distribution Performance modeling, monitoring and evaluation of wireless multimedia networks and systems Multipoint, multicast wireless multimedia services Deployment of wireless multimedia applications, services and networks Protocols for wireless multimedia networks QoS in wireless multimedia networks Integration of wireless multimedia networks to broadband networks End-to-end IP multimedia wireless communications Coding and transmission for wireless multimedia networks Distributed wireless multimedia services Content-based wireless multimedia information retrieval tools Video, streaming, real-time wireless multimedia communications and applications Security in wireless multimedia networks Wireless multimedia right protection and watermarking Pricing mechanisms for wireless multimedia networks E-Commerce and related applications for wireless multimedia networks Multimedia evaluation and processing for wireless networks Cross layer design for wireless multimedia networks Analytical modeling of wireless multimedia networks Software tools for system performance and evaluation of wireless multimedia networks Performance comparison of wireless multimedia networks Case studies showing the role of evaluation in the design of systems ----------------------------------------------------------------------------= ---- Important Dates: Submission deadline: June 10th, 2006 Notification of acceptance: July 10th, 2006 Camera ready papers: TBA ----------------------------------------------------------------------------= ---- Paper Submission Guidelines: Authors are invited to submit research contributions representing original, previously unpublished work. Submitted papers will be carefully evaluated based on originality, significance, technical soundness, and clarity of exposition. Accepted papers will appear on the workshop proceedings that will be published by ACM press. At least one of the authors of accepted papers must attend the conference to present his/her paper. Paper length should be no more than 10 pages, double column, ACM style including tables and figures. A template for ACM SIG Proceedings style (LaTeX2e and MS Word) can be found here. Only Postscript and PDF formats are accepted. Papers must be submitted electronically via the JEMS system (Brazilian EDAS). Each submission must be accompanied by the following information: a paper title a short abstract a complete list of authors and their affiliations a contact person for correspondence (please check the correct e-mail is configured on JEMS system) WMuNeP 2006 electronic submission is now active on the JEMS system (Brazilian EDAS) at https://submissoes.sbc.org.br/wmunep2006. Once you are a registered JEMS user, this link will address you directly to the WMuNeP 2006 Paper Submission page. Important - For any question or problem related to WMuNeP 2006, please contact wmunep2006@dc.ufscar.br ----------------------------------------------------------------------------= ---- Venue: The 2006 ACM Workhop on Wireless Multimedia Networking and Performance Modeling (WMuNeP '06) will take place in Torremolinos, M=E1laga, Spain, in October 2-6th, 2006, co-located with ACM MSWiM '06. For some information on the beautiful city of Torremolinos please go to: http://www.ayto-torremolinos.org/ http://www.torremolinos.com/ http://www.andalucia.com/cities/malaga/home.htm ----------------------------------------------------------------------------= ---- Workshop Co-Chairs: Prof. Regina B. Araujo Federal University of S=E3o Carlos S=E3o Carlos, SP, Brazil regina@dc.ufscar.br Prof. Hussein M Alnuweiri University of British Columbia Vancouver, Canada hussein@ece.ubc.ca ----------------------------------------------------------------------------= ---- Program Committee: Hussein Alnuweiri, University of British Columbia, Canada Rossana Andrade, Federal University of Ceara, Brazil Regina Araujo, Federal University of Sao Carlos, Brazil Nazim Agoulmine, University of Evry, France Azzedine Boukerche, University of Ottawa, Canada Raffaele Bruno, CNR, Italy Hsiao-Hwa Chen, National Sun Yat-Sen University, Taiwan Zihua Guo, Lenovo Corporate R&D, China Anna Hac, University of Hawaii, USA Hai Jiang, University of Waterloo, Canada Victor Leung, University of British Columbia, Canada Wei Li, University of Toledo, USA Jiangchuan Liu, Simon Fraser University, Canada Pascal Lorenz, University of Haute Alsace, France Antonio A. F. Loureiro, Federal University of Minas Gerais, Brazil Andreas Meissner, Fraunhofer Institute, Germany Jelena Misic, University of Manitoba, Canada Edmundo Monteiro, University of Coimbra, Portugal Jander Moreira, Federal University of Sao Carlos, Brazil Mirela S. M. Notare, Barddal University, Brazil Stephen Olariu, Old Dominion University, USA Jianping Pan, NTT MCL, USA Bjorn Pehrson, Royal Institute of Technology, Sweden Yu-Chee Tseng, National Chiao Tung Univ., Taiwan Murat Uysal, University of Waterloo, Canada Qi Xue, Qualcomm Inc., USA Yang Yang, University College London, UK Weihua Zhuang, University of Waterloo, Canada ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 05 17:06:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMHP-0001fh-8L; Mon, 05 Jun 2006 17:06:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FnMHO-0001fc-3F for mip4@ietf.org; Mon, 05 Jun 2006 17:06:30 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FnMHL-0002PW-MZ for mip4@ietf.org; Mon, 05 Jun 2006 17:06:30 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Jun 2006 14:06:25 -0700 Message-ID: <44849C8E.4070000@azairenet.com> Date: Mon, 05 Jun 2006 14:05:18 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jouni.korhonen@teliasonera.com Subject: Re: [Mip4] Working Group Last Call fordraft-ietf-mip4-mobike-connectivity-00 References: <5D25AEFB114D034FBDC8B156FCA78E03BFB8D3@SEHAN021MB.tcad.telia.se> <445BD94C.4030900@azairenet.com> In-Reply-To: <445BD94C.4030900@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jun 2006 21:06:25.0395 (UTC) FILETIME=[E7C3A430:01C688E3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hello Jouni and all, >>> jouni.korhonen@teliasonera.com wrote: >>> >>>> o The draft seems to be biased toward enterprise networks, at >>>> least from the used terminology point of view. However, the >>>> same solution would nicely fit e.g. into 'mobile operator' >>>> controlled and hosted network deployments as well (thinking >>>> e.g. 3GPP stuff here). Maybe few words about that would be >>>> good to have.. or slight change of wording (like enterprise >>>> network -> trusted network etc) >>> >>> its historical. MIPv4 has been working on >>> Enterprise connectivity solutions using MIPv4 and >>> VPNs for a while. so this was proposed an alternate >>> solution when IKEv2 with MOBIKE is used to setup >>> the VPN. >>> >>> we could in the appendix describe how this can be >>> applied to an operator's trusted/untrusted network. >>> however, this would need WG consensus. >> >> Some lines around this would be nice. > > I will write something up and send to the > mailing list soon. here is some text for a new appendix. Appendix A. Applicability to a Mobile Operator Network The solution described in this document can also be applied to a Mobile Operator's network when the Operator deploys heterogeneous access networks and some of the access networks are considered as trusted networks and others as untrusted networks. Figure 2 illustrates such a network topology. +----------------------+ | +----+ | +----------------+ | |i-HA| | | | | +----+ | (MN)----+ trusted +---+ | | access network | | internal network | +----------------+ | | | | +----------+-----------+ | | | [mVPN] +----------------+ | | | | (MN)----+ untrusted +--------------+ {mc} | access network | +----------------+ Figure 2: Network Topology of a Mobile Operator with trusted and untrusted networks An IPsec VPN gateway provides secure connectivity to the Operator's internal network for mobile nodes attached to an untrusted access network. The VPN gateway supports MOBIKE extensions so that the IPsec tunnels survive any IP address change when the mobile node moves while attached to the untrusted access networks. When the mobile node is attached to the trusted access network it uses Mobile IP with the i-HA. It uses the IP address obtained from the trusted access network as the co-located care-of address to register with the i-HA. If a foreign agent is available in the trusted access network, the mobile node may use foreign agent care-of address. If the mobile node moves and attaches to an untrusted access network, it sets up an IPsec tunnel with the VPN gateway to access the Operator's internal network. It uses the IPsec TIA as the co-located care-of address to register with the i-HA thereby creating a Mobile IP tunnel inside an IPsec tunnel. comments are welcome. you can find the latest version of the draft at http://www.dvijay.com/ietf/internet-drafts/mip4/mipsec.txt Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 08 16:50:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRSr-0005PS-U1; Thu, 08 Jun 2006 16:50:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoRSr-0005OQ-12; Thu, 08 Jun 2006 16:50:49 -0400 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 1FoQw7-0005SP-Ue; Thu, 08 Jun 2006 16:16:59 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoQW2-00064q-0F; Thu, 08 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k58Jo1WR007601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FoQW1-0003hL-Je; Thu, 08 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 08 Jun 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-gen-ext-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : MIPv4 Extension for Configuration Options Exchange Author(s) : J. Bharatia, et al. Filename : draft-ietf-mip4-gen-ext-00.txt Pages : 12 Date : 2006-6-8 This document describes the mechanism for providing the host configuration information during Mobile IP registration. One or more Configuration Options Exchange Extensions may be included in the registration message to provide the Mobile Node the configuration parameters needed for network service usage (e.g. DNS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-gen-ext-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-gen-ext-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-gen-ext-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-8125702.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-gen-ext-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-gen-ext-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-8125702.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Thu Jun 08 17:26:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoS11-00009D-VT; Thu, 08 Jun 2006 17:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoS10-00008x-LK for mip4@ietf.org; Thu, 08 Jun 2006 17:26:06 -0400 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 1FoS10-0005UH-Jo for mip4@ietf.org; Thu, 08 Jun 2006 17:26:06 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FoRvn-00005e-KS for mip4@ietf.org; Thu, 08 Jun 2006 17:20:45 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Jun 2006 14:20:28 -0700 Message-ID: <448894A0.5000001@azairenet.com> Date: Thu, 08 Jun 2006 14:20:32 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: mip4@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2006 21:20:28.0228 (UTC) FILETIME=[5D5F0040:01C68B41] X-Spam-Score: -1.9 (-) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Mip4] Comments on draft-ietf-mip4-gen-ext-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org hello, I am curious about draft-ietf-mip4-gen-ext-00.txt. I can see this mechanism being used when the mobile node wants to get DNS/DHCP information from the home link. but from a visited link, why would the FA send this information through a registration reply? wouldn't it be better to use agent advertisement? the mobile node might need the DNS information even before it sends a registration request. also the mechanism described here does not work if the mobile node is using co-located CoA and wants DNS/DHCP information from the visited link. I wasn't involved in the earlier discussions of this draft. so I might not be aware of certain things. Vijay -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 09 08:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fog6u-00066M-0D; Fri, 09 Jun 2006 08:29:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoLzA-0000Ze-8S for mip4@ietf.org; Thu, 08 Jun 2006 10:59:48 -0400 Received: from barbarian.comsoc.org ([140.98.194.218]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FoLz8-0004dK-Uf for mip4@ietf.org; Thu, 08 Jun 2006 10:59:48 -0400 Received: from [140.98.210.253] by barbarian.comsoc.org (GMS 11.01.3365/NY9491.00.1c9c152c) with ESMTP id iodwjcaa for mip4@ietf.org; Thu, 8 Jun 2006 11:35:10 -0400 From: ComSocConferences@comsoc.org To: mip4@ietf.org Date: Thu, 8 Jun 2006 11:00:38 -0400 MIME-Version: 1.0 Message-ID: X-Originating-IP: [140.98.210.253] X-Spam-Score: 0.5 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 X-Mailman-Approved-At: Fri, 09 Jun 2006 08:29:06 -0400 Subject: [Mip4] IEEE WCNC 2007/Hong Kong: CFP Announcement! X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1094124601==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1094124601== Content-Type: multipart/alternative; boundary="--=_NextPart_03B56690_1EDF06E1_01C9F258.D84EF1C0" This is a multi-part message in MIME format. ----=_NextPart_03B56690_1EDF06E1_01C9F258.D84EF1C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable IEEE Wireless Communications and Networking Conference (WCNC 2007) 11 =96 15 March 2007 / Hong Kong / http://www.ieee-wcnc.org WCNC is the premier wireless event for wireless communications researchers,= industry professionals, and academics interested in the latest development= and design of wireless systems. It is organized by the IEEE Communications= Society and has a history of bringing together academia, industry and= regulatory bodies. In 2007, WCNC will be held in Hong Kong, Asia=92s World City. You are= invited to submit papers in all areas of wireless communications including= physical layer, MAC layer, networks and applications. IMPORTANT DATES: Full paper submissions: 20 September 2006 Notification of acceptance: 8 December 2006 Camera ready submission: 5 January 2007 SUBMISSION GUIDELINES: Authors are invited to submit full papers (maximum 5 pages) electronically in= PDF format. For all submissions, please use the template available on the= website. CALL FOR PROPOSALS: The WCNC 2007 organizing committee invites you to submit proposals for= tutorials, technical papers and Technology/Business Applications Panels. Deadline: 20 September 2006 Ross Murch Technical Program Chair, WCNC 2007 Khaled B. Letaief Chih-Lin I General Chairs, WCNC 2007 For more WCNC 2007 details & updates, visit: http://www.ieee-wcnc.org ----=_NextPart_03B56690_1EDF06E1_01C9F258.D84EF1C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
3D""
 

IEEE Wireless Communications and Networking Conference (WCNC 2007)
11 =96 15 March 2007 /Hong Kong / http://www.ieee-wcnc.org

WCNC is the premier wireless event for wireless communications researchers, industry professionals, and academics interested in the latest development and design of wireless systems.  It is organized by the IEEE Communications Society and has a history of bringing together academia, industry and regulatory= bodies.

In 2007, WCNC will be held in Hong Kong, Asia=92s World City.   You are invited to submit papers in all areas of wireless communications including physical layer, MAC layer, networks and applications. 

IMPORTANT DATES:
Full paper submissions:           =     20 September 2006
Notification of acceptance:         =    8 December 2006
Camera ready submission:  =           5 January 2007
SUBMISSION GUIDELINES:
Authors are= invited to submit full papers (maximum 5 pages) electronically in PDF format.  For all submissions, please use the template available on the website. 

CALL FOR PROPOSALS:
The WCNC 2007 organizing committee invites you to submit proposals for tutorials, technical papers and Technology/Business Applications Panels. 
Deadline:  20 September 2006

Ross Murch
Technical Program Chair, WCNC= 2007

Khaled B. Letaief
Chih-Lin I
General Chairs, WCNC 2007



For more= WCNC 2007 details & updates, visit:  http://www.ieee-wcnc.org<= /P>

----=_NextPart_03B56690_1EDF06E1_01C9F258.D84EF1C0-- --===============1094124601== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1094124601==-- From mip4-bounces@ietf.org Fri Jun 09 13:30:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokoB-0004rN-4Y; Fri, 09 Jun 2006 13:30:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FokoA-0004rH-AQ for mip4@ietf.org; Fri, 09 Jun 2006 13:30:06 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foko5-0002br-U1 for mip4@ietf.org; Fri, 09 Jun 2006 13:30:06 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k59HTvm24348; Fri, 9 Jun 2006 13:29:57 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Comments on draft-ietf-mip4-gen-ext-00.txt Date: Fri, 9 Jun 2006 12:29:56 -0500 Message-ID: In-Reply-To: <448894A0.5000001@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Comments on draft-ietf-mip4-gen-ext-00.txt Thread-Index: AcaLQi+1gXGmwSELRgyayS4bhuGNAAApiOMQ From: "Jayshree Bharatia" To: "Vijay Devarapalli" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Vijay, Thanks for reviewing this draft.=20 We have debated this point of supporting FA option earlier and I guess it was brought up as a one of the open issue in one of the WG meeting. Some of us like to see this option so that information like SIP server address (resided in the visited network) can be exchanged. This information is currently exchanged using specific link layer protocols today. By having this mechanism makes the solution independent of link layer hooks.=20 You are right that information from the visited link for co-located CoA is not possible. We will add this to our draft. Thanks, Jayshree -----Original Message----- From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 Sent: Thursday, June 08, 2006 4:21 PM To: mip4@ietf.org Subject: [Mip4] Comments on draft-ietf-mip4-gen-ext-00.txt hello, I am curious about draft-ietf-mip4-gen-ext-00.txt. I can see this mechanism being used when the mobile node wants to get DNS/DHCP information from the home link. but from a visited link, why would the FA send this information through a registration reply? wouldn't it be better to use agent advertisement? the mobile node might need the DNS information even before it sends a registration request. also the mechanism described here does not work if the mobile node is using co-located CoA and wants DNS/DHCP information from the visited link. I wasn't involved in the earlier discussions of this draft. so I might not be aware of certain things. Vijay --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 09 15:16:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomT3-0008Sq-45; Fri, 09 Jun 2006 15:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FomT2-0008Sk-Am for mip4@ietf.org; Fri, 09 Jun 2006 15:16:24 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FomT1-0008UQ-1n for mip4@ietf.org; Fri, 09 Jun 2006 15:16:24 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k59JGM19008593 for ; Fri, 9 Jun 2006 12:16:22 -0700 (MST) Received: from de01exm63.ds.mot.com (de01exm63.am.mot.com [10.176.8.108]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k59JGM7B000147 for ; Fri, 9 Jun 2006 14:16:22 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 9 Jun 2006 15:16:18 -0400 Message-ID: <5AE7B4EFBF6A994C91FAC5A6C31C33E0018BED0B@de01exm63.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt Thread-Index: AcaL+S+MuN8j6R2fR7S22Nmtj9RbPw== From: "Kakinada Umamaheswar-W00231" To: X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Mip4] comments on draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1037156833==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1037156833== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68BF9.300CD4E1" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68BF9.300CD4E1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 Hi, I am curious about the section 1.3 in draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt which states=20 =20 " An L2 trigger may be categorized according to whether it is received by the MN, oFA, or nFA. Table 1 gives such a categorization along with information contained in the trigger. The methods presented in this document operate based on different types of L2 triggers as shown in Table 1. Once the L2 trigger is received, the handoff processes described hereafter are initiated. The three triggers: L2- ST, L2-TT and L2-MT are independent of each other and are not expected to occur together since each will trigger a different type of handoff behaviour. " =20 So, does it preclude occurrence of more then one instance of the events L2-ST, L2-TT and L2-MT at any given time. Please bear with me if it was already discussed, I was not part of any previous discussions on this topic. Would appreciate if somebody can elaborate on this aspect. =20 Thanks and regards=20 =20 Achari =20 =20 ------_=_NextPart_001_01C68BF9.300CD4E1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
  = I am curious=20 about the  section 1.3 in = draft-ietf-mobileip-lowlatency-handoffs-v4-11.txt=20 which states
 
  = " An L2=20 trigger may be categorized according to whether it is = received
  =20 by the MN, oFA, or nFA.  Table 1 gives such a categorization=20 along
   with information contained in the trigger.  = The=20 methods presented in
   this document operate based on = different=20 types of L2 triggers as
   shown in Table 1.  Once the = L2=20 trigger is received, the handoff
   processes described = hereafter=20 are initiated.  The three triggers: L2-
   ST, L2-TT = and L2-MT=20 are independent of each other and are not
   expected to = occur=20 together since each will trigger a different type
   of = handoff=20 behaviour. "
 
   So,=20 does it preclude occurrence of more then one instance of the=20 events  L2-ST, L2-TT and L2-MT at any given time. = Please bear=20 with me if it was already discussed, I was not part of any previous = discussions on this topic. Would appreciate if somebody can elaborate on = this=20 aspect.
 
Thanks and regards =
 
Achari
 
 
------_=_NextPart_001_01C68BF9.300CD4E1-- --===============1037156833== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1037156833==-- From mip4-bounces@ietf.org Fri Jun 09 16:10:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fon3C-0003B2-2Z; Fri, 09 Jun 2006 15:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fon2y-00034t-2Z for mip4@ietf.org; Fri, 09 Jun 2006 15:53:32 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fon2v-0004Lk-05 for mip4@ietf.org; Fri, 09 Jun 2006 15:53:31 -0400 Received: from [10.1.210.4] ([10.1.210.4]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Jun 2006 12:53:24 -0700 Message-ID: <4489D1B4.1030604@azairenet.com> Date: Fri, 09 Jun 2006 12:53:24 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Jayshree Bharatia Subject: Re: [Mip4] Comments on draft-ietf-mip4-gen-ext-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2006 19:53:25.0165 (UTC) FILETIME=[5E9895D0:01C68BFE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Jayshree Bharatia wrote: > Hi Vijay, > > Thanks for reviewing this draft. it was more of a quick glance. :) > We have debated this point of supporting FA option earlier and I guess > it was brought up as a one of the open issue in one of the WG meeting. > Some of us like to see this option so that information like SIP server > address (resided in the visited network) can be exchanged. the SIP folks have specified a number of options to discover the SIP proxy address from the visited network. > This > information is currently exchanged using specific link layer protocols > today. By having this mechanism makes the solution independent of link > layer hooks. ok. Vijay > You are right that information from the visited link for co-located CoA > is not possible. We will add this to our draft. > > Thanks, > Jayshree > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Thursday, June 08, 2006 4:21 PM > To: mip4@ietf.org > Subject: [Mip4] Comments on draft-ietf-mip4-gen-ext-00.txt > > > hello, > > I am curious about draft-ietf-mip4-gen-ext-00.txt. I can > see this mechanism being used when the mobile node wants > to get DNS/DHCP information from the home link. but from > a visited link, why would the FA send this information > through a registration reply? wouldn't it be better to > use agent advertisement? the mobile node might need the > DNS information even before it sends a registration > request. also the mechanism described here does not work > if the mobile node is using co-located CoA and wants > DNS/DHCP information from the visited link. > > I wasn't involved in the earlier discussions of this > draft. so I might not be aware of certain things. > > Vijay > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 13 12:29:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBmA-0001qZ-6J; Tue, 13 Jun 2006 12:29:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqBm9-0001qU-2Q for mip4@ietf.org; Tue, 13 Jun 2006 12:29:57 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqBm7-00037i-PY for mip4@ietf.org; Tue, 13 Jun 2006 12:29:57 -0400 Received: from nwsgpa.ih.lucent.com (h135-1-121-22.lucent.com [135.1.121.22]) by ihemail3.lucent.com (8.13.6/IER-o) with ESMTP id k5DGTtUl019119; Tue, 13 Jun 2006 11:29:55 -0500 (CDT) Received: from [127.0.0.1] by nwsgpa.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id k5DGTsM05150; Tue, 13 Jun 2006 11:29:54 -0500 (CDT) Message-ID: <448EE7FC.90104@lucent.com> Date: Tue, 13 Jun 2006 11:29:48 -0500 From: Pete McCann User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Henrik Levkowetz Subject: [Mip4] Working Group Last Call on draft-ietf-mip4-message-string-ext-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This message announces a WG last call on: "Mobile IPv4 Message String Extension" - draft-ietf-mip4-message-string-ext-00 The last call will conclude at 24:00 UTC on Tuesday, 27 June 2006. draft-ietf-mip4-message-string-ext-00 describes a new Mobile IPv4 extension to carry a user-readable result string with Mobile IPv4 Registration Replies. A URL for this Internet-Draft is: Please respond to this WG last call: * If you have no comments on the draft, and support its advancement, simply respond with a line containing something like "I support the advancement of this document to the IESG with a request for publication as proposed standard." If you have comments, please use a line similar to the one above, and supplement this with your comments. * If you *don't* support its advancement, respond with a line containing something like the following, supplemented by your comments - "I don't support the advancement of this document to the IESG with a request for publication as proposed standard, for the following reasons:" ... Pete & Henrik -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 13 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 1FqCAN-0005M3-DS; Tue, 13 Jun 2006 12:54:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqCAM-0005Lt-I7 for mip4@ietf.org; Tue, 13 Jun 2006 12:54:58 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqCAK-0005ln-8B for mip4@ietf.org; Tue, 13 Jun 2006 12:54:58 -0400 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: [Mip4] Working Group Last Call ondraft-ietf-mip4-message-string-ext-00.txt Date: Tue, 13 Jun 2006 12:55:07 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last Call ondraft-ietf-mip4-message-string-ext-00.txt Thread-Index: AcaPBrPw04kMBRlBTqS6UnZQg3W/egAAhngA From: "Avi Lior" To: "Pete McCann" , "Mobile IPv4 Mailing List" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org "I support the advancement of this document to the IESG with a request for publication as proposed standard." I have the following technical comment. The text field should not be null terminated. From: The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [RFC2279] characters. To: The implementation dependent Text field is one or more octets, and must not be NUL (hex 00) terminated. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [RFC2279] characters. > -----Original Message----- > From: Pete McCann [mailto:mccap@lucent.com]=20 > Sent: Tuesday, June 13, 2006 12:30 PM > To: Mobile IPv4 Mailing List > Cc: Henrik Levkowetz > Subject: [Mip4] Working Group Last Call=20 > ondraft-ietf-mip4-message-string-ext-00.txt >=20 > This message announces a WG last call on: >=20 > "Mobile IPv4 Message String Extension" > - draft-ietf-mip4-message-string-ext-00 >=20 > The last call will conclude at 24:00 UTC on Tuesday, 27 June 2006. >=20 > draft-ietf-mip4-message-string-ext-00 describes a new Mobile=20 > IPv4 extension to carry a user-readable result string with=20 > Mobile IPv4 Registration Replies. >=20 > A URL for this Internet-Draft is: >=20 > >=20 >=20 > Please respond to this WG last call: >=20 > * If you have no comments on the draft, and support its advancement, > simply respond with a line containing something like >=20 > "I support the advancement of this document to the IESG with a > request for publication as proposed standard." >=20 > If you have comments, please use a line similar to the one=20 > above, and > supplement this with your comments. >=20 >=20 > * If you *don't* support its advancement, respond with a line=20 > containing > something like the following, supplemented by your comments - >=20 > "I don't support the advancement of this document to the IESG with > a request for publication as proposed standard, for the following > reasons:" > ... >=20 >=20 > Pete & Henrik >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 13 23:26:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqM1v-0001OB-M6; Tue, 13 Jun 2006 23:26:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqM1u-0001O3-8T for mip4@ietf.org; Tue, 13 Jun 2006 23:26:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqM1s-0007qE-QG for mip4@ietf.org; Tue, 13 Jun 2006 23:26:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 13 Jun 2006 20:26:52 -0700 X-IronPort-AV: i="4.06,129,1149490800"; d="scan'208"; a="294303499:sNHT179819350" 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 k5E3Qp1u001305; Tue, 13 Jun 2006 20:26:51 -0700 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 k5E3Qp9s023590; Tue, 13 Jun 2006 20:26:51 -0700 (PDT) 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.211); Tue, 13 Jun 2006 20:26:51 -0700 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: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Date: Tue, 13 Jun 2006 20:26:50 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201FA2EDF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Thread-Index: AcaPBrPw04kMBRlBTqS6UnZQg3W/egAAhngAAA6q6nA= From: "Kent Leung \(kleung\)" To: "Avi Lior" , "Pete McCann" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 14 Jun 2006 03:26:51.0177 (UTC) FILETIME=[604B9190:01C68F62] DKIM-Signature: a=rsa-sha1; q=dns; l=3491; t=1150255612; x=1151119612; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Working=20Group=20Last=20Callondraft-ietf-mip4-message- string-ext-00.txt; X=v=3Dcisco.com=3B=20h=3Dgkn+nM32iuL2MD4SBGJey/qDWHg=3D; b=Q736eCJTC1zGNdJEjOLQjowE/mjtDt0+B6+43iN4NXCK5d57ujj4XxwG5e1Oc6Jmt+o58IYX VIp1nWE91moyCYT0JtIlD+0QQ2B5JlUCBehPlSUeIdYoQRBGoTe5F3wJ; Authentication-Results: sj-dkim-3.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Avi. This is a good clarification. Thanks. Kent=20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Tuesday, June 13, 2006 9:55 AM > To: Pete McCann; Mobile IPv4 Mailing List > Cc: Henrik Levkowetz > Subject: RE: [Mip4] Working Group Last=20 > Callondraft-ietf-mip4-message-string-ext-00.txt >=20 > "I support the advancement of this document to the IESG with=20 > a request for publication as proposed standard." >=20 > I have the following technical comment. The text field=20 > should not be null terminated. >=20 > From: >=20 > The Text field is one or more octets, and its contents are > implementation dependent. It is intended to be human readable, > and MUST NOT affect operation of the protocol. It is=20 > recommended > that the message contain UTF-8 encoded 10646 [RFC2279]=20 > characters. >=20 > To: > The implementation dependent Text field is one or more=20 > octets, and must not be NUL (hex 00) terminated. It is=20 > intended to be human readable, > and MUST NOT affect operation of the protocol. It is=20 > recommended > that the message contain UTF-8 encoded 10646 [RFC2279]=20 > characters. >=20 >=20 >=20 > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Tuesday, June 13, 2006 12:30 PM > > To: Mobile IPv4 Mailing List > > Cc: Henrik Levkowetz > > Subject: [Mip4] Working Group Last Call=20 > > ondraft-ietf-mip4-message-string-ext-00.txt > >=20 > > This message announces a WG last call on: > >=20 > > "Mobile IPv4 Message String Extension" > > - draft-ietf-mip4-message-string-ext-00 > >=20 > > The last call will conclude at 24:00 UTC on Tuesday, 27 June 2006. > >=20 > > draft-ietf-mip4-message-string-ext-00 describes a new Mobile > > IPv4 extension to carry a user-readable result string with=20 > Mobile IPv4=20 > > Registration Replies. > >=20 > > A URL for this Internet-Draft is: > >=20 > > tring-ext-00.txt> > >=20 > >=20 > > Please respond to this WG last call: > >=20 > > * If you have no comments on the draft, and support its advancement, > > simply respond with a line containing something like > >=20 > > "I support the advancement of this document to the IESG with a > > request for publication as proposed standard." > >=20 > > If you have comments, please use a line similar to the=20 > one above,=20 > > and > > supplement this with your comments. > >=20 > >=20 > > * If you *don't* support its advancement, respond with a line=20 > > containing > > something like the following, supplemented by your comments - > >=20 > > "I don't support the advancement of this document to=20 > the IESG with > > a request for publication as proposed standard, for=20 > the following > > reasons:" > > ... > >=20 > >=20 > > Pete & Henrik > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 14 13:13:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYvm-0000R5-Mx; Wed, 14 Jun 2006 13:13:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqYvl-0000Qd-H8 for mip4@ietf.org; Wed, 14 Jun 2006 13:13:25 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqYow-0005H6-Sn for mip4@ietf.org; Wed, 14 Jun 2006 13:06:24 -0400 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 k5EH6HT13174; Wed, 14 Jun 2006 13:06:18 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Date: Wed, 14 Jun 2006 12:05:58 -0500 Message-ID: <7A3E36B3528ED04A880178D337F30C9A0CA0B33B@zrc2hxm1.corp.nortel.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5201FA2EDF@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Thread-Index: AcaPBrPw04kMBRlBTqS6UnZQg3W/egAAhngAAA6q6nAAI+Rq8A== From: "Curtis Provost" To: "Kent Leung \(kleung\)" , "Avi Lior" , "Pete McCann" , "Mobile IPv4 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I'm not convinced that I agree. I think it may be more appropriate to have a general statement saying that only human-readable characters may be included in the text field, but to exclude only the null terminator seems too narrow.=20 Perhaps something like: The implementation dependent Text field is one or more octets, and SHOULD NOT contain non human readable characters; e.g. it should not be null terminated. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [RFC2279] characters. Curtis -----Original Message----- From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Tuesday, June 13, 2006 10:27 PM To: Avi Lior; Pete McCann; Mobile IPv4 Mailing List Cc: Henrik Levkowetz Subject: RE: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Hi Avi. This is a good clarification. Thanks. Kent=20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Tuesday, June 13, 2006 9:55 AM > To: Pete McCann; Mobile IPv4 Mailing List > Cc: Henrik Levkowetz > Subject: RE: [Mip4] Working Group Last=20 > Callondraft-ietf-mip4-message-string-ext-00.txt >=20 > "I support the advancement of this document to the IESG with=20 > a request for publication as proposed standard." >=20 > I have the following technical comment. The text field=20 > should not be null terminated. >=20 > From: >=20 > The Text field is one or more octets, and its contents are > implementation dependent. It is intended to be human readable, > and MUST NOT affect operation of the protocol. It is=20 > recommended > that the message contain UTF-8 encoded 10646 [RFC2279]=20 > characters. >=20 > To: > The implementation dependent Text field is one or more=20 > octets, and must not be NUL (hex 00) terminated. It is=20 > intended to be human readable, > and MUST NOT affect operation of the protocol. It is=20 > recommended > that the message contain UTF-8 encoded 10646 [RFC2279]=20 > characters. >=20 >=20 >=20 > > -----Original Message----- > > From: Pete McCann [mailto:mccap@lucent.com] > > Sent: Tuesday, June 13, 2006 12:30 PM > > To: Mobile IPv4 Mailing List > > Cc: Henrik Levkowetz > > Subject: [Mip4] Working Group Last Call=20 > > ondraft-ietf-mip4-message-string-ext-00.txt > >=20 > > This message announces a WG last call on: > >=20 > > "Mobile IPv4 Message String Extension" > > - draft-ietf-mip4-message-string-ext-00 > >=20 > > The last call will conclude at 24:00 UTC on Tuesday, 27 June 2006. > >=20 > > draft-ietf-mip4-message-string-ext-00 describes a new Mobile > > IPv4 extension to carry a user-readable result string with=20 > Mobile IPv4=20 > > Registration Replies. > >=20 > > A URL for this Internet-Draft is: > >=20 > > tring-ext-00.txt> > >=20 > >=20 > > Please respond to this WG last call: > >=20 > > * If you have no comments on the draft, and support its advancement, > > simply respond with a line containing something like > >=20 > > "I support the advancement of this document to the IESG with a > > request for publication as proposed standard." > >=20 > > If you have comments, please use a line similar to the=20 > one above,=20 > > and > > supplement this with your comments. > >=20 > >=20 > > * If you *don't* support its advancement, respond with a line=20 > > containing > > something like the following, supplemented by your comments - > >=20 > > "I don't support the advancement of this document to=20 > the IESG with > > a request for publication as proposed standard, for=20 > the following > > reasons:" > > ... > >=20 > >=20 > > Pete & Henrik > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 14 15:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqaba-0006FS-7A; Wed, 14 Jun 2006 15:00:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqabZ-0006FM-Di for mip4@ietf.org; Wed, 14 Jun 2006 15:00:41 -0400 Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqabX-0003g9-NL for mip4@ietf.org; Wed, 14 Jun 2006 15:00:41 -0400 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id C07AE37E9B; Wed, 14 Jun 2006 21:00:38 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 996ED37E49; Wed, 14 Jun 2006 21:00:38 +0200 (CEST) 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 BC72637E46; Wed, 14 Jun 2006 21:00:35 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FqabT-0006jo-CG; Wed, 14 Jun 2006 21:00:35 +0200 Message-ID: <44905CD3.9070206@levkowetz.com> Date: Wed, 14 Jun 2006 21:00:35 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Curtis Provost Subject: Re: [Mip4] Working Group Last Call on draft-ietf-mip4-message-string-ext-00.txt References: <7A3E36B3528ED04A880178D337F30C9A0CA0B33B@zrc2hxm1.corp.nortel.com> In-Reply-To: <7A3E36B3528ED04A880178D337F30C9A0CA0B33B@zrc2hxm1.corp.nortel.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: "Kent Leung \(kleung\)" , Mobile IPv4 Mailing List , Pete McCann , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1982670375==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1982670375== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB869936DAFB244512DF86502" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB869936DAFB244512DF86502 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If I may be a bit contrary here... Why would / should we exclude anything? So far there's a statement that the string should not be NUL terminated, and now a statement that it might make more sense to extend this to only human-readable characters. But I miss at least * A motivation why any of these are better than the current text. * If NUL terminated strings are disallowed, an explanation of how to handle strings which are non-null terminated, but contain a NUL character. * NUL is an ascii character, but the text recommends that the text have UTF-8 encoding. What does NUL terminated mean for UTF-8 strings? * What is the proper definition of "human-readable" for unicode characters? I would propose to skip this whole can of worms, and use ether the original text: The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [RFC2279] characters. or one of the following two modifications. For the first one, note the elevation of 'recommended' to 'RECOMMENDED', and the additional sentence at the end. The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. It is RECOMMENDED that the message contain UTF-8 encoded 10646 [RFC2279] characters. The length of the text in the text field is exactly the value of the Length field minus one, in the encoding used. But I'd really also like to elevate the RECOMMENDED one step further, to a MUST in order to remove potential incompatibilities between 256 valued character sets like Latin-1 and UTF-8. Even if ASCII and UTF-8 can 'co-exist', this is not the case for many other character sets that have a fairly wide spread. So this would be my favourite text: The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable, and MUST NOT affect operation of the protocol. The content of this field MUST be an UTF-8 encoded representation of an ISO-10646 [RFC2279] message. The length of the UTF-8 representation of the message is is exactly the value of the Length field minus one. Regards, Henrik on 2006-06-14 19:05 Curtis Provost said the following: > I'm not convinced that I agree. I think it may be more appropriate to > have a general statement saying that only human-readable characters may= > be included in the text field, but to exclude only the null terminator > seems too narrow.=20 >=20 >=20 > Perhaps something like: >=20 > The implementation dependent Text field is one or more octets, and > SHOULD NOT contain non human readable characters; e.g. it should not be= > null terminated. It is intended to be human readable, and MUST NOT > affect operation of the protocol. It is recommended that the message > contain UTF-8 encoded 10646 [RFC2279] characters. >=20 >=20 >=20 > Curtis >=20 > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 > Sent: Tuesday, June 13, 2006 10:27 PM > To: Avi Lior; Pete McCann; Mobile IPv4 Mailing List > Cc: Henrik Levkowetz > Subject: RE: [Mip4] Working Group Last > Callondraft-ietf-mip4-message-string-ext-00.txt >=20 > Hi Avi. This is a good clarification. Thanks. >=20 > Kent=20 >=20 >> -----Original Message----- >> From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 >> Sent: Tuesday, June 13, 2006 9:55 AM >> To: Pete McCann; Mobile IPv4 Mailing List >> Cc: Henrik Levkowetz >> Subject: RE: [Mip4] Working Group Last=20 >> Callondraft-ietf-mip4-message-string-ext-00.txt >>=20 >> "I support the advancement of this document to the IESG with=20 >> a request for publication as proposed standard." >>=20 >> I have the following technical comment. The text field=20 >> should not be null terminated. >>=20 >> From: >>=20 >> The Text field is one or more octets, and its contents are >> implementation dependent. It is intended to be human readable, >> and MUST NOT affect operation of the protocol. It is=20 >> recommended >> that the message contain UTF-8 encoded 10646 [RFC2279]=20 >> characters. >>=20 >> To: >> The implementation dependent Text field is one or more=20 >> octets, and must not be NUL (hex 00) terminated. It is=20 >> intended to be human readable, >> and MUST NOT affect operation of the protocol. It is=20 >> recommended >> that the message contain UTF-8 encoded 10646 [RFC2279]=20 >> characters. >>=20 >>=20 >>=20 >> > -----Original Message----- >> > From: Pete McCann [mailto:mccap@lucent.com] >> > Sent: Tuesday, June 13, 2006 12:30 PM >> > To: Mobile IPv4 Mailing List >> > Cc: Henrik Levkowetz >> > Subject: [Mip4] Working Group Last Call=20 >> > ondraft-ietf-mip4-message-string-ext-00.txt >> >=20 >> > This message announces a WG last call on: >> >=20 >> > "Mobile IPv4 Message String Extension" >> > - draft-ietf-mip4-message-string-ext-00 >> >=20 >> > The last call will conclude at 24:00 UTC on Tuesday, 27 June 2006. >> >=20 >> > draft-ietf-mip4-message-string-ext-00 describes a new Mobile >> > IPv4 extension to carry a user-readable result string with=20 >> Mobile IPv4=20 >> > Registration Replies. >> >=20 >> > A URL for this Internet-Draft is: >> >=20 >> > > tring-ext-00.txt> >> >=20 >> >=20 >> > Please respond to this WG last call: >> >=20 >> > * If you have no comments on the draft, and support its advancement,= >> > simply respond with a line containing something like >> >=20 >> > "I support the advancement of this document to the IESG with a >> > request for publication as proposed standard." >> >=20 >> > If you have comments, please use a line similar to the=20 >> one above,=20 >> > and >> > supplement this with your comments. >> >=20 >> >=20 >> > * If you *don't* support its advancement, respond with a line=20 >> > containing >> > something like the following, supplemented by your comments - >> >=20 >> > "I don't support the advancement of this document to=20 >> the IESG with >> > a request for publication as proposed standard, for=20 >> the following >> > reasons:" >> > ... >> >=20 >> >=20 >> > Pete & Henrik >> >=20 >> > -- >> > Mip4 mailing list: Mip4@ietf.org >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> > Charter page:=20 >> http://www.ietf.org/html.charters/mip4-charter.html >> > Supplemental site: http://www.mip4.org/ >> >=20 >>=20 >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html= >> Supplemental site: http://www.mip4.org/ >>=20 >=20 --------------enigB869936DAFB244512DF86502 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEkFzTeVhrtTJkXCMRAqbwAKD4emuJdwKbcUOWRd5oaNhO+F63vACfb6+l 88/i4It91XbP1eE586zt/0Y= =QGQK -----END PGP SIGNATURE----- --------------enigB869936DAFB244512DF86502-- --===============1982670375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1982670375==-- From mip4-bounces@ietf.org Wed Jun 14 15:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbNm-0005nL-Gm; Wed, 14 Jun 2006 15:50:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqbNO-00055y-3q; Wed, 14 Jun 2006 15:50:06 -0400 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 1FqbNO-00015Z-1d; Wed, 14 Jun 2006 15:50:06 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=oak.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FqbNK-0000NL-4C; Wed, 14 Jun 2006 15:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k5EJo1WR030749 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jun 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FqbNJ-0006sJ-Ls; Wed, 14 Jun 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Jun 2006 15:50:01 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-mobike-connectivity-01.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE Author(s) : V. Devarapalli, P. Eronen Filename : draft-ietf-mip4-mobike-connectivity-01.txt Pages : 15 Date : 2006-6-14 Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivity-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-mobike-connectivity-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-mobike-connectivity-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-14113606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-mobike-connectivity-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-mobike-connectivity-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-14113606.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Wed Jun 14 17:22:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqcp4-0005h5-Ea; Wed, 14 Jun 2006 17:22:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqcp2-0005h0-K1 for mip4@ietf.org; Wed, 14 Jun 2006 17:22:44 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqcp1-00023z-8m for mip4@ietf.org; Wed, 14 Jun 2006 17:22:44 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Jun 2006 14:22:42 -0700 Message-ID: <44907DC2.80906@azairenet.com> Date: Wed, 14 Jun 2006 14:21:06 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip4@ietf.org Subject: [Fwd: [Mip4] I-D ACTION:draft-ietf-mip4-mobike-connectivity-01.txt] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jun 2006 21:22:42.0229 (UTC) FILETIME=[ABB86E50:01C68FF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org hello, I believe this version addresses comments that were raised during the WG last call. let me know if I missed anything. Vijay -------- Original Message -------- Subject: [Mip4] I-D ACTION:draft-ietf-mip4-mobike-connectivity-01.txt Date: Wed, 14 Jun 2006 15:50:01 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: mip4@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : Secure Connectivity and Mobility using Mobile IPv4 and MOBIKE Author(s) : V. Devarapalli, P. Eronen Filename : draft-ietf-mip4-mobike-connectivity-01.txt Pages : 15 Date : 2006-6-14 Enterprise users require mobility and secure connectivity when they roam and connect to the services offered in the enterprise. Secure connectivity is required when the user connects to the enterprise from an untrusted network. Mobility is beneficial when the user moves, either inside or outside the enterprise network, and acquires a new IP address. This document describes a solution using Mobile IPv4 and mobility extensions to IKEv2 (MOBIKE) to provide secure connectivity and mobility. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-mobike-connectivity-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-mobike-connectivity-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-mobike-connectivity-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 14 23:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqiCI-0006o5-Q1; Wed, 14 Jun 2006 23:07:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqiCI-0006nV-2T for mip4@ietf.org; Wed, 14 Jun 2006 23:07:06 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqiCG-0000fb-LM for mip4@ietf.org; Wed, 14 Jun 2006 23:07:06 -0400 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: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Date: Wed, 14 Jun 2006 23:07:19 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Thread-Index: AcaPBrPw04kMBRlBTqS6UnZQg3W/egAAhngAAA6q6nAAI+Rq8AAU1qMQ From: "Avi Lior" To: "Curtis Provost" , "Kent Leung \(kleung\)" , "Pete McCann" , "Mobile IPv4 Mailing List" X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Curtis, I am not excluding NULL, in fact I am allowing an embedded null. I am just saying the string should not be terminated. Your text does not address the termination part. I think we either need to say that this is terminated or non-terminated. We need to be clear about this. This is important. This could lead to very bad programming errors. Also your text is a MUST for human readable yet I don't think we need to be that ridgid. The current text say is is intended to be human readable which is totally different to what you are saying. Anyway there is precedence for this: I am just borrowing from RADIUS RFC 2865....This seems to be also the definition in Diameter. In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. =20 > -----Original Message----- > From: Curtis Provost [mailto:cprovost@nortel.com]=20 > Sent: Wednesday, June 14, 2006 1:06 PM > To: Kent Leung (kleung); Avi Lior; Pete McCann; Mobile IPv4=20 > Mailing List > Cc: Henrik Levkowetz > Subject: RE: [Mip4] Working Group Last=20 > Callondraft-ietf-mip4-message-string-ext-00.txt >=20 > I'm not convinced that I agree. I think it may be more=20 > appropriate to have a general statement saying that only=20 > human-readable characters may be included in the text field,=20 > but to exclude only the null terminator seems too narrow.=20 >=20 >=20 > Perhaps something like: >=20 > The implementation dependent Text field is one or more=20 > octets, and SHOULD NOT contain non human readable characters;=20 > e.g. it should not be null terminated. It is intended to be=20 > human readable, and MUST NOT affect operation of the=20 > protocol. It is recommended that the message contain UTF-8=20 > encoded 10646 [RFC2279] characters. >=20 >=20 >=20 > Curtis >=20 > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, June 13, 2006 10:27 PM > To: Avi Lior; Pete McCann; Mobile IPv4 Mailing List > Cc: Henrik Levkowetz > Subject: RE: [Mip4] Working Group Last > Callondraft-ietf-mip4-message-string-ext-00.txt >=20 > Hi Avi. This is a good clarification. Thanks. >=20 > Kent=20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Tuesday, June 13, 2006 9:55 AM > > To: Pete McCann; Mobile IPv4 Mailing List > > Cc: Henrik Levkowetz > > Subject: RE: [Mip4] Working Group Last=20 > > Callondraft-ietf-mip4-message-string-ext-00.txt > >=20 > > "I support the advancement of this document to the IESG=20 > with a request=20 > > for publication as proposed standard." > >=20 > > I have the following technical comment. The text field=20 > should not be=20 > > null terminated. > >=20 > > From: > >=20 > > The Text field is one or more octets, and its contents are > > implementation dependent. It is intended to be human=20 > readable, > > and MUST NOT affect operation of the protocol. It is=20 > > recommended > > that the message contain UTF-8 encoded 10646 [RFC2279]=20 > > characters. > >=20 > > To: > > The implementation dependent Text field is one or more octets, and=20 > > must not be NUL (hex 00) terminated. It is intended to be human=20 > > readable, > > and MUST NOT affect operation of the protocol. It is=20 > > recommended > > that the message contain UTF-8 encoded 10646 [RFC2279]=20 > > characters. > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Tuesday, June 13, 2006 12:30 PM > > > To: Mobile IPv4 Mailing List > > > Cc: Henrik Levkowetz > > > Subject: [Mip4] Working Group Last Call=20 > > > ondraft-ietf-mip4-message-string-ext-00.txt > > >=20 > > > This message announces a WG last call on: > > >=20 > > > "Mobile IPv4 Message String Extension" > > > - draft-ietf-mip4-message-string-ext-00 > > >=20 > > > The last call will conclude at 24:00 UTC on Tuesday, 27 June 2006. > > >=20 > > > draft-ietf-mip4-message-string-ext-00 describes a new Mobile > > > IPv4 extension to carry a user-readable result string with > > Mobile IPv4 > > > Registration Replies. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > > > > tring-ext-00.txt> > > >=20 > > >=20 > > > Please respond to this WG last call: > > >=20 > > > * If you have no comments on the draft, and support its=20 > advancement, > > > simply respond with a line containing something like > > >=20 > > > "I support the advancement of this document to the IESG with a > > > request for publication as proposed standard." > > >=20 > > > If you have comments, please use a line similar to the > > one above, > > > and > > > supplement this with your comments. > > >=20 > > >=20 > > > * If you *don't* support its advancement, respond with a line=20 > > > containing > > > something like the following, supplemented by your comments - > > >=20 > > > "I don't support the advancement of this document to > > the IESG with > > > a request for publication as proposed standard, for > > the following > > > reasons:" > > > ... > > >=20 > > >=20 > > > Pete & Henrik > > >=20 > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page:=20 > > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 15 10:57:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtID-0005Rf-Nt; Thu, 15 Jun 2006 10:57:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FqtIC-0005Ra-EH for mip4@ietf.org; Thu, 15 Jun 2006 10:57:56 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FqtIA-0007Il-Va for mip4@ietf.org; Thu, 15 Jun 2006 10:57:56 -0400 Received: from zrc2hxm1.corp.nortel.com (zrc2hxm1.corp.nortel.com [47.103.123.72]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k5FEvoG22377; Thu, 15 Jun 2006 10:57:51 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Date: Thu, 15 Jun 2006 09:57:34 -0500 Message-ID: <7A3E36B3528ED04A880178D337F30C9A0CA5A8D0@zrc2hxm1.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Thread-Index: AcaPBrPw04kMBRlBTqS6UnZQg3W/egAAhngAAA6q6nAAI+Rq8AAU1qMQABiLRSA= From: "Curtis Provost" To: "Avi Lior" , "Kent Leung \(kleung\)" , "Pete McCann" , "Mobile IPv4 Mailing List" X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Avi, Can you clarify why you would allow embedded null characters but not a null terminator?=20 My only points were a) it doesn't make sense to explicitly disallow only a single character, and b) while providing guidance for what the string should contain might be reasonable, it doesn't make sense disallow any character.=20 The text I provided was intended to explicitly NOT disallow inclusion of anything, but to be clear that an implementation would have to deal with characters that are not typically readable. Hence, any special handling for embedded or terminating nulls or other control characters would be an implementation detail and not subject to specification. As Henrik stated in his email, and I agree, if we explicitly disallow a terminating null, then we have to define the behavior if a string is null terminated.=20 Curtis -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Wednesday, June 14, 2006 10:07 PM To: Provost, Curtis [RICH1:2H10:EXCH]; Kent Leung (kleung); Pete McCann; Mobile IPv4 Mailing List Cc: Henrik Levkowetz Subject: RE: [Mip4] Working Group Last Callondraft-ietf-mip4-message-string-ext-00.txt Curtis, I am not excluding NULL, in fact I am allowing an embedded null. I am just saying the string should not be terminated. Your text does not address the termination part. I think we either need to say that this is terminated or non-terminated. We need to be clear about this. This is important. This could lead to very bad programming errors. Also your text is a MUST for human readable yet I don't think we need to be that ridgid. The current text say is is intended to be human readable which is totally different to what you are saying. Anyway there is precedence for this: I am just borrowing from RADIUS RFC 2865....This seems to be also the definition in Diameter. In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [7] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. text 1-253 octets containing UTF-8 encoded 10646 [7] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead. =20 > -----Original Message----- > From: Curtis Provost [mailto:cprovost@nortel.com]=20 > Sent: Wednesday, June 14, 2006 1:06 PM > To: Kent Leung (kleung); Avi Lior; Pete McCann; Mobile IPv4=20 > Mailing List > Cc: Henrik Levkowetz > Subject: RE: [Mip4] Working Group Last=20 > Callondraft-ietf-mip4-message-string-ext-00.txt >=20 > I'm not convinced that I agree. I think it may be more=20 > appropriate to have a general statement saying that only=20 > human-readable characters may be included in the text field,=20 > but to exclude only the null terminator seems too narrow.=20 >=20 >=20 > Perhaps something like: >=20 > The implementation dependent Text field is one or more=20 > octets, and SHOULD NOT contain non human readable characters;=20 > e.g. it should not be null terminated. It is intended to be=20 > human readable, and MUST NOT affect operation of the=20 > protocol. It is recommended that the message contain UTF-8=20 > encoded 10646 [RFC2279] characters. >=20 >=20 >=20 > Curtis >=20 > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Tuesday, June 13, 2006 10:27 PM > To: Avi Lior; Pete McCann; Mobile IPv4 Mailing List > Cc: Henrik Levkowetz > Subject: RE: [Mip4] Working Group Last > Callondraft-ietf-mip4-message-string-ext-00.txt >=20 > Hi Avi. This is a good clarification. Thanks. >=20 > Kent=20 >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Tuesday, June 13, 2006 9:55 AM > > To: Pete McCann; Mobile IPv4 Mailing List > > Cc: Henrik Levkowetz > > Subject: RE: [Mip4] Working Group Last=20 > > Callondraft-ietf-mip4-message-string-ext-00.txt > >=20 > > "I support the advancement of this document to the IESG=20 > with a request=20 > > for publication as proposed standard." > >=20 > > I have the following technical comment. The text field=20 > should not be=20 > > null terminated. > >=20 > > From: > >=20 > > The Text field is one or more octets, and its contents are > > implementation dependent. It is intended to be human=20 > readable, > > and MUST NOT affect operation of the protocol. It is=20 > > recommended > > that the message contain UTF-8 encoded 10646 [RFC2279]=20 > > characters. > >=20 > > To: > > The implementation dependent Text field is one or more octets, and=20 > > must not be NUL (hex 00) terminated. It is intended to be human=20 > > readable, > > and MUST NOT affect operation of the protocol. It is=20 > > recommended > > that the message contain UTF-8 encoded 10646 [RFC2279]=20 > > characters. > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Pete McCann [mailto:mccap@lucent.com] > > > Sent: Tuesday, June 13, 2006 12:30 PM > > > To: Mobile IPv4 Mailing List > > > Cc: Henrik Levkowetz > > > Subject: [Mip4] Working Group Last Call=20 > > > ondraft-ietf-mip4-message-string-ext-00.txt > > >=20 > > > This message announces a WG last call on: > > >=20 > > > "Mobile IPv4 Message String Extension" > > > - draft-ietf-mip4-message-string-ext-00 > > >=20 > > > The last call will conclude at 24:00 UTC on Tuesday, 27 June 2006. > > >=20 > > > draft-ietf-mip4-message-string-ext-00 describes a new Mobile > > > IPv4 extension to carry a user-readable result string with > > Mobile IPv4 > > > Registration Replies. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > > > > tring-ext-00.txt> > > >=20 > > >=20 > > > Please respond to this WG last call: > > >=20 > > > * If you have no comments on the draft, and support its=20 > advancement, > > > simply respond with a line containing something like > > >=20 > > > "I support the advancement of this document to the IESG with a > > > request for publication as proposed standard." > > >=20 > > > If you have comments, please use a line similar to the > > one above, > > > and > > > supplement this with your comments. > > >=20 > > >=20 > > > * If you *don't* support its advancement, respond with a line=20 > > > containing > > > something like the following, supplemented by your comments - > > >=20 > > > "I don't support the advancement of this document to > > the IESG with > > > a request for publication as proposed standard, for > > the following > > > reasons:" > > > ... > > >=20 > > >=20 > > > Pete & Henrik > > >=20 > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page:=20 > > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > >=20 > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 15 22:17:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3tV-0002uU-MK; Thu, 15 Jun 2006 22:17:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3tU-0002uJ-I9 for mip4@ietf.org; Thu, 15 Jun 2006 22:17:08 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3tS-0004cK-O7 for mip4@ietf.org; Thu, 15 Jun 2006 22:17:08 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0X002G1L1L5T@szxga01-in.huawei.com> for mip4@ietf.org; Fri, 16 Jun 2006 10:17:46 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J0X00DPVL1LMW@szxga01-in.huawei.com> for mip4@ietf.org; Fri, 16 Jun 2006 10:17:45 +0800 (CST) Received: from w50392 ([10.164.45.173]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0X00LIZLGPQP@szxml04-in.huawei.com> for mip4@ietf.org; Fri, 16 Jun 2006 10:26:50 +0800 (CST) Date: Fri, 16 Jun 2006 10:16:11 +0800 From: Tom Wan To: mip4@ietf.org Message-id: <01bf01c690ea$d69b8060$6e2ea40a@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 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Subject: [Mip4] [Mip6] Mip6] request comments on a new individual draft X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2022036968==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============2022036968== Content-type: multipart/alternative; boundary="Boundary_(ID_icRdbFZub65wYBT9BnEKpw)" This is a multi-part message in MIME format. --Boundary_(ID_icRdbFZub65wYBT9BnEKpw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi,folks: I have submitted a new individual draft. Abstract The current Mobile IPv6 and NEMO specification supports only IPv6. As an extension, the DSMip6 protocol [v4traversal]defines how the dual-stack mobile node roams in the ipv4 network. The dsmip6 protocol assumes that both home agent and mobile node supports mipv4 and mipv6 protocol. It also assumes that both the home agent and mobile node have a configured ipv4 address. These assumptions do work during many scenarios. However, as the ipv4 address is a scarce resource in many counrties, some mobile nodes may not be able to get configured ipv4 home addresses from their home agents. In this scenario, a temporary ipv4 home address is more useful. This document will focuse on this scenario. Would you mind give me some comments?Your comments are much appreciated. http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-routing-00.txt BR Tom --Boundary_(ID_icRdbFZub65wYBT9BnEKpw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi,folks:
I have submitted a new individual draft.
 
Abstract

   The current Mobile IPv6 and NEMO specification supports only IPv6.
   As an extension, the DSMip6 protocol [v4traversal]defines how the
   dual-stack mobile node roams in the ipv4 network.  The dsmip6
   protocol assumes that both home agent and mobile node supports mipv4
   and mipv6 protocol.  It also assumes that both the home agent and
   mobile node have a configured ipv4 address.  These assumptions do
   work during many scenarios.  However, as the ipv4 address is a scarce
   resource in many counrties, some mobile nodes may not be able to get
   configured ipv4 home addresses from their home agents.  In this
   scenario, a temporary ipv4 home address is more useful.  This
   document will focuse on this scenario.
 
Would you mind give me some comments?Your comments are much appreciated.
 
BR
Tom
 
 
 
 
--Boundary_(ID_icRdbFZub65wYBT9BnEKpw)-- --===============2022036968== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2022036968==-- From mip4-bounces@ietf.org Thu Jun 15 22:18:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3uZ-0003aQ-2z; Thu, 15 Jun 2006 22:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fr3uY-0003aG-J9 for mip4@ietf.org; Thu, 15 Jun 2006 22:18:14 -0400 Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fr3uW-0004hZ-Pt for mip4@ietf.org; Thu, 15 Jun 2006 22:18:14 -0400 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 <0J0X0030ALR77H@szxga02-in.huawei.com> for mip4@ietf.org; Fri, 16 Jun 2006 10:33:07 +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 <0J0X00K9VLR7UB@szxga02-in.huawei.com> for mip4@ietf.org; Fri, 16 Jun 2006 10:33:07 +0800 (CST) Received: from w50392 ([10.164.45.173]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J0X00LOLLIHQP@szxml04-in.huawei.com> for mip4@ietf.org; Fri, 16 Jun 2006 10:27:54 +0800 (CST) Date: Fri, 16 Jun 2006 10:17:16 +0800 From: Tom Wan Subject: [mip4]new draft of ds ps: draft-wan-mip6-nemo-dsanalysis-00.txtrequest for comment To: mip4@ietf.org Message-id: <01df01c690ea$fce26400$6e2ea40a@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 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1543990399==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1543990399== Content-type: multipart/alternative; boundary="Boundary_(ID_BNsZxHtREpcHuIx49ahPQw)" This is a multi-part message in MIME format. --Boundary_(ID_BNsZxHtREpcHuIx49ahPQw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi, folks: I have written a draft on the ds problem statement.please review it and give me comments.Your comments are appreciated. Abstract The purpose of this document is to investigate the motivations for mobile entities using dual stacks and the scenarios of mobile entities with dual-stacks roaming in the ipv4 or ipv6 network. This document also discusses the problems to be solved during these scenarios. I am sorry for sending this message again, because I forgot to attach the link address in the former mail. http://www.ietf.org/internet-drafts/draft-wan-mip6-nemo-dsanalysis-00.txt BR Tom --Boundary_(ID_BNsZxHtREpcHuIx49ahPQw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi, folks:
I have written a draft on the ds problem statement.please review it and give me comments.Your comments are appreciated.
 
Abstract

   The purpose of this document is to investigate the motivations for
   mobile entities using dual stacks and the scenarios of mobile
   entities with dual-stacks roaming in the ipv4 or ipv6 network.  This
   document also discusses the problems to be solved during these
   scenarios.
 
I am sorry for sending this message again, because I forgot to attach the link address in the former mail.

 
 
BR
Tom
 
--Boundary_(ID_BNsZxHtREpcHuIx49ahPQw)-- --===============1543990399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1543990399==-- From mip4-bounces@ietf.org Fri Jun 16 08:34:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDWv-0005eP-58; Fri, 16 Jun 2006 08:34:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDWu-0005eK-4E for mip4@ietf.org; Fri, 16 Jun 2006 08:34:28 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrDWs-0000cV-Io for mip4@ietf.org; Fri, 16 Jun 2006 08:34:28 -0400 Received: from YSHEFFER (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k5GCYJNH028442; Fri, 16 Jun 2006 15:34:25 +0300 (IDT) Message-Id: <200606161234.k5GCYJNH028442@michael.checkpoint.com> Date: Fri, 16 Jun 2006 15:34:19 +0300 From: Yaron Sheffer To: mobike@machshav.com, mip4@ietf.org MIME-Version: 1.0 X-Mailer: Sun Outlook Connector 7.1.228.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: Subject: [Mip4] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi All, This individual submission may be of interest to both the MOBIKE and Mobile= IPv4 groups. Your comments are very welcome. Thanks, =09Yaron=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Thursday, June 15, 2006 22:50 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =09Title=09=09: Secure Beacon: Securely Detecting a Trusted Network =09Author(s)=09: Y. Sheffer =09Filename=09: draft-sheffer-ipsec-secure-beacon-00.txt =09Pages=09=09: 15 =09Date=09=09: 2006-6-15 =09 Remote access clients, in particular IPsec-based ones, are heavily deployed= in enterprise environments. In many enterprises the security policy allow= s remote-access clients to switch to unprotected operation when entering th= e trusted network. This document specifies a method that lets a client det= ect this situation in a secure manner, with the help of a security gateway.= We propose a minor extension to IKEv2 to achieve this goal. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-secure-beacon-00.tx= t To remove yourself from the I-D Announcement list, send a message to i-d-an= nounce-request@ietf.org with the word unsubscribe in the body of the messag= e. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type= "cd internet-drafts" and then =09"get draft-sheffer-ipsec-secure-beacon-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/s= hadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: =09mailserv@ietf.org. In the body type: =09"FILE /internet-drafts/draft-sheffer-ipsec-secure-beacon-00.txt". =09 NOTE:=09The mail server at ietf.org can return the document in =09MIME-encoded form by using the "mpack" utility. To use this =09feature, insert the command "ENCODING mime" before the "FILE" =09command. To decode the response(s), you will need "munpack" or =09a MIME-compliant mail reader. Different MIME-compliant mail readers =09exhibit different behavior, especially when dealing with =09"multipart" MIME messages (i.e. documents which have been split =09up into multiple messages), so check your local documentation on =09how to manipulate these messages. =09=09 =09=09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 16 08:47:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDju-0005x1-3d; Fri, 16 Jun 2006 08:47:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fqmbx-0004VZ-8A for mip4@ietf.org; Thu, 15 Jun 2006 03:49:53 -0400 Received: from wx-out-0102.google.com ([66.249.82.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fqm1C-0003Uy-OR for mip4@ietf.org; Thu, 15 Jun 2006 03:11:55 -0400 Received: by wx-out-0102.google.com with SMTP id h26so253532wxd for ; Thu, 15 Jun 2006 00:11:54 -0700 (PDT) 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=EloIK6rDL7tcxOTFYhYXbb4KgO9bUNc0/DiM08cho96B2mVYL3PDLiWi4LlQezZS6AckKQD+i+GJbXlFm49wlKaIA3ElRMEbZY8qk2Y+t8bPBWu6uN6/1OD4ui9EKTdlbGbOjTZVa6XFUpnytVcTLAz/XBbJxFw20KQZyT7XToY= Received: by 10.70.63.1 with SMTP id l1mr1853170wxa; Thu, 15 Jun 2006 00:11:54 -0700 (PDT) Received: by 10.70.53.9 with HTTP; Thu, 15 Jun 2006 00:11:54 -0700 (PDT) Message-ID: Date: Thu, 15 Jun 2006 14:11:54 +0700 From: "Kuljaree Tantayakul" To: mip4@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-Mailman-Approved-At: Fri, 16 Jun 2006 08:47:53 -0400 Subject: [Mip4] Mobile IPv4 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2044844145==" Errors-To: mip4-bounces@ietf.org --===============2044844145== Content-Type: multipart/alternative; boundary="----=_Part_7700_26551177.1150355514288" ------=_Part_7700_26551177.1150355514288 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Dear Sir, My name is Kuljaree Tantayakul. I'm interesting about Mobile IPv4 but I don't know how to setup my network to support mobile IP and can uses it. Please suggest me about MIP software or website for finding the way. Thanks you for your times. Best Regards, Kuljaree ------=_Part_7700_26551177.1150355514288 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Dear Sir,
  My name is Kuljaree Tantayakul. I'm interesting about Mobile IPv4 but I don't know how to setup my network to support mobile IP and can uses it. Please suggest me about MIP software or website for finding the way.
 
Thanks you for your times.
Best Regards,
Kuljaree
------=_Part_7700_26551177.1150355514288-- --===============2044844145== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2044844145==-- From mip4-bounces@ietf.org Fri Jun 16 12:12:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGvz-0003iE-7b; Fri, 16 Jun 2006 12:12:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGve-0003gG-Pp for mip4@ietf.org; Fri, 16 Jun 2006 12:12:15 -0400 Received: from web60316.mail.yahoo.com ([209.73.178.124]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FrGvd-0002s1-Di for mip4@ietf.org; Fri, 16 Jun 2006 12:12:14 -0400 Received: (qmail 30803 invoked by uid 60001); 16 Jun 2006 16:12:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=u8FZVJUm23qNPCUZxxsuc1cq3FZ+NqxtqDS+5yKhGGl+49dXb1f15E+pZnz0BvKW43oVbj9+KnZI+C7O5kuc9wjoJwb3XH9acIaMz5E0o15iUFawvDKd27ui8I+mk5TLPFwAgETYVsxiEL2nCillOI3paEXkhEi+4Y5SVfMH2hQ= ; Message-ID: <20060616161213.30801.qmail@web60316.mail.yahoo.com> Received: from [12.129.211.52] by web60316.mail.yahoo.com via HTTP; Fri, 16 Jun 2006 09:12:13 PDT Date: Fri, 16 Jun 2006 09:12:13 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip4] Mobile IPv4 To: Kuljaree Tantayakul , mip4@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.9 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0746673221==" Errors-To: mip4-bounces@ietf.org --===============0746673221== Content-Type: multipart/alternative; boundary="0-588145486-1150474333=:30532" --0-588145486-1150474333=:30532 Content-Type: text/plain; charset=us-ascii ----- Original Message ---- From: Kuljaree Tantayakul To: mip4@ietf.org Sent: Thursday, June 15, 2006 2:11:54 AM Subject: [Mip4] Mobile IPv4 Dear Sir, My name is Kuljaree Tantayakul. I'm interesting about Mobile IPv4 but I don't know how to setup my network to support mobile IP and can uses it. Please suggest me about MIP software or website for finding the way. ==> Yes, please go to: ==> http://www.mip4.org/2004/implementations/ ==>Regards, ==>Behcet Thanks you for your times. Best Regards, Kuljaree -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --0-588145486-1150474333=:30532 Content-Type: text/html; charset=us-ascii


----- Original Message ----
From: Kuljaree Tantayakul <kuljaree@gmail.com>
To: mip4@ietf.org
Sent: Thursday, June 15, 2006 2:11:54 AM
Subject: [Mip4] Mobile IPv4

Dear Sir,
  My name is Kuljaree Tantayakul. I'm interesting about Mobile IPv4 but I don't know how to setup my network to support mobile IP and can uses it. Please suggest me about MIP software or website for finding the way.
 
==> Yes, please go to:
==> http://www.mip4.org/2004/implementations/
==>Regards,
==>Behcet
Thanks you for your times.
Best Regards,
Kuljaree
--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

--0-588145486-1150474333=:30532-- --===============0746673221== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0746673221==-- From mip4-bounces@ietf.org Fri Jun 16 15:50:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKKT-0007ZV-Ss; Fri, 16 Jun 2006 15:50:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrKKQ-0007Xw-NG; Fri, 16 Jun 2006 15:50:02 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrKKQ-0000ei-Cu; Fri, 16 Jun 2006 15:50:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k5GJo2Rx030929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FrKKQ-0004rz-33; Fri, 16 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 16 Jun 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: mip4@ietf.org Subject: [Mip4] I-D ACTION:draft-ietf-mip4-rfc2006bis-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv4 Working Group of the IETF. Title : The Definitions of Managed Objects for IP Mobility Support using SMIv2, revised Author(s) : R. Rathi, et al. Filename : draft-ietf-mip4-rfc2006bis-02.txt Pages : 111 Date : 2006-6-16 This memo defines the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it describes managed objects used for managing the Mobile Node, Foreign Agent and Home Agent of the Mobile IP Protocol. This memo is intended to update and possibly obsolete RFC 2006, however, it is designed to be backward compatible A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip4-rfc2006bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mip4-rfc2006bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mip4-rfc2006bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-16140125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip4-rfc2006bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip4-rfc2006bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-16140125.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --NextPart-- From mip4-bounces@ietf.org Sun Jun 18 19:59:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fs7BK-00012W-La; Sun, 18 Jun 2006 19:59:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrGGW-0001Gz-Qk for mip4@ietf.org; Fri, 16 Jun 2006 11:29:44 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrGGV-00072a-Ex for mip4@ietf.org; Fri, 16 Jun 2006 11:29:44 -0400 Received: from [10.20.30.249] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5GFTYk4011209; Fri, 16 Jun 2006 08:29:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200606161234.k5GCYJNH028442@michael.checkpoint.com> References: <200606161234.k5GCYJNH028442@michael.checkpoint.com> Date: Fri, 16 Jun 2006 08:29:32 -0700 To: Yaron Sheffer , mobike@machshav.com, mip4@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Sun, 18 Jun 2006 19:59:53 -0400 Cc: Subject: [Mip4] Re: [Mobike] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org At 3:34 PM +0300 6/16/06, Yaron Sheffer wrote: >Hi All, > >This individual submission may be of interest to both the MOBIKE and >Mobile IPv4 groups. Your comments are very welcome. Inasmuch as the MOBIKE mailing list is pretty dead (and may be shut off after the final WG document becomes an RFC), it would be better to have the discussion of this draft on a different mailing list. Yaron already posted this to the IPsec mailing list, which will be long-lived; it is better to discuss it there (and the MIP4 mailing list, if so desired). --Paul Hoffman, Director --VPN Consortium -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 19 04:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFWI-0007tv-Pu; Mon, 19 Jun 2006 04:54:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsFWG-0007tq-Nk for mip4@ietf.org; Mon, 19 Jun 2006 04:54:04 -0400 Received: from 213.80.52.78.dataphone.se ([213.80.52.78] helo=mailgw.local.ipunplugged.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsFWE-0007fR-G0 for mip4@ietf.org; Mon, 19 Jun 2006 04:54:04 -0400 Received: from [127.0.0.1] (c32.local.ipunplugged.com [192.168.4.231]) by mailgw.local.ipunplugged.com (8.12.8/8.12.3) with ESMTP id k5J8ru5C024993 for ; Mon, 19 Jun 2006 10:53:59 +0200 Message-ID: <44966624.4040307@ipunplugged.com> Date: Mon, 19 Jun 2006 10:53:56 +0200 From: Hans Sjostrand User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: mip4@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on mailgw.local.ipunplugged.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Mip4] Fwd: I-D ACTION:draft-sjostrand-mip4-udptunnel-mib-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org In the work to get a update on the MIP MIB it was apparent that there where no objects for management of RFC3519. It was decided in the editing group to create a separate mib module for these objects, instead of extending the MIP-MIB itself. The initial version of this is draft-sjostrand-mip4-udptunnel-mib-00 It would be very good if the WG adopted this as a work group document to go hand in hand with 2006bis. A five minute slot on the Montreal agenda to take that discussion would be nice. Best regards /// Hasse Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : The Definitions of Managed Objects for Mobile IP UDP Tunneling > Author(s) : H. Sjostrand > Filename : draft-sjostrand-mip4-udptunnel-mib-00.txt > Pages : 13 > Date : 2006-6-16 > > This memo defines the Management Information Base (MIB) for use with > network management protocols in TCP/IP-based internets. In > particular, it describes managed objects used for managing the Mobile > Node, Foreign Agent and Home Agent when Mobile IP Traversal of > Network Address Translation (NAT) Devices are used. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-sjostrand-mip4-udptunnel-mib-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-sjostrand-mip4-udptunnel-mib-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-sjostrand-mip4-udptunnel-mib-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 19 19:43:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTOj-0000y7-3P; Mon, 19 Jun 2006 19:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsTOi-0000y2-CX for mip4@ietf.org; Mon, 19 Jun 2006 19:43:12 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsTOg-0002GJ-NH for mip4@ietf.org; Mon, 19 Jun 2006 19:43:12 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 19 Jun 2006 16:43:09 -0700 X-IronPort-AV: i="4.06,153,1149490800"; d="scan'208,217"; a="297452000:sNHT85618344" 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/8.12.11) with ESMTP id k5JNh9o6010051 for ; Mon, 19 Jun 2006 16:43:09 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5JNh9CU024247 for ; Mon, 19 Jun 2006 16:43:09 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 19 Jun 2006 16:43:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 19 Jun 2006 16:43:07 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201FFCE2C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Incorrect destination IP address in RRP? Thread-Index: AcaT+h3I0lP3NehNQHKJ7hUDhnaVDQ== From: "Kent Leung \(kleung\)" To: "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 19 Jun 2006 23:43:09.0498 (UTC) FILETIME=[1ED461A0:01C693FA] DKIM-Signature: a=rsa-sha1; q=dns; l=7682; t=1150760589; x=1151624589; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:Incorrect=20destination=20IP=20address=20in=20RRP?; X=v=3Dcisco.com=3B=20h=3DiIQe4gkbzTfY4i74uZZMMj1N9Fc=3D; b=XB5HMjhZGSVcAbsiM+VU8g28dctM2JPLZAvj9fZ1i9Mgt93QEslUvlKi34FA8kxKsEc6aXrJ fTaMQYIRGPvKaxWFo00aRZ5H4/dY1DwoPooOOKrUXNB8qERmDDfgj6cI; Authentication-Results: sj-dkim-1.cisco.com; header.From=kleung@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Subject: [Mip4] Incorrect destination IP address in RRP? X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1060738880==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1060738880== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C693FA.1ED44FD0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C693FA.1ED44FD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi. I think the IP Destination Address of the RRP cannot be set to the Home Address field of the RRP as stated in this section. In the case where RRQ contains the Home Address set to 0.0.0.0, and HA responds with a non-zero Home Address field in the RRP, the IP Destination Address of the RRP from FA should be set to 255.255.255.255. At that point of receiving the RRP, MN is not aware of its Home Address yet. I notice the same text in 3344bis and RFC 3344. =20 =20 Section 3.7.2.3: IP Destination Address If the Registration Reply is generated by the Foreign Agent in order to reject a mobile node's Registration Request, and the Registration Request contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Request. Otherwise, if the Registration Reply is received from the Home Agent, and contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Reply. Otherwise, the IP Destination Address of the Registration Reply is set to be 255.255.255.255.=20 Suggested text: IP Destination Address If the Registration Reply is generated by the Foreign Agent in order to reject a mobile node's Registration Request, and the Registration Request contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Request. Otherwise, if the Registration Reply is received from the Home Agent, and the Registration Request contains a Home Address which is not 0.0.0.0, then the IP Destination Address is copied from the Home Address field of the Registration Reply. Otherwise, the IP Destination Address of the Registration Reply is set to be 255.255.255.255.=20 Kent -- | | Kent Leung :|: :|: IP Mobility Development :|||: :|||: Internet Technologies Division :|||||||: :|||||||: Voice: +1.408.526.5030 .:|||||||||:.:|||||||||:. Email: kleung@cisco.com =20 c i s c o S y s t e m s http://safari.ciscopress.com/?XmlId=3D1-58705-132-X =20 =20 ------_=_NextPart_001_01C693FA.1ED44FD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi.  I think=20 the IP Destination Address of the RRP cannot be set to the Home Address = field of=20 the RRP as stated in this section.  In the case where RRQ contains = the Home=20 Address set to 0.0.0.0, and HA responds with a non-zero Home Address = field in=20 the RRP, the IP Destination Address of the RRP from FA should be set to=20 255.255.255.255.  At that point of receiving the RRP, MN is not = aware of=20 its Home Address yet.  I notice the same text in 3344bis and RFC=20 3344.
 
 
Section =
3.7.2.3:
      IP =
Destination Address

               If the Registration Reply is generated by the Foreign
               Agent in order to reject a mobile node's Registration
               Request, and the Registration Request contains a Home
               Address which is not 0.0.0.0, then the IP Destination
               Address is copied from the Home Address field of the
               Registration Request.  Otherwise, if the Registration
               Reply is received from the Home Agent, and contains a
               Home Address which is not 0.0.0.0, then the IP
               Destination Address is copied from the Home Address field
               of the Registration Reply.  Otherwise, the IP Destination
               Address of the Registration Reply is set to be
               255.255.255.255. 
Suggested =
text:
     IP Destination Address

               If the Registration Reply is generated by the Foreign
               Agent in order to reject a mobile node's Registration
               Request, and the Registration Request contains a Home
               Address which is not 0.0.0.0, then the IP Destination
               Address is copied from the Home Address field of the
               Registration Request.  Otherwise, if the Registration
               Reply is received from the Home Agent, and the =
Registration Request contains a
               Home Address which is not 0.0.0.0, then the IP
               Destination Address is copied from the Home Address field
               of the Registration Reply.  Otherwise, the IP Destination
               Address of the Registration Reply is set to be
               255.255.255.255. 

Kent

--
    =20 |        =20 |            =       =20 Kent Leung
    :|:       = :|:           &nbs= p;     =20 IP Mobility Development
   :|||:     =20 :|||:           &n= bsp;    =20 Internet Technologies Division
  :|||||||: =20 :|||||||:         =20       Voice:=20 +1.408.526.5030
.:|||||||||:.:|||||||||:.    =20          Email: kleung@cisco.com
c i = s c o S y s t=20 e m s  http://safari.ciscopress.com/?XmlId=3D1-58705-132-X

 
------_=_NextPart_001_01C693FA.1ED44FD0-- --===============1060738880== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1060738880==-- From mip4-bounces@ietf.org Wed Jun 21 11:13:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4OI-0008My-IP; Wed, 21 Jun 2006 11:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft4OI-0008Lp-4Q for mip4@ietf.org; Wed, 21 Jun 2006 11:13:14 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft4OG-0007AK-SI for mip4@ietf.org; Wed, 21 Jun 2006 11:13:14 -0400 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, 21 Jun 2006 11:13:24 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85w== From: "Avi Lior" To: "Mobile IPv4 Mailing List" X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, =20 While working a scenario in WiMAX I have run into some ambiguity in RFC3344. =20 The HA receives a Reg Request with MN-HA-AE and NAI extension which it fails to authenticate. In particular=20 the HA cant authenticate because it can't obtain the MN-HA from the AAA using the NAI. =20 >From section 3.8.2.1 RFC3344 states that a Registration Reply should be sent with code 131. "if the Authenticator is invalid, the home agent MUST reject=20 the mobile node's registration and SHOULD send a Registration=20 Reply to the mobile node with Code 131" And from section 3.6.2.1 describing the MN behavior we have: =20 "If the Code field indicates an authentication failure, either at the foreign agent or the home agent, then it is quite possible that any authenticators in the Registration Reply will also be in error. This could happen, for example, if the shared secret between the mobile node and home agent was erroneously configured. The mobile node SHOULD log such errors as security exceptions." =20 RFC3344 also states that Registration Reply MUST include a MN-HA authentication extension: =20 Section 3.8.3.3 says " Note that items (a) and (c) MUST appear in every Registration Reply sent by the home agent." =20 where (c) is The Mobile-Home Authentication Extension. =20 The problem is that when MN-HA-AE fails at the HA there isnt an available MN-HA authentication extension to use. So how can one send a registration reply? Furthermore, if the HA cant not obtain an MN-HA for the mobile, what should happen? Any help will be appreciated. =20 =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Avi Lior =20 Bridgewater Systems Corporation=20 Phone : +1 (613) 591-9104 x6417 Cell : +1 (613) 796-4183 E-mail : mailto:avi@bridgewatersystems.com =20 www.bridgewatersystems.com =20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 12:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5uf-0000Qr-PV; Wed, 21 Jun 2006 12:50:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft5ue-0000K5-B8 for mip4@ietf.org; Wed, 21 Jun 2006 12:50:44 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft5nc-0000V1-FB for mip4@ietf.org; Wed, 21 Jun 2006 12:43:29 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 21 Jun 2006 09:43:28 -0700 X-IronPort-AV: i="4.06,162,1149490800"; d="scan'208"; a="1829979907:sNHT32610404" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id k5LGhR39025489; Wed, 21 Jun 2006 09:43:27 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k5LGhQcL003452; Wed, 21 Jun 2006 09:43:27 -0700 (PDT) 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.211); Wed, 21 Jun 2006 09:43:26 -0700 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 09:43:25 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202061F1B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWg From: "Kent Leung \(kleung\)" To: "Avi Lior" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 21 Jun 2006 16:43:26.0641 (UTC) FILETIME=[D180DA10:01C69551] DKIM-Signature: a=rsa-sha1; q=dns; l=2984; t=1150908207; x=1151772207; c=relaxed/simple; s=sjdkim8001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=203344=20Sending=20a=20Reg=20Reply=20when=20the=20Authent icator=20fails; X=v=3Dcisco.com=3B=20h=3DOffBF2QDuGm/mTFCreg6jJ5NNKI=3D; b=Zptc7W4DdpFrqAJyQP7HRe+DaCEpfbqnO0fxlS97BSWZ2A0HxJcmHkSKvSRSyRbd362JsdfX hIQk7nasX8h1Niaf59KSQw/iFcCXkX8V/YjLrePevBSv8IdlyclXdfGv; Authentication-Results: sj-dkim-8.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Avi. My understanding is that in this case, the HA will not be able to send an RRP if it does not have an SA with the MN because this message requires MN-HA AE. The text state that if HA has an SA, then to use that in the RRP. Without an SA, the HA should drop the RRQ, IMHO. =20 Kent=20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Wednesday, June 21, 2006 8:13 AM > To: Mobile IPv4 Mailing List > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi, > =20 > While working a scenario in WiMAX I have run into some=20 > ambiguity in RFC3344. > =20 > The HA receives a Reg Request with MN-HA-AE and NAI extension=20 > which it fails to authenticate. In particular the HA cant=20 > authenticate because it can't obtain the MN-HA from the AAA=20 > using the NAI. > =20 > >From section 3.8.2.1 RFC3344 states that a Registration=20 > Reply should be > sent with code 131. >=20 > "if the Authenticator is invalid, the home agent MUST reject=20 > the mobile node's registration and SHOULD send a Registration=20 > Reply to the mobile node with Code 131" >=20 > And from section 3.6.2.1 describing the MN behavior we have: > =20 > "If the Code field indicates an authentication failure,=20 > either at the > foreign agent or the home agent, then it is quite possible that any > authenticators in the Registration Reply will also be in=20 > error. This > could happen, for example, if the shared secret between the mobile > node and home agent was erroneously configured. The mobile node > SHOULD log such errors as security exceptions." > =20 > RFC3344 also states that Registration Reply MUST include a=20 > MN-HA authentication extension: > =20 > Section 3.8.3.3 says " Note that items (a) and (c) MUST=20 > appear in every Registration Reply sent by the home agent." > =20 > where (c) is The Mobile-Home Authentication Extension. > =20 > The problem is that when MN-HA-AE fails at the HA there isnt=20 > an available MN-HA authentication extension to use. So how=20 > can one send a registration reply? >=20 > Furthermore, if the HA cant not obtain an MN-HA for the=20 > mobile, what should happen? >=20 >=20 > Any help will be appreciated. >=20 >=20 > =20 > =20 > =20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Avi Lior =20 > Bridgewater Systems Corporation > Phone : +1 (613) 591-9104 x6417 > Cell : +1 (613) 796-4183 > E-mail : mailto:avi@bridgewatersystems.com=20 > > www.bridgewatersystems.com =20 >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 13:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6Bc-0005Pi-TE; Wed, 21 Jun 2006 13:08:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6Bc-0005MG-3j for mip4@ietf.org; Wed, 21 Jun 2006 13:08:16 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6BZ-0002of-GG for mip4@ietf.org; Wed, 21 Jun 2006 13:08:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 555B490012 for ; Wed, 21 Jun 2006 13:08:09 -0400 (EDT) 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 20453-03 for ; Wed, 21 Jun 2006 13:08:08 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 21 Jun 2006 13:08:08 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jun 2006 13:05:10 -0400 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 13:05:10 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51B7@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWgAADMYBA= From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" , "Avi Lior" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 21 Jun 2006 17:05:10.0535 (UTC) FILETIME=[DAAF4970:01C69554] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Kent/Avi, The current text does not say that the HA cannot send RRP when auth fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > if the Authenticator is invalid, the home agent MUST reject the=20 > mobile node's registration and SHOULD send a Registration Reply to the > mobile node with Code 131" What we need is a proper description of the HA and the MN behaviors when the auth fails and the HA needs to send a RRP to stop the MN from re-trying unnecessarily.=20 The clarification could be:=20 If the Authenticator is invalid, the home agent MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 131. In this case, the HA populates the MN-HA AE with all 0s. Upon receiving the RRP with error code 131, the MN skips MN-HA AE validation and stops retrying registration attempts. The MN MAY log this event in its internal log. What do you think? -Kuntal > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Wednesday, June 21, 2006 11:43 AM > To: Avi Lior; Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi Avi. My understanding is that in this case, the HA will not be able > to send an RRP if it does not have an SA with the MN because this > message requires MN-HA AE. The text state that if HA has an SA, then to > use that in the RRP. Without an SA, the HA should drop the RRQ, IMHO. >=20 > Kent >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Wednesday, June 21, 2006 8:13 AM > > To: Mobile IPv4 Mailing List > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails > > > > Hi, > > > > While working a scenario in WiMAX I have run into some > > ambiguity in RFC3344. > > > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > which it fails to authenticate. In particular the HA cant > > authenticate because it can't obtain the MN-HA from the AAA > > using the NAI. > > > > >From section 3.8.2.1 RFC3344 states that a Registration > > Reply should be > > sent with code 131. > > > > "if the Authenticator is invalid, the home agent MUST reject > > the mobile node's registration and SHOULD send a Registration > > Reply to the mobile node with Code 131" > > > > And from section 3.6.2.1 describing the MN behavior we have: > > > > "If the Code field indicates an authentication failure, > > either at the > > foreign agent or the home agent, then it is quite possible that any > > authenticators in the Registration Reply will also be in > > error. This > > could happen, for example, if the shared secret between the mobile > > node and home agent was erroneously configured. The mobile node > > SHOULD log such errors as security exceptions." > > > > RFC3344 also states that Registration Reply MUST include a > > MN-HA authentication extension: > > > > Section 3.8.3.3 says " Note that items (a) and (c) MUST > > appear in every Registration Reply sent by the home agent." > > > > where (c) is The Mobile-Home Authentication Extension. > > > > The problem is that when MN-HA-AE fails at the HA there isnt > > an available MN-HA authentication extension to use. So how > > can one send a registration reply? > > > > Furthermore, if the HA cant not obtain an MN-HA for the > > mobile, what should happen? > > > > > > Any help will be appreciated. > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Avi Lior > > Bridgewater Systems Corporation > > Phone : +1 (613) 591-9104 x6417 > > Cell : +1 (613) 796-4183 > > E-mail : mailto:avi@bridgewatersystems.com > > > > www.bridgewatersystems.com > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 13:13:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6Ge-0007Yt-MF; Wed, 21 Jun 2006 13:13:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6Gd-0007Yo-KX for mip4@ietf.org; Wed, 21 Jun 2006 13:13:27 -0400 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 1Ft6Gc-0003A8-1D for mip4@ietf.org; Wed, 21 Jun 2006 13:13:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 21 Jun 2006 10:13:24 -0700 X-IronPort-AV: i="4.06,162,1149490800"; d="scan'208"; a="431110912:sNHT34525148" 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/8.12.11) with ESMTP id k5LHDPxb008969; Wed, 21 Jun 2006 10:13:25 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5LHDPCU009499; Wed, 21 Jun 2006 10:13:25 -0700 (PDT) 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.211); Wed, 21 Jun 2006 10:13:25 -0700 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 10:13:24 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202061F78@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWgAADMYBAAAGxr0A== From: "Kent Leung \(kleung\)" To: "Chowdhury, Kuntal" , "Avi Lior" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 21 Jun 2006 17:13:25.0102 (UTC) FILETIME=[017838E0:01C69556] DKIM-Signature: a=rsa-sha1; q=dns; l=6012; t=1150910005; x=1151774005; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=203344=20Sending=20a=20Reg=20Reply=20when=20the=20Authent icator=20fails; X=v=3Dcisco.com=3B=20h=3DOffBF2QDuGm/mTFCreg6jJ5NNKI=3D; b=DVQFQVsXGYkRPUOA4RFQ2xeymJTWyL5PPNdeJpTsIjSYSpGXbkAnVQcxrktktwhuUIgjwnZK kxNuALHkcAe+f3sOUj8J+tG4bzrQJswWc8sKBJfKs/HUHn0peOsfDm6+; Authentication-Results: sj-dkim-3.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org If there is no SA, then I don't think HA should send a RRP.=20 Kent=20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Wednesday, June 21, 2006 10:05 AM > To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator fails >=20 > Kent/Avi, >=20 > The current text does not say that the HA cannot send RRP=20 > when auth fails. Rather it says that the HA "SHOULD" send RRP=20 > back to the MN: >=20 > > if the Authenticator is invalid, the home agent MUST reject=20 > the mobile=20 > > node's registration and SHOULD send a Registration Reply to the >=20 > > mobile node with Code 131" >=20 > What we need is a proper description of the HA and the MN=20 > behaviors when the auth fails and the HA needs to send a RRP=20 > to stop the MN from re-trying unnecessarily.=20 >=20 > The clarification could be:=20 >=20 > If the Authenticator is invalid, the home agent MUST reject=20 > the mobile node's registration and SHOULD send a Registration=20 > Reply to the mobile node with Code 131. In this case, the HA=20 > populates the MN-HA AE with all 0s. Upon receiving the RRP=20 > with error code 131, the MN skips MN-HA AE validation and=20 > stops retrying registration attempts. The MN MAY log this=20 > event in its internal log. >=20 > What do you think? >=20 > -Kuntal >=20 > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Wednesday, June 21, 2006 11:43 AM > > To: Avi Lior; Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > >=20 > > Hi Avi. My understanding is that in this case, the HA will not be > able > > to send an RRP if it does not have an SA with the MN because this=20 > > message requires MN-HA AE. The text state that if HA has=20 > an SA, then > to > > use that in the RRP. Without an SA, the HA should drop the=20 > RRQ, IMHO. > >=20 > > Kent > >=20 > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Wednesday, June 21, 2006 8:13 AM > > > To: Mobile IPv4 Mailing List > > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > > > Hi, > > > > > > While working a scenario in WiMAX I have run into some=20 > ambiguity in=20 > > > RFC3344. > > > > > > The HA receives a Reg Request with MN-HA-AE and NAI=20 > extension which=20 > > > it fails to authenticate. In particular the HA cant authenticate=20 > > > because it can't obtain the MN-HA from the AAA using the NAI. > > > > > > >From section 3.8.2.1 RFC3344 states that a Registration > > > Reply should be > > > sent with code 131. > > > > > > "if the Authenticator is invalid, the home agent MUST reject the=20 > > > mobile node's registration and SHOULD send a Registration=20 > Reply to=20 > > > the mobile node with Code 131" > > > > > > And from section 3.6.2.1 describing the MN behavior we have: > > > > > > "If the Code field indicates an authentication=20 > failure, either at=20 > > > the > > > foreign agent or the home agent, then it is quite possible that > any > > > authenticators in the Registration Reply will also be=20 > in error. =20 > > > This > > > could happen, for example, if the shared secret between the > mobile > > > node and home agent was erroneously configured. The=20 > mobile node > > > SHOULD log such errors as security exceptions." > > > > > > RFC3344 also states that Registration Reply MUST include a MN-HA=20 > > > authentication extension: > > > > > > Section 3.8.3.3 says " Note that items (a) and (c) MUST=20 > appear in=20 > > > every Registration Reply sent by the home agent." > > > > > > where (c) is The Mobile-Home Authentication Extension. > > > > > > The problem is that when MN-HA-AE fails at the HA there isnt an=20 > > > available MN-HA authentication extension to use. So how can one=20 > > > send a registration reply? > > > > > > Furthermore, if the HA cant not obtain an MN-HA for the=20 > mobile, what=20 > > > should happen? > > > > > > > > > Any help will be appreciated. > > > > > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Avi Lior > > > Bridgewater Systems Corporation > > > Phone : +1 (613) 591-9104 x6417 > > > Cell : +1 (613) 796-4183 > > > E-mail : mailto:avi@bridgewatersystems.com=20 > > > > > > www.bridgewatersystems.com > > > > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > >=20 > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page:=20 > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ >=20 >=20 > "This email message and any attachments are confidential=20 > information of Starent Networks, Corp. The information=20 > transmitted may not be used to create or change any=20 > contractual obligations of Starent Networks, Corp. Any=20 > review, retransmission, dissemination or other use of, or=20 > taking of any action in reliance upon this e-mail and its=20 > attachments by persons or entities other than the intended=20 > recipient is prohibited. If you are not the intended=20 > recipient, please notify the sender immediately -- by=20 > replying to this message or by sending an email to=20 > postmaster@starentnetworks.com -- and destroy all copies of=20 > this message and any attachments without reading or=20 > disclosing their contents. Thank you." >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 13:53:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6t0-0000Pr-Nn; Wed, 21 Jun 2006 13:53:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft6sz-0000Pj-9b for mip4@ietf.org; Wed, 21 Jun 2006 13:53:05 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft6sx-0007TX-QD for mip4@ietf.org; Wed, 21 Jun 2006 13:53:05 -0400 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 k5LHqvfk000552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 10:52:59 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LHqbhU000742; Wed, 21 Jun 2006 10:52:56 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 10:52:41 -0700 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 10:50:40 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FAAA@NAEX14.na.qualcomm.com> In-Reply-To: <7CCD07160348804497EF29E9EA5560D73C51B7@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWgAADMYBAAAYSc0A== From: "Tsirtsis, George" To: "Chowdhury, Kuntal" , "Kent Leung \(kleung\)" , "Avi Lior" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 21 Jun 2006 17:52:41.0309 (UTC) FILETIME=[7DE0E0D0:01C6955B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Usually it is not a good idea to be responding to messages that fail authentication because that can be used to mound DoS attacks. It is better to silently discard such messages. The RFC also talks about authorization-enabling extensions and it is a bit unclear on which extensions qualify for that. Most people think of the MN-HA Authenticator to be an authentication-enabling extension. Others think that the MN-AAA Authenticator or even an FA-HA authenticator could play this role in some scenarios. It would be nice not to loose this flexibility while clarifying the text. George > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Wednesday, June 21, 2006 1:05 PM > To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Kent/Avi, >=20 > The current text does not say that the HA cannot send RRP when auth > fails. Rather it says that the HA "SHOULD" send RRP back to the MN: >=20 > > if the Authenticator is invalid, the home agent MUST reject the > > mobile node's registration and SHOULD send a Registration Reply to the >=20 > > mobile node with Code 131" >=20 > What we need is a proper description of the HA and the MN behaviors when > the auth fails and the HA needs to send a RRP to stop the MN from > re-trying unnecessarily. >=20 > The clarification could be: >=20 > If the Authenticator is invalid, the home agent MUST reject the mobile > node's registration and SHOULD send a Registration Reply to the mobile > node with Code 131. In this case, the HA populates the MN-HA AE with all > 0s. Upon receiving the RRP with error code 131, the MN skips MN-HA AE > validation and stops retrying registration attempts. The MN MAY log this > event in its internal log. >=20 > What do you think? >=20 > -Kuntal >=20 > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Wednesday, June 21, 2006 11:43 AM > > To: Avi Lior; Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > Hi Avi. My understanding is that in this case, the HA will not be > able > > to send an RRP if it does not have an SA with the MN because this > > message requires MN-HA AE. The text state that if HA has an SA, then > to > > use that in the RRP. Without an SA, the HA should drop the RRQ, IMHO. > > > > Kent > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Wednesday, June 21, 2006 8:13 AM > > > To: Mobile IPv4 Mailing List > > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > > > Hi, > > > > > > While working a scenario in WiMAX I have run into some > > > ambiguity in RFC3344. > > > > > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > > which it fails to authenticate. In particular the HA cant > > > authenticate because it can't obtain the MN-HA from the AAA > > > using the NAI. > > > > > > >From section 3.8.2.1 RFC3344 states that a Registration > > > Reply should be > > > sent with code 131. > > > > > > "if the Authenticator is invalid, the home agent MUST reject > > > the mobile node's registration and SHOULD send a Registration > > > Reply to the mobile node with Code 131" > > > > > > And from section 3.6.2.1 describing the MN behavior we have: > > > > > > "If the Code field indicates an authentication failure, > > > either at the > > > foreign agent or the home agent, then it is quite possible that > any > > > authenticators in the Registration Reply will also be in > > > error. This > > > could happen, for example, if the shared secret between the > mobile > > > node and home agent was erroneously configured. The mobile node > > > SHOULD log such errors as security exceptions." > > > > > > RFC3344 also states that Registration Reply MUST include a > > > MN-HA authentication extension: > > > > > > Section 3.8.3.3 says " Note that items (a) and (c) MUST > > > appear in every Registration Reply sent by the home agent." > > > > > > where (c) is The Mobile-Home Authentication Extension. > > > > > > The problem is that when MN-HA-AE fails at the HA there isnt > > > an available MN-HA authentication extension to use. So how > > > can one send a registration reply? > > > > > > Furthermore, if the HA cant not obtain an MN-HA for the > > > mobile, what should happen? > > > > > > > > > Any help will be appreciated. > > > > > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Avi Lior > > > Bridgewater Systems Corporation > > > Phone : +1 (613) 591-9104 x6417 > > > Cell : +1 (613) 796-4183 > > > E-mail : mailto:avi@bridgewatersystems.com > > > > > > www.bridgewatersystems.com > > > > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 14:07:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft76f-0001QS-TL; Wed, 21 Jun 2006 14:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft76e-0001QN-Le for mip4@ietf.org; Wed, 21 Jun 2006 14:07:12 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft76d-0000TB-4i for mip4@ietf.org; Wed, 21 Jun 2006 14:07:12 -0400 Received: from [10.1.201.0] ([10.1.201.0]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 11:07:07 -0700 Message-ID: <44998A59.2000908@azairenet.com> Date: Wed, 21 Jun 2006 11:05:13 -0700 From: Vijay Devarapalli User-Agent: Debian Thunderbird 1.0.2 (X11/20060423) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avi Lior Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Jun 2006 18:07:07.0270 (UTC) FILETIME=[82080A60:01C6955D] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org if authentication fails, it is probably best to just silently discard the registration request. Vijay Avi Lior wrote: > Hi, > > While working a scenario in WiMAX I have run into some ambiguity in > RFC3344. > > The HA receives a Reg Request with MN-HA-AE and NAI extension which it > fails to authenticate. In particular > the HA cant authenticate because it can't obtain the MN-HA from the AAA > using the NAI. > >>From section 3.8.2.1 RFC3344 states that a Registration Reply should be > sent with code 131. > > "if the Authenticator is invalid, the home agent MUST reject > the mobile node's registration and SHOULD send a Registration > Reply to the mobile node with Code 131" > > And from section 3.6.2.1 describing the MN behavior we have: > > "If the Code field indicates an authentication failure, either at the > foreign agent or the home agent, then it is quite possible that any > authenticators in the Registration Reply will also be in error. This > could happen, for example, if the shared secret between the mobile > node and home agent was erroneously configured. The mobile node > SHOULD log such errors as security exceptions." > > RFC3344 also states that Registration Reply MUST include a MN-HA > authentication extension: > > Section 3.8.3.3 says " Note that items (a) and (c) MUST appear in every > Registration Reply sent by the home agent." > > where (c) is The Mobile-Home Authentication Extension. > > The problem is that when MN-HA-AE fails at the HA there isnt an > available MN-HA authentication extension to use. So how can one send a > registration reply? > > Furthermore, if the HA cant not obtain an MN-HA for the mobile, what > should happen? > > > Any help will be appreciated. > > > > > > > ======================== > > Avi Lior > Bridgewater Systems Corporation > Phone : +1 (613) 591-9104 x6417 > Cell : +1 (613) 796-4183 > E-mail : mailto:avi@bridgewatersystems.com > > www.bridgewatersystems.com > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 14:41:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7dh-0006RG-Q4; Wed, 21 Jun 2006 14:41:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft7dh-0006RB-3o for mip4@ietf.org; Wed, 21 Jun 2006 14:41:21 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft7dg-0002tu-J1 for mip4@ietf.org; Wed, 21 Jun 2006 14:41:21 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 42F7890023 for ; Wed, 21 Jun 2006 14:41:17 -0400 (EDT) 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 22135-09 for ; Wed, 21 Jun 2006 14:41:16 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 21 Jun 2006 14:41:16 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jun 2006 14:38:18 -0400 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 14:38:17 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51B9@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWgAADMYBAAAYSc0AABQx3A From: "Chowdhury, Kuntal" To: "Tsirtsis, George" , "Kent Leung (kleung)" , "Avi Lior" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 21 Jun 2006 18:38:18.0153 (UTC) FILETIME=[DD2A2190:01C69561] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org All, Simply not replying back to the MN won't prevent a malicious MN to send zillions of bogus RRQs to the HA to launch an attack. If the MN has a malicious intent, it can care less whether the HA replies or not. Also, note that in most of the MIP4 deployments today, the MN has to go through several levels of auth before it's messages are forwarded to the HA. So, a completely untrusted MN pounding on the HA is a slim possibility in these deployments. Therefore, I am less concerned about dealing with MN's with malicious intent _at_ the HA. OTOH, if the MN is not malicious, but for any reason failed auth at the HA, the MN will have no clue why there is no RRP. Therefore, the MN will send number of retries to the HA unnecessarily. From the current deployments, we have seen many MNs go crazy and send numerous retries of RRQ to the HA when they don't receive RRP within their retry timers. These add unnecessarily load on the system.=20 Lastly, RFC 3344 based mip4 is widely deployed today. If we need to clarify something to better describe node behaviors, I am all for it. However, changing basic protocol operation should be avoided as much as possible. Regards, Kuntal > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com] > Sent: Wednesday, June 21, 2006 12:51 PM > To: Chowdhury, Kuntal; Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing > List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Usually it is not a good idea to be responding to messages that fail > authentication because that can be used to mound DoS attacks. It is > better to silently discard such messages. >=20 > The RFC also talks about authorization-enabling extensions and it is a > bit unclear on which extensions qualify for that. Most people think of > the MN-HA Authenticator to be an authentication-enabling extension. > Others think that the MN-AAA Authenticator or even an FA-HA > authenticator could play this role in some scenarios. >=20 > It would be nice not to loose this flexibility while clarifying the > text. >=20 > George > > -----Original Message----- > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > Sent: Wednesday, June 21, 2006 1:05 PM > > To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > Kent/Avi, > > > > The current text does not say that the HA cannot send RRP when auth > > fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > > > > > if the Authenticator is invalid, the home agent MUST reject the > > > mobile node's registration and SHOULD send a Registration Reply to > the > > > > > mobile node with Code 131" > > > > What we need is a proper description of the HA and the MN behaviors > when > > the auth fails and the HA needs to send a RRP to stop the MN from > > re-trying unnecessarily. > > > > The clarification could be: > > > > If the Authenticator is invalid, the home agent MUST reject the mobile > > node's registration and SHOULD send a Registration Reply to the mobile > > node with Code 131. In this case, the HA populates the MN-HA AE with > all > > 0s. Upon receiving the RRP with error code 131, the MN skips MN-HA AE > > validation and stops retrying registration attempts. The MN MAY log > this > > event in its internal log. > > > > What do you think? > > > > -Kuntal > > > > > -----Original Message----- > > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > > Sent: Wednesday, June 21, 2006 11:43 AM > > > To: Avi Lior; Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > > fails > > > > > > Hi Avi. My understanding is that in this case, the HA will not be > > able > > > to send an RRP if it does not have an SA with the MN because this > > > message requires MN-HA AE. The text state that if HA has an SA, > then > > to > > > use that in the RRP. Without an SA, the HA should drop the RRQ, > IMHO. > > > > > > Kent > > > > > > > -----Original Message----- > > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > > Sent: Wednesday, June 21, 2006 8:13 AM > > > > To: Mobile IPv4 Mailing List > > > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator > > fails > > > > > > > > Hi, > > > > > > > > While working a scenario in WiMAX I have run into some > > > > ambiguity in RFC3344. > > > > > > > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > > > which it fails to authenticate. In particular the HA cant > > > > authenticate because it can't obtain the MN-HA from the AAA > > > > using the NAI. > > > > > > > > >From section 3.8.2.1 RFC3344 states that a Registration > > > > Reply should be > > > > sent with code 131. > > > > > > > > "if the Authenticator is invalid, the home agent MUST reject > > > > the mobile node's registration and SHOULD send a Registration > > > > Reply to the mobile node with Code 131" > > > > > > > > And from section 3.6.2.1 describing the MN behavior we have: > > > > > > > > "If the Code field indicates an authentication failure, > > > > either at the > > > > foreign agent or the home agent, then it is quite possible that > > any > > > > authenticators in the Registration Reply will also be in > > > > error. This > > > > could happen, for example, if the shared secret between the > > mobile > > > > node and home agent was erroneously configured. The mobile > node > > > > SHOULD log such errors as security exceptions." > > > > > > > > RFC3344 also states that Registration Reply MUST include a > > > > MN-HA authentication extension: > > > > > > > > Section 3.8.3.3 says " Note that items (a) and (c) MUST > > > > appear in every Registration Reply sent by the home agent." > > > > > > > > where (c) is The Mobile-Home Authentication Extension. > > > > > > > > The problem is that when MN-HA-AE fails at the HA there isnt > > > > an available MN-HA authentication extension to use. So how > > > > can one send a registration reply? > > > > > > > > Furthermore, if the HA cant not obtain an MN-HA for the > > > > mobile, what should happen? > > > > > > > > > > > > Any help will be appreciated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Avi Lior > > > > Bridgewater Systems Corporation > > > > Phone : +1 (613) 591-9104 x6417 > > > > Cell : +1 (613) 796-4183 > > > > E-mail : mailto:avi@bridgewatersystems.com > > > > > > > > www.bridgewatersystems.com > > > > > > > > > > > > -- > > > > Mip4 mailing list: Mip4@ietf.org > > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > > Charter page: > > http://www.ietf.org/html.charters/mip4-charter.html > > > > Supplemental site: http://www.mip4.org/ > > > > > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 16:22:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9DX-0007J0-Aa; Wed, 21 Jun 2006 16:22:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9DV-0007Ia-EG for mip4@ietf.org; Wed, 21 Jun 2006 16:22:25 -0400 Received: from web60320.mail.yahoo.com ([209.73.178.128]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ft9DU-0007nP-08 for mip4@ietf.org; Wed, 21 Jun 2006 16:22:25 -0400 Received: (qmail 14745 invoked by uid 60001); 21 Jun 2006 19:55:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=HWtyjm54YFHEmB10W/BWw/RX5Iy22lm32xfUsQ+Qdxh3N9HH5rRoF4WxVAcMeDqhE1nI4IQ+czWgAKYPnm3mYjrYccKN5xJYmm7rZizswzgcxRhwxo3aWpblWppwr7NVXSPoWP5MbxQLYGw8AYxJPWVpV4xq+DqiVeh0KGhRXd4= ; Message-ID: <20060621195542.14743.qmail@web60320.mail.yahoo.com> Received: from [12.129.211.52] by web60320.mail.yahoo.com via HTTP; Wed, 21 Jun 2006 12:55:42 PDT Date: Wed, 21 Jun 2006 12:55:42 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails To: Vijay Devarapalli , Avi Lior In-Reply-To: <44998A59.2000908@azairenet.com> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0266401499==" Errors-To: mip4-bounces@ietf.org --===============0266401499== Content-Type: multipart/alternative; boundary="0-490483431-1150919742=:12564" --0-490483431-1150919742=:12564 Content-Type: text/plain; charset=us-ascii I agree. FYI, in WiMAX forum NWG discussions, people were divided into two groups: some wanting HA to send RRP and some to ignore and they decided to ask it from Mip4 WG. I think the answer should be, yes 3344 is weakly allowing a RRP reply but not replying seems to have gained consensus currently. Regards, --behcet ----- Original Message ---- From: Vijay Devarapalli To: Avi Lior Cc: Mobile IPv4 Mailing List Sent: Wednesday, June 21, 2006 1:05:13 PM Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails if authentication fails, it is probably best to just silently discard the registration request. Vijay Avi Lior wrote: > Hi, > > While working a scenario in WiMAX I have run into some ambiguity in > RFC3344. > > The HA receives a Reg Request with MN-HA-AE and NAI extension which it > fails to authenticate. In particular > the HA cant authenticate because it can't obtain the MN-HA from the AAA > using the NAI. > >>From section 3.8.2.1 RFC3344 states that a Registration Reply should be > sent with code 131. > > "if the Authenticator is invalid, the home agent MUST reject > the mobile node's registration and SHOULD send a Registration > Reply to the mobile node with Code 131" > > And from section 3.6.2.1 describing the MN behavior we have: > > "If the Code field indicates an authentication failure, either at the > foreign agent or the home agent, then it is quite possible that any > authenticators in the Registration Reply will also be in error. This > could happen, for example, if the shared secret between the mobile > node and home agent was erroneously configured. The mobile node > SHOULD log such errors as security exceptions." > > RFC3344 also states that Registration Reply MUST include a MN-HA > authentication extension: > > Section 3.8.3.3 says " Note that items (a) and (c) MUST appear in every > Registration Reply sent by the home agent." > > where (c) is The Mobile-Home Authentication Extension. > > The problem is that when MN-HA-AE fails at the HA there isnt an > available MN-HA authentication extension to use. So how can one send a > registration reply? > > Furthermore, if the HA cant not obtain an MN-HA for the mobile, what > should happen? > > > Any help will be appreciated. > > > > > > > ======================== > > Avi Lior > Bridgewater Systems Corporation > Phone : +1 (613) 591-9104 x6417 > Cell : +1 (613) 796-4183 > E-mail : mailto:avi@bridgewatersystems.com > > www.bridgewatersystems.com > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --0-490483431-1150919742=:12564 Content-Type: text/html; charset=us-ascii
I agree.
FYI, in WiMAX forum NWG discussions, people were divided into two groups: some wanting HA to send RRP and some to ignore and they decided to ask it from Mip4 WG. I think the answer should be, yes 3344 is weakly allowing a RRP reply but  not replying seems to have gained consensus currently.

Regards,

--behcet

----- Original Message ----
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
To: Avi Lior <avi@bridgewatersystems.com>
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>
Sent: Wednesday, June 21, 2006 1:05:13 PM
Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails

if authentication fails, it is probably best to just silently
discard the registration request.

Vijay

Avi Lior wrote:
> Hi,
>  
> While working a scenario in WiMAX I have run into some ambiguity in
> RFC3344.
>  
> The HA receives a Reg Request with MN-HA-AE and NAI extension which it
> fails to authenticate.  In particular
> the HA cant authenticate because it can't obtain the MN-HA from the AAA
> using the NAI.
>  
>>From section 3.8.2.1 RFC3344 states that a Registration Reply should be
> sent with code 131.
>
> "if the Authenticator is invalid, the home agent MUST reject
> the mobile node's registration and SHOULD send a Registration
> Reply to the mobile node with Code 131"
>
> And from section 3.6.2.1 describing the MN behavior we have:
>  
>    "If the Code field indicates an authentication failure, either at the
>    foreign agent or the home agent, then it is quite possible that any
>    authenticators in the Registration Reply will also be in error.  This
>    could happen, for example, if the shared secret between the mobile
>    node and home agent was erroneously configured.  The mobile node
>    SHOULD log such errors as security exceptions."
>  
> RFC3344 also states that Registration Reply MUST include a MN-HA
> authentication extension:
>  
> Section 3.8.3.3 says  " Note that items (a) and (c) MUST appear in every
> Registration Reply sent by the home agent."
>  
> where  (c) is  The Mobile-Home Authentication Extension.
>  
> The problem is that when MN-HA-AE fails at the HA there isnt an
> available MN-HA authentication extension to use.  So how can one send a
> registration reply?
>
> Furthermore, if the HA cant not obtain an MN-HA for the mobile, what
> should happen?
>
>
> Any help will be appreciated.
>
>
>  
>  
>  
>
> ========================
>
> Avi Lior                                    
> Bridgewater Systems Corporation
> Phone :  +1 (613) 591-9104 x6417
> Cell    :  +1 (613) 796-4183
> E-mail : mailto:avi@bridgewatersystems.com
> <mailto:avi@bridgewatersystems.com>
> www.bridgewatersystems.com <http://www.bridgewatersystems.com/>  
>
>


--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

--0-490483431-1150919742=:12564-- --===============0266401499== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0266401499==-- From mip4-bounces@ietf.org Wed Jun 21 16:54:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9iW-0001TO-1H; Wed, 21 Jun 2006 16:54:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9iU-0001TB-G7 for mip4@ietf.org; Wed, 21 Jun 2006 16:54:26 -0400 Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9iT-0004G9-37 for mip4@ietf.org; Wed, 21 Jun 2006 16:54:26 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id k5LKG8V23995; Wed, 21 Jun 2006 13:16:08 -0700 X-mProtect: <200606212016> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141103.americas.nokia.com (172.18.141.103, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdfPOANW; Wed, 21 Jun 2006 13:16:06 PDT Message-ID: <4499B1E5.7000707@iprg.nokia.com> Date: Wed, 21 Jun 2006 13:53:57 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center, Mtn. View User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails References: <7EB20EA0938B4D42A2D82689365C9B7A04FAAA@NAEX14.na.qualcomm.com> In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FAAA@NAEX14.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: 52e1467c2184c31006318542db5614d5 Cc: "Kent Leung \(kleung\)" , "Chowdhury, Kuntal" , Mobile IPv4 Mailing List , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hello George, Tsirtsis, George wrote: > Usually it is not a good idea to be responding to messages that fail > authentication because that can be used to mound DoS attacks. It is > better to silently discard such messages. > I definitely do not agree with this, because the registration process is already rate limited. This was put in exactly to avoid DoS. > The RFC also talks about authorization-enabling extensions and it is a > bit unclear on which extensions qualify for that. Most people think of > the MN-HA Authenticator to be an authentication-enabling extension. > Others think that the MN-AAA Authenticator or even an FA-HA > authenticator could play this role in some scenarios. > MN-AAA was explicitly designed to be authorization-enabling, and I did not think this was unclear. In fact, the entire process of inserting the new terminology about "authorization-enabling" was aimed exactly at having another kind of authorizing extension -- namely, the MN-AAA extension. FA-HA was never designed to be authorization-enabling, but if sufficiently large amount of control is removed from the mobile node I can see where operators would like that. > It would be nice not to loose this flexibility while clarifying the > text. > I'll have to try to catch up on the rest of this thread while watching the fires burn out of control elsewhere, sigh. Regards, Charlie P. -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 16:55:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9jM-0001zG-Od; Wed, 21 Jun 2006 16:55:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9jL-0001yz-DT for mip4@ietf.org; Wed, 21 Jun 2006 16:55:19 -0400 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 1Ft9jL-0004Jq-AF for mip4@ietf.org; Wed, 21 Jun 2006 16:55:19 -0400 Received: from av12-2-sn2.hy.skanova.net ([81.228.8.186]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ft9XU-0005NR-NH for mip4@ietf.org; Wed, 21 Jun 2006 16:43:06 -0400 Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 44B44381DC; Wed, 21 Jun 2006 22:43:03 +0200 (CEST) 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 3654137E70; Wed, 21 Jun 2006 22:43:03 +0200 (CEST) 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 A21AB37E47; Wed, 21 Jun 2006 22:43:02 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1Ft9XP-0002RP-7e; Wed, 21 Jun 2006 22:43:01 +0200 Message-ID: <4499AF53.6000405@levkowetz.com> Date: Wed, 21 Jun 2006 22:42:59 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails References: <2979E38DD6FC6544B789C8DAD7BAFC5202061F78@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5202061F78@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: -2.5 (--) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0290741137==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0290741137== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2525F27955595BFC9BD07276" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2525F27955595BFC9BD07276 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kent, on 2006-06-21 19:13 Kent Leung (kleung) said the following: > If there is no SA, then I don't think HA should send a RRP.=20 Maybe, but it leaves the MN and user with less information than it/he could have. I think that the best would be if we could find a standard way of handling this situation. Fwiw, this has come up before, we discussed how to handle this at ipUnplugged some time ago - it's a real situation when you're setting up and deploying a network. Regards, Henrik > Kent=20 >=20 >> -----Original Message----- >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 >> Sent: Wednesday, June 21, 2006 10:05 AM >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 >> Authenticator fails >>=20 >> Kent/Avi, >>=20 >> The current text does not say that the HA cannot send RRP=20 >> when auth fails. Rather it says that the HA "SHOULD" send RRP=20 >> back to the MN: >>=20 >> > if the Authenticator is invalid, the home agent MUST reject the mob= ile=20 >> > node's registration and SHOULD send a Registration Reply to the =20 >> > mobile node with Code 131" >>=20 >> What we need is a proper description of the HA and the MN=20 >> behaviors when the auth fails and the HA needs to send a RRP=20 >> to stop the MN from re-trying unnecessarily.=20 >>=20 >> The clarification could be:=20 >>=20 >> If the Authenticator is invalid, the home agent MUST reject=20 >> the mobile node's registration and SHOULD send a Registration=20 >> Reply to the mobile node with Code 131. In this case, the HA=20 >> populates the MN-HA AE with all 0s. Upon receiving the RRP=20 >> with error code 131, the MN skips MN-HA AE validation and=20 >> stops retrying registration attempts. The MN MAY log this=20 >> event in its internal log. >>=20 >> What do you think? >>=20 >> -Kuntal >>=20 >> > -----Original Message----- >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] >> > Sent: Wednesday, June 21, 2006 11:43 AM >> > To: Avi Lior; Mobile IPv4 Mailing List >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator = fails >> >=20 >> > Hi Avi. My understanding is that in this case, the HA will not be a= ble >> > to send an RRP if it does not have an SA with the MN because this=20 >> > message requires MN-HA AE. The text state that if HA has=20 >> an SA, then >> to >> > use that in the RRP. Without an SA, the HA should drop the RRQ, IM= HO. >> >=20 >> > Kent >> >=20 >> > > -----Original Message----- >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] >> > > Sent: Wednesday, June 21, 2006 8:13 AM >> > > To: Mobile IPv4 Mailing List >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator fa= ils >> > > >> > > Hi, >> > > >> > > While working a scenario in WiMAX I have run into some ambiguity = in=20 >> > > RFC3344. >> > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension whi= ch=20 >> > > it fails to authenticate. In particular the HA cant authenticate = >> > > because it can't obtain the MN-HA from the AAA using the NAI. >> > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration >> > > Reply should be >> > > sent with code 131. >> > > >> > > "if the Authenticator is invalid, the home agent MUST reject the=20 >> > > mobile node's registration and SHOULD send a Registration Reply t= o=20 >> > > the mobile node with Code 131" >> > > >> > > And from section 3.6.2.1 describing the MN behavior we have: >> > > >> > > "If the Code field indicates an authentication failure, either= at=20 >> > > the >> > > foreign agent or the home agent, then it is quite possible that= any >> > > authenticators in the Registration Reply will also be in error= =2E =20 >> > > This >> > > could happen, for example, if the shared secret between the mob= ile >> > > node and home agent was erroneously configured. The mobile no= de >> > > SHOULD log such errors as security exceptions." >> > > >> > > RFC3344 also states that Registration Reply MUST include a MN-HA=20 >> > > authentication extension: >> > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) MUST appear i= n=20 >> > > every Registration Reply sent by the home agent." >> > > >> > > where (c) is The Mobile-Home Authentication Extension. >> > > >> > > The problem is that when MN-HA-AE fails at the HA there isnt an=20 >> > > available MN-HA authentication extension to use. So how can one=20 >> > > send a registration reply? >> > > >> > > Furthermore, if the HA cant not obtain an MN-HA for the mobile, w= hat=20 >> > > should happen? >> > > >> > > >> > > Any help will be appreciated. >> > > >> > > >> > > >> > > >> > > >> > > >> > > =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D >> > > >> > > Avi Lior >> > > Bridgewater Systems Corporation >> > > Phone : +1 (613) 591-9104 x6417 >> > > Cell : +1 (613) 796-4183 >> > > E-mail : mailto:avi@bridgewatersystems.com=20 >> > > >> > > www.bridgewatersystems.com >> > > >> > > >> > > -- >> > > Mip4 mailing list: Mip4@ietf.org >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> > > Charter page: http://www.ietf.org/html.charters/mip4-charter.= html >> > > Supplemental site: http://www.mip4.org/ >> > > >> >=20 >> > -- >> > Mip4 mailing list: Mip4@ietf.org >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> > Charter page: http://www.ietf.org/html.charters/mip4-charter.h= tml >> > Supplemental site: http://www.mip4.org/ >>=20 >>=20 >> "This email message and any attachments are confidential=20 >> information of Starent Networks, Corp. The information=20 >> transmitted may not be used to create or change any=20 >> contractual obligations of Starent Networks, Corp. Any=20 >> review, retransmission, dissemination or other use of, or=20 >> taking of any action in reliance upon this e-mail and its=20 >> attachments by persons or entities other than the intended=20 >> recipient is prohibited. If you are not the intended=20 >> recipient, please notify the sender immediately -- by=20 >> replying to this message or by sending an email to=20 >> postmaster@starentnetworks.com -- and destroy all copies of=20 >> this message and any attachments without reading or=20 >> disclosing their contents. Thank you." >>=20 >=20 --------------enig2525F27955595BFC9BD07276 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEma9TeVhrtTJkXCMRApPzAJ9U7KlyM85u6/4emEPA7wleQ99YbwCg/uGR KXLuO0K0TZABSX2Ej/aqXWQ= =CRzN -----END PGP SIGNATURE----- --------------enig2525F27955595BFC9BD07276-- --===============0290741137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0290741137==-- From mip4-bounces@ietf.org Wed Jun 21 17:02:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9qI-0005v2-Kk; Wed, 21 Jun 2006 17:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft9qH-0005jD-3Q for mip4@ietf.org; Wed, 21 Jun 2006 17:02:29 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ft9qF-0004u3-Oj for mip4@ietf.org; Wed, 21 Jun 2006 17:02:29 -0400 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 k5LL2O9I023097 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Jun 2006 14:02:25 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5LL1m7Z012920; Wed, 21 Jun 2006 14:02:24 -0700 (PDT) Received: from NAEX14.na.qualcomm.com ([10.47.5.242]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 14:02:15 -0700 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 14:02:13 -0700 Message-ID: <7EB20EA0938B4D42A2D82689365C9B7A04FAEC@NAEX14.na.qualcomm.com> In-Reply-To: <4499B1E5.7000707@iprg.nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVdN97Ya2rZ7E+Qi+HXsvbCKvdjwAAI6zg From: "Tsirtsis, George" To: "Charles E. Perkins" X-OriginalArrivalTime: 21 Jun 2006 21:02:15.0524 (UTC) FILETIME=[F9705A40:01C69575] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: "Kent Leung \(kleung\)" , "Chowdhury, Kuntal" , Mobile IPv4 Mailing List , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Wednesday, June 21, 2006 4:54 PM > To: Tsirtsis, George > Cc: Chowdhury, Kuntal; Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing > List > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 >=20 > Hello George, >=20 > Tsirtsis, George wrote: > > Usually it is not a good idea to be responding to messages that fail > > authentication because that can be used to mound DoS attacks. It is > > better to silently discard such messages. > > > I definitely do not agree with this, because the registration process is > already rate limited. This was put in exactly to avoid DoS. >=20 > > The RFC also talks about authorization-enabling extensions and it is a > > bit unclear on which extensions qualify for that. Most people think of > > the MN-HA Authenticator to be an authentication-enabling extension. > > Others think that the MN-AAA Authenticator or even an FA-HA > > authenticator could play this role in some scenarios. > > > MN-AAA was explicitly designed to be authorization-enabling, and I did not > think this was unclear. In fact, the entire process of inserting the > new terminology > about "authorization-enabling" was aimed exactly at having another kind of > authorizing extension -- namely, the MN-AAA extension. >=20 > FA-HA was never designed to be authorization-enabling, but if > sufficiently > large amount of control is removed from the mobile node I can see where > operators would like that. GT> There is value in the FA-HA auth extension being an authentication-enabling extension in scenarios other than netlmm. In some scenarios for example where the access control is done at the FA and the FA and HA are in the same domain, a "chain of trust" model can be used i.e, MN-FA Auth and FA-HA Auth.=20 George -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 17:55:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAfO-00058y-Q7; Wed, 21 Jun 2006 17:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAfO-00058t-1E for mip4@ietf.org; Wed, 21 Jun 2006 17:55:18 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAfM-00033x-9z for mip4@ietf.org; Wed, 21 Jun 2006 17:55:18 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5LLtFMu023668 for ; Wed, 21 Jun 2006 14:55:15 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5LLtEjv002612 for ; Wed, 21 Jun 2006 16:55:15 -0500 (CDT) 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 17:55:12 -0400 Message-ID: In-Reply-To: <7CCD07160348804497EF29E9EA5560D73C51B7@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWgAADMYBAACkUJUA== From: "Nakhjiri Madjid-MNAKHJI1" To: "Chowdhury, Kuntal" , "Kent Leung \(kleung\)" , "Avi Lior" , "Mobile IPv4 Mailing List" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi guys,=20 I agree with Kuntal, except a MUST for reject should be accompanied by a MUST for sending the RRP with the code, not a SHOULD as Kuntal's text suggest, otherwise how would the MN know about the rejection. However, the MN-HA-AE filled with 0 worries me a bit, since anybody could send such an unsigned rejection to the MN and in a sense do a DoS for HA!! -----Original Message----- From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Wednesday, June 21, 2006 12:05 PM To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Kent/Avi, The current text does not say that the HA cannot send RRP when auth fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > if the Authenticator is invalid, the home agent MUST reject the=20 > mobile node's registration and SHOULD send a Registration Reply to the > mobile node with Code 131" What we need is a proper description of the HA and the MN behaviors when the auth fails and the HA needs to send a RRP to stop the MN from re-trying unnecessarily.=20 The clarification could be:=20 If the Authenticator is invalid, the home agent MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 131. In this case, the HA populates the MN-HA AE with all 0s. Upon receiving the RRP with error code 131, the MN skips MN-HA AE validation and stops retrying registration attempts. The MN MAY log this event in its internal log. What do you think? -Kuntal > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Wednesday, June 21, 2006 11:43 AM > To: Avi Lior; Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi Avi. My understanding is that in this case, the HA will not be able > to send an RRP if it does not have an SA with the MN because this > message requires MN-HA AE. The text state that if HA has an SA, then to > use that in the RRP. Without an SA, the HA should drop the RRQ, IMHO. >=20 > Kent >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Wednesday, June 21, 2006 8:13 AM > > To: Mobile IPv4 Mailing List > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails > > > > Hi, > > > > While working a scenario in WiMAX I have run into some > > ambiguity in RFC3344. > > > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > which it fails to authenticate. In particular the HA cant > > authenticate because it can't obtain the MN-HA from the AAA > > using the NAI. > > > > >From section 3.8.2.1 RFC3344 states that a Registration > > Reply should be > > sent with code 131. > > > > "if the Authenticator is invalid, the home agent MUST reject > > the mobile node's registration and SHOULD send a Registration > > Reply to the mobile node with Code 131" > > > > And from section 3.6.2.1 describing the MN behavior we have: > > > > "If the Code field indicates an authentication failure, > > either at the > > foreign agent or the home agent, then it is quite possible that any > > authenticators in the Registration Reply will also be in > > error. This > > could happen, for example, if the shared secret between the mobile > > node and home agent was erroneously configured. The mobile node > > SHOULD log such errors as security exceptions." > > > > RFC3344 also states that Registration Reply MUST include a > > MN-HA authentication extension: > > > > Section 3.8.3.3 says " Note that items (a) and (c) MUST > > appear in every Registration Reply sent by the home agent." > > > > where (c) is The Mobile-Home Authentication Extension. > > > > The problem is that when MN-HA-AE fails at the HA there isnt > > an available MN-HA authentication extension to use. So how > > can one send a registration reply? > > > > Furthermore, if the HA cant not obtain an MN-HA for the > > mobile, what should happen? > > > > > > Any help will be appreciated. > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > Avi Lior > > Bridgewater Systems Corporation > > Phone : +1 (613) 591-9104 x6417 > > Cell : +1 (613) 796-4183 > > E-mail : mailto:avi@bridgewatersystems.com > > > > www.bridgewatersystems.com > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 17:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAim-0006KV-S7; Wed, 21 Jun 2006 17:58:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtAil-0006JY-Sf for mip4@ietf.org; Wed, 21 Jun 2006 17:58:47 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtAih-00037P-Lx for mip4@ietf.org; Wed, 21 Jun 2006 17:58:47 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5LLwg68025929 for ; Wed, 21 Jun 2006 14:58:42 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k5LLwfx9001972 for ; Wed, 21 Jun 2006 16:58:42 -0500 (CDT) 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 17:58:39 -0400 Message-ID: In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FAAA@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWgAADMYBAAAYSc0AAI6BFQ From: "Nakhjiri Madjid-MNAKHJI1" To: "Tsirtsis, George" , "Chowdhury, Kuntal" , "Kent Leung \(kleung\)" , "Avi Lior" , "Mobile IPv4 Mailing List" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Great, I see that George and I feel the same way about the security threat of sending unsigned RRP. I was going to suggest use of MN-AAA authenticator, but that means RRP has to go to the AAA server and hence the use of RFCs other than 3344 for key bootstrapping, so it might cause extra implementation burdens for people who only want to implement 3344. -----Original Message----- From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 Sent: Wednesday, June 21, 2006 12:51 PM To: Chowdhury, Kuntal; Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Usually it is not a good idea to be responding to messages that fail authentication because that can be used to mound DoS attacks. It is better to silently discard such messages. The RFC also talks about authorization-enabling extensions and it is a bit unclear on which extensions qualify for that. Most people think of the MN-HA Authenticator to be an authentication-enabling extension. Others think that the MN-AAA Authenticator or even an FA-HA authenticator could play this role in some scenarios. It would be nice not to loose this flexibility while clarifying the text. George > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Wednesday, June 21, 2006 1:05 PM > To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Kent/Avi, >=20 > The current text does not say that the HA cannot send RRP when auth > fails. Rather it says that the HA "SHOULD" send RRP back to the MN: >=20 > > if the Authenticator is invalid, the home agent MUST reject the > > mobile node's registration and SHOULD send a Registration Reply to the >=20 > > mobile node with Code 131" >=20 > What we need is a proper description of the HA and the MN behaviors when > the auth fails and the HA needs to send a RRP to stop the MN from > re-trying unnecessarily. >=20 > The clarification could be: >=20 > If the Authenticator is invalid, the home agent MUST reject the mobile > node's registration and SHOULD send a Registration Reply to the mobile > node with Code 131. In this case, the HA populates the MN-HA AE with all > 0s. Upon receiving the RRP with error code 131, the MN skips MN-HA AE > validation and stops retrying registration attempts. The MN MAY log this > event in its internal log. >=20 > What do you think? >=20 > -Kuntal >=20 > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Wednesday, June 21, 2006 11:43 AM > > To: Avi Lior; Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > Hi Avi. My understanding is that in this case, the HA will not be > able > > to send an RRP if it does not have an SA with the MN because this > > message requires MN-HA AE. The text state that if HA has an SA, then > to > > use that in the RRP. Without an SA, the HA should drop the RRQ, IMHO. > > > > Kent > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Wednesday, June 21, 2006 8:13 AM > > > To: Mobile IPv4 Mailing List > > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > > > Hi, > > > > > > While working a scenario in WiMAX I have run into some > > > ambiguity in RFC3344. > > > > > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > > which it fails to authenticate. In particular the HA cant > > > authenticate because it can't obtain the MN-HA from the AAA > > > using the NAI. > > > > > > >From section 3.8.2.1 RFC3344 states that a Registration > > > Reply should be > > > sent with code 131. > > > > > > "if the Authenticator is invalid, the home agent MUST reject > > > the mobile node's registration and SHOULD send a Registration > > > Reply to the mobile node with Code 131" > > > > > > And from section 3.6.2.1 describing the MN behavior we have: > > > > > > "If the Code field indicates an authentication failure, > > > either at the > > > foreign agent or the home agent, then it is quite possible that > any > > > authenticators in the Registration Reply will also be in > > > error. This > > > could happen, for example, if the shared secret between the > mobile > > > node and home agent was erroneously configured. The mobile node > > > SHOULD log such errors as security exceptions." > > > > > > RFC3344 also states that Registration Reply MUST include a > > > MN-HA authentication extension: > > > > > > Section 3.8.3.3 says " Note that items (a) and (c) MUST > > > appear in every Registration Reply sent by the home agent." > > > > > > where (c) is The Mobile-Home Authentication Extension. > > > > > > The problem is that when MN-HA-AE fails at the HA there isnt > > > an available MN-HA authentication extension to use. So how > > > can one send a registration reply? > > > > > > Furthermore, if the HA cant not obtain an MN-HA for the > > > mobile, what should happen? > > > > > > > > > Any help will be appreciated. > > > > > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Avi Lior > > > Bridgewater Systems Corporation > > > Phone : +1 (613) 591-9104 x6417 > > > Cell : +1 (613) 796-4183 > > > E-mail : mailto:avi@bridgewatersystems.com > > > > > > www.bridgewatersystems.com > > > > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 18:21:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtB4L-0007M2-8K; Wed, 21 Jun 2006 18:21:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtB4K-0007KF-C3 for mip4@ietf.org; Wed, 21 Jun 2006 18:21:04 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtB4F-00044q-FD for mip4@ietf.org; Wed, 21 Jun 2006 18:21:04 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id DB38290041 for ; Wed, 21 Jun 2006 18:20:55 -0400 (EDT) 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 27509-08 for ; Wed, 21 Jun 2006 18:20:54 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Wed, 21 Jun 2006 18:20:54 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 21 Jun 2006 18:17:56 -0400 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 18:17:56 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51BD@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWgAADMYBAACkUJUAAA4+Cw From: "Chowdhury, Kuntal" To: "Nakhjiri Madjid-MNAKHJI1" , "Kent Leung (kleung)" , "Avi Lior" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 21 Jun 2006 22:17:56.0653 (UTC) FILETIME=[8C29A5D0:01C69580] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Madjid and all, It does not really matter how the HA data-fills the MN-HA AE in this case. The MN-HA AE will not pass validation at the MN regardless we put all 0s or all non-0s. So, my modified proposal is: If the Authenticator is invalid, the home agent MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 131. In this case, the HA populates the MN-HA AE with any random number. Upon receiving the RRP with error code 131, the MN skips MN-HA AE validation and stops retrying registration attempts. The MN MAY log this event in its internal log. -Kuntal > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Wednesday, June 21, 2006 4:55 PM > To: Chowdhury, Kuntal; Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing > List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi guys, >=20 > I agree with Kuntal, except a MUST for reject should be accompanied by a > MUST for sending the RRP with the code, not a SHOULD as Kuntal's text > suggest, otherwise how would the MN know about the rejection. However, > the MN-HA-AE filled with 0 worries me a bit, since anybody could send > such an unsigned rejection to the MN and in a sense do a DoS for HA!! >=20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Wednesday, June 21, 2006 12:05 PM > To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails >=20 > Kent/Avi, >=20 > The current text does not say that the HA cannot send RRP when auth > fails. Rather it says that the HA "SHOULD" send RRP back to the MN: >=20 > > if the Authenticator is invalid, the home agent MUST reject the > > mobile node's registration and SHOULD send a Registration Reply to the >=20 > > mobile node with Code 131" >=20 > What we need is a proper description of the HA and the MN behaviors when > the auth fails and the HA needs to send a RRP to stop the MN from > re-trying unnecessarily. >=20 > The clarification could be: >=20 > If the Authenticator is invalid, the home agent MUST reject the mobile > node's registration and SHOULD send a Registration Reply to the mobile > node with Code 131. In this case, the HA populates the MN-HA AE with all > 0s. Upon receiving the RRP with error code 131, the MN skips MN-HA AE > validation and stops retrying registration attempts. The MN MAY log this > event in its internal log. >=20 > What do you think? >=20 > -Kuntal >=20 > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Wednesday, June 21, 2006 11:43 AM > > To: Avi Lior; Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > Hi Avi. My understanding is that in this case, the HA will not be > able > > to send an RRP if it does not have an SA with the MN because this > > message requires MN-HA AE. The text state that if HA has an SA, then > to > > use that in the RRP. Without an SA, the HA should drop the RRQ, IMHO. > > > > Kent > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Wednesday, June 21, 2006 8:13 AM > > > To: Mobile IPv4 Mailing List > > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > > > Hi, > > > > > > While working a scenario in WiMAX I have run into some > > > ambiguity in RFC3344. > > > > > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > > which it fails to authenticate. In particular the HA cant > > > authenticate because it can't obtain the MN-HA from the AAA > > > using the NAI. > > > > > > >From section 3.8.2.1 RFC3344 states that a Registration > > > Reply should be > > > sent with code 131. > > > > > > "if the Authenticator is invalid, the home agent MUST reject > > > the mobile node's registration and SHOULD send a Registration > > > Reply to the mobile node with Code 131" > > > > > > And from section 3.6.2.1 describing the MN behavior we have: > > > > > > "If the Code field indicates an authentication failure, > > > either at the > > > foreign agent or the home agent, then it is quite possible that > any > > > authenticators in the Registration Reply will also be in > > > error. This > > > could happen, for example, if the shared secret between the > mobile > > > node and home agent was erroneously configured. The mobile node > > > SHOULD log such errors as security exceptions." > > > > > > RFC3344 also states that Registration Reply MUST include a > > > MN-HA authentication extension: > > > > > > Section 3.8.3.3 says " Note that items (a) and (c) MUST > > > appear in every Registration Reply sent by the home agent." > > > > > > where (c) is The Mobile-Home Authentication Extension. > > > > > > The problem is that when MN-HA-AE fails at the HA there isnt > > > an available MN-HA authentication extension to use. So how > > > can one send a registration reply? > > > > > > Furthermore, if the HA cant not obtain an MN-HA for the > > > mobile, what should happen? > > > > > > > > > Any help will be appreciated. > > > > > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Avi Lior > > > Bridgewater Systems Corporation > > > Phone : +1 (613) 591-9104 x6417 > > > Cell : +1 (613) 796-4183 > > > E-mail : mailto:avi@bridgewatersystems.com > > > > > > www.bridgewatersystems.com > > > > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 19:46:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCOp-0002BZ-Fd; Wed, 21 Jun 2006 19:46:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCOo-0002BO-5R for mip4@ietf.org; Wed, 21 Jun 2006 19:46:18 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCOm-00083W-7R for mip4@ietf.org; Wed, 21 Jun 2006 19:46:18 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k5LNkFP3009018 for ; Wed, 21 Jun 2006 16:46:15 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5LNkDfA018046 for ; Wed, 21 Jun 2006 18:46:14 -0500 (CDT) 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 19:46:07 -0400 Message-ID: In-Reply-To: <7CCD07160348804497EF29E9EA5560D73C51BD@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVRT2xWIVEVPg5QNekAtjbpwR85wAC2BWgAADMYBAACkUJUAAA4+CwAALMtkA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Chowdhury, Kuntal" , "Kent Leung \(kleung\)" , "Avi Lior" , "Mobile IPv4 Mailing List" X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Kuntal,=20 My point was not about what you put in MN-HA AE, it will be garbage anyway. My point was if HA MUST reject it, then HA MUST make the rejection known to MN, i.e. you cannot say "it SHOULD send a RRP". Madjid -----Original Message----- From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Wednesday, June 21, 2006 5:18 PM To: Nakhjiri Madjid-MNAKHJI1; Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Madjid and all, It does not really matter how the HA data-fills the MN-HA AE in this case. The MN-HA AE will not pass validation at the MN regardless we put all 0s or all non-0s. So, my modified proposal is: If the Authenticator is invalid, the home agent MUST reject the mobile node's registration and SHOULD send a Registration Reply to the mobile node with Code 131. In this case, the HA populates the MN-HA AE with any random number. Upon receiving the RRP with error code 131, the MN skips MN-HA AE validation and stops retrying registration attempts. The MN MAY log this event in its internal log. -Kuntal > -----Original Message----- > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com] > Sent: Wednesday, June 21, 2006 4:55 PM > To: Chowdhury, Kuntal; Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing > List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi guys, >=20 > I agree with Kuntal, except a MUST for reject should be accompanied by a > MUST for sending the RRP with the code, not a SHOULD as Kuntal's text > suggest, otherwise how would the MN know about the rejection. However, > the MN-HA-AE filled with 0 worries me a bit, since anybody could send > such an unsigned rejection to the MN and in a sense do a DoS for HA!! >=20 > -----Original Message----- > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > Sent: Wednesday, June 21, 2006 12:05 PM > To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails >=20 > Kent/Avi, >=20 > The current text does not say that the HA cannot send RRP when auth > fails. Rather it says that the HA "SHOULD" send RRP back to the MN: >=20 > > if the Authenticator is invalid, the home agent MUST reject the > > mobile node's registration and SHOULD send a Registration Reply to the >=20 > > mobile node with Code 131" >=20 > What we need is a proper description of the HA and the MN behaviors when > the auth fails and the HA needs to send a RRP to stop the MN from > re-trying unnecessarily. >=20 > The clarification could be: >=20 > If the Authenticator is invalid, the home agent MUST reject the mobile > node's registration and SHOULD send a Registration Reply to the mobile > node with Code 131. In this case, the HA populates the MN-HA AE with all > 0s. Upon receiving the RRP with error code 131, the MN skips MN-HA AE > validation and stops retrying registration attempts. The MN MAY log this > event in its internal log. >=20 > What do you think? >=20 > -Kuntal >=20 > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > Sent: Wednesday, June 21, 2006 11:43 AM > > To: Avi Lior; Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > Hi Avi. My understanding is that in this case, the HA will not be > able > > to send an RRP if it does not have an SA with the MN because this > > message requires MN-HA AE. The text state that if HA has an SA, then > to > > use that in the RRP. Without an SA, the HA should drop the RRQ, IMHO. > > > > Kent > > > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Wednesday, June 21, 2006 8:13 AM > > > To: Mobile IPv4 Mailing List > > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticator > fails > > > > > > Hi, > > > > > > While working a scenario in WiMAX I have run into some > > > ambiguity in RFC3344. > > > > > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > > which it fails to authenticate. In particular the HA cant > > > authenticate because it can't obtain the MN-HA from the AAA > > > using the NAI. > > > > > > >From section 3.8.2.1 RFC3344 states that a Registration > > > Reply should be > > > sent with code 131. > > > > > > "if the Authenticator is invalid, the home agent MUST reject > > > the mobile node's registration and SHOULD send a Registration > > > Reply to the mobile node with Code 131" > > > > > > And from section 3.6.2.1 describing the MN behavior we have: > > > > > > "If the Code field indicates an authentication failure, > > > either at the > > > foreign agent or the home agent, then it is quite possible that > any > > > authenticators in the Registration Reply will also be in > > > error. This > > > could happen, for example, if the shared secret between the > mobile > > > node and home agent was erroneously configured. The mobile node > > > SHOULD log such errors as security exceptions." > > > > > > RFC3344 also states that Registration Reply MUST include a > > > MN-HA authentication extension: > > > > > > Section 3.8.3.3 says " Note that items (a) and (c) MUST > > > appear in every Registration Reply sent by the home agent." > > > > > > where (c) is The Mobile-Home Authentication Extension. > > > > > > The problem is that when MN-HA-AE fails at the HA there isnt > > > an available MN-HA authentication extension to use. So how > > > can one send a registration reply? > > > > > > Furthermore, if the HA cant not obtain an MN-HA for the > > > mobile, what should happen? > > > > > > > > > Any help will be appreciated. > > > > > > > > > > > > > > > > > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > Avi Lior > > > Bridgewater Systems Corporation > > > Phone : +1 (613) 591-9104 x6417 > > > Cell : +1 (613) 796-4183 > > > E-mail : mailto:avi@bridgewatersystems.com > > > > > > www.bridgewatersystems.com > > > > > > > > > -- > > > Mip4 mailing list: Mip4@ietf.org > > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > Charter page: > http://www.ietf.org/html.charters/mip4-charter.html > > > Supplemental site: http://www.mip4.org/ > > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you." -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 21 19:46:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCOs-0002Ck-SX; Wed, 21 Jun 2006 19:46:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtCOr-0002Cf-88 for mip4@ietf.org; Wed, 21 Jun 2006 19:46:21 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtCOl-00083V-On for mip4@ietf.org; Wed, 21 Jun 2006 19:46:21 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k5LNkEq5005280 for ; Wed, 21 Jun 2006 16:46:14 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5LNkDf8018046 for ; Wed, 21 Jun 2006 18:46:14 -0500 (CDT) 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 19:46:06 -0400 Message-ID: In-Reply-To: <7EB20EA0938B4D42A2D82689365C9B7A04FAEC@NAEX14.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVdN97Ya2rZ7E+Qi+HXsvbCKvdjwAAI6zgAAVNlPA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Tsirtsis, George" , "Charles E. Perkins" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: "Kent Leung \(kleung\)" , "Chowdhury, Kuntal" , Mobile IPv4 Mailing List , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org I=20 Ignoring the security issues with that "chain of trust" and how it is practically done, are you envisioning a case where MN has an SA with FA but not with HA?? I am curious on what scenario that is. The scenario I can think of is a case where FA is part of some access network edge device and MN-FA SA is established through authentication. Scalability-wise it would make sense to use AAA and the MN-AAA AE to bootstrap the MN-HA, but as I said earlier, it would require other RFCs such as 3957. Madjid > FA-HA was never designed to be authorization-enabling, but if > sufficiently > large amount of control is removed from the mobile node I can see where > operators would like that. GT> There is value in the FA-HA auth extension being an authentication-enabling extension in scenarios other than netlmm. In some scenarios for example where the access control is done at the FA and the FA and HA are in the same domain, a "chain of trust" model can be used i.e, MN-FA Auth and FA-HA Auth.=20 George --=20 Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 22 02:43:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIuP-0007jz-N5; Thu, 22 Jun 2006 02:43:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtIuN-0007ju-Pj for mip4@ietf.org; Thu, 22 Jun 2006 02:43:19 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtIuM-0006Ym-3v for mip4@ietf.org; Thu, 22 Jun 2006 02:43:19 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 21 Jun 2006 23:43:17 -0700 X-IronPort-AV: i="4.06,164,1149490800"; d="scan'208"; a="325493406:sNHT36379476" 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/8.12.11) with ESMTP id k5M6hHTb009029; Wed, 21 Jun 2006 23:43:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5M6hGCU005163; Wed, 21 Jun 2006 23:43:16 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 21 Jun 2006 23:43:16 -0700 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Wed, 21 Jun 2006 23:43:14 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52020622AC@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVc1DfUCjXk4gbTvSsUTW4unIXTQAE+0mg From: "Kent Leung \(kleung\)" To: "Henrik Levkowetz" X-OriginalArrivalTime: 22 Jun 2006 06:43:16.0254 (UTC) FILETIME=[240D9BE0:01C695C7] DKIM-Signature: a=rsa-sha1; q=dns; l=8377; t=1150958597; x=1151822597; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=203344=20Sending=20a=20Reg=20Reply=20when=20the=20Authent icator=20fails; X=v=3Dcisco.com=3B=20h=3DOffBF2QDuGm/mTFCreg6jJ5NNKI=3D; b=AEwKHDx6skHEyu1QuUpjLerjk0Y6Qz4mshY0T8P8SFv1ZqGtA2obx4EFIZVbKbXdTjRuWIZK /rfOaQ1rMmHAqAimPOzerCFQx2BDRliyQIBWe6WVkcVv0MVB+3iyqaBW; Authentication-Results: sj-dkim-3.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Henrik. I think the protocol can already handle authentication failures sufficiently. It's possible for MN to have multiple security contexts (indexed by different SPIs) with the HA. One could be used for registration and the other for authenticating RRP with error code 131. So I believe RFC 3344 provides the mechanism already. As long as HA has an SA that can be used to protect the RRP with the MN-HA AE, it can inform the MN such event happened in a secure manner. I think mucking with the MN-HA AE is not good. This can create the situation when MN sends a valid RRQ, and MITM can send a RRP with error code 131 and invalid MN-HA AE to the MN immediately. When the RRP is received, the MN will stop retrying. It's possible that the RRQ was lost in transit to the HA. And even if the valid RRP arrives later, MN may not be able to associate with the any pending RRQ, which could have been possibly removed since an associated RRP had been received already. Kent > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Wednesday, June 21, 2006 1:43 PM > To: Kent Leung (kleung) > Cc: Mobile IPv4 Mailing List > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator fails >=20 > Hi Kent, >=20 > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > If there is no SA, then I don't think HA should send a RRP.=20 >=20 > Maybe, but it leaves the MN and user with less information=20 > than it/he could have. I think that the best would be if we=20 > could find a standard way of handling this situation. >=20 > Fwiw, this has come up before, we discussed how to handle=20 > this at ipUnplugged some time ago - it's a real situation=20 > when you're setting up and deploying a network. >=20 > Regards, >=20 > Henrik >=20 > > Kent > >=20 > >> -----Original Message----- > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > >> Sent: Wednesday, June 21, 2006 10:05 AM > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator=20 > >> fails > >>=20 > >> Kent/Avi, > >>=20 > >> The current text does not say that the HA cannot send RRP=20 > when auth=20 > >> fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > >>=20 > >> > if the Authenticator is invalid, the home agent MUST reject the=20 > >> > mobile node's registration and SHOULD send a=20 > Registration Reply to=20 > >> > the mobile node with Code 131" > >>=20 > >> What we need is a proper description of the HA and the MN=20 > behaviors=20 > >> when the auth fails and the HA needs to send a RRP to stop the MN=20 > >> from re-trying unnecessarily. > >>=20 > >> The clarification could be:=20 > >>=20 > >> If the Authenticator is invalid, the home agent MUST reject the=20 > >> mobile node's registration and SHOULD send a Registration Reply to=20 > >> the mobile node with Code 131. In this case, the HA populates the=20 > >> MN-HA AE with all 0s. Upon receiving the RRP with error=20 > code 131, the=20 > >> MN skips MN-HA AE validation and stops retrying registration=20 > >> attempts. The MN MAY log this event in its internal log. > >>=20 > >> What do you think? > >>=20 > >> -Kuntal > >>=20 > >> > -----Original Message----- > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > >> > Sent: Wednesday, June 21, 2006 11:43 AM > >> > To: Avi Lior; Mobile IPv4 Mailing List > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator=20 > >> > fails > >> >=20 > >> > Hi Avi. My understanding is that in this case, the HA=20 > will not be=20 > >> > able to send an RRP if it does not have an SA with the=20 > MN because=20 > >> > this message requires MN-HA AE. The text state that if HA has > >> an SA, then > >> to > >> > use that in the RRP. Without an SA, the HA should drop=20 > the RRQ, IMHO. > >> >=20 > >> > Kent > >> >=20 > >> > > -----Original Message----- > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > >> > > To: Mobile IPv4 Mailing List > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator=20 > >> > > fails > >> > > > >> > > Hi, > >> > > > >> > > While working a scenario in WiMAX I have run into some=20 > ambiguity=20 > >> > > in RFC3344. > >> > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension=20 > >> > > which it fails to authenticate. In particular the HA cant=20 > >> > > authenticate because it can't obtain the MN-HA from=20 > the AAA using the NAI. > >> > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > >> > > Reply should be > >> > > sent with code 131. > >> > > > >> > > "if the Authenticator is invalid, the home agent MUST=20 > reject the=20 > >> > > mobile node's registration and SHOULD send a=20 > Registration Reply=20 > >> > > to the mobile node with Code 131" > >> > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > >> > > > >> > > "If the Code field indicates an authentication failure,=20 > >> > > either at the > >> > > foreign agent or the home agent, then it is quite=20 > possible that any > >> > > authenticators in the Registration Reply will also=20 > be in error. =20 > >> > > This > >> > > could happen, for example, if the shared secret=20 > between the mobile > >> > > node and home agent was erroneously configured. =20 > The mobile node > >> > > SHOULD log such errors as security exceptions." > >> > > > >> > > RFC3344 also states that Registration Reply MUST=20 > include a MN-HA=20 > >> > > authentication extension: > >> > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c)=20 > MUST appear=20 > >> > > in every Registration Reply sent by the home agent." > >> > > > >> > > where (c) is The Mobile-Home Authentication Extension. > >> > > > >> > > The problem is that when MN-HA-AE fails at the HA=20 > there isnt an=20 > >> > > available MN-HA authentication extension to use. So=20 > how can one=20 > >> > > send a registration reply? > >> > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for=20 > the mobile,=20 > >> > > what should happen? > >> > > > >> > > > >> > > Any help will be appreciated. > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > >> > > > >> > > Avi Lior > >> > > Bridgewater Systems Corporation > >> > > Phone : +1 (613) 591-9104 x6417 > >> > > Cell : +1 (613) 796-4183 > >> > > E-mail : mailto:avi@bridgewatersystems.com=20 > >> > > > >> > > www.bridgewatersystems.com > >> > > > >> > > > >> > > -- > >> > > Mip4 mailing list: Mip4@ietf.org > >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> > > Charter page:=20 > >> > > http://www.ietf.org/html.charters/mip4-charter.html > >> > > Supplemental site: http://www.mip4.org/ > >> > > > >> >=20 > >> > -- > >> > Mip4 mailing list: Mip4@ietf.org > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > >> > Charter page: =20 > >> > http://www.ietf.org/html.charters/mip4-charter.html > >> > Supplemental site: http://www.mip4.org/ > >>=20 > >>=20 > >> "This email message and any attachments are confidential=20 > information=20 > >> of Starent Networks, Corp. The information transmitted may not be=20 > >> used to create or change any contractual obligations of Starent=20 > >> Networks, Corp. Any review, retransmission, dissemination=20 > or other=20 > >> use of, or taking of any action in reliance upon this=20 > e-mail and its=20 > >> attachments by persons or entities other than the intended=20 > recipient=20 > >> is prohibited. If you are not the intended recipient,=20 > please notify=20 > >> the sender immediately -- by replying to this message or=20 > by sending=20 > >> an email to postmaster@starentnetworks.com -- and destroy=20 > all copies=20 > >> of this message and any attachments without reading or disclosing=20 > >> their contents. Thank you." > >>=20 > >=20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 22 03:26:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJaT-00073S-F0; Thu, 22 Jun 2006 03:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtJaR-00073N-Vg for mip4@ietf.org; Thu, 22 Jun 2006 03:26:47 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtJaP-0004hQ-Db for mip4@ietf.org; Thu, 22 Jun 2006 03:26:47 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 22 Jun 2006 13:21:03 -0700 X-IronPort-AV: i="4.06,164,1149490800"; d="scan'208"; a="69569977:sNHT36173932" Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5M7Qe6D022826; Thu, 22 Jun 2006 15:26:41 +0800 (CST) Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 22 Jun 2006 15:26:40 +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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 22 Jun 2006 15:26:38 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765012CBB5F@xmb-hkg-416.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVc1DfUCjXk4gbTvSsUTW4unIXTQAE+0mgABCIeTA= From: "Yoshi Tsuda \(yotsuda\)" To: "Kent Leung \(kleung\)" , "Henrik Levkowetz" X-OriginalArrivalTime: 22 Jun 2006 07:26:40.0400 (UTC) FILETIME=[343EC100:01C695CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Henrik, I have the same opinion with Kent; the RFC3344 has already provided the method. And, I have another concern, if an HA or an FA should reply an RRP to an MN even without having an SA: - A malicious host could send an RRQ with any home address or NAI to an HA or an FA. Then, you know, the HA or the FA needs to reply an RRP to the specified CoA, even if the host of the CoA isn't using Mobile IP service. This could produce another kind of security problem. :( Thanks. -Yoshi > -----Original Message----- > From: Kent Leung (kleung)=20 > Sent: Thursday, June 22, 2006 3:43 PM > To: Henrik Levkowetz > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator fails >=20 > Hi Henrik. I think the protocol can already handle=20 > authentication failures sufficiently. >=20 > It's possible for MN to have multiple security contexts=20 > (indexed by different SPIs) with the HA. One could be used=20 > for registration and the other for authenticating RRP with=20 > error code 131. So I believe RFC 3344 provides the mechanism=20 > already. As long as HA has an SA that can be used to protect=20 > the RRP with the MN-HA AE, it can inform the MN such event=20 > happened in a secure manner. >=20 > I think mucking with the MN-HA AE is not good. This can=20 > create the situation when MN sends a valid RRQ, and MITM can=20 > send a RRP with error code 131 and invalid MN-HA AE to the MN=20 > immediately. When the RRP is received, the MN will stop=20 > retrying. It's possible that the RRQ was lost in transit to=20 > the HA. And even if the valid RRP arrives later, MN may not=20 > be able to associate with the any pending RRQ, which could=20 > have been possibly removed since an associated RRP had been=20 > received already. >=20 > Kent >=20 > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 1:43 PM > > To: Kent Leung (kleung) > > Cc: Mobile IPv4 Mailing List > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator=20 > > fails > >=20 > > Hi Kent, > >=20 > > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > > If there is no SA, then I don't think HA should send a RRP.=20 > >=20 > > Maybe, but it leaves the MN and user with less information=20 > than it/he=20 > > could have. I think that the best would be if we could find a=20 > > standard way of handling this situation. > >=20 > > Fwiw, this has come up before, we discussed how to handle this at=20 > > ipUnplugged some time ago - it's a real situation when=20 > you're setting=20 > > up and deploying a network. > >=20 > > Regards, > >=20 > > Henrik > >=20 > > > Kent > > >=20 > > >> -----Original Message----- > > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > >> Sent: Wednesday, June 21, 2006 10:05 AM > > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> fails > > >>=20 > > >> Kent/Avi, > > >>=20 > > >> The current text does not say that the HA cannot send RRP > > when auth > > >> fails. Rather it says that the HA "SHOULD" send RRP back=20 > to the MN: > > >>=20 > > >> > if the Authenticator is invalid, the home agent MUST=20 > reject the=20 > > >> > mobile node's registration and SHOULD send a > > Registration Reply to > > >> > the mobile node with Code 131" > > >>=20 > > >> What we need is a proper description of the HA and the MN > > behaviors > > >> when the auth fails and the HA needs to send a RRP to=20 > stop the MN=20 > > >> from re-trying unnecessarily. > > >>=20 > > >> The clarification could be:=20 > > >>=20 > > >> If the Authenticator is invalid, the home agent MUST reject the=20 > > >> mobile node's registration and SHOULD send a=20 > Registration Reply to=20 > > >> the mobile node with Code 131. In this case, the HA=20 > populates the=20 > > >> MN-HA AE with all 0s. Upon receiving the RRP with error > > code 131, the > > >> MN skips MN-HA AE validation and stops retrying registration=20 > > >> attempts. The MN MAY log this event in its internal log. > > >>=20 > > >> What do you think? > > >>=20 > > >> -Kuntal > > >>=20 > > >> > -----Original Message----- > > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > >> > Sent: Wednesday, June 21, 2006 11:43 AM > > >> > To: Avi Lior; Mobile IPv4 Mailing List > > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > fails > > >> >=20 > > >> > Hi Avi. My understanding is that in this case, the HA > > will not be > > >> > able to send an RRP if it does not have an SA with the > > MN because > > >> > this message requires MN-HA AE. The text state that if HA has > > >> an SA, then > > >> to > > >> > use that in the RRP. Without an SA, the HA should drop > > the RRQ, IMHO. > > >> >=20 > > >> > Kent > > >> >=20 > > >> > > -----Original Message----- > > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > > >> > > To: Mobile IPv4 Mailing List > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > > fails > > >> > > > > >> > > Hi, > > >> > > > > >> > > While working a scenario in WiMAX I have run into some > > ambiguity > > >> > > in RFC3344. > > >> > > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI =20 > extension=20 > > >> > > which it fails to authenticate. In particular the HA cant=20 > > >> > > authenticate because it can't obtain the MN-HA from > > the AAA using the NAI. > > >> > > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > > >> > > Reply should be > > >> > > sent with code 131. > > >> > > > > >> > > "if the Authenticator is invalid, the home agent MUST > > reject the > > >> > > mobile node's registration and SHOULD send a > > Registration Reply > > >> > > to the mobile node with Code 131" > > >> > > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > > >> > > > > >> > > "If the Code field indicates an authentication failure,=20 > > >> > > either at the > > >> > > foreign agent or the home agent, then it is quite > > possible that any > > >> > > authenticators in the Registration Reply will also > > be in error. =20 > > >> > > This > > >> > > could happen, for example, if the shared secret > > between the mobile > > >> > > node and home agent was erroneously configured. =20 > > The mobile node > > >> > > SHOULD log such errors as security exceptions." > > >> > > > > >> > > RFC3344 also states that Registration Reply MUST > > include a MN-HA > > >> > > authentication extension: > > >> > > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) > > MUST appear > > >> > > in every Registration Reply sent by the home agent." > > >> > > > > >> > > where (c) is The Mobile-Home Authentication Extension. > > >> > > > > >> > > The problem is that when MN-HA-AE fails at the HA > > there isnt an > > >> > > available MN-HA authentication extension to use. So > > how can one > > >> > > send a registration reply? > > >> > > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for > > the mobile, > > >> > > what should happen? > > >> > > > > >> > > > > >> > > Any help will be appreciated. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > >> > > > > >> > > Avi Lior > > >> > > Bridgewater Systems Corporation Phone : +1 (613) 591-9104=20 > > >> > > x6417 > > >> > > Cell : +1 (613) 796-4183 > > >> > > E-mail : mailto:avi@bridgewatersystems.com=20 > > >> > > > > >> > > www.bridgewatersystems.com=20 > > > >> > > > > >> > > > > >> > > -- > > >> > > Mip4 mailing list: Mip4@ietf.org > > >> > > Web interface:=20 > https://www1.ietf.org/mailman/listinfo/mip4 > > >> > > Charter page:=20 > > >> > > http://www.ietf.org/html.charters/mip4-charter.html > > >> > > Supplemental site: http://www.mip4.org/ > > >> > > > > >> >=20 > > >> > -- > > >> > Mip4 mailing list: Mip4@ietf.org > > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > Charter page: =20 > > >> > http://www.ietf.org/html.charters/mip4-charter.html > > >> > Supplemental site: http://www.mip4.org/ > > >>=20 > > >>=20 > > >> "This email message and any attachments are confidential > > information > > >> of Starent Networks, Corp. The information transmitted=20 > may not be=20 > > >> used to create or change any contractual obligations of Starent=20 > > >> Networks, Corp. Any review, retransmission, dissemination > > or other > > >> use of, or taking of any action in reliance upon this > > e-mail and its > > >> attachments by persons or entities other than the intended > > recipient > > >> is prohibited. If you are not the intended recipient, > > please notify > > >> the sender immediately -- by replying to this message or > > by sending > > >> an email to postmaster@starentnetworks.com -- and destroy > > all copies > > >> of this message and any attachments without reading or=20 > disclosing=20 > > >> their contents. Thank you." > > >>=20 > > >=20 > >=20 > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 22 04:09:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKFK-0006dL-RW; Thu, 22 Jun 2006 04:09:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKFK-0006aZ-4i for mip4@ietf.org; Thu, 22 Jun 2006 04:09:02 -0400 Received: from av10-2-sn2.hy.skanova.net ([81.228.8.182]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtKFG-0003D3-5r for mip4@ietf.org; Thu, 22 Jun 2006 04:09:02 -0400 Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 42D7538463; Thu, 22 Jun 2006 10:08:55 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 2D33E38463; Thu, 22 Jun 2006 10:08:55 +0200 (CEST) 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 D0BCB37E42; Thu, 22 Jun 2006 10:08:54 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FtKF7-0003Mm-37; Thu, 22 Jun 2006 10:08:54 +0200 Message-ID: <449A5009.9050405@levkowetz.com> Date: Thu, 22 Jun 2006 10:08:41 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails References: <2979E38DD6FC6544B789C8DAD7BAFC52020622AC@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52020622AC@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0321931204==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0321931204== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0552C8BE8F8AEDBFCB161E7D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0552C8BE8F8AEDBFCB161E7D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kent, on 2006-06-22 08:43 Kent Leung (kleung) said the following: > Hi Henrik. I think the protocol can already handle authentication > failures sufficiently. Well, I'm not quite as convinced :-) > It's possible for MN to have multiple security contexts (indexed by > different SPIs) with the HA. One could be used for registration and th= e > other for authenticating RRP with error code 131. But this assumes that you've actually managed to set things up correctly.= In which case I don't see why you couldn't manage with only one context. No, the problem I'm concerned with is primarily with the case when you're= first rolling out a service, and haven't smoothed out all the wrinkles - the case where something has gone wrong, and you either can get some information through to the user device, or you can't. > So I believe RFC 3344 > provides the mechanism already. As long as HA has an SA that can be > used to protect the RRP with the MN-HA AE, it can inform the MN such > event happened in a secure manner. Yes, sure - but that's not the use case under consideration, as indicated= above. > I think mucking with the MN-HA AE is not good. This can create the > situation when MN sends a valid RRQ, and MITM can send a RRP with error= > code 131 and invalid MN-HA AE to the MN immediately. Oh, agreed! I'm not suggesting that we should permit that - I'm trying to point out that there actually is a problem here, and we should see if we can solve it, rather than closing our eyes to it... > When the RRP is > received, the MN will stop retrying. Well, it shouldn't do that if it gets an un-authenticated reply. That doesn't mean that the reply shouldn't be sent; and it also doesn't mean that some indication can't be made to a log-file and the user. > It's possible that the RRQ was > lost in transit to the HA. And even if the valid RRP arrives later, MN= > may not be able to associate with the any pending RRQ, which could have= > been possibly removed since an associated RRP had been received already= =2E Yes. So there are very good reasons not to accept an un-authenticated reply. Now, what can we do to alleviate the problem which exists when there actually is a mismatch in authentication setup? Henrik > Kent >=20 >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 >> Sent: Wednesday, June 21, 2006 1:43 PM >> To: Kent Leung (kleung) >> Cc: Mobile IPv4 Mailing List >> Subject: Re: [Mip4] 3344 Sending a Reg Reply when the=20 >> Authenticator fails >>=20 >> Hi Kent, >>=20 >> on 2006-06-21 19:13 Kent Leung (kleung) said the following: >> > If there is no SA, then I don't think HA should send a RRP.=20 >>=20 >> Maybe, but it leaves the MN and user with less information=20 >> than it/he could have. I think that the best would be if we=20 >> could find a standard way of handling this situation. >>=20 >> Fwiw, this has come up before, we discussed how to handle=20 >> this at ipUnplugged some time ago - it's a real situation=20 >> when you're setting up and deploying a network. >>=20 >> Regards, >>=20 >> Henrik >>=20 >> > Kent >> >=20 >> >> -----Original Message----- >> >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >> >> Sent: Wednesday, June 21, 2006 10:05 AM >> >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List >> >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticato= r=20 >> >> fails >> >>=20 >> >> Kent/Avi, >> >>=20 >> >> The current text does not say that the HA cannot send RRP when aut= h=20 >> >> fails. Rather it says that the HA "SHOULD" send RRP back to the MN:= >> >>=20 >> >> > if the Authenticator is invalid, the home agent MUST reject the = >> >> > mobile node's registration and SHOULD send a Registration Reply = to=20 >> >> > the mobile node with Code 131" >> >>=20 >> >> What we need is a proper description of the HA and the MN behavior= s=20 >> >> when the auth fails and the HA needs to send a RRP to stop the MN=20 >> >> from re-trying unnecessarily. >> >>=20 >> >> The clarification could be:=20 >> >>=20 >> >> If the Authenticator is invalid, the home agent MUST reject the=20 >> >> mobile node's registration and SHOULD send a Registration Reply to = >> >> the mobile node with Code 131. In this case, the HA populates the=20 >> >> MN-HA AE with all 0s. Upon receiving the RRP with error code 131, = the=20 >> >> MN skips MN-HA AE validation and stops retrying registration=20 >> >> attempts. The MN MAY log this event in its internal log. >> >>=20 >> >> What do you think? >> >>=20 >> >> -Kuntal >> >>=20 >> >> > -----Original Message----- >> >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] >> >> > Sent: Wednesday, June 21, 2006 11:43 AM >> >> > To: Avi Lior; Mobile IPv4 Mailing List >> >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authentica= tor=20 >> >> > fails >> >> >=20 >> >> > Hi Avi. My understanding is that in this case, the HA will not = be=20 >> >> > able to send an RRP if it does not have an SA with the MN becaus= e=20 >> >> > this message requires MN-HA AE. The text state that if HA has >> >> an SA, then >> >> to >> >> > use that in the RRP. Without an SA, the HA should drop the RRQ= , IMHO. >> >> >=20 >> >> > Kent >> >> >=20 >> >> > > -----Original Message----- >> >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] >> >> > > Sent: Wednesday, June 21, 2006 8:13 AM >> >> > > To: Mobile IPv4 Mailing List >> >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the Authenticato= r=20 >> >> > > fails >> >> > > >> >> > > Hi, >> >> > > >> >> > > While working a scenario in WiMAX I have run into some ambigui= ty=20 >> >> > > in RFC3344. >> >> > > >> >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension = >> >> > > which it fails to authenticate. In particular the HA cant=20 >> >> > > authenticate because it can't obtain the MN-HA from the AAA us= ing the NAI. >> >> > > >> >> > > >From section 3.8.2.1 RFC3344 states that a Registration >> >> > > Reply should be >> >> > > sent with code 131. >> >> > > >> >> > > "if the Authenticator is invalid, the home agent MUST reject t= he=20 >> >> > > mobile node's registration and SHOULD send a Registration Rep= ly=20 >> >> > > to the mobile node with Code 131" >> >> > > >> >> > > And from section 3.6.2.1 describing the MN behavior we have: >> >> > > >> >> > > "If the Code field indicates an authentication failure,=20 >> >> > > either at the >> >> > > foreign agent or the home agent, then it is quite possible = that any >> >> > > authenticators in the Registration Reply will also be in e= rror. =20 >> >> > > This >> >> > > could happen, for example, if the shared secret between the= mobile >> >> > > node and home agent was erroneously configured. The mobil= e node >> >> > > SHOULD log such errors as security exceptions." >> >> > > >> >> > > RFC3344 also states that Registration Reply MUST include a MN-= HA=20 >> >> > > authentication extension: >> >> > > >> >> > > Section 3.8.3.3 says " Note that items (a) and (c) MUST appe= ar=20 >> >> > > in every Registration Reply sent by the home agent." >> >> > > >> >> > > where (c) is The Mobile-Home Authentication Extension. >> >> > > >> >> > > The problem is that when MN-HA-AE fails at the HA there isnt a= n=20 >> >> > > available MN-HA authentication extension to use. So how can o= ne=20 >> >> > > send a registration reply? >> >> > > >> >> > > Furthermore, if the HA cant not obtain an MN-HA for the mobil= e,=20 >> >> > > what should happen? >> >> > > >> >> > > >> >> > > Any help will be appreciated. >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> >> > > >> >> > > Avi Lior >> >> > > Bridgewater Systems Corporation >> >> > > Phone : +1 (613) 591-9104 x6417 >> >> > > Cell : +1 (613) 796-4183 >> >> > > E-mail : mailto:avi@bridgewatersystems.com=20 >> >> > > >> >> > > www.bridgewatersystems.com = >> >> > > >> >> > > >> >> > > -- >> >> > > Mip4 mailing list: Mip4@ietf.org >> >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> >> > > Charter page:=20 >> >> > > http://www.ietf.org/html.charters/mip4-charter.html >> >> > > Supplemental site: http://www.mip4.org/ >> >> > > >> >> >=20 >> >> > -- >> >> > Mip4 mailing list: Mip4@ietf.org >> >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> >> > Charter page: =20 >> >> > http://www.ietf.org/html.charters/mip4-charter.html >> >> > Supplemental site: http://www.mip4.org/ >> >>=20 >> >>=20 >> >> "This email message and any attachments are confidential informati= on=20 >> >> of Starent Networks, Corp. The information transmitted may not be=20 >> >> used to create or change any contractual obligations of Starent=20 >> >> Networks, Corp. Any review, retransmission, dissemination or othe= r=20 >> >> use of, or taking of any action in reliance upon this e-mail and i= ts=20 >> >> attachments by persons or entities other than the intended recipie= nt=20 >> >> is prohibited. If you are not the intended recipient, please notif= y=20 >> >> the sender immediately -- by replying to this message or by sendin= g=20 >> >> an email to postmaster@starentnetworks.com -- and destroy all copi= es=20 >> >> of this message and any attachments without reading or disclosing=20 >> >> their contents. Thank you." >> >>=20 >> >=20 >>=20 >>=20 >=20 --------------enig0552C8BE8F8AEDBFCB161E7D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEmlAQeVhrtTJkXCMRAhdzAKChuQ1vQ78kCjgLQCDh4ldo0HwbmwCfcg9p qtdlkwkFe7z97R4sZde4vbU= =f8vC -----END PGP SIGNATURE----- --------------enig0552C8BE8F8AEDBFCB161E7D-- --===============0321931204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0321931204==-- From mip4-bounces@ietf.org Thu Jun 22 04:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKIC-0001QS-KX; Thu, 22 Jun 2006 04:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtKIB-0001Kn-Cf for mip4@ietf.org; Thu, 22 Jun 2006 04:11:59 -0400 Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtKIA-0003YG-HU for mip4@ietf.org; Thu, 22 Jun 2006 04:11:59 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id B5B6F384AC; Thu, 22 Jun 2006 10:11:57 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A4CF03844C; Thu, 22 Jun 2006 10:11:57 +0200 (CEST) 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 31A7537E55; Thu, 22 Jun 2006 10:11:57 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FtKI8-0003do-L6; Thu, 22 Jun 2006 10:11:56 +0200 Message-ID: <449A50CB.9020702@levkowetz.com> Date: Thu, 22 Jun 2006 10:11:55 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: "Yoshi Tsuda (yotsuda)" Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails References: <35912544FC930E49BF20EF16C3EF2765012CBB5F@xmb-hkg-416.apac.cisco.com> In-Reply-To: <35912544FC930E49BF20EF16C3EF2765012CBB5F@xmb-hkg-416.apac.cisco.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1189480285==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1189480285== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig68F5A74AF58527E7EF10E58A" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig68F5A74AF58527E7EF10E58A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Yoshi, on 2006-06-22 09:26 Yoshi Tsuda (yotsuda) said the following: > Hi Henrik, >=20 > I have the same opinion with Kent; the RFC3344 has already > provided the method. Here we disagree. See my recent mail to Kent and the list. > And, I have another concern, if an HA or an FA should reply > an RRP to an MN even without having an SA: > - A malicious host could send an RRQ with any home address > or NAI to an HA or an FA. Then, you know, the HA or the FA > needs to reply an RRP to the specified CoA, even if the host > of the CoA isn't using Mobile IP service. This could produce > another kind of security problem. :( Agreed. This is a valid point, and has to be taken into consideration in any proposed solution to the original problem. Which still doesn't mean that we can ignore that problem. Regards, Henrik >=20 > Thanks. > -Yoshi >=20 >> -----Original Message----- >> From: Kent Leung (kleung)=20 >> Sent: Thursday, June 22, 2006 3:43 PM >> To: Henrik Levkowetz >> Cc: Mobile IPv4 Mailing List >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 >> Authenticator fails >>=20 >> Hi Henrik. I think the protocol can already handle=20 >> authentication failures sufficiently. >>=20 >> It's possible for MN to have multiple security contexts=20 >> (indexed by different SPIs) with the HA. One could be used=20 >> for registration and the other for authenticating RRP with=20 >> error code 131. So I believe RFC 3344 provides the mechanism=20 >> already. As long as HA has an SA that can be used to protect=20 >> the RRP with the MN-HA AE, it can inform the MN such event=20 >> happened in a secure manner. >>=20 >> I think mucking with the MN-HA AE is not good. This can=20 >> create the situation when MN sends a valid RRQ, and MITM can=20 >> send a RRP with error code 131 and invalid MN-HA AE to the MN=20 >> immediately. When the RRP is received, the MN will stop=20 >> retrying. It's possible that the RRQ was lost in transit to=20 >> the HA. And even if the valid RRP arrives later, MN may not=20 >> be able to associate with the any pending RRQ, which could=20 >> have been possibly removed since an associated RRP had been=20 >> received already. >>=20 >> Kent >>=20 >> > -----Original Message----- >> > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> > Sent: Wednesday, June 21, 2006 1:43 PM >> > To: Kent Leung (kleung) >> > Cc: Mobile IPv4 Mailing List >> > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator = >> > fails >> >=20 >> > Hi Kent, >> >=20 >> > on 2006-06-21 19:13 Kent Leung (kleung) said the following: >> > > If there is no SA, then I don't think HA should send a RRP.=20 >> >=20 >> > Maybe, but it leaves the MN and user with less information=20 >> than it/he=20 >> > could have. I think that the best would be if we could find a=20 >> > standard way of handling this situation. >> >=20 >> > Fwiw, this has come up before, we discussed how to handle this at=20 >> > ipUnplugged some time ago - it's a real situation when=20 >> you're setting=20 >> > up and deploying a network. >> >=20 >> > Regards, >> >=20 >> > Henrik >> >=20 >> > > Kent >> > >=20 >> > >> -----Original Message----- >> > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] >> > >> Sent: Wednesday, June 21, 2006 10:05 AM >> > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List >> > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the >> > Authenticator >> > >> fails >> > >>=20 >> > >> Kent/Avi, >> > >>=20 >> > >> The current text does not say that the HA cannot send RRP >> > when auth >> > >> fails. Rather it says that the HA "SHOULD" send RRP back=20 >> to the MN: >> > >>=20 >> > >> > if the Authenticator is invalid, the home agent MUST=20 >> reject the=20 >> > >> > mobile node's registration and SHOULD send a >> > Registration Reply to >> > >> > the mobile node with Code 131" >> > >>=20 >> > >> What we need is a proper description of the HA and the MN >> > behaviors >> > >> when the auth fails and the HA needs to send a RRP to=20 >> stop the MN=20 >> > >> from re-trying unnecessarily. >> > >>=20 >> > >> The clarification could be:=20 >> > >>=20 >> > >> If the Authenticator is invalid, the home agent MUST reject the=20 >> > >> mobile node's registration and SHOULD send a=20 >> Registration Reply to=20 >> > >> the mobile node with Code 131. In this case, the HA=20 >> populates the=20 >> > >> MN-HA AE with all 0s. Upon receiving the RRP with error >> > code 131, the >> > >> MN skips MN-HA AE validation and stops retrying registration=20 >> > >> attempts. The MN MAY log this event in its internal log. >> > >>=20 >> > >> What do you think? >> > >>=20 >> > >> -Kuntal >> > >>=20 >> > >> > -----Original Message----- >> > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] >> > >> > Sent: Wednesday, June 21, 2006 11:43 AM >> > >> > To: Avi Lior; Mobile IPv4 Mailing List >> > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the >> > Authenticator >> > >> > fails >> > >> >=20 >> > >> > Hi Avi. My understanding is that in this case, the HA >> > will not be >> > >> > able to send an RRP if it does not have an SA with the >> > MN because >> > >> > this message requires MN-HA AE. The text state that if HA has >> > >> an SA, then >> > >> to >> > >> > use that in the RRP. Without an SA, the HA should drop >> > the RRQ, IMHO. >> > >> >=20 >> > >> > Kent >> > >> >=20 >> > >> > > -----Original Message----- >> > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] >> > >> > > Sent: Wednesday, June 21, 2006 8:13 AM >> > >> > > To: Mobile IPv4 Mailing List >> > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the >> > Authenticator >> > >> > > fails >> > >> > > >> > >> > > Hi, >> > >> > > >> > >> > > While working a scenario in WiMAX I have run into some >> > ambiguity >> > >> > > in RFC3344. >> > >> > > >> > >> > > The HA receives a Reg Request with MN-HA-AE and NAI =20 >> extension=20 >> > >> > > which it fails to authenticate. In particular the HA cant=20 >> > >> > > authenticate because it can't obtain the MN-HA from >> > the AAA using the NAI. >> > >> > > >> > >> > > >From section 3.8.2.1 RFC3344 states that a Registration >> > >> > > Reply should be >> > >> > > sent with code 131. >> > >> > > >> > >> > > "if the Authenticator is invalid, the home agent MUST >> > reject the >> > >> > > mobile node's registration and SHOULD send a >> > Registration Reply >> > >> > > to the mobile node with Code 131" >> > >> > > >> > >> > > And from section 3.6.2.1 describing the MN behavior we have: >> > >> > > >> > >> > > "If the Code field indicates an authentication failure,=20 >> > >> > > either at the >> > >> > > foreign agent or the home agent, then it is quite >> > possible that any >> > >> > > authenticators in the Registration Reply will also >> > be in error. =20 >> > >> > > This >> > >> > > could happen, for example, if the shared secret >> > between the mobile >> > >> > > node and home agent was erroneously configured. =20 >> > The mobile node >> > >> > > SHOULD log such errors as security exceptions." >> > >> > > >> > >> > > RFC3344 also states that Registration Reply MUST >> > include a MN-HA >> > >> > > authentication extension: >> > >> > > >> > >> > > Section 3.8.3.3 says " Note that items (a) and (c) >> > MUST appear >> > >> > > in every Registration Reply sent by the home agent." >> > >> > > >> > >> > > where (c) is The Mobile-Home Authentication Extension. >> > >> > > >> > >> > > The problem is that when MN-HA-AE fails at the HA >> > there isnt an >> > >> > > available MN-HA authentication extension to use. So >> > how can one >> > >> > > send a registration reply? >> > >> > > >> > >> > > Furthermore, if the HA cant not obtain an MN-HA for >> > the mobile, >> > >> > > what should happen? >> > >> > > >> > >> > > >> > >> > > Any help will be appreciated. >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >> > >> > > >> > >> > > Avi Lior >> > >> > > Bridgewater Systems Corporation Phone : +1 (613) 591-9104=20 >> > >> > > x6417 >> > >> > > Cell : +1 (613) 796-4183 >> > >> > > E-mail : mailto:avi@bridgewatersystems.com=20 >> > >> > > >> > >> > > www.bridgewatersystems.com=20 >> >> > >> > > >> > >> > > >> > >> > > -- >> > >> > > Mip4 mailing list: Mip4@ietf.org >> > >> > > Web interface:=20 >> https://www1.ietf.org/mailman/listinfo/mip4 >> > >> > > Charter page:=20 >> > >> > > http://www.ietf.org/html.charters/mip4-charter.html >> > >> > > Supplemental site: http://www.mip4.org/ >> > >> > > >> > >> >=20 >> > >> > -- >> > >> > Mip4 mailing list: Mip4@ietf.org >> > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> > >> > Charter page: =20 >> > >> > http://www.ietf.org/html.charters/mip4-charter.html >> > >> > Supplemental site: http://www.mip4.org/ >> > >>=20 >> > >>=20 >> > >> "This email message and any attachments are confidential >> > information >> > >> of Starent Networks, Corp. The information transmitted=20 >> may not be=20 >> > >> used to create or change any contractual obligations of Starent=20 >> > >> Networks, Corp. Any review, retransmission, dissemination >> > or other >> > >> use of, or taking of any action in reliance upon this >> > e-mail and its >> > >> attachments by persons or entities other than the intended >> > recipient >> > >> is prohibited. If you are not the intended recipient, >> > please notify >> > >> the sender immediately -- by replying to this message or >> > by sending >> > >> an email to postmaster@starentnetworks.com -- and destroy >> > all copies >> > >> of this message and any attachments without reading or=20 >> disclosing=20 >> > >> their contents. Thank you." >> > >>=20 >> > >=20 >> >=20 >> >=20 >>=20 >> -- >> Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html= >> Supplemental site: http://www.mip4.org/ >>=20 >=20 --------------enig68F5A74AF58527E7EF10E58A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEmlDMeVhrtTJkXCMRAnNNAKCgClVpcwqjErdTsNiMlG0o+icI4QCfSjvR df33zIzvyNFk2tz7BHFyZKM= =8Lg5 -----END PGP SIGNATURE----- --------------enig68F5A74AF58527E7EF10E58A-- --===============1189480285== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1189480285==-- From mip4-bounces@ietf.org Thu Jun 22 11:51:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRSZ-00033y-I5; Thu, 22 Jun 2006 11:51:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtRSY-00033n-Eu for mip4@ietf.org; Thu, 22 Jun 2006 11:51:10 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtRSV-0004yX-L4 for mip4@ietf.org; Thu, 22 Jun 2006 11:51:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 493DD9000D for ; Thu, 22 Jun 2006 11:51:04 -0400 (EDT) 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 14740-01 for ; Thu, 22 Jun 2006 11:51:02 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 22 Jun 2006 11:51:02 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jun 2006 11:48:03 -0400 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 22 Jun 2006 11:48:03 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51C8@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVc1DfUCjXk4gbTvSsUTW4unIXTQAE+0mgACJTqmA= From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" X-OriginalArrivalTime: 22 Jun 2006 15:48:03.0839 (UTC) FILETIME=[3F5F40F0:01C69613] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac Cc: Mobile IPv4 Mailing List , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Thursday, June 22, 2006 1:43 AM > To: Henrik Levkowetz > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi Henrik. I think the protocol can already handle authentication > failures sufficiently. >=20 > It's possible for MN to have multiple security contexts (indexed by > different SPIs) with the HA. One could be used for registration and the > other for authenticating RRP with error code 131. So I believe RFC 3344 > provides the mechanism already. As long as HA has an SA that can be > used to protect the RRP with the MN-HA AE, it can inform the MN such > event happened in a secure manner. >=20 > I think mucking with the MN-HA AE is not good. This can create the > situation when MN sends a valid RRQ, and MITM can send a RRP with error > code 131 and invalid MN-HA AE to the MN immediately. When the RRP is > received, the MN will stop retrying. It's possible that the RRQ was > lost in transit to the HA. And even if the valid RRP arrives later, MN > may not be able to associate with the any pending RRQ, which could have > been possibly removed since an associated RRP had been received already. >=20 [KC>] If the HA does not send RRP back to the MN, as you initially suggested, the MN will keep retrying. That is not good either. Look at other protocols. For example EAP, if auth fails, the authenticator MUST send back a failure packet to the peer. Same case for other protocols over UNI. So, I am wondering why the paranoids are not concerned about MiTM and DoS attacks in general! Regarding your comment "mucking with the MN-HA AE is not good", if MN-HA AE is not absolutely necessary in the RRP messages, I will be more than happy to propose that when code 131 is included, the RRP contains no MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a better suggestion that does not break current implementations, and does not produce a new mip4 protocol, I don't think we have a choice here. > Kent >=20 > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 1:43 PM > > To: Kent Leung (kleung) > > Cc: Mobile IPv4 Mailing List > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator fails > > > > Hi Kent, > > > > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > > If there is no SA, then I don't think HA should send a RRP. > > > > Maybe, but it leaves the MN and user with less information > > than it/he could have. I think that the best would be if we > > could find a standard way of handling this situation. > > > > Fwiw, this has come up before, we discussed how to handle > > this at ipUnplugged some time ago - it's a real situation > > when you're setting up and deploying a network. > > > > Regards, > > > > Henrik > > > > > Kent > > > > > >> -----Original Message----- > > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > >> Sent: Wednesday, June 21, 2006 10:05 AM > > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> fails > > >> > > >> Kent/Avi, > > >> > > >> The current text does not say that the HA cannot send RRP > > when auth > > >> fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > > >> > > >> > if the Authenticator is invalid, the home agent MUST reject the > > >> > mobile node's registration and SHOULD send a > > Registration Reply to > > >> > the mobile node with Code 131" > > >> > > >> What we need is a proper description of the HA and the MN > > behaviors > > >> when the auth fails and the HA needs to send a RRP to stop the MN > > >> from re-trying unnecessarily. > > >> > > >> The clarification could be: > > >> > > >> If the Authenticator is invalid, the home agent MUST reject the > > >> mobile node's registration and SHOULD send a Registration Reply to > > >> the mobile node with Code 131. In this case, the HA populates the > > >> MN-HA AE with all 0s. Upon receiving the RRP with error > > code 131, the > > >> MN skips MN-HA AE validation and stops retrying registration > > >> attempts. The MN MAY log this event in its internal log. > > >> > > >> What do you think? > > >> > > >> -Kuntal > > >> > > >> > -----Original Message----- > > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > >> > Sent: Wednesday, June 21, 2006 11:43 AM > > >> > To: Avi Lior; Mobile IPv4 Mailing List > > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > fails > > >> > > > >> > Hi Avi. My understanding is that in this case, the HA > > will not be > > >> > able to send an RRP if it does not have an SA with the > > MN because > > >> > this message requires MN-HA AE. The text state that if HA has > > >> an SA, then > > >> to > > >> > use that in the RRP. Without an SA, the HA should drop > > the RRQ, IMHO. > > >> > > > >> > Kent > > >> > > > >> > > -----Original Message----- > > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > > >> > > To: Mobile IPv4 Mailing List > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > > fails > > >> > > > > >> > > Hi, > > >> > > > > >> > > While working a scenario in WiMAX I have run into some > > ambiguity > > >> > > in RFC3344. > > >> > > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > >> > > which it fails to authenticate. In particular the HA cant > > >> > > authenticate because it can't obtain the MN-HA from > > the AAA using the NAI. > > >> > > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > > >> > > Reply should be > > >> > > sent with code 131. > > >> > > > > >> > > "if the Authenticator is invalid, the home agent MUST > > reject the > > >> > > mobile node's registration and SHOULD send a > > Registration Reply > > >> > > to the mobile node with Code 131" > > >> > > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > > >> > > > > >> > > "If the Code field indicates an authentication failure, > > >> > > either at the > > >> > > foreign agent or the home agent, then it is quite > > possible that any > > >> > > authenticators in the Registration Reply will also > > be in error. > > >> > > This > > >> > > could happen, for example, if the shared secret > > between the mobile > > >> > > node and home agent was erroneously configured. > > The mobile node > > >> > > SHOULD log such errors as security exceptions." > > >> > > > > >> > > RFC3344 also states that Registration Reply MUST > > include a MN-HA > > >> > > authentication extension: > > >> > > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) > > MUST appear > > >> > > in every Registration Reply sent by the home agent." > > >> > > > > >> > > where (c) is The Mobile-Home Authentication Extension. > > >> > > > > >> > > The problem is that when MN-HA-AE fails at the HA > > there isnt an > > >> > > available MN-HA authentication extension to use. So > > how can one > > >> > > send a registration reply? > > >> > > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for > > the mobile, > > >> > > what should happen? > > >> > > > > >> > > > > >> > > Any help will be appreciated. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > >> > > > > >> > > Avi Lior > > >> > > Bridgewater Systems Corporation > > >> > > Phone : +1 (613) 591-9104 x6417 > > >> > > Cell : +1 (613) 796-4183 > > >> > > E-mail : mailto:avi@bridgewatersystems.com > > >> > > > > >> > > www.bridgewatersystems.com > > >> > > > > >> > > > > >> > > -- > > >> > > Mip4 mailing list: Mip4@ietf.org > > >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > > Charter page: > > >> > > http://www.ietf.org/html.charters/mip4-charter.html > > >> > > Supplemental site: http://www.mip4.org/ > > >> > > > > >> > > > >> > -- > > >> > Mip4 mailing list: Mip4@ietf.org > > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > Charter page: > > >> > http://www.ietf.org/html.charters/mip4-charter.html > > >> > Supplemental site: http://www.mip4.org/ > > >> > > >> > > >> "This email message and any attachments are confidential > > information > > >> of Starent Networks, Corp. The information transmitted may not be > > >> used to create or change any contractual obligations of Starent > > >> Networks, Corp. Any review, retransmission, dissemination > > or other > > >> use of, or taking of any action in reliance upon this > > e-mail and its > > >> attachments by persons or entities other than the intended > > recipient > > >> is prohibited. If you are not the intended recipient, > > please notify > > >> the sender immediately -- by replying to this message or > > by sending > > >> an email to postmaster@starentnetworks.com -- and destroy > > all copies > > >> of this message and any attachments without reading or disclosing > > >> their contents. Thank you." > > >> > > > > > > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 22 14:06:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTZC-0006Tg-Ch; Thu, 22 Jun 2006 14:06:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTZA-0006Ta-St for mip4@ietf.org; Thu, 22 Jun 2006 14:06:08 -0400 Received: from web60315.mail.yahoo.com ([209.73.178.138]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FtTZ9-0004SR-0T for mip4@ietf.org; Thu, 22 Jun 2006 14:06:08 -0400 Received: (qmail 26004 invoked by uid 60001); 22 Jun 2006 18:06:00 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=eWVME2WeKeS1X/IyHRrly1huLh0S8/VqrBJschXBmh9XdAzAK80vWjf4PG3oUxLGXH56qCzS/vlEjQ196pp+HBzZ+UYKefoHoBmN7Gpu4TbdrD2zSjVx534idIT/2adlu5a84epwiQ54R75rqOAm76oHmUGvuLoZvBUnr3ClKk8= ; Message-ID: <20060622180600.26002.qmail@web60315.mail.yahoo.com> Received: from [12.129.211.52] by web60315.mail.yahoo.com via HTTP; Thu, 22 Jun 2006 11:06:00 PDT Date: Thu, 22 Jun 2006 11:06:00 -0700 (PDT) From: Behcet Sarikaya Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails To: "Chowdhury, Kuntal" , "Kent Leung \(kleung\)" In-Reply-To: <7CCD07160348804497EF29E9EA5560D73C51C8@exchtewks2.starentnetworks.com> MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Cc: Mobile IPv4 Mailing List , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Behcet Sarikaya List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0780590101==" Errors-To: mip4-bounces@ietf.org --===============0780590101== Content-Type: multipart/alternative; boundary="0-1544963828-1150999560=:25012" --0-1544963828-1150999560=:25012 Content-Type: text/plain; charset=us-ascii Hi Kuntal In WiMAX, if MS fails EAP authentication, it is out, it cannot even send an RREQ. Regards, Behcet ----- Original Message ---- From: "Chowdhury, Kuntal" To: Kent Leung (kleung) Cc: Mobile IPv4 Mailing List ; Henrik Levkowetz Sent: Thursday, June 22, 2006 10:48:03 AM Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Thursday, June 22, 2006 1:43 AM > To: Henrik Levkowetz > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails > > Hi Henrik. I think the protocol can already handle authentication > failures sufficiently. > > It's possible for MN to have multiple security contexts (indexed by > different SPIs) with the HA. One could be used for registration and the > other for authenticating RRP with error code 131. So I believe RFC 3344 > provides the mechanism already. As long as HA has an SA that can be > used to protect the RRP with the MN-HA AE, it can inform the MN such > event happened in a secure manner. > > I think mucking with the MN-HA AE is not good. This can create the > situation when MN sends a valid RRQ, and MITM can send a RRP with error > code 131 and invalid MN-HA AE to the MN immediately. When the RRP is > received, the MN will stop retrying. It's possible that the RRQ was > lost in transit to the HA. And even if the valid RRP arrives later, MN > may not be able to associate with the any pending RRQ, which could have > been possibly removed since an associated RRP had been received already. > [KC>] If the HA does not send RRP back to the MN, as you initially suggested, the MN will keep retrying. That is not good either. Look at other protocols. For example EAP, if auth fails, the authenticator MUST send back a failure packet to the peer. Same case for other protocols over UNI. So, I am wondering why the paranoids are not concerned about MiTM and DoS attacks in general! Regarding your comment "mucking with the MN-HA AE is not good", if MN-HA AE is not absolutely necessary in the RRP messages, I will be more than happy to propose that when code 131 is included, the RRP contains no MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a better suggestion that does not break current implementations, and does not produce a new mip4 protocol, I don't think we have a choice here. > Kent > > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 1:43 PM > > To: Kent Leung (kleung) > > Cc: Mobile IPv4 Mailing List > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator fails > > > > Hi Kent, > > > > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > > If there is no SA, then I don't think HA should send a RRP. > > > > Maybe, but it leaves the MN and user with less information > > than it/he could have. I think that the best would be if we > > could find a standard way of handling this situation. > > > > Fwiw, this has come up before, we discussed how to handle > > this at ipUnplugged some time ago - it's a real situation > > when you're setting up and deploying a network. > > > > Regards, > > > > Henrik > > > > > Kent > > > > > >> -----Original Message----- > > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > >> Sent: Wednesday, June 21, 2006 10:05 AM > > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> fails > > >> > > >> Kent/Avi, > > >> > > >> The current text does not say that the HA cannot send RRP > > when auth > > >> fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > > >> > > >> > if the Authenticator is invalid, the home agent MUST reject the > > >> > mobile node's registration and SHOULD send a > > Registration Reply to > > >> > the mobile node with Code 131" > > >> > > >> What we need is a proper description of the HA and the MN > > behaviors > > >> when the auth fails and the HA needs to send a RRP to stop the MN > > >> from re-trying unnecessarily. > > >> > > >> The clarification could be: > > >> > > >> If the Authenticator is invalid, the home agent MUST reject the > > >> mobile node's registration and SHOULD send a Registration Reply to > > >> the mobile node with Code 131. In this case, the HA populates the > > >> MN-HA AE with all 0s. Upon receiving the RRP with error > > code 131, the > > >> MN skips MN-HA AE validation and stops retrying registration > > >> attempts. The MN MAY log this event in its internal log. > > >> > > >> What do you think? > > >> > > >> -Kuntal > > >> > > >> > -----Original Message----- > > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > >> > Sent: Wednesday, June 21, 2006 11:43 AM > > >> > To: Avi Lior; Mobile IPv4 Mailing List > > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > fails > > >> > > > >> > Hi Avi. My understanding is that in this case, the HA > > will not be > > >> > able to send an RRP if it does not have an SA with the > > MN because > > >> > this message requires MN-HA AE. The text state that if HA has > > >> an SA, then > > >> to > > >> > use that in the RRP. Without an SA, the HA should drop > > the RRQ, IMHO. > > >> > > > >> > Kent > > >> > > > >> > > -----Original Message----- > > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > > >> > > To: Mobile IPv4 Mailing List > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > > fails > > >> > > > > >> > > Hi, > > >> > > > > >> > > While working a scenario in WiMAX I have run into some > > ambiguity > > >> > > in RFC3344. > > >> > > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > >> > > which it fails to authenticate. In particular the HA cant > > >> > > authenticate because it can't obtain the MN-HA from > > the AAA using the NAI. > > >> > > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > > >> > > Reply should be > > >> > > sent with code 131. > > >> > > > > >> > > "if the Authenticator is invalid, the home agent MUST > > reject the > > >> > > mobile node's registration and SHOULD send a > > Registration Reply > > >> > > to the mobile node with Code 131" > > >> > > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > > >> > > > > >> > > "If the Code field indicates an authentication failure, > > >> > > either at the > > >> > > foreign agent or the home agent, then it is quite > > possible that any > > >> > > authenticators in the Registration Reply will also > > be in error. > > >> > > This > > >> > > could happen, for example, if the shared secret > > between the mobile > > >> > > node and home agent was erroneously configured. > > The mobile node > > >> > > SHOULD log such errors as security exceptions." > > >> > > > > >> > > RFC3344 also states that Registration Reply MUST > > include a MN-HA > > >> > > authentication extension: > > >> > > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) > > MUST appear > > >> > > in every Registration Reply sent by the home agent." > > >> > > > > >> > > where (c) is The Mobile-Home Authentication Extension. > > >> > > > > >> > > The problem is that when MN-HA-AE fails at the HA > > there isnt an > > >> > > available MN-HA authentication extension to use. So > > how can one > > >> > > send a registration reply? > > >> > > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for > > the mobile, > > >> > > what should happen? > > >> > > > > >> > > > > >> > > Any help will be appreciated. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > =3D======================= > > >> > > > > >> > > Avi Lior > > >> > > Bridgewater Systems Corporation > > >> > > Phone : +1 (613) 591-9104 x6417 > > >> > > Cell : +1 (613) 796-4183 > > >> > > E-mail : mailto:avi@bridgewatersystems.com > > >> > > > > >> > > www.bridgewatersystems.com > > >> > > > > >> > > > > >> > > -- > > >> > > Mip4 mailing list: Mip4@ietf.org > > >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > > Charter page: > > >> > > http://www.ietf.org/html.charters/mip4-charter.html > > >> > > Supplemental site: http://www.mip4.org/ > > >> > > > > >> > > > >> > -- > > >> > Mip4 mailing list: Mip4@ietf.org > > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > Charter page: > > >> > http://www.ietf.org/html.charters/mip4-charter.html > > >> > Supplemental site: http://www.mip4.org/ > > >> > > >> > > >> "This email message and any attachments are confidential > > information > > >> of Starent Networks, Corp. The information transmitted may not be > > >> used to create or change any contractual obligations of Starent > > >> Networks, Corp. Any review, retransmission, dissemination > > or other > > >> use of, or taking of any action in reliance upon this > > e-mail and its > > >> attachments by persons or entities other than the intended > > recipient > > >> is prohibited. If you are not the intended recipient, > > please notify > > >> the sender immediately -- by replying to this message or > > by sending > > >> an email to postmaster@starentnetworks.com -- and destroy > > all copies > > >> of this message and any attachments without reading or disclosing > > >> their contents. Thank you." > > >> > > > > > > > > > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --0-1544963828-1150999560=:25012 Content-Type: text/html; charset=us-ascii
Hi Kuntal
  In WiMAX, if MS fails EAP authentication, it is out, it cannot even send an RREQ.

Regards,

Behcet

----- Original Message ----
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: Kent Leung (kleung) <kleung@cisco.com>
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>; Henrik Levkowetz <henrik@levkowetz.com>
Sent: Thursday, June 22, 2006 10:48:03 AM
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails



> -----Original Message-----
> From: Kent Leung (kleung) [mailto:kleung@cisco.com]
> Sent: Thursday, June 22, 2006 1:43 AM
> To: Henrik Levkowetz
> Cc: Mobile IPv4 Mailing List
> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator
fails
>
> Hi Henrik.  I think the protocol can already handle authentication
> failures sufficiently.
>
> It's possible for MN to have multiple security contexts (indexed by
> different SPIs) with the HA.  One could be used for registration and
the
> other for authenticating RRP with error code 131.  So I believe RFC
3344
> provides the mechanism already.  As long as HA has an SA that can be
> used to protect the RRP with the MN-HA AE, it can inform the MN such
> event happened in a secure manner.
>
> I think mucking with the MN-HA AE is not good.  This can create the
> situation when MN sends a valid RRQ, and MITM can send a RRP with
error
> code 131 and invalid MN-HA AE to the MN immediately.  When the RRP is
> received, the MN will stop retrying.  It's possible that the RRQ was
> lost in transit to the HA.  And even if the valid RRP arrives later,
MN
> may not be able to associate with the any pending RRQ, which could
have
> been possibly removed since an associated RRP had been received
already.
>
[KC>] If the HA does not send RRP back to the MN, as you initially
suggested, the MN will keep retrying. That is not good either.

Look at other protocols. For example EAP, if auth fails, the
authenticator MUST send back a failure packet to the peer. Same case for
other protocols over UNI. So, I am wondering why the paranoids are not
concerned about MiTM and DoS attacks in general!

Regarding your comment "mucking with the MN-HA AE is not good", if MN-HA
AE is not absolutely necessary in the RRP messages, I will be more than
happy to propose that when code 131 is included, the RRP contains no
MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a
better suggestion that does not break current implementations, and does
not produce a new mip4 protocol, I don't think we have a choice here.



> Kent
>
> > -----Original Message-----
> > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> > Sent: Wednesday, June 21, 2006 1:43 PM
> > To: Kent Leung (kleung)
> > Cc: Mobile IPv4 Mailing List
> > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator fails
> >
> > Hi Kent,
> >
> > on 2006-06-21 19:13 Kent Leung (kleung) said the following:
> > > If there is no SA, then I don't think HA should send a RRP.
> >
> > Maybe, but it leaves the MN and user with less information
> > than it/he could have.  I think that the best would be if we
> > could find a standard way of handling this situation.
> >
> > Fwiw, this has come up before, we discussed how to handle
> > this at ipUnplugged some time ago - it's a real situation
> > when you're setting up and deploying a network.
> >
> > Regards,
> >
> >     Henrik
> >
> > > Kent
> > >
> > >> -----Original Message-----
> > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
> > >> Sent: Wednesday, June 21, 2006 10:05 AM
> > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List
> > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator
> > >> fails
> > >>
> > >> Kent/Avi,
> > >>
> > >> The current text does not say that the HA cannot send RRP
> > when auth
> > >> fails. Rather it says that the HA "SHOULD" send RRP back to the
MN:
> > >>
> > >> > if the Authenticator is invalid, the home agent MUST reject
the
> > >> > mobile node's registration and SHOULD send a
> > Registration Reply to
> > >> > the mobile node with Code 131"
> > >>
> > >> What we need is a proper description of the HA and the MN
> > behaviors
> > >> when the auth fails and the HA needs to send a RRP to stop the MN
> > >> from re-trying unnecessarily.
> > >>
> > >> The clarification could be:
> > >>
> > >> If the Authenticator is invalid, the home agent MUST reject the
> > >> mobile node's registration and SHOULD send a Registration Reply
to
> > >> the mobile node with Code 131. In this case, the HA populates the
> > >> MN-HA AE with all 0s. Upon receiving the RRP with error
> > code 131, the
> > >> MN skips MN-HA AE validation and stops retrying registration
> > >> attempts. The MN MAY log this event in its internal log.
> > >>
> > >> What do you think?
> > >>
> > >> -Kuntal
> > >>
> > >> > -----Original Message-----
> > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com]
> > >> > Sent: Wednesday, June 21, 2006 11:43 AM
> > >> > To: Avi Lior; Mobile IPv4 Mailing List
> > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator
> > >> > fails
> > >> >
> > >> > Hi Avi.  My understanding is that in this case, the HA
> > will not be
> > >> > able to send an RRP if it does not have an SA with the
> > MN because
> > >> > this message requires MN-HA AE.  The text state that if HA has
> > >> an SA, then
> > >> to
> > >> > use that in the RRP.  Without an SA, the HA should drop
> > the  RRQ, IMHO.
> > >> >
> > >> > Kent
> > >> >
> > >> > > -----Original Message-----
> > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com]
> > >> > > Sent: Wednesday, June 21, 2006 8:13 AM
> > >> > > To: Mobile IPv4 Mailing List
> > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator
> > >> > > fails
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > While working a scenario in WiMAX I have run into some
> >  ambiguity
> > >> > > in RFC3344.
> > >> > >
> > >> > > The HA receives a Reg Request with MN-HA-AE and NAI
extension
> > >> > > which it fails to authenticate.  In particular the HA cant
> > >> > > authenticate because it can't obtain the MN-HA from
> > the AAA using the NAI.
> > >> > >
> > >> > > >From section 3.8.2.1 RFC3344 states that a Registration
> > >> > > Reply should be
> > >> > > sent with code 131.
> > >> > >
> > >> > > "if the Authenticator is invalid, the home agent MUST
> > reject the
> > >> > > mobile node's registration and SHOULD send a
> > Registration  Reply
> > >> > > to the mobile node with Code 131"
> > >> > >
> > >> > > And from section 3.6.2.1 describing the MN behavior we have:
> > >> > >
> > >> > >    "If the Code field indicates an authentication  failure,
> > >> > > either at the
> > >> > >    foreign agent or the home agent, then it is quite
> > possible that any
> > >> > >    authenticators in the Registration Reply will also
> > be  in error.
> > >> > > This
> > >> > >    could happen, for example, if the shared secret
> > between the mobile
> > >> > >    node and home agent was erroneously configured.
> > The  mobile node
> > >> > >    SHOULD log such errors as security exceptions."
> > >> > >
> > >> > > RFC3344 also states that Registration Reply MUST
> > include a MN-HA
> > >> > > authentication extension:
> > >> > >
> > >> > > Section 3.8.3.3 says  " Note that items (a) and (c)
> > MUST  appear
> > >> > > in every Registration Reply sent by the home agent."
> > >> > >
> > >> > > where  (c) is  The Mobile-Home Authentication Extension.
> > >> > >
> > >> > > The problem is that when MN-HA-AE fails at the HA
> > there isnt an
> > >> > > available MN-HA authentication extension to use.  So
> > how can one
> > >> > > send a registration reply?
> > >> > >
> > >> > > Furthermore, if the HA cant not obtain an MN-HA for
> > the  mobile,
> > >> > > what should happen?
> > >> > >
> > >> > >
> > >> > > Any help will be appreciated.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > =3D=======================
> > >> > >
> > >> > > Avi Lior
> > >> > > Bridgewater Systems Corporation
> > >> > > Phone :  +1 (613) 591-9104 x6417
> > >> > > Cell    :  +1 (613) 796-4183
> > >> > > E-mail : mailto:avi@bridgewatersystems.com
> > >> > > <mailto:avi@bridgewatersystems.com>
> > >> > > www.bridgewatersystems.com
<http://www.bridgewatersystems.com/>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Mip4 mailing list: Mip4@ietf.org
> > >> > >     Web interface:
https://www1.ietf.org/mailman/listinfo/mip4
> > >> > >      Charter page:
> > >> > > http://www.ietf.org/html.charters/mip4-charter.html
> > >> > > Supplemental site: http://www.mip4.org/
> > >> > >
> > >> >
> > >> > --
> > >> > Mip4 mailing list: Mip4@ietf.org
> > >> >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> > >> >      Charter page:
> > >> > http://www.ietf.org/html.charters/mip4-charter.html
> > >> > Supplemental site: http://www.mip4.org/
> > >>
> > >>
> > >> "This email message and any attachments are confidential
> > information
> > >> of Starent Networks, Corp. The information transmitted may not be
> > >> used to create or change any contractual obligations of Starent
> > >> Networks, Corp.  Any review, retransmission, dissemination
> > or other
> > >> use of, or taking of any action in reliance upon this
> > e-mail and its
> > >> attachments by persons or entities other than the intended
> > recipient
> > >> is prohibited. If you are not the intended recipient,
> > please notify
> > >> the sender immediately -- by replying to this message or
> > by sending
> > >> an email to postmaster@starentnetworks.com -- and destroy
> > all copies
> > >> of this message and any attachments without reading or disclosing
> > >> their contents. Thank you."
> > >>
> > >
> >
> >
>
> --
> Mip4 mailing list: Mip4@ietf.org
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/

--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

--0-1544963828-1150999560=:25012-- --===============0780590101== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0780590101==-- From mip4-bounces@ietf.org Thu Jun 22 14:39:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtU53-0007r2-GH; Thu, 22 Jun 2006 14:39:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtU51-0007pG-C4 for mip4@ietf.org; Thu, 22 Jun 2006 14:39:03 -0400 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 1FtRJE-0003TV-I8 for mip4@ietf.org; Thu, 22 Jun 2006 11:41:32 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FtR6t-0006e8-VX for mip4@ietf.org; Thu, 22 Jun 2006 11:28:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 315FE90062 for ; Thu, 22 Jun 2006 11:28:41 -0400 (EDT) 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 14319-10 for ; Thu, 22 Jun 2006 11:28:39 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 22 Jun 2006 11:28:39 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jun 2006 11:25:40 -0400 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 22 Jun 2006 11:25:40 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51C6@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVc1DfUCjXk4gbTvSsUTW4unIXTQAE+0mgABCIeTAAEYhQEA== From: "Chowdhury, Kuntal" To: "Yoshi Tsuda (yotsuda)" , "Kent Leung (kleung)" , "Henrik Levkowetz" X-OriginalArrivalTime: 22 Jun 2006 15:25:40.0788 (UTC) FILETIME=[1ED9EF40:01C69610] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: -2.6 (--) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org > -----Original Message----- > From: Yoshi Tsuda (yotsuda) [mailto:yotsuda@cisco.com] > Sent: Thursday, June 22, 2006 2:27 AM > To: Kent Leung (kleung); Henrik Levkowetz > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi Henrik, >=20 > I have the same opinion with Kent; the RFC3344 has already > provided the method. >=20 > And, I have another concern, if an HA or an FA should reply > an RRP to an MN even without having an SA: > - A malicious host could send an RRQ with any home address > or NAI to an HA or an FA. Then, you know, the HA or the FA > needs to reply an RRP to the specified CoA, even if the host > of the CoA isn't using Mobile IP service. This could produce > another kind of security problem. :( [KC>] If the FA and the HA in the operator's network are widely exposed to the internet, yeah what you describe is possible. However, I don't believe we have too many of those types of operators out there who give access to their FA and HA to anyone with a connection to the internet. We can think of all sorts of scenarios, but we have to solve for the most likely scenario, IMHO. >=20 > Thanks. > -Yoshi >=20 > > -----Original Message----- > > From: Kent Leung (kleung) > > Sent: Thursday, June 22, 2006 3:43 PM > > To: Henrik Levkowetz > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator fails > > > > Hi Henrik. I think the protocol can already handle > > authentication failures sufficiently. > > > > It's possible for MN to have multiple security contexts > > (indexed by different SPIs) with the HA. One could be used > > for registration and the other for authenticating RRP with > > error code 131. So I believe RFC 3344 provides the mechanism > > already. As long as HA has an SA that can be used to protect > > the RRP with the MN-HA AE, it can inform the MN such event > > happened in a secure manner. > > > > I think mucking with the MN-HA AE is not good. This can > > create the situation when MN sends a valid RRQ, and MITM can > > send a RRP with error code 131 and invalid MN-HA AE to the MN > > immediately. When the RRP is received, the MN will stop > > retrying. It's possible that the RRQ was lost in transit to > > the HA. And even if the valid RRP arrives later, MN may not > > be able to associate with the any pending RRQ, which could > > have been possibly removed since an associated RRP had been > > received already. > > > > Kent > > > > > -----Original Message----- > > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > > Sent: Wednesday, June 21, 2006 1:43 PM > > > To: Kent Leung (kleung) > > > Cc: Mobile IPv4 Mailing List > > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator > > > fails > > > > > > Hi Kent, > > > > > > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > > > If there is no SA, then I don't think HA should send a RRP. > > > > > > Maybe, but it leaves the MN and user with less information > > than it/he > > > could have. I think that the best would be if we could find a > > > standard way of handling this situation. > > > > > > Fwiw, this has come up before, we discussed how to handle this at > > > ipUnplugged some time ago - it's a real situation when > > you're setting > > > up and deploying a network. > > > > > > Regards, > > > > > > Henrik > > > > > > > Kent > > > > > > > >> -----Original Message----- > > > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > > >> Sent: Wednesday, June 21, 2006 10:05 AM > > > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > > Authenticator > > > >> fails > > > >> > > > >> Kent/Avi, > > > >> > > > >> The current text does not say that the HA cannot send RRP > > > when auth > > > >> fails. Rather it says that the HA "SHOULD" send RRP back > > to the MN: > > > >> > > > >> > if the Authenticator is invalid, the home agent MUST > > reject the > > > >> > mobile node's registration and SHOULD send a > > > Registration Reply to > > > >> > the mobile node with Code 131" > > > >> > > > >> What we need is a proper description of the HA and the MN > > > behaviors > > > >> when the auth fails and the HA needs to send a RRP to > > stop the MN > > > >> from re-trying unnecessarily. > > > >> > > > >> The clarification could be: > > > >> > > > >> If the Authenticator is invalid, the home agent MUST reject the > > > >> mobile node's registration and SHOULD send a > > Registration Reply to > > > >> the mobile node with Code 131. In this case, the HA > > populates the > > > >> MN-HA AE with all 0s. Upon receiving the RRP with error > > > code 131, the > > > >> MN skips MN-HA AE validation and stops retrying registration > > > >> attempts. The MN MAY log this event in its internal log. > > > >> > > > >> What do you think? > > > >> > > > >> -Kuntal > > > >> > > > >> > -----Original Message----- > > > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > > >> > Sent: Wednesday, June 21, 2006 11:43 AM > > > >> > To: Avi Lior; Mobile IPv4 Mailing List > > > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > > Authenticator > > > >> > fails > > > >> > > > > >> > Hi Avi. My understanding is that in this case, the HA > > > will not be > > > >> > able to send an RRP if it does not have an SA with the > > > MN because > > > >> > this message requires MN-HA AE. The text state that if HA has > > > >> an SA, then > > > >> to > > > >> > use that in the RRP. Without an SA, the HA should drop > > > the RRQ, IMHO. > > > >> > > > > >> > Kent > > > >> > > > > >> > > -----Original Message----- > > > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > > > >> > > To: Mobile IPv4 Mailing List > > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the > > > Authenticator > > > >> > > fails > > > >> > > > > > >> > > Hi, > > > >> > > > > > >> > > While working a scenario in WiMAX I have run into some > > > ambiguity > > > >> > > in RFC3344. > > > >> > > > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI > > extension > > > >> > > which it fails to authenticate. In particular the HA cant > > > >> > > authenticate because it can't obtain the MN-HA from > > > the AAA using the NAI. > > > >> > > > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > > > >> > > Reply should be > > > >> > > sent with code 131. > > > >> > > > > > >> > > "if the Authenticator is invalid, the home agent MUST > > > reject the > > > >> > > mobile node's registration and SHOULD send a > > > Registration Reply > > > >> > > to the mobile node with Code 131" > > > >> > > > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > > > >> > > > > > >> > > "If the Code field indicates an authentication failure, > > > >> > > either at the > > > >> > > foreign agent or the home agent, then it is quite > > > possible that any > > > >> > > authenticators in the Registration Reply will also > > > be in error. > > > >> > > This > > > >> > > could happen, for example, if the shared secret > > > between the mobile > > > >> > > node and home agent was erroneously configured. > > > The mobile node > > > >> > > SHOULD log such errors as security exceptions." > > > >> > > > > > >> > > RFC3344 also states that Registration Reply MUST > > > include a MN-HA > > > >> > > authentication extension: > > > >> > > > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) > > > MUST appear > > > >> > > in every Registration Reply sent by the home agent." > > > >> > > > > > >> > > where (c) is The Mobile-Home Authentication Extension. > > > >> > > > > > >> > > The problem is that when MN-HA-AE fails at the HA > > > there isnt an > > > >> > > available MN-HA authentication extension to use. So > > > how can one > > > >> > > send a registration reply? > > > >> > > > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for > > > the mobile, > > > >> > > what should happen? > > > >> > > > > > >> > > > > > >> > > Any help will be appreciated. > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > > >> > > > > > >> > > Avi Lior > > > >> > > Bridgewater Systems Corporation Phone : +1 (613) 591-9104 > > > >> > > x6417 > > > >> > > Cell : +1 (613) 796-4183 > > > >> > > E-mail : mailto:avi@bridgewatersystems.com > > > >> > > > > > >> > > www.bridgewatersystems.com > > > > > >> > > > > > >> > > > > > >> > > -- > > > >> > > Mip4 mailing list: Mip4@ietf.org > > > >> > > Web interface: > > https://www1.ietf.org/mailman/listinfo/mip4 > > > >> > > Charter page: > > > >> > > http://www.ietf.org/html.charters/mip4-charter.html > > > >> > > Supplemental site: http://www.mip4.org/ > > > >> > > > > > >> > > > > >> > -- > > > >> > Mip4 mailing list: Mip4@ietf.org > > > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > > >> > Charter page: > > > >> > http://www.ietf.org/html.charters/mip4-charter.html > > > >> > Supplemental site: http://www.mip4.org/ > > > >> > > > >> > > > >> "This email message and any attachments are confidential > > > information > > > >> of Starent Networks, Corp. The information transmitted > > may not be > > > >> used to create or change any contractual obligations of Starent > > > >> Networks, Corp. Any review, retransmission, dissemination > > > or other > > > >> use of, or taking of any action in reliance upon this > > > e-mail and its > > > >> attachments by persons or entities other than the intended > > > recipient > > > >> is prohibited. If you are not the intended recipient, > > > please notify > > > >> the sender immediately -- by replying to this message or > > > by sending > > > >> an email to postmaster@starentnetworks.com -- and destroy > > > all copies > > > >> of this message and any attachments without reading or > > disclosing > > > >> their contents. Thank you." > > > >> > > > > > > > > > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 22 14:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtULO-0006gg-3M; Thu, 22 Jun 2006 14:55:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtULM-0006gY-Hw for mip4@ietf.org; Thu, 22 Jun 2006 14:55:56 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtULI-0000yW-S3 for mip4@ietf.org; Thu, 22 Jun 2006 14:55:56 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2D4909002C for ; Thu, 22 Jun 2006 14:55:49 -0400 (EDT) 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 18149-09 for ; Thu, 22 Jun 2006 14:55:48 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 22 Jun 2006 14:55:48 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jun 2006 14:52:48 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 22 Jun 2006 14:52:48 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51CD@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQ From: "Chowdhury, Kuntal" To: "Behcet Sarikaya" , "Kent Leung (kleung)" X-OriginalArrivalTime: 22 Jun 2006 18:52:48.0891 (UTC) FILETIME=[0E93F4B0:01C6962D] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.1 (/) X-Scan-Signature: d0743789926799c3479e30df83b2a345 Cc: Mobile IPv4 Mailing List , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0166043722==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0166043722== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6962D.0E688E24" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6962D.0E688E24 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yep...same case for other access technologies as well. That means, rogue mobiles sending bogus RRQ packets to the HA is extremely slim. =20 -Kuntal =20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Thursday, June 22, 2006 1:06 PM To: Chowdhury, Kuntal; Kent Leung (kleung) Cc: Mobile IPv4 Mailing List; Henrik Levkowetz Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 Hi Kuntal In WiMAX, if MS fails EAP authentication, it is out, it cannot even send an RREQ. Regards, Behcet ----- Original Message ---- From: "Chowdhury, Kuntal" To: Kent Leung (kleung) Cc: Mobile IPv4 Mailing List ; Henrik Levkowetz Sent: Thursday, June 22, 2006 10:48:03 AM Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Thursday, June 22, 2006 1:43 AM > To: Henrik Levkowetz > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi Henrik. I think the protocol can already handle authentication > failures sufficiently. >=20 > It's possible for MN to have multiple security contexts (indexed by > different SPIs) with the HA. One could be used for registration and the > other for authenticating RRP with error code 131. So I believe RFC 3344 > provides the mechanism already. As long as HA has an SA that can be > used to protect the RRP with the MN-HA AE, it can inform the MN such > event happened in a secure manner. >=20 > I think mucking with the MN-HA AE is not good. This can create the > situation when MN sends a valid RRQ, and MITM can send a RRP with error > code 131 and invalid MN-HA AE to the MN immediately. When the RRP is > received, the MN will stop retrying. It's possible that the RRQ was > lost in transit to the HA. And even if the valid RRP arrives later, MN > may not be able to associate with the any pending RRQ, which could have > been possibly removed since an associated RRP had been received already. >=20 [KC>] If the HA does not send RRP back to the MN, as you initially suggested, the MN will keep retrying. That is not good either. Look at other protocols. For example EAP, if auth fails, the authenticator MUST send back a failure packet to the peer. Same case for other protocols over UNI. So, I am wondering why the paranoids are not concerned about MiTM and DoS attacks in general! Regarding your comment "mucking with the MN-HA AE is not good", if MN-HA AE is not absolutely necessary in the RRP messages, I will be more than happy to propose that when code 131 is included, the RRP contains no MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a better suggestion that does not break current implementations, and does not produce a new mip4 protocol, I don't think we have a choice here. > Kent >=20 > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 1:43 PM > > To: Kent Leung (kleung) > > Cc: Mobile IPv4 Mailing List > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator fails > > > > Hi Kent, > > > > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > > If there is no SA, then I don't think HA should send a RRP. > > > > Maybe, but it leaves the MN and user with less information > > than it/he could have. I think that the best would be if we > > could find a standard way of handling this situation. > > > > Fwiw, this has come up before, we discussed how to handle > > this at ipUnplugged some time ago - it's a real situation > > when you're setting up and deploying a network. > > > > Regards, > > > > Henrik > > > > > Kent > > > > > >> -----Original Message----- > > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > >> Sent: Wednesday, June 21, 2006 10:05 AM > > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> fails > > >> > > >> Kent/Avi, > > >> > > >> The current text does not say that the HA cannot send RRP > > when auth > > >> fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > > >> > > >> > if the Authenticator is invalid, the home agent MUST reject the > > >> > mobile node's registration and SHOULD send a > > Registration Reply to > > >> > the mobile node with Code 131" > > >> > > >> What we need is a proper description of the HA and the MN > > behaviors > > >> when the auth fails and the HA needs to send a RRP to stop the MN > > >> from re-trying unnecessarily. > > >> > > >> The clarification could be: > > >> > > >> If the Authenticator is invalid, the home agent MUST reject the > > >> mobile node's registration and SHOULD send a Registration Reply to > > >> the mobile node with Code 131. In this case, the HA populates the > > >> MN-HA AE with all 0s. Upon receiving the RRP with error > > code 131, the > > >> MN skips MN-HA AE validation and stops retrying registration > > >> attempts. The MN MAY log this event in its internal log. > > >> > > >> What do you think? > > >> > > >> -Kuntal > > >> > > >> > -----Original Message----- > > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > >> > Sent: Wednesday, June 21, 2006 11:43 AM > > >> > To: Avi Lior; Mobile IPv4 Mailing List > > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > fails > > >> > > > >> > Hi Avi. My understanding is that in this case, the HA > > will not be > > >> > able to send an RRP if it does not have an SA with the > > MN because > > >> > this message requires MN-HA AE. The text state that if HA has > > >> an SA, then > > >> to > > >> > use that in the RRP. Without an SA, the HA should drop > > the RRQ, IMHO. > > >> > > > >> > Kent > > >> > > > >> > > -----Original Message----- > > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > > >> > > To: Mobile IPv4 Mailing List > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > > fails > > >> > > > > >> > > Hi, > > >> > > > > >> > > While working a scenario in WiMAX I have run into some > > ambiguity > > >> > > in RFC3344. > > >> > > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > >> > > which it fails to authenticate. In particular the HA cant > > >> > > authenticate because it can't obtain the MN-HA from > > the AAA using the NAI. > > >> > > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > > >> > > Reply should be > > >> > > sent with code 131. > > >> > > > > >> > > "if the Authenticator is invalid, the home agent MUST > > reject the > > >> > > mobile node's registration and SHOULD send a > > Registration Reply > > >> > > to the mobile node with Code 131" > > >> > > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > > >> > > > > >> > > "If the Code field indicates an authentication failure, > > >> > > either at the > > >> > > foreign agent or the home agent, then it is quite > > possible that any > > >> > > authenticators in the Registration Reply will also > > be in error. > > >> > > This > > >> > > could happen, for example, if the shared secret > > between the mobile > > >> > > node and home agent was erroneously configured. > > The mobile node > > >> > > SHOULD log such errors as security exceptions." > > >> > > > > >> > > RFC3344 also states that Registration Reply MUST > > include a MN-HA > > >> > > authentication extension: > > >> > > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) > > MUST appear > > >> > > in every Registration Reply sent by the home agent." > > >> > > > > >> > > where (c) is The Mobile-Home Authentication Extension. > > >> > > > > >> > > The problem is that when MN-HA-AE fails at the HA > > there isnt an > > >> > > available MN-HA authentication extension to use. So > > how can one > > >> > > send a registration reply? > > >> > > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for > > the mobile, > > >> > > what should happen? > > >> > > > > >> > > > > >> > > Any help will be appreciated. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > >> > > > > >> > > Avi Lior > > >> > > Bridgewater Systems Corporation > > >> > > Phone : +1 (613) 591-9104 x6417 > > >> > > Cell : +1 (613) 796-4183 > > >> > > E-mail : mailto:avi@bridgewatersystems.com > > >> > > > > >> > > www.bridgewatersystems.com > > >> > > > > >> > > > > >> > > -- > > >> > > Mip4 mailing list: Mip4@ietf.org > > >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > > Charter page: > > >> > > http://www.ietf.org/html.charters/mip4-charter.html > > >> > > Supplemental site: http://www.mip4.org/ > > >> > > > > >> > > > >> > -- > > >> > Mip4 mailing list: Mip4@ietf.org > > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > Charter page: > > >> > http://www.ietf.org/html.charters/mip4-charter.html > > >> > Supplemental site: http://www.mip4.org/ > > >> > > >> > > >> "This email message and any attachments are confidential > > information > > >> of Starent Networks, Corp. The information transmitted may not be > > >> used to create or change any contractual obligations of Starent > > >> Networks, Corp. Any review, retransmission, dissemination > > or other > > >> use of, or taking of any action in reliance upon this > > e-mail and its > > >> attachments by persons or entities other than the intended > > recipient > > >> is prohibited. If you are not the intended recipient, > > please notify > > >> the sender immediately -- by replying to this message or > > by sending > > >> an email to postmaster@starentnetworks.com -- and destroy > > all copies > > >> of this message and any attachments without reading or disclosing > > >> their contents. Thank you." > > >> > > > > > > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ =20 ------_=_NextPart_001_01C6962D.0E688E24 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yep…same case for other = access technologies as well.  That means, rogue mobiles sending bogus RRQ = packets to the HA is extremely slim.

 

-Kuntal

=

 

 

From: = Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Sent: Thursday, June 22, = 2006 1:06 PM
To: Chowdhury, Kuntal; = Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: Re: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

 

Hi Kuntal
  In WiMAX, if MS fails EAP authentication, it is out, it cannot = even send an RREQ.

Regards,

Behcet

----- Original = Message ----
From: "Chowdhury, Kuntal" = <kchowdhury@starentnetworks.com>
To: Kent Leung (kleung) <kleung@cisco.com>
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>; Henrik Levkowetz <henrik@levkowetz.com>
Sent: Thursday, June 22, 2006 10:48:03 AM
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator = fails



> -----Original Message-----
> From: Kent Leung (kleung) [mailto:kleung@cisco.com]
> Sent: Thursday, June 22, 2006 1:43 AM
> To: Henrik Levkowetz
> Cc: Mobile IPv4 Mailing List
> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the = Authenticator
fails
>
> Hi Henrik.  I think the protocol can already handle authentication
> failures sufficiently.
>
> It's possible for MN to have multiple security contexts (indexed = by
> different SPIs) with the HA.  One could be used for = registration and
the
> other for authenticating RRP with error code 131.  So I = believe RFC
3344
> provides the mechanism already.  As long as HA has an SA = that can be
> used to protect the RRP with the MN-HA AE, it can inform the MN = such
> event happened in a secure manner.
>
> I think mucking with the MN-HA AE is not good.  This can = create the
> situation when MN sends a valid RRQ, and MITM can send a RRP = with
error
> code 131 and invalid MN-HA AE to the MN = immediately.  When the RRP is
> received, the MN will stop retrying.  It's possible that = the RRQ was
> lost in transit to the HA.  And even if the valid RRP = arrives later,
MN
> may not be able to associate with the any pending RRQ, which = could
have
> been possibly removed since an associated RRP had been received
already.
>
[KC>] If the HA does not send RRP back to the MN, as you = initially
suggested, the MN will keep retrying. That is not good either.

Look at other protocols. For example EAP, if auth fails, the
authenticator MUST send back a failure packet to the peer. Same case = for
other protocols over UNI. So, I am wondering why the paranoids are = not
concerned about MiTM and DoS attacks in general!

Regarding your comment "mucking with the MN-HA AE is not = good", if MN-HA
AE is not absolutely necessary in the RRP messages, I will be more = than
happy to propose that when code 131 is included, the RRP contains no
MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a
better suggestion that does not break current implementations, and = does
not produce a new mip4 protocol, I don't think we have a choice = here.



> Kent
>
> > -----Original Message-----
> > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> > Sent: Wednesday, June 21, 2006 1:43 PM
> > To: Kent Leung (kleung)
> > Cc: Mobile IPv4 Mailing = List
> > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator fails
> >
> > Hi Kent,
> >
> > on 2006-06-21 19:13 Kent Leung (kleung) said the = following:
> > > If there is no SA, then I don't think HA should send a = RRP.
> >
> > Maybe, but it leaves the MN and user with less information
> > than it/he could have.  I think that the best would = be if we
> > could find a standard way of handling this situation.
> >
> > Fwiw, this has come up before, we discussed how to handle
> > this at ipUnplugged some time ago - it's a real situation
> > when you're setting up and deploying a network.
> >
> > Regards,
> >
> >     Henrik
> >
> > > Kent
> > >
> > >> -----Original Message-----
> > >> From: Chowdhury, Kuntal = [mailto:kchowdhury@starentnetworks.com]
> > >> Sent: Wednesday, June 21, 2006 10:05 AM
> > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 = Mailing List
> > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when = the
> > Authenticator
> > >> fails
> > >>
> > >> Kent/Avi,
> > >>
> > >> The current text does not say that the HA cannot send = RRP
> > when auth
> > >> fails. Rather it says that the HA "SHOULD" = send RRP back to the
MN:
> > >>
> > >> > if the Authenticator is invalid, the home agent = MUST reject
the
> > >> > mobile node's registration and SHOULD send a
> > Registration Reply to
> > >> > the mobile node with Code 131"
> > >>
> > >> What we need is a proper description of the HA and = the MN
> > behaviors
> > >> when the auth fails and the HA needs to send a RRP to = stop the MN
> > >> from re-trying unnecessarily.
> > >>
> > >> The clarification could be:
> > >>
> > >> If the Authenticator is invalid, the home agent MUST = reject the
> > >> mobile node's registration and SHOULD send a = Registration Reply
to
> > >> the mobile node with Code 131. In this case, the HA populates the
> > >> MN-HA AE with all 0s. Upon receiving the RRP with = error
> > code 131, the
> > >> MN skips MN-HA AE validation and stops retrying = registration
> > >> attempts. The MN MAY log this event in its internal = log.
> > >>
> > >> What do you think?
> > >>
> > >> -Kuntal
> > >>
> > >> > -----Original Message-----
> > >> > From: Kent Leung (kleung) = [mailto:kleung@cisco.com]
> > >> > Sent: Wednesday, June 21, 2006 11:43 AM
> > >> > To: Avi Lior; Mobile IPv4 Mailing List
> > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply = when the
> > Authenticator
> > >> > fails
> > >> >
> > >> > Hi Avi.  My understanding is that in = this case, the HA
> > will not be
> > >> > able to send an RRP if it does not have an SA = with the
> > MN because
> > >> > this message requires MN-HA AE.  The = text state that if HA has
> > >> an SA, then
> > >> to
> > >> > use that in the RRP.  Without an SA, = the HA should drop
> > the  RRQ, IMHO.
> > >> >
> > >> > Kent
> > >> >
> > >> > > -----Original Message-----
> > >> > > From: Avi Lior = [mailto:avi@bridgewatersystems.com]
> > >> > > Sent: Wednesday, June 21, 2006 8:13 AM
> > >> > > To: Mobile IPv4 Mailing List
> > >> > > Subject: [Mip4] 3344 Sending a Reg Reply = when the
> > Authenticator
> > >> > > fails
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > While working a scenario in WiMAX I have = run into some
> >  ambiguity
> > >> > > in RFC3344.
> > >> > >
> > >> > > The HA receives a Reg Request with MN-HA-AE = and NAI
extension
> > >> > > which it fails to = authenticate.  In particular the HA cant
> > >> > > authenticate because it can't obtain the = MN-HA from
> > the AAA using the NAI.
> > >> > >
> > >> > > >From section 3.8.2.1 RFC3344 states = that a Registration
> > >> > > Reply should be
> > >> > > sent with code 131.
> > >> > >
> > >> > > "if the Authenticator is invalid, the = home agent MUST
> > reject the
> > >> > > mobile node's registration and SHOULD send = a
> > Registration  Reply
> > >> > > to the mobile node with Code 131"
> > >> > >
> > >> > > And from section 3.6.2.1 describing the MN behavior we have:
> > >> > >
> > >> > >    "If the Code = field indicates an authentication  failure,
> > >> > > either at the
> > >> > >    foreign agent or the = home agent, then it is quite
> > possible that any
> > >> > >    authenticators in = the Registration Reply will also
> > be  in error.
> > >> > > This
> > >> > >    could happen, for = example, if the shared secret
> > between the mobile
> > >> > >    node and home agent = was erroneously configured.
> > The  mobile node
> > >> > >    SHOULD log such = errors as security exceptions."
> > >> > >
> > >> > > RFC3344 also states that Registration Reply = MUST
> > include a MN-HA
> > >> > > authentication extension:
> > >> > >
> > >> > > Section 3.8.3.3 says  " Note = that items (a) and (c)
> > MUST  appear
> > >> > > in every Registration Reply sent by the = home agent."
> > >> > >
> > >> > > where  (c) is  The = Mobile-Home Authentication Extension.
> > >> > >
> > >> > > The problem is that when MN-HA-AE fails at = the HA
> > there isnt an
> > >> > > available MN-HA authentication extension to use.  So
> > how can one
> > >> > > send a registration reply?
> > >> > >
> > >> > > Furthermore, if the HA cant not obtain an = MN-HA for
> > the  mobile,
> > >> > > what should happen?
> > >> > >
> > >> > >
> > >> > > Any help will be appreciated.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > >> > >
> > >> > > Avi Lior
> > >> > > Bridgewater Systems Corporation
> > >> > > Phone :  +1 (613) 591-9104 = x6417
> > >> > > Cell    :  +1 = (613) 796-4183
> > >> > > E-mail : = mailto:avi@bridgewatersystems.com
> > >> > > = <mailto:avi@bridgewatersystems.com>
> > >> > > www.bridgewatersystems.com
<http://www.bridgewatersystems.com/>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Mip4 mailing list: Mip4@ietf.org
> > >> > >     Web interface:
https://www1.ietf.org/mailman/listinfo/mip4
> > >> > >      Charter = page:
> > >> > > http://www.ietf.org/html.charters/mip4-charter.html=
> > >> > > Supplemental site: http://www.mip4.org/
> > >> > >
> > >> >
> > >> > --
> > >> > Mip4 mailing list: Mip4@ietf.org
> > >> >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> > >> >      Charter = page:
> > >> > http://www.ietf.org/html.charters/mip4-charter.html=
> > >> > Supplemental site: http://www.mip4.org/
> > >>
> > >>
> > >> "This email message and any attachments are confidential
> > information
> > >> of Starent Networks, Corp. The information = transmitted may not be
> > >> used to create or change any contractual obligations = of Starent
> > >> Networks, Corp.  Any review, = retransmission, dissemination
> > or other
> > >> use of, or taking of any action in reliance upon = this
> > e-mail and its
> > >> attachments by persons or entities other than the = intended
> > recipient
> > >> is prohibited. If you are not the intended = recipient,
> > please notify
> > >> the sender immediately -- by replying to this message = or
> > by sending
> > >> an email to postmaster@starentnetworks.com -- and = destroy
> > all copies
> > >> of this message and any attachments without reading = or disclosing
> > >> their contents. Thank you."
> > >>
> > >
> >
> >
>
> --
> Mip4 mailing list: Mip4@ietf.org
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html=
> Supplemental site: http://www.mip4.org/

--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html=
Supplemental site: http://www.mip4.org/

 

------_=_NextPart_001_01C6962D.0E688E24-- --===============0166043722== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0166043722==-- From mip4-bounces@ietf.org Thu Jun 22 16:25:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVk1-0002Bu-Gv; Thu, 22 Jun 2006 16:25:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtVjz-0002Ba-7Y for mip4@ietf.org; Thu, 22 Jun 2006 16:25:27 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtVjs-00005h-OJ for mip4@ietf.org; Thu, 22 Jun 2006 16:25:27 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k5MKPJJf000529 for ; Thu, 22 Jun 2006 13:25:19 -0700 (MST) Received: from de01exm70.ds.mot.com (de01exm70.am.mot.com [10.176.8.26]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5MKPI4O001830 for ; Thu, 22 Jun 2006 15:25:19 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 22 Jun 2006 16:25:16 -0400 Message-ID: In-Reply-To: <7CCD07160348804497EF29E9EA5560D73C51CD@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAMoRxA= From: "Nakhjiri Madjid-MNAKHJI1" To: "Chowdhury, Kuntal" , "Behcet Sarikaya" , "Kent Leung \(kleung\)" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a23818fb0eec942c015c9afea589725 Cc: Mobile IPv4 Mailing List , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2027971540==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============2027971540== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69639.FA50D108" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69639.FA50D108 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I thought the issue was avoiding a rouge HA sending a fake RRP with reject code, and no amount of access control can help that.. =20 ________________________________ From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Thursday, June 22, 2006 1:53 PM To: Behcet Sarikaya; Kent Leung (kleung) Cc: Mobile IPv4 Mailing List; Henrik Levkowetz Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 Yep...same case for other access technologies as well. That means, rogue mobiles sending bogus RRQ packets to the HA is extremely slim. =20 -Kuntal =20 =20 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Thursday, June 22, 2006 1:06 PM To: Chowdhury, Kuntal; Kent Leung (kleung) Cc: Mobile IPv4 Mailing List; Henrik Levkowetz Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 Hi Kuntal In WiMAX, if MS fails EAP authentication, it is out, it cannot even send an RREQ. Regards, Behcet ----- Original Message ---- From: "Chowdhury, Kuntal" To: Kent Leung (kleung) Cc: Mobile IPv4 Mailing List ; Henrik Levkowetz Sent: Thursday, June 22, 2006 10:48:03 AM Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Thursday, June 22, 2006 1:43 AM > To: Henrik Levkowetz > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi Henrik. I think the protocol can already handle authentication > failures sufficiently. >=20 > It's possible for MN to have multiple security contexts (indexed by > different SPIs) with the HA. One could be used for registration and the > other for authenticating RRP with error code 131. So I believe RFC 3344 > provides the mechanism already. As long as HA has an SA that can be > used to protect the RRP with the MN-HA AE, it can inform the MN such > event happened in a secure manner. >=20 > I think mucking with the MN-HA AE is not good. This can create the > situation when MN sends a valid RRQ, and MITM can send a RRP with error > code 131 and invalid MN-HA AE to the MN immediately. When the RRP is > received, the MN will stop retrying. It's possible that the RRQ was > lost in transit to the HA. And even if the valid RRP arrives later, MN > may not be able to associate with the any pending RRQ, which could have > been possibly removed since an associated RRP had been received already. >=20 [KC>] If the HA does not send RRP back to the MN, as you initially suggested, the MN will keep retrying. That is not good either. Look at other protocols. For example EAP, if auth fails, the authenticator MUST send back a failure packet to the peer. Same case for other protocols over UNI. So, I am wondering why the paranoids are not concerned about MiTM and DoS attacks in general! Regarding your comment "mucking with the MN-HA AE is not good", if MN-HA AE is not absolutely necessary in the RRP messages, I will be more than happy to propose that when code 131 is included, the RRP contains no MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a better suggestion that does not break current implementations, and does not produce a new mip4 protocol, I don't think we have a choice here. > Kent >=20 > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 1:43 PM > > To: Kent Leung (kleung) > > Cc: Mobile IPv4 Mailing List > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator fails > > > > Hi Kent, > > > > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > > If there is no SA, then I don't think HA should send a RRP. > > > > Maybe, but it leaves the MN and user with less information > > than it/he could have. I think that the best would be if we > > could find a standard way of handling this situation. > > > > Fwiw, this has come up before, we discussed how to handle > > this at ipUnplugged some time ago - it's a real situation > > when you're setting up and deploying a network. > > > > Regards, > > > > Henrik > > > > > Kent > > > > > >> -----Original Message----- > > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > >> Sent: Wednesday, June 21, 2006 10:05 AM > > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> fails > > >> > > >> Kent/Avi, > > >> > > >> The current text does not say that the HA cannot send RRP > > when auth > > >> fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > > >> > > >> > if the Authenticator is invalid, the home agent MUST reject the > > >> > mobile node's registration and SHOULD send a > > Registration Reply to > > >> > the mobile node with Code 131" > > >> > > >> What we need is a proper description of the HA and the MN > > behaviors > > >> when the auth fails and the HA needs to send a RRP to stop the MN > > >> from re-trying unnecessarily. > > >> > > >> The clarification could be: > > >> > > >> If the Authenticator is invalid, the home agent MUST reject the > > >> mobile node's registration and SHOULD send a Registration Reply to > > >> the mobile node with Code 131. In this case, the HA populates the > > >> MN-HA AE with all 0s. Upon receiving the RRP with error > > code 131, the > > >> MN skips MN-HA AE validation and stops retrying registration > > >> attempts. The MN MAY log this event in its internal log. > > >> > > >> What do you think? > > >> > > >> -Kuntal > > >> > > >> > -----Original Message----- > > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > >> > Sent: Wednesday, June 21, 2006 11:43 AM > > >> > To: Avi Lior; Mobile IPv4 Mailing List > > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > fails > > >> > > > >> > Hi Avi. My understanding is that in this case, the HA > > will not be > > >> > able to send an RRP if it does not have an SA with the > > MN because > > >> > this message requires MN-HA AE. The text state that if HA has > > >> an SA, then > > >> to > > >> > use that in the RRP. Without an SA, the HA should drop > > the RRQ, IMHO. > > >> > > > >> > Kent > > >> > > > >> > > -----Original Message----- > > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > > >> > > To: Mobile IPv4 Mailing List > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > > fails > > >> > > > > >> > > Hi, > > >> > > > > >> > > While working a scenario in WiMAX I have run into some > > ambiguity > > >> > > in RFC3344. > > >> > > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > >> > > which it fails to authenticate. In particular the HA cant > > >> > > authenticate because it can't obtain the MN-HA from > > the AAA using the NAI. > > >> > > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > > >> > > Reply should be > > >> > > sent with code 131. > > >> > > > > >> > > "if the Authenticator is invalid, the home agent MUST > > reject the > > >> > > mobile node's registration and SHOULD send a > > Registration Reply > > >> > > to the mobile node with Code 131" > > >> > > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > > >> > > > > >> > > "If the Code field indicates an authentication failure, > > >> > > either at the > > >> > > foreign agent or the home agent, then it is quite > > possible that any > > >> > > authenticators in the Registration Reply will also > > be in error. > > >> > > This > > >> > > could happen, for example, if the shared secret > > between the mobile > > >> > > node and home agent was erroneously configured. > > The mobile node > > >> > > SHOULD log such errors as security exceptions." > > >> > > > > >> > > RFC3344 also states that Registration Reply MUST > > include a MN-HA > > >> > > authentication extension: > > >> > > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) > > MUST appear > > >> > > in every Registration Reply sent by the home agent." > > >> > > > > >> > > where (c) is The Mobile-Home Authentication Extension. > > >> > > > > >> > > The problem is that when MN-HA-AE fails at the HA > > there isnt an > > >> > > available MN-HA authentication extension to use. So > > how can one > > >> > > send a registration reply? > > >> > > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for > > the mobile, > > >> > > what should happen? > > >> > > > > >> > > > > >> > > Any help will be appreciated. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > >> > > > > >> > > Avi Lior > > >> > > Bridgewater Systems Corporation > > >> > > Phone : +1 (613) 591-9104 x6417 > > >> > > Cell : +1 (613) 796-4183 > > >> > > E-mail : mailto:avi@bridgewatersystems.com > > >> > > > > >> > > www.bridgewatersystems.com > > >> > > > > >> > > > > >> > > -- > > >> > > Mip4 mailing list: Mip4@ietf.org > > >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > > Charter page: > > >> > > http://www.ietf.org/html.charters/mip4-charter.html > > >> > > Supplemental site: http://www.mip4.org/ > > >> > > > > >> > > > >> > -- > > >> > Mip4 mailing list: Mip4@ietf.org > > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > Charter page: > > >> > http://www.ietf.org/html.charters/mip4-charter.html > > >> > Supplemental site: http://www.mip4.org/ > > >> > > >> > > >> "This email message and any attachments are confidential > > information > > >> of Starent Networks, Corp. The information transmitted may not be > > >> used to create or change any contractual obligations of Starent > > >> Networks, Corp. Any review, retransmission, dissemination > > or other > > >> use of, or taking of any action in reliance upon this > > e-mail and its > > >> attachments by persons or entities other than the intended > > recipient > > >> is prohibited. If you are not the intended recipient, > > please notify > > >> the sender immediately -- by replying to this message or > > by sending > > >> an email to postmaster@starentnetworks.com -- and destroy > > all copies > > >> of this message and any attachments without reading or disclosing > > >> their contents. Thank you." > > >> > > > > > > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ =20 ------_=_NextPart_001_01C69639.FA50D108 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I thought the issue was avoiding a = rouge HA sending a fake RRP with reject code, and no amount of access control = can help that..

 

From: = Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
Sent: Thursday, June 22, = 2006 1:53 PM
To: Behcet Sarikaya; Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: RE: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

 

Yep…same case for other = access technologies as well.  That means, rogue mobiles sending bogus RRQ = packets to the HA is extremely slim.

 

-Kuntal

=

 

 

From: = Behcet Sarikaya = [mailto:behcetsarikaya@yahoo.com]
Sent: Thursday, June 22, = 2006 1:06 PM
To: Chowdhury, Kuntal; = Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: Re: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

 

Hi Kuntal
  In WiMAX, if MS fails EAP authentication, it is out, it cannot = even send an RREQ.

Regards,

Behcet

----- Original = Message ----
From: "Chowdhury, Kuntal" = <kchowdhury@starentnetworks.com>
To: Kent Leung (kleung) <kleung@cisco.com>
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>; Henrik Levkowetz <henrik@levkowetz.com>
Sent: Thursday, June 22, 2006 10:48:03 AM
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator = fails



> -----Original Message-----
> From: Kent Leung (kleung) [mailto:kleung@cisco.com]
> Sent: Thursday, June 22, 2006 1:43 AM
> To: Henrik Levkowetz
> Cc: Mobile IPv4 Mailing List
> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the = Authenticator
fails
>
> Hi Henrik.  I think the protocol can already handle authentication
> failures sufficiently.
>
> It's possible for MN to have multiple security contexts (indexed = by
> different SPIs) with the HA.  One could be used for = registration and
the
> other for authenticating RRP with error code 131.  So I = believe RFC
3344
> provides the mechanism already.  As long as HA has an SA = that can be
> used to protect the RRP with the MN-HA AE, it can inform the MN = such
> event happened in a secure manner.
>
> I think mucking with the MN-HA AE is not good.  This can = create the
> situation when MN sends a valid RRQ, and MITM can send a RRP = with
error
> code 131 and invalid MN-HA AE to the MN = immediately.  When the RRP is
> received, the MN will stop retrying.  It's possible that = the RRQ was
> lost in transit to the HA.  And even if the valid RRP = arrives later,
MN
> may not be able to associate with the any pending RRQ, which = could
have
> been possibly removed since an associated RRP had been received
already.
>
[KC>] If the HA does not send RRP back to the MN, as you = initially
suggested, the MN will keep retrying. That is not good either.

Look at other protocols. For example EAP, if auth fails, the
authenticator MUST send back a failure packet to the peer. Same case = for
other protocols over UNI. So, I am wondering why the paranoids are = not
concerned about MiTM and DoS attacks in general!

Regarding your comment "mucking with the MN-HA AE is not = good", if MN-HA
AE is not absolutely necessary in the RRP messages, I will be more = than
happy to propose that when code 131 is included, the RRP contains no
MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a
better suggestion that does not break current implementations, and = does
not produce a new mip4 protocol, I don't think we have a choice = here.



> Kent
>
> > -----Original Message-----
> > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> > Sent: Wednesday, June 21, 2006 1:43 PM
> > To: Kent Leung (kleung)
> > Cc: Mobile IPv4 Mailing = List
> > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator fails
> >
> > Hi Kent,
> >
> > on 2006-06-21 19:13 Kent Leung (kleung) said the = following:
> > > If there is no SA, then I don't think HA should send a = RRP.
> >
> > Maybe, but it leaves the MN and user with less information
> > than it/he could have.  I think that the best would = be if we
> > could find a standard way of handling this situation.
> >
> > Fwiw, this has come up before, we discussed how to handle
> > this at ipUnplugged some time ago - it's a real situation
> > when you're setting up and deploying a network.
> >
> > Regards,
> >
> >     Henrik
> >
> > > Kent
> > >
> > >> -----Original Message-----
> > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
> > >> Sent: Wednesday, June 21, 2006 10:05 AM
> > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 = Mailing List
> > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when = the
> > Authenticator
> > >> fails
> > >>
> > >> Kent/Avi,
> > >>
> > >> The current text does not say that the HA cannot send = RRP
> > when auth
> > >> fails. Rather it says that the HA "SHOULD" = send RRP back to the
MN:
> > >>
> > >> > if the Authenticator is invalid, the home agent = MUST reject
the
> > >> > mobile node's registration and SHOULD send a
> > Registration Reply to
> > >> > the mobile node with Code 131"
> > >>
> > >> What we need is a proper description of the HA and = the MN
> > behaviors
> > >> when the auth fails and the HA needs to send a RRP to = stop the MN
> > >> from re-trying unnecessarily.
> > >>
> > >> The clarification could be:
> > >>
> > >> If the Authenticator is invalid, the home agent MUST = reject the
> > >> mobile node's registration and SHOULD send a = Registration Reply
to
> > >> the mobile node with Code 131. In this case, the HA populates the
> > >> MN-HA AE with all 0s. Upon receiving the RRP with = error
> > code 131, the
> > >> MN skips MN-HA AE validation and stops retrying = registration
> > >> attempts. The MN MAY log this event in its internal = log.
> > >>
> > >> What do you think?
> > >>
> > >> -Kuntal
> > >>
> > >> > -----Original Message-----
> > >> > From: Kent Leung (kleung) = [mailto:kleung@cisco.com]
> > >> > Sent: Wednesday, June 21, 2006 11:43 AM
> > >> > To: Avi Lior; Mobile IPv4 Mailing List
> > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply = when the
> > Authenticator
> > >> > fails
> > >> >
> > >> > Hi Avi.  My understanding is that in = this case, the HA
> > will not be
> > >> > able to send an RRP if it does not have an SA = with the
> > MN because
> > >> > this message requires MN-HA AE.  The = text state that if HA has
> > >> an SA, then
> > >> to
> > >> > use that in the RRP.  Without an SA, = the HA should drop
> > the  RRQ, IMHO.
> > >> >
> > >> > Kent
> > >> >
> > >> > > -----Original Message-----
> > >> > > From: Avi Lior = [mailto:avi@bridgewatersystems.com]
> > >> > > Sent: Wednesday, June 21, 2006 8:13 AM
> > >> > > To: Mobile IPv4 Mailing List
> > >> > > Subject: [Mip4] 3344 Sending a Reg Reply = when the
> > Authenticator
> > >> > > fails
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > While working a scenario in WiMAX I have = run into some
> >  ambiguity
> > >> > > in RFC3344.
> > >> > >
> > >> > > The HA receives a Reg Request with MN-HA-AE = and NAI
extension
> > >> > > which it fails to = authenticate.  In particular the HA cant
> > >> > > authenticate because it can't obtain the = MN-HA from
> > the AAA using the NAI.
> > >> > >
> > >> > > >From section 3.8.2.1 RFC3344 states = that a Registration
> > >> > > Reply should be
> > >> > > sent with code 131.
> > >> > >
> > >> > > "if the Authenticator is invalid, the = home agent MUST
> > reject the
> > >> > > mobile node's registration and SHOULD send = a
> > Registration  Reply
> > >> > > to the mobile node with Code 131"
> > >> > >
> > >> > > And from section 3.6.2.1 describing the MN behavior we have:
> > >> > >
> > >> > >    "If the Code = field indicates an authentication  failure,
> > >> > > either at the
> > >> > >    foreign agent or the = home agent, then it is quite
> > possible that any
> > >> > >    authenticators in = the Registration Reply will also
> > be  in error.
> > >> > > This
> > >> > >    could happen, for = example, if the shared secret
> > between the mobile
> > >> > >    node and home agent = was erroneously configured.
> > The  mobile node
> > >> > >    SHOULD log such = errors as security exceptions."
> > >> > >
> > >> > > RFC3344 also states that Registration Reply = MUST
> > include a MN-HA
> > >> > > authentication extension:
> > >> > >
> > >> > > Section 3.8.3.3 says  " Note = that items (a) and (c)
> > MUST  appear
> > >> > > in every Registration Reply sent by the = home agent."
> > >> > >
> > >> > > where  (c) is  The = Mobile-Home Authentication Extension.
> > >> > >
> > >> > > The problem is that when MN-HA-AE fails at = the HA
> > there isnt an
> > >> > > available MN-HA authentication extension to use.  So
> > how can one
> > >> > > send a registration reply?
> > >> > >
> > >> > > Furthermore, if the HA cant not obtain an = MN-HA for
> > the  mobile,
> > >> > > what should happen?
> > >> > >
> > >> > >
> > >> > > Any help will be appreciated.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > >> > >
> > >> > > Avi Lior
> > >> > > Bridgewater Systems Corporation
> > >> > > Phone :  +1 (613) 591-9104 = x6417
> > >> > > Cell    :  +1 = (613) 796-4183
> > >> > > E-mail : = mailto:avi@bridgewatersystems.com
> > >> > > = <mailto:avi@bridgewatersystems.com>
> > >> > > www.bridgewatersystems.com
<http://www.bridgewatersystems.com/>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Mip4 mailing list: Mip4@ietf.org
> > >> > >     Web interface:
https://www1.ietf.org/mailman/listinfo/mip4
> > >> > >      Charter = page:
> > >> > > http://www.ietf.org/html.charters/mip4-charter.html=
> > >> > > Supplemental site: http://www.mip4.org/
> > >> > >
> > >> >
> > >> > --
> > >> > Mip4 mailing list: Mip4@ietf.org
> > >> >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> > >> >      Charter = page:
> > >> > http://www.ietf.org/html.charters/mip4-charter.html=
> > >> > Supplemental site: http://www.mip4.org/
> > >>
> > >>
> > >> "This email message and any attachments are confidential
> > information
> > >> of Starent Networks, Corp. The information = transmitted may not be
> > >> used to create or change any contractual obligations = of Starent
> > >> Networks, Corp.  Any review, = retransmission, dissemination
> > or other
> > >> use of, or taking of any action in reliance upon = this
> > e-mail and its
> > >> attachments by persons or entities other than the = intended
> > recipient
> > >> is prohibited. If you are not the intended = recipient,
> > please notify
> > >> the sender immediately -- by replying to this message = or
> > by sending
> > >> an email to postmaster@starentnetworks.com -- and = destroy
> > all copies
> > >> of this message and any attachments without reading = or disclosing
> > >> their contents. Thank you."
> > >>
> > >
> >
> >
>
> --
> Mip4 mailing list: Mip4@ietf.org
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html=
> Supplemental site: http://www.mip4.org/

--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html=
Supplemental site: http://www.mip4.org/

 

------_=_NextPart_001_01C69639.FA50D108-- --===============2027971540== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============2027971540==-- From mip4-bounces@ietf.org Thu Jun 22 17:31:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWlR-0003cJ-5o; Thu, 22 Jun 2006 17:31:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtWlQ-0003Zr-3d for mip4@ietf.org; Thu, 22 Jun 2006 17:31:00 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtWlN-0006Kr-OT for mip4@ietf.org; Thu, 22 Jun 2006 17:31:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 22 Jun 2006 17:31:13 -0400 Message-ID: In-Reply-To: <7CCD07160348804497EF29E9EA5560D73C51CD@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFA= From: "Avi Lior" To: "Chowdhury, Kuntal" , "Behcet Sarikaya" , "Kent Leung \(kleung\)" X-Spam-Score: 0.1 (/) X-Scan-Signature: 1b2066b7e944cd0f55ca6d7a2077c2e4 Cc: Mobile IPv4 Mailing List , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1132976635==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1132976635== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69643.3448A5ED" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69643.3448A5ED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A rogue mobile can gain network access and then send bogus MIP Reg Request totally masquerading the UDP packet. Only specialized consideration in the access network can thwart that attack, otherwise the bogus MIP Reg Request is off to the HA.=20 =20 As well, compromise of a network element in the Access Network could also send MIP Reg Request especially if Proxy MIP is being used. ________________________________ From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Thursday, June 22, 2006 2:53 PM To: Behcet Sarikaya; Kent Leung (kleung) Cc: Mobile IPv4 Mailing List; Henrik Levkowetz Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =09 =09 Yep...same case for other access technologies as well. That means, rogue mobiles sending bogus RRQ packets to the HA is extremely slim. =20 -Kuntal =20 =20 =09 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Thursday, June 22, 2006 1:06 PM To: Chowdhury, Kuntal; Kent Leung (kleung) Cc: Mobile IPv4 Mailing List; Henrik Levkowetz Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 Hi Kuntal In WiMAX, if MS fails EAP authentication, it is out, it cannot even send an RREQ. =09 Regards, =09 Behcet ----- Original Message ---- From: "Chowdhury, Kuntal" To: Kent Leung (kleung) Cc: Mobile IPv4 Mailing List ; Henrik Levkowetz Sent: Thursday, June 22, 2006 10:48:03 AM Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =09 =09 > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Thursday, June 22, 2006 1:43 AM > To: Henrik Levkowetz > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi Henrik. I think the protocol can already handle authentication > failures sufficiently. >=20 > It's possible for MN to have multiple security contexts (indexed by > different SPIs) with the HA. One could be used for registration and the > other for authenticating RRP with error code 131. So I believe RFC 3344 > provides the mechanism already. As long as HA has an SA that can be > used to protect the RRP with the MN-HA AE, it can inform the MN such > event happened in a secure manner. >=20 > I think mucking with the MN-HA AE is not good. This can create the > situation when MN sends a valid RRQ, and MITM can send a RRP with error > code 131 and invalid MN-HA AE to the MN immediately. When the RRP is > received, the MN will stop retrying. It's possible that the RRQ was > lost in transit to the HA. And even if the valid RRP arrives later, MN > may not be able to associate with the any pending RRQ, which could have > been possibly removed since an associated RRP had been received already. >=20 [KC>] If the HA does not send RRP back to the MN, as you initially suggested, the MN will keep retrying. That is not good either. =09 Look at other protocols. For example EAP, if auth fails, the authenticator MUST send back a failure packet to the peer. Same case for other protocols over UNI. So, I am wondering why the paranoids are not concerned about MiTM and DoS attacks in general! =09 Regarding your comment "mucking with the MN-HA AE is not good", if MN-HA AE is not absolutely necessary in the RRP messages, I will be more than happy to propose that when code 131 is included, the RRP contains no MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a better suggestion that does not break current implementations, and does not produce a new mip4 protocol, I don't think we have a choice here. =09 =09 =09 > Kent >=20 > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 1:43 PM > > To: Kent Leung (kleung) > > Cc: Mobile IPv4 Mailing List > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator fails > > > > Hi Kent, > > > > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > > If there is no SA, then I don't think HA should send a RRP. > > > > Maybe, but it leaves the MN and user with less information > > than it/he could have. I think that the best would be if we > > could find a standard way of handling this situation. > > > > Fwiw, this has come up before, we discussed how to handle > > this at ipUnplugged some time ago - it's a real situation > > when you're setting up and deploying a network. > > > > Regards, > > > > Henrik > > > > > Kent > > > > > >> -----Original Message----- > > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > >> Sent: Wednesday, June 21, 2006 10:05 AM > > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> fails > > >> > > >> Kent/Avi, > > >> > > >> The current text does not say that the HA cannot send RRP > > when auth > > >> fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > > >> > > >> > if the Authenticator is invalid, the home agent MUST reject the > > >> > mobile node's registration and SHOULD send a > > Registration Reply to > > >> > the mobile node with Code 131" > > >> > > >> What we need is a proper description of the HA and the MN > > behaviors > > >> when the auth fails and the HA needs to send a RRP to stop the MN > > >> from re-trying unnecessarily. > > >> > > >> The clarification could be: > > >> > > >> If the Authenticator is invalid, the home agent MUST reject the > > >> mobile node's registration and SHOULD send a Registration Reply to > > >> the mobile node with Code 131. In this case, the HA populates the > > >> MN-HA AE with all 0s. Upon receiving the RRP with error > > code 131, the > > >> MN skips MN-HA AE validation and stops retrying registration > > >> attempts. The MN MAY log this event in its internal log. > > >> > > >> What do you think? > > >> > > >> -Kuntal > > >> > > >> > -----Original Message----- > > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > >> > Sent: Wednesday, June 21, 2006 11:43 AM > > >> > To: Avi Lior; Mobile IPv4 Mailing List > > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > fails > > >> > > > >> > Hi Avi. My understanding is that in this case, the HA > > will not be > > >> > able to send an RRP if it does not have an SA with the > > MN because > > >> > this message requires MN-HA AE. The text state that if HA has > > >> an SA, then > > >> to > > >> > use that in the RRP. Without an SA, the HA should drop > > the RRQ, IMHO. > > >> > > > >> > Kent > > >> > > > >> > > -----Original Message----- > > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > > >> > > To: Mobile IPv4 Mailing List > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > > fails > > >> > > > > >> > > Hi, > > >> > > > > >> > > While working a scenario in WiMAX I have run into some > > ambiguity > > >> > > in RFC3344. > > >> > > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > >> > > which it fails to authenticate. In particular the HA cant > > >> > > authenticate because it can't obtain the MN-HA from > > the AAA using the NAI. > > >> > > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > > >> > > Reply should be > > >> > > sent with code 131. > > >> > > > > >> > > "if the Authenticator is invalid, the home agent MUST > > reject the > > >> > > mobile node's registration and SHOULD send a > > Registration Reply > > >> > > to the mobile node with Code 131" > > >> > > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > > >> > > > > >> > > "If the Code field indicates an authentication failure, > > >> > > either at the > > >> > > foreign agent or the home agent, then it is quite > > possible that any > > >> > > authenticators in the Registration Reply will also > > be in error. > > >> > > This > > >> > > could happen, for example, if the shared secret > > between the mobile > > >> > > node and home agent was erroneously configured. > > The mobile node > > >> > > SHOULD log such errors as security exceptions." > > >> > > > > >> > > RFC3344 also states that Registration Reply MUST > > include a MN-HA > > >> > > authentication extension: > > >> > > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) > > MUST appear > > >> > > in every Registration Reply sent by the home agent." > > >> > > > > >> > > where (c) is The Mobile-Home Authentication Extension. > > >> > > > > >> > > The problem is that when MN-HA-AE fails at the HA > > there isnt an > > >> > > available MN-HA authentication extension to use. So > > how can one > > >> > > send a registration reply? > > >> > > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for > > the mobile, > > >> > > what should happen? > > >> > > > > >> > > > > >> > > Any help will be appreciated. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > >> > > > > >> > > Avi Lior > > >> > > Bridgewater Systems Corporation > > >> > > Phone : +1 (613) 591-9104 x6417 > > >> > > Cell : +1 (613) 796-4183 > > >> > > E-mail : mailto:avi@bridgewatersystems.com > > >> > > > > >> > > www.bridgewatersystems.com > > >> > > > > >> > > > > >> > > -- > > >> > > Mip4 mailing list: Mip4@ietf.org > > >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > > Charter page: > > >> > > http://www.ietf.org/html.charters/mip4-charter.html > > >> > > Supplemental site: http://www.mip4.org/ > > >> > > > > >> > > > >> > -- > > >> > Mip4 mailing list: Mip4@ietf.org > > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > Charter page: > > >> > http://www.ietf.org/html.charters/mip4-charter.html > > >> > Supplemental site: http://www.mip4.org/ > > >> > > >> > > >> "This email message and any attachments are confidential > > information > > >> of Starent Networks, Corp. The information transmitted may not be > > >> used to create or change any contractual obligations of Starent > > >> Networks, Corp. Any review, retransmission, dissemination > > or other > > >> use of, or taking of any action in reliance upon this > > e-mail and its > > >> attachments by persons or entities other than the intended > > recipient > > >> is prohibited. If you are not the intended recipient, > > please notify > > >> the sender immediately -- by replying to this message or > > by sending > > >> an email to postmaster@starentnetworks.com -- and destroy > > all copies > > >> of this message and any attachments without reading or disclosing > > >> their contents. Thank you." > > >> > > > > > > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ =09 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ =20 ------_=_NextPart_001_01C69643.3448A5ED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A rogue mobile can gain network access and then = send bogus=20 MIP Reg Request totally masquerading the UDP packet. Only = specialized=20 consideration in the access network can thwart that attack,=20 otherwise the bogus MIP Reg Request is off to the=20 HA. 
 
As well, compromise of a network element in the = Access=20 Network could also send MIP Reg Request especially if Proxy MIP is being = used.

From: Chowdhury, Kuntal=20 [mailto:kchowdhury@starentnetworks.com]
Sent: Thursday, = June 22,=20 2006 2:53 PM
To: Behcet Sarikaya; Kent Leung = (kleung)
Cc:=20 Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: RE: = [Mip4] 3344=20 Sending a Reg Reply when the Authenticator fails

Yep…same case for=20 other access technologies as well.  That means, rogue mobiles = sending=20 bogus RRQ packets to the HA is extremely = slim.

 

-Kuntal

 

 

From: Behcet=20 Sarikaya [mailto:behcetsarikaya@yahoo.com]
Sent: Thursday, June 22, 2006 = 1:06=20 PM
To: Chowdhury, = Kuntal;=20 Kent Leung (kleung)
Cc:=20 Mobile IPv4 Mailing List; Henrik=20 Levkowetz
Subject: = Re: [Mip4]=20 3344 Sending a Reg Reply when the Authenticator=20 fails

 

Hi Kuntal
  In WiMAX, = if MS fails=20 EAP authentication, it is out, it cannot even send an=20 RREQ.

Regards,

Behcet

----- Original Message = ----
From:=20 "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: Kent = Leung=20 (kleung) <kleung@cisco.com>
Cc: Mobile IPv4 Mailing List = <mip4@ietf.org>; Henrik=20 Levkowetz <henrik@levkowetz.com>
Sent: Thursday, June 22, = 2006=20 10:48:03 AM
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 Authenticator fails



> -----Original = Message-----
> From:=20 Kent Leung (kleung) [mailto:kleung@cisco.com]
> Sent: Thursday, = June 22,=20 2006 1:43 AM
> To: Henrik Levkowetz
> Cc: Mobile IPv4 Mailing List
> Subject: RE: = [Mip4]=20 3344 Sending a Reg Reply when the Authenticator
fails
> =
> Hi=20 Henrik.  I think the protocol can already handle=20 authentication
> failures sufficiently.
>
> It's = possible=20 for MN to have multiple security contexts (indexed by
> = different SPIs)=20 with the HA.  One could be used for registration = and
the
>=20 other for authenticating RRP with error code 131.  So I = believe=20 RFC
3344
> provides the mechanism already.  As long = as HA=20 has an SA that can be
> used to protect the RRP with the MN-HA = AE, it=20 can inform the MN such
> event happened in a secure = manner.
>=20
> I think mucking with the MN-HA AE is not = good.  This can=20 create the
> situation when MN sends a valid RRQ, and MITM can = send a=20 RRP with
error
> code 131 and invalid MN-HA AE to the MN=20 immediately.  When the RRP is
> received, the MN will = stop=20 retrying.  It's possible that the RRQ was
> lost in = transit to=20 the HA.  And even if the valid RRP arrives = later,
MN
> may=20 not be able to associate with the any pending RRQ, which = could
have
>=20 been possibly removed since an associated RRP had been=20 received
already.
>
[KC>] If the HA does not send RRP = back to=20 the MN, as you initially
suggested, the MN will keep retrying. That = is not=20 good either.

Look at other protocols. For example EAP, if auth = fails,=20 the
authenticator MUST send back a failure packet to the peer. Same = case=20 for
other protocols over UNI. So, I am wondering why the paranoids = are=20 not
concerned about MiTM and DoS attacks in = general!

Regarding your=20 comment "mucking with the MN-HA AE is not good", if MN-HA
AE is not = absolutely necessary in the RRP messages, I will be more than
happy = to=20 propose that when code 131 is included, the RRP contains no
MN-HA = AE.=20 However, MN-HA AE is a MUST in RRP. So, unless you have a
better = suggestion=20 that does not break current implementations, and does
not produce a = new=20 mip4 protocol, I don't think we have a choice = here.



>=20 Kent
>
> = >=20 -----Original Message-----
> > From: Henrik Levkowetz=20 [mailto:henrik@levkowetz.com]
> > Sent: Wednesday, June 21, = 2006 1:43=20 PM
> > To: Kent Leung (kleung)
> > Cc: Mobile IPv4 Mailing List
> > Subject: = Re:=20 [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator=20 fails
> >
> > Hi Kent,
> = >
> > on=20 2006-06-21 19:13 Kent Leung (kleung) said the following:
> > = > If=20 there is no SA, then I don't think HA should send a RRP.
> = >
>=20 > Maybe, but it leaves the MN and user with less = information
> >=20 than it/he could have.  I think that the best would be if = we
>=20 > could find a standard way of handling this situation.
>=20 >
> > Fwiw, this has come up before, we discussed how to=20 handle
> > this at ipUnplugged some time ago - it's a real=20 situation
> > when you're setting up and deploying a = network.
>=20 >
> > Regards,
> >
> >=20     Henrik
> >
> > >=20 Kent
> > = >
> >=20 >> -----Original Message-----
> > >> From: = Chowdhury,=20 Kuntal [mailto:kchowdhury@starentnetworks.com]
> > >> = Sent:=20 Wednesday, June 21, 2006 10:05 AM
> > >> To: Kent Leung = (kleung); Avi Lior; Mobile IPv4 Mailing List
> > >> = Subject:=20 RE: [Mip4] 3344 Sending a Reg Reply when the
> >=20 Authenticator
> > >> fails
> > = >>
> >=20 >> Kent/Avi,
> > >>
> > >> The = current=20 text does not say that the HA cannot send RRP
> > when = auth
>=20 > >> fails. Rather it says that the HA "SHOULD" send RRP back = to=20 the
MN:
> > >>
> > >> > if the=20 Authenticator is invalid, the home agent MUST reject
the
> = >=20 >> > mobile node's registration and SHOULD send a
> = >=20 Registration Reply to
> > >> > the mobile node with = Code=20 131"
> > >>
> > >> What we need is a = proper=20 description of the HA and the MN
> > behaviors
> > = >>=20 when the auth fails and the HA needs to send a RRP to stop the = MN
> >=20 >> from re-trying unnecessarily.
> > >>
> = >=20 >> The clarification could be:
> > >>
> = >=20 >> If the Authenticator is invalid, the home agent MUST reject=20 the
> > >> mobile node's registration and SHOULD send a = Registration Reply
to
> > >> the mobile node with = Code 131.=20 In this case, the HA populates the
> > >> MN-HA AE with = all 0s.=20 Upon receiving the RRP with error
> > code 131, the
> = >=20 >> MN skips MN-HA AE validation and stops retrying = registration
>=20 > >> attempts. The MN MAY log this event in its internal = log.
>=20 > >>
> > >> What do you think?
> >=20 >>
> > >> -Kuntal
> > >>
> = >=20 >> > -----Original Message-----
> > >> > = From: Kent=20 Leung (kleung) [mailto:kleung@cisco.com]
> > >> > = Sent:=20 Wednesday, June 21, 2006 11:43 AM
> > >> > To: Avi = Lior;=20 Mobile IPv4 Mailing List
> = >=20 >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when = the
>=20 > Authenticator
> > >> > fails
> > = >>=20 >
> > >> > Hi Avi.  My understanding is = that in=20 this case, the HA
> > will not be
> > >> > = able to=20 send an RRP if it does not have an SA with the
> > MN = because
>=20 > >> > this message requires MN-HA AE.  The text = state=20 that if HA has
> > >> an SA, then
> > >> = to
> > >> > use that in the RRP.  Without = an SA,=20 the HA should drop
> > the  RRQ, IMHO.
> > = >> >
> > >> > Kent
>=20 > >> >
> > >> > > -----Original=20 Message-----
> > >> > > From: Avi Lior=20 [mailto:avi@bridgewatersystems.com]
> > >> > > = Sent:=20 Wednesday, June 21, 2006 8:13 AM
> > >> > > To:=20 Mobile IPv4 Mailing List
> = >=20 >> > > Subject: [Mip4] 3344 Sending a Reg Reply when = the
>=20 > Authenticator
> > >> > > fails
> > = >>=20 > >
> > >> > > Hi,
> > >> = >=20 >
> > >> > > While working a scenario in WiMAX = I have=20 run into some
> >  ambiguity
> > >> = >=20 > in RFC3344.
> > >> > >
> > >> = >=20 > The HA receives a Reg Request with MN-HA-AE and = NAI
extension
>=20 > >> > > which it fails to authenticate.  In=20 particular the HA cant
> > >> > > authenticate = because it=20 can't obtain the MN-HA from
> > the AAA using the = NAI.
> >=20 >> > >
> > >> > > >From section = 3.8.2.1=20 RFC3344 states that a Registration
> > >> > > = Reply=20 should be
> > >> > > sent with code 131.
> = >=20 >> > >
> > >> > > "if the = Authenticator is=20 invalid, the home agent MUST
> > reject the
> > = >>=20 > > mobile node's registration and SHOULD send a
> >=20 Registration  Reply
> > >> > > to the = mobile=20 node with Code 131"
> > >> > >
> > = >> >=20 > And from section 3.6.2.1 describing the MN behavior we = have:
> >=20 >> > >
> > >> > = >    "If=20 the Code field indicates an authentication  failure,
> = >=20 >> > > either at the
> > >> >=20 >    foreign agent or the home agent, then it = is=20 quite
> > possible that any
> > >> >=20 >    authenticators in the Registration Reply = will=20 also
> > be  in error.
> > >> > = >=20 This
> > >> > >    could = happen, for=20 example, if the shared secret
> > between the mobile
> = >=20 >> > >    node and home agent was = erroneously=20 configured.
> > The  mobile node
> > = >> >=20 >    SHOULD log such errors as security=20 exceptions."
> > >> > >
> > >> = > >=20 RFC3344 also states that Registration Reply MUST
> > include = a=20 MN-HA
> > >> > > authentication = extension:
> >=20 >> > >
> > >> > > Section 3.8.3.3=20 says  " Note that items (a) and (c)
> >=20 MUST  appear
> > >> > > in every = Registration=20 Reply sent by the home agent."
> > >> > >
> = >=20 >> > > where  (c) is  The Mobile-Home=20 Authentication Extension.
> > >> > >
> > = >> > > The problem is that when MN-HA-AE fails at the = HA
>=20 > there isnt an
> > >> > > available MN-HA=20 authentication extension to use.  So
> > how can=20 one
> > >> > > send a registration reply?
> = >=20 >> > >
> > >> > > Furthermore, if the = HA cant=20 not obtain an MN-HA for
> > the  mobile,
> = >=20 >> > > what should happen?
> > >> > = >
>=20 > >> > >
> > >> > > Any help will = be=20 appreciated.
> > >> > >
> > >> = >=20 >
> > >> > >
> > >> > = >
>=20 > >> > >
> > >> > >
> > = >>=20 > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > >> > >
>=20 > >> > > Avi Lior
> > >> > > = Bridgewater=20 Systems Corporation
> > >> > > Phone = :  +1=20 (613) 591-9104 x6417
> > >> > >=20 Cell    :  +1 (613) 796-4183
> = >=20 >> > > E-mail : mailto:avi@bridgewatersystems.com
> = >=20 >> > > <mailto:avi@bridgewatersystems.com>
> = >=20 >> > > www.bridgewatersystems.com
<http://www.bridgewatersystems.com/>
> = > >>=20 > >
> > >> > >
> > >> > = >=20 --
> > >> > > Mip4 mailing list: = Mip4@ietf.org
>=20 > >> > >     Web interface:
https://www1.ietf.org/mailman/listinfo/mip4
> = >=20 >> > >      Charter = page:
>=20 > >> > > http://www.ietf.org/html.charters/mip4-charter.html>=20 > >> > > Supplemental site: http://www.mip4.org/
> > >> > = >
>=20 > >> >
> > >> > --
> > >> = >=20 Mip4 mailing list: Mip4@ietf.org
> > >>=20 >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> = >=20 >> >      Charter page:
> = >=20 >> > http://www.ietf.org/html.charters/mip4-charter.html>=20 > >> > Supplemental site: http://www.mip4.org/
> > >>
> = >=20 >>
> > >> "This email message and any attachments = are=20 confidential
> > information
> > >> of Starent = Networks, Corp. The information transmitted may not be
> > = >>=20 used to create or change any contractual obligations of = Starent
> >=20 >> Networks, Corp.  Any review, retransmission,=20 dissemination
> > or other
> > >> use of, or = taking of=20 any action in reliance upon this
> > e-mail and its
> = >=20 >> attachments by persons or entities other than the = intended
>=20 > recipient
> > >> is prohibited. If you are not the = intended recipient,
> > please notify
> > >> = the=20 sender immediately -- by replying to this message or
> > by=20 sending
> > >> an email to = postmaster@starentnetworks.com --=20 and destroy
> > all copies
> > >> of this = message and=20 any attachments without reading or disclosing
> > >> = their=20 contents. Thank you."
> > >>
> > >
>=20 >
> >
>
> --
> Mip4 mailing list:=20 Mip4@ietf.org
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>&n= bsp;     Charter=20 page: http://www.ietf.org/html.charters/mip4-charter.html>=20 Supplemental site: http://www.mip4.org/

--
Mip4 mailing = list:=20 Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
 =    =20 Charter page: http://www.ietf.org/html.charters/mip4-charter.htmlSupplemental=20 site: http://www.mip4.org/

 

------_=_NextPart_001_01C69643.3448A5ED-- --===============1132976635== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1132976635==-- From mip4-bounces@ietf.org Thu Jun 22 19:28:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYbQ-0005OS-GU; Thu, 22 Jun 2006 19:28:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtYbO-0005NR-Ra for mip4@ietf.org; Thu, 22 Jun 2006 19:28:46 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtYbM-0000Ws-AV for mip4@ietf.org; Thu, 22 Jun 2006 19:28:46 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id E5F6A90018 for ; Thu, 22 Jun 2006 19:28:40 -0400 (EDT) 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 22919-10 for ; Thu, 22 Jun 2006 19:28:39 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 22 Jun 2006 19:28:39 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 22 Jun 2006 19:25:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 22 Jun 2006 19:25:40 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51D7@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkA== From: "Chowdhury, Kuntal" To: "Avi Lior" X-OriginalArrivalTime: 22 Jun 2006 23:25:40.0398 (UTC) FILETIME=[2CC1ACE0:01C69653] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.1 (/) X-Scan-Signature: a92223e791a86c0e8c238fc6d8c729a6 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0420235563==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0420235563== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69653.2C977CCC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69653.2C977CCC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Avi, =20 If a rogue MN can break into the network (i.e. pass access auth), anything is possible. However, by putting multiple levels of auth (at least 1 or 2); the operators make this possibility extremely slim. So, let's not get hung-up with the fact that rouge MNs can do bad things. =20 The issue is simple: if the auth of a RRQ fails, should the HA respond back to the MN? There are some people who believe a response should be sent. There are some who believe that the HA should silently discard the packet. =20 In this context, the current mip4 protocol allows the HA to send a response upon auth failure. The current text also allows those HA implementations which like to silently discard the packet. So, let's not change the protocol as it allows both the behaviors/implementations. We can just clarify some text to describe how the response packet is formatted. =20 -Kuntal =20 =20 ________________________________ From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Thursday, June 22, 2006 4:31 PM To: Chowdhury, Kuntal; Behcet Sarikaya; Kent Leung (kleung) Cc: Mobile IPv4 Mailing List; Henrik Levkowetz Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 A rogue mobile can gain network access and then send bogus MIP Reg Request totally masquerading the UDP packet. Only specialized consideration in the access network can thwart that attack, otherwise the bogus MIP Reg Request is off to the HA.=20 =20 As well, compromise of a network element in the Access Network could also send MIP Reg Request especially if Proxy MIP is being used. =20 =09 ________________________________ From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Thursday, June 22, 2006 2:53 PM To: Behcet Sarikaya; Kent Leung (kleung) Cc: Mobile IPv4 Mailing List; Henrik Levkowetz Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Yep...same case for other access technologies as well. That means, rogue mobiles sending bogus RRQ packets to the HA is extremely slim. =20 -Kuntal =20 =20 =09 ________________________________ From: Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]=20 Sent: Thursday, June 22, 2006 1:06 PM To: Chowdhury, Kuntal; Kent Leung (kleung) Cc: Mobile IPv4 Mailing List; Henrik Levkowetz Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 Hi Kuntal In WiMAX, if MS fails EAP authentication, it is out, it cannot even send an RREQ. =09 Regards, =09 Behcet ----- Original Message ---- From: "Chowdhury, Kuntal" To: Kent Leung (kleung) Cc: Mobile IPv4 Mailing List ; Henrik Levkowetz Sent: Thursday, June 22, 2006 10:48:03 AM Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =09 =09 > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > Sent: Thursday, June 22, 2006 1:43 AM > To: Henrik Levkowetz > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails >=20 > Hi Henrik. I think the protocol can already handle authentication > failures sufficiently. >=20 > It's possible for MN to have multiple security contexts (indexed by > different SPIs) with the HA. One could be used for registration and the > other for authenticating RRP with error code 131. So I believe RFC 3344 > provides the mechanism already. As long as HA has an SA that can be > used to protect the RRP with the MN-HA AE, it can inform the MN such > event happened in a secure manner. >=20 > I think mucking with the MN-HA AE is not good. This can create the > situation when MN sends a valid RRQ, and MITM can send a RRP with error > code 131 and invalid MN-HA AE to the MN immediately. When the RRP is > received, the MN will stop retrying. It's possible that the RRQ was > lost in transit to the HA. And even if the valid RRP arrives later, MN > may not be able to associate with the any pending RRQ, which could have > been possibly removed since an associated RRP had been received already. >=20 [KC>] If the HA does not send RRP back to the MN, as you initially suggested, the MN will keep retrying. That is not good either. =09 Look at other protocols. For example EAP, if auth fails, the authenticator MUST send back a failure packet to the peer. Same case for other protocols over UNI. So, I am wondering why the paranoids are not concerned about MiTM and DoS attacks in general! =09 Regarding your comment "mucking with the MN-HA AE is not good", if MN-HA AE is not absolutely necessary in the RRP messages, I will be more than happy to propose that when code 131 is included, the RRP contains no MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a better suggestion that does not break current implementations, and does not produce a new mip4 protocol, I don't think we have a choice here. =09 =09 =09 > Kent >=20 > > -----Original Message----- > > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > > Sent: Wednesday, June 21, 2006 1:43 PM > > To: Kent Leung (kleung) > > Cc: Mobile IPv4 Mailing List > > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator fails > > > > Hi Kent, > > > > on 2006-06-21 19:13 Kent Leung (kleung) said the following: > > > If there is no SA, then I don't think HA should send a RRP. > > > > Maybe, but it leaves the MN and user with less information > > than it/he could have. I think that the best would be if we > > could find a standard way of handling this situation. > > > > Fwiw, this has come up before, we discussed how to handle > > this at ipUnplugged some time ago - it's a real situation > > when you're setting up and deploying a network. > > > > Regards, > > > > Henrik > > > > > Kent > > > > > >> -----Original Message----- > > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] > > >> Sent: Wednesday, June 21, 2006 10:05 AM > > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 Mailing List > > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> fails > > >> > > >> Kent/Avi, > > >> > > >> The current text does not say that the HA cannot send RRP > > when auth > > >> fails. Rather it says that the HA "SHOULD" send RRP back to the MN: > > >> > > >> > if the Authenticator is invalid, the home agent MUST reject the > > >> > mobile node's registration and SHOULD send a > > Registration Reply to > > >> > the mobile node with Code 131" > > >> > > >> What we need is a proper description of the HA and the MN > > behaviors > > >> when the auth fails and the HA needs to send a RRP to stop the MN > > >> from re-trying unnecessarily. > > >> > > >> The clarification could be: > > >> > > >> If the Authenticator is invalid, the home agent MUST reject the > > >> mobile node's registration and SHOULD send a Registration Reply to > > >> the mobile node with Code 131. In this case, the HA populates the > > >> MN-HA AE with all 0s. Upon receiving the RRP with error > > code 131, the > > >> MN skips MN-HA AE validation and stops retrying registration > > >> attempts. The MN MAY log this event in its internal log. > > >> > > >> What do you think? > > >> > > >> -Kuntal > > >> > > >> > -----Original Message----- > > >> > From: Kent Leung (kleung) [mailto:kleung@cisco.com] > > >> > Sent: Wednesday, June 21, 2006 11:43 AM > > >> > To: Avi Lior; Mobile IPv4 Mailing List > > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > fails > > >> > > > >> > Hi Avi. My understanding is that in this case, the HA > > will not be > > >> > able to send an RRP if it does not have an SA with the > > MN because > > >> > this message requires MN-HA AE. The text state that if HA has > > >> an SA, then > > >> to > > >> > use that in the RRP. Without an SA, the HA should drop > > the RRQ, IMHO. > > >> > > > >> > Kent > > >> > > > >> > > -----Original Message----- > > >> > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > >> > > Sent: Wednesday, June 21, 2006 8:13 AM > > >> > > To: Mobile IPv4 Mailing List > > >> > > Subject: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > >> > > fails > > >> > > > > >> > > Hi, > > >> > > > > >> > > While working a scenario in WiMAX I have run into some > > ambiguity > > >> > > in RFC3344. > > >> > > > > >> > > The HA receives a Reg Request with MN-HA-AE and NAI extension > > >> > > which it fails to authenticate. In particular the HA cant > > >> > > authenticate because it can't obtain the MN-HA from > > the AAA using the NAI. > > >> > > > > >> > > >From section 3.8.2.1 RFC3344 states that a Registration > > >> > > Reply should be > > >> > > sent with code 131. > > >> > > > > >> > > "if the Authenticator is invalid, the home agent MUST > > reject the > > >> > > mobile node's registration and SHOULD send a > > Registration Reply > > >> > > to the mobile node with Code 131" > > >> > > > > >> > > And from section 3.6.2.1 describing the MN behavior we have: > > >> > > > > >> > > "If the Code field indicates an authentication failure, > > >> > > either at the > > >> > > foreign agent or the home agent, then it is quite > > possible that any > > >> > > authenticators in the Registration Reply will also > > be in error. > > >> > > This > > >> > > could happen, for example, if the shared secret > > between the mobile > > >> > > node and home agent was erroneously configured. > > The mobile node > > >> > > SHOULD log such errors as security exceptions." > > >> > > > > >> > > RFC3344 also states that Registration Reply MUST > > include a MN-HA > > >> > > authentication extension: > > >> > > > > >> > > Section 3.8.3.3 says " Note that items (a) and (c) > > MUST appear > > >> > > in every Registration Reply sent by the home agent." > > >> > > > > >> > > where (c) is The Mobile-Home Authentication Extension. > > >> > > > > >> > > The problem is that when MN-HA-AE fails at the HA > > there isnt an > > >> > > available MN-HA authentication extension to use. So > > how can one > > >> > > send a registration reply? > > >> > > > > >> > > Furthermore, if the HA cant not obtain an MN-HA for > > the mobile, > > >> > > what should happen? > > >> > > > > >> > > > > >> > > Any help will be appreciated. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= > > >> > > > > >> > > Avi Lior > > >> > > Bridgewater Systems Corporation > > >> > > Phone : +1 (613) 591-9104 x6417 > > >> > > Cell : +1 (613) 796-4183 > > >> > > E-mail : mailto:avi@bridgewatersystems.com > > >> > > > > >> > > www.bridgewatersystems.com > > >> > > > > >> > > > > >> > > -- > > >> > > Mip4 mailing list: Mip4@ietf.org > > >> > > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > > Charter page: > > >> > > http://www.ietf.org/html.charters/mip4-charter.html > > >> > > Supplemental site: http://www.mip4.org/ > > >> > > > > >> > > > >> > -- > > >> > Mip4 mailing list: Mip4@ietf.org > > >> > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > > >> > Charter page: > > >> > http://www.ietf.org/html.charters/mip4-charter.html > > >> > Supplemental site: http://www.mip4.org/ > > >> > > >> > > >> "This email message and any attachments are confidential > > information > > >> of Starent Networks, Corp. The information transmitted may not be > > >> used to create or change any contractual obligations of Starent > > >> Networks, Corp. Any review, retransmission, dissemination > > or other > > >> use of, or taking of any action in reliance upon this > > e-mail and its > > >> attachments by persons or entities other than the intended > > recipient > > >> is prohibited. If you are not the intended recipient, > > please notify > > >> the sender immediately -- by replying to this message or > > by sending > > >> an email to postmaster@starentnetworks.com -- and destroy > > all copies > > >> of this message and any attachments without reading or disclosing > > >> their contents. Thank you." > > >> > > > > > > > >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ =09 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ =20 ------_=_NextPart_001_01C69653.2C977CCC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Avi,

 

If a rogue MN can break into the = network (i.e. pass access auth), anything is possible. However, by putting multiple = levels of auth (at least 1 or 2); the operators make this possibility extremely = slim. So, let’s not get hung-up with the fact that rouge MNs can do bad = things.

 

The issue is simple: if the auth of = a RRQ fails, should the HA respond back to the MN? There are some people who believe = a response should be sent. There are some who believe that the HA should = silently discard the packet.

 

In this context, the current mip4 = protocol allows the HA to send a response upon auth failure. The current text = also allows those HA implementations which like to silently discard the = packet. So, let’s not change the protocol as it allows both the = behaviors/implementations. We can just clarify some text to describe how the response packet is = formatted.

 

-Kuntal

=

 

 

From: Avi = Lior [mailto:avi@bridgewatersystems.com]
Sent: Thursday, June 22, = 2006 4:31 PM
To: Chowdhury, Kuntal; = Behcet Sarikaya; Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: RE: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

 

A rogue mobile can gain network = access and then send bogus MIP Reg Request totally masquerading the UDP = packet. Only specialized consideration in the access network can thwart that = attack, otherwise the bogus MIP Reg Request is off to the = HA. 

 

As well, compromise of a network = element in the Access Network could also send MIP Reg Request especially if = Proxy MIP is being used.

=

 

From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
Sent: Thursday, June 22, = 2006 2:53 PM
To: Behcet Sarikaya; Kent = Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: RE: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

Yep…same case for other = access technologies as well.  That means, rogue mobiles sending bogus RRQ = packets to the HA is extremely slim.

 

-Kuntal

=

 

 

From: = Behcet Sarikaya [mailto:behcetsarikaya@yahoo.com]
Sent: Thursday, June 22, = 2006 1:06 PM
To: Chowdhury, Kuntal; = Kent Leung (kleung)
Cc: Mobile IPv4 Mailing List; Henrik Levkowetz
Subject: Re: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

 

Hi Kuntal
  In WiMAX, if MS fails EAP authentication, it is out, it cannot = even send an RREQ.

Regards,

Behcet

----- Original = Message ----
From: "Chowdhury, Kuntal" = <kchowdhury@starentnetworks.com>
To: Kent Leung (kleung) <kleung@cisco.com>
Cc: Mobile IPv4 Mailing List <mip4@ietf.org>; Henrik Levkowetz <henrik@levkowetz.com>
Sent: Thursday, June 22, 2006 10:48:03 AM
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator = fails



> -----Original Message-----
> From: Kent Leung (kleung) [mailto:kleung@cisco.com]
> Sent: Thursday, June 22, 2006 1:43 AM
> To: Henrik Levkowetz
> Cc: Mobile IPv4 Mailing List
> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the = Authenticator
fails
>
> Hi Henrik.  I think the protocol can already handle authentication
> failures sufficiently.
>
> It's possible for MN to have multiple security contexts (indexed = by
> different SPIs) with the HA.  One could be used for = registration and
the
> other for authenticating RRP with error code 131.  So I = believe RFC
3344
> provides the mechanism already.  As long as HA has an SA = that can be
> used to protect the RRP with the MN-HA AE, it can inform the MN = such
> event happened in a secure manner.
>
> I think mucking with the MN-HA AE is not good.  This can = create the
> situation when MN sends a valid RRQ, and MITM can send a RRP = with
error
> code 131 and invalid MN-HA AE to the MN = immediately.  When the RRP is
> received, the MN will stop retrying.  It's possible that = the RRQ was
> lost in transit to the HA.  And even if the valid RRP = arrives later,
MN
> may not be able to associate with the any pending RRQ, which = could
have
> been possibly removed since an associated RRP had been received
already.
>
[KC>] If the HA does not send RRP back to the MN, as you = initially
suggested, the MN will keep retrying. That is not good either.

Look at other protocols. For example EAP, if auth fails, the
authenticator MUST send back a failure packet to the peer. Same case = for
other protocols over UNI. So, I am wondering why the paranoids are = not
concerned about MiTM and DoS attacks in general!

Regarding your comment "mucking with the MN-HA AE is not = good", if MN-HA
AE is not absolutely necessary in the RRP messages, I will be more = than
happy to propose that when code 131 is included, the RRP contains no
MN-HA AE. However, MN-HA AE is a MUST in RRP. So, unless you have a
better suggestion that does not break current implementations, and = does
not produce a new mip4 protocol, I don't think we have a choice = here.



> Kent
>
> > -----Original Message-----
> > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> > Sent: Wednesday, June 21, 2006 1:43 PM
> > To: Kent Leung (kleung)
> > Cc: Mobile IPv4 Mailing = List
> > Subject: Re: [Mip4] 3344 Sending a Reg Reply when the
> > Authenticator fails
> >
> > Hi Kent,
> >
> > on 2006-06-21 19:13 Kent Leung (kleung) said the = following:
> > > If there is no SA, then I don't think HA should send a = RRP.
> >
> > Maybe, but it leaves the MN and user with less information
> > than it/he could have.  I think that the best would = be if we
> > could find a standard way of handling this situation.
> >
> > Fwiw, this has come up before, we discussed how to handle
> > this at ipUnplugged some time ago - it's a real situation
> > when you're setting up and deploying a network.
> >
> > Regards,
> >
> >     Henrik
> >
> > > Kent
> > >
> > >> -----Original Message-----
> > >> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
> > >> Sent: Wednesday, June 21, 2006 10:05 AM
> > >> To: Kent Leung (kleung); Avi Lior; Mobile IPv4 = Mailing List
> > >> Subject: RE: [Mip4] 3344 Sending a Reg Reply when = the
> > Authenticator
> > >> fails
> > >>
> > >> Kent/Avi,
> > >>
> > >> The current text does not say that the HA cannot send = RRP
> > when auth
> > >> fails. Rather it says that the HA "SHOULD" = send RRP back to the
MN:
> > >>
> > >> > if the Authenticator is invalid, the home agent = MUST reject
the
> > >> > mobile node's registration and SHOULD send a
> > Registration Reply to
> > >> > the mobile node with Code 131"
> > >>
> > >> What we need is a proper description of the HA and = the MN
> > behaviors
> > >> when the auth fails and the HA needs to send a RRP to = stop the MN
> > >> from re-trying unnecessarily.
> > >>
> > >> The clarification could be:
> > >>
> > >> If the Authenticator is invalid, the home agent MUST = reject the
> > >> mobile node's registration and SHOULD send a = Registration Reply
to
> > >> the mobile node with Code 131. In this case, the HA populates the
> > >> MN-HA AE with all 0s. Upon receiving the RRP with = error
> > code 131, the
> > >> MN skips MN-HA AE validation and stops retrying = registration
> > >> attempts. The MN MAY log this event in its internal = log.
> > >>
> > >> What do you think?
> > >>
> > >> -Kuntal
> > >>
> > >> > -----Original Message-----
> > >> > From: Kent Leung (kleung) = [mailto:kleung@cisco.com]
> > >> > Sent: Wednesday, June 21, 2006 11:43 AM
> > >> > To: Avi Lior; Mobile IPv4 Mailing List
> > >> > Subject: RE: [Mip4] 3344 Sending a Reg Reply = when the
> > Authenticator
> > >> > fails
> > >> >
> > >> > Hi Avi.  My understanding is that in = this case, the HA
> > will not be
> > >> > able to send an RRP if it does not have an SA = with the
> > MN because
> > >> > this message requires MN-HA AE.  The = text state that if HA has
> > >> an SA, then
> > >> to
> > >> > use that in the RRP.  Without an SA, = the HA should drop
> > the  RRQ, IMHO.
> > >> >
> > >> > Kent
> > >> >
> > >> > > -----Original Message-----
> > >> > > From: Avi Lior = [mailto:avi@bridgewatersystems.com]
> > >> > > Sent: Wednesday, June 21, 2006 8:13 AM
> > >> > > To: Mobile IPv4 Mailing List
> > >> > > Subject: [Mip4] 3344 Sending a Reg Reply = when the
> > Authenticator
> > >> > > fails
> > >> > >
> > >> > > Hi,
> > >> > >
> > >> > > While working a scenario in WiMAX I have = run into some
> >  ambiguity
> > >> > > in RFC3344.
> > >> > >
> > >> > > The HA receives a Reg Request with MN-HA-AE = and NAI
extension
> > >> > > which it fails to = authenticate.  In particular the HA cant
> > >> > > authenticate because it can't obtain the = MN-HA from
> > the AAA using the NAI.
> > >> > >
> > >> > > >From section 3.8.2.1 RFC3344 states = that a Registration
> > >> > > Reply should be
> > >> > > sent with code 131.
> > >> > >
> > >> > > "if the Authenticator is invalid, the = home agent MUST
> > reject the
> > >> > > mobile node's registration and SHOULD send = a
> > Registration  Reply
> > >> > > to the mobile node with Code 131"
> > >> > >
> > >> > > And from section 3.6.2.1 describing the MN behavior we have:
> > >> > >
> > >> > >    "If the Code = field indicates an authentication  failure,
> > >> > > either at the
> > >> > >    foreign agent or the = home agent, then it is quite
> > possible that any
> > >> > >    authenticators in = the Registration Reply will also
> > be  in error.
> > >> > > This
> > >> > >    could happen, for = example, if the shared secret
> > between the mobile
> > >> > >    node and home agent = was erroneously configured.
> > The  mobile node
> > >> > >    SHOULD log such = errors as security exceptions."
> > >> > >
> > >> > > RFC3344 also states that Registration Reply = MUST
> > include a MN-HA
> > >> > > authentication extension:
> > >> > >
> > >> > > Section 3.8.3.3 says  " Note = that items (a) and (c)
> > MUST  appear
> > >> > > in every Registration Reply sent by the = home agent."
> > >> > >
> > >> > > where  (c) is  The = Mobile-Home Authentication Extension.
> > >> > >
> > >> > > The problem is that when MN-HA-AE fails at = the HA
> > there isnt an
> > >> > > available MN-HA authentication extension to use.  So
> > how can one
> > >> > > send a registration reply?
> > >> > >
> > >> > > Furthermore, if the HA cant not obtain an = MN-HA for
> > the  mobile,
> > >> > > what should happen?
> > >> > >
> > >> > >
> > >> > > Any help will be appreciated.
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > >
> > >> > > = =3D3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> > >> > >
> > >> > > Avi Lior
> > >> > > Bridgewater Systems Corporation
> > >> > > Phone :  +1 (613) 591-9104 = x6417
> > >> > > Cell    :  +1 = (613) 796-4183
> > >> > > E-mail : = mailto:avi@bridgewatersystems.com
> > >> > > = <mailto:avi@bridgewatersystems.com>
> > >> > > www.bridgewatersystems.com
<http://www.bridgewatersystems.com/>
> > >> > >
> > >> > >
> > >> > > --
> > >> > > Mip4 mailing list: Mip4@ietf.org
> > >> > >     Web interface:
https://www1.ietf.org/mailman/listinfo/mip4
> > >> > >      Charter = page:
> > >> > > http://www.ietf.org/html.charters/mip4-charter.html=
> > >> > > Supplemental site: http://www.mip4.org/
> > >> > >
> > >> >
> > >> > --
> > >> > Mip4 mailing list: Mip4@ietf.org
> > >> >     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
> > >> >      Charter = page:
> > >> > http://www.ietf.org/html.charters/mip4-charter.html=
> > >> > Supplemental site: http://www.mip4.org/
> > >>
> > >>
> > >> "This email message and any attachments are confidential
> > information
> > >> of Starent Networks, Corp. The information = transmitted may not be
> > >> used to create or change any contractual obligations = of Starent
> > >> Networks, Corp.  Any review, = retransmission, dissemination
> > or other
> > >> use of, or taking of any action in reliance upon = this
> > e-mail and its
> > >> attachments by persons or entities other than the = intended
> > recipient
> > >> is prohibited. If you are not the intended = recipient,
> > please notify
> > >> the sender immediately -- by replying to this message = or
> > by sending
> > >> an email to postmaster@starentnetworks.com -- and = destroy
> > all copies
> > >> of this message and any attachments without reading = or disclosing
> > >> their contents. Thank you."
> > >>
> > >
> >
> >
>
> --
> Mip4 mailing list: Mip4@ietf.org
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html=
> Supplemental site: http://www.mip4.org/

--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html=
Supplemental site: http://www.mip4.org/

 

------_=_NextPart_001_01C69653.2C977CCC-- --===============0420235563== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0420235563==-- From mip4-bounces@ietf.org Thu Jun 22 21:15:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtaGj-0006eB-Ad; Thu, 22 Jun 2006 21:15:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtaGh-0006cu-7A for mip4@ietf.org; Thu, 22 Jun 2006 21:15:31 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtaGf-00060r-OO for mip4@ietf.org; Thu, 22 Jun 2006 21:15:31 -0400 Received: from wei.isi.edu (wei.isi.edu [128.9.160.23]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5N1Edp00428 for ; Thu, 22 Jun 2006 18:14:39 -0700 (PDT) From: Wei Ye To: mip4@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Thu, 22 Jun 2006 18:14:33 -0700 Message-Id: <1151025274.3070.54.camel@wei.isi.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: weiye@isi.edu Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by boreas.isi.edu id k5N1Edp00428 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [Mip4] CFP: ACM Workshop on Underwater Networks (WUWNet 2006) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Our Apologies if you have received multiple copies of the CFP. Volkan Rodoplu and Wei Ye WUWNet 2006 Publicity Co-Chairs ----------------------------------------------------- The First ACM International Workshop on UnderWater Networks (WUWNet 2006) http://wuwnet.engr.uconn.edu/ In conjunction with ACM MobiCom 2006 September 25, 2006 Los Angeles, California, USA Sponsored by ACM SIGMOBILE Technical Co-Sponsorship: IEEE Oceanographic Engineering Society Financial Support Pending From: MIT SeaGrant, Boeing, DARPA ----------------------------------------------------- Important Dates *************** Submission deadline: June 30, 2006 Acceptance notification: July 28, 2006 Camera-ready version: August 11, 2006 Workshop date: September 25, 2006 Overview & Scope **************** The oceans cover 71% of the earth's surface and represent one of the least explored frontiers, yet the oceans are integral to climate regulation, nutrient production, oil retrieval and transportation. As such, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military reasons. While there is a need for highly precise, real-time, fine grained spatio-temporal sampling of the ocean environment, current methods such as remote telemetry and sequential local sensing cannot satisfy current needs, let alone future needs. The notion of an underwater network is relatively new due to the lack of maturity of underwater acoustic communication. However, networks are necessary in order to achieve the monitoring goals noted above. The physical challenges of acoustic underwater communication require us to completely re-think how a network should be designed and deployed in this environment. Challenges to be overcome by underwater acoustic modem and network designers include: severely limited range-dependent bandwidth and attenuation, extensive time-varying multipath propagation, and low speed of sound propagation in water resulting in long propagation delays. Moreover, a unique feature of underwater networks is that the environment is constantly mobile, naturally causing the node passive mobility. All the above distinct features of underwater networks yield new challenges for every level of the network protocol suite. The goal of the proposed workshop is to bring together researchers and practioners in areas relevant to underwater networks. Thus, many layers of the "stack" from the physical layer to the application layer will be represented. The objective is to serve as a forum for presenting state of the art research, exchanging ideas and experiences, and facilitating interaction and collaboration. The workshop will span one day, including presentations of technical papers, tutorial/survey papers, a panel session and a poster/demo session. Submissions for regular technical papers and poster/demo extended abstracts should describe original research, not published or currently under review for other workshops, conferences, or journals. Topics of interest include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Power management - Data storage and management - Localization and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Capacity analysis - New techniques for aquatic applications - New applications for underwater networks Submission Guidelines ********************* All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 8 pages for regular papers (10 pages for tutorial/survey papers and 4 pages for poster/demo papers), and must follow ACM single-space, double-column format, 10 pt. Submitted papers will be judged based on their quality and novelty through a rigorous review process. Over-length papers will be automatically rejected. Detailed instructions for paper submission are posted on the workshop website. Organizing Committee ******************** General Co-chairs: Jun-Hong Cui (University of Connecticut) Urbashi Mitra (University of Southern California) Technical Program Co-chairs: Kevin Fall (Intel Research, Berkeley) Milica Stojanovic (MIT/WHOI) Publicity Co-chairs: Volkan Rodoplu (University of California, Santa Barbara) Wei Ye (USC/ISI) Treasurer: Shengli Zhou (University of Connecticut) Publications Chair: Xiuzhen Cheng (George Washington University) Technical Program Committee *************************** Ian Akyildiz (Georgia Institute of Technology) Lee Freitag (Woods Hole Oceanographic Institution) Mario Gerla (University of California, Los Angeles) Jo=C3=A3o Pedro Gomes (Instituto Superior T=C3=A9cnico, Portugal) John Heidemann (USC/ISI) Ronald A. Iltis (University of California, Santa Barbara) Jim Kurose (University of Massachusetts, Amherst) Mehul Motani (National University of Singapore) Joseph A. Rice (Naval Postgraduate School) Daniela Rus (Massachusetts Institute of Technology) Mani Srivastava (University of California, Los Angeles) Yongguang Zhang (Microsoft Research Asia, China) Michele Zorzi (Universita'di Ferrara, Italy) -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 23 03:19:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftfx1-0008Tp-IY; Fri, 23 Jun 2006 03:19:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftfx0-0008Na-2M for mip4@ietf.org; Fri, 23 Jun 2006 03:19:34 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftfwx-00074p-Lh for mip4@ietf.org; Fri, 23 Jun 2006 03:19:34 -0400 Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 23 Jun 2006 13:14:02 -0700 X-IronPort-AV: i="4.06,168,1149490800"; d="scan'208,217"; a="69660519:sNHT61126640" Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5N7Itql021547; Fri, 23 Jun 2006 07:19:25 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 23 Jun 2006 12:49:13 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Fri, 23 Jun 2006 12:49:12 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQ From: "Venkateshwara Sastry \(vsastry\)" To: "Chowdhury, Kuntal" , "Avi Lior" X-OriginalArrivalTime: 23 Jun 2006 07:19:13.0938 (UTC) FILETIME=[548BCF20:01C69695] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1431458974==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1431458974== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69695.5463D1CC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69695.5463D1CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We can not really claim that current protocol allows HA to respond on auth failure. If HA responding on auth failure was really the intention of the designers, silently discarding such packets by MN as indicated in following text does not make sense. b) If the Code field indicates that service is denied by the home agent, or if the Code field indicates that the registration was accepted by the home agent, exactly one Mobile-Home Authentication Extension MUST be present in the Registration Reply, and the mobile node MUST check the Authenticator value in the Extension. If the Registration Reply was generated by the home agent but no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Reply and SHOULD log the event as a security exception. Regards Sastry ________________________________ From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Friday, June 23, 2006 4:56 AM To: Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =09 =09 Avi, =20 If a rogue MN can break into the network (i.e. pass access auth), anything is possible. However, by putting multiple levels of auth (at least 1 or 2); the operators make this possibility extremely slim. So, let's not get hung-up with the fact that rouge MNs can do bad things. =20 The issue is simple: if the auth of a RRQ fails, should the HA respond back to the MN? There are some people who believe a response should be sent. There are some who believe that the HA should silently discard the packet. =20 In this context, the current mip4 protocol allows the HA to send a response upon auth failure. The current text also allows those HA implementations which like to silently discard the packet. So, let's not change the protocol as it allows both the behaviors/implementations. We can just clarify some text to describe how the response packet is formatted. =20 -Kuntal =20 ------_=_NextPart_001_01C69695.5463D1CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
We can not really = claim that=20 current protocol allows HA to respond on auth failure. If HA responding = on auth=20 failure was really the intention of the designers, silently discarding = such=20 packets by MN as indicated in following text does not make sense.
    =
  b) If the Code field indicates that service is denied by the home
         agent, or if the Code field indicates that the registration was
         accepted by the home agent, exactly one Mobile-Home
         Authentication Extension MUST be present in the Registration
         Reply, and the mobile node MUST check the Authenticator value
         in the Extension.  If the Registration Reply was generated by
         the home agent but no Mobile-Home Authentication Extension is
         found, or if more than one Mobile-Home Authentication Extension
         is found, or if the Authenticator is invalid, the mobile node
         MUST silently discard the Reply and SHOULD log the event as a
         security exception.
Regards
Sastry
=

From: Chowdhury, Kuntal=20 [mailto:kchowdhury@starentnetworks.com]
Sent: Friday, June = 23, 2006=20 4:56 AM
To: Avi Lior
Cc: Mobile IPv4 Mailing=20 List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 Authenticator fails

Avi,

 

If a rogue = MN can=20 break into the network (i.e. pass access auth), anything is possible. = However,=20 by putting multiple levels of auth (at least 1 or 2); the operators = make this=20 possibility extremely slim. So, let’s not get hung-up with the = fact that rouge=20 MNs can do bad things.

 

The issue = is simple:=20 if the auth of a RRQ fails, should the HA respond back to the MN? = There are=20 some people who believe a response should be sent. There are some who = believe=20 that the HA should silently discard the = packet.

 

In this = context, the=20 current mip4 protocol allows the HA to send a response upon auth = failure. The=20 current text also allows those HA implementations which like to = silently=20 discard the packet. So, let’s not change the protocol as it = allows both the=20 behaviors/implementations. We can just clarify some text to describe = how the=20 response packet is formatted.

 

-Kuntal

 

------_=_NextPart_001_01C69695.5463D1CC-- --===============1431458974== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1431458974==-- From mip4-bounces@ietf.org Fri Jun 23 03:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftg1E-0004KM-IB; Fri, 23 Jun 2006 03:23:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftg1C-0004KH-Fv for mip4@ietf.org; Fri, 23 Jun 2006 03:23:54 -0400 Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftg1B-0007Kn-7R for mip4@ietf.org; Fri, 23 Jun 2006 03:23:54 -0400 Received: by wr-out-0506.google.com with SMTP id i30so554003wra for ; Fri, 23 Jun 2006 00:23:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EECKTRMOzWHbW0ToQUHFQkRagKTyKODAzyRjtdGZENjkQGGC0+NZkebCKFXqYS3xkFaPyxqvyadt+4sLl04+kkrdWAlXZozLYkfPX9E+CrnsIWqdyHZQqXEwI6KVpFrnYgo4zZNlRJZ+hSeGmSFO2oGOkDBghq+WBeF7eSgub3I= Received: by 10.54.134.12 with SMTP id h12mr4221482wrd; Fri, 23 Jun 2006 00:23:52 -0700 (PDT) Received: by 10.54.118.8 with HTTP; Fri, 23 Jun 2006 00:23:52 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 15:23:52 +0800 From: Owen.Lai To: mip4@ietf.org, kleung@cisco.com In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [Mip4] Fwd: I-D ACTION:draft-lai-mip4-proxy-sequence-problem-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0888458878==" Errors-To: mip4-bounces@ietf.org --===============0888458878== Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGkgZm9sa3MsCgpXZSd2ZSBwdWJsaXNoZWQgYSBuZXcgZHJhZnQsICJQcm9ibGVtIG9mIFJlcGxh eSBQcm90ZWN0aW9uIFVzaW5nClNlcXVlbmNlIE51bWJlciBpbiBQcm94eSBNb2JpbGUgSVB2NCIu CgpUaGUgZG9jdW1lbnQgcHJlc2VudHMgdGhlIHByb2JsZW1zIG9mIHJlcGxheSBwcm90ZWN0aW9u IHVzaW5nIHNlcXVlbmNlCm51bWJlciBpbiBwcm94eSBNb2JpbGUgSVB2NCBzb2x1dGlvbi4gIFRo ZSBzZXF1ZW5jZSBudW1iZXIgY2Fubm90CnByZXZlbnQgcmVnaXN0cmF0aW9uIG1lc3NhZ2UgZnJv bSByZXBsYXkgYXR0YWNrLgoKQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLgoKVGhhbmtzLApTaG91 d2VuLAoKLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0tCkZyb206IEludGVy bmV0LURyYWZ0c0BpZXRmLm9yZyA8SW50ZXJuZXQtRHJhZnRzQGlldGYub3JnPgpEYXRlOiAyMDA2 LTYtMjMgyc/O5zY6NTAKU3ViamVjdDogSS1EIEFDVElPTjpkcmFmdC1sYWktbWlwNC1wcm94eS1z ZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dApUbzogaS1kLWFubm91bmNlQGlldGYub3JnCgoKQSBOZXcg SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh ZnRzIGRpcmVjdG9yaWVzLgoKCiAgICAgICBUaXRsZSAgICAgICAgICAgOiBQcm9ibGVtIG9mIFJl cGxheSBQcm90ZWN0aW9uIFVzaW5nIFNlcXVlbmNlCk51bWJlciBpbiBQcm94eSBNb2JpbGUgSVB2 NAogICAgICAgQXV0aG9yKHMpICAgICAgIDogUy4gTGFpLCBILiBEZW5nCiAgICAgICBGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1sYWktbWlwNC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dAog ICAgICAgUGFnZXMgICAgICAgICAgIDogNwogICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAwNi02 LTIyCgogIFRoZSBkb2N1bWVudCBwcmVzZW50cyB0aGUgcHJvYmxlbXMgb2YgcmVwbGF5IHByb3Rl Y3Rpb24gdXNpbmcKICBzZXF1ZW5jZSBudW1iZXIgaW4gcHJveHkgTW9iaWxlIElQdjQgc29sdXRp b24uICBUaGUgc2VxdWVuY2UgbnVtYmVyCiAgY2Fubm90IHByZXZlbnQgcmVnaXN0cmF0aW9uIG1l c3NhZ2UgZnJvbSByZXBsYXkgYXR0YWNrLgoKCkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0 IGlzOgpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sYWktbWlwNC1w cm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dAoKVG8gcmVtb3ZlIHlvdXJzZWxmIGZyb20gdGhl IEktRCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhIG1lc3NhZ2UgdG8KaS1kLWFubm91bmNlLXJl cXVlc3RAaWV0Zi5vcmcgd2l0aCB0aGUgd29yZCB1bnN1YnNjcmliZSBpbiB0aGUgYm9keSBvZgp0 aGUgbWVzc2FnZS4KWW91IGNhbiBhbHNvIHZpc2l0IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZQp0byBjaGFuZ2UgeW91ciBzdWJzY3JpcHRpb24gc2V0 dGluZ3MuCgoKSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMg RlRQLiBMb2dpbiB3aXRoIHRoZSB1c2VybmFtZQoiYW5vbnltb3VzIiBhbmQgYSBwYXNzd29yZCBv ZiB5b3VyIGUtbWFpbCBhZGRyZXNzLiBBZnRlciBsb2dnaW5nIGluLAp0eXBlICJjZCBpbnRlcm5l dC1kcmFmdHMiIGFuZCB0aGVuCiAgICAgICAiZ2V0IGRyYWZ0LWxhaS1taXA0LXByb3h5LXNlcXVl bmNlLXByb2JsZW0tMDAudHh0Ii4KCkEgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMgY2FuIGJlIGZvdW5kIGluCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRw Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCgpJbnRlcm5ldC1EcmFmdHMg Y2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLgoKU2VuZCBhIG1lc3NhZ2UgdG86CiAgICAg ICBtYWlsc2VydkBpZXRmLm9yZy4KSW4gdGhlIGJvZHkgdHlwZToKICAgICAgICJGSUxFIC9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtbGFpLW1pcDQtcHJveHktc2VxdWVuY2UtcHJvYmxlbS0wMC50eHQi LgoKTk9URTogICBUaGUgbWFpbCBzZXJ2ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0aGUgZG9j dW1lbnQgaW4KICAgICAgIE1JTUUtZW5jb2RlZCBmb3JtIGJ5IHVzaW5nIHRoZSAibXBhY2siIHV0 aWxpdHkuICBUbyB1c2UgdGhpcwogICAgICAgZmVhdHVyZSwgaW5zZXJ0IHRoZSBjb21tYW5kICJF TkNPRElORyBtaW1lIiBiZWZvcmUgdGhlICJGSUxFIgogICAgICAgY29tbWFuZC4gIFRvIGRlY29k ZSB0aGUgcmVzcG9uc2UocyksIHlvdSB3aWxsIG5lZWQgIm11bnBhY2siIG9yCiAgICAgICBhIE1J TUUtY29tcGxpYW50IG1haWwgcmVhZGVyLiAgRGlmZmVyZW50IE1JTUUtY29tcGxpYW50IG1haWwg cmVhZGVycwogICAgICAgZXhoaWJpdCBkaWZmZXJlbnQgYmVoYXZpb3IsIGVzcGVjaWFsbHkgd2hl biBkZWFsaW5nIHdpdGgKICAgICAgICJtdWx0aXBhcnQiIE1JTUUgbWVzc2FnZXMgKGkuZS4gZG9j dW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBzcGxpdAogICAgICAgdXAgaW50byBtdWx0aXBsZSBtZXNz YWdlcyksIHNvIGNoZWNrIHlvdXIgbG9jYWwgZG9jdW1lbnRhdGlvbiBvbgogICAgICAgaG93IHRv IG1hbmlwdWxhdGUgdGhlc2UgbWVzc2FnZXMuCgoKQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2ls bCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcgppbXBsZW1lbnRhdGlvbiB0byBh dXRvbWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQpJbnRlcm5ldC1E cmFmdC4KCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f CkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QKSS1ELUFubm91bmNlQGlldGYub3JnCmh0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQo= --===============0888458878== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0888458878==-- From mip4-bounces@ietf.org Fri Jun 23 05:25:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fthum-0006sB-M6; Fri, 23 Jun 2006 05:25:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fthum-0006s6-3D for mip4@ietf.org; Fri, 23 Jun 2006 05:25:24 -0400 Received: from wr-out-0506.google.com ([64.233.184.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fthuk-0005ip-RI for mip4@ietf.org; Fri, 23 Jun 2006 05:25:24 -0400 Received: by wr-out-0506.google.com with SMTP id i32so558122wra for ; Fri, 23 Jun 2006 02:25:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NCMCwrIVk6Hs/Vx3k4phP6joLU3uoJSDNQoI+ELSEEe3lzdIKRGcf+p0qcJ3z2yw9UuGgx33WnxMQjYbKT3XREJPkzWlga7FGW5wKe9pmQEpX9jCeJ2UhorOa96+QNgKh55UtXbNV5I6Hzbyt4/0ysfY+3T1+zC/S7TQXxacPtI= Received: by 10.54.80.7 with SMTP id d7mr4290141wrb; Fri, 23 Jun 2006 02:25:22 -0700 (PDT) Received: by 10.54.118.8 with HTTP; Fri, 23 Jun 2006 02:25:22 -0700 (PDT) Message-ID: Date: Fri, 23 Jun 2006 17:25:22 +0800 From: Owen.Lai To: mip4@ietf.org In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA38AAFF30@hcbjdc2> MIME-Version: 1.0 References: <834B54D356AA8F46B9B233DD88BEAA38AAFF30@hcbjdc2> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Mip4] Fwd: I-D ACTION:draft-lai-mip4-proxy-nat-traversal-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1772076335==" Errors-To: mip4-bounces@ietf.org --===============1772076335== Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksYWxsOgoKV2Ugc3VibWl0dGVkIGEgbmV3IGRyYWZ0LgoKQ29tbWVudHMgYXJlIHdlbGNvbWUK ClRoYW5rcyB2ZXJ5IG11Y2gKU2hvdXdlbgoKCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCkZy b206IEludGVybmV0LURyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOkludGVybmV0LURyYWZ0c0BpZXRm Lm9yZ10KU2VudDogMjAwNi02LTIxICjQx8bayP0pIDM6NTAKVG86IGktZC1hbm5vdW5jZUBpZXRm Lm9yZwpDYzoKU3ViamVjdDogSS1EIEFDVElPTjpkcmFmdC1sYWktbWlwNC1wcm94eS1uYXQtdHJh dmVyc2FsLTAwLnR4dAoKCgpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuCgoKICAgICAgICBUaXRsZSAg ICAgICAgICAgOiBQcm94eSBNb2JpbGUgSVB2NCBUcmF2ZXJzYWwgb2YgTmV0d29yayBBZGRyZXNz CiAgICAgICAgICAgICAgICAgICAgICAgICAgVHJhbnNsYXRpb24gKE5BVCkgRGV2aWNlcwogICAg ICAgIEF1dGhvcihzKSAgICAgICA6IFMuIExhaSwgSC4gRGVuZwogICAgICAgIEZpbGVuYW1lICAg ICAgICA6IGRyYWZ0LWxhaS1taXA0LXByb3h5LW5hdC10cmF2ZXJzYWwtMDAudHh0CiAgICAgICAg UGFnZXMgICAgICAgICAgIDogMTcKICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDA2LTYtMjAK CiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgc29sdXRpb24gdG8gYWRkcmVzcyBOQVQgdHJh dmVyc2FsIHByb2JsZW0KICAgZm9yIHByb3h5IE1vYmlsZSBJUHY0LiAgQnkgb25seSB1dGlsaXpp bmcgbmV0d29yayBlbnRpdGllcywgYW4gTUlQCiAgIFVEUCBUdW5uZWwgdG8gYWNoaWV2ZSBOQVQg VHJhdmVyc2FsIGlzIGJ1aWx0IHVwIGZvciBhbiBNb2JpbGUgSVAKICAgQ2xpZW50IHdoaWNoIGV4 Y2hhbmdlcyBtZXNzYWdlcyBhbmQgZGF0YSB3aXRoIEhBIG9uIG1vYmlsZSBub2RlJ3MKICAgYmVo YWxmLgoKQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6Cmh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxhaS1taXA0LXByb3h5LW5hdC10cmF2ZXJzYWwtMDAu dHh0CgpUbyByZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91bmNlbWVudCBsaXN0LCBz ZW5kIGEgbWVzc2FnZSB0bwppLWQtYW5ub3VuY2UtcmVxdWVzdEBpZXRmLm9yZyB3aXRoIHRoZSB3 b3JkIHVuc3Vic2NyaWJlIGluIHRoZSBib2R5IG9mCnRoZSBtZXNzYWdlLgpZb3UgY2FuIGFsc28g dmlzaXQgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFubm91bmNl CnRvIGNoYW5nZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0aW5ncy4KCgpJbnRlcm5ldC1EcmFmdHMg YXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2luIHdpdGggdGhlIHVzZXJu YW1lCiJhbm9ueW1vdXMiIGFuZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFm dGVyIGxvZ2dpbmcgaW4sCnR5cGUgImNkIGludGVybmV0LWRyYWZ0cyIgYW5kIHRoZW4KICAgICAg ICAiZ2V0IGRyYWZ0LWxhaS1taXA0LXByb3h5LW5hdC10cmF2ZXJzYWwtMDAudHh0Ii4KCkEgbGlz dCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMgY2FuIGJlIGZvdW5kIGluCmh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRv dy1zaXRlcy50eHQKCgpJbnRlcm5ldC1EcmFmdHMgY2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1t YWlsLgoKU2VuZCBhIG1lc3NhZ2UgdG86CiAgICAgICAgbWFpbHNlcnZAaWV0Zi5vcmcuCkluIHRo ZSBib2R5IHR5cGU6CiAgICAgICAgIkZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sYWktbWlw NC1wcm94eS1uYXQtdHJhdmVyc2FsLTAwLnR4dCIuCgpOT1RFOiAgIFRoZSBtYWlsIHNlcnZlciBh dCBpZXRmLm9yZyBjYW4gcmV0dXJuIHRoZSBkb2N1bWVudCBpbgogICAgICAgIE1JTUUtZW5jb2Rl ZCBmb3JtIGJ5IHVzaW5nIHRoZSAibXBhY2siIHV0aWxpdHkuICBUbyB1c2UgdGhpcwogICAgICAg IGZlYXR1cmUsIGluc2VydCB0aGUgY29tbWFuZCAiRU5DT0RJTkcgbWltZSIgYmVmb3JlIHRoZSAi RklMRSIKICAgICAgICBjb21tYW5kLiAgVG8gZGVjb2RlIHRoZSByZXNwb25zZShzKSwgeW91IHdp bGwgbmVlZCAibXVucGFjayIgb3IKICAgICAgICBhIE1JTUUtY29tcGxpYW50IG1haWwgcmVhZGVy LiAgRGlmZmVyZW50IE1JTUUtY29tcGxpYW50IG1haWwgcmVhZGVycwogICAgICAgIGV4aGliaXQg ZGlmZmVyZW50IGJlaGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4gZGVhbGluZyB3aXRoCiAgICAgICAg Im11bHRpcGFydCIgTUlNRSBtZXNzYWdlcyAoaS5lLiBkb2N1bWVudHMgd2hpY2ggaGF2ZSBiZWVu IHNwbGl0CiAgICAgICAgdXAgaW50byBtdWx0aXBsZSBtZXNzYWdlcyksIHNvIGNoZWNrIHlvdXIg bG9jYWwgZG9jdW1lbnRhdGlvbiBvbgogICAgICAgIGhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1l c3NhZ2VzLgoKCkJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21w bGlhbnQgbWFpbCByZWFkZXIKaW1wbGVtZW50YXRpb24gdG8gYXV0b21hdGljYWxseSByZXRyaWV2 ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUKSW50ZXJuZXQtRHJhZnQuCg== --===============1772076335== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1772076335==-- From mip4-bounces@ietf.org Fri Jun 23 12:55:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtowT-0002tG-I9; Fri, 23 Jun 2006 12:55:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtowR-0002t9-TL for mip4@ietf.org; Fri, 23 Jun 2006 12:55:35 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtowQ-0003Qb-QE for mip4@ietf.org; Fri, 23 Jun 2006 12:55:35 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2C58890068 for ; Fri, 23 Jun 2006 12:55:31 -0400 (EDT) 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 09385-10 for ; Fri, 23 Jun 2006 12:55:30 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Fri, 23 Jun 2006 12:55:30 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 23 Jun 2006 12:52:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Fri, 23 Jun 2006 12:52:30 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C51F2@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQABPy+sA= From: "Chowdhury, Kuntal" To: "Venkateshwara Sastry (vsastry)" , "Avi Lior" X-OriginalArrivalTime: 23 Jun 2006 16:52:30.0184 (UTC) FILETIME=[6A4E6E80:01C696E5] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: f5c1164b9029aa0dd842007e530e24ad Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0267105881==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0267105881== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C696E5.6A38AD64" This is a multi-part message in MIME format. ------_=_NextPart_001_01C696E5.6A38AD64 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure we can say that the HA is allowed to send RRP on auth failure. What you cite here is talking about how the MN processes the RRP. It does not say anything about allowing or disallowing the HA to send RRP on auth failure.=20 =20 As I have been saying all along...all we need is to clarify the node behaviors better for error case handling. The current text does a poor job on describing the error handling cases.=20 =20 -Kuntal =20 ________________________________ From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]=20 Sent: Friday, June 23, 2006 2:19 AM To: Chowdhury, Kuntal; Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 We can not really claim that current protocol allows HA to respond on auth failure. If HA responding on auth failure was really the intention of the designers, silently discarding such packets by MN as indicated in following text does not make sense. b) If the Code field indicates that service is denied by the home agent, or if the Code field indicates that the registration was accepted by the home agent, exactly one Mobile-Home Authentication Extension MUST be present in the Registration Reply, and the mobile node MUST check the Authenticator value in the Extension. If the Registration Reply was generated by the home agent but no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Reply and SHOULD log the event as a security exception. Regards Sastry =20 =09 ________________________________ From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Friday, June 23, 2006 4:56 AM To: Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Avi, =20 If a rogue MN can break into the network (i.e. pass access auth), anything is possible. However, by putting multiple levels of auth (at least 1 or 2); the operators make this possibility extremely slim. So, let's not get hung-up with the fact that rouge MNs can do bad things. =20 The issue is simple: if the auth of a RRQ fails, should the HA respond back to the MN? There are some people who believe a response should be sent. There are some who believe that the HA should silently discard the packet. =20 In this context, the current mip4 protocol allows the HA to send a response upon auth failure. The current text also allows those HA implementations which like to silently discard the packet. So, let's not change the protocol as it allows both the behaviors/implementations. We can just clarify some text to describe how the response packet is formatted. =20 -Kuntal =20 ------_=_NextPart_001_01C696E5.6A38AD64 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure we can say that the HA is = allowed to send RRP on auth failure. What you cite here is talking about how the MN = processes the RRP. It does not say anything about allowing or disallowing the HA = to send RRP on auth failure.

 

As I have been saying all = along…all we need is to clarify the node behaviors better for error case handling. = The current text does a poor job on describing the error handling cases. =

 

-Kuntal

=

 

From: = Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]
Sent: Friday, June 23, = 2006 2:19 AM
To: Chowdhury, Kuntal; = Avi Lior
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

 

We can not really claim that = current protocol allows HA to respond on auth failure. If HA responding on auth = failure was really the intention of the designers, silently discarding such = packets by MN as indicated in following text does not make = sense. 

      b) If the Code field =
indicates that service is denied by the =
home
      =
;   agent, or if the Code field indicates that the =
registration was
      =
;   accepted by the home agent, exactly one =
Mobile-Home
      =
;   Authentication Extension MUST be present in the =
Registration
      =
;   Reply, and the mobile node MUST check the Authenticator =
value
      =
;   in the Extension.  If the Registration Reply was =
generated by
      =
;   the home agent but no Mobile-Home Authentication Extension =
is
      =
;   found, or if more than one Mobile-Home Authentication =
Extension
      =
;   is found, or if the Authenticator is invalid, the mobile =
node
      =
;   MUST silently discard the Reply and SHOULD log the event =
as a
      =
;   security exception.

Regards

Sastry

=

 

From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
Sent: Friday, June 23, = 2006 4:56 AM
To: Avi Lior
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

Avi,

 

If a rogue MN can break into the = network (i.e. pass access auth), anything is possible. However, by putting = multiple levels of auth (at least 1 or 2); the operators make this possibility = extremely slim. So, let’s not get hung-up with the fact that rouge MNs can = do bad things.

 

The issue is simple: if the auth of = a RRQ fails, should the HA respond back to the MN? There are some people who = believe a response should be sent. There are some who believe that the HA should silently discard the packet.

 

In this context, the current mip4 = protocol allows the HA to send a response upon auth failure. The current text = also allows those HA implementations which like to silently discard the = packet. So, let’s not change the protocol as it allows both the behaviors/implementations. We can just clarify some text to describe how = the response packet is formatted.

 

-Kuntal

=

 

------_=_NextPart_001_01C696E5.6A38AD64-- --===============0267105881== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0267105881==-- From mip4-bounces@ietf.org Sat Jun 24 11:11:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fu9nf-00061w-3H; Sat, 24 Jun 2006 11:11:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ftd6p-0007VF-MC; Fri, 23 Jun 2006 00:17:31 -0400 Received: from ms-smtp-02.nyroc.rr.com ([24.24.2.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ftd6l-0001RT-Ar; Fri, 23 Jun 2006 00:17:31 -0400 Received: from hpn307pc2 (cpe-66-67-141-103.rochester.res.rr.com [66.67.141.103]) by ms-smtp-02.nyroc.rr.com (8.13.6/8.13.6) with SMTP id k5N4HPQt025685; Fri, 23 Jun 2006 00:17:26 -0400 (EDT) Message-ID: <012201c6967b$f1113b60$6701a8c0@hpn307pc2> From: "Wendi Heinzelman" To: , Date: Fri, 23 Jun 2006 00:17:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 X-Mailman-Approved-At: Sat, 24 Jun 2006 11:11:54 -0400 Cc: Subject: [Mip4] IEEE SECON 2006 Call for Posters and Demos-- June 30 Deadline X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org (Apologies if you receive this call multiple times.) *********************************************************************** CALL FOR POSTERS and DEMOS *Deadline: June 30, 2006, 5 pm EDT* IEEE SECON 2006 The Third IEEE International Conference on Sensors, Mesh and Ad Hoc Communications and Networks http://www.ieee-secon.org/2006/ Sponsored by IEEE Communications Society (www.comsoc.org) Technically Co-Sponsored by AFCEA (www.afcea.org) September 25-28, 2006 Reston, Virginia, USA (Near Washington DC's Dulles airport) ************************************************************************ To provide a forum for discussion and personal interaction between presenter and participants, IEEE SECON 2006 will include poster and demonstration sessions: works in progress, industry demonstrations of new applications and techniques, practical implementations, military, industrial and commercial developments, research testbeds and demonstrations, recent research/implementation results, upcoming research challenges, future directions, and novel approaches in the fields of sensor, mesh and ad hoc communications and networks. One of the key goals of this conference is to foster collaboration between industry, government agencies and academia. Hence, participation of researchers/developers from industry or governement agencies and posters/demonstrations reporting joint work are especially encouraged. Topics considered for posters and demo are, but not limited to: * New architectures and protocols to support communication, localization, time synchronization, routing, data dissemination, and other distributed services in heterogeneous, large-scale distributed, mesh networks and sensor networks * Novel algorithms and theories for management, supervisory control, and monitoring of distributed ad hoc networks, and techniques for the interpretation and use of sensor data in decision-making processes * Modeling and performance evaluation of large-scale distributed ad hoc and sensor networks, practical implementations and deployments, and real-world experiences * Theories and models on fundamental information and communication aspects of wireless mesh and sensor networks * Mechanisms for authenticated, secure communication and data dissemination in sensor and mesh networks * Algorithms and protocols to support quality of service in mesh and sensor networks, including admission control, resource allocation and fairness, and capacity planning * Integration of sensors into engineered systems, including novel techniques for on-sensor renewable power sources, mechanisms for on-sensor self-calibration and self-testing, and efficient schemes to maximize accuracy and minimize false alarms * Hardware platforms incorporating multiple sensors, computation, actuation, and wireless interfaces * Software platforms, middleware, and tools for mesh and sensor network applications development, deployment, and management Submissions should be in the form of a proposal describing the main contributions of the poster/demo and the merits of the proposed ideas. If available, preliminary results can also be included. Proposals will be evaluated mainly based on their potential to stimulate interesting discussions, exchange of ideas and promote collaborations. A prize will be awarded to the best demo by a jury composed of academic and/or venture capital participants. Submissions should not be more than three pages (preferably IEEE conference format, 2-column) in length. Demonstration submissions should include the space requirements and/or any other equipment-specific requirements. The documents must contain the authors' names, affiliations, and contact information and the designated corresponding author. Accepted authors of posters/demos will have a space in the poster/demo session room to display their posters or exhibit their demos and describe their work in discussions with interested attendees. IEEE Communications Society policy states that all accepted SECON 2006 posters/demos must have at least one registration at the regular rate. For authors co-authoring multiple posters/demos, one regular registration is valid for up to three presentations. Submission will be accepted until Friday, June 30th, 5 pm EDT for demos and for posters. Please send the submission material to the poster/demo chairs in pdf format, and make sure to include the first author name and either POSTER or DEMO in the name of the pdf file: Stefano Basagni Cedric Westphal Northeastern University Nokia basagni@ece.neu.edu cedric.westphal@nokia.com Notification of Poster/Demo decisions: July 21, 2006. Accepted Poster/Demo Presenters MUST register by August 31, 2006. ************************************************************************ -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Jun 24 12:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBTH-0000EI-5x; Sat, 24 Jun 2006 12:58:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBTF-0000ED-86 for mip4@ietf.org; Sat, 24 Jun 2006 12:58:57 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuBTC-0008JL-OU for mip4@ietf.org; Sat, 24 Jun 2006 12:58:57 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 24 Jun 2006 09:58:54 -0700 X-IronPort-AV: i="4.06,172,1149490800"; d="scan'208"; a="1832034952:sNHT33358744" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k5OGws8O025377; Sat, 24 Jun 2006 09:58:54 -0700 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 k5OGwpke021209; Sat, 24 Jun 2006 09:58:51 -0700 (PDT) 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.211); Sat, 24 Jun 2006 09:58:51 -0700 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Sat, 24 Jun 2006 09:58:48 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202062ACB@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaVc1DfUCjXk4gbTvSsUTW4unIXTQAE+0mgACJTqmAAWKJsIA== From: "Kent Leung \(kleung\)" To: "Chowdhury, Kuntal" X-OriginalArrivalTime: 24 Jun 2006 16:58:51.0499 (UTC) FILETIME=[78003BB0:01C697AF] DKIM-Signature: a=rsa-sha1; q=dns; l=3605; t=1151168334; x=1152032334; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=203344=20Sending=20a=20Reg=20Reply=20when=20the=20Authent icator=20fails; X=v=3Dcisco.com=3B=20h=3DvU24gB2U8GGZdPa37Y8LTDl8E2s=3D; b=PemnuLemolAJhfPHAf6MzGQpptVONg/AzIpzNYI0X7nvB593/vfsLZ91QpMMunLfyV28lSe9 V8mymeIPvTLpB0EaCBypLNfP0ehpspoq91gffKp8IO1KTiEnelOparLt; Authentication-Results: sj-dkim-1.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Mobile IPv4 Mailing List , Henrik Levkowetz X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Kuntal. > >=20 > > I think mucking with the MN-HA AE is not good. This can create the=20 > > situation when MN sends a valid RRQ, and MITM can send a RRP with > error > > code 131 and invalid MN-HA AE to the MN immediately. When=20 > the RRP is=20 > > received, the MN will stop retrying. It's possible that=20 > the RRQ was=20 > > lost in transit to the HA. And even if the valid RRP arrives later, > MN > > may not be able to associate with the any pending RRQ, which could > have > > been possibly removed since an associated RRP had been received > already. > >=20 > [KC>] If the HA does not send RRP back to the MN, as you=20 > initially suggested, the MN will keep retrying. That is not=20 > good either. >=20 Let's not mix two issues: 1) When processing the RRP, MN discards the message if authentication fails as clearly stated in RFC. This message is _not_ processed. 2) The security exception is logged by the MN when this happens as clearly stated in RFC. There is no mention that registration retransmission stops. I believe there's good reason for the omission because such message is indeed _not_ authenticated and should not be trusted. So I believe even sending bogus authenticator in MHAE will not work well in accordance to the RFC. > Look at other protocols. For example EAP, if auth fails, the=20 > authenticator MUST send back a failure packet to the peer.=20 > Same case for other protocols over UNI. So, I am wondering=20 > why the paranoids are not concerned about MiTM and DoS=20 > attacks in general! >=20 > Regarding your comment "mucking with the MN-HA AE is not=20 > good", if MN-HA AE is not absolutely necessary in the RRP=20 > messages, I will be more than happy to propose that when code=20 > 131 is included, the RRP contains no MN-HA AE. However, MN-HA=20 > AE is a MUST in RRP. So, unless you have a better suggestion=20 > that does not break current implementations, and does not=20 > produce a new mip4 protocol, I don't think we have a choice here. >=20 >=20 My view is that the MN/HA needs the mobility security association to calculate the authenticator value used in the MHAE to be appended to the RRQ and RRP. So without any SA, the MHAE cannot be appended and therefore, RRQ/RRP cannot be sent. If there is an SA, then from MN/HA's view, that is the SA to use to protect the RRP. It's up to the administrator to decide which side has the incorrect key, not MN/HA's judgement. The security exception event is logged on both MN and HA. The SNMP trap can inform the admin to fix the problem. As for the bandwidth issue, a good backoff registration mechanism should not consume much at all before the problem is dealt with. BTW, there is no service when registration fails so it's very obvious to the end user. But logging in the network should have caught it right away. 3.6.3. Registration Retransmission=20 "Each successive retransmission timeout period SHOULD be at least twice the previous period, as long as that is less than the maximum as specified above." So, if there is a misconfiguration of SA on either MN or HA, both sides will log a security exception. If HA doesn't have an SA, then only HA log the security exception. The registration backoff mechanism on MN reduces link consumption. I think we can work in accordance to RFC by setting up an default SA between MN and HA for authentication failure case. At least, then MN know it's a legit RRP. Else, stick with the rules specified by RFC 3344 today. Kent -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Sat Jun 24 13:02:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBWa-00061V-Qs; Sat, 24 Jun 2006 13:02:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuBWa-00061Q-A2 for mip4@ietf.org; Sat, 24 Jun 2006 13:02:24 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuBWZ-000068-Da for mip4@ietf.org; Sat, 24 Jun 2006 13:02:24 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 24 Jun 2006 10:02:23 -0700 X-IronPort-AV: i="4.06,172,1149490800"; d="scan'208,217"; a="1832035745:sNHT69928028" 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 k5OH2MCk026581; Sat, 24 Jun 2006 10:02:22 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5OH2K9s000163; Sat, 24 Jun 2006 10:02:20 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 24 Jun 2006 10:02:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Sat, 24 Jun 2006 10:02:18 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202062AD4@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQABPy+sAAIiAmsA== From: "Kent Leung \(kleung\)" To: "Chowdhury, Kuntal" , "Venkateshwara Sastry \(vsastry\)" , "Avi Lior" X-OriginalArrivalTime: 24 Jun 2006 17:02:20.0107 (UTC) FILETIME=[F45749B0:01C697AF] DKIM-Signature: a=rsa-sha1; q=dns; l=24708; t=1151168542; x=1152032542; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=203344=20Sending=20a=20Reg=20Reply=20when=20the=20Authent icator=20fails; X=v=3Dcisco.com=3B=20h=3DvU24gB2U8GGZdPa37Y8LTDl8E2s=3D; b=TMOD7A1rO15W0AQWx4/YrBlULTY2en+0yy1HJwvyp/XPvvoYe8wIfnKdJXyxSfC28GbfOpgm psuKXC/yVaNQMUCd/sOy4Mfai1HWsIoHX/EPuPDX1k/I/1WVSvi4pSp7; Authentication-Results: sj-dkim-1.cisco.com; header.From=kleung@cisco.com; dkim=pass ( 59 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1263524715==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1263524715== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C697AF.F416224F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C697AF.F416224F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW, there are many places where authentication is specified as "MUST". =20 =20 1) This section says the registration messages must be authenticated between MN and HA. =20 3.2. Authentication =20 "Registration messages between a mobile node and its home agent MUST be authenticated with an authorization-enabling extension, e.g. the Mobile-Home Authentication Extension (Section 3.5.2)." =20 2) This section says that the authenticator value must protect the message. =20 3.5.1. Computing Authentication Extension Values The Authenticator value computed for each authentication Extension MUST protect the following fields from the registration message: - the UDP payload (that is, the Registration Request or Registration Reply data), - all prior Extensions in their entirety, and - the Type, Length, and SPI of this Extension. =20 3) This section says MHAE must be present in message. =20 3.5.2. Mobile-Home Authentication Extension Exactly one authorization-enabling extension MUST be present in all Registration Requests, and also in all Registration Replies generated by the Home Agent. The Mobile-Home Authentication Extension is always an authorization-enabling for registration messages specified in this document.=20 =20 4) This section says MHAE must be in RRP. =20 c) The Mobile-Home Authentication Extension, =20 Note that items (a) and (c) MUST appear in every Registration Reply sent by the home agent. =20 5) This section says MN must check the authenticator value and discard reply if it's invalid. =20 3.6.2.1. Validity Checks =20 b) If the Code field indicates that service is denied by the home agent, or if the Code field indicates that the registration was accepted by the home agent, exactly one Mobile-Home Authentication Extension MUST be present in the Registration Reply, and the mobile node MUST check the Authenticator value in the Extension. If the Registration Reply was generated by the home agent but no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Reply=20 =20 I think valid authentication is pretty important before any entity changes its=20 operation based on the message. Logging a security violation is not considered=20 a change in the registration logic, IMHO. But stopping registration retransmission=20 surely is. =20 Kent ________________________________ From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Friday, June 23, 2006 9:53 AM To: Venkateshwara Sastry (vsastry); Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =09 =09 Sure we can say that the HA is allowed to send RRP on auth failure. What you cite here is talking about how the MN processes the RRP. It does not say anything about allowing or disallowing the HA to send RRP on auth failure.=20 =20 As I have been saying all along...all we need is to clarify the node behaviors better for error case handling. The current text does a poor job on describing the error handling cases.=20 =20 -Kuntal =20 =09 ________________________________ From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]=20 Sent: Friday, June 23, 2006 2:19 AM To: Chowdhury, Kuntal; Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 We can not really claim that current protocol allows HA to respond on auth failure. If HA responding on auth failure was really the intention of the designers, silently discarding such packets by MN as indicated in following text does not make sense. b) If the Code field indicates that service is denied by the home agent, or if the Code field indicates that the registration was accepted by the home agent, exactly one Mobile-Home Authentication Extension MUST be present in the Registration Reply, and the mobile node MUST check the Authenticator value in the Extension. If the Registration Reply was generated by the home agent but no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Reply and SHOULD log the event as a security exception. Regards Sastry =20 =09 ________________________________ From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Friday, June 23, 2006 4:56 AM To: Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Avi, =20 If a rogue MN can break into the network (i.e. pass access auth), anything is possible. However, by putting multiple levels of auth (at least 1 or 2); the operators make this possibility extremely slim. So, let's not get hung-up with the fact that rouge MNs can do bad things. =20 The issue is simple: if the auth of a RRQ fails, should the HA respond back to the MN? There are some people who believe a response should be sent. There are some who believe that the HA should silently discard the packet. =20 In this context, the current mip4 protocol allows the HA to send a response upon auth failure. The current text also allows those HA implementations which like to silently discard the packet. So, let's not change the protocol as it allows both the behaviors/implementations. We can just clarify some text to describe how the response packet is formatted. =20 -Kuntal =20 ------_=_NextPart_001_01C697AF.F416224F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
BTW, there are many =
places where authentication is specified as =
"MUST".
 
 
1) This section says the registration =
messages must be authenticated between MN and HA.
 
3.2. =
Authentication
 
   "Registration messages between
   a mobile node and its home agent MUST be authenticated with an
   authorization-enabling extension, e.g. the Mobile-Home Authentication
   Extension (Section 3.5.2)."
 
2) This section says =
that the authenticator value must protect the =
message.
 
3.5.1. Computing Authentication Extension Values

   The Authenticator value computed for each authentication Extension
   MUST protect the following fields from the registration message:

      -  the UDP payload (that is, the Registration Request or
         Registration Reply data),

      -  all prior Extensions in their entirety, and

      -  the Type, Length, and SPI of this =
Extension.
 
3) This section says =
MHAE must be present in message.
 
3.5.2. Mobile-Home Authentication Extension

   Exactly one authorization-enabling extension MUST be present in all
   Registration Requests, and also in all Registration Replies generated
   by the Home Agent.  The Mobile-Home Authentication Extension is
   always an authorization-enabling for registration messages specified
   in this document. 
 
4) This section says =
MHAE must be in RRP.
 
c) The =
Mobile-Home Authentication Extension,
 
  =
Note that items (a) and (c) MUST appear in every Registration Reply
   sent by the home agent.
 
5) This section says MN =
must check the authenticator value and discard reply if it's =
invalid.
 
3.6.2.1. Validity =
Checks
 
      b) If the Code field =
indicates that service is denied by the home
         agent, or if the Code field indicates that the registration was
         accepted by the home agent, exactly one Mobile-Home
         Authentication Extension MUST be present in the Registration
         Reply, and the mobile node MUST check the Authenticator value
         in the Extension.  If the Registration Reply was generated by
         the home agent but no Mobile-Home Authentication Extension is
         found, or if more than one Mobile-Home Authentication Extension
         is found, or if the Authenticator is invalid, the mobile node
         MUST silently discard the Reply =

 
I think =
valid authentication is pretty important before any entity changes its =

operation based on =
the message.  Logging a security violation is not considered =

a change in the =
registration logic, IMHO.  But stopping registration retransmission =

surely =
is.
 
Kent

=
From: Chowdhury, Kuntal=20 [mailto:kchowdhury@starentnetworks.com]
Sent: Friday, June = 23, 2006=20 9:53 AM
To: Venkateshwara Sastry (vsastry); Avi = Lior
Cc:=20 Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 Sending a = Reg=20 Reply when the Authenticator fails

Sure we can = say that=20 the HA is allowed to send RRP on auth failure. What you cite here is = talking=20 about how the MN processes the RRP. It does not say anything about = allowing or=20 disallowing the HA to send RRP on auth failure. =

 

As I have = been saying=20 all along…all we need is to clarify the node behaviors better = for error case=20 handling. The current text does a poor job on describing the error = handling=20 cases.

 

-Kuntal

 

From:=20 Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]
Sent: Friday, June 23, 2006 = 2:19=20 AM
To: Chowdhury, = Kuntal; Avi=20 Lior
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 = Sending a Reg=20 Reply when the Authenticator fails

 

We can not = really=20 claim that current protocol allows HA to respond on auth failure. If = HA=20 responding on auth failure was really the intention of the designers, = silently=20 discarding such packets by MN as indicated in following text does not = make=20 sense.

      b) If the Code field indicates that =
service is denied by the home
         =
agent, or if the Code field indicates that the registration =
was
         accepted by the =
home agent, exactly one =
Mobile-Home
         Authentication =
Extension MUST be present in the =
Registration
         Reply, and the =
mobile node MUST check the Authenticator =
value
         in the =
Extension.  If the Registration Reply was generated =
by
         the home agent =
but no Mobile-Home Authentication Extension =
is
         found, or if more =
than one Mobile-Home Authentication =
Extension
         is found, or if =
the Authenticator is invalid, the mobile =
node
         MUST silently =
discard the Reply and SHOULD log the event as =
a
         security =
exception.

Regards

Sastry

 

From:=20 Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com] =
Sent: Friday, June 23, 2006 = 4:56=20 AM
To: Avi = Lior
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 = Sending a Reg=20 Reply when the Authenticator fails

Avi,

 

If a = rogue MN can=20 break into the network (i.e. pass access auth), anything is = possible.=20 However, by putting multiple levels of auth (at least 1 or 2); the = operators=20 make this possibility extremely slim. So, let’s not get = hung-up with the=20 fact that rouge MNs can do bad things.

 

The issue = is=20 simple: if the auth of a RRQ fails, should the HA respond back to = the MN?=20 There are some people who believe a response should be sent. There = are some=20 who believe that the HA should silently discard the=20 packet.

 

In this = context,=20 the current mip4 protocol allows the HA to send a response upon auth = failure. The current text also allows those HA implementations which = like to=20 silently discard the packet. So, let’s not change the protocol = as it allows=20 both the behaviors/implementations. We can just clarify some text to = describe how the response packet is = formatted.

 

-Kuntal

 

------_=_NextPart_001_01C697AF.F416224F-- --===============1263524715== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1263524715==-- From mip4-bounces@ietf.org Sat Jun 24 13:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuC7k-0004L3-01; Sat, 24 Jun 2006 13:40:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuC7i-0004Fo-M4 for mip4@ietf.org; Sat, 24 Jun 2006 13:40:46 -0400 Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuC7i-0003jJ-4u for mip4@ietf.org; Sat, 24 Jun 2006 13:40:46 -0400 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id 4C78738194; Sat, 24 Jun 2006 19:40:45 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av10-1-sn2.hy.skanova.net (Postfix) with ESMTP id 3AF9037ED1; Sat, 24 Jun 2006 19:40:45 +0200 (CEST) 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 527A137E42; Sat, 24 Jun 2006 19:40:42 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FuC7d-0006E4-Jq; Sat, 24 Jun 2006 19:40:41 +0200 Message-ID: <449D7918.1020204@levkowetz.com> Date: Sat, 24 Jun 2006 19:40:40 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails References: <2979E38DD6FC6544B789C8DAD7BAFC5202062ACB@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5202062ACB@xmb-sjc-235.amer.cisco.com> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: "Chowdhury, Kuntal" , Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0000751604==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0000751604== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig5E807186F000D081357CB0C5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E807186F000D081357CB0C5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Kent, I agree to your points below, but think that this is to some extent missing the issue: on 2006-06-24 18:58 Kent Leung (kleung) said the following: > Hi Kuntal. >=20 >> >=20 >> > I think mucking with the MN-HA AE is not good. This can create the = >> > situation when MN sends a valid RRQ, and MITM can send a RRP with er= ror >> > code 131 and invalid MN-HA AE to the MN immediately. When the RRP = is=20 >> > received, the MN will stop retrying. It's possible that the RRQ wa= s=20 >> > lost in transit to the HA. And even if the valid RRP arrives later,= MN >> > may not be able to associate with the any pending RRQ, which could h= ave >> > been possibly removed since an associated RRP had been received alre= ady. >> >=20 >> [KC>] If the HA does not send RRP back to the MN, as you=20 >> initially suggested, the MN will keep retrying. That is not=20 >> good either. >>=20 >=20 > Let's not mix two issues: >=20 > 1) When processing the RRP, MN discards the message if authentication > fails > as clearly stated in RFC. This message is _not_ processed. Agreed. > 2) The security exception is logged by the MN when this happens as > clearly > stated in RFC. There is no mention that registration retransmission= stops. > I believe there's good reason for the omission because such message = is > indeed _not_ authenticated and should not be trusted. Agreed. What these two point don't cover is the behaviour of the HA. If the HA simply doesn't send back a reject, because it can't create a valid MN-HA = AE, this cannot be logged by the MN, and the MN has less information than it could have. I think we can do better, which is what we should focus on. Henrik > So I believe even sending bogus authenticator in MHAE will not work wel= l > in accordance to the RFC. >=20 >=20 >> Look at other protocols. For example EAP, if auth fails, the=20 >> authenticator MUST send back a failure packet to the peer.=20 >> Same case for other protocols over UNI. So, I am wondering=20 >> why the paranoids are not concerned about MiTM and DoS=20 >> attacks in general! >>=20 >> Regarding your comment "mucking with the MN-HA AE is not=20 >> good", if MN-HA AE is not absolutely necessary in the RRP=20 >> messages, I will be more than happy to propose that when code=20 >> 131 is included, the RRP contains no MN-HA AE. However, MN-HA=20 >> AE is a MUST in RRP. So, unless you have a better suggestion=20 >> that does not break current implementations, and does not=20 >> produce a new mip4 protocol, I don't think we have a choice here. >>=20 >>=20 >=20 > My view is that the MN/HA needs the mobility security association to > calculate the authenticator value used in the MHAE to be appended to th= e > RRQ and RRP. So without any SA, the MHAE cannot be appended and > therefore, RRQ/RRP cannot be sent. If there is an SA, then from MN/HA'= s > view, that is the SA to use to protect the RRP. It's up to the > administrator to decide which side has the incorrect key, not MN/HA's > judgement. >=20 > The security exception event is logged on both MN and HA. The SNMP tra= p > can inform the admin to fix the problem. >=20 > As for the bandwidth issue, a good backoff registration mechanism shoul= d > not consume much at all before the problem is dealt with. BTW, there i= s > no service when registration fails so it's very obvious to the end user= =2E > But logging in the network should have caught it right away. >=20 > 3.6.3. Registration Retransmission=20 >=20 > "Each successive retransmission timeout period > SHOULD be at least twice the previous period, as long as that is les= s > than the maximum as specified above." >=20 > So, if there is a misconfiguration of SA on either MN or HA, both sides= > will log a security exception. If HA doesn't have an SA, then only HA > log the security exception. The registration backoff mechanism on MN > reduces link consumption. I think we can work in accordance to RFC by > setting up an default SA between MN and HA for authentication failure > case. At least, then MN know it's a legit RRP. Else, stick with the > rules specified by RFC 3344 today. >=20 > Kent >=20 --------------enig5E807186F000D081357CB0C5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEnXkZeVhrtTJkXCMRAiUVAJ40ekKlDHUDv4aDpix+IJYVCwg4wgCgyGZu ds4yzdzRyvJWpZG8nhJ0MtM= =IoTC -----END PGP SIGNATURE----- --------------enig5E807186F000D081357CB0C5-- --===============0000751604== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0000751604==-- From mip4-bounces@ietf.org Sun Jun 25 19:37:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FueAP-0007S7-45; Sun, 25 Jun 2006 19:37:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FueAO-0007S2-FA for mip4@ietf.org; Sun, 25 Jun 2006 19:37:24 -0400 Received: from bws14.bridgewatersystems.com ([216.113.7.14] helo=exchange.bridgewatersys.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FueAN-0000hw-R4 for mip4@ietf.org; Sun, 25 Jun 2006 19:37:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Sun, 25 Jun 2006 19:37:49 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQAGbdTjA= From: "Avi Lior" To: "Venkateshwara Sastry \(vsastry\)" , "Chowdhury, Kuntal" X-Spam-Score: 0.1 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1840279399==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1840279399== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C698B0.5E98E521" This is a multi-part message in MIME format. ------_=_NextPart_001_01C698B0.5E98E521 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the protocol does allow an HA to respond with an auth failure. Code 131 was designed for that no? =20 However, as you point out an MN receiving a RRP which fails its auth check MUST silently discard. Silently discard means no more processing. Does that mean that the MN is not allowed to use the receipt of the RRP to stop sending any further RRQs? Some would say yes. =20 Therefore, why allow the HA to send an RRP when clearly the MN will silently discard it? =20 Is this a contradiction or is it by design? =20 =20 ________________________________ From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]=20 Sent: Friday, June 23, 2006 4:19 PM To: Chowdhury, Kuntal; Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =09 =09 We can not really claim that current protocol allows HA to respond on auth failure. If HA responding on auth failure was really the intention of the designers, silently discarding such packets by MN as indicated in following text does not make sense. b) If the Code field indicates that service is denied by the home agent, or if the Code field indicates that the registration was accepted by the home agent, exactly one Mobile-Home Authentication Extension MUST be present in the Registration Reply, and the mobile node MUST check the Authenticator value in the Extension. If the Registration Reply was generated by the home agent but no Mobile-Home Authentication Extension is found, or if more than one Mobile-Home Authentication Extension is found, or if the Authenticator is invalid, the mobile node MUST silently discard the Reply and SHOULD log the event as a security exception. =09 Regards Sastry ________________________________ From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Friday, June 23, 2006 4:56 AM To: Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =09 =09 Avi, =20 If a rogue MN can break into the network (i.e. pass access auth), anything is possible. However, by putting multiple levels of auth (at least 1 or 2); the operators make this possibility extremely slim. So, let's not get hung-up with the fact that rouge MNs can do bad things. =20 The issue is simple: if the auth of a RRQ fails, should the HA respond back to the MN? There are some people who believe a response should be sent. There are some who believe that the HA should silently discard the packet. =20 In this context, the current mip4 protocol allows the HA to send a response upon auth failure. The current text also allows those HA implementations which like to silently discard the packet. So, let's not change the protocol as it allows both the behaviors/implementations. We can just clarify some text to describe how the response packet is formatted. =20 -Kuntal =20 ------_=_NextPart_001_01C698B0.5E98E521 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I think the protocol does allow an HA to = respond with an=20 auth failure.  Code 131 was designed for that = no?
 
However, as you point out an MN receiving a RRP which fails its = auth=20 check MUST silently discard.  Silently discard means no more=20 processing.  Does that mean that the MN is not allowed to use the = receipt=20 of the RRP to stop sending any further RRQs?  Some would say=20 yes.
 
Therefore, why allow the HA to send an RRP when clearly the MN = will=20 silently discard it?
 
Is=20 this a contradiction or is it by design?
 
 

From: Venkateshwara Sastry = (vsastry)=20 [mailto:vsastry@cisco.com]
Sent: Friday, June 23, 2006 4:19 = PM
To: Chowdhury, Kuntal; Avi Lior
Cc: Mobile IPv4 = Mailing=20 List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 Authenticator fails

We can not = really claim that=20 current protocol allows HA to respond on auth failure. If HA = responding on=20 auth failure was really the intention of the designers, silently = discarding=20 such packets by MN as indicated in following text does not make = sense.
  =
    b) If the Code field indicates that service is denied by the home
         agent, or if the Code field indicates that the registration was
         accepted by the home agent, exactly one Mobile-Home
         Authentication Extension MUST be present in the Registration
         Reply, and the mobile node MUST check the Authenticator value
         in the Extension.  If the Registration Reply was generated by
         the home agent but no Mobile-Home Authentication Extension is
         found, or if more than one Mobile-Home Authentication Extension
         is found, or if the Authenticator is invalid, the mobile node
         MUST silently discard the Reply and SHOULD log the event as a
         security exception.
Regards
Sastry
=

From: Chowdhury, Kuntal=20 [mailto:kchowdhury@starentnetworks.com]
Sent: Friday, = June 23,=20 2006 4:56 AM
To: Avi Lior
Cc: Mobile IPv4 = Mailing=20 List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the = Authenticator fails

Avi,

 

If a = rogue MN can=20 break into the network (i.e. pass access auth), anything is = possible.=20 However, by putting multiple levels of auth (at least 1 or 2); the = operators=20 make this possibility extremely slim. So, let’s not get = hung-up with the=20 fact that rouge MNs can do bad things.

 

The issue = is=20 simple: if the auth of a RRQ fails, should the HA respond back to = the MN?=20 There are some people who believe a response should be sent. There = are some=20 who believe that the HA should silently discard the=20 packet.

 

In this = context,=20 the current mip4 protocol allows the HA to send a response upon auth = failure. The current text also allows those HA implementations which = like to=20 silently discard the packet. So, let’s not change the protocol = as it allows=20 both the behaviors/implementations. We can just clarify some text to = describe how the response packet is = formatted.

 

-Kuntal

 

------_=_NextPart_001_01C698B0.5E98E521-- --===============1840279399== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1840279399==-- From mip4-bounces@ietf.org Mon Jun 26 01:01:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujDr-0002HN-Ic; Mon, 26 Jun 2006 01:01:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FujDp-0002E8-GO for mip4@ietf.org; Mon, 26 Jun 2006 01:01:17 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FujDn-0006H1-Ft for mip4@ietf.org; Mon, 26 Jun 2006 01:01:17 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 26 Jun 2006 10:56:26 -0700 X-IronPort-AV: i="4.06,173,1149490800"; d="scan'208"; a="69762942:sNHT2370203042" Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5Q5146D027097; Mon, 26 Jun 2006 13:01:04 +0800 (CST) Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jun 2006 13:01:03 +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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Mon, 26 Jun 2006 13:01:02 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765012CC13F@xmb-hkg-416.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQAGbdTjAAKkQB4A== From: "Yoshi Tsuda \(yotsuda\)" To: "Avi Lior" , "Venkateshwara Sastry \(vsastry\)" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 26 Jun 2006 05:01:03.0648 (UTC) FILETIME=[86633200:01C698DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Avi and all, Good point. Personally, I believe, an MN should stop sending RRQs, if it receives an RRP with 131, and if the MN has sent the original RRQ in spite of the meaning of "silently discard". The term, "silently discard" found to be used in rfc2002, too; so it might have a histrical reason, though... Also, I agree with Kuntal that error handlings haven't been well documented. If this causes deployment issues, should we have a new I-D about handling codes or ask modifications of rfc3344 to the inventor of MIP? Thanks. -Yoshi > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Monday, June 26, 2006 8:38 AM > To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator fails >=20 > I think the protocol does allow an HA to respond with an auth=20 > failure. Code 131 was designed for that no? > =20 > However, as you point out an MN receiving a RRP which fails=20 > its auth check MUST silently discard. Silently discard means=20 > no more processing. Does that mean that the MN is not=20 > allowed to use the receipt of the RRP to stop sending any=20 > further RRQs? Some would say yes. > =20 > Therefore, why allow the HA to send an RRP when clearly the=20 > MN will silently discard it? > =20 > Is this a contradiction or is it by design? > =20 > =20 >=20 >=20 >=20 > ________________________________ >=20 > From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]=20 > Sent: Friday, June 23, 2006 4:19 PM > To: Chowdhury, Kuntal; Avi Lior > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator fails > =09 > =09 > We can not really claim that current protocol allows HA=20 > to respond on auth failure. If HA responding on auth failure=20 > was really the intention of the designers, silently=20 > discarding such packets by MN as indicated in following text=20 > does not make sense. > b) If the Code field indicates that service is=20 > denied by the home > agent, or if the Code field indicates that the=20 > registration was > accepted by the home agent, exactly one Mobile-Home > Authentication Extension MUST be present in=20 > the Registration > Reply, and the mobile node MUST check the=20 > Authenticator value > in the Extension. If the Registration Reply=20 > was generated by > the home agent but no Mobile-Home=20 > Authentication Extension is > found, or if more than one Mobile-Home=20 > Authentication Extension > is found, or if the Authenticator is invalid,=20 > the mobile node > MUST silently discard the Reply and SHOULD log=20 > the event as a > security exception. > =09 > Regards > Sastry >=20 >=20 > ________________________________ >=20 > From: Chowdhury, Kuntal=20 > [mailto:kchowdhury@starentnetworks.com]=20 > Sent: Friday, June 23, 2006 4:56 AM > To: Avi Lior > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply=20 > when the Authenticator fails > =09 > =09 >=20 > Avi, >=20 > =20 >=20 > If a rogue MN can break into the network (i.e.=20 > pass access auth), anything is possible. However, by putting=20 > multiple levels of auth (at least 1 or 2); the operators make=20 > this possibility extremely slim. So, let's not get hung-up=20 > with the fact that rouge MNs can do bad things. >=20 > =20 >=20 > The issue is simple: if the auth of a RRQ=20 > fails, should the HA respond back to the MN? There are some=20 > people who believe a response should be sent. There are some=20 > who believe that the HA should silently discard the packet. >=20 > =20 >=20 > In this context, the current mip4 protocol=20 > allows the HA to send a response upon auth failure. The=20 > current text also allows those HA implementations which like=20 > to silently discard the packet. So, let's not change the=20 > protocol as it allows both the behaviors/implementations. We=20 > can just clarify some text to describe how the response=20 > packet is formatted. >=20 > =20 >=20 > -Kuntal >=20 > =20 >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 26 02:57:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ful1q-0007hY-MN; Mon, 26 Jun 2006 02:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ful1p-0007bU-G0 for mip4@ietf.org; Mon, 26 Jun 2006 02:57:01 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ful1m-0002rz-27 for mip4@ietf.org; Mon, 26 Jun 2006 02:57:01 -0400 Received: from india-core-1.cisco.com ([64.104.129.221]) by ind-iport-1.cisco.com with ESMTP; 26 Jun 2006 12:52:11 -0700 X-IronPort-AV: i="4.06,174,1149490800"; d="scan'208"; a="69779191:sNHT34706064" Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5Q6uoqZ026684; Mon, 26 Jun 2006 06:56:51 GMT Received: from xmb-blr-417.apac.cisco.com ([64.104.140.146]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jun 2006 12:26:49 +0530 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Mon, 26 Jun 2006 12:26:49 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQAGbdTjAAKkQB4AAEtz3Q From: "Venkateshwara Sastry \(vsastry\)" To: "Yoshi Tsuda \(yotsuda\)" , "Avi Lior" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 26 Jun 2006 06:56:49.0870 (UTC) FILETIME=[B2A88EE0:01C698ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org IMHO, if RRQ authentication failed at HA(may be packet was corrupted when received by HA), and HA HAS a SA with that MN, the HA can send an RRP with MHAE and error code 131. In such a sceanrio, there is a possibility that MN can authenticate the RRP and continue further processing. Regards Sastry > -----Original Message----- > From: Yoshi Tsuda (yotsuda)=20 > Sent: Monday, June 26, 2006 10:31 AM > To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator fails >=20 > Hi Avi and all, >=20 > Good point. >=20 > Personally, I believe, an MN should stop sending RRQs, if=20 > it receives an RRP with 131, and if the MN has sent the =20 > original RRQ in spite of the meaning of "silently discard". > The term, "silently discard" found to be used in rfc2002, =20 > too; so it might have a histrical reason, though... >=20 > Also, I agree with Kuntal that error handlings haven't been =20 > well documented. If this causes deployment issues, should=20 > we have a new I-D about handling codes or ask modifications=20 > of rfc3344 to the inventor of MIP? >=20 > Thanks. > -Yoshi >=20 > > -----Original Message----- > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > Sent: Monday, June 26, 2006 8:38 AM > > To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator=20 > > fails > >=20 > > I think the protocol does allow an HA to respond with an=20 > auth failure. =20 > > Code 131 was designed for that no? > > =20 > > However, as you point out an MN receiving a RRP which fails=20 > its auth=20 > > check MUST silently discard. Silently discard means no more=20 > > processing. Does that mean that the MN is not allowed to use the=20 > > receipt of the RRP to stop sending any further RRQs? Some=20 > would say=20 > > yes. > > =20 > > Therefore, why allow the HA to send an RRP when clearly the MN will=20 > > silently discard it? > > =20 > > Is this a contradiction or is it by design? > > =20 > > =20 > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]=20 > > Sent: Friday, June 23, 2006 4:19 PM > > To: Chowdhury, Kuntal; Avi Lior > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator=20 > > fails > > =09 > > =09 > > We can not really claim that current protocol allows HA=20 > to respond on=20 > > auth failure. If HA responding on auth failure was really the=20 > > intention of the designers, silently discarding such=20 > packets by MN as=20 > > indicated in following text does not make sense. > > b) If the Code field indicates that service is=20 > denied by the=20 > > home > > agent, or if the Code field indicates that the=20 > registration=20 > > was > > accepted by the home agent, exactly one Mobile-Home > > Authentication Extension MUST be present in=20 > the Registration > > Reply, and the mobile node MUST check the=20 > Authenticator=20 > > value > > in the Extension. If the Registration Reply=20 > was generated=20 > > by > > the home agent but no Mobile-Home=20 > Authentication Extension=20 > > is > > found, or if more than one Mobile-Home Authentication=20 > > Extension > > is found, or if the Authenticator is invalid,=20 > the mobile=20 > > node > > MUST silently discard the Reply and SHOULD log=20 > the event as=20 > > a > > security exception. > > =09 > > Regards > > Sastry > >=20 > >=20 > > ________________________________ > >=20 > > From: Chowdhury, Kuntal > > [mailto:kchowdhury@starentnetworks.com]=20 > > Sent: Friday, June 23, 2006 4:56 AM > > To: Avi Lior > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply=20 > when the Authenticator=20 > > fails > > =09 > > =09 > >=20 > > Avi, > >=20 > > =20 > >=20 > > If a rogue MN can break into the network (i.e.=20 > > pass access auth), anything is possible. However, by=20 > putting multiple=20 > > levels of auth (at least 1 or 2); the operators make this=20 > possibility=20 > > extremely slim. So, let's not get hung-up with the fact=20 > that rouge MNs=20 > > can do bad things. > >=20 > > =20 > >=20 > > The issue is simple: if the auth of a RRQ=20 > fails, should the HA=20 > > respond back to the MN? There are some people who believe a=20 > response=20 > > should be sent. There are some who believe that the HA=20 > should silently=20 > > discard the packet. > >=20 > > =20 > >=20 > > In this context, the current mip4 protocol=20 > allows the HA to send a=20 > > response upon auth failure. The current text also allows those HA=20 > > implementations which like to silently discard the packet.=20 > So, let's=20 > > not change the protocol as it allows both the=20 > > behaviors/implementations. We can just clarify some text to=20 > describe=20 > > how the response packet is formatted. > >=20 > > =20 > >=20 > > -Kuntal > >=20 > > =20 > >=20 > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 26 04:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fum1t-0001ND-7a; Mon, 26 Jun 2006 04:01:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fum1r-00011B-96 for mip4@ietf.org; Mon, 26 Jun 2006 04:01:07 -0400 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 1Fum1r-0006UF-6K for mip4@ietf.org; Mon, 26 Jun 2006 04:01:07 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fum1o-0001EP-QU for mip4@ietf.org; Mon, 26 Jun 2006 04:01:07 -0400 Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ind-iport-1.cisco.com with ESMTP; 26 Jun 2006 13:56:15 -0700 X-IronPort-AV: i="4.06,174,1149490800"; d="scan'208"; a="69787837:sNHT34828056" Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5Q80t6D025123; Mon, 26 Jun 2006 16:00:55 +0800 (CST) Received: from xmb-hkg-416.apac.cisco.com ([64.104.123.88]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 26 Jun 2006 16:00:55 +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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Mon, 26 Jun 2006 16:00:54 +0800 Message-ID: <35912544FC930E49BF20EF16C3EF2765012CC24C@xmb-hkg-416.apac.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQAGbdTjAAKkQB4AAEtz3QAADOcVA= From: "Yoshi Tsuda \(yotsuda\)" To: "Venkateshwara Sastry \(vsastry\)" , "Avi Lior" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 26 Jun 2006 08:00:55.0116 (UTC) FILETIME=[A69A88C0:01C698F6] X-Spam-Score: -2.6 (--) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Sastry, Oh, I see. Thank you for your pointing out the case. Then, I should have written the conditions like the following: a) An MN should stop sending RRQs, a-1) if it receives an RRP with 131, a-2) and if auth check fails, a-3) and if the MN has sent the original RRQ. <- This might be caused due to key differences between an HA and an MN. But, according to the current rfc3344, an MN can continue sending such RRQs. b) An MN can re-send an RRQ, b-1) if the MN receives an RRP with 131, b-2) and if auth check succeeds, b-3) and if the MN has sent the original RRQ. <- This might be caused due to a corrupted RRQ. This kind of description about error handling, other than 69, 133, 136 and so on, isn't so clear in rfc3344, I'm afraid. Best regards. -Yoshi > -----Original Message----- > From: Venkateshwara Sastry (vsastry)=20 > Sent: Monday, June 26, 2006 3:57 PM > To: Yoshi Tsuda (yotsuda); 'Avi Lior'; 'Chowdhury, Kuntal' > Cc: 'Mobile IPv4 Mailing List' > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator fails >=20 > IMHO, if RRQ authentication failed at HA(may be packet was=20 > corrupted when received by HA), and HA HAS a SA with that MN,=20 > the HA can send an RRP with MHAE and error code 131. In such=20 > a sceanrio, there is a possibility that MN can authenticate=20 > the RRP and continue further processing. >=20 > Regards > Sastry >=20 > > -----Original Message----- > > From: Yoshi Tsuda (yotsuda) > > Sent: Monday, June 26, 2006 10:31 AM > > To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator=20 > > fails > >=20 > > Hi Avi and all, > >=20 > > Good point. > >=20 > > Personally, I believe, an MN should stop sending RRQs, if it=20 > > receives an RRP with 131, and if the MN has sent the=20 > original RRQ in=20 > > spite of the meaning of "silently discard". > > The term, "silently discard" found to be used in rfc2002,=20 > too; so it=20 > > might have a histrical reason, though... > >=20 > > Also, I agree with Kuntal that error handlings haven't been well=20 > > documented. If this causes deployment issues, should we=20 > have a new=20 > > I-D about handling codes or ask modifications of rfc3344 to the=20 > > inventor of MIP? > >=20 > > Thanks. > > -Yoshi > >=20 > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Monday, June 26, 2006 8:38 AM > > > To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal > > > Cc: Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator=20 > > > fails > > >=20 > > > I think the protocol does allow an HA to respond with an > > auth failure. =20 > > > Code 131 was designed for that no? > > > =20 > > > However, as you point out an MN receiving a RRP which fails > > its auth > > > check MUST silently discard. Silently discard means no more=20 > > > processing. Does that mean that the MN is not allowed to use the=20 > > > receipt of the RRP to stop sending any further RRQs? Some > > would say > > > yes. > > > =20 > > > Therefore, why allow the HA to send an RRP when clearly=20 > the MN will=20 > > > silently discard it? > > > =20 > > > Is this a contradiction or is it by design? > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > > ________________________________ > > >=20 > > > From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]=20 > > > Sent: Friday, June 23, 2006 4:19 PM > > > To: Chowdhury, Kuntal; Avi Lior > > > Cc: Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > > fails > > > =09 > > > =09 > > > We can not really claim that current protocol allows HA > > to respond on > > > auth failure. If HA responding on auth failure was really the=20 > > > intention of the designers, silently discarding such > > packets by MN as > > > indicated in following text does not make sense. > > > b) If the Code field indicates that service is > > denied by the > > > home > > > agent, or if the Code field indicates that the > > registration > > > was > > > accepted by the home agent, exactly one Mobile-Home > > > Authentication Extension MUST be present in > > the Registration > > > Reply, and the mobile node MUST check the > > Authenticator > > > value > > > in the Extension. If the Registration Reply > > was generated > > > by > > > the home agent but no Mobile-Home > > Authentication Extension > > > is > > > found, or if more than one Mobile-Home Authentication=20 > > > Extension > > > is found, or if the Authenticator is invalid, > > the mobile > > > node > > > MUST silently discard the Reply and SHOULD log > > the event as > > > a > > > security exception. > > > =09 > > > Regards > > > Sastry > > >=20 > > >=20 > > > ________________________________ > > >=20 > > > From: Chowdhury, Kuntal > > > [mailto:kchowdhury@starentnetworks.com]=20 > > > Sent: Friday, June 23, 2006 4:56 AM > > > To: Avi Lior > > > Cc: Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] 3344 Sending a Reg Reply > > when the Authenticator > > > fails > > > =09 > > > =09 > > >=20 > > > Avi, > > >=20 > > > =20 > > >=20 > > > If a rogue MN can break into the network (i.e.=20 > > > pass access auth), anything is possible. However, by > > putting multiple > > > levels of auth (at least 1 or 2); the operators make this > > possibility > > > extremely slim. So, let's not get hung-up with the fact > > that rouge MNs > > > can do bad things. > > >=20 > > > =20 > > >=20 > > > The issue is simple: if the auth of a RRQ > > fails, should the HA > > > respond back to the MN? There are some people who believe a > > response > > > should be sent. There are some who believe that the HA > > should silently > > > discard the packet. > > >=20 > > > =20 > > >=20 > > > In this context, the current mip4 protocol > > allows the HA to send a > > > response upon auth failure. The current text also allows those HA=20 > > > implementations which like to silently discard the packet. > > So, let's > > > not change the protocol as it allows both the=20 > > > behaviors/implementations. We can just clarify some text to > > describe > > > how the response packet is formatted. > > >=20 > > > =20 > > >=20 > > > -Kuntal > > >=20 > > > =20 > > >=20 > > >=20 > >=20 >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 26 04:11:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumBR-0001Gy-SD; Mon, 26 Jun 2006 04:11:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumBQ-0001Bo-1p for mip4@ietf.org; Mon, 26 Jun 2006 04:11:00 -0400 Received: from wx-out-0102.google.com ([66.249.82.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumBP-0007VV-Lz for mip4@ietf.org; Mon, 26 Jun 2006 04:11:00 -0400 Received: by wx-out-0102.google.com with SMTP id s12so871780wxc for ; Mon, 26 Jun 2006 01:10:59 -0700 (PDT) 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=FCCeNsycbkYJ3qqROYTcnaWdQ02ySNvkXMZ2wDHMwG7fe+mtjQDPq3cHNjNZ8BC6qiNgXySTAGDHtTT9mq4R5OXNSGh+SsMhQFQyo68XCvCQicz8OzzrXeDiL2ymiFeLSWRtV/pxxTRHUNhDiO//FXBW9WyBvgGBB5AsrQ6Fx+A= Received: by 10.70.26.1 with SMTP id 1mr7580567wxz; Mon, 26 Jun 2006 01:10:59 -0700 (PDT) Received: by 10.70.17.13 with HTTP; Mon, 26 Jun 2006 01:10:59 -0700 (PDT) Message-ID: Date: Mon, 26 Jun 2006 16:10:59 +0800 From: "zhen cao" To: mip4@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Subject: [Mip4] Re: Fwd: I-D ACTION:draft-lai-mip4-proxy-sequence-problem-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1913948670==" Errors-To: mip4-bounces@ietf.org --===============1913948670== Content-Type: multipart/alternative; boundary="----=_Part_43192_21193324.1151309459430" ------=_Part_43192_21193324.1151309459430 Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIFNob3V3ZW4KCiAgICAgSSBoYXZlIG9uZSBxdWVzdGlvbiBhYm91dCB5b3VyIGRyYWZ0OgoK ICAgICBJc24ndCB0aW1lc3RhbXAgaW4gaWRlbnRpZmljYXRpb24gb2YgcnJxIHdpbGwgYmUgdXNl ZCBmb3IgYW50aS1yZXBseT8KCk1hbnkgdGhhbmtzLApaaGVuCgoKLS0tLS0tLS0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpIaSBmb2xrcywKCgpX ZSd2ZSBwdWJsaXNoZWQgYSBuZXcgZHJhZnQsICJQcm9ibGVtIG9mIFJlcGxheSBQcm90ZWN0aW9u IFVzaW5nClNlcXVlbmNlIE51bWJlciBpbiBQcm94eSBNb2JpbGUgSVB2NCIuCgoKVGhlIGRvY3Vt ZW50IHByZXNlbnRzIHRoZSBwcm9ibGVtcyBvZiByZXBsYXkgcHJvdGVjdGlvbiB1c2luZyBzZXF1 ZW5jZQpudW1iZXIgaW4gcHJveHkgTW9iaWxlIElQdjQgc29sdXRpb24uICBUaGUgc2VxdWVuY2Ug bnVtYmVyIGNhbm5vdApwcmV2ZW50IHJlZ2lzdHJhdGlvbiBtZXNzYWdlIGZyb20gcmVwbGF5IGF0 dGFjay4KCgpBbnkgY29tbWVudHMgYXJlIHdlbGNvbWUuCgoKVGhhbmtzLApTaG91d2VuLAoKCi0t LS0tLS0tLS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQpGcm9tOiBJbnRlcm5ldC1EcmFm dHMgYXQgaWV0Zi5vcmcgPEludGVybmV0LURyYWZ0cyBhdCBpZXRmLm9yZz4KRGF0ZTogMjAwNi02 LTIzIMnPzuc2OjUwClN1YmplY3Q6IEktRCBBQ1RJT046ZHJhZnQtbGFpLW1pcDQtcHJveHktc2Vx dWVuY2UtcHJvYmxlbS0wMC50eHQKVG86IGktZC1hbm5vdW5jZSBhdCBpZXRmLm9yZwoKCgpBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuCgoKCiAgICAgIFRpdGxlICAgICAgICAgICA6IFByb2JsZW0gb2Yg UmVwbGF5IFByb3RlY3Rpb24gVXNpbmcgU2VxdWVuY2UKTnVtYmVyIGluIFByb3h5IE1vYmlsZSBJ UHY0CiAgICAgIEF1dGhvcihzKSAgICAgICA6IFMuIExhaSwgSC4gRGVuZwogICAgICBGaWxlbmFt ZSAgICAgICAgOiBkcmFmdC1sYWktbWlwNC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dAog ICAgICBQYWdlcyAgICAgICAgICAgOiA3CiAgICAgIERhdGUgICAgICAgICAgICA6IDIwMDYtNi0y MgoKCiBUaGUgZG9jdW1lbnQgcHJlc2VudHMgdGhlIHByb2JsZW1zIG9mIHJlcGxheSBwcm90ZWN0 aW9uIHVzaW5nCiBzZXF1ZW5jZSBudW1iZXIgaW4gcHJveHkgTW9iaWxlIElQdjQgc29sdXRpb24u ICBUaGUgc2VxdWVuY2UgbnVtYmVyCiBjYW5ub3QgcHJldmVudCByZWdpc3RyYXRpb24gbWVzc2Fn ZSBmcm9tIHJlcGxheSBhdHRhY2suCgoKCkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0Cmlz Omh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxhaS1taXA0LXByb3h5 LXNlcXVlbmNlLXByb2JsZW0tMDAudHh0CgoKVG8gcmVtb3ZlIHlvdXJzZWxmIGZyb20gdGhlIEkt RCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhIG1lc3NhZ2UgdG8KaS1kLWFubm91bmNlLXJlcXVl c3QgYXQgaWV0Zi5vcmcgd2l0aCB0aGUgd29yZCB1bnN1YnNjcmliZSBpbiB0aGUgYm9keSBvZgp0 aGUgbWVzc2FnZS4KWW91IGNhbiBhbHNvIHZpc2l0IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5jZQp0byBjaGFuZ2UgeW91ciBzdWJzY3JpcHRpb24gc2V0 dGluZ3MuCgoKCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUC4gTG9naW4gd2l0aCB0aGUgdXNlcm5hbWUKImFub255bW91cyIgYW5kIGEgcGFzc3dvcmQg b2YgeW91ciBlLW1haWwgYWRkcmVzcy4gQWZ0ZXIgbG9nZ2luZyBpbiwKdHlwZSAiY2QgaW50ZXJu ZXQtZHJhZnRzIiBhbmQgdGhlbgogICAgICAiZ2V0IGRyYWZ0LWxhaS1taXA0LXByb3h5LXNlcXVl bmNlLXByb2JsZW0tMDAudHh0Ii4KCgpBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9y aWVzIGNhbiBiZSBmb3VuZAppbmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IgZnRw Oi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQKCgoKSW50ZXJuZXQtRHJhZnRz IGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5IGUtbWFpbC4KCgpTZW5kIGEgbWVzc2FnZSB0bzoKICAg ICAgbWFpbHNlcnYgYXQgaWV0Zi5vcmcuCkluIHRoZSBib2R5IHR5cGU6CiAgICAgICJGSUxFIC9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbGFpLW1pcDQtcHJveHktc2VxdWVuY2UtcHJvYmxlbS0wMC50 eHQiLgoKCk5PVEU6ICAgVGhlIG1haWwgc2VydmVyIGF0IGlldGYub3JnIGNhbiByZXR1cm4gdGhl IGRvY3VtZW50IGluCiAgICAgIE1JTUUtZW5jb2RlZCBmb3JtIGJ5IHVzaW5nIHRoZSAibXBhY2si IHV0aWxpdHkuICBUbyB1c2UgdGhpcwogICAgICBmZWF0dXJlLCBpbnNlcnQgdGhlIGNvbW1hbmQg IkVOQ09ESU5HIG1pbWUiIGJlZm9yZSB0aGUgIkZJTEUiCiAgICAgIGNvbW1hbmQuICBUbyBkZWNv ZGUgdGhlIHJlc3BvbnNlKHMpLCB5b3Ugd2lsbCBuZWVkICJtdW5wYWNrIiBvcgogICAgICBhIE1J TUUtY29tcGxpYW50IG1haWwgcmVhZGVyLiAgRGlmZmVyZW50IE1JTUUtY29tcGxpYW50IG1haWwg cmVhZGVycwogICAgICBleGhpYml0IGRpZmZlcmVudCBiZWhhdmlvciwgZXNwZWNpYWxseSB3aGVu IGRlYWxpbmcgd2l0aAogICAgICAibXVsdGlwYXJ0IiBNSU1FIG1lc3NhZ2VzIChpLmUuIGRvY3Vt ZW50cyB3aGljaCBoYXZlIGJlZW4gc3BsaXQKICAgICAgdXAgaW50byBtdWx0aXBsZSBtZXNzYWdl cyksIHNvIGNoZWNrIHlvdXIgbG9jYWwgZG9jdW1lbnRhdGlvbiBvbgogICAgICBob3cgdG8gbWFu aXB1bGF0ZSB0aGVzZSBtZXNzYWdlcy4KCgoKQmVsb3cgaXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBl bmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsIHJlYWRlcgppbXBsZW1lbnRhdGlvbiB0byBhdXRv bWF0aWNhbGx5IHJldHJpZXZlIHRoZSBBU0NJSSB2ZXJzaW9uIG9mIHRoZQpJbnRlcm5ldC1EcmFm dC4KCgoKCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpJ LUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0CkktRC1Bbm5vdW5jZSBhdCBpZXRmLm9yZ2h0dHBzOi8v d3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQo= ------=_Part_43192_21193324.1151309459430 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: base64 Content-Disposition: inline PGRpdj5IaSwgU2hvdXdlbjwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2PiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBJIGhhdmUgb25lIHF1ZXN0aW9uIGFib3V0IHlvdXIgZHJhZnQ6PC9kaXY+ CjxkaXY+Jm5ic3A7PC9kaXY+CjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElzbid0IHRp bWVzdGFtcCBpbiBpZGVudGlmaWNhdGlvbiBvZiBycnEgd2lsbCBiZSB1c2VkIGZvciBhbnRpLXJl cGx5PzwvZGl2Pgo8ZGl2PiZuYnNwOzwvZGl2Pgo8ZGl2Pk1hbnkgdGhhbmtzLDwvZGl2Pgo8ZGl2 PlpoZW48L2Rpdj4KPGRpdj4mbmJzcDsmbmJzcDsgPC9kaXY+CjxkaXY+Jm5ic3A7PC9kaXY+Cjxk aXY+LS0tLS0tLS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPC9kaXY+CjxkaXY+PHByZSBzdHlsZT0iTUFSR0lOOiAwZW0iPkhpIGZvbGtzLDwvcHJl Pjxicj48cHJlIHN0eWxlPSJNQVJHSU46IDBlbSI+V2UndmUgcHVibGlzaGVkIGEgbmV3IGRyYWZ0 LCAmcXVvdDtQcm9ibGVtIG9mIFJlcGxheSBQcm90ZWN0aW9uIFVzaW5nClNlcXVlbmNlIE51bWJl ciBpbiBQcm94eSBNb2JpbGUgSVB2NCZxdW90Oy48L3ByZT48YnI+PHByZSBzdHlsZT0iTUFSR0lO OiAwZW0iPlRoZSBkb2N1bWVudCBwcmVzZW50cyB0aGUgcHJvYmxlbXMgb2YgcmVwbGF5IHByb3Rl Y3Rpb24gdXNpbmcgc2VxdWVuY2UKbnVtYmVyIGluIHByb3h5IE1vYmlsZSBJUHY0IHNvbHV0aW9u LiAgVGhlIHNlcXVlbmNlIG51bWJlciBjYW5ub3QKcHJldmVudCByZWdpc3RyYXRpb24gbWVzc2Fn ZSBmcm9tIHJlcGxheSBhdHRhY2suPC9wcmU+PGJyPjxwcmUgc3R5bGU9Ik1BUkdJTjogMGVtIj5B bnkgY29tbWVudHMgYXJlIHdlbGNvbWUuPC9wcmU+PGJyPjxwcmUgc3R5bGU9Ik1BUkdJTjogMGVt Ij5UaGFua3MsClNob3V3ZW4sPC9wcmU+PGJyPjxwcmUgc3R5bGU9Ik1BUkdJTjogMGVtIj4tLS0t LS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0KRnJvbTogSW50ZXJuZXQtRHJhZnRz IGF0IDxhIGhyZWY9Imh0dHA6Ly9pZXRmLm9yZyI+aWV0Zi5vcmc8L2E+ICZsdDtJbnRlcm5ldC1E cmFmdHMgYXQgPGEgaHJlZj0iaHR0cDovL2lldGYub3JnIj5pZXRmLm9yZzwvYT4mZ3Q7CkRhdGU6 IDIwMDYtNi0yMyDJz87nNjo1MApTdWJqZWN0OiBJLUQgQUNUSU9OOmRyYWZ0LWxhaS1taXA0LXBy b3h5LXNlcXVlbmNlLXByb2JsZW0tMDAudHh0ClRvOiBpLWQtYW5ub3VuY2UgYXQgPGEgaHJlZj0i aHR0cDovL2lldGYub3JnIj5pZXRmLm9yZzwvYT48L3ByZT48YnI+PHByZSBzdHlsZT0iTUFSR0lO OiAwZW0iPjxicj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPC9wcmU+PGJyPjxwcmUgc3R5bGU9Ik1B UkdJTjogMGVtIj48YnI+ICAgICAgVGl0bGUgICAgICAgICAgIDogUHJvYmxlbSBvZiBSZXBsYXkg UHJvdGVjdGlvbiBVc2luZyBTZXF1ZW5jZQpOdW1iZXIgaW4gUHJveHkgTW9iaWxlIElQdjQKICAg ICAgQXV0aG9yKHMpICAgICAgIDogUy4gTGFpLCBILiBEZW5nCiAgICAgIEZpbGVuYW1lICAgICAg ICA6IGRyYWZ0LWxhaS1taXA0LXByb3h5LXNlcXVlbmNlLXByb2JsZW0tMDAudHh0CiAgICAgIFBh Z2VzICAgICAgICAgICA6IDcKICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAwNi02LTIyPC9wcmU+ PGJyPjxwcmUgc3R5bGU9Ik1BUkdJTjogMGVtIj4gVGhlIGRvY3VtZW50IHByZXNlbnRzIHRoZSBw cm9ibGVtcyBvZiByZXBsYXkgcHJvdGVjdGlvbiB1c2luZwogc2VxdWVuY2UgbnVtYmVyIGluIHBy b3h5IE1vYmlsZSBJUHY0IHNvbHV0aW9uLiAgVGhlIHNlcXVlbmNlIG51bWJlcgogY2Fubm90IHBy ZXZlbnQgcmVnaXN0cmF0aW9uIG1lc3NhZ2UgZnJvbSByZXBsYXkgYXR0YWNrLjwvcHJlPjxicj48 cHJlIHN0eWxlPSJNQVJHSU46IDBlbSI+PGJyPkEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0 IGlzOgo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1s YWktbWlwNC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dCI+aHR0cDovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGFpLW1pcDQtcHJveHktc2VxdWVuY2UtcHJvYmxlbS0w MC50eHQ8L2E+PC9wcmU+PGJyPjxwcmUgc3R5bGU9Ik1BUkdJTjogMGVtIj5UbyByZW1vdmUgeW91 cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91bmNlbWVudCBsaXN0LCBzZW5kIGEgbWVzc2FnZSB0bwpp LWQtYW5ub3VuY2UtcmVxdWVzdCBhdCA8YSBocmVmPSJodHRwOi8vaWV0Zi5vcmciPmlldGYub3Jn PC9hPiB3aXRoIHRoZSB3b3JkIHVuc3Vic2NyaWJlIGluIHRoZSBib2R5IG9mCnRoZSBtZXNzYWdl LgpZb3UgY2FuIGFsc28gdmlzaXQgPGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vSS1ELWFubm91bmNlIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9JLUQtYW5ub3VuY2U8L2E+CnRvIGNoYW5nZSB5b3VyIHN1YnNjcmlwdGlvbiBzZXR0 aW5ncy48L3ByZT48YnI+PHByZSBzdHlsZT0iTUFSR0lOOiAwZW0iPjxicj5JbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAuIExvZ2luIHdpdGggdGhlIHVz ZXJuYW1lCiZxdW90O2Fub255bW91cyZxdW90OyBhbmQgYSBwYXNzd29yZCBvZiB5b3VyIGUtbWFp bCBhZGRyZXNzLiBBZnRlciBsb2dnaW5nIGluLAp0eXBlICZxdW90O2NkIGludGVybmV0LWRyYWZ0 cyZxdW90OyBhbmQgdGhlbgogICAgICAmcXVvdDtnZXQgZHJhZnQtbGFpLW1pcDQtcHJveHktc2Vx dWVuY2UtcHJvYmxlbS0wMC50eHQmcXVvdDsuPC9wcmU+PGJyPjxwcmUgc3R5bGU9Ik1BUkdJTjog MGVtIj5BIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNhbiBiZSBmb3VuZCBp bgo8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sIj5odHRwOi8vd3d3Lmll dGYub3JnL3NoYWRvdy5odG1sPC9hPgpvciA8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0 Zi8xc2hhZG93LXNpdGVzLnR4dCI+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRl cy50eHQ8L2E+PC9wcmU+PGJyPjxwcmUgc3R5bGU9Ik1BUkdJTjogMGVtIj48YnI+SW50ZXJuZXQt RHJhZnRzIGNhbiBhbHNvIGJlIG9idGFpbmVkIGJ5IGUtbWFpbC48L3ByZT48YnI+PHByZSBzdHls ZT0iTUFSR0lOOiAwZW0iPgpTZW5kIGEgbWVzc2FnZSB0bzoKICAgICAgbWFpbHNlcnYgYXQgPGEg aHJlZj0iaHR0cDovL2lldGYub3JnIj5pZXRmLm9yZzwvYT4uCkluIHRoZSBib2R5IHR5cGU6CiAg ICAgICZxdW90O0ZJTEUgL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sYWktbWlwNC1wcm94eS1zZXF1 ZW5jZS1wcm9ibGVtLTAwLnR4dCZxdW90Oy48L3ByZT48YnI+PHByZSBzdHlsZT0iTUFSR0lOOiAw ZW0iPk5PVEU6ICAgVGhlIG1haWwgc2VydmVyIGF0IDxhIGhyZWY9Imh0dHA6Ly9pZXRmLm9yZyI+ aWV0Zi5vcmc8L2E+IGNhbiByZXR1cm4gdGhlIGRvY3VtZW50IGluCiAgICAgIE1JTUUtZW5jb2Rl ZCBmb3JtIGJ5IHVzaW5nIHRoZSAmcXVvdDttcGFjayZxdW90OyB1dGlsaXR5LiAgVG8gdXNlIHRo aXMKICAgICAgZmVhdHVyZSwgaW5zZXJ0IHRoZSBjb21tYW5kICZxdW90O0VOQ09ESU5HIG1pbWUm cXVvdDsgYmVmb3JlIHRoZSAmcXVvdDtGSUxFJnF1b3Q7CiAgICAgIGNvbW1hbmQuICBUbyBkZWNv ZGUgdGhlIHJlc3BvbnNlKHMpLCB5b3Ugd2lsbCBuZWVkICZxdW90O211bnBhY2smcXVvdDsgb3IK ICAgICAgYSBNSU1FLWNvbXBsaWFudCBtYWlsIHJlYWRlci4gIERpZmZlcmVudCBNSU1FLWNvbXBs aWFudCBtYWlsIHJlYWRlcnMKICAgICAgZXhoaWJpdCBkaWZmZXJlbnQgYmVoYXZpb3IsIGVzcGVj aWFsbHkgd2hlbiBkZWFsaW5nIHdpdGgKICAgICAgJnF1b3Q7bXVsdGlwYXJ0JnF1b3Q7IE1JTUUg bWVzc2FnZXMgKGkuZS4gZG9jdW1lbnRzIHdoaWNoIGhhdmUgYmVlbiBzcGxpdAogICAgICB1cCBp bnRvIG11bHRpcGxlIG1lc3NhZ2VzKSwgc28gY2hlY2sgeW91ciBsb2NhbCBkb2N1bWVudGF0aW9u IG9uCiAgICAgIGhvdyB0byBtYW5pcHVsYXRlIHRoZXNlIG1lc3NhZ2VzLjwvcHJlPjxicj48cHJl IHN0eWxlPSJNQVJHSU46IDBlbSI+PGJyPkJlbG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5h YmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXIKaW1wbGVtZW50YXRpb24gdG8gYXV0b21h dGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGUKSW50ZXJuZXQtRHJhZnQu PC9wcmU+PGJyPjxwcmUgc3R5bGU9Ik1BUkdJTjogMGVtIj48YnI+PC9wcmU+PGJyPjxwcmUgc3R5 bGU9Ik1BUkdJTjogMGVtIj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdApJLUQtQW5ub3VuY2UgYXQgPGEg aHJlZj0iaHR0cDovL2lldGYub3JnIj5pZXRmLm9yZzwvYT4KPGEgaHJlZj0iaHR0cHM6Ly93d3cx LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlIj5odHRwczovL3d3dzEuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8L2E+CjwvcHJlPjwvZGl2Pgo= ------=_Part_43192_21193324.1151309459430-- --===============1913948670== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1913948670==-- From mip4-bounces@ietf.org Mon Jun 26 04:24:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumOW-0004Jf-SD; Mon, 26 Jun 2006 04:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FumOV-0004JZ-KV for mip4@ietf.org; Mon, 26 Jun 2006 04:24:31 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FumOT-00009P-8k for mip4@ietf.org; Mon, 26 Jun 2006 04:24:31 -0400 Received: by wr-out-0506.google.com with SMTP id i34so1080424wra for ; Mon, 26 Jun 2006 01:24:29 -0700 (PDT) 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=aj3WJCkE6n/hx7zXMkSD9cyaJmVe3GoBBzRasqumTDPDdngU78s15oJeQ8NS9jq9QmmqIH5cJuuoCdVFVtGQy4NULRjjGsbmvMuUBtazcrl0NLKrd6f1FdmboVEOpnMgJF6KQoDSfNlIxDxBpRbJ7eimGiKKI0OiU1W+FAVTamQ= Received: by 10.65.219.7 with SMTP id w7mr4569125qbq; Mon, 26 Jun 2006 01:24:28 -0700 (PDT) Received: by 10.64.250.14 with HTTP; Mon, 26 Jun 2006 01:24:28 -0700 (PDT) Message-ID: Date: Mon, 26 Jun 2006 16:24:28 +0800 From: Owen.Lai To: "zhen cao" Subject: Re: [Mip4] Re: Fwd: I-D ACTION:draft-lai-mip4-proxy-sequence-problem-00.txt In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0199377784==" Errors-To: mip4-bounces@ietf.org --===============0199377784== Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGksIFpoZW4sCgpUaGFua3MgZm9yIHlvdXIgcXVlc3Rpb24hCgpXZSBtYWRlIG1pc3Rha2UgYmVm b3JlLCB0aGlzIGlzIGludGVyY2VwdGlvbiBwcm9ibGVtIG90aGVyIHRoYW4KYW50aS1yZXBsYXkg cHJvYmxlbS4KCkFsbCB0aGUgYmVzdAoKU2hvdXdlbgoKCgrU2iAwNi02LTI2o6x6aGVuIGNhbzxj YW96aGVucGt1QGdtYWlsLmNvbT4g0LS1wKO6Cj4KPiBIaSwgU2hvdXdlbgo+Cj4gICAgICBJIGhh dmUgb25lIHF1ZXN0aW9uIGFib3V0IHlvdXIgZHJhZnQ6Cj4KPiAgICAgIElzbid0IHRpbWVzdGFt cCBpbiBpZGVudGlmaWNhdGlvbiBvZiBycnEgd2lsbCBiZSB1c2VkIGZvciBhbnRpLXJlcGx5Pwo+ Cj4gTWFueSB0aGFua3MsCj4gWmhlbgo+Cj4KPiAtLS0tLS0tLS0tLS1PcmlnaW5hbAo+IE1lc3Nh Z2UtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IEhpIGZvbGtzLAo+Cj4gV2UndmUg cHVibGlzaGVkIGEgbmV3IGRyYWZ0LCAiUHJvYmxlbSBvZiBSZXBsYXkgUHJvdGVjdGlvbiBVc2lu ZwpTZXF1ZW5jZQo+IE51bWJlciBpbiBQcm94eSBNb2JpbGUgSVB2NCIuCj4KPiBUaGUgZG9jdW1l bnQgcHJlc2VudHMgdGhlIHByb2JsZW1zIG9mIHJlcGxheSBwcm90ZWN0aW9uIHVzaW5nCj4gc2Vx dWVuY2UKbnVtYmVyIGluIHByb3h5IE1vYmlsZSBJUHY0IHNvbHV0aW9uLiBUaGUgc2VxdWVuY2Ug bnVtYmVyCj4gY2Fubm90CnByZXZlbnQgcmVnaXN0cmF0aW9uIG1lc3NhZ2UgZnJvbSByZXBsYXkg YXR0YWNrLgo+Cj4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLgo+Cj4gVGhhbmtzLApTaG91d2Vu LAo+Cj4KPiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS0gRnJvbTogSW50 ZXJuZXQtRHJhZnRzIGF0IGlldGYub3JnCj4gPEludGVybmV0LURyYWZ0cyBhdCBpZXRmLm9yZz4g RGF0ZTogMjAwNi02LTIzIMnPzuc2OjUwIFN1YmplY3Q6IEktRAo+IEFDVElPTjpkcmFmdC1sYWkt bWlwNC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dAo+IFRvOiBpLWQtYW5ub3VuY2UgYXQg aWV0Zi5vcmcKPgo+Cj4KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMKPiBkaXJlY3Rvcmllcy4KPgo+Cj4gIFRpdGxlIDog UHJvYmxlbSBvZiBSZXBsYXkgUHJvdGVjdGlvbiBVc2luZyBTZXF1ZW5jZQpOdW1iZXIgaW4gUHJv eHkgTW9iaWxlCj4gSVB2NAogQXV0aG9yKHMpIDogUy4gTGFpLCBILiBEZW5nCiBGaWxlbmFtZSA6 Cj4gZHJhZnQtbGFpLW1pcDQtcHJveHktc2VxdWVuY2UtcHJvYmxlbS0wMC50eHQKIFBhZ2VzIDog Nwo+IERhdGUgOiAyMDA2LTYtMjIKPgo+ICBUaGUgZG9jdW1lbnQgcHJlc2VudHMgdGhlIHByb2Js ZW1zIG9mIHJlcGxheSBwcm90ZWN0aW9uIHVzaW5nCiBzZXF1ZW5jZQo+IG51bWJlciBpbiBwcm94 eSBNb2JpbGUgSVB2NCBzb2x1dGlvbi4gVGhlIHNlcXVlbmNlIG51bWJlcgogY2Fubm90IHByZXZl bnQKPiByZWdpc3RyYXRpb24gbWVzc2FnZSBmcm9tIHJlcGxheSBhdHRhY2suCj4KPgo+IEEgVVJM IGZvciB0aGlzIEludGVybmV0LURyYWZ0Cj4gaXM6Cmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWxhaS1taXA0LXByb3h5LXNlcXVlbmNlLXByb2JsZW0tMDAudHh0Cj4K PiBUbyByZW1vdmUgeW91cnNlbGYgZnJvbSB0aGUgSS1EIEFubm91bmNlbWVudCBsaXN0LCBzZW5k IGEgbWVzc2FnZQo+IHRvCmktZC1hbm5vdW5jZS1yZXF1ZXN0IGF0IGlldGYub3JnIHdpdGggdGhl IHdvcmQgdW5zdWJzY3JpYmUgaW4gdGhlIGJvZHkKPiBvZgp0aGUgbWVzc2FnZS4KWW91IGNhbiBh bHNvIHZpc2l0Cj4gaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vSS1ELWFu bm91bmNlCj4gdG8gY2hhbmdlIHlvdXIgc3Vic2NyaXB0aW9uIHNldHRpbmdzLgo+Cj4KPgo+IElu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUC4gTG9naW4g d2l0aCB0aGUKPiB1c2VybmFtZQoiYW5vbnltb3VzIiBhbmQgYSBwYXNzd29yZCBvZiB5b3VyIGUt bWFpbCBhZGRyZXNzLiBBZnRlciBsb2dnaW5nCj4gaW4sCnR5cGUgImNkIGludGVybmV0LWRyYWZ0 cyIgYW5kIHRoZW4KICJnZXQKPiBkcmFmdC1sYWktbWlwNC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVt LTAwLnR4dCIuCj4KPiBBIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzIGNhbiBi ZSBmb3VuZAo+IGluCmh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwKb3IKPiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dAo+Cj4KPiBJbnRlcm5ldC1EcmFmdHMg Y2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLgo+Cj4gU2VuZCBhIG1lc3NhZ2UgdG86CiBt YWlsc2VydiBhdCBpZXRmLm9yZy4KSW4gdGhlIGJvZHkgdHlwZToKICJGSUxFCj4gL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1sYWktbWlwNC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dCIuCj4K PiBOT1RFOiBUaGUgbWFpbCBzZXJ2ZXIgYXQgaWV0Zi5vcmcgY2FuIHJldHVybiB0aGUgZG9jdW1l bnQgaW4KIE1JTUUtZW5jb2RlZAo+IGZvcm0gYnkgdXNpbmcgdGhlICJtcGFjayIgdXRpbGl0eS4g VG8gdXNlIHRoaXMKIGZlYXR1cmUsIGluc2VydCB0aGUgY29tbWFuZAo+ICJFTkNPRElORyBtaW1l IiBiZWZvcmUgdGhlICJGSUxFIgogY29tbWFuZC4gVG8gZGVjb2RlIHRoZSByZXNwb25zZShzKSwg eW91Cj4gd2lsbCBuZWVkICJtdW5wYWNrIiBvcgogYSBNSU1FLWNvbXBsaWFudCBtYWlsIHJlYWRl ci4gRGlmZmVyZW50Cj4gTUlNRS1jb21wbGlhbnQgbWFpbCByZWFkZXJzCiBleGhpYml0IGRpZmZl cmVudCBiZWhhdmlvciwgZXNwZWNpYWxseSB3aGVuCj4gZGVhbGluZyB3aXRoCiAibXVsdGlwYXJ0 IiBNSU1FIG1lc3NhZ2VzIChpLmUuIGRvY3VtZW50cyB3aGljaCBoYXZlIGJlZW4KPiBzcGxpdAog dXAgaW50byBtdWx0aXBsZSBtZXNzYWdlcyksIHNvIGNoZWNrIHlvdXIgbG9jYWwgZG9jdW1lbnRh dGlvbiBvbgogaG93Cj4gdG8gbWFuaXB1bGF0ZSB0aGVzZSBtZXNzYWdlcy4KPgo+Cj4gQmVsb3cg aXMgdGhlIGRhdGEgd2hpY2ggd2lsbCBlbmFibGUgYSBNSU1FIGNvbXBsaWFudCBtYWlsCj4gcmVh ZGVyCmltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZl cnNpb24gb2YKPiB0aGUKSW50ZXJuZXQtRHJhZnQuCj4KPgo+Cj4KPgo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkktRC1Bbm5vdW5jZQo+IG1haWxpbmcg bGlzdApJLUQtQW5ub3VuY2UgYXQgaWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UKPgo+Cj4gLS0KPiBNaXA0IG1haWxpbmcgbGlzdDog TWlwNEBpZXRmLm9yZwo+ICAgIFdlYiBpbnRlcmZhY2U6Cj4gaHR0cHM6Ly93d3cxLmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbWlwNAo+ICAgICBDaGFydGVyIHBhZ2U6Cj4gaHR0cDovL3d3dy5p ZXRmLm9yZy9odG1sLmNoYXJ0ZXJzL21pcDQtY2hhcnRlci5odG1sCj4gU3VwcGxlbWVudGFsIHNp dGU6IGh0dHA6Ly93d3cubWlwNC5vcmcvCj4KPgo+Cg== --===============0199377784== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0199377784==-- From mip4-bounces@ietf.org Mon Jun 26 06:15:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuo87-0007QA-6B; Mon, 26 Jun 2006 06:15:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuo85-0007L6-F7 for mip4@ietf.org; Mon, 26 Jun 2006 06:15:41 -0400 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 1Fun8A-0002zl-Ev for mip4@ietf.org; Mon, 26 Jun 2006 05:11:42 -0400 Received: from kcout02.prserv.net ([12.154.55.32]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fun0A-0002ep-3t for mip4@ietf.org; Mon, 26 Jun 2006 05:03:26 -0400 Received: from attglobal.net (p6045-ipbffx02miyazaki.miyazaki.ocn.ne.jp[125.200.180.109]) by prserv.net (kcout02) with SMTP id <20060626084804202005ob33e> (Authid: sebastn); Mon, 26 Jun 2006 08:48:19 +0000 X-Originating-IP: [125.200.180.109] Message-ID: <449F9F3F.8080906@attglobal.net> Date: Mon, 26 Jun 2006 03:47:59 -0500 From: Sebastian Thalanany User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Yoshi Tsuda (yotsuda)" Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails References: <35912544FC930E49BF20EF16C3EF2765012CC24C@xmb-hkg-416.apac.cisco.com> In-Reply-To: <35912544FC930E49BF20EF16C3EF2765012CC24C@xmb-hkg-416.apac.cisco.com> X-Spam-Score: -2.6 (--) X-Scan-Signature: ec9c506f029e38d2a6e7b00bc7714181 Cc: "Chowdhury, Kuntal" , Mobile IPv4 Mailing List , "Venkateshwara Sastry \(vsastry\)" , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0920483691==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0920483691== Content-Type: multipart/alternative; boundary="------------040701060000070104040802" This is a multi-part message in MIME format. --------------040701060000070104040802 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Yoshi, Good points in this thread pertaining to the behavior associated with Code 131. A silent discard of the RRP, at the MN, in the case of Code 131 is reasonable to avoid further RRQs that do not contain the MHAE. However, if an RRP containing Code 131 was generated by the HA, it is possible that it is a result of a corruption of the original RRQ, over the wireless link. In this case it is reasonable for the MN to use the receipt of an RRP with Code 131 to trigger a new RRP. A configurable counter could be maintained at the HA to restrict the number of repeated RRPs with a Code 131 for the same MN. Thanks. Regards, Sebastian Yoshi Tsuda (yotsuda) wrote: >Hi Sastry, > > Oh, I see. Thank you for your pointing out the case. > Then, I should have written the conditions like the following: > a) An MN should stop sending RRQs, > a-1) if it receives an RRP with 131, > a-2) and if auth check fails, > a-3) and if the MN has sent the original RRQ. > <- This might be caused due to key differences between > an HA and an MN. But, according to the current rfc3344, > an MN can continue sending such RRQs. > > b) An MN can re-send an RRQ, > b-1) if the MN receives an RRP with 131, > b-2) and if auth check succeeds, > b-3) and if the MN has sent the original RRQ. > <- This might be caused due to a corrupted RRQ. > > This kind of description about error handling, other than 69, > 133, 136 and so on, isn't so clear in rfc3344, I'm afraid. > >Best regards. >-Yoshi > > > >>-----Original Message----- >>From: Venkateshwara Sastry (vsastry) >>Sent: Monday, June 26, 2006 3:57 PM >>To: Yoshi Tsuda (yotsuda); 'Avi Lior'; 'Chowdhury, Kuntal' >>Cc: 'Mobile IPv4 Mailing List' >>Subject: RE: [Mip4] 3344 Sending a Reg Reply when the >>Authenticator fails >> >>IMHO, if RRQ authentication failed at HA(may be packet was >>corrupted when received by HA), and HA HAS a SA with that MN, >>the HA can send an RRP with MHAE and error code 131. In such >>a sceanrio, there is a possibility that MN can authenticate >>the RRP and continue further processing. >> >>Regards >>Sastry >> >> >> >>>-----Original Message----- >>>From: Yoshi Tsuda (yotsuda) >>>Sent: Monday, June 26, 2006 10:31 AM >>>To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal >>>Cc: Mobile IPv4 Mailing List >>>Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator >>>fails >>> >>>Hi Avi and all, >>> >>> Good point. >>> >>> Personally, I believe, an MN should stop sending RRQs, if it >>>receives an RRP with 131, and if the MN has sent the >>> >>> >>original RRQ in >> >> >>>spite of the meaning of "silently discard". >>> The term, "silently discard" found to be used in rfc2002, >>> >>> >>too; so it >> >> >>>might have a histrical reason, though... >>> >>> Also, I agree with Kuntal that error handlings haven't been well >>>documented. If this causes deployment issues, should we >>> >>> >>have a new >> >> >>>I-D about handling codes or ask modifications of rfc3344 to the >>>inventor of MIP? >>> >>>Thanks. >>>-Yoshi >>> >>> >>> >>>>-----Original Message----- >>>>From: Avi Lior [mailto:avi@bridgewatersystems.com] >>>>Sent: Monday, June 26, 2006 8:38 AM >>>>To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal >>>>Cc: Mobile IPv4 Mailing List >>>>Subject: RE: [Mip4] 3344 Sending a Reg Reply when the >>>> >>>> >>Authenticator >> >> >>>>fails >>>> >>>>I think the protocol does allow an HA to respond with an >>>> >>>> >>>auth failure. >>> >>> >>>>Code 131 was designed for that no? >>>> >>>>However, as you point out an MN receiving a RRP which fails >>>> >>>> >>>its auth >>> >>> >>>>check MUST silently discard. Silently discard means no more >>>>processing. Does that mean that the MN is not allowed to use the >>>>receipt of the RRP to stop sending any further RRQs? Some >>>> >>>> >>>would say >>> >>> >>>>yes. >>>> >>>>Therefore, why allow the HA to send an RRP when clearly >>>> >>>> >>the MN will >> >> >>>>silently discard it? >>>> >>>>Is this a contradiction or is it by design? >>>> >>>> >>>> >>>> >>>> >>>>________________________________ >>>> >>>> From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com] >>>> Sent: Friday, June 23, 2006 4:19 PM >>>> To: Chowdhury, Kuntal; Avi Lior >>>> Cc: Mobile IPv4 Mailing List >>>> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the >>>> >>>> >>>Authenticator >>> >>> >>>>fails >>>> >>>> >>>> We can not really claim that current protocol allows HA >>>> >>>> >>>to respond on >>> >>> >>>>auth failure. If HA responding on auth failure was really the >>>>intention of the designers, silently discarding such >>>> >>>> >>>packets by MN as >>> >>> >>>>indicated in following text does not make sense. >>>> b) If the Code field indicates that service is >>>> >>>> >>>denied by the >>> >>> >>>>home >>>> agent, or if the Code field indicates that the >>>> >>>> >>>registration >>> >>> >>>>was >>>> accepted by the home agent, exactly one Mobile-Home >>>> Authentication Extension MUST be present in >>>> >>>> >>>the Registration >>> >>> >>>> Reply, and the mobile node MUST check the >>>> >>>> >>>Authenticator >>> >>> >>>>value >>>> in the Extension. If the Registration Reply >>>> >>>> >>>was generated >>> >>> >>>>by >>>> the home agent but no Mobile-Home >>>> >>>> >>>Authentication Extension >>> >>> >>>>is >>>> found, or if more than one Mobile-Home Authentication >>>>Extension >>>> is found, or if the Authenticator is invalid, >>>> >>>> >>>the mobile >>> >>> >>>>node >>>> MUST silently discard the Reply and SHOULD log >>>> >>>> >>>the event as >>> >>> >>>>a >>>> security exception. >>>> >>>> Regards >>>> Sastry >>>> >>>> >>>>________________________________ >>>> >>>> From: Chowdhury, Kuntal >>>>[mailto:kchowdhury@starentnetworks.com] >>>> Sent: Friday, June 23, 2006 4:56 AM >>>> To: Avi Lior >>>> Cc: Mobile IPv4 Mailing List >>>> Subject: RE: [Mip4] 3344 Sending a Reg Reply >>>> >>>> >>>when the Authenticator >>> >>> >>>>fails >>>> >>>> >>>> >>>> Avi, >>>> >>>> >>>> >>>> If a rogue MN can break into the network (i.e. >>>>pass access auth), anything is possible. However, by >>>> >>>> >>>putting multiple >>> >>> >>>>levels of auth (at least 1 or 2); the operators make this >>>> >>>> >>>possibility >>> >>> >>>>extremely slim. So, let's not get hung-up with the fact >>>> >>>> >>>that rouge MNs >>> >>> >>>>can do bad things. >>>> >>>> >>>> >>>> The issue is simple: if the auth of a RRQ >>>> >>>> >>>fails, should the HA >>> >>> >>>>respond back to the MN? There are some people who believe a >>>> >>>> >>>response >>> >>> >>>>should be sent. There are some who believe that the HA >>>> >>>> >>>should silently >>> >>> >>>>discard the packet. >>>> >>>> >>>> >>>> In this context, the current mip4 protocol >>>> >>>> >>>allows the HA to send a >>> >>> >>>>response upon auth failure. The current text also allows those HA >>>>implementations which like to silently discard the packet. >>>> >>>> >>>So, let's >>> >>> >>>>not change the protocol as it allows both the >>>>behaviors/implementations. We can just clarify some text to >>>> >>>> >>>describe >>> >>> >>>>how the response packet is formatted. >>>> >>>> >>>> >>>> -Kuntal >>>> >>>> >>>> >>>> >>>> >>>> > > > --------------040701060000070104040802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Yoshi,

                Good points in this thread pertaining to the behavior associated with Code 131.

                A silent discard of the RRP, at the MN, in the case of Code 131 is reasonable to avoid further RRQs that do not contain the MHAE.

                However, if an RRP containing Code 131 was generated by the HA, it is possible that it is a result of a corruption of the original RRQ, over the wireless link. In this case it is reasonable for the MN to use the receipt of an RRP with Code 131 to trigger a new RRP. A configurable counter could be maintained at the HA to restrict the number of repeated RRPs with a Code 131 for the same MN.

                 Thanks.

Regards,
    Sebastian

   

   



Yoshi Tsuda (yotsuda) wrote:
Hi Sastry,

 Oh, I see.  Thank you for your pointing out the case.
 Then, I should have written the conditions like the following:
 a) An MN should stop sending RRQs,
 a-1) if it receives an RRP with 131,
 a-2) and if auth check fails,
 a-3) and if the MN has sent the original RRQ.
 <- This might be caused due to key differences between
     an HA and an MN.  But, according to the current rfc3344,
     an MN can continue sending such RRQs.

 b) An MN can re-send an RRQ,
 b-1) if the MN receives an RRP with 131,
 b-2) and if auth check succeeds,
 b-3) and if the MN has sent the original RRQ.
 <- This might be caused due to a corrupted RRQ.

 This kind of description about error handling, other than 69,
 133, 136 and so on, isn't so clear in rfc3344, I'm afraid.

Best regards.
-Yoshi

  
-----Original Message-----
From: Venkateshwara Sastry (vsastry) 
Sent: Monday, June 26, 2006 3:57 PM
To: Yoshi Tsuda (yotsuda); 'Avi Lior'; 'Chowdhury, Kuntal'
Cc: 'Mobile IPv4 Mailing List'
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the 
Authenticator fails

IMHO, if RRQ authentication failed at HA(may be packet was 
corrupted when received by HA), and HA HAS a SA with that MN, 
the HA can send an RRP with MHAE and error code 131. In such 
a sceanrio, there is a possibility that MN can authenticate 
the RRP and continue further processing.

Regards
Sastry

    
-----Original Message-----
From: Yoshi Tsuda (yotsuda)
Sent: Monday, June 26, 2006 10:31 AM
To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator 
fails

Hi Avi and all,

 Good point.

 Personally, I believe, an MN should stop sending RRQs,  if it 
receives an RRP with 131, and if the MN has sent the 
      
original RRQ in 
    
spite of the meaning of "silently discard".
 The term, "silently discard" found to be used in rfc2002, 
      
too; so it 
    
might have a histrical reason, though...

 Also, I agree with Kuntal that error handlings haven't been well 
documented.  If this causes deployment issues,  should we 
      
have a new 
    
I-D about handling codes or ask  modifications of rfc3344 to the 
inventor of MIP?

Thanks.
-Yoshi

      
-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Monday, June 26, 2006 8:38 AM
To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the 
        
Authenticator 
    
fails

I think the protocol does allow an HA to respond with an
        
auth failure.  
      
Code 131 was designed for that no?
 
However, as you point out an MN receiving a RRP which fails
        
its auth
      
check MUST silently discard.  Silently discard means no more 
processing.  Does that mean that the MN is not allowed to use the 
receipt of the RRP to stop sending any further RRQs?  Some
        
would say
      
yes.
 
Therefore, why allow the HA to send an RRP when clearly 
        
the MN will 
    
silently discard it?
 
Is this a contradiction or is it by design?
 
 



________________________________

	From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com] 
	Sent: Friday, June 23, 2006 4:19 PM
	To: Chowdhury, Kuntal; Avi Lior
	Cc: Mobile IPv4 Mailing List
	Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
        
Authenticator
      
fails
	
	
	We can not really claim that current protocol allows HA
        
to respond on
      
auth failure. If HA responding on auth failure was really the 
intention of the designers, silently discarding such
        
packets by MN as
      
indicated in following text does not make sense.
	      b) If the Code field indicates that service is
        
denied by the
      
home
	         agent, or if the Code field indicates that the
        
registration
      
was
	         accepted by the home agent, exactly one Mobile-Home
	         Authentication Extension MUST be present in
        
the Registration
      
	         Reply, and the mobile node MUST check the
        
Authenticator
      
value
	         in the Extension.  If the Registration Reply
        
was generated
      
by
	         the home agent but no Mobile-Home
        
Authentication Extension
      
is
	         found, or if more than one Mobile-Home Authentication 
Extension
	         is found, or if the Authenticator is invalid,
        
the mobile
      
node
	         MUST silently discard the Reply and SHOULD log
        
the event as
      
a
	         security exception.
	
	Regards
	Sastry


________________________________

		From: Chowdhury, Kuntal
[mailto:kchowdhury@starentnetworks.com] 
		Sent: Friday, June 23, 2006 4:56 AM
		To: Avi Lior
		Cc: Mobile IPv4 Mailing List
		Subject: RE: [Mip4] 3344 Sending a Reg Reply
        
when the Authenticator
      
fails
		
		

		Avi,

		 

		If a rogue MN can break into the network (i.e. 
pass access auth), anything is possible. However, by
        
putting multiple
      
levels of auth (at least 1 or 2); the operators make this
        
possibility
      
extremely slim. So, let's not get hung-up with the fact
        
that rouge MNs
      
can do bad things.

		 

		The issue is simple: if the auth of a RRQ
        
fails, should the HA
      
respond back to the MN? There are some people who believe a
        
response
      
should be sent. There are some who believe that the HA
        
should silently
      
discard the packet.

		 

		In this context, the current mip4 protocol
        
allows the HA to send a
      
response upon auth failure. The current text also allows those HA 
implementations which like to silently discard the packet.
        
So, let's
      
not change the protocol as it allows both the 
behaviors/implementations. We can just clarify some text to
        
describe
      
how the response packet is formatted.

		 

		-Kuntal
--------------040701060000070104040802-- --===============0920483691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0920483691==-- From mip4-bounces@ietf.org Mon Jun 26 07:19:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fup89-0001hk-QX; Mon, 26 Jun 2006 07:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fup88-0001hf-2o for mip4@ietf.org; Mon, 26 Jun 2006 07:19:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fup85-0006JW-FP for mip4@ietf.org; Mon, 26 Jun 2006 07:19:48 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 26 Jun 2006 04:19:44 -0700 X-IronPort-AV: i="4.06,175,1149490800"; d="scan'208"; a="300878765:sNHT36459536" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k5QBJiim005259; Mon, 26 Jun 2006 04:19:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k5QBJhIs029359; Mon, 26 Jun 2006 04:19:43 -0700 (PDT) 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.211); Mon, 26 Jun 2006 04:19:43 -0700 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: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Mon, 26 Jun 2006 04:19:36 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202062C39@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQAGbdTjAAKkQB4AAEtz3QAAkuDjA= From: "Kent Leung \(kleung\)" To: "Venkateshwara Sastry \(vsastry\)" , "Yoshi Tsuda \(yotsuda\)" , "Avi Lior" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 26 Jun 2006 11:19:43.0106 (UTC) FILETIME=[6C3D5E20:01C69912] DKIM-Signature: a=rsa-sha1; q=dns; l=6499; t=1151320784; x=1152184784; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=203344=20Sending=20a=20Reg=20Reply=20when=20the=20Authent icator=20fails; X=v=3Dcisco.com=3B=20h=3DOffBF2QDuGm/mTFCreg6jJ5NNKI=3D; b=QMgQqkcJsG4wtiwP7jAcQRVRBxNb9SzMq4DYFTAGdGsPqmzXeLN9G0Wi+SSdWNSpK5iGU+ri m8StjILwmbqFTaAK4jEZP0g3VQI+MJioDmcZ74S6NaByOCP23Y08xPSL; Authentication-Results: sj-dkim-6.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org That's been my point. HA sends the RRP with MHAE when it _has_ an SA with the MN. So if administrator wants the HA to be able to inform the MN that the registration SA (key) is wrong, then set up a default SA to communicate this event securely. This mechanism would be already covered in current RFC 3344 without protocol changes. Kent=20 > -----Original Message----- > From: Venkateshwara Sastry (vsastry)=20 > Sent: Sunday, June 25, 2006 11:57 PM > To: Yoshi Tsuda (yotsuda); Avi Lior; Chowdhury, Kuntal > Cc: Mobile IPv4 Mailing List > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator fails >=20 >=20 > IMHO, if RRQ authentication failed at HA(may be packet was=20 > corrupted when received by HA), and HA HAS a SA with that MN,=20 > the HA can send an RRP with MHAE and error code 131. In such=20 > a sceanrio, there is a possibility that MN can authenticate=20 > the RRP and continue further processing. >=20 > Regards > Sastry >=20 > > -----Original Message----- > > From: Yoshi Tsuda (yotsuda) > > Sent: Monday, June 26, 2006 10:31 AM > > To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal > > Cc: Mobile IPv4 Mailing List > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator=20 > > fails > >=20 > > Hi Avi and all, > >=20 > > Good point. > >=20 > > Personally, I believe, an MN should stop sending RRQs, if it=20 > > receives an RRP with 131, and if the MN has sent the=20 > original RRQ in=20 > > spite of the meaning of "silently discard". > > The term, "silently discard" found to be used in rfc2002,=20 > too; so it=20 > > might have a histrical reason, though... > >=20 > > Also, I agree with Kuntal that error handlings haven't been well=20 > > documented. If this causes deployment issues, should we=20 > have a new=20 > > I-D about handling codes or ask modifications of rfc3344 to the=20 > > inventor of MIP? > >=20 > > Thanks. > > -Yoshi > >=20 > > > -----Original Message----- > > > From: Avi Lior [mailto:avi@bridgewatersystems.com] > > > Sent: Monday, June 26, 2006 8:38 AM > > > To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal > > > Cc: Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 > Authenticator=20 > > > fails > > >=20 > > > I think the protocol does allow an HA to respond with an > > auth failure. =20 > > > Code 131 was designed for that no? > > > =20 > > > However, as you point out an MN receiving a RRP which fails > > its auth > > > check MUST silently discard. Silently discard means no more=20 > > > processing. Does that mean that the MN is not allowed to use the=20 > > > receipt of the RRP to stop sending any further RRQs? Some > > would say > > > yes. > > > =20 > > > Therefore, why allow the HA to send an RRP when clearly=20 > the MN will=20 > > > silently discard it? > > > =20 > > > Is this a contradiction or is it by design? > > > =20 > > > =20 > > >=20 > > >=20 > > >=20 > > > ________________________________ > > >=20 > > > From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]=20 > > > Sent: Friday, June 23, 2006 4:19 PM > > > To: Chowdhury, Kuntal; Avi Lior > > > Cc: Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] 3344 Sending a Reg Reply when the > > Authenticator > > > fails > > > =09 > > > =09 > > > We can not really claim that current protocol allows HA > > to respond on > > > auth failure. If HA responding on auth failure was really the=20 > > > intention of the designers, silently discarding such > > packets by MN as > > > indicated in following text does not make sense. > > > b) If the Code field indicates that service is > > denied by the > > > home > > > agent, or if the Code field indicates that the > > registration > > > was > > > accepted by the home agent, exactly one Mobile-Home > > > Authentication Extension MUST be present in > > the Registration > > > Reply, and the mobile node MUST check the > > Authenticator > > > value > > > in the Extension. If the Registration Reply > > was generated > > > by > > > the home agent but no Mobile-Home > > Authentication Extension > > > is > > > found, or if more than one Mobile-Home Authentication=20 > > > Extension > > > is found, or if the Authenticator is invalid, > > the mobile > > > node > > > MUST silently discard the Reply and SHOULD log > > the event as > > > a > > > security exception. > > > =09 > > > Regards > > > Sastry > > >=20 > > >=20 > > > ________________________________ > > >=20 > > > From: Chowdhury, Kuntal > > > [mailto:kchowdhury@starentnetworks.com]=20 > > > Sent: Friday, June 23, 2006 4:56 AM > > > To: Avi Lior > > > Cc: Mobile IPv4 Mailing List > > > Subject: RE: [Mip4] 3344 Sending a Reg Reply > > when the Authenticator > > > fails > > > =09 > > > =09 > > >=20 > > > Avi, > > >=20 > > > =20 > > >=20 > > > If a rogue MN can break into the network (i.e.=20 > > > pass access auth), anything is possible. However, by > > putting multiple > > > levels of auth (at least 1 or 2); the operators make this > > possibility > > > extremely slim. So, let's not get hung-up with the fact > > that rouge MNs > > > can do bad things. > > >=20 > > > =20 > > >=20 > > > The issue is simple: if the auth of a RRQ > > fails, should the HA > > > respond back to the MN? There are some people who believe a > > response > > > should be sent. There are some who believe that the HA > > should silently > > > discard the packet. > > >=20 > > > =20 > > >=20 > > > In this context, the current mip4 protocol > > allows the HA to send a > > > response upon auth failure. The current text also allows those HA=20 > > > implementations which like to silently discard the packet. > > So, let's > > > not change the protocol as it allows both the=20 > > > behaviors/implementations. We can just clarify some text to > > describe > > > how the response packet is formatted. > > >=20 > > > =20 > > >=20 > > > -Kuntal > > >=20 > > > =20 > > >=20 > > >=20 > >=20 >=20 > -- > Mip4 mailing list: Mip4@ietf.org > Web interface: https://www1.ietf.org/mailman/listinfo/mip4 > Charter page: http://www.ietf.org/html.charters/mip4-charter.html > Supplemental site: http://www.mip4.org/ >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 26 07:26:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FupEc-0006xZ-3z; Mon, 26 Jun 2006 07:26:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FupEa-0006xU-Tq for mip4@ietf.org; Mon, 26 Jun 2006 07:26:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FupEa-0006U1-EJ for mip4@ietf.org; Mon, 26 Jun 2006 07:26:28 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 26 Jun 2006 04:26:28 -0700 X-IronPort-AV: i="4.06,175,1149490800"; d="scan'208"; a="1832535756:sNHT34085826" 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 k5QBQRZ9006378; Mon, 26 Jun 2006 04:26:27 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5QBQR9s024422; Mon, 26 Jun 2006 04:26:27 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 04:26:27 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Subject: RE: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt Date: Mon, 26 Jun 2006 04:26:21 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202062C3C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt Thread-Index: AcaY+gRlzQVKShZ2S9y2SbL3ZwHdjwAGQEAw From: "Kent Leung \(kleung\)" To: "Owen.Lai" , "zhen cao" X-OriginalArrivalTime: 26 Jun 2006 11:26:27.0720 (UTC) FILETIME=[5D689080:01C69913] DKIM-Signature: a=rsa-sha1; q=dns; l=4598; t=1151321188; x=1152185188; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Re=3A=20Fwd=3A=20I-DACTION=3Adraft-lai-mip4-proxy-seque nce-problem-00.txt; X=v=3Dcisco.com=3B=20h=3Dq4wAokK0M5PUzQmf4MRNHlbV8HQ=3D; b=MWG6j5w7h8qk2ecXRnmbT6Vf9FbEWju6QfLFtZgCPluidAbE3Je4EhiHPvsPJ+e2z0EmIUe+ ZFAuE975d9GTDFJkYLETjRItgxpjHOqr+jWEhVgwVw16nr06fodBb1EF; Authentication-Results: sj-dkim-1.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: mip4@ietf.org X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Owen. As mentioned by Zhen, replay protection is provided by the ID field. The draft brings up replay attack as a problem for sequence number. So, not clear what you mean by interception problem? Can you explain more? Kent > -----Original Message----- > From: Owen.Lai [mailto:sumriver@gmail.com] > Sent: Monday, June 26, 2006 1:24 AM > To: zhen cao > Cc: mip4@ietf.org > Subject: Re: [Mip4] Re: Fwd: > I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt > > Hi, Zhen, > > Thanks for your question! > > We made mistake before, this is interception problem other > than anti-replay problem. > > All the best > > Shouwen > > > > $B:_(J 06-6-26$B!$(Jzhen cao $B > > > Hi, Shouwen > > > > I have one question about your draft: > > > > Isn't timestamp in identification of rrq will be used > for anti-reply? > > > > Many thanks, > > Zhen > > > > > > ------------Original > > Message-------------------------------- > > Hi folks, > > > > We've published a new draft, "Problem of Replay Protection Using > Sequence > > Number in Proxy Mobile IPv4". > > > > The document presents the problems of replay protection > using sequence > number in proxy Mobile IPv4 solution. The sequence number > > cannot > prevent registration message from replay attack. > > > > Any comments are welcome. > > > > Thanks, > Shouwen, > > > > > > ---------- Forwarded message ---------- From: Internet-Drafts at > > ietf.org Date: 2006-6-23 > $B>e8a(J6:50 Subject: > > I-D ACTION:draft-lai-mip4-proxy-sequence-problem-00.txt > > To: i-d-announce at ietf.org > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : Problem of Replay Protection Using Sequence > Number in Proxy Mobile > > IPv4 > Author(s) : S. Lai, H. Deng > Filename : > > draft-lai-mip4-proxy-sequence-problem-00.txt > Pages : 7 > > Date : 2006-6-22 > > > > The document presents the problems of replay protection using > sequence > > number in proxy Mobile IPv4 solution. The sequence number > cannot prevent > > registration message from replay attack. > > > > > > A URL for this Internet-Draft > > is: > http://www.ietf.org/internet-drafts/draft-lai-mip4-proxy-seque > nce-problem-00.txt > > > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request at ietf.org with the word unsubscribe in the body > > of > the message. > You can also visit > > https://www1.ietf.org/mailman/listinfo/I-D-announce > > to change your subscription settings. > > > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the > > username > "anonymous" and a password of your e-mail address. After logging > > in, > type "cd internet-drafts" and then > "get > > draft-lai-mip4-proxy-sequence-problem-00.txt". > > > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > > > Internet-Drafts can also be obtained by e-mail. > > > > Send a message to: > mailserv at ietf.org. > In the body type: > "FILE > > /internet-drafts/draft-lai-mip4-proxy-sequence-problem-00.txt". > > > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded > > form by using the "mpack" utility. To use this > feature, insert the command > > "ENCODING mime" before the "FILE" > command. To decode the response(s), you > > will need "munpack" or > a MIME-compliant mail reader. Different > > MIME-compliant mail readers > exhibit different behavior, especially when > > dealing with > "multipart" MIME messages (i.e. documents which have been > > split > up into multiple messages), so check your local documentation on how > > to manipulate these messages. > > > > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of > > the > Internet-Draft. > > > > > > > > > > > > _______________________________________________ > I-D-Announce > > mailing list > I-D-Announce at ietf.org > > https://www1.ietf.org/mailman/listinfo/i-d-announce > > > > > > -- > > Mip4 mailing list: Mip4@ietf.org > > Web interface: > > https://www1.ietf.org/mailman/listinfo/mip4 > > Charter page: > > http://www.ietf.org/html.charters/mip4-charter.html > > Supplemental site: http://www.mip4.org/ > > > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 26 07:31:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FupJ5-0002ZB-Ob; Mon, 26 Jun 2006 07:31:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FupJ4-0002YP-Ll for mip4@ietf.org; Mon, 26 Jun 2006 07:31:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FupJ4-0006b9-21 for mip4@ietf.org; Mon, 26 Jun 2006 07:31:06 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 26 Jun 2006 04:31:05 -0700 X-IronPort-AV: i="4.06,175,1149490800"; d="scan'208,217"; a="300882746:sNHT59452924" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5QBV5Dm006090; Mon, 26 Jun 2006 04:31:05 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k5QBV4CU023785; Mon, 26 Jun 2006 04:31:04 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 04:31:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Mon, 26 Jun 2006 04:30:56 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5202062C3E@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQAGbdTjAAOKAkcA== From: "Kent Leung \(kleung\)" To: "Avi Lior" , "Venkateshwara Sastry \(vsastry\)" , "Chowdhury, Kuntal" X-OriginalArrivalTime: 26 Jun 2006 11:31:04.0609 (UTC) FILETIME=[02727910:01C69914] DKIM-Signature: a=rsa-sha1; q=dns; l=7467; t=1151321465; x=1152185465; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=203344=20Sending=20a=20Reg=20Reply=20when=20the=20Authent icator=20fails; X=v=3Dcisco.com=3B=20h=3Dx7NPD4YqYf73jH3gK4mAzGt6TG0=3D; b=HDWNdbODTKWm/q6c1+rBcs5HWJPn7d9k7G7RAxVqKR6OjSfSXFxx9ZkY36gCxZNipQHU/HxC RzcVt11Asbj4HK/FYbyoujgDYXz4bFiZm407Xv+9PHm8CILI3qPiSfOp; Authentication-Results: sj-dkim-2.cisco.com; header.From=kleung@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0629326442==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0629326442== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69914.021A4063" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69914.021A4063 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, 131 is the error code indicating the authentication failed. As Sastry pointed out, this could be the case that data corruption occurred along the way. So when HA has an SA, it should send the RRP which is protected by MHAE. In this case, MN can authenticate the message properly. =20 For example, let's say there are 2 SAs between MN and HA. If HA fails to authenticate the RRQ, it would be wise for HA to use the other SA to send the RRP. =20 Kent ________________________________ From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Sunday, June 25, 2006 4:38 PM To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =09 =09 I think the protocol does allow an HA to respond with an auth failure. Code 131 was designed for that no? =20 However, as you point out an MN receiving a RRP which fails its auth check MUST silently discard. Silently discard means no more processing. Does that mean that the MN is not allowed to use the receipt of the RRP to stop sending any further RRQs? Some would say yes. =20 Therefore, why allow the HA to send an RRP when clearly the MN will silently discard it? =20 Is this a contradiction or is it by design? =20 =20 ------_=_NextPart_001_01C69914.021A4063 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes, 131 is the error code indicating the = authentication=20 failed.  As Sastry pointed out, this could be the case that data = corruption=20 occurred along the way.  So when HA has an SA, it should send the = RRP which=20 is protected by MHAE.  In this case, MN can authenticate the = message=20 properly.
 
For example, let's say there are 2 SAs between = MN and=20 HA.  If HA fails to authenticate the RRQ, it would be wise for HA = to use=20 the other SA to send the RRP.
 
Kent

From: Avi Lior=20 [mailto:avi@bridgewatersystems.com]
Sent: Sunday, June 25, = 2006=20 4:38 PM
To: Venkateshwara Sastry (vsastry); Chowdhury,=20 Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: = [Mip4]=20 3344 Sending a Reg Reply when the Authenticator = fails

I think the protocol does allow an HA to = respond with an=20 auth failure.  Code 131 was designed for that = no?
 
However, as you point out an MN receiving a RRP which fails = its auth=20 check MUST silently discard.  Silently discard means no more=20 processing.  Does that mean that the MN is not allowed to use the = receipt=20 of the RRP to stop sending any further RRQs?  Some would say = yes.
 
Therefore, why allow the HA to send an RRP when clearly the = MN will=20 silently discard it?
 
Is=20 this a contradiction or is it by design?
 
<snip> 
------_=_NextPart_001_01C69914.021A4063-- --===============0629326442== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0629326442==-- From mip4-bounces@ietf.org Mon Jun 26 09:14:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqvE-0000Pt-N5; Mon, 26 Jun 2006 09:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FuqvD-0000JU-PX for mip4@ietf.org; Mon, 26 Jun 2006 09:14:35 -0400 Received: from kcout01.prserv.net ([12.154.55.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FuqvB-0007cq-3T for mip4@ietf.org; Mon, 26 Jun 2006 09:14:35 -0400 Received: from attglobal.net (unknown[218.224.253.40]) by prserv.net (kcout01) with SMTP id <2006062613142820100ld1fne> (Authid: sebastn); Mon, 26 Jun 2006 13:14:32 +0000 X-Originating-IP: [218.224.253.40] Message-ID: <449FDD88.7040706@attglobal.net> Date: Mon, 26 Jun 2006 08:13:44 -0500 From: Sebastian Thalanany User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Kent Leung (kleung)" Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails References: <2979E38DD6FC6544B789C8DAD7BAFC5202062C39@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5202062C39@xmb-sjc-235.amer.cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5e12d21a4de46ba01a82feaa82469733 Cc: Mobile IPv4 Mailing List , "Chowdhury, Kuntal" , "Yoshi Tsuda \(yotsuda\)" , "Venkateshwara Sastry \(vsastry\)" , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1629886797==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============1629886797== Content-Type: multipart/alternative; boundary="------------010503070006020208000203" This is a multi-part message in MIME format. --------------010503070006020208000203 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Kent, If the corruption of the RRQ has occurred, as a result of a loss of integrity of the wireless link (MN and HA have a security association), then the RRP with a Code 131 should be processed (not limited to discarding and error logging) further by the MN to re-send an RRQ. To accommodate this scenario, the HA could avoid sending an RRP, when the MN and HA do not have a security association. Regards, Sebastian Kent Leung (kleung) wrote: >That's been my point. HA sends the RRP with MHAE when it _has_ an SA >with the MN. So if administrator wants the HA to be able to inform the >MN that the registration SA (key) is wrong, then set up a default SA to >communicate this event securely. This mechanism would be already >covered in current RFC 3344 without protocol changes. > >Kent > > > >>-----Original Message----- >>From: Venkateshwara Sastry (vsastry) >>Sent: Sunday, June 25, 2006 11:57 PM >>To: Yoshi Tsuda (yotsuda); Avi Lior; Chowdhury, Kuntal >>Cc: Mobile IPv4 Mailing List >>Subject: RE: [Mip4] 3344 Sending a Reg Reply when the >>Authenticator fails >> >> >>IMHO, if RRQ authentication failed at HA(may be packet was >>corrupted when received by HA), and HA HAS a SA with that MN, >>the HA can send an RRP with MHAE and error code 131. In such >>a sceanrio, there is a possibility that MN can authenticate >>the RRP and continue further processing. >> >>Regards >>Sastry >> >> >> >>>-----Original Message----- >>>From: Yoshi Tsuda (yotsuda) >>>Sent: Monday, June 26, 2006 10:31 AM >>>To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal >>>Cc: Mobile IPv4 Mailing List >>>Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator >>>fails >>> >>>Hi Avi and all, >>> >>> Good point. >>> >>> Personally, I believe, an MN should stop sending RRQs, if it >>>receives an RRP with 131, and if the MN has sent the >>> >>> >>original RRQ in >> >> >>>spite of the meaning of "silently discard". >>> The term, "silently discard" found to be used in rfc2002, >>> >>> >>too; so it >> >> >>>might have a histrical reason, though... >>> >>> Also, I agree with Kuntal that error handlings haven't been well >>>documented. If this causes deployment issues, should we >>> >>> >>have a new >> >> >>>I-D about handling codes or ask modifications of rfc3344 to the >>>inventor of MIP? >>> >>>Thanks. >>>-Yoshi >>> >>> >>> >>>>-----Original Message----- >>>>From: Avi Lior [mailto:avi@bridgewatersystems.com] >>>>Sent: Monday, June 26, 2006 8:38 AM >>>>To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal >>>>Cc: Mobile IPv4 Mailing List >>>>Subject: RE: [Mip4] 3344 Sending a Reg Reply when the >>>> >>>> >>Authenticator >> >> >>>>fails >>>> >>>>I think the protocol does allow an HA to respond with an >>>> >>>> >>>auth failure. >>> >>> >>>>Code 131 was designed for that no? >>>> >>>>However, as you point out an MN receiving a RRP which fails >>>> >>>> >>>its auth >>> >>> >>>>check MUST silently discard. Silently discard means no more >>>>processing. Does that mean that the MN is not allowed to use the >>>>receipt of the RRP to stop sending any further RRQs? Some >>>> >>>> >>>would say >>> >>> >>>>yes. >>>> >>>>Therefore, why allow the HA to send an RRP when clearly >>>> >>>> >>the MN will >> >> >>>>silently discard it? >>>> >>>>Is this a contradiction or is it by design? >>>> >>>> >>>> >>>> >>>> >>>>________________________________ >>>> >>>> From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com] >>>> Sent: Friday, June 23, 2006 4:19 PM >>>> To: Chowdhury, Kuntal; Avi Lior >>>> Cc: Mobile IPv4 Mailing List >>>> Subject: RE: [Mip4] 3344 Sending a Reg Reply when the >>>> >>>> >>>Authenticator >>> >>> >>>>fails >>>> >>>> >>>> We can not really claim that current protocol allows HA >>>> >>>> >>>to respond on >>> >>> >>>>auth failure. If HA responding on auth failure was really the >>>>intention of the designers, silently discarding such >>>> >>>> >>>packets by MN as >>> >>> >>>>indicated in following text does not make sense. >>>> b) If the Code field indicates that service is >>>> >>>> >>>denied by the >>> >>> >>>>home >>>> agent, or if the Code field indicates that the >>>> >>>> >>>registration >>> >>> >>>>was >>>> accepted by the home agent, exactly one Mobile-Home >>>> Authentication Extension MUST be present in >>>> >>>> >>>the Registration >>> >>> >>>> Reply, and the mobile node MUST check the >>>> >>>> >>>Authenticator >>> >>> >>>>value >>>> in the Extension. If the Registration Reply >>>> >>>> >>>was generated >>> >>> >>>>by >>>> the home agent but no Mobile-Home >>>> >>>> >>>Authentication Extension >>> >>> >>>>is >>>> found, or if more than one Mobile-Home Authentication >>>>Extension >>>> is found, or if the Authenticator is invalid, >>>> >>>> >>>the mobile >>> >>> >>>>node >>>> MUST silently discard the Reply and SHOULD log >>>> >>>> >>>the event as >>> >>> >>>>a >>>> security exception. >>>> >>>> Regards >>>> Sastry >>>> >>>> >>>>________________________________ >>>> >>>> From: Chowdhury, Kuntal >>>>[mailto:kchowdhury@starentnetworks.com] >>>> Sent: Friday, June 23, 2006 4:56 AM >>>> To: Avi Lior >>>> Cc: Mobile IPv4 Mailing List >>>> Subject: RE: [Mip4] 3344 Sending a Reg Reply >>>> >>>> >>>when the Authenticator >>> >>> >>>>fails >>>> >>>> >>>> >>>> Avi, >>>> >>>> >>>> >>>> If a rogue MN can break into the network (i.e. >>>>pass access auth), anything is possible. However, by >>>> >>>> >>>putting multiple >>> >>> >>>>levels of auth (at least 1 or 2); the operators make this >>>> >>>> >>>possibility >>> >>> >>>>extremely slim. So, let's not get hung-up with the fact >>>> >>>> >>>that rouge MNs >>> >>> >>>>can do bad things. >>>> >>>> >>>> >>>> The issue is simple: if the auth of a RRQ >>>> >>>> >>>fails, should the HA >>> >>> >>>>respond back to the MN? There are some people who believe a >>>> >>>> >>>response >>> >>> >>>>should be sent. There are some who believe that the HA >>>> >>>> >>>should silently >>> >>> >>>>discard the packet. >>>> >>>> >>>> >>>> In this context, the current mip4 protocol >>>> >>>> >>>allows the HA to send a >>> >>> >>>>response upon auth failure. The current text also allows those HA >>>>implementations which like to silently discard the packet. >>>> >>>> >>>So, let's >>> >>> >>>>not change the protocol as it allows both the >>>>behaviors/implementations. We can just clarify some text to >>>> >>>> >>>describe >>> >>> >>>>how the response packet is formatted. >>>> >>>> >>>> >>>> -Kuntal >>>> >>>> >>>> >>>> >>>> >>>> >>-- >>Mip4 mailing list: Mip4@ietf.org >> Web interface: https://www1.ietf.org/mailman/listinfo/mip4 >> Charter page: http://www.ietf.org/html.charters/mip4-charter.html >>Supplemental site: http://www.mip4.org/ >> >> >> > > > --------------010503070006020208000203 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Kent,
                  If the corruption of the RRQ has occurred, as a result of a loss of integrity of the wireless link (MN and HA have a security association), then the RRP with a Code 131 should be processed (not limited to discarding and error logging) further by the MN to re-send an RRQ.  To accommodate this scenario, the HA could avoid sending an RRP, when the MN and HA do not have a security association.

Regards,
     Sebastian

Kent Leung (kleung) wrote:
That's been my point.  HA sends the RRP with MHAE when it _has_ an SA
with the MN.  So if administrator wants the HA to be able to inform the
MN that the registration SA (key) is wrong, then set up a default SA to
communicate this event securely.  This mechanism would be already
covered in current RFC 3344 without protocol changes.

Kent 

  
-----Original Message-----
From: Venkateshwara Sastry (vsastry) 
Sent: Sunday, June 25, 2006 11:57 PM
To: Yoshi Tsuda (yotsuda); Avi Lior; Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the 
Authenticator fails


IMHO, if RRQ authentication failed at HA(may be packet was 
corrupted when received by HA), and HA HAS a SA with that MN, 
the HA can send an RRP with MHAE and error code 131. In such 
a sceanrio, there is a possibility that MN can authenticate 
the RRP and continue further processing.

Regards
Sastry

    
-----Original Message-----
From: Yoshi Tsuda (yotsuda)
Sent: Monday, June 26, 2006 10:31 AM
To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator 
fails

Hi Avi and all,

 Good point.

 Personally, I believe, an MN should stop sending RRQs,  if it 
receives an RRP with 131, and if the MN has sent the 
      
original RRQ in 
    
spite of the meaning of "silently discard".
 The term, "silently discard" found to be used in rfc2002, 
      
too; so it 
    
might have a histrical reason, though...

 Also, I agree with Kuntal that error handlings haven't been well 
documented.  If this causes deployment issues,  should we 
      
have a new 
    
I-D about handling codes or ask  modifications of rfc3344 to the 
inventor of MIP?

Thanks.
-Yoshi

      
-----Original Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Monday, June 26, 2006 8:38 AM
To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 Sending a Reg Reply when the 
        
Authenticator 
    
fails

I think the protocol does allow an HA to respond with an
        
auth failure.  
      
Code 131 was designed for that no?
 
However, as you point out an MN receiving a RRP which fails
        
its auth
      
check MUST silently discard.  Silently discard means no more 
processing.  Does that mean that the MN is not allowed to use the 
receipt of the RRP to stop sending any further RRQs?  Some
        
would say
      
yes.
 
Therefore, why allow the HA to send an RRP when clearly 
        
the MN will 
    
silently discard it?
 
Is this a contradiction or is it by design?
 
 



________________________________

	From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com] 
	Sent: Friday, June 23, 2006 4:19 PM
	To: Chowdhury, Kuntal; Avi Lior
	Cc: Mobile IPv4 Mailing List
	Subject: RE: [Mip4] 3344 Sending a Reg Reply when the
        
Authenticator
      
fails
	
	
	We can not really claim that current protocol allows HA
        
to respond on
      
auth failure. If HA responding on auth failure was really the 
intention of the designers, silently discarding such
        
packets by MN as
      
indicated in following text does not make sense.
	      b) If the Code field indicates that service is
        
denied by the
      
home
	         agent, or if the Code field indicates that the
        
registration
      
was
	         accepted by the home agent, exactly one Mobile-Home
	         Authentication Extension MUST be present in
        
the Registration
      
	         Reply, and the mobile node MUST check the
        
Authenticator
      
value
	         in the Extension.  If the Registration Reply
        
was generated
      
by
	         the home agent but no Mobile-Home
        
Authentication Extension
      
is
	         found, or if more than one Mobile-Home Authentication 
Extension
	         is found, or if the Authenticator is invalid,
        
the mobile
      
node
	         MUST silently discard the Reply and SHOULD log
        
the event as
      
a
	         security exception.
	
	Regards
	Sastry


________________________________

		From: Chowdhury, Kuntal
[mailto:kchowdhury@starentnetworks.com] 
		Sent: Friday, June 23, 2006 4:56 AM
		To: Avi Lior
		Cc: Mobile IPv4 Mailing List
		Subject: RE: [Mip4] 3344 Sending a Reg Reply
        
when the Authenticator
      
fails
		
		

		Avi,

		 

		If a rogue MN can break into the network (i.e. 
pass access auth), anything is possible. However, by
        
putting multiple
      
levels of auth (at least 1 or 2); the operators make this
        
possibility
      
extremely slim. So, let's not get hung-up with the fact
        
that rouge MNs
      
can do bad things.

		 

		The issue is simple: if the auth of a RRQ
        
fails, should the HA
      
respond back to the MN? There are some people who believe a
        
response
      
should be sent. There are some who believe that the HA
        
should silently
      
discard the packet.

		 

		In this context, the current mip4 protocol
        
allows the HA to send a
      
response upon auth failure. The current text also allows those HA 
implementations which like to silently discard the packet.
        
So, let's
      
not change the protocol as it allows both the 
behaviors/implementations. We can just clarify some text to
        
describe
      
how the response packet is formatted.

		 

		-Kuntal

		 


        
--
Mip4 mailing list: Mip4@ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/
--------------010503070006020208000203-- --===============1629886797== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1629886797==-- From mip4-bounces@ietf.org Mon Jun 26 09:32:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurCO-0000pJ-IP; Mon, 26 Jun 2006 09:32:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FurCN-0000pE-VT for mip4@ietf.org; Mon, 26 Jun 2006 09:32:19 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FurCM-0008DI-KW for mip4@ietf.org; Mon, 26 Jun 2006 09:32:19 -0400 Received: by wr-out-0506.google.com with SMTP id i23so11463wra for ; Mon, 26 Jun 2006 06:32:18 -0700 (PDT) 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=YNVufqoow0vHNjze7SpZQJiqV0TJeCJgJ4fYNBykhC0HFJ6M3uaiTUiR+8IDiBAkf0kuEbfvgIW4UnD3uv/OR3S+aFg4I2xkymTcr2BGrsYWY+j9R2eEPMPQgukjONCEdc40wWqFwLkeClPmVw2igP8j9jDN0w74Le0tTboLk2A= Received: by 10.65.211.14 with SMTP id n14mr1821883qbq; Mon, 26 Jun 2006 06:32:18 -0700 (PDT) Received: by 10.64.250.14 with HTTP; Mon, 26 Jun 2006 06:32:18 -0700 (PDT) Message-ID: Date: Mon, 26 Jun 2006 21:32:18 +0800 From: Owen.Lai To: "Kent Leung (kleung)" Subject: Re: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC5202062C3C@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 References: <2979E38DD6FC6544B789C8DAD7BAFC5202062C3C@xmb-sjc-235.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: mip4@ietf.org, zhen cao X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0084831720==" Errors-To: mip4-bounces@ietf.org --===============0084831720== Content-Type: text/plain; charset=GB2312; format=flowed Content-Transfer-Encoding: base64 Content-Disposition: inline SGVsbG8sIEtlbnQsCgpTb3JyeSBmb3IgbXkgcHJldmlvdXMgbWlzdGFrZSwKCiJJbnRlcmNlcHRp b24gcHJvYmxlbSIgaXMgYSBraW5kIG9mIE1hbi1pbi1NaWRkbGUgYXR0YWNrLgoKU3VwcG9zaW5n IHRoZSBmb2xsb3dpbmcgc2NlbmFyaW8sIE1TIGZpcnN0IGNvbm5lY3RlZCB3aXRoIEFSMSwgdGhl bgptb3ZlIHRvIEFSMidzIGxpbmsuCklmIGFuIG1hbGljaW91cyBub2RlIGludGVyY2VwdGVkIFJS USBmcm9tIEFSMSBhbmQgd2FpdCB1bnRpbCBBUjIgc2VuZApSUlEgdG8gSEEsIHRoZW4gbWFsaWNp b3VzIG5vZGUgc2VudCBpbnRlcmNlcHRlZCBSUlEgdG8gSEEgLCBpdCBjb3VsZApjYXVzZSBIQSBm YWxsIGJhY2sgdG8gQVIxIHJlZ2lzdHJhdGlvbi4KCkFuZCBJIHRoaW5rIElkZW50aWZpY2F0aW9u IGZpZWxkIGluIFJSUSBjYW5ub3QgcHJldmVudCB0aGUgYXR0YWNrLApiZWNhdXNlIFRpbWVzdGFt cHMgaW4gdGhlIElEIGZpZWxkcyBtYXkgYmUgZnJvbSB0d28gZGlmZmVyZW50IEFScyBhbmQKaXQg aXMgaW52YWxpZCB0byBtYWtlIGNvbXBhcmlzb24gYmV0d2VlbiB0d28gVGltZXN0YW1wcyBmcm9t IGRpZmZlcmVudApub2Rlcy4KClJlZ2FyZHMsCgpPd2VuCgoyMDA2LzYvMjYsIEtlbnQgTGV1bmcg KGtsZXVuZykgPGtsZXVuZ0BjaXNjby5jb20+Ogo+IEhpIE93ZW4uICBBcyBtZW50aW9uZWQgYnkg WmhlbiwgcmVwbGF5IHByb3RlY3Rpb24gaXMgcHJvdmlkZWQgYnkgdGhlIElEIGZpZWxkLiAgVGhl IGRyYWZ0IGJyaW5ncyB1cCByZXBsYXkgYXR0YWNrIGFzIGEgcHJvYmxlbSBmb3Igc2VxdWVuY2Ug bnVtYmVyLiAgU28sIG5vdCBjbGVhciB3aGF0IHlvdSBtZWFuIGJ5IGludGVyY2VwdGlvbiBwcm9i bGVtPyAgQ2FuIHlvdSBleHBsYWluIG1vcmU/Cj4KPiBLZW50Cj4KPiA+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tCj4gPiBGcm9tOiBPd2VuLkxhaSBbbWFpbHRvOnN1bXJpdmVyQGdtYWlsLmNv bV0KPiA+IFNlbnQ6IE1vbmRheSwgSnVuZSAyNiwgMjAwNiAxOjI0IEFNCj4gPiBUbzogemhlbiBj YW8KPiA+IENjOiBtaXA0QGlldGYub3JnCj4gPiBTdWJqZWN0OiBSZTogW01pcDRdIFJlOiBGd2Q6 Cj4gPiBJLURBQ1RJT046ZHJhZnQtbGFpLW1pcDQtcHJveHktc2VxdWVuY2UtcHJvYmxlbS0wMC50 eHQKPiA+Cj4gPiBIaSwgWmhlbiwKPiA+Cj4gPiBUaGFua3MgZm9yIHlvdXIgcXVlc3Rpb24hCj4g Pgo+ID4gV2UgbWFkZSBtaXN0YWtlIGJlZm9yZSwgdGhpcyBpcyBpbnRlcmNlcHRpb24gcHJvYmxl bSBvdGhlcgo+ID4gdGhhbiBhbnRpLXJlcGxheSBwcm9ibGVtLgo+ID4KPiA+IEFsbCB0aGUgYmVz dAo+ID4KPiA+IFNob3V3ZW4KPiA+Cj4gPgo+ID4KPiA+INTaIDA2LTYtMjajrHpoZW4gY2FvPGNh b3poZW5wa3VAZ21haWwuY29tPiDQtLXAo7oKPiA+ID4KPiA+ID4gSGksIFNob3V3ZW4KPiA+ID4K PiA+ID4gICAgICBJIGhhdmUgb25lIHF1ZXN0aW9uIGFib3V0IHlvdXIgZHJhZnQ6Cj4gPiA+Cj4g PiA+ICAgICAgSXNuJ3QgdGltZXN0YW1wIGluIGlkZW50aWZpY2F0aW9uIG9mIHJycSB3aWxsIGJl IHVzZWQKPiA+IGZvciBhbnRpLXJlcGx5Pwo+ID4gPgo+ID4gPiBNYW55IHRoYW5rcywKPiA+ID4g Wmhlbgo+ID4gPgo+ID4gPgo+ID4gPiAtLS0tLS0tLS0tLS1PcmlnaW5hbAo+ID4gPiBNZXNzYWdl LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPiA+ID4gSGkgZm9sa3MsCj4gPiA+Cj4g PiA+IFdlJ3ZlIHB1Ymxpc2hlZCBhIG5ldyBkcmFmdCwgIlByb2JsZW0gb2YgUmVwbGF5IFByb3Rl Y3Rpb24gVXNpbmcKPiA+IFNlcXVlbmNlCj4gPiA+IE51bWJlciBpbiBQcm94eSBNb2JpbGUgSVB2 NCIuCj4gPiA+Cj4gPiA+IFRoZSBkb2N1bWVudCBwcmVzZW50cyB0aGUgcHJvYmxlbXMgb2YgcmVw bGF5IHByb3RlY3Rpb24KPiA+IHVzaW5nIHNlcXVlbmNlCj4gPiBudW1iZXIgaW4gcHJveHkgTW9i aWxlIElQdjQgc29sdXRpb24uIFRoZSBzZXF1ZW5jZSBudW1iZXIKPiA+ID4gY2Fubm90Cj4gPiBw cmV2ZW50IHJlZ2lzdHJhdGlvbiBtZXNzYWdlIGZyb20gcmVwbGF5IGF0dGFjay4KPiA+ID4KPiA+ ID4gQW55IGNvbW1lbnRzIGFyZSB3ZWxjb21lLgo+ID4gPgo+ID4gPiBUaGFua3MsCj4gPiBTaG91 d2VuLAo+ID4gPgo+ID4gPgo+ID4gPiAtLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0t LS0tLS0gRnJvbTogSW50ZXJuZXQtRHJhZnRzIGF0Cj4gPiA+IGlldGYub3JnIDxJbnRlcm5ldC1E cmFmdHMgYXQgaWV0Zi5vcmc+IERhdGU6IDIwMDYtNi0yMwo+ID4gyc/O5zY6NTAgU3ViamVjdDoK PiA+ID4gSS1EIEFDVElPTjpkcmFmdC1sYWktbWlwNC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAw LnR4dAo+ID4gPiBUbzogaS1kLWFubm91bmNlIGF0IGlldGYub3JnCj4gPiA+Cj4gPiA+Cj4gPiA+ Cj4gPiA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5l IEludGVybmV0LURyYWZ0cwo+ID4gPiBkaXJlY3Rvcmllcy4KPiA+ID4KPiA+ID4KPiA+ID4gIFRp dGxlIDogUHJvYmxlbSBvZiBSZXBsYXkgUHJvdGVjdGlvbiBVc2luZyBTZXF1ZW5jZQo+ID4gTnVt YmVyIGluIFByb3h5IE1vYmlsZQo+ID4gPiBJUHY0Cj4gPiAgQXV0aG9yKHMpIDogUy4gTGFpLCBI LiBEZW5nCj4gPiAgRmlsZW5hbWUgOgo+ID4gPiBkcmFmdC1sYWktbWlwNC1wcm94eS1zZXF1ZW5j ZS1wcm9ibGVtLTAwLnR4dAo+ID4gIFBhZ2VzIDogNwo+ID4gPiBEYXRlIDogMjAwNi02LTIyCj4g PiA+Cj4gPiA+ICBUaGUgZG9jdW1lbnQgcHJlc2VudHMgdGhlIHByb2JsZW1zIG9mIHJlcGxheSBw cm90ZWN0aW9uIHVzaW5nCj4gPiAgc2VxdWVuY2UKPiA+ID4gbnVtYmVyIGluIHByb3h5IE1vYmls ZSBJUHY0IHNvbHV0aW9uLiBUaGUgc2VxdWVuY2UgbnVtYmVyCj4gPiAgY2Fubm90IHByZXZlbnQK PiA+ID4gcmVnaXN0cmF0aW9uIG1lc3NhZ2UgZnJvbSByZXBsYXkgYXR0YWNrLgo+ID4gPgo+ID4g Pgo+ID4gPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdAo+ID4gPiBpczoKPiA+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxhaS1taXA0LXByb3h5LXNlcXVl Cj4gPiBuY2UtcHJvYmxlbS0wMC50eHQKPiA+ID4KPiA+ID4gVG8gcmVtb3ZlIHlvdXJzZWxmIGZy b20gdGhlIEktRCBBbm5vdW5jZW1lbnQgbGlzdCwgc2VuZCBhIG1lc3NhZ2UgdG8KPiA+IGktZC1h bm5vdW5jZS1yZXF1ZXN0IGF0IGlldGYub3JnIHdpdGggdGhlIHdvcmQgdW5zdWJzY3JpYmUgaW4g dGhlIGJvZHkKPiA+ID4gb2YKPiA+IHRoZSBtZXNzYWdlLgo+ID4gWW91IGNhbiBhbHNvIHZpc2l0 Cj4gPiA+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL0ktRC1hbm5vdW5j ZQo+ID4gPiB0byBjaGFuZ2UgeW91ciBzdWJzY3JpcHRpb24gc2V0dGluZ3MuCj4gPiA+Cj4gPiA+ Cj4gPiA+Cj4gPiA+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUC4gTG9naW4gd2l0aCB0aGUKPiA+ID4gdXNlcm5hbWUKPiA+ICJhbm9ueW1vdXMiIGFu ZCBhIHBhc3N3b3JkIG9mIHlvdXIgZS1tYWlsIGFkZHJlc3MuIEFmdGVyIGxvZ2dpbmcKPiA+ID4g aW4sCj4gPiB0eXBlICJjZCBpbnRlcm5ldC1kcmFmdHMiIGFuZCB0aGVuCj4gPiAgImdldAo+ID4g PiBkcmFmdC1sYWktbWlwNC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dCIuCj4gPiA+Cj4g PiA+IEEgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMgY2FuIGJlIGZvdW5kIGlu Cj4gPiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sCj4gPiBvcgo+ID4gPiBmdHA6Ly9m dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dAo+ID4gPgo+ID4gPgo+ID4gPiBJbnRl cm5ldC1EcmFmdHMgY2FuIGFsc28gYmUgb2J0YWluZWQgYnkgZS1tYWlsLgo+ID4gPgo+ID4gPiBT ZW5kIGEgbWVzc2FnZSB0bzoKPiA+ICBtYWlsc2VydiBhdCBpZXRmLm9yZy4KPiA+IEluIHRoZSBi b2R5IHR5cGU6Cj4gPiAgIkZJTEUKPiA+ID4gL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sYWktbWlw NC1wcm94eS1zZXF1ZW5jZS1wcm9ibGVtLTAwLnR4dCIuCj4gPiA+Cj4gPiA+IE5PVEU6IFRoZSBt YWlsIHNlcnZlciBhdCBpZXRmLm9yZyBjYW4gcmV0dXJuIHRoZSBkb2N1bWVudCBpbgo+ID4gIE1J TUUtZW5jb2RlZAo+ID4gPiBmb3JtIGJ5IHVzaW5nIHRoZSAibXBhY2siIHV0aWxpdHkuIFRvIHVz ZSB0aGlzCj4gPiAgZmVhdHVyZSwgaW5zZXJ0IHRoZSBjb21tYW5kCj4gPiA+ICJFTkNPRElORyBt aW1lIiBiZWZvcmUgdGhlICJGSUxFIgo+ID4gIGNvbW1hbmQuIFRvIGRlY29kZSB0aGUgcmVzcG9u c2UocyksIHlvdQo+ID4gPiB3aWxsIG5lZWQgIm11bnBhY2siIG9yCj4gPiAgYSBNSU1FLWNvbXBs aWFudCBtYWlsIHJlYWRlci4gRGlmZmVyZW50Cj4gPiA+IE1JTUUtY29tcGxpYW50IG1haWwgcmVh ZGVycwo+ID4gIGV4aGliaXQgZGlmZmVyZW50IGJlaGF2aW9yLCBlc3BlY2lhbGx5IHdoZW4KPiA+ ID4gZGVhbGluZyB3aXRoCj4gPiAgIm11bHRpcGFydCIgTUlNRSBtZXNzYWdlcyAoaS5lLiBkb2N1 bWVudHMgd2hpY2ggaGF2ZSBiZWVuCj4gPiA+IHNwbGl0Cj4gPiAgdXAgaW50byBtdWx0aXBsZSBt ZXNzYWdlcyksIHNvIGNoZWNrIHlvdXIgbG9jYWwgZG9jdW1lbnRhdGlvbiBvbiAgaG93Cj4gPiA+ IHRvIG1hbmlwdWxhdGUgdGhlc2UgbWVzc2FnZXMuCj4gPiA+Cj4gPiA+Cj4gPiA+IEJlbG93IGlz IHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCByZWFkZXIK PiA+IGltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJIHZl cnNpb24gb2YKPiA+ID4gdGhlCj4gPiBJbnRlcm5ldC1EcmFmdC4KPiA+ID4KPiA+ID4KPiA+ID4K PiA+ID4KPiA+ID4KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18KPiA+IEktRC1Bbm5vdW5jZQo+ID4gPiBtYWlsaW5nIGxpc3QKPiA+IEktRC1Bbm5v dW5jZSBhdCBpZXRmLm9yZwo+ID4gPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pLWQtYW5ub3VuY2UKPiA+ID4KPiA+ID4KPiA+ID4gLS0KPiA+ID4gTWlwNCBtYWlsaW5n IGxpc3Q6IE1pcDRAaWV0Zi5vcmcKPiA+ID4gICAgV2ViIGludGVyZmFjZToKPiA+ID4gaHR0cHM6 Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlwNAo+ID4gPiAgICAgQ2hhcnRlciBw YWdlOgo+ID4gPiBodHRwOi8vd3d3LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbWlwNC1jaGFydGVy Lmh0bWwKPiA+ID4gU3VwcGxlbWVudGFsIHNpdGU6IGh0dHA6Ly93d3cubWlwNC5vcmcvCj4gPiA+ Cj4gPiA+Cj4gPiA+Cj4gPgo+Cg== --===============0084831720== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0084831720==-- From mip4-bounces@ietf.org Mon Jun 26 14:17:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuveh-0003lg-Ol; Mon, 26 Jun 2006 14:17:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuveg-0003lb-Bp for mip4@ietf.org; Mon, 26 Jun 2006 14:17:50 -0400 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 1Fuvee-0007aT-21 for mip4@ietf.org; Mon, 26 Jun 2006 14:17:50 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2006 11:17:47 -0700 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 k5QIHkII028556; Mon, 26 Jun 2006 11:17:46 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5QIHiAG029435; Mon, 26 Jun 2006 11:17:46 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 26 Jun 2006 11:17:46 -0700 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: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt Date: Mon, 26 Jun 2006 11:17:43 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52020C8C8B@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt Thread-Index: AcaZJPb6XbsmYTH7R72HTFXKDD87ygAJ2VIw From: "Kent Leung \(kleung\)" To: "Owen.Lai" X-OriginalArrivalTime: 26 Jun 2006 18:17:46.0017 (UTC) FILETIME=[D2D1D910:01C6994C] DKIM-Signature: a=rsa-sha1; q=dns; l=1163; t=1151345866; x=1152209866; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Re=3A=20Fwd=3A=20I-DACTION=3Adraft-lai-mip4-proxy-seque nce-problem-00.txt; X=v=3Dcisco.com=3B=20h=3DTWIkMpoyZW2J1gqesf2bduOQOK8=3D; b=kyFJwtTPkP/ER/YJTVhawQMHLKMPk7kY0xDTErMVP7pTLwVnMcUmmoyRRUUrQ1W7jEoXpkZY 19ZXDLmhcF9KSMo/YGa1Xuc3xYCTqHB7+AiDrdbbZnKENsbXbDy7q7pn; Authentication-Results: sj-dkim-3.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: mip4@ietf.org, zhen cao X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi Owen. The flaw in your logic is that the timestamp is based on HA's value. The HA uses error code 133 to inform the sender of the RRQ the correct timestamp. Kent=20 > -----Original Message----- > From: Owen.Lai [mailto:sumriver@gmail.com]=20 > Sent: Monday, June 26, 2006 6:32 AM > To: Kent Leung (kleung) > Cc: zhen cao; mip4@ietf.org > Subject: Re: [Mip4] Re: Fwd:=20 > I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt >=20 > Hello, Kent, >=20 > Sorry for my previous mistake, >=20 > "Interception problem" is a kind of Man-in-Middle attack. >=20 > Supposing the following scenario, MS first connected with=20 > AR1, then move to AR2's link. > If an malicious node intercepted RRQ from AR1 and wait until=20 > AR2 send RRQ to HA, then malicious node sent intercepted RRQ=20 > to HA , it could cause HA fall back to AR1 registration. >=20 > And I think Identification field in RRQ cannot prevent the=20 > attack, because Timestamps in the ID fields may be from two=20 > different ARs and it is invalid to make comparison between=20 > two Timestamps from different nodes. >=20 > Regards, >=20 > Owen > >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 26 19:13:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzw8-0008K0-Aj; Mon, 26 Jun 2006 18:52:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuzu7-0004Q6-Vx; Mon, 26 Jun 2006 18:50:03 -0400 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 1Fuzu7-0007eo-TY; Mon, 26 Jun 2006 18:50:03 -0400 Received: from cypress.neustar.com ([209.173.57.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FuzoA-0007kQ-Oz; Mon, 26 Jun 2006 18:43:56 -0400 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k5QMgmjx024683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Jun 2006 22:42:48 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1Fuzn5-0006M4-Uo; Mon, 26 Jun 2006 18:42:47 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: IETF Announcement list From: IESG Secretary Message-Id: Date: Mon, 26 Jun 2006 18:42:47 -0400 X-Spam-Score: -2.6 (--) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: Peter McCann , mip4@ietf.org, Henrik Levkowetz Subject: [Mip4] WG Review: Recharter of Mobility for IPv4 (mip4) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org A modified charter has been submitted for the Mobility for IPv4 (mip4) working group in the Internet Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by July 3rd. +++ Mobility for IPv4 (mip4) =========================== Current Status: Active Working Group Chair(s): Peter McCann Henrik Levkowetz Internet Area Director(s): Jari Arkko Mark Townsley Internet Area Advisor: Jari Arkko Mailing Lists: General Discussion: mip4@ietf.org To Subscribe: mip4-request@ietf.org In Body: subscribe Archive: http://www.ietf.org/mail-archive/web/mip4/index.html Description of Working Group: IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the Internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings.Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues. MIPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when MIPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track. Work expected to be done by the MIP4 WG as proposed by this charter is as follows: 1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised to reflect implementation experience 2. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are: - completion of the MIB for the revised base Mobile IP specification (2006bis) - regional registration draft. 3. The MIP4 WG will also complete the work on MIPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for MIPv4 operation in the presence of IPsec VPNs. 4. Additionally, a proposal has been made for how MOBIKE could work together with MIPv4. This proposal does not describe any new protocol, but formulates a best current practice for deploying MOBIKE together with MIPv4. The working group will adopt and complete this document. 5. Some issues have been raised with respect to RFC3519. These will be identified and addressed as appropriate, through errata, revision of RFC 3519, and/or supplemental documents as needed. 6. It has been proposed that the FMIP protocol, which has been standardised for MIPv6 in the MIPSHOP working group, should also be published as an experimental protocol for MIPv4. A draft for this exists. The working group will take up and carry this work forward to publication 7. An extension to carry generic strings in the Registration Reply message has been proposed. The purpose is to supply supplemental human-readable information intended to the MN user. The working group will complete the specification and applicability statement of such an extension. 8. RADIUS attributes for MIP4. A set of RADIUS attributes has been proposed for MIPv4. The working group will first produce a requirements specification, describing how the work differs from the requirements in RFC 2977 and the functionality provided by RFC 4004 (the MIPv4 Diameter App). The reason why this first step is required is that RFC 3127 pretty clearly shows that full 2977 functionality can't be provided by even a considerably extended RADIUS, so we need to match the requirements to what can be done within RADIUS. Provided the requirements work finds approval with ADs and radext, the workgroup will complete the specification of MIPv4 RADIUS attributes, solicit feedback from the Radius Extensions WG, adjust, and submit this for publication. 9. MIPv4 Extension for Configuration Options. Several drafts have proposed extensions to help improve configuration of MIPv4 clients. The latest proposal is for a general configuration option extension which could carry information such as e.g., DNS address and DHCP server address. The working group will take on and complete one proposal for a configuration option extension. 10. Dual-stack Support There have been several proposals for how to enable an IPv6 connection over a network that supports Mobile IPv4. The basic idea is to include an IPv6 address in the Mobile IPv4 signaling messages. The working group will take on and complete one proposal for IPv6 over Mobile IPv4. Goals and Milestones: Done AAA Keys for MIPv4 to IESG Done MIPv4 VPN interaction problem statement to IESG Done Low latency handover to experimental Done Experimental MIPv4 message and extensions draft to IESG Done Dynamic Home Agent assignment protocol solution to IESG Done Revised MIPv4 Challenge/Response (3012bis) to IESG Done Regional registration document to IESG Jul 2006 MIPv4 Mobike interaction (BCP) to the IESG Jul 2006 MIPv4 VPN interaction (BCP) to the IESG Jul 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment Jul 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG Aug 2006 Revised MIPv4 specification to IESG for Draft Std. Aug 2006 MIPv4 Extension for Config. Options (Proposed Std.) to the IESG Sep 2006 FMIPv4 (Experimental) to the IESG Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG Nov 2006 Revised rfc2794bis (NAI extension) (Draft Std.) to the IESG Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Mon Jun 26 20:08:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv17f-00046I-2X; Mon, 26 Jun 2006 20:08:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv17d-00044x-CN for mip4@ietf.org; Mon, 26 Jun 2006 20:08:05 -0400 Received: from static-ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fv17b-000298-LN for mip4@ietf.org; Mon, 26 Jun 2006 20:08:05 -0400 Received: (qmail 7894 invoked from network); 27 Jun 2006 00:07:47 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;026a4d81c7e3772c249dfba3990a192d; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 27 Jun 2006 00:07:47 -0000 Received: (qmail 28376 invoked from network); 27 Jun 2006 00:07:46 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;435a48781d0e436f2a8cd9044674b625; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 27 Jun 2006 00:07:46 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 08:07:46 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C6997D.B74B50E4" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 27 Jun 2006 08:07:45 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3801923519@hcbjdc2> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-deng-mip4-generic-notification-message-02.txt Thread-Index: AcaZfF2C43LAXfXATA+R0L8fJaAO1gAAM8yJ From: "DENG, HUI -HCHBJ" To: X-OriginalArrivalTime: 27 Jun 2006 00:07:46.0392 (UTC) FILETIME=[B804C580:01C6997D] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1151366866.627-28373-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.03/0.10 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1151366867.175-7890-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.03/0.03 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Mip4] FW: I-D ACTION:draft-deng-mip4-generic-notification-message-02.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C6997D.B74B50E4 Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIGFsbA0KIA0KY291bGQgeW91IGhlbHAgdG8gcmV2aWV3IHRoaXMgY29tbWVudCwNClRo YW5rcw0KIA0KLUh1aQ0KDQogDQoNCiANCg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IEdl bmVyaWMgTm90aWZpY2F0aW9uIE1lc3NhZ2UgZm9yIE1vYmlsZSBJUHY0DQogICAgICAgIEF1dGhv cihzKSAgICAgICA6IEguIERlbmcsIGV0IGFsLg0KICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1kZW5nLW1pcDQtZ2VuZXJpYy1ub3RpZmljYXRpb24tbWVzc2FnZS0wMi50eHQNCiAgICAg ICAgUGFnZXMgICAgICAgICAgIDogMjMNCiAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAwNi02 LTI2DQogICAgICAgDQpUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBwcm90b2NvbCBlbmhhbmNlbWVu dHMgdGhhdCBhbGxvdyBNb2JpbGUgSVB2NA0KZW50aXRpZXMgdG8gc2VuZCBhbmQgcmVjZWl2ZSBl eHBsaWNpdCBub3RpZmljYXRpb24gbWVzc2FnZXMgdXNpbmcgYQ0KbmV3IE1vYmlsZSBJUHY0IHR5 cGUgZGVzaWduZWQgZm9yIHRoaXMgcHVycG9zZS4NCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQt RHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1kZW5n LW1pcDQtZ2VuZXJpYy1ub3RpZmljYXRpb24tbWVzc2FnZS0wMi50eHQNCg0KDQo= ------_=_NextPart_001_01C6997D.B74B50E4 Content-Type: text/plain;name="ATT17008.txt" Content-Transfer-Encoding: base64 Content-Description: ATT17008.txt Content-Disposition: attachment;filename="ATT17008.txt" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQo= ------_=_NextPart_001_01C6997D.B74B50E4 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ------_=_NextPart_001_01C6997D.B74B50E4-- From mip4-bounces@ietf.org Tue Jun 27 01:29:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv68x-0003nF-3m; Tue, 27 Jun 2006 01:29:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv68v-0003nA-Qn for mip4@ietf.org; Tue, 27 Jun 2006 01:29:45 -0400 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fv68s-0002ij-JJ for mip4@ietf.org; Tue, 27 Jun 2006 01:29:45 -0400 Received: by wr-out-0506.google.com with SMTP id i34so40588wra for ; Mon, 26 Jun 2006 22:29:42 -0700 (PDT) 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=PWj+FlkL5FtFEkPCB2q3k0kaW3S2AGtDgTsrNjRF2Si8DYWAOiW1TT7WOkSpKsE+qXuEZOafKwA+A+ySJkF51v/7PuG9/BQ2/Kgh9/j+6UK57f9+7DhOCRaQPI9BgsxZlIZ5Jmmiv15gTEhdkvcVuPU0DaXXTQmk3rB8t72MJR0= Received: by 10.64.76.8 with SMTP id y8mr7083167qba; Mon, 26 Jun 2006 22:29:42 -0700 (PDT) Received: by 10.64.250.14 with HTTP; Mon, 26 Jun 2006 22:29:42 -0700 (PDT) Message-ID: Date: Tue, 27 Jun 2006 13:29:42 +0800 From: Owen.Lai To: "Kent Leung (kleung)" Subject: Re: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52020C8C8B@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2979E38DD6FC6544B789C8DAD7BAFC52020C8C8B@xmb-sjc-235.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip4@ietf.org, zhen cao X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Kent, I agree that code 133 can be used to inform the sender of the RRQ the correct timestamp, and future timestamp is based on this correct value. HA rejects a RRQ with code 133 when it find out that the timestamp in ID field of RRQ is invalid. However, the Intercepted RRQ probably has the CORRECT timestamp which is in the range of time difference between sender and HA, 3~7s in default as in RFC 3344. And then HA may accept the intercepted RRQ. All the best, Owen 2006/6/27, Kent Leung (kleung) : > Hi Owen. The flaw in your logic is that the timestamp is based on HA's > value. The HA uses error code 133 to inform the sender of the RRQ the > correct timestamp. > > Kent > > > -----Original Message----- > > From: Owen.Lai [mailto:sumriver@gmail.com] > > Sent: Monday, June 26, 2006 6:32 AM > > To: Kent Leung (kleung) > > Cc: zhen cao; mip4@ietf.org > > Subject: Re: [Mip4] Re: Fwd: > > I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt > > > > Hello, Kent, > > > > Sorry for my previous mistake, > > > > "Interception problem" is a kind of Man-in-Middle attack. > > > > Supposing the following scenario, MS first connected with > > AR1, then move to AR2's link. > > If an malicious node intercepted RRQ from AR1 and wait until > > AR2 send RRQ to HA, then malicious node sent intercepted RRQ > > to HA , it could cause HA fall back to AR1 registration. > > > > And I think Identification field in RRQ cannot prevent the > > attack, because Timestamps in the ID fields may be from two > > different ARs and it is invalid to make comparison between > > two Timestamps from different nodes. > > > > Regards, > > > > Owen > > > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 27 11:37:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFd5-0007BI-PV; Tue, 27 Jun 2006 11:37:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvFd4-0007B9-TU for mip4@ietf.org; Tue, 27 Jun 2006 11:37:30 -0400 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 1FvFd3-0007UW-IK for mip4@ietf.org; Tue, 27 Jun 2006 11:37:30 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 27 Jun 2006 08:37:29 -0700 X-IronPort-AV: i="4.06,183,1149490800"; d="scan'208"; a="431364762:sNHT33545204" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k5RFbSjF025776; Tue, 27 Jun 2006 08:37:28 -0700 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 k5RFbS9s028931; Tue, 27 Jun 2006 08:37:28 -0700 (PDT) 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.211); Tue, 27 Jun 2006 08:37:28 -0700 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: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt Date: Tue, 27 Jun 2006 08:37:25 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52020C904C@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt Thread-Index: AcaZqrQOiBWAuGEoQUeo5/sVc9DOqAAVHjMA From: "Kent Leung \(kleung\)" To: "Owen.Lai" X-OriginalArrivalTime: 27 Jun 2006 15:37:28.0794 (UTC) FILETIME=[98EBD3A0:01C699FF] DKIM-Signature: a=rsa-sha1; q=dns; l=2620; t=1151422648; x=1152286648; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kleung@cisco.com; z=From:=22Kent=20Leung=20\(kleung\)=22=20 |Subject:RE=3A=20[Mip4]=20Re=3A=20Fwd=3A=20I-DACTION=3Adraft-lai-mip4-proxy-seque nce-problem-00.txt; X=v=3Dcisco.com=3B=20h=3DTWIkMpoyZW2J1gqesf2bduOQOK8=3D; b=XzDlb6s2c3Uk1o4faUbNlGDZszSry+KWtH9lyMJPWo06JkSyhtCHXtYtnq133lguKLVNwiWv ckSDuRs4wK4CZLG6xRKjnmcv/SMMT4/UKXoYK6oYZ11c6L2gcdCYKagq; Authentication-Results: sj-dkim-2.cisco.com; header.From=kleung@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: mip4@ietf.org, zhen cao X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Pls read RFC 3344 section 5.7.1: Note, however, that when using timestamps, the 64-bit Identification used in a Registration Request from the mobile node MUST be greater than that used in any previous Registration Request, as the home agent uses this field also as a sequence number. So the replayed RRQ with older ID value than the current binding will not be accepted by the HA. Kent=20 > -----Original Message----- > From: Owen.Lai [mailto:sumriver@gmail.com]=20 > Sent: Monday, June 26, 2006 10:30 PM > To: Kent Leung (kleung) > Cc: zhen cao; mip4@ietf.org > Subject: Re: [Mip4] Re: Fwd:=20 > I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt >=20 > Hi, Kent, >=20 > I agree that code 133 can be used to inform the sender of the=20 > RRQ the correct timestamp, and future timestamp is based on=20 > this correct value. >=20 > HA rejects a RRQ with code 133 when it find out that the=20 > timestamp in ID field of RRQ is invalid. >=20 > However, the Intercepted RRQ probably has the CORRECT=20 > timestamp which is in the range of time difference between=20 > sender and HA, 3~7s in default as in RFC 3344. And then HA=20 > may accept the intercepted RRQ. >=20 > All the best, >=20 > Owen >=20 >=20 > 2006/6/27, Kent Leung (kleung) : > > Hi Owen. The flaw in your logic is that the timestamp is based on=20 > > HA's value. The HA uses error code 133 to inform the sender of the=20 > > RRQ the correct timestamp. > > > > Kent > > > > > -----Original Message----- > > > From: Owen.Lai [mailto:sumriver@gmail.com] > > > Sent: Monday, June 26, 2006 6:32 AM > > > To: Kent Leung (kleung) > > > Cc: zhen cao; mip4@ietf.org > > > Subject: Re: [Mip4] Re: Fwd: > > > I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt > > > > > > Hello, Kent, > > > > > > Sorry for my previous mistake, > > > > > > "Interception problem" is a kind of Man-in-Middle attack. > > > > > > Supposing the following scenario, MS first connected with=20 > AR1, then=20 > > > move to AR2's link. > > > If an malicious node intercepted RRQ from AR1 and wait until > > > AR2 send RRQ to HA, then malicious node sent intercepted=20 > RRQ to HA ,=20 > > > it could cause HA fall back to AR1 registration. > > > > > > And I think Identification field in RRQ cannot prevent=20 > the attack,=20 > > > because Timestamps in the ID fields may be from two different ARs=20 > > > and it is invalid to make comparison between two Timestamps from=20 > > > different nodes. > > > > > > Regards, > > > > > > Owen > > > > > > > > >=20 -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Tue Jun 27 22:56:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvQDu-0005N8-VB; Tue, 27 Jun 2006 22:56:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvQDt-0005Lz-0k for mip4@ietf.org; Tue, 27 Jun 2006 22:56:13 -0400 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvQDr-0008K1-P5 for mip4@ietf.org; Tue, 27 Jun 2006 22:56:12 -0400 Received: by wr-out-0506.google.com with SMTP id i24so319982wra for ; Tue, 27 Jun 2006 19:56:11 -0700 (PDT) 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=XSPB9eGK5qs0zYxCnut8Q/CsJ++r263uCwAxfej+aiJkF5Zdv5sIbZ+L/OElvzgEELMwd9Up/PgpfKkEBSdaUkcGt9VXyBsGcJZHBVzfHPnsqlFdD9gjnsSI0KOzG7pZbN+EoTFNWEWuVVzPQRCfPCW0WeqJMRi8FnAn6EvqzJo= Received: by 10.65.97.17 with SMTP id z17mr430944qbl; Tue, 27 Jun 2006 19:56:10 -0700 (PDT) Received: by 10.64.250.14 with HTTP; Tue, 27 Jun 2006 19:56:10 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 10:56:10 +0800 From: Owen.Lai To: "Kent Leung (kleung)" Subject: Re: [Mip4] Re: Fwd: I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52020C904C@xmb-sjc-235.amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <2979E38DD6FC6544B789C8DAD7BAFC52020C904C@xmb-sjc-235.amer.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: mip4@ietf.org, zhen cao X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hi, Kent, Sorry, I didn't explain issue clearly, let me try to redo it again. In proxy MIP4, 1) MS first connected with MPA1, 2) MPA1 send RRQ to HA 3) An malicious node intercepts RRQ from MPA1 to HA, so this RRQ will not arrive at HA 4) MS move from MPA1 to the MPA2 in a very short time 5) MPA2 send RRQ to HA to update BCE. 6) An malicious node send MPA1 RRQ to HA, to invalidate MPA2 RRQ. Although timestamp is based on HA's value, MPA can only guarantee that its RRQ timestamp is close to HA's time of day. It's not necessay that MPA1 RRQ has a less Identification then that in MPA2 RRQ. So MPA1 RRQ MAY have a greater Identification then that in MPA2 RRQ, and hence HA will accetp MPA1 RRQ, causeing Man-in-Middle attack. Best Regards, Owen 2006/6/27, Kent Leung (kleung) : > Pls read RFC 3344 section 5.7.1: > > Note, however, that when using timestamps, the 64-bit Identification > used in a Registration Request from the mobile node MUST be greater > than that used in any previous Registration Request, as the home > agent uses this field also as a sequence number. > > So the replayed RRQ with older ID value than the current binding will > not be accepted by the HA. > > Kent > > > -----Original Message----- > > From: Owen.Lai [mailto:sumriver@gmail.com] > > Sent: Monday, June 26, 2006 10:30 PM > > To: Kent Leung (kleung) > > Cc: zhen cao; mip4@ietf.org > > Subject: Re: [Mip4] Re: Fwd: > > I-DACTION:draft-lai-mip4-proxy-sequence-problem-00.txt > > > > Hi, Kent, > > > > I agree that code 133 can be used to inform the sender of the > > RRQ the correct timestamp, and future timestamp is based on > > this correct value. > > > > HA rejects a RRQ with code 133 when it find out that the > > timestamp in ID field of RRQ is invalid. > > > > However, the Intercepted RRQ probably has the CORRECT > > timestamp which is in the range of time difference between > > sender and HA, 3~7s in default as in RFC 3344. And then HA > > may accept the intercepted RRQ. > > > > All the best, > > > > Owen > > > > > > 2006/6/27, Kent Leung (kleung) : > > > Hi Owen. The flaw in your logic is that the timestamp is based on > > > HA's value. The HA uses error code 133 to inform the sender of the > > > RRQ the correct timestamp. > > > > > > Kent > > > -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Wed Jun 28 15:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvfk7-0006On-2B; Wed, 28 Jun 2006 15:30:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvfk5-0006ME-CQ for mip4@ietf.org; Wed, 28 Jun 2006 15:30:29 -0400 Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvfjz-0001MJ-KS for mip4@ietf.org; Wed, 28 Jun 2006 15:30:29 -0400 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id k5SJUSDT011866 for ; Wed, 28 Jun 2006 21:30:28 +0200 Received: from nets139a.ww300.siemens.net ([158.226.129.98]) by vies1k7x.sie.siemens.at (8.12.11.20060308/8.12.1) with ESMTP id k5SJULGF002950 for ; Wed, 28 Jun 2006 21:30:22 +0200 Received: from zagh223a.ww300.siemens.net ([141.29.124.9]) by nets139a.ww300.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 21:30:21 +0200 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-2" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jun 2006 21:30:20 +0200 Message-ID: <3C31CDD06342EA4A8137716247B1CD681ED57B@zagh223a.ww300.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION: draft-premec-mip4-ip6-proxy-mip4-00.txt Thread-Index: Acaa6Uri9oalTIpvQZaEGDZs64kuVg== From: "Damic, Damjan" To: X-OriginalArrivalTime: 28 Jun 2006 19:30:21.0484 (UTC) FILETIME=[4BB4DEC0:01C69AE9] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mip4] Fwd: I-D ACTION: draft-premec-mip4-ip6-proxy-mip4-00.txt X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Hello, =20 As a contribution to the mip4, a new Internet-Draft is available from = the on-line Internet-Drafts directories: = http://www.ietf.org/internet-drafts/draft-premec-mip4-ip6-proxy-mip4-00.t= xt. =20 By comprising several approaches, and extending the Proxy MIP, this = draft illustrates how the pure IPv6 host could be provided with = IP-mobility management, while residing in the MIPv4-based network. With this initial version a rough concept is presented, therefore we = would greatly appreciate all your comments. =20 Many thanks, and kind regards. Damjan Damic -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Thu Jun 29 03:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvr2y-0002T0-2A; Thu, 29 Jun 2006 03:34:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvr2w-0002K6-Ly for mip4@ietf.org; Thu, 29 Jun 2006 03:34:42 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvr2s-0002bo-1Z for mip4@ietf.org; Thu, 29 Jun 2006 03:34:42 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 2BE4590019 for ; Thu, 29 Jun 2006 03:34:33 -0400 (EDT) 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 19835-05 for ; Thu, 29 Jun 2006 03:34:29 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 29 Jun 2006 03:34:29 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Jun 2006 03:31:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 29 Jun 2006 03:31:20 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C5228@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaWJhvxl+ec4R/6R02W3YjjoEjEaQABxVfQAAVYjFAAA3gnkAARIiVQAGbdTjAAOKAkcACOvi0Q From: "Chowdhury, Kuntal" To: "Kent Leung (kleung)" , "Avi Lior" , "Venkateshwara Sastry (vsastry)" X-OriginalArrivalTime: 29 Jun 2006 07:31:21.0122 (UTC) FILETIME=[0475C820:01C69B4E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 919b3965bd46f7460d234f848680b238 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0484692541==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0484692541== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69B4E.04440863" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69B4E.04440863 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Separate SA for each direction i.e. SA1 for RRQ processing, and SA2 for RRP processing is an implementation specific detail, IMHO. MIP4 protocol in RFC3344 allows that, no? =20 -Kuntal =20 =20 ________________________________ From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: Monday, June 26, 2006 6:31 AM To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 Yes, 131 is the error code indicating the authentication failed. As Sastry pointed out, this could be the case that data corruption occurred along the way. So when HA has an SA, it should send the RRP which is protected by MHAE. In this case, MN can authenticate the message properly. =20 For example, let's say there are 2 SAs between MN and HA. If HA fails to authenticate the RRQ, it would be wise for HA to use the other SA to send the RRP. =20 Kent =20 =09 ________________________________ From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 Sent: Sunday, June 25, 2006 4:38 PM To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails I think the protocol does allow an HA to respond with an auth failure. Code 131 was designed for that no? =20 However, as you point out an MN receiving a RRP which fails its auth check MUST silently discard. Silently discard means no more processing. Does that mean that the MN is not allowed to use the receipt of the RRP to stop sending any further RRQs? Some would say yes. =20 Therefore, why allow the HA to send an RRP when clearly the MN will silently discard it? =20 Is this a contradiction or is it by design? =20 ------_=_NextPart_001_01C69B4E.04440863 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Separate SA for each direction i.e. = SA1 for RRQ processing, and SA2 for RRP processing is an implementation = specific detail, IMHO. MIP4 protocol in RFC3344 allows that, = no?

 

-Kuntal

=

 

 

From: Kent = Leung (kleung) [mailto:kleung@cisco.com]
Sent: Monday, June 26, = 2006 6:31 AM
To: Avi Lior; = Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

 

Yes, 131 is the error code = indicating the authentication failed.  As Sastry pointed out, this could be the = case that data corruption occurred along the way.  So when HA has an SA, it = should send the RRP which is protected by MHAE.  In this case, MN can authenticate the message properly.

 

For example, let's say there are 2 = SAs between MN and HA.  If HA fails to authenticate the RRQ, it would = be wise for HA to use the other SA to send the RRP.

 

Kent

=

 

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Sunday, June 25, = 2006 4:38 PM
To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing List
Subject: RE: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

I think the protocol does allow an = HA to respond with an auth failure.  Code 131 was designed for that = no?

 

However, as you point out an MN = receiving a RRP which fails its auth check MUST silently discard.  Silently = discard means no more processing.  Does that mean that the MN is not = allowed to use the receipt of the RRP to stop sending any further RRQs?  = Some would say yes.

 

Therefore, why allow the HA to send = an RRP when clearly the MN will silently discard = it?

 

Is this a contradiction or is it by design?

 

<snip>

------_=_NextPart_001_01C69B4E.04440863-- --===============0484692541== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0484692541==-- From mip4-bounces@ietf.org Thu Jun 29 17:19:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3ut-0003Rl-4T; Thu, 29 Jun 2006 17:19:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw3ur-0003Rg-Uu for mip4@ietf.org; Thu, 29 Jun 2006 17:19:14 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw3uq-00058I-Gu for mip4@ietf.org; Thu, 29 Jun 2006 17:19:13 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k5TLJCVT025401 for ; Thu, 29 Jun 2006 14:19:12 -0700 (MST) Received: from [10.129.40.100] ([10.129.40.100]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k5TLJAFN012212 for ; Thu, 29 Jun 2006 16:19:11 -0500 (CDT) Message-ID: <44A443C8.5030003@motorola.com> Date: Thu, 29 Jun 2006 23:19:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Mobile IPv4 Mailing List Content-Type: multipart/mixed; boundary="------------060102060503020408090909" X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Subject: [Mip4] [Fwd: I-D ACTION:draft-ietf-nemo-v4-base-01.txt] X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --------------060102060503020408090909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI - the NEMOv4 draft, item of the NEMO WG is proposing extensions to Mobile IPv4 with prefixes in RegReq and RegRep (in addition to the Home Address) such as to have a Mobile Router supporting a moving network. All and any comments appreciated, Alex --------------060102060503020408090909 Content-Type: message/rfc822; name="I-D ACTION:draft-ietf-nemo-v4-base-01.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="I-D ACTION:draft-ietf-nemo-v4-base-01.txt" Received: from zuk35exm63.ds.mot.com ([10.178.1.42]) by zuk35exm62.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 20:50:59 +0100 Received: from az33exr02.mot.com ([10.64.251.232]) by zuk35exm63.ds.mot.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Jun 2006 20:50:58 +0100 Received: from motgate2.mot.com (motgate2.mot.com [144.189.100.101]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k5TJouhf018449; Thu, 29 Jun 2006 14:50:56 -0500 (CDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.179]) by motgate2.mot.com (8.12.11/Motgate2) with SMTP id k5TJot0X015788; Thu, 29 Jun 2006 12:50:55 -0700 (MST) X-VirusChecked: Checked X-Env-Sender: i-d-announce-bounces@ietf.org X-Msg-Ref: server-3.tower-119.messagelabs.com!1151610653!9309188!1 X-StarScan-Version: 5.5.10.7; banners=-,-,- X-Originating-IP: [156.154.16.145] X-SpamReason: No, hits=0.3 required=7.0 tests=MIME_BOUND_NEXTPART, NO_REAL_NAME Received: (qmail 30838 invoked from network); 29 Jun 2006 19:50:53 -0000 Received: from odin.ietf.org (HELO megatron.ietf.org) (156.154.16.145) by server-3.tower-119.messagelabs.com with AES256-SHA encrypted SMTP; 29 Jun 2006 19:50:53 -0000 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2XM-0006Hz-5H; Thu, 29 Jun 2006 15:50:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw2WZ-0004kM-8d; Thu, 29 Jun 2006 15:50:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=pine.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw2WY-0001YZ-VT; Thu, 29 Jun 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k5TJo2UA025391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Jun 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Fw2WY-0003Tv-Bu; Thu, 29 Jun 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: From: Message-Id: Date: Thu, 29 Jun 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: I-D ACTION:draft-ietf-nemo-v4-base-01.txt X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: internet-drafts@ietf.org List-Id: i-d-announce.ietf.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: i-d-announce-bounces@ietf.org Return-Path: i-d-announce-bounces@ietf.org X-OriginalArrivalTime: 29 Jun 2006 19:50:58.0944 (UTC) FILETIME=[57B40800:01C69BB5] --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Mobility Working Group of the IETF. Title : IPv4 Network Mobility (NEMO) Basic Support Protocol Author(s) : K. Leung, et al. Filename : draft-ietf-nemo-v4-base-01.txt Pages : 16 Date : 2006-6-29 This document describes the support of Mobile Networks, as defined in Mobile IPv4, by the Mobile Router and Home Agent. A Mobile Router is responsible for the mobility of one or more network segments or subnets moving together. The Mobile Router hides its mobility from the nodes on the mobile network. The nodes on the Mobile Network may be fixed in relationship to the Mobile Router and may not have any mobility function. Extensions to Mobile IPv4 are introduced to support Mobile Networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nemo-v4-base-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nemo-v4-base-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nemo-v4-base-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-6-29113121.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nemo-v4-base-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nemo-v4-base-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-6-29113121.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------060102060503020408090909 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --------------060102060503020408090909-- From mip4-bounces@ietf.org Thu Jun 29 17:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw44t-0004RL-B4; Thu, 29 Jun 2006 17:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fv0Os-0005W3-7P for mip4@ietf.org; Mon, 26 Jun 2006 19:21:50 -0400 Received: from dash.ece.ufl.edu ([128.227.220.23] helo=ece.ufl.edu) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fv0Or-00041R-09 for mip4@ietf.org; Mon, 26 Jun 2006 19:21:50 -0400 Received: (qmail 7679 invoked by uid 0); 26 Jun 2006 23:07:16 -0000 Received: from 10.227.80.48 by dash.ece.ufl.edu (envelope-from , uid 0) with qmail-scanner-1.25 (uvscan: v4.40.0/vJun 26 04:54. Clear:RC:1(10.227.80.48):. Processed in 3.538227 secs); 26 Jun 2006 23:07:16 -0000 Received: from unknown (HELO VENUS) (10.227.80.48) by dot.ece.ufl.edu with SMTP; 26 Jun 2006 23:07:13 -0000 Message-ID: <02c001c69976$5bc33bf0$3050e30a@VENUS> From: "Dr. Dapeng Oliver Wu" To: Date: Mon, 26 Jun 2006 19:15:05 -0400 Organization: ECE Dept., University of Florida MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_02BC_01C69954.D4A7FF00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-Spam-Score: 0.7 (/) X-Scan-Signature: 03bd269ff9197f68224a5792afcc9053 X-Mailman-Approved-At: Thu, 29 Jun 2006 17:29:33 -0400 Subject: [Mip4] INFOCOM 2007 CFP: important changes on page limits and INFOCOM mini-conferences X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_02BC_01C69954.D4A7FF00 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02BD_01C69954.D4A7FF00" ------=_NextPart_001_02BD_01C69954.D4A7FF00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [Please accept our apologies if you receive multiple copies of this = message.]=20 INFOCOM 2007 Call for Papers (a CFP in PDF is also attached): Please pay attention to the paper registration deadline, new page limit, = and INFOCOM mini-conferences (a.k.a., Specialized Workshops). =20 =20 The Conference on Computer Communications=20 May 6-12, 2007, Anchorage, Alaska The Twenty-sixth Annual Joint Conference of the IEEE = Communications Society http://www.ieee-infocom.org/2007/=20 =20 General Chair: Robert L. Baldwin Alaska Science and Technology r.baldwin@ieee.org =20 Technical Program Co-Chairs: George Kesidis Pennsylvania State University kesidis@engr.psu.edu Eytan Modiano Massachusetts Institute of Technology modiano@mit.edu R. Srikant University of Illinois at Urbana-Champaign rsrikant@uiuc.edu =20 =20 Standing Committee Chair: Harvey Freeman Booz Allen Hamilton h.freeman@ieee.org =20 Topics of Interest: Original papers are invited on recent advances = in computer communications and networking. Topics of interest include, = but are not limited to, the following: =C2=B7 Ad hoc mobile networks =E2=97=8F Addressing & location management =E2=97=8F Broadband access technologies =E2=97=8F Capacity planning =E2=97=8F Cellular & broadband wireless nets =E2=97=8F Congestion control =E2=97=8F Content distribution =E2=97=8F Denial of service =E2=97=8F IPv6 & IPv6 transition =E2=97=8F Multicast & anycast =E2=97=8F Multimedia protocols =E2=97=8F Mobility models & systems =C2=B7 Network applications & services =E2=97=8F Network architectures =E2=97=8F Network control by pricing =E2=97=8F Network management =E2=97=8F Novel network architectures =E2=97=8F Optical networks =E2=97=8F Peer-to-peer communications =E2=97=8F Performance evaluation =E2=97=8F Power control =E2=97=8F Pricing & billing =E2=97=8F Quality of service =E2=97=8F Resource allocation & management =C2=B7 Routing protocols =E2=97=8F Scheduling & buffer management =E2=97=8F Security, trust, & privacy =E2=97=8F Self-organizing networks =E2=97=8F Sensor nets & embedded systems =E2=97=8F Service overlays =E2=97=8F Switches & switching =E2=97=8F Topology characterization &inference =E2=97=8F Traffic analysis, engineering, & control =E2=97=8F Virtual & overlay networks =E2=97=8F Web services & performance =E2=97=8F Wireless mesh networks and protocols =20 =20 Paper Submissions: For INFOCOM'07, each submission will be limited to 9 = pages. Upon submission in EDAS, authors will be asked to indicate = whether they wish an abbreviated version (5 pages) of their paper to be = considered for inclusion in special-topics INFOCOM mini-conferences in = the event that the paper cannot be included in the main conference = program. =20 Important Dates=20 Paper registration with EDAS: July = 24, 2006 Full paper due 5pm EST, Tuesday, August 1, = 2006 Notification of acceptance Monday, November 20, 2006 Final version due Thursday, January = 18, 2007 See website for info on: Submission instructions Program and = registration Local arrangements Student and travel = grants Component events: Tutorials and Specialized Workshops May 6 , 7, 11, 2007 Conference Sessions May 8-10, 2007 Global Internet Workshop May 11,12, 2007 =20 =20 =20 =20 =20 ------=_NextPart_001_02BD_01C69954.D4A7FF00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
 
[Please accept our apologies if you receive multiple copies of this = message.]
INFOCOM 2007 Call for Papers = (a CFP=20 in PDF is also attached):
 
Please pay attention to the = paper=20 registration deadline, new page limit, and INFOCOM mini-conferences = (a.k.a.,=20 Specialized Workshops).
 

 

 

The Conference = on Computer=20 Communications

May 6-12, 2007, Anchorage, Alaska

The Twenty-sixth Annual Joint = Conference of=20 the IEEE Communications Society

http://www.ieee-infocom.org/2007/

 

General=20 Chair:

Robert L. Baldwin

Alaska=20 Science and Technology

r.baldwin@ieee.org

 

Technical Program=20 Co-Chairs:

George=20 Kesidis

Pennsylvania=20 State University

kesidis@engr.psu.edu

Eytan=20 Modiano

Massachusetts  Institute of=20 Technology

modiano@mit.edu

R.=20 Srikant

University of=20 Illinois at=20 Urbana-Champaign

rsrikant@uiuc.edu

 

Standing Committee = Chair:

Harvey Freeman
Booz Allen Hamilton

h.freeman@ieee.org

 

Topics of = Interest:     Original papers are = invited=20 on recent advances in computer communications and networking. Topics of = interest=20 include, but are not limited to, the following:

=C2=B7      =20 Ad hoc mobile=20 networks

=E2=97=8F   =20 Addressing & location management

=E2=97=8F    Broadband access = technologies

=E2=97=8F    Capacity planning

=E2=97=8F    Cellular & broadband wireless=20 nets

=E2=97=8F    Congestion control

=E2=97=8F    Content = distribution

=E2=97=8F    Denial of service

=E2=97=8F    IPv6 & IPv6 = transition

=E2=97=8F    Multicast & = anycast

=E2=97=8F    Multimedia = protocols

=E2=97=8F   Mobility models &=20 systems

=C2=B7      =20 Network=20 applications & services

=E2=97=8F    Network = architectures

=E2=97=8F    Network control by = pricing

=E2=97=8F   =20 Network management

=E2=97=8F    Novel network = architectures

=E2=97=8F    Optical networks

=E2=97=8F    Peer-to-peer = communications

=E2=97=8F    Performance = evaluation

=E2=97=8F    Power control

=E2=97=8F    Pricing & = billing

=E2=97=8F    Quality of service

=E2=97=8F   Resource allocation &=20 management

=C2=B7      =20 Routing=20 protocols

=E2=97=8F    Scheduling & buffer = management

=E2=97=8F    Security, trust, &=20 privacy

=E2=97=8F    Self-organizing = networks

=E2=97=8F    Sensor nets & embedded=20 systems

=E2=97=8F    Service overlays

=E2=97=8F    Switches & = switching

=E2=97=8F    Topology characterization=20 &inference

=E2=97=8F    Traffic analysis, engineering, &=20 control

=E2=97=8F    Virtual & overlay=20 networks

=E2=97=8F    Web services &=20 performance

=E2=97=8F  Wireless mesh networks and=20 protocols

 

Paper = Submissions:  For=20 INFOCOM'07, each submission will be limited to 9 pages.=20 Upon=20 submission in EDAS, authors will be asked to indicate whether they = wish=20 an abbreviated version (5 pages) of their paper to be considered for = inclusion=20 in special-topics INFOCOM mini-conferences in the event that the paper = cannot be=20 included in the main conference program.


 

Important=20 Dates

Paper registration with EDAS: =            &nbs= p;            = ;            = =20 July 24, = 2006

Full paper due            &nbs= p;            = ; =20 5pm EST, Tuesday, August 1, 2006

Notification of acceptance            &nbs= p;   =20 Monday, November 20, 2006

Final version due           &nbs= p;            = ;          =20 Thursday, January 18, 2007

See website for info = on:

Submission instructions           &nbs= p;            = ;  =20 Program and registration

Local arrangements            &nbs= p;            = ;       =20  Student and travel = grants

Component = events:

Tutorials and Specialized = Workshops

May 6 , 7, 11,=20 2007

Conference Sessions

May 8-10, 2007

Global Internet Workshop

May 11,12,=20 2007

 

 

 

 

 

<= /DIV> ------=_NextPart_001_02BD_01C69954.D4A7FF00-- ------=_NextPart_000_02BC_01C69954.D4A7FF00 Content-Type: application/pdf; name="Infocom2007_cfp.pdf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Infocom2007_cfp.pdf" JVBERi0xLjQNJeLjz9MNCjE4MiAwIG9iaiA8PC9MaW5lYXJpemVkIDEvTCAxMDIwODAvTyAxODQv RSA4OTU5MC9OIDEvVCA5ODM5Mi9IIFsgMTExNyAyNjRdPj4NZW5kb2JqDSAgICAgICAgICAgICAg DQp4cmVmDQoxODIgNDANCjAwMDAwMDAwMTYgMDAwMDAgbg0KMDAwMDAwMTU1OCAwMDAwMCBuDQow MDAwMDAxODMxIDAwMDAwIG4NCjAwMDAwMDIyNDIgMDAwMDAgbg0KMDAwMDAwMjYwMCAwMDAwMCBu DQowMDAwMDAzMDY4IDAwMDAwIG4NCjAwMDAwMDM0MzMgMDAwMDAgbg0KMDAwMDAwMzg2MiAwMDAw MCBuDQowMDAwMDAzODk4IDAwMDAwIG4NCjAwMDAwMDQ4MTcgMDAwMDAgbg0KMDAwMDAwNTY2OCAw MDAwMCBuDQowMDAwMDA1ODAxIDAwMDAwIG4NCjAwMDAwMDU5NDMgMDAwMDAgbg0KMDAwMDAwNjgz OCAwMDAwMCBuDQowMDAwMDA3NDgzIDAwMDAwIG4NCjAwMDAwMDgxNDAgMDAwMDAgbg0KMDAwMDAw ODUxMiAwMDAwMCBuDQowMDAwMDA5MzA4IDAwMDAwIG4NCjAwMDAwMDk2NzQgMDAwMDAgbg0KMDAw MDAxMDYwNCAwMDAwMCBuDQowMDAwMDExNDMwIDAwMDAwIG4NCjAwMDAwMTQxMDAgMDAwMDAgbg0K MDAwMDAyNjExMSAwMDAwMCBuDQowMDAwMDI2MzM5IDAwMDAwIG4NCjAwMDAwNjY1NTUgMDAwMDAg bg0KMDAwMDA2NjgyMyAwMDAwMCBuDQowMDAwMDY3MDQ1IDAwMDAwIG4NCjAwMDAwNjcyOTQgMDAw MDAgbg0KMDAwMDA2NzU1NSAwMDAwMCBuDQowMDAwMDY3ODExIDAwMDAwIG4NCjAwMDAwNzQ4ODgg MDAwMDAgbg0KMDAwMDA3NTExOSAwMDAwMCBuDQowMDAwMDc1MzA1IDAwMDAwIG4NCjAwMDAwNzU1 OTMgMDAwMDAgbg0KMDAwMDA4ODc2MiAwMDAwMCBuDQowMDAwMDg5MDI5IDAwMDAwIG4NCjAwMDAw ODkyMjQgMDAwMDAgbg0KMDAwMDA4OTUxMyAwMDAwMCBuDQowMDAwMDAxMzgxIDAwMDAwIG4NCjAw MDAwMDExMTcgMDAwMDAgbg0KdHJhaWxlcg0KPDwvU2l6ZSAyMjIvUHJldiA5ODM4MC9YUmVmU3Rt IDEzODEvUm9vdCAxODMgMCBSL0luZm8gMTggMCBSL0lEWzxGODM4N0U1OUYxMDREOUI5NjREOUZB NTI0QjNBMUE4Nj48NUE4NzdDRDQ1M0RGRkQ0MTg4RUFGNjZBNDE2MTAxQkE+XT4+DQpzdGFydHhy ZWYNCjANCiUlRU9GDQogICAgICAgICAgICAgICAgICANCjIyMSAwIG9iajw8L0xlbmd0aCAxNjUv QyAxNzUvRmlsdGVyL0ZsYXRlRGVjb2RlL0kgMTk3L0wgMTU5L08gMTQzL1MgNDI+PnN0cmVhbQ0K eNpiYGBQYWBgk2dgYGAMO8+ACljAmGMCAwOTagKSuAoUg0gBxnJGJ8YNjJ6MnQwMzMXM+gyJDFnM 0UyJTLmMAUw/GL2Y65jFuLz0jjMcmPOF4QXDLoarDA8Z7kg3MhxmmMbwx9iX4TnDfIa/DJowwxkZ GGPeAWluoHEpQJqPgTGnAUgzAbE1EPMwMCYEQfg8enAnCTEw1pmDdTMw8gIEGACtFRzYDQplbmRz dHJlYW0NZW5kb2JqDTIyMCAwIG9iajw8L0xlbmd0aCAyNy9GaWx0ZXIvRmxhdGVEZWNvZGUvV1sx IDEgMV0vSW5kZXhbMTkgMTYzXS9EZWNvZGVQYXJtczw8L0NvbHVtbnMgMy9QcmVkaWN0b3IgMTI+ Pi9TaXplIDE4Mi9UeXBlL1hSZWY+PnN0cmVhbQ0KeNpiYuJhYGJgYBzFgwUzzh2pfgcIMAAtEwKU DQplbmRzdHJlYW0NZW5kb2JqDTE4MyAwIG9iajw8L01hcmtJbmZvPDwvTGV0dGVyc3BhY2VGbGFn cyAwL01hcmtlZCB0cnVlPj4vT3V0bGluZXMgMSAwIFIvTWV0YWRhdGEgMTcgMCBSL1BpZWNlSW5m bzw8L01hcmtlZFBERjw8L0xhc3RNb2RpZmllZChEOjIwMDYwNTExMTUxMjIxKT4+Pj4vUGFnZXMg MTYgMCBSL1BhZ2VMYXlvdXQvT25lQ29sdW1uL1N0cnVjdFRyZWVSb290IDE5IDAgUi9UeXBlL0Nh dGFsb2cvTGFzdE1vZGlmaWVkKEQ6MjAwNjA1MTExNTEyMjEpL1BhZ2VMYWJlbHMgMTQgMCBSPj4N ZW5kb2JqDTE4NCAwIG9iajw8L0Nyb3BCb3hbMCAwIDYxMiA3OTJdL1BhcmVudCAxNiAwIFIvU3Ry dWN0UGFyZW50cyAwL0NvbnRlbnRzWzE5MCAwIFIgMTkxIDAgUiAxOTQgMCBSIDE5NSAwIFIgMTk2 IDAgUiAxOTggMCBSIDIwMCAwIFIgMjAxIDAgUl0vUm90YXRlIDAvTWVkaWFCb3hbMCAwIDYxMiA3 OTJdL1Jlc291cmNlczw8L1hPYmplY3Q8PC9JbTAgMjAzIDAgUj4+L0NvbG9yU3BhY2U8PC9DUzAg MTg5IDAgUj4+L0ZvbnQ8PC9UVDAgMTg1IDAgUi9UVDEgMTg2IDAgUi9UVDIgMTg3IDAgUi9UVDMg MTg4IDAgUi9UVDQgMTk3IDAgUi9UVDUgMTk5IDAgUi9DMl8wIDE5MiAwIFIvQzJfMSAxOTMgMCBS Pj4vUHJvY1NldFsvUERGL1RleHQvSW1hZ2VDXS9FeHRHU3RhdGU8PC9HUzAgMjE5IDAgUj4+Pj4v VHlwZS9QYWdlPj4NZW5kb2JqDTE4NSAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2Ny aXB0b3IgMjA0IDAgUi9MYXN0Q2hhciAxMTcvV2lkdGhzWzI3OCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDcyMiAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDYxMSAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1 NTYgMCA1NTYgMCA1NTYgMzMzIDAgNjExIDI3OCAwIDAgMCA4ODkgNjExIDYxMSA2MTEgMCAzODkg NTU2IDMzMyA2MTFdL0Jhc2VGb250L0FyaWFsLUJvbGRNVC9GaXJzdENoYXIgMzIvRW5jb2Rpbmcv V2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0xODYgMCBvYmo8PC9TdWJ0eXBlL1Ry dWVUeXBlL0ZvbnREZXNjcmlwdG9yIDIwNiAwIFIvTGFzdENoYXIgMTIyL1dpZHRoc1syNTAgMCAw IDAgMCAwIDc3OCAxODAgMCAwIDAgMCAyNTAgMzMzIDI1MCAwIDUwMCA1MDAgNTAwIDAgMCA1MDAg NTAwIDUwMCA1MDAgNTAwIDI3OCAwIDAgMCAwIDAgOTIxIDcyMiA2NjcgNjY3IDcyMiA2MTEgNTU2 IDAgNzIyIDMzMyAzODkgMCA2MTEgODg5IDcyMiA3MjIgNTU2IDcyMiA2NjcgNTU2IDYxMSA3MjIg NzIyIDk0NCAwIDAgMCAwIDAgMCAwIDAgMCA0NDQgNTAwIDQ0NCA1MDAgNDQ0IDMzMyA1MDAgNTAw IDI3OCAwIDUwMCAyNzggNzc4IDUwMCA1MDAgNTAwIDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIg NTAwIDUwMCA0NDRdL0Jhc2VGb250L0ZPSExBRitUaW1lc05ld1JvbWFuUFNNVC9GaXJzdENoYXIg MzIvRW5jb2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0xODcgMCBvYmo8 PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlwdG9yIDIwNyAwIFIvTGFzdENoYXIgMTE5L1dp ZHRoc1syNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMzMzIDI3OCAyNzggNTU2IDAgNTU2IDAg MCAwIDAgNTU2IDAgMCAyNzggMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgMCA1NTYgMjc4IDU1 NiA1NTYgMjIyIDAgMCAwIDgzMyA1NTYgNTU2IDU1NiAwIDMzMyAwIDI3OCAwIDAgNzIyXS9CYXNl Rm9udC9BcmlhbE1UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9G b250Pj4NZW5kb2JqDTE4OCAwIG9iajw8L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3Ig MjA4IDAgUi9MYXN0Q2hhciAxMjIvV2lkdGhzWzI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAz MzMgMjUwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCA2NjcgNzIyIDAg NjY3IDYxMSA3NzggNzc4IDM4OSAwIDc3OCA2NjcgOTQ0IDAgMCA2MTEgMCA3MjIgNTU2IDY2NyAw IDAgMTAwMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgNTU2IDQ0NCA1NTYgNDQ0IDMzMyA1MDAgNTU2 IDI3OCAwIDU1NiAyNzggODMzIDU1NiA1MDAgNTU2IDAgNDQ0IDM4OSAzMzMgNTU2IDUwMCA3MjIg MCA1MDAgNDQ0XS9CYXNlRm9udC9UaW1lc05ld1JvbWFuUFMtQm9sZE1UL0ZpcnN0Q2hhciAzMi9F bmNvZGluZy9XaW5BbnNpRW5jb2RpbmcvVHlwZS9Gb250Pj4NZW5kb2JqDTE4OSAwIG9ialsvSUND QmFzZWQgMjAyIDAgUl0NZW5kb2JqDTE5MCAwIG9iajw8L0xlbmd0aCA4NDkvRmlsdGVyL0ZsYXRl RGVjb2RlPj5zdHJlYW0NCkiJhFXbbuM2EH3XV8yjBKwp3iUuFotuHGORRQO0td6KPmgV2lZrU6ms wE2/vkPK8kqJhMKwObyfc+YMnT64Y+3s9lA+W/j0KX1cP9wDhc+f7+7XEP0dpV+3FPbnSDJJuDBG mQynKeicGEkp5RKMIjkzxnAGWmWEKowzDdUpSh9OFO6b6Ndo84inpb/cbmDDDekaz6/O4UwGcK5c xKCG2713RZQWhZ8rdhGFosJ1xQV/oDgDo7791w+1IHk4BBvFaEDRw9EU956iGJLiz2hT9FCEgIxr EPhpbbQb+koYpDUMqowRk08Xzo3hZq0EkX4o40TJydK5qZESfFBiypSgtszTXYVQetIs72XKPXFi OGihidaBXXGwsG7czrbWVRYah73T80tnWx+cXlxdlV3duPNbGTRXhHnKPCeCT5HPTI2QiwE5DbBC 7noSrCfRQ1eeBdOE9vnpI5ZrgndjoniP/7F8Bb1i/ANwSrMP8MVVh6Yt9xbDY3n+q5zgHqGQU/3Y SD/+Qz8e9LsiwOupJjkodK7Oe3v8HhQsLtZ1r6tz/U93QAjupTxCwuJvTe26ibw76HD5Q/JH8e1K MyRriC7IgiiuvDOf8OzNZoPbk5WKJ6nYNlVtu1cIx8xwU2OF2VhhPlbY3MrivcyMaCyILPP5DDQP Xff8MU0vHszlQmpr7ap2u6ZqTqRp96mXP50iQpcojSd4E2NFof8G21+HFfpwXDbUu/K2ZVo5cye9 nRLvvKYXvSZGT4Mc2IdAUA9Cos/elX+6fS7d7fBsaiExspAYsspCVtGv5lqEIeJIFe2kpPFN0Per dTZZybhF66wPZd1+nGh524GKAdLGh5J5sD3hCax8HtaPZL8BIyQjeT4CEy/VjJk9uTeTHhjzgfHg qBBxrQnDhOOb1vP9rflu2w5+JnCX5HHpqR+fLrVbNDWjixXLbnJfC/bt5cgQCxa9w/l1kYfw5ZjI 2L8RCAC2VY09m/AYC9UPlA77T1DYCnsHjF1zTBiNGwz3yYrHrxgso2WLaPk4E+9EEhJfPv9PpCS9 StWSJIu/lx7tU4LV54G6n3q4Ar8mtKTBuXa/jIgv+2KmAKj0/zr/UwFMLJfAzRA0ny0BwX0jc0Nk yAf8J8AAHKPf/A0KZW5kc3RyZWFtDWVuZG9iag0xOTEgMCBvYmo8PC9MZW5ndGggNzgxL0ZpbHRl ci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiYxV226bQBB95yvmcXlgw164RVGUxkmbtLIUNeQp6sPW Xts0NkSAW7lf35n1paYC10LALrvsnDlnLiy3k0VZTMwSnupqXpsVjKpgtDBF3Vz6+Q/vPvfuxyPw pJI8S0GnCZcgdEQTwUMJtfVm3sUTXF1djEePd7gG19e3d/jLbe5d5LkCAfnMC3kYhhnkE3CjGPJf IEI6IMRrO1Ix6CTiKeQr75V9slXtp2xu4YsfM+tL1hS+YlN6NOB/yz8fwB2bj7rmxdZ8QFZFurev 1JD9WPJUh2IL4cmWpR9ErNksf9LbuFlh4Lk1rYWX7dQt2bop2s0wrLgXlkOlHaohQDrjqdwDerPI gSYONGv8hN3YEkfz2o8YR5Le/QBZWuMnbpG66drBORKBLOHRqN3OCKkoNUcMW0NkhsGx8MdOJL3S Om6lorO3Q9nnixQZjzsC32+IuNbQs4RxRe9pYUo3GGYyPSFwfBBYnMLQEXlsmsZMFmsnNBFo2xbj K2bwuBW/LVq3iIpXM6CEcYgdzGU1p9fGFycQZ4Pay0Hp91A78q98oVjl1EeabtyUJi0p7qLwPMll prk8S3IZ/iebHe+R7o3eTPJIHiv+lcNzXbwZhFu2g3xJMZwr6lBBeoNsb7Ij8EtZ+CJkP522dbMn bIM3VPiY+QGpF7NHTKMlfqCbdpWVyzMwtB1ecLWmrd+Jfkyv0gQjOnhhnBAu+Qz9MaekHHZPDrsn hkvBzrNOPNRN7Vx7M2V7gw6sCUKxniA4KgdnRoOOYx6dFQyqNxj6qpbSPNY9hz2/m/LveSdahdwL LfZCdyNYhxzNSMnlLrawJJfTopxj/1qtira1FrCN+UGKUqJo9WVHj/3/aCEGoUKe6ON21oUZ9cM8 1qoDTiWCK32EbpjReJgBcWCgN7tknPEEdEjaOQIeTI0dAaNcMbuBj7W1OF1hy9qFgPgXNnZyldFw ugPoKlJ6yGrhmmSQ8AzraiC4UCntfWW3mAlV9ZsiDz4sXdJg6aGEoar5YGhh5RPxuNTS5hKzAf4I MAB76uZyDQplbmRzdHJlYW0NZW5kb2JqDTE5MiAwIG9iajw8L1N1YnR5cGUvVHlwZTAvRGVzY2Vu ZGFudEZvbnRzWzIxMyAwIFJdL0Jhc2VGb250L0ZPSExETCtTeW1ib2xNVC9Ub1VuaWNvZGUgMjE0 IDAgUi9FbmNvZGluZy9JZGVudGl0eS1IL1R5cGUvRm9udD4+DWVuZG9iag0xOTMgMCBvYmo8PC9T dWJ0eXBlL1R5cGUwL0Rlc2NlbmRhbnRGb250c1syMTcgMCBSXS9CYXNlRm9udC9GT0hMQUUrVGlt ZXNOZXdSb21hblBTTVQvVG9Vbmljb2RlIDIxOCAwIFIvRW5jb2RpbmcvSWRlbnRpdHktSC9UeXBl L0ZvbnQ+Pg1lbmRvYmoNMTk0IDAgb2JqPDwvTGVuZ3RoIDgyNS9GaWx0ZXIvRmxhdGVEZWNvZGU+ PnN0cmVhbQ0KSImcVNtu00AQfc9XzBNaS2S7F19RVUEDDyAhkPAbQmhjb1yDsxvZLhF/z8y6MUmb VpQH2+O9nD1n5uyUHxbvysW7jytYXHyGy8uLj6v3b0FlcHV1/RYHr8vFRVlKkFBuFoILITCqQEC5 B4n/CkNxF6k04SopJOhc8zQWMZTbxVd2wze9tdtIKmbc69Zay33fRN/KDwtBWGmASEHHKc/iu820 lUFU/jhLLz9LbwYS+GQJL86AfNkZ9xenOMXRE84y6EyIWwjjc2I1nkF61SSy9Lu2GsBvIFqm7L0b bZSy3g7jqyD0cH7YpbnMIcu5BsGLFHq72Byr0+LR5Mt0JkV1eMhKyhhhj4kB8kBOSin2qW8jKVgT LSVro5g5CkyHES3amZ2NctZHCRsixcD0FsJ694sWj/hYHK9xnpZ7R0FvK9rkaBYMzf0y9F/hyw4w nwI04ClCH2i2uw1wPQFVfhtl0/Ctow2VoUmKvBsgwCFuTWudpak9/nri+ROfcETDSWVJZ+wCxBAo 4vQmnD7poPAgg0oThFN1QkJlHIyNEdoCUyt4pjNYSi7RCTVmskUAhO5u6VPTy+IBL+mkNf2F8RG1 hNQ5H36ha6NlQvIEa0cbtsEY5l7CeBNQCGEThroufPYtooTTGnq9IswTGx27RR67ZaW+izu7zNe0 CP4ogmN1ylPyxaUQWX6FFwP9pQ7+iukCodTpyty79uqQHT0Zj+O1EFNi3tRw4yvY+nXboXBka6Ol ZuPe9z+Hx4mre8TlU8RVylVWZBN3WcRXDxnqmeFUvlRkB4Z0KWOBRGus+9C6Bl4Apjojr7XewdY4 00y8FdtatDORPsrN356XcC31cZ7OSdPnpR0Lknf96VjNXImZ+tlSZKedSfC80Ael17039dq4GkxV 2YFshyVYZmy01Y0jyZ1vWvtEWeLnlEUkPDlTln8Ucs9TJ0JWZmeqdvxN7RR2xJtqY5xryWDN4/yT Z/BXBTbK/ySfzO0if0jedt1th93BEGlscxl7Aeue0h9GagzWETZfrNO+7S12og6NCY6i8YnipM8R l8c8///ixLPLsA2eCmQr7xpsoHR1Ku/G3ncBAf4IMACaUuwwDQplbmRzdHJlYW0NZW5kb2JqDTE5 NSAwIG9iajw8L0xlbmd0aCA1NzUvRmlsdGVyL0ZsYXRlRGVjb2RlPj5zdHJlYW0NCkiJtJVLb6Mw EIDv/Io5VeYQxy9eUpRDkxy6UqoeuFWrFSFu17s8IiCp+u93IIR2E4hKpB6wEwPm+zwz9iq0VusF WNMnmM2m68XDEqQH8/n9EgfvQ2u6EL84cAhfLAZhDNi8QYAdw1a6IDxFHQhTa8Z4oObhH2sahqJ9 gbrMq9/YWgTs4612rgmjjDHezIi/pKqnZdQP5PH5Z7LIs0pnFWxNWRVms7c9Upk8A/tn+MNa9VD7 Y6hdRbkXeOPBG27vxC3cC+6lzkyUQP4CpS4OSG1iPQwdjIF2JPVvJBbdSvML4oengwt30HRVgcRR Vpqra63YGGwlqbp5rYU6kbPggnxtO2RvC5JUJo5K/FMhPdzVTZTZAXlvR4dF+BgRKSm/cf39LmOc S4s98qfIqbcmwg52RV5hn8d5Ug6jizHoQlDvWgwQrE2RTx7QV7TcOakov1VRnUm+MYmp3u2JTyDN 0WGrUeEOStsnOModUlY6vSIlz6TYkJTgAXVBShfbRop5/rmUcq9tPh8l0YSEU9Z6kEddveXFX4h2 uwQTqy6FRgLrGYu5tP//TIfGJWWe/PzJPkPVH7YzL+FS8T37UydXV3r829SZpvGK7Ykg1b7QV6Lj fDXlWgvu0OBGhY+jQQwqxHhEFDlqJLDBFhPMq4vHxCZ7HZZwR0owhzo9oejZXV112l07t2cCJ1rb VYykURa9Iqu2J5Kk9fk2yPnlU/jIKQKHim84HR7zg04g67KmThkdY6LUFnWuwD8BBgBYEedYDQpl bmRzdHJlYW0NZW5kb2JqDTE5NiAwIG9iajw8L0xlbmd0aCA1ODcvRmlsdGVyL0ZsYXRlRGVjb2Rl Pj5zdHJlYW0NCkiJpJVdb5swFIbv+RW+qmypOP7kQ4py0bQXm1Qta7mrpolSp2MDHBFotH+/AyQ0 IqEq2Q02Bh/e57znmOircxc5d/dL5MxWaD6f3S+/3CIVoMXi5hYWbyJnthQ/OeIoWjsMRQmCyw6F MDC4Ch5SD4lA0cAPfRTlzpzxUC2i384sisR+G/WY3+x7cTAi3aNDRMoYPGvCwkx4TWxGg1B2rz/h b5sqTWKicUZcjlFhYFrtbPmH+HhLJMT7EZ1nCCcy+IrqCwFkE9NtpvKUYGVM6VbW3cCIEgu687wu AKpKbbEd1a/ZRP2eovxiD7joEZQ+RSAKG+IKXK5tmRMPx0VikHnrfalbmHEWPpFFSxpc6IXXF5M/ 4MAru2stKKrSZu3ec1rFRK1KUnV53t/TLk/TXqZJWryiK0RcHz+nkPgsgwUSjJe9lhPlS0n5hdqD XjwYPBT/vY6ztALJf5FdtwBbU76REKcJLJpxADURQAjqf5R/qATR1cQRDRrwtBRMH2pHBnsedcB5 gL6FFpB4a+sSij/OMtu1MNiTx0X8anJTVONYeoDFxrAUk1QgKT2Aa5mYHwyZlHfelg6D9xiqCcwp e8ewddWU1KZsDqKq6Wmb2OyDY8j7rB173cKj4vJfwXj3PuHH5Jd5qdsG8DFk/bmGcb2Glm7z3xkk cGNDS3P01V4sl1QHx98/h+yfRx6Ack3D/2mcdnZ61j6apC67xiGuxtdwxKLmriQC19vqGgHnFfiX Nr0UJ22DjZr36f/4nolpqqeah/4JMADAhOEoDQplbmRzdHJlYW0NZW5kb2JqDTE5NyAwIG9iajw8 L1N1YnR5cGUvVHJ1ZVR5cGUvRm9udERlc2NyaXB0b3IgMjA5IDAgUi9MYXN0Q2hhciAxMTgvV2lk dGhzWzI1MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDMzMyAwIDAgMCAwIDAgMCAwIDAgNjY3IDcyMiAwIDAgMCAwIDM4OSAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgMCAwIDQ0NCAwIDAgMCAwIDAgMCAw IDc3OCA1NTYgNTAwIDUwMCAwIDM4OSAzODkgMjc4IDAgNDQ0XS9CYXNlRm9udC9UaW1lc05ld1Jv bWFuUFMtQm9sZEl0YWxpY01UL0ZpcnN0Q2hhciAzMi9FbmNvZGluZy9XaW5BbnNpRW5jb2Rpbmcv VHlwZS9Gb250Pj4NZW5kb2JqDTE5OCAwIG9iajw8L0xlbmd0aCA3MjYvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJnJVdT9swFIbv8yvO1eZINLWd7wlxwZfEJAYS0XaB0BRSt/WWxJUdqODX 79gtpaUtU3pjOx8+fh+/x8cMirFHA0ppCEUFAzsMEyjmQIMsD4FCMfLuyZ2oxwOlJ2UrX2U78VMC rejmSv814D8U372Lwru4PgNveAvHx8Prs6tziHM4OTk9x5enhTc8478ZMLeaXYjaJXLsKLYRDQMO PI+xLRrvmLI8Oin+eMOi4Ms5QULThRgC/uLTMpyTTBMX1IrPd4hvjdJWsIEvIJpHMRqJERg/Jy/+ gEXEdKLZz5HQnhxZFGRpnh6IwuM3lDjbgeIPYqKfpe0q2whQz4uXtW1LJMqJsQbt5WE9edIoiPvD OFv4yha2zTKXXTUV6IkfEzD4hH01xfTaL533lJ5EATvICqc+Xx2JiG/JL9RM1WriZzaJEgLVtNS4 7WXVCS1fy06qFvxBSr7IdizsF9FWYj9Z2JMsDoPsMCzOVlhxtI2ly/FYotwKyrascfBi0BdpmyNr lGgn0lEMPjgc21hZEKXLWKQVuBPt5AgPXaXaTqvaqdlFH/Wkj8Igyig7tFp8EL2xAT+l7p7KGkWr Z+uaru2ZsucpJf+teUncEyQMA4bpdWCCshXHdn7+Eo9gBJaKyh4xq34m9Fjppvw0D5OeAJwH6WdO 4GYvd3sNZZcpK5YotMsggNSixtKG9dlAsxhMsYrbgbXBIdD3W8tNI2hO2Y5gplWnKlWbvSmXroMW RbjinAPDeNxhLkZ4IXLGAp4sOMlmzLtZ2b6HzXaHXc86HvM9q7A8DHJ3B96T23LmygbcPT36CWmk MVhSzLcN59wcFmQZ4KUTZRg9T0ALb7yBmm9q2tj17E1UulMU49TGXRcGcIm36dWPy5uzm+uvNLXX zhGIspraERiUi33jM0qcZrxiGWndN+SYy7oG9wcayQjUssHCbx9H7pdOYW75D/BPgAEAN/T/0Q0K ZW5kc3RyZWFtDWVuZG9iag0xOTkgMCBvYmo8PC9TdWJ0eXBlL1RydWVUeXBlL0ZvbnREZXNjcmlw dG9yIDIxMCAwIFIvTGFzdENoYXIgMTE5L1dpZHRoc1syNTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAw IDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAzMzMgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1 MDAgMCAwIDQ0NCAyNzggMCAwIDI3OCAwIDAgMCAwIDUwMCA1MDAgMCAwIDM4OSAzODkgMjc4IDAg MCA2NjddL0Jhc2VGb250L1RpbWVzTmV3Um9tYW5QUy1JdGFsaWNNVC9GaXJzdENoYXIgMzIvRW5j b2RpbmcvV2luQW5zaUVuY29kaW5nL1R5cGUvRm9udD4+DWVuZG9iag0yMDAgMCBvYmo8PC9MZW5n dGggODYwL0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiZRVXW/bOgx996/gowzUqiTLX8Aw YGs6oAPaDajfhvvgOErji9Y2bKfD/v0O5TjttvTe7MWiKfLokJTI8nMQKamUTqmsCZLJqPxOJpax zUhRuQm+iT6MElGFiXhgwYWRFqOkMBUf9qyYwkzsWOiGkbXfm8dHap3bsI6mjjazWyLG5qH1WJOj vUft/D+N+zWvT6FWohnDKIdpx5oW2BT+U34OPMv4wDK3zDKKtcyynCItdTJTbUILn8gIul7hwA/3 ntDOTYy8cwNNMNixgfsBaaYLYdyxWLVUrfG3HlyYi2c2480qNIL9HNYNez27YWwYsWvZrdu+goUj +wzUVz3/zEd2nhNs146/NeLGoaH2thvv6M/0Im1BvWMQrHQMqX6EtB8bDwfdyw6NSFPvUWpPmC2j 6WDYL3HU4D/SDUDvuIaf4PSFhSvseeGWg0MRYpjDp2WnyGffXxJlD+lXuuD8qyXzK2QeIW05hpQp xaJ2I0RqfIKmnSP3fNybkJKc0xXjJtC0e6nvgq8SxtdGWlsst9An7pjUusLSLgngMKcwFoT0NliX fBVizwVzvmrzxnLWq2C0Pwx3ydjlMLByfPWQDIP6o04tLRFmS4Se0NA9DBV03lJyFuf7el0G17dX FFx+pXfvLm+vblaUKXr//uMKyo9lcFmWmnDyNlCeiOfADxCiOki437YoLOmkkNZwep4CwJf/nkTX J9HfxLSZLNT/YZqzMI1OZV4UyZlE478EPYupPQvUKiPN+UyTvwQ9i2n6K6g9gMoinzFZQJXSHHhK Zn+CxUpq3rRSpZQkWuYGXgkNLtgeN41MzbIJFDPvXt73aHJHKtlJKv55+FY7zwbfbHV8JBgfGCJg k0njCd489d0wVe1EK3T38Ve+s6mVcU6FxZsG2/g0ofw0oZcX8hsLbbiMr3i8mfXi9Ns7NLNDqKl9 4xmCv04gz7X9Jj7tucU++hEScVtCq0FnKtCZNnteCXqL4SSS3jdUb3Z9X15Q6fdHniXVD/TiC8IY 5dmaiL0frdOCSvqCDNSK1QpC+p/tJT/dXl61bi9a/XaMKpaJWmK866Zm29TV1GDMYcYxpaquXY8y o/nh32SFErddi0Au6K57dghVizV3R4xatjcKISCvIE0/BRgA1Jzmwg0KZW5kc3RyZWFtDWVuZG9i ag0yMDEgMCBvYmo8PC9MZW5ndGggNzU2L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFtDQpIiaRV yW7bMBC96yvmKAEWQ1KURAVBDllaJKiBABaQQ9GDYtOOW5syJDtB+vWdoRYvkE49iOt4OO/Nm3H+ 7D3m3uP0HryrF7i5uZrePz2AFnB7e/eAh3e5d5XnAgTkS48zzkUM+Rw45J8gcC9xydtVJFgMmWCZ 5mi+9X7639aB8m2xwRE+TKD9qqaTMoh9C0HiL3BxCELh0x0Ev/JnTyim0oweWKCD/J0sqjpI0Rbt ii/cT+C5QHvrfhz7RSD9is5B4KDJbIK+QeKO05c2nodwynOc8REnjxxOQixasJnuwOLKgU0jFvMO 7MwY+DRv9XpvYBmECcIMMTJY22UJpb0ejyIaZzulKEIXkBzlPBFMJ20QxMjbNhCRT0zXDd8WXCKI mhqZ2+OmOsxp6tNRHzMQsyQVXQZeKrpe4Ve5BDjXUNgF5a/CY4P0r9xbzm3Re7XjgNU4YNXRzsUo 3pizSDV4f5TzRl4FxVI5XaxITVuUDIVmKZ4aemgyjTpoM7o6LMjaWUGjKkzagnYOjsOMxx90bNxL q9NzZ+6eCETLH+8LJGzfCwUTStGjaJL/PlIy2xX2yEp8zoo6EeNRBkI7WqJejW6lkowlGoRMmSRi /PtyuyutsXswHzjW16fv9taKRTghs1gIgkUSKuMtL8NKhsM6toGLWGLNmcqy7CSac9QnQkjPfUeN b9FmHNOtNaMII8Zdwv38sC+rdbGpnQRnOzPHzfqvWcBrWf2p38tdPfqYHlSdYzXqq13pIdnFPGVC ECYumJSN9qbFFyRU6DBJaZoI4aYgxF6E1SE5bbm7G6+FbJCCrgK64m+KoedFpQnlTKcs7fJtl6Yy dm5gZrDqSzvKQ8ZHq08mR50Nll8sEiYpt2nMsr7zTRFsEUT+F7VdHeIoOA6TlgTkAL/xLpyJQQr6 rtf2A3lBgYoYpjSRTLWB+N835VuxgSe7N5U1+14So0zI/2FCMkGdKNYDJKASSA+Ef4KNCP+LGhIu /4vgnwADAM6csCcNCmVuZHN0cmVhbQ1lbmRvYmoNMjAyIDAgb2JqPDwvTGVuZ3RoIDI1NzUvRmls dGVyL0ZsYXRlRGVjb2RlL04gMy9BbHRlcm5hdGUvRGV2aWNlUkdCPj5zdHJlYW0NCkiJnJZ5VFN3 Fsd/b8mekJWww2MNW4CwBpA1bGGRHQRRCEkIARJCSNgFQUQFFEVEhKqVMtZtdEZPRZ0urmOtDtZ9 6tID9TDq6Di0FteOnRc4R51OZ6bT7x/v9zn3d+/v3d+9953zAKAnpaq11TALAI3WoM9KjMUWFRRi pAkAAwogAhEAMnmtLi07IQfgksZLsFrcCfyLnl4HkGm9IkzKwDDw/4kt1+kNAEAZOAcolLVynDtx rqo36Ez2GZx5pZUmhlET6/EEcbY0sWqeved85jnaxAqNVoGzKWedQqMw8WmcV9cZlTgjqTh31amV 9ThfxdmlyqhR4/zcFKtRymoBQOkmu0EpL8fZD2e6PidLgvMCAMh01Ttc+g4blA0G06Uk1bpGvVpV bsDc5R6YKDRUjCUp66uUBoMwQyavlOkVmKRao5NpGwGYv/OcOKbaYniRg0WhwcFCfx/RO4X6r5u/ UKbeztOTzLmeQfwLb20/51c9CoB4Fq/N+re20i0AjK8EwPLmW5vL+wAw8b4dvvjOffimeSk3GHRh vr719fU+aqXcx1TQN/qfDr9A77zPx3Tcm/JgccoymbHKgJnqJq+uqjbqsVqdTK7EhD8d4l8d+PN5 eGcpy5R6pRaPyMOnTK1V4e3WKtQGdbUWU2v/UxN/ZdhPND/XuLhjrwGv2AewLvIA8rcLAOXSAFK0 Dd+B3vQtlZIHMvA13+He/NzPCfr3U+E+06NWrZqLk2TlYHKjvm5+z/RZAgKgAibgAStgD5yBOxAC fxACwkE0iAfJIB3kgAKwFMhBOdAAPagHLaAddIEesB5sAsNgOxgDu8F+cBCMg4/BCfBHcB58Ca6B W2ASTIOHYAY8Ba8gCCJBDIgLWUEOkCvkBflDYigSiodSoSyoACqBVJAWMkIt0AqoB+qHhqEd0G7o 99BR6AR0DroEfQVNQQ+g76CXMALTYR5sB7vBvrAYjoFT4Bx4CayCa+AmuBNeBw/Bo/A++DB8Aj4P X4Mn4YfwLAIQGsJHHBEhIkYkSDpSiJQheqQV6UYGkVFkP3IMOYtcQSaRR8gLlIhyUQwVouFoEpqL ytEatBXtRYfRXehh9DR6BZ1CZ9DXBAbBluBFCCNICYsIKkI9oYswSNhJ+IhwhnCNME14SiQS+UQB MYSYRCwgVhCbib3ErcQDxOPES8S7xFkSiWRF8iJFkNJJMpKB1EXaQtpH+ox0mTRNek6mkR3I/uQE ciFZS+4gD5L3kD8lXybfI7+isCiulDBKOkVBaaT0UcYoxygXKdOUV1Q2VUCNoOZQK6jt1CHqfuoZ 6m3qExqN5kQLpWXS1LTltCHa72if06ZoL+gcuiddQi+iG+nr6B/Sj9O/oj9hMBhujGhGIcPAWMfY zTjF+Jrx3Ixr5mMmNVOYtZmNmB02u2z2mElhujJjmEuZTcxB5iHmReYjFoXlxpKwZKxW1gjrKOsG a5bNZYvY6WwNu5e9h32OfZ9D4rhx4jkKTifnA84pzl0uwnXmSrhy7gruGPcMd5pH5Al4Ul4Fr4f3 W94Eb8acYx5onmfeYD5i/on5JB/hu/Gl/Cp+H/8g/zr/pYWdRYyF0mKNxX6LyxbPLG0soy2Vlt2W ByyvWb60wqzirSqtNliNW92xRq09rTOt6623WZ+xfmTDswm3kdt02xy0uWkL23raZtk2235ge8F2 1s7eLtFOZ7fF7pTdI3u+fbR9hf2A/af2Dxy4DpEOaocBh88c/oqZYzFYFTaEncZmHG0dkxyNjjsc JxxfOQmccp06nA443XGmOoudy5wHnE86z7g4uKS5tLjsdbnpSnEVu5a7bnY96/rMTeCW77bKbdzt vsBSIBU0CfYKbrsz3KPca9xH3a96ED3EHpUeWz2+9IQ9gzzLPUc8L3rBXsFeaq+tXpe8Cd6h3lrv Ue8bQrowRlgn3Cuc8uH7pPp0+Iz7PPZ18S303eB71ve1X5Bfld+Y3y0RR5Qs6hAdE33n7+kv9x/x vxrACEgIaAs4EvBtoFegMnBb4J+DuEFpQauCTgb9IzgkWB+8P/hBiEtISch7ITfEPHGGuFf8eSgh NDa0LfTj0BdhwWGGsINhfw8XhleG7wm/v0CwQLlgbMHdCKcIWcSOiMlILLIk8v3IySjHKFnUaNQ3 0c7Riuid0fdiPGIqYvbFPI71i9XHfhT7TBImWSY5HofEJcZ1x03Ec+Jz44fjv05wSlAl7E2YSQxK bE48nkRISknakHRDaieVS3dLZ5JDkpcln06hp2SnDKd8k+qZqk89lganJadtTLu90HWhduF4OkiX pm9Mv5MhyKjJ+EMmMTMjcyTzL1mirJass9nc7OLsPdlPc2Jz+nJu5brnGnNP5jHzivJ25z3Lj8vv z59c5Lto2aLzBdYF6oIjhaTCvMKdhbOL4xdvWjxdFFTUVXR9iWBJw5JzS62XVi39pJhZLCs+VEIo yS/ZU/KDLF02KpstlZa+Vzojl8g3yx8qohUDigfKCGW/8l5ZRFl/2X1VhGqj6kF5VPlg+SO1RD2s /rYiqWJ7xbPK9MoPK3+syq86oCFrSjRHtRxtpfZ0tX11Q/UlnZeuSzdZE1azqWZGn6LfWQvVLqk9 YuDhP1MXjO7Glcapusi6kbrn9Xn1hxrYDdqGC42ejWsa7zUlNP2mGW2WN59scWxpb5laFrNsRyvU Wtp6ss25rbNtenni8l3t1PbK9j91+HX0d3y/In/FsU67zuWdd1cmrtzbZdal77qxKnzV9tXoavXq iTUBa7ased2t6P6ix69nsOeHXnnvF2tFa4fW/riubN1EX3DftvXE9dr11zdEbdjVz+5v6r+7MW3j 4QFsoHvg+03Fm84NBg5u30zdbNw8OZT6TwCkAVv+mLiZJJmQmfyaaJrVm0Kbr5wcnImc951kndKe QJ6unx2fi5/6oGmg2KFHobaiJqKWowajdqPmpFakx6U4pammGqaLpv2nbqfgqFKoxKk3qamqHKqP qwKrdavprFys0K1ErbiuLa6hrxavi7AAsHWw6rFgsdayS7LCszizrrQltJy1E7WKtgG2ebbwt2i3 4LhZuNG5SrnCuju6tbsuu6e8IbybvRW9j74KvoS+/796v/XAcMDswWfB48JfwtvDWMPUxFHEzsVL xcjGRsbDx0HHv8g9yLzJOsm5yjjKt8s2y7bMNcy1zTXNtc42zrbPN8+40DnQutE80b7SP9LB00TT xtRJ1MvVTtXR1lXW2Ndc1+DYZNjo2WzZ8dp22vvbgNwF3IrdEN2W3hzeot8p36/gNuC94UThzOJT 4tvjY+Pr5HPk/OWE5g3mlucf56noMui86Ubp0Opb6uXrcOv77IbtEe2c7ijutO9A78zwWPDl8XLx //KM8xnzp/Q09ML1UPXe9m32+/eK+Bn4qPk4+cf6V/rn+3f8B/yY/Sn9uv5L/tz/bf//AgwA94Tz +woNCmVuZHN0cmVhbQ1lbmRvYmoNMjAzIDAgb2JqPDwvU3VidHlwZS9JbWFnZS9MZW5ndGggMTE4 NTMvRmlsdGVyL0ZsYXRlRGVjb2RlL0JpdHNQZXJDb21wb25lbnQgOC9Db2xvclNwYWNlIDE4OSAw IFIvV2lkdGggNzA1L0hlaWdodCAxMTcvVHlwZS9YT2JqZWN0Pj5zdHJlYW0NCkiJ7Jd/UBXXFcff vn3wRH4YFBVRQAT5IVIFUfGJvIKCYlN/RBu1xoBARAUDEWNiUiWxTWtry9Sx42haG2sZW5NOZjqZ TNN2lKghWqvJNJkmmWI7Jo0INNP6A5lGxpkeve1m2ff27r377r63fZ7P3D/g3XvP/d5z7+757p07 CIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIg CIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgyH3Ei4fb Z84u8cwrJw3+rqtvpozf23aAjJ9TPL+4pOLDj7pMLNrff6t80bLZnlJlXW0rXlDkKTvTeZ6M7+7u 9ZYthl90xw9toHBjwzYy95cv/1q9QdqsIu+yh9aa2A6CIAiC3IesfqTOMZTk1AzK+PLKZerBv/lt h4lFe3r6nJLkMOLAwSNk/J/e+8BwsIaJk7LI3C3NO7gmJo5LTkxKOXzkF//81zUTW0MQBEGQ+4Tq 2kZNDc3IzKWMX7J8jTISTMCJk2+ZWLSv77PISLdhNX/9jZNk/O3BQdkpczmBrJxpZO6TTz/PNVEh LT171+7v7T9w2MQGEQRBECTsqa1v0pTOzOw8yniNhXj73EVz67JYiOkzPAsWLoVW7K2QJInLAORM LSALPf+tH3BN1OCUJM+88iM/f9ncNhEEQQw50dH53e//CNqSZWs0rWV7K/x+tP2V0Cok8qpqGjTy yO8hkWT/pIUr3d29n/z9yqdXrkJbvbZOUzQjIiJTJmaQNiF50uTsvL6+z5S5Ggtx/FevkTjQIOb1 GzeVkR9+1JWWng0RlGhKS05Jd3JaAl7AopC1Ro4aIyTaSz873t9/KxTHhSBIGAIFzltaOSFlEvuL KD4+AaZAfQyCvK5Ll8EwwBel2z2MRRsMyy/0WG0nbJ60+wGo8iNGjHRKTpfsguZ0Oun5h0oP3kCZ XlG5XN0ryzKJA02SpOraRmXkufPvsp/y/wXJqRl79u6/PTgYinNjxdeQUxoljl9vb12DlxVq0NMg BCEXA777uOKwfwb6ft5SGsgQFSokRwZTGOuyHvACh6WhyvMuzQKkF8yAaW2wNSuucciTxnv5uZ6s kC/HzrXrNyMiItWJTUvP9pYtJm1mkVcamnbwBp9euapM/+H+H88pnn9vcGVc3AOaM1q9tk4ZeeGd 952SJph54PKUlC4iLWl8qqiwJiicXWLFuYiCay+UOHD9LEqgX+CzAjXoaRAClwy9IGCouOJAJWKU x/VdSf/U5QoVOFxHBsoDrINqSE1kX90QKK/e0koh2iAt7AaSjk2Sxnv5/UK/umpatrcGvpyJbRoC FkJzHFuadyi93d290tC6r7EQanLzZmgEf33dBqWXxUIUeyt2tu7xbfC7ZmTKxMlK5IdWrjObUTHM 9pT29PRZcTqBw7URShw7lE7UIBAuGXpBeN+i8LpmlHc/WAiL7hL4NCj9jBooQMUXWKkd906fvWLa P2lCLAS7exGycf58G+NrIaprG5XezrMX2C1EVs40jeD6zS2qhW7AFaJvsG3fIb+R4XfNSFtZCMe9 tNTWNwk6E5Fw7YISxw6lEzUIhEuGXhATb1H4mGKRF/YWAmqWdRoys/NYNFAA/2D4ujZHIC7CVkkT YiG8pZWMy4G8wJfjzjgDYCEiI93qVapqGpTeuxZiqAbZKetZCN89gqlYuaqatEVfWaEJ5UtG1tQF C5eStnzluhUPV5GWm1eoGTl8eIzSm5qWaSabFrBh01YrzigQuPRT4tihdKIGgXDJ0Ati4i0KVYBF XnhbCCgcVstgzLNfTnR0WuQfAIgM/sSEKrslTYiFYH/A4+MTAl/ORNoNuX7jJpRjCC7dA/5YX7dF 6QULITud0v964Y/ICLeehciZWqDEUaKpMbQQ0wvmPLp+891WvclwsD2prm204phMwyWeEscOpRM1 CIRLhl4QE29Rt3sYi7wwthBCSg8LcFdZUh38jEE15JVkw6QJkQSGinG5wNdyWGMhbg8O/uGP755+ 6zy4BWgdp852d/cqvQMDA/Cj0gt/vH3uIkzxG+rPH/wFppOR0FauqlKLl53ya6///kzneWgbG7b5 3eDO1j1KtOjoWE3vMztfINPbj72q8Sfwz0tHj5Pe53bv5cpqwuhxZCK0L5ct5prrl0eq6q04KXNw KafEsUPpRA0C4ZKhF8TcW5TlIzRcLUTXpctgooKjBMrTiY5Ow1RrCM4N57I39kyaKFcDuzNcCx4Z IWux59wONLd8Qy3e5YpQutr2HfK7wWd3fUcZ42shTr75xcn6WoiPP7lCusCocGV1/ISJStgVD1cZ T2Bgw6at1ieYCS7ZlDh2KJ2oQSBcMvSCmHuLeksrDeWFq4UI8v3JL/QYploNlDOooUEQBquwlE47 J02UhaDfXkJVTYOQtRgTbhM2NmxTi3e5XL29/yBd3/x2m98Njk2ckJObT5pzqEkAUlIzSFdG1lRN Fwy98M77JHj7sVe5sjouKUXR/NVlq7nm6iHZxkVwyabEsUPpRA0C4ZKhF8TcWxS+KA3lhaWFCFqB VgMfsIbZVgjm9Ya1WCTZNmmiLARLHkSdC0vCrWbK1AJ4A8TExEGDPx5cukrpKppbpnRBi4x0a/Rf vdpHRupZiEAY5o6KioqG5rsuHckhkYnQZFkWKKm6tjFEp/QFXIIpcexQOlGDQLhk6AUx/RY1fEWH pYUI8uUh5Bd6DC+DQjCLNYuTtHPSRFkIlrVE3WGWhFvNmLHj1ZJmFXmVrvTJUzSCR40ak5ObDy0r Z9qMWfOuXbtORrJYCKckkbnQxiZOEJLA4PPYxuYQHdR/4VJLiWOH0okaBMIlQy+I6beot7SSLi8s LUR8fEIwlRDAFXRdumx4H4CqmoYga2vZ3mqoyrZJE2UhWJ5xsFtC1mK5BlYzPjlNLckzr1zpAp+g EaxXQFksRHR0rDJ+Z+seTW9MTFx1bQO0uSXlhqFkWX50/WYYvGR5CAxtbX2T1YdCgUsqJY4dSidq EAiXDL0gpt+ihl+g4Wchjra/EkwZasAbsFyJzOy8IAszdJJ2TpooC+FgqOxBWygIJKemqyUZWYgn /AY5cPCI4WbpFiItPZt0vfG7Nw1DRUVFK6EMB1tBzWOP3+y/Zcl5GMGlkxLHDqUTNQiES4ZekEDe olAdKPLCz0IEcnPAccXHJ5ienl/oEX4l1Dglpzl5hk7SzkkTaCHoz0IwvYpwenr6mrY+29j01Jbm HaTFxcWrJdEtxJemz2psetq3lZRWGm7W5YpQxs8q8mp6Y2MfIF1l5Q8ah5JdDU1PweDVa2sNB1uB 5JAuXHwv+Md3By1EOGoQApcMvSCBvNwgkxR54WchzMnIzM470dFJIsAf5oJAiTe8D+aOEiJX1TQo EeBf3ghdly4LP7vgJE1gZW/Z3kpZSOA7x/AaCOfU6XN0SbM9pcrgjMxcUTsNP4q9FcE/vjshshBg 4OH5CqT5teWoQSDsu3BYYyHgC5EiL1QWAs7XoiPjz5BDqc5qvAzfX74YXiQTdQpOUGMAYBXeIPSz 443mCGLSBFoIup02J94v1CtgCZ1nL0iSpNYgO+W2fYd+8tNj0A4cPHKm87wyuGBmMfRGRrpJk2WZ vh3JIe1+oe3Fw+3Qajc0icoSYcHCpSQyNLd7mNjgJohwRfz1bx8H/wS5RFLicL1h6E+EaVCDQNh3 4bDGQgDKp6IvobIQ9FCmMVFboXDoRcvMzuON5rewquHKEuCUnH6PD2wzVxzKM2LzpAm0EKBN4NFQ oKxiEb4WwiW79AYPDAxcu37jZv8t0urqm+nbcUqSeiFRWSJsfXKXEjwmZoTY4ObImz7L2tPyB5dC Shw7lE7UIBD2XTgssxCU/ISZhYBixJUZ+OqhROu6dBkqOFdASm0l8AbUK6/gK0QJs3nSBFqI+PgE gUdDgbKKRfi1EP/+/HOWuVDEDXdUMHPunOL50LKnTBeVJcLjTzyjKLGJhcjJzbfsoHThUkiJY4fS iRoEwr4Lh2UWgvLmDDMLwXVtHPoF2nRASAIlGpRXrmj0Yg3HKkSYzZMm0EI49B8x3qMxt4p1nDp9 zlfGmMTxiUkp0OJHjv7amvXK4PkVS+AX0gUtNjaUhTtq2PDRY5PutjFJ/2G/WmOjuK7w7MNeY4zN UjsUv98P7PUD2zg4tY0NDhgDFmBepsbGgPOwG4KcuG4T1y0iAoECFY2cFJUWWU6oZBHyo0JVG0L6 QG0CChAIrWp+uG2iRhQIJKQJWCv1kBGj1ezOnXN3zqzH5n66P1Z7z/3ud86ZnfOtTT88FJhbMC/0 HeRSyOCxwugUGgiBz0IyzUIA4E9rQOYpZiG4NMC/ThgcbEKoG55Q0hv6vH1kP9glZZV4KsaYnmJF Y0PrwQuNUTEPFy/9LTU9Jyk5Izk1U15Oh9NXUnlFtRKcnpmnEhwd7VYOxiekEJbCYXfAAwYLTAsh rT/CnGHyRbDCw8KNUAkLYRBCAyHwWUhmWgitEk0xC+F2x+I1ZOd6MJxceUnMX3dbRxcX1dDwCION 6zfCEGbxotEOd2gBSTHZwJTIbCQmZ/hKqqyqV7Zy8opUgju2P+N7dmnjmtrFjYuXNOV7SnWTBZOw qH6FvDKz81W74ElkzsNHhg1WlY3i0gWK/rKKKiNUwkIYhNBACHwWkpkWAsZEQOYpZiG4aoJ8bHiH C2Puc1G5XBFsYbxPxSQtGq2F0NJfUlZJeAumRGYjISnNVxLbQrS0dgYkOX7ipG6yUVHRSvz+A4Oq XcVCHDl6zGBV2SgprVRklFdUG6ESFsIghAZC4LOQzLQQgNGrY/7MD7OFQGrgLT6Dtqa2Ac+Tneth C4OxyyVskhaN1kLAUxrwFq6nVxeYEvHi3vj44GtH9+w7BGMa1u49B8+eu8iID9pC3Pzs1ss//fm+ l+/f0rR6k26y4WHhsiRYdfXLVbvuWXHy1qrmVmNF1UFyapYiIzU9xwiVsBAGITQQAp+FZLKFaOvo 8meeShaCt0p4Zi7ant4BLR6uEmGeai5hYDkmY9FoLYTLFWFcrS7wVcLj9udfOJ1hvre0bO5kxMfG zfENLq+oVraycj0qwRs2bVN23zt7nrYakw7CQhiE0EAIfBaSyRYi4L/ah9ZC2G12PDME45kZTyNX iQJaPhXwbJJGza1fNFoLARi9Oqa6AswV7RX4KuFx6/YX4H98b2nf2s2IH3zt6PN9P3lxYA8s+HD8 rZPKVr6nVLrfTZu84PPmLU8ru+c+uCR/qYLtmxVKFBSW9Q/sldeMGTEhu1dYCIMQGgiBz0Iy2UJI gV6eD62FALV4Zq7UGE+j2x1LWyI8mxah9YtGbiH869DTO0B7Bb5KePBaCAbgPfDX98+DVZAXfP70 02vKbkAL4Z4Vd/bcRVgDu/bR1oqBdRs7FFUJiWkhuzcja67RbvGDSyGDxwqjU2ggBD4LyXwL4f/H dipZCK5nZkKmIZ4EWSLjNbd+0cgthP9dXEXAAF8lPAgtBBsBLcSchBR597e/e5e2Vgys3bBFURUy C2G327t39JlRWDa4RDJ4rDA6hQZC4LOQzLcQ2bkeFbOwEBjU1Dbgmf2LrABPgiyRlS0EVdHILQQI U10Bt9Nega8SHmAhnA6n7y0trZ2Yg9euXS8oLE/LyM3MzvdfGVlzk1Ozdr10QIkPaCEcdkd6Zh6s +IQU2loxEBUVI18Ky+FwhObS6JhZZrRPF1wiGTxWGJ1CAyHwWUjmWwjA6NUxX+aH1kKUlFWaxMyY s3gSCTeG2jq6QBtynTp9ZjIWjdxC+N/ldsfSXoGvEh537nyZkpYVHT1zpjsW1vSo6Of7fow5+K9/ f2LzswQqrFm7WYkPaCEeHkybFnnk6LGProya0UQGuEQyeKwwOoUGQuCzkEJiIWDo+DLDUMCfnUoW guuZsayFMA7rF43r4cc8hHabXXUFhhlO4WUE2Qxz8PEn/wlzhrEFt7R2KvEYC5GYlFZcusB/wfe6 xZlbME8OzszOx5cUAFkoF8XGzeE6y4uO7c+EuE1c8hg8VhidQgMh8FlIIbEQqj+SXHUWFgIDrWk4 NDyCJ5GEhXgArocfaYlPnT7Dy+9yReBlGGoJNe6Nj5NbiP6BvQHvgu/ZB22S7b/Xb8rBb7/zZ3xJ AQmJacpF61u2cp3lRdwj8Rc+vGJqX1TgksfgscLoFBoIgc9CComFUP0Fm0oWgktA6KchbxOJqqID ixfNy1k3uBSecN0w38evraMLqRAvw1BLKHD+wuXXf/3W8RMnYf3il284HU624Cee7lHO3rr9uW4N u3f0BbwXvmcfBAtx4+YtOfidd8/gSwpISAqdhQD0vbDb1B6pwKWNwWOF0Sk0EAKfhRQSCwHo6R1Q mIWFwEBYiIkqmpffQmAy8k0EoxM4J5eFqK5dilcLyPeUtm/tlteq5labzcaO7x/YG/De7U/u1L2r afWm9q1dsBbVr+ASGRk5XT4IKyungOtsEHDYHa+8+quQtYxLG4PHCqNTaCAEPgspVBaipKxSYRYW AgOuKkkafRQWIrh8eS1ETW2DbpjvTwBTAeCcbBZCvwhGEJ+YWlBUDivfU1a1cIly7+/f/uPm9qeU QX/fjehRFRbPl4NnfzvRVM1BwOlwHjx0ODQt4xLG4OH93RmB0MDWQAISJbQWwm6zB1dnQgthEAFn mcWnobAQweXLayEw90LWCr/LFYGhnVwWoqZumUoSTOrjJ04GXI0r1/mnMP/RmpHjv/Ff3Tv6VJEw Z7VkfH33rs2mYyJ6f7BLDp5X/hi+wrpwOp3Db7wJgvcfGNS1MQx8p+bx0LSMSxWDxwqjU2ggBIkS WgsB6OkdCKLOwkIgQdJEvDwjsHjRvPwWAhkvk49eHcMEA+dktxDVtQ1awc/2vOifwspVgXv9pzPv qyKnT5+hxfy/r76aKAsRHu5SZNgkIyZCal7fHmQbeMAlicFjhdEpNBCCRAm5hah58D5p6+jCnxIW AgmSJuLlGYHFi+bltxBIVzA0PIInB04LWojtT+4sKCyDyQsLPrS0dipb/haisqpei6drx/f9U3i8 YZW8+8P+l4pKKopLF8grIzNPFWm32ZVd1cr3lOrWKiExVQ4GK4KvsC7AuhR+I3tuwTzjbGs3bDG7 m1x6GDxWGJ1CAyFIlJBbCJcrIghmYSGQIGkiXp4RWLxoXn4LAUfg8daN7OkdQIqUfywWtBA5eUW+ lyYlZyhbj1bWqSSVzq9Sdr++ezc1PWfGjJkz3bGwIiIiVcHRMe4PLlyWgx+rqscnPoXRtLrF1G5y iWHwWGF0Cg2EIFHC9RaFPwWYMK5/YTKEhUDCeBO1SMhh8aJ5OesG6SCTknOpqW0g5FRguC0oFBbP 9700Mztf2Xqq+7mUtCz4Rl7wedsTzyq7YCHCwsJ9z8bEzErPzJMXuIvGleuU4EX1K/CJ+8PpcCrM UVHRRqgmHGs3bjGvm1xKGDxWGJ1CAyFIlHC9RbNzPZgw+RUqLAQGwkJMVNG8QVkIzNXwM0GmL2c9 uSyELiIjo3zPbu3coRW5tHENPnF/pKZlK1TN69uNUFkBLa2dhnqmDS4ZDB4rjE6hgRAkSrjeosjS ud2xvMzCQiBhvIlaJOSweNG8QVmIto4u3Uj5+bfb7LqRwMZbKMNtQQFvIe7c+fLS5b9/dOUf8rrw 4ZWIiEjfsxu/u10JhoD4xNRvxc6Omx0PKzwsHJ+4P+ITUuBqeS2sW2aEygqAstwbHzejm1wyGDxW GJ1CAyFIlHC9RU+dPoOPFBYCA2EhJqpo3qAsBPKIF/fzHBoe4S2U4bagkJNX5HtpUnKGVuSrh4ds kmS32R4stXHytRDvnT2PzxQD24M1NZCXX3Ljxmfk3eTSwOCxwugUGghBooR30LtcEZhI+HsFr0cu ZkamwkIoMN5ELRJyWLxo3qAshBf3u4PnHy/MghbihR/tqatf0bC8GRZ82Plcv1bkoVeOsAX7Woiz 5y5OmXFvEvI9pffGx2m7ySWAwWOF0Sk0EIJECa+FKCmrxERCGJdCYSGQMN5ELRJyWLxo3mAthNsd qxtcU9ugGwM8MiHSlssw0hEz8LNBSguRkZm3/8BgwFVXvxxfJRnVtQ3y2eTULNVWcekChTkmZhYv s6nwFJVfu3adsEdctzN4rDA6hQZCkCjhtRA9vQOYSLvNzqVQWAgkjDdRi4QcFi+aN1gLkZ3r4bpd C7LN9tK94ScEtBZi4aJlWhfBrOcqFGD3noPy2YrKWtXWlm3fU5iTUzJ5mc3GkmWrCXvEdTWDxwqj U2ggBIkSXgsxenUMGTw0PMLFzMhUWAgFxpuoRUIOixfNG6yFoHqBKClznTLSEQWn//CXxUuaGpY3 w1rauGZ50/qxf36s7L5+7M26+hXyLiz4vPP5fi0qWgsR+8ichsY1AVd2biFXoQCZOQXyWbc7VrUF tkHegvQjXNN4mc1GVc0SkkbL4LqawWOF0Sk0EIJECa+F8KJHA1edhYX4P/tVA1PVdcfvF7wPHigt RmsFERDfVCggoFAV0TQb2prZqlWDSv1ot+K2ZKzMdTNYda2tnbpi0Go7DRKzFj/SdDVmFV2ZRKek ympr1+cHWqUxOuq6zoiEZP/mJNfLfe+dd/73nvu80PvLiTGcc3739/+dc+//9xhh/hDDkXCHzU3r MRohqqprUE8PB/XOo3aZOREV617ZpKP9qPmEOjuvfJluNnl4ejiqjW9spwvWRoh/nDqNKvZ7i5Kp 07kcNAHq0RQe1HvncrnhlTE8HA10DVzAXoXA6SsKH092A1EdhGOEgF8cZo5s8ZJKkwKcCEFgc9N6 jEaI+oZG1NPDoeloCyFE7TJzIio2bKzTcoqi2HK8VZ2tWLpC99CMzDHhqP787ntJg4YMGZqiDkkU tXu1EeLTz74YOiz1waTBgwYP1Y2kQQ+xlB8fP5CsT3xgEMq3voXxxaVcDpoA9WgKD+q9Q73R7HA0 cAR7FQKnryhxAz59jOvZmwjHCEGnMgabd0MnQhir11iE6EG+eiEhiZIxNmNnoQPHCBEMr9en3Vu+ 6DnGjYoSE7H8vQcOksU3bnaKvbNKv4EkSTVrNrAbHhGop1N47NA6HQ0cwV6FwDVCABITk1BPjwgn QjAiJIkTIYzVazhCoEqLyIbaaOwsdMBGiEx/Fju5LkLMnf/MN9/8F8atW/+Bf9Vld7u7yd/JuHjp iqIoEcvfUvcnsv7EydP9MkJMmTajbtsuLqesAiWAwmOH1ulo4Aj2KgTeEaKktAz19IhwIgQjQpI4 EcJYvYYjRG5+MUpAMOANUtlQG42dhQ7rXtmko/2o+YQ6O698mW4Wam/Ys5+MXbvffWfv+3e6usji jo7r8BftrCRJ2r2yJMfGxMKIUWIGDHzwxs1OsnHjH9+Ev5Cp72ZjYlnKV2RFZUP5ZnPE+RJgzJg5 l8v56oBSQuGxQ+t0NHAEexUC7whR39CIenpEOBGCESFJnAhhrF7DEQIrIBjaelEbjZ2FDh8cOpKX /2jhhBIYBeMnTyieGjjfrs5u3V6fk1dEZmFk5xSKvTVASLjy5TWyeHPtDp3CMdn56t6U1JG9NorS 9es3yMbVa183Ytz9gM+XAC7BSE5Jt+gRB947xOVkQwKlhMJjh9bpaOAI9ioE3hEC4HK5UQLocCIE I0KSOBHCWL2GIwTW8GBobylqo7GzMIOOjuui2CtEyLJ89dpXZLa27m3tFKzTppEXVr6knVUURY0Q a1/eGLHYWbMXrvjFShizn65gMWfBwuVk/YyZc1nWMyKv4FGiufo3azjSapHpz7buBFFKKDx2aJ2O Bo5gr0KwIEKUlJahBNDhRAhGhCRxIoSxeg1HiKajLSgBdEmGN0YHLcdbdRFCkRVKhGg6ckzd+9zz VdrZGCVGndq6vT5isW2fnCOLA4FLEReLgvjvzltk/eEjx9jsZEIUIgSI33fgoEUniFJC4bFD63Q0 cAR7FQKnryjEBnVjfUMjSgAdToRgREgSKyKE+dfE5qZhfdNGCIAkSigNWrhcbi0Vai+7S+xYv6F2 /sLlFUtXkLFg4fK/HDysznKMEJIozi9fVrG0EsaE4qkRiz3d9inh+dcXFyIuhi5842YnWf/h4WY2 O5kweMgwojk7p5AjrQ6paaOsONweJ0L0Rw1cwF6FYL+vqA5OhGBESBIrIoT5km1uGtY33eVHVadD pj9LS4Xay+4SO1JSR+qeAilCnW0+dlI3C0lAjRCba3foZj9salb3Lln+c6w5WqSPHD32kQIYGaPG sqzP9GeT9WkZPzDz3PsCRVFq1rxmxfmiZFB47NA6HQ0cwV6FYM1XNDe/GKWBgv4UIUpKy9iZUbdR 57+KfhAhom8a1jcdDwhm36uDzi7UXnaX2JGROUb3lIqlK9TZU61tCQmJcXHxPl8CDI8nLmnQkI6O 62R2Z/07breXTMGa+PiBLcdb1b2/fnGNy+UmszC8Xl9wRW63BzhhxMa6KIWLokiWwZAksz9eZFlW 2URBNMnGC9k5haqxHIHSQOGxQ+t0NHAEexWCNRGiqroGpYGC/hQhKD0rGPclQgTOt/Mt2XyEiL5p WN90PCgNOsCLo6VC7WV3iR30CMERH585K4m9+jUEg3OfB8jsWzv3UAofOSpL5SmaOA1lWjBmzrp3 Y4c+PNwkG0esfXkTd9tRAig8dmidjgaOYK9CsCZCACTR7M8BAptHCNRPzuh3w/qGRnYSRotQni9e UtnnTOsxd/mxsU0LOC8tFWovu0vsiFqEaPvnZ8ERov3yVTLbsGc/pXD/6EdUnklTfogyLRizZper bEOHpZpk44jVa1/nbjtKAIXHDq3T0cAR7FUIlkWI3PxilIxwsHmE4NWzrGNmJ2G0yLzn9jfNzOUP nG9n36uDToaZvVxgJkJ0fn3r7y0nW463wmg+9t1/vv32f+EWt378iS5CAHy+AQkDEmF4PHGUwlPT MuFBZOTkFaFMC0aMEkMeCkMMknQf8YfN2zid6j2gBFB47NA6HQ0cwV6FYFmEqKquQckIh+9thMj0 Z3FhZidhtMjOEYKXaSYvv8vlZt9O4UFtZ3eJHSmpGbqnzCtfxri3btsuWC8SCIIkSU1HW8ItDhkh HBDIsvyTyl/d7e7mdKr3gJJB4bFD63Q0cAR7FYJlEQIgiRJKSUj0pwghYL7zqNJy84vD8aDksdzq xMQkdkLzEUK4H6aZvPwoGRQ9qO3sLrHjdzXrn/jxvNlPV5AB/9+7/wPGvW9seVunsOnIsXCLsRFC kZWn5i4mY/TYPN2s1+sjU/njJ6E8tCdSUkdyOk89UDIoPHZonY4GjmCvQrAyQsAnEaUkJGweIRYv qUSVw86M6tSU24gKciy3GlVvfUNjXzTN5OXHZqRwelDb2V2KDmrrekUIkWuEiIuLV/euWv2qbnZE up9MHfrr31Ae2hCyJDfs2W/RGaGUUHjs0DodDRzBXoVgZYSoqq5BKQkJm0cIlEsoDShaym1EWZTp z+IrrI+aZvLyYzMSQXCZqO2MFkUNjfve18qDfHDh4uVwi/lGiAEDHlhVsx7G9CfmoDy0IeAnwO3b ty06I5QSCo8dWqejgSPYqxCsjBAAuP8oMcHoZxGC8drUNzSiaKFnhaNCWeRyufnW20dNM3n5sQUS BM6363hQ21ks4ou5858pmjitZOr0kGNM1jidwnEFE9VZ2Pjmjt0q1anWNkSAgMYqSZNLf0RGWrof ZVTfQmHRlM6vb1l0giglFB47tE5HA0ewVyFYHCFy84tRYoJh8wgBn31UOZn+LBZa1FWkl1ZSWoai ajraQhFWVV3DTgUBso+aZv7yo5QIYbxCMbBYxBcejxdbphZPzlmkUp0+czY21iVLsiIrEA/M0BoA mE+GKKKCjOWA0HW3u9u6E0SJofDYoXU6GjiCvQrB4giB6jghYfMI0YN0O1xX1QGaJoqW0vexjZV+ sVFs4W6F/U0zf/kTE5NQYsznEBaL+GJgpBrdbu/DySPIGJacJvVu0AsWPqtS3enqgmAJ48LFyy+s fAlVuElAdDn3eSAQuATj2Z/+MpqPpiN5eLrVJ4jSQ+GxQ+t0NHAEexWCxRECAN9/lB4d7B8hsM1i 8ZJKOiG0NqRJtLcbHoeignJ4FZubX9xHTTN/+bF5pqS0LJiEVzkWIWKE0BXl9fq0s9oIocXm2h2o wk3C7fKoj65Z81o0H03HiHS/tefnRIj+qIEL2KsQrI8Q0EdQenSwf4TANguXy00nxDpGb/r1DY0o NiG8Udg2TXlHbG6a+cuP+pgIYTISioHujxWIGCGKJz2mLr7T1eXxxGlntRHibnf31WtfkbHyt+tQ hZuEK9Z98dKVL692wHj+Z9XRfDQdqWmjrD5BlB4Kjx1ap6OBI9irEKyPEFXVNSg9Otg/QmCbhUC9 PAY6PnRPukIsIfTrwPl285VSDLe5aeYvP/bah/QKxUApxyJ4PF66pHEFE9XFECEUWdHOPjlnkTp7 +sxZt9sDC2KUGFmWUYWbhyzJZEiiGOVHU5CROcbqE0TpofDYoXU6GjiCvQrB+ggBkEQJJUkL+0cI lFEqQv7qhFZowKuIVzEx0q/FYMAWXYow0Kabjrb0UdPMX36oHaUnpAzzDJZi1lPlBeMnF096jIwh DyVr9UAYeHHV79XFd7u7yx6fXTihhCyGjVu27lRnT7W2BTdvYCiaOA2Gf3QOyopg5IwrIlSjx+aZ pIoavF7f7j37LD1BlB4Kj4FfBGYQ8o1zNHAESkY4Eo4RAn7xIb25B/tHiB6k4SrgvmnbNPRHY1kL eihdXklpmQFaSBGqY/AIbA5xudz/Z7/MY6OoozjO7NXdLhA2lqsc4WhrD8otQUKorUUohEu8KEdJ CaC0gKSmHIJrCKeGO2mAQJAjRMEEC6gFLY3ABoMNEbnkSogKBCSGywQkTXx1YFh3d37zezO/WWbK ++T9scn8fm+/7/1+O++79m2akMvPnwF6a7xF7G7HgcFDR4fradOuI//e2hOnHFKkiWiV3F5+uu/r 71CtiEBqJClfdPLUOSOp4ozX66vcf1DwOYWBEsPIY4XRSRoEgpKhlkSghSgrDyJ78xRbWAiUjHBg /KWlZ4PFgoGrO4OmPCP9h+kGCnVshKLs2zQhl5+/QCgnZgZUUZrXwGxy8oaE61EMAA8xLUTzlsny 042bd6BaEU1w4SeQBOLdkg8MpoozK1avN+e46kEpYeSxwugkDQJByVBLItBCAPr+KjayiYWI880J R3NSAxcvXYm/sKLiEvs2Tcjlh2/hzACtiJkBVZTmNeAhdKx2xOtj33h7ohzDR42ZNr2cc++A3IJw Pa3/byGWLF8zbOQ7Smb4/PmuSuWp2RbCvqxcs0HIycYEpYSRxwqjkzQIBCVDLYlYC8H/Oo3AFhai uiakrzrjlJUHeRTq7r9uwLfYt2lCLj//+0RND6oonmugyaKlqyLS+hL9nHtz84fCeulJeNyeFzO6 KeFyuSMyj35zgrKXbSE2bdmJakWDAfp2+sx5IScbE5QYRh4rjE7SIBCUDLUkYi0EvCSR7XmMLSwE VokoHJKDU57u/usDHIutmybk8vMnATcVMwOqLp6Ga/LpyoqItM0CSZx7z1+4/O2BmupDR+ujJlQ6 czZbcOH4KcpetoWo2LAVnvr9TeSAE4zO5k3wyU8TE/2ovlkTt8udld3r9p27Qo5VDZQkRh4rjE7S IBCUDLUkYi0EEPOHr4ldLERRcYmO6gwCN5ZfYUKCN27COFtt2aYJufwXL13hzKAmA1UXT8M1MWIh Ivhs+y624HFFU5XFJ385y7AQwYWfdO/1srI4s0vP6Gxbt++Wn166fEWKSmVxQHDX7n2UyOra+4fD P+o9QwQokYw8VhidpEEgKBlqSYRbCPhniuxQPXaxEHXxndEAWDIYUvzy4javURfbmk0Tdfl5bDNj O6o0/p4zEGgh1lVsZgseO+GphTjx8+kYFqLFYwux4OPl3Xs+tRAZsSzEpi075afnfr1oQQsBN2HM uMlTp5VFx8RJpfODy/SemCFQJTDyWGF0kgaBoGSoJRFuIcrKg8gO1WMjC4HqmHHgumIVBgJJcRCG 6rM1mybq8vPcT7DWattRpfH3nMGipasi0vp8frXFP9WebNo04Pc3ady4KQSsTGre+tq1G/JTTQvh cSfIGyESExtHL5D++3YIt9sDBkP+DBFtNuqzeRLkp16vD9U383A6HOCQ09K7Vu4/WHWgRsgBiQVV DiOPFUYnaRAISoZaEuEWoo7vT1kENrIQQE5uAbZAfei7PNU1IR1HgCItPbsBNE3U5ecpjeFqUNVh 2x6TPZVVcIKZXXrKkZqenZM3RG3x4aPHIzRIkvTb71flpytWr0fpRwEuIiOrhxwtW7UVmLlZ4AUl s8vp0p2nc2rmvAWLhRyKeaAqYuSxwugkDQJByVBLYoaFgD9cyCbZzEJcvHQlEEjC1ogFbACYAX0K i4pLTBUGHWgATRN1+XleKYxriSoQ23bjhI7VgmcI1wAz94+r1+WntSdOvVVYXDh+ihzNW7RGlcPG 72+iyPjwo6UCM4+bMFXJjHq9hPNawag4n4U+UEUx8lhhdJIGgaBkqCUxw0LomF/2shB15g9EGIXb duw2otCke25EmNWaJury8+RhmC5UjbiOiwDcAsNCRNCtZ19UOWzCLcSC4DKBmV/JG3IkdFyOpOZ6 bE/ewGHx6b9xUHUx8lhhdJIGgaBkqCUxw0LA2xLXIxtaiDozB2JCgtegf5DR4eXYwIwuKw82mKYJ vPya2nTvjQBVICcPHj6ct2Dxe6Xl09+fGx2F4ydLjVQtxJmzF6ZNf7qxVXJ7VDlsXC536cw5cvTp myMws0E6pWaacRAmgSqNkccKo5M0CAQlQy2JGRYCSEvPRsmzo4WQEX6doHWMf6xYYKrC/BIiTJSx qbNM0wRefnaTjdiPCLA18nD7zj2n08mvwSFJioVYtXYjSn/DoFNKhhkHYRLwc+MPRh74vaBSGQz4 B0Qa1DQIQcjFqK4JmVELtskgg5ENvldUKjOAb+zRu5/x9xIMGpP8DzTQiJFwSA5orEBjU2eNpgm8 /OwrylYo5IdsBLAQ7OsBnsHjSZDD7XI3adrs2rUb8t51FZsjFrvdHmWxy+nSPEFYI+N0aNgYkOFS QZIk9l54jFLFADqwp7LKjIMgCOK5BSYsvOHT0rOxbyQYgvFxPjDIcnILUF4iEEgSbh7CsX7Tngc0 LUSn1MybN28pcevWX8reCAsBk3rP3ipl5cRJpexzhNF/JHT8xo0/IVav3chePHzUGHlldOQPGsHe 6/P5wfbIqmbMmsdezMbr9T3DwyIIosGzbcdumNfsv5Nl5UFY9kzkweAGeUXFJQx5sMA85xATizet AaNpIVLSstT2RluI0LFa5WnJjNnscQwW4vr1m/LiL77cx148ZtxkNRngLth7ExMbK4vnzl/MXszG 4/bcuXtPROMJgiAIwt6AhXA6nIyh2b5DitreaAtRfeio8nTipFLNiVyxYev+b76HKJ05h72yX/98 eWV09HqpP3uvy+V+8PChrGrGrHmaqhiUzJz9z6NHpp8KQRAEQVie+/f/zsjq0aZdR7AK0dE6uX3+ oBFqe1esXh8xYasO1ChPlyxfC9tjpn0SqZ1TM1PSsiDgA3NlSsfO6fLK6IBHjI3JbTtkZfdS5j7Y Hi1VMUIp8Ku9VaYfCUEQBEE0dI6EjufmDwWPAfHqwGEDB488f+HysxZlCoXjJw/ILcgbOKz2xKln rYUgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIIgCIKo+1eAAQCWyzWpCg0KZW5kc3RyZWFtDWVu ZG9iag0yMDQgMCBvYmo8PC9TdGVtViAxMzgvRm9udE5hbWUvQXJpYWwtQm9sZE1UL0ZvbnRTdHJl dGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9GbGFncyAzMi9EZXNjZW50IC0yMTEvRm9udEJCb3hb LTYyOCAtMzc2IDIwMDAgMTAxMF0vQXNjZW50IDkwNS9Gb250RmFtaWx5KEFyaWFsKS9DYXBIZWln aHQgNzE4L1hIZWlnaHQgNTE1L1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVu ZG9iag0yMDUgMCBvYmo8PC9MZW5ndGggNDAxMzAvRmlsdGVyL0ZsYXRlRGVjb2RlL0xlbmd0aDEg NjU3NDg+PnN0cmVhbQ0KSInUVns8VHkb/52ZMW7JvcTQcdtcBr+ZQu63KIUR4xJljWmYkTGzMyPX LTNJF4WElq1IymW9qWi7qOgqRYvkbam2XUKlKLvSW9gz0e7W+767/72X3+9zPuc819/znOf7POcA BAAwF6QDPIhcFui9fOjRFhHGGQZAO5cWaEVVEVqMAKCThvGCmVwGP77b4QUAExiJ7GJuFKFj5B4x Ju8CQPZ6ND+Ge+WoLubRcD8AREpMXHJ0Mm9LGACBEICdZWwWY/134bpbAAIwObBhYwy1EbVxAEzb MdqIzRUlnXCfdxOjf8bON4njMRl49tkIAB5g/rXJXEYSXwlROYbZS+NB4xlclpuTgR8Ab2qw89r4 PKEIywNbb3ZJ5XwBi9+/NL8cgGUkAJTVpUG/39I70E7F7hrg/dIWQok2jyhvlrki87USIosrlWhH Yqy1OAShzIVziHIzEpyMDICRRAVzIkJAJLY4hFAaAP0h+Q8cUpleOgk4vt80EAWEgAfiAAuIsMtZ uiH6sT+CysMFwi/7qtvp2Uh/1ovWGE6pROM8lOCklzFOZeWCzqW7JGtIR9YJP9dcd/8wVPotToSA hSM+SFkIdYn4IIKC+rxgloATyImJR+mCBKEI9WOJEnmCDZT5UFOqoKg+94MCGfWOZ1pSyNBsRmD4 uyWHy0IDRQwunxMfgwayBBs5TBYawOOJKEsgdUbb3I+G+ni7uXv7eNPXoG4eHp7+dM9lZNSEaWpn i358BtSbr2RnC60pVPh+hc1XgksgBdpSF1vbWduF/e8nIC754ztHZABevBt77ztwYjG4Y4mOstPI FpZi0gniyQrF06pKIT2B9xL6Whabnewalw9fMvYkd0p+TnuvTtjZtsHx7ScONG0zfvZlqIowNunW F5qT10PHTb8JjSgkTFpEqYaKSTe/yL9rEGp1t1VDJsPmXH51ve/KJy8cDP4WXLRJf39cZtPK5fti 64/a3H0nb3Gn3u5rHB4D9CeQwGNxMYLmOqc256ltUlXJNmjtqlM3Dx9a1q+YdLB801iFrEDvpzUj rRl9O/J9ev0YI3Xlb72c/JcolvCDx7PNNs+//ZjZmMyRFVoeLzDZ+cvz6qrOdW0KN1Xkc27X1ZoU Xk02zci7P30uxn3F0VyV/kbGxP7Ax3s7hC4TkwdoGTVBHZOqTCaUEHBQgt9QischOJyKXAp3LS9q L+3c1UmPHzW0Dvw/ghjDLJW69GMQ2/wG4tIP8Sn8U3yzmSn+28wcoN2MApXOEnCFKC8aTRCyUIYI ZYtEfKG9lVViYqLlRsxYiBlbMnlcKwGfIQ0UUiiLoLHUGK+u9+fZQwli8CmOJYgywPgKOAmCgKYU xrZnJyvwTB1zbcbD9NOauqVZuU4Ni/IyNOyebb1tmkeMXlGOp+0eolWM1kZ0WC1o3vPy1MHUPfq3 n0z3+Y2+qy0IPcO0GMgeN9Vq42f7X3le2ODae9F4yD2oe3zrK+JgVhGJMoZX7vLZb2R2X0cnRzJ2 fKTCt0+j4lFOdzP7MiO0StA1AVfQvrfiMdHvd9yUpF5edd7kmpg9OCBxrfGyL33jYtPm00B3D0th pU5l9Dcvp9ecdRpOb9Z+fXWxWNxiVvB2c4T9tlyN3lbLhFcjGwacqiIvuiPVtOrwShcDSoma5hvh IT1JFsH8qRfOh5uz0N+yYJVZEjFD5LQnh7yc8r6VDovPQPEp6EqUwya6jIwsBk8MMBB+oCGSaSQt ClYTHlPI/7goUo6VUMQQJQihPFYUXXWsCQBcJn1ECU5QWmfFyMwVSOaEJ4K5hmbQ5INjHDKP9GfV hupSL8aEOVDhgwleDipKmcoEAh5HbPoXU8BijMaMJGv1/GKkHFA351nd+Zitlw2f53gpfafte3Es LQWFVC12Vl4DtWh07xkHTeKiVGccEZTr52WoK1z76rFryDUZ46HaWtXYqscOt54YjuebrnMNGjsS eOCGjb0dS04oLKd21tY0Nss4TnsOXxnqMeq4zTwmX/H2J52+STeF2EJsCqhhX7F/zEwBZXAJZDk6 blftcB5nDv/g+ukQ4FPMoelMIxh48PjJAk4MWyRFOUqxwzrSl8MU8IS8aBHqwRPwLSl6kDSjrPmx hCdgiDi8eIo+XDjTGFq/y6UTAHVLELF5Ao4oefbTRKFAaDvb1VRIoS6mzJL/hYj+qkmrcBcu8Qcc XvnpmJTsS4qAT8uqdht/PjFV4HP49NSBMtQ5bXXZ12U5kdQNHe7rk1/UbGyh97x6tj+TlFOSEV13 bUNKlGG3ruNDZSRvqPBqo0V0cTH7s6J2e3LjnFOhn13yGlRwXlpIrjKxqxz23uLel6HcUBwXxKiR pB2KtEj0eVJUv96h2J9EkTPSKKka3GOuNeD0FVMjMlSGVaJrG7DtdcVIPu66zp3GIM+6HemN9sP0 fL9jkxUpXJFfrVZrobyJPgjJjeTYNqxSk3UMng5/Wx6tIHe0UxwcMvKtQ8Q8cSKhZ/zisfSCqeNt m7srtAVrHW+eH5U7bADriFtb6tBE9a0/zDZpJRQfgeIyKfoRgrgYivelq4S380c4goOGqzdpnPTN nr51SPCfr5/kLzCOl9awYEixaffYPi3r52cQo3uJqmNrI6klBxVvOcvs2Z7TYj+g/2o0ZC/5VOny G1Ej7/7e6uAQVmVD50wZcV1aWqsfyqQ9oOx2KlHhxzZMqdG0OE3v2j36VMNQ2tOo1NrqBTfMbY0t LrIOqe00VmYefk0nvdFv6dYcC6iJ96DKTkrmTzyOiVNaPX7hZUDzhcGr8B1Kkd+uW2Cq7XtXF3fk ZfojfH34zyce3Ah5wfJuDqB/W483UZvO7R6Vy9l0Zt+1b2zJ/Sn9lYl9G0tBe6zLpU6bnY/c1Cqt Y3Vie61/7CIR+is9CTfCFi+N9yUpRZ1WKNt15y7dxauNFHSU36tmv21vQklFZyk2FVqwf4MTs/8G sYpFtCbwsFq1655rceWv1Jd7PFRbG8fnTuNeRgoZjWjwsvegmNzHbQjJIKWYjJgjxmXiJWlMRTnT B12Ua0YHOVHCFLnUEXGaXE66cChyEF0QnZNCzh66OF0+73/v+7b/2XutZ62919rr93yf56kb+r/A AgBxAMKC0YdgbwiCUAK70ATiC0CJecCjMMsQ7m7gMkBO1BBfhvWkRwRCMZcNfUcWkBZ1ii0T2+zP CGaFMD6sDPutlX1rm6LE+YttEgC1hW2sXGxhQHEfChqisL+JYglRA/8lTaRENBGfp0neQZxbpwQg bXByjqxUP6m3N3g9wWnyDm9w9uJsI8JAVb1pkN9Dex6HYNud7yZtUZB3JRq9jCur4JHtBMbOIbR6 UJIcPN3SItyUpXShsLPLQcNc0ChMTuunTgR3jqSZPUK3jRe4ry/R823h0K34VJqDjOIVx67j6cBW uz2Mio7qh5fPS2a7VEZsUCT/XJHIKz1c6uSi6iwn0Of0SpEZLOsmg1qH45k1BSpv0ARnX2Lyba2J gxnpJee6saF77xtYpuRf2dXkraRyVl86k4ZcaX46pfL2E1MUm6Kc/Np4qLzYPiZIS3onnG4cGTJr dlrMUf4l3HYWB+uz+91lAD3AWYOAI89y4Wuh/6H+tfiK/D4QI4tZ8r78xMGhTAAOm883VaRRCih5 oneV0uUW/dHqHK99rwdv6TZIGawFVnycII9ASa7Cwtxge6BSlQKzXJRQwG0BmfkcBg6fQ6EBJHT7 GsxstvRnWO6fyb5mHxV1gdc1tKLRs2JlbUWVD4Jv84Ox15sqzax/OeXM5A0YJRkxVlv1VulptV25 j7n1TOta38pDsd2u4qavVnfcvR58OB5n7cM4wGgoOqGT1J2y3kHmyvBdenJk5OOuNXPqB08eRXnQ TvCVyWbcmtH8RJ4yzzHaR0B9u4PEJKvSSvY49TKeACbdDKr19HSDslXYUK6pzWgQ7EyxVe1VuXKP gel7eVrxnarOee51msmhBXm7leZoSdyaeMcC/qVdMUXLC4WY63bPCspHQJybqRbq2lyEfc+PmpQZ v+FR9cRtdet+Gwb/JHXt6I2OuQoUMxMcpnly15SO0rwALloGgtnrBZhh6WJyFJjoMlj8s9CiEud7 gYaIfiTAkGQIAIaGBkYi+ulD8DOEyh1RE4jn/7c3QvqWGyG/8bL/mEb9nF5rfE5R85W2qcRG89go 3UKh4DeeVD2Z/eC4oC/X0dxrR6uNS0Y08SX19kq7Ufd6cbOl+Cn3iVGfjr5baTXAo3dbmjVJ7Ydo w+OpstWT2nUrBpGZEgkqk6XGvMpZCRWTCI1iT+1bxDxcChfXH3XWYjPyx+z60KuqIwZ/TRoec3Y/ MPU7cBn/yBMj2GqFeeQlnOgtqMXZha1YQ7gjZGWuiO79YdvLSHQ0ceaGx61ka/FD7knCZhlbR3ch Ly3KIXG4yBLTNCc1EujpF36D6VlBaSORgR6lkXsUDa3odye7Vweo/6rXbvDH0LQrNaHSpH2Nz/3n OUh6YlGgRdNUP3KoDb2QRnHhFtAfMZk/KhUZkZ8vFBJfReEnpgQ133TFj1fodeRevrB/h0ZZZeJm IhBfJLITUPF8ID6H81Xu8Nk//S94+WWC4SBaqiqKAlgC5rmmuRsSjN+XdH7hu3WDP7xnvvIKDWKK evVCw1mMPX7sCD2Ru4i8BfIUXcjwmZfPI9GQMLuMNjPSM/5QUj7mbWF562whufnq4JO/kNNu3YXp RbmZ67KQz7h2ymq18sInARZLmhRSEe6tFKuKFqXtpZMklOnSQZVCscLks3E27pFKaSdTmeMPjSbt j4yFWlzpFrhzriMbdC+v7cFypZsof8TYb6/EHDlmsTuksWcqY0yiTg3L0yMLXhS2hiUGEh6XDyju q7SD52s3bBGWHdntM9uh08CqJJRJzZlMyNmwJ5Zg0hUfsq4nwBWXqmgrXPQY89fnPw1wfuXIPT8i 0wN/2+u7f5fddqFO6O29zl2YyhCe5Ludq6zeHI/NO4/NaSfIXnDaq5nK0qgLfFtgfobwrDm7OhHk ogkQFlURUIUbL/huwPcPeEtixBeOFQGdam78OCD/MWauhYNiSOiooXGiSPr+9JcgQUkM9v0QBBwF rf5TSwKUBhZbcZBqP05EgUtRstOY0lUNxBdYharTslM3OCAQt2i4JBgKhORac6xgNBgTFgzzh0XA 8DBn6B4F3TfDWFAfHRYCPdtCzyEwNvTkAVnDoXHM+R48TB+mCwNgAF+Do/5e7FFRUZ+JnR0dygoI p4cGRn+eNqK4cBgdzz4x17atj19tunR8Hw/rdUAyM46gavWG3NIrdcf2otW1mViiGsMIL3Psz3yv Me7haH9jpQBpSeNyb0J+hrLQ451g02TlqoYSNVObYseJHOQUwuxFA3n5UNlUzBHv/iS4/QZsdURQ wjt7Xl9K2/POAWaQp8XTWpOLJWN+laMX+iJj2tGnunS5c10Zz5RC7qtsim2K7d3te9i0Jir7qEde +mw05d/+uybVSo9uEZzKbVd5Ec5o3dZk2rH+UN1PumcqVWQvtVIz903mj5XiDmjlBYch8UWnMl// Ghncl92XiskaK6Gd6QwJc0u5O9d4P6FnNtb5FZv44lwZfd3ZB41xGq87+FzERoCLsP90chiQizCG ugznlV4OgQ9UneckpFoFD/9wpkhdeFr4ngg23tmfHcUKDwKXA7gF2Up/GKCDp4b46YI6gNaCgfBp JjMYUiibHhwqkqibf3gk089/Hm+gAUBaGK3t7ILfSLW0om6k0rzwlhSKzSaajbWOyBUgnP7zGwhZ 8Zhgb9bO4y5XG2Ypj+UVsz/TuReguFjQEh8bYnBIzx8taFBGlCOAAGhEAsH1JP2tX+j5VI9dS/cv Zb4O9ZEc9Wr1rK/oyZ5MHMK96i9/61Nd19bA1nMlrn347oFDfdVNpjcFvrm240/zEZ+isdTppJ2p zx/7eqyzHWahx7rVHHdyn98MC5iBUtB9l6i9YjUcnyrOEpO9YNkqIxdzT486+GMZl6yt236xvFdN Txtvhk035T46M7bBKY7zZI2r/lNjFbOtiiVYYedU6UCxNCeF0Snj/TfX1QJe05WF/7X3OfdG0HpF FCM3rkTk0QTxCiWV3AgR4p0YKlGPJAyhZUq1oanyJd6jHjOe44tXOtxoaTw6wldmUEW9TQkt9ehQ Y7SfmXD3/LntzNfO/b9z7jrnrH32v9Ze51/njJyTvHZF898FlJXcePTvuMiADROa+kZsy/iq09Ug X9c96REJrb6dHOvacLSs+rtPLp5fMLLR2orV6evj4g+u3VWx82Dna5s9b2ZOmXd7kvejE3kNIgvb dEgNnLa9qLTftIS79c4fHzVlYOb6sbvGVnf4ak0lluZW9Q/5w7a5gOgOsgQ2YP/ebs/DsB//9QaM Uw3EVsqhbYu92gJmzpvtVyYE1OzSJ0+ajES4zFN7gS9F2jtDZX8ixBhTc9VexK0vQrg118vRDDA3 uN3kdsfXh2MmwO3LN9d1Qzr/6acNCMMKrEcrPJS2OIxK9MFmvIwMLEcvnMJOPIcZcgIW3EjGVoRJ CBT1JpiruRqXMYJqcwvXEYE0XJMGvI8HBWiMLuYu92mYb/bSK5AfGTuwTybKIMTSTlXREsWZF5tK BCPCnDSXeLQWt6SVKUcqrW9QH61RiKVogHwcN0/JtBU/VrbILLmLUGSjxIq3is0EdMVunJc0WumY YV+qtRsTOWqTBEulqTK38WdLqImFeAfzyXgXKtWLOsneQG0Mx0tU0xxefROXpaG01YmmtelpVvPs FjxSUeqodpJHFHpjFBZiI7NxATfxvdSWDrJWyogz8sC+RG5p/JSaidlkvpljP8BeaSttVbAKZraC 0QZDeG0xSjn/hzgtaZIllXJIl9pxvh6mkQkyt7mGkcgkw/X8zruJxxJHH86gW+rXrRbW63a7Z3MY 4RiswWmcIY9rzPv3eCKRxA31tio0w8xWc8tfKyHojAEYzh4wnb3ij1zVw/gU/5BqVYuep6wj9kz7 oVnG3IajJ7n3p/cg3ruEq7QLFcQFRllfXIyis/STgTJeFssKqZDLclk5VKiaou5prz6hv7Q62rZJ 4J0aowXndWMYcrkCbzPbyxjvVhzBMQmScIlhRBc4/gfVVSUTm9QpdU3P1Yutp/Z7vuu+b33VphhO Vlkv5mEatjML30ljcmgj+fKafE3mS9RH+jldT7t1B/2yHqyz9Hy9XP9Vf25NtcqsK3ZvO8cuc+b4 JvnOmDTzLnMhcJBXa0QjHp1YP+NYTRPIr4CYilmYg2IsYr0swwaUMe6DOIbzuIq/cwUgoeScx9l/ w6qbK4uI1fKBHJIjckxuyA81UC2JCNVR9VBJKkWNV3OJ5eq0uqDu6Ob6VV2oZxPr9B592YJlWcZu R6TaJfYWxwlnhDPVOTrgs6f3n0U+y3p2zQdfU9+vfSt8h3y3zVAzg/zDEMMePgvzyHI1a7CU2M5K 3IOj+AwX/VwfiRKbFd9E3KyGaK5aD+klvYl0GUAMIYbJcCJHRksuUSiz5R0pkndlobzvxyrGVirb ZA/xsewjzkuVfCP35JFiESvNag5TrVWs6sJIk1Qv1V8NJMaryUSBmqqmc4W2qA/VXnVBN9RhOkbn 6Cl6td6hD+tz+l+WsqKtWKubNdQabxVZp6wz1iWr2g6xPXauvc4+7GjmiHcMceQ7Vjl2Ou44njod zgznaOcs5zmnCQijWv2Fce/Gz3+xjlPymt3IekNV8bloogvseTKEGXOowXqiXqS/sMfJQ+2SK1Ks 8/QEs0mnqCd6sgxVB6WlDrET9DgsgJEydUM9VretIBms7kqEtVQ+VpN1knL4dfWsFWQV2XcAdREJ 6i2pVEd0kS4ynyDBXidV9jp1Bi7rumqIKj7V89RKDvpc5akSZFrxdjXymPdt9hvMd3c1XyL1OWsd bmm3+qc8lBVUjZPSx2qlXlFdpIyK+0xa4L5MQYG8j0TZL1elAiJb9Rbpq+pwtbyqrnQS4KQOlXM6 EFk1HCVcBUmGeqiG6AOO0+wvQpX4AjNFSxxr578/H98Jx2G5ak1N81BNzko7NMFK6v1j34EaxbYv 2SWss406mu+XcRipTiCBz8YtIhPvoR32sQbnI06twiwzW8ZQ99OpnwoVko9YqU21DCa3QvaLxqol tXAUZ31C/T9O1U+TB/ituPhkVSLCqrmywPJQmbKpvyXEGIzk0Rosc+y2z6K/BAOWy7eOVf4lXmHP +ZrzN0U38huOjVY0WbuozFM4Yo0vlX0xkQxPiMJb5Nydz3mGlUrlXWHyGWEee1Rf9sRjyDMrkcS1 G2iKTAlGmY1mBMZjkNlK/Z1udqEj5tlZaqgdZcVTY4/Jp+xHf5MS6nYqrlCPwqQJ7hE7yL+7vR/F 1kVqZw+zwJxHEPPRkhkazS56k2/nD5i3VF2J9r5+qtyk6AJ2qCoMMFtMiAQi10yk8h5AqdOm9sxG C7uUtYvEnkMGJ/bo/lK3rgldOnfq2CG+PV+5Yl+MiY6KbBPROjyslbtlqCukxa+aN2v6QpPgxo0a Nqhf7/nn6tapHVgrwOmwLa0E0R53SrbLG57ttcLdqakxNcfuHJ7I+dmJbK+Lp1J+6eN1ZfvdXL/0 TKTnuP/zTPzRM/F/nlLP1Q3dYqJdHrfLezLZ7aqQ4QMyaS9Mdme5vPf9drrfXuK369IODeUAl6dJ brLLK9kujzdlem6xJzuZtyuvHZjkThobGBON8sDaNGvT8ga7C8oluLv4DRXsSShXCKhLUt6m7mSP 9wV3cg0Drw7z5IzxZgzI9CQ3Cw3Nion2StKr7tFeuHt6n4/yuyDJP43XkeR1+qdx5dVEgxJXeXRl 8YKKehidHVVnjHtMzohMr875D+tVAxvFdYRn3+7eXQjG5x/+fIbccZwt/2F+ys+ZYi7YdzGYhhgb c+c6zQF2BLhNqPiJaKNgFPGTJbQlbSOCCEKoTRFuw9okrU0lZFQhlFY0rSqDktA2JaEtbQIRglYQ ydtv3t4e54MWWhXxed7MvHlv3ryZN3sJ3iOvAvvWm+O/8fGEOywWz6+L78rU+lQjOmGdn1nD2OU3 DzfFM7UB/ptIYA1ThGJJI4aNX0YIG5v92EvsSMRNZQc29PM5+Ez26TqDUZYk1/vNh4KLgmuN9Ulc TJFh0vKtgb6iosiA9SEVRf1GSzwYMBf6golV9cW9hWQs33piYsQ/caSmqrLXm2eHtXdMbmowOidz 0JnWyZGczqPG5em4KuxRcDHSwfSv8cOTeBBnmsd/OueRsWYepuFfQoGV2YH7WGc+VJc0vDWQe9ne 1EPeoN+4Sbj/4KefjJSsSklcIe9N4iFnSTrRoHfGZkWFWV7OCeKuw43Cx1rJz66q3NIvzOAGrx8E 4aMnENtViZpqBD8Q4Ovd0x+h1WDM7qa4zftpta+PItUVCVMkWTPoaMauYE23o0mbJ4PI47fQr4nG mp6S9P9c77iC6NoaUxn3H9Sdtr6xOdjY1Bb3R41kKraNLSM4Wz8vrUuNFFuBgJtaCJFaHETqLW+L swD/9VAsGF2XbECpwUezoC6u+kTCHgmfKpdC/ranV2YmPprX0kIumf8d/W4PElhKFH/M9CYb7L+J UYHAAxr1W5+xlSR3zFJnMmsqRvLzR/Aj3BttqHBYKxGNLW2GMWqELobHyjBiQX/MSBqr+q3u1UG/ N2gMqHE1bmyIJp3r77dO7vGZsZcTOMRapQapLWhRb1DZ3dQbUXY3t8UHvET+3S3xPqGIuuSiRO9U 6OIDfrzPUipYykJm/Mygv6Eq+oRHzvcNRIi6pVaTAsmv6VdIyjyOTKE1/cKWeR2ZgEyzZREp43/8 UtS1xDNzQBZWokp+ABC5A8NRWumlzzcNl3ilJPOfy3CFlWIeCQf4wlbraQd+ZoaAr7qOUYMrjFN8 nZqgawGmQb5Pe5FCmP8M+GbQfSJM/NN0CfAZUAk0A35gNRAHlgLPA02YawLf4jUcqHup3f0VWqWf Ja/eSlOAJRgHtY+oXNtIAYwbmMd+s9RJVI7xFOjK3JMw96x1mfWYN0XOa4XdRuqGvhb8w0C+ey/5 QHOBAsiLsM5R9hm0UT3NZ7WuYbwFfizG+HPQGHytB10K+TKMFwA5sPmiCFtrMM7DeAFik4fxaCAK u1tsg/k58LED+kLwgudi3xxQH8/FmmXqBcWnHMA31QXq1VqoEPoxEjg3n9k5E/vPPv0bxNi/TNj+ SbCv4o5vd0FkoVOdJe9qe+qsB8U52qAetq5jHHQVUpThvkCTcb5PgLDWQRPdk6y/wsfF+ls0G7wH mCDBax6kneoNikBX4XoVedNBtWIGFLOt2+KbNMkVosdwXsSbSuF7gnMPuTAV85qlfQdN1i5TEcYR hofoz+k4ITa4+0bQOsT9qoesT7FGHQPrDACnYT8e+1dzDPjeldbhHsy9At1zwEbkyERgPPR7ZA7D hu2xz6O8h30P5JU5CHDuATMdpO7HwcMOZPyPSYwDxgNzAd73VeDnwOPA93gO1h2H+ZPhxwucM5yb nB+cGzL/kU8yZ/keNyI2nGN2zfxQPE27gUKgEj9KdqZQjrmyXvge2WeuBV6bc4tzxqHQl9h5r1zj c3JOZdCgXin3ljXIuZVByzj3maoReYYyMUhzOGftWDtU+hDleuSacKjjD9enrBFQtYsKOHZ87w51 YpGmhykE3VL9PXpMm0Er1TPI/3aMnwCdi/gckjV4Tfs+fSx2kHAPUiXukmv3tSy6n+EeUtZjvUHE skQ7R69JOiSmaEOKrvdYV/Qe8YINZ5xJs6EM2jqmjEzdfyv/XyDO6z30NMZ/04csSxuiV3BWcv9d mQ74HQp5H9ANlHsqlP2eLqXfvYK8yJsbwLNaBL9fIzRXG6SF2lhZdyHIV2Dtaq2L5sNOxS+1l9QV dMTVQ19Qh3CP2EucpxcZvD7ohnQeZefc3bkkqZOv96BcAzkOlTUVtv4g6yps/VHWZNgatimFuTfw +yz7A8m3Oc/J13Revk4l6s2M/MzK04z8nA87b3ZeZtAxTFO9JcepU9iM417D55fvY6usJ/nOQdfn zM+maftj1C+OWR/Id/gctTl1DcwAQtD/IvWO4B3GfXPP3Gu1u56z2tUlVjvO+VPXLtDr1glRavWm e2qIZqbesiKnl3Kc9HNUnO6jIVqWes9C3E+1o+jhdh8tkP3zLzRBvy7ftpnSX65DrsFqvHul6OP/ sG5r+fSM+hKRirpkOXKkiXWah8aqf8Kbu4Q2qYes36n75BsUVYcpoVaghmGLmE3QBRXr9dQIG5Lr 8RxQlrH/Lg35yW9BA3jclfMu8927blMOUKpfxXvUijnH5FlD8h3fT1M5DtJ2M/oK1nJXUL4mqCI1 JyRtvobvBRkPvIEZsUj15lpe07Vc5myutJll3fbkU5ihv0FzsH9I7tVANZ4wleit1lX5XZFPj6tn abraQI9gXCTzfhd6VBn6ZQP6I6B+BAwjN702L3u1pNYt2e+3yX4+Wq+mlfJ7gnUumuwqo2kMLQhd kqrUN7DOs8ir2xi/aVny++D3lMd7Qx5LfZ/wd4KQ9fJb2L1DVVxj7IPsN+zPAeTbu/QI90T3EcRw FNegoiDexak+mA9egH47A99JyYptqgTEe9QqdS30oTgljotTVhd/B6rv01PqD3B/xymgtqF/n0Fv nI8evgSx+g3F1V9jPAXyQ8AWfPttolwtlzrUS5g3E7oNsDuHNY5Az9gJm4ugb9IC9Ze0Th3E98El /kaggLYZ9EmgnuqUH1OXuEVdrjnoyfOt1+X6jE3WlyWOoG9eStmmIH11cC+ft+Lb7h7+Sl8z/WQf 7+Efr8HrSjvM0TTKJbIuAiGbDjeJvdQDHBbvY+6XaKty1DqpHKSYchk4mMJPqEHSXqAJNTZbeR6Y ps2mnwHbMa4EPQUct3k6AHwA7MDap0FPuPBTgSEWIZ9BITsE7Ad+5egywXvdS54J3WedHMG/jV4D KDdwhhsjdXLP7TQH+83RFlgnGeoV9BDAtY0K3VuoUC2FfDLssnjdh3fubZp6P3/uB+Vdmi5jaCPy IGd8UHDtcn/+f633oMD9bgOelD5cxXssc4jGKOeti6Ctynn07c14SwHwVeALnHg69wT5d6U86/6Q K6SS9c9seTaffa/348UJeioTTh6k8+EVqmVoCzEfyOY971Atw3UGujN389qP7oM2fKMcYJ+Qg6V3 865lVMoQU+FrEdug5oA0/y/uqz04qqsOn3PP3bu7LDe7LIFKQjgJm4WELE1YpKGwmrtpKM1jmiDI I850kUeZgTIJgnYckwZUFLSYWLBQsCRFoh2TmOUuoctDyYxjO+20gDOOOs4IQXH8w3FMH+CgCfE7 Z+8NYSmTptZ/nJ3v953f4zz23PP4ncs4VwERK+vruC8BuXcB5TTuYmDUvwhnPjBmXh8R88qOpvz2 97G/S/r3wfgM9RJQj3z2EikBrwRHbR5d39Z5cc+aX5Fa76O6OEv+khZzd0/c3RvYKw9q8/8J2Dtv AW8Ar/+v+6IEaxXwATJHXUqWaYuQe64meK4Ov03IUCZ4Ku4F7LyhAZR/g/IGoAjl12A7At4HxlEz dAf2EdwjDHxczUL+Tsg+AG3caUzVHb4FPJtqY/g8If/+vYVdqfpDzwOPw4fMbOg08CrwM6ACdex2 vg99B/iX0Jen2hpCefg68G2gGjic4qHvAMLvRh+/E/nIh7xDP1F+0Pvjo7L1zojYfN8bYiK89CPx PW8O+/uPx/Zb4kNYzoM1fm3MeB70xrmHsX7cY4FcOiBySpFHi1zWgfxZ5I+jLN5tT0iearVjs1fc gSJ3FvmrYyFy5tQ7r2jMe3CZfW+MPVvpB+Q44AOyLd6GmNt461zC3eTFmXoT/++kgLzbxL0GYLyX pf+3IxdFDPgd6Dngm/adZp+t952x49xpn7Q+0TvyY9ypYQuxNDzIbmOxhUqB9Lt4ohjv7v7Yd/kD 7uix9/R/q9v3vI3x8tL78oBx9PHam6ienndMWE/LS2w9Hff509eenc9kkaxRpO27iUK8LdS+u7m/ PYb0fTy63+w3Qgvu1DHAOVCAO6sQOIHzogTIAfzAC7A95xoiYVcPCUPvA87A9nfwJuEDt9MDONxu jQxD/zp0n/qOjF1rYdN46zl93Yr8XOaHmDN5DraJ8ZNiYCngB04B2+1vLd6e6PuvygVCxDtXrR+5 qV4C0nLAcXkR2QH0QPdC954jq0b62fXEsmVhIwkueliyWVAYPiscZtbM8M/ZdaWbzCUchmvm9Gzp uWqWl1uFRxanCol588PXopPYVfIPQGFX2TVMuqyVKHg4PBjVYaDsOZzUlHDSwf5I4oBCDPaHRP6c cPtF9jb8b7E3ySZZ7U1TnxJGg2+w14ifcHaG9VmevkTGlDCJ7sSVQkk/5BVgABgEVNLAfkJagFag F1CJF5IDxUCtsLAu1oVxdqK+F7IYaABaAZWsYj+FfZuQ7FW2lcxG3efZITIN/F12UPJJcBb4BOyz wK9AF9xu6cfAwn/Usr8EfTr4iMWHYc8Gvwhd8A8s/StY1qLeLos72E5zFvdFZ8GfC5QADKVDKB3C 1B2CRiAp+wZ7RvZ0ChwGb08xpqvZzAvIb9SceGhGuANT2oypb8bMNWPmmokKV5Md05SKmc+aENOE mCbENGFWSthO9LdTJAuQPiAXYJj3nZh3YY9D9gNXpP2bkG1Ah9DYs5jHQoxqP9tqFnAssi2JR41w 2Xn2NKbaYE8nZuSEW+9q7kliIYIzLPaK2M3SuznhniysmxNZOSlG1LZoBttIvgYoOBo3knzg00AF oLKNZn4xP8eeJNtdxMjgLUoLa1FbHGpJBfVfZGFSh0yaEz+bTyIIKOSxCC1d725073YznzvXXeI2 3HVuRwNrYa2McVbMylgtizFHcqTfdC5ZCDKWa0sWtnk6PHFPv+eKxxHX+rUr2oA2qDlytRLN0Oq0 9Vqjtltr0zo0d5vW5lTWexo9uz3M58n1lHgMT53HwZ20I7qXbcDfJJA+oBFoA1TMcQz2XPYUEMPX iGEqnoKdQBJoPuAKygNgBzQv4ryI88LqhdULK4EUnjpgPdBoebVRj11HxA8KD4BnAcuANQNzOwA5 KEpAFTQdmg5NR9QVZQgj9EHmAnUAk7YBAKsG0vaVWP71gCb9gzLG9hmirjJkfHFufyGNF9KOQtpW SI1IWTRszIbw+/2xQCwYK4h1qg2BhmBDQUOnWhuoDdYW1HaqZYGyYFlBWadaHCgOFhcUd6o8wIO8 gHeqrTW9NRdrLteosZqGmpYaVopPlzCLSsKSZwcF95kzssKl3uhSpRd/JwbZDlwDGOGQxUAZ0ACo Si8kV3pg7YG1h9QCMcCBGj3ieIHklk/Y26VPlIRfucfP8Me7zSULa6NVOHJjQDvA0HY3/N0yOlXq lfY45IC011rxHdLOIe06DAdcvTzm6rH96kkZEAMaAQe5zNaQawBahuRAI9ALqKwevzVsjdKDX7fS zUKGvmAaJ9OnE0L8U1y+qE+ZjDWg43IV8oiU+6UskzLfyKjSb1Xpv6jSv1Wlz0VBKSBROA5JmWd4 ovrpqF4b1QujOlp7iOQRXZkmpSYk/ZuUT0oZMjLz9Nt5+vt5+rt5+st5+o48/TN5ot5M7F1dyZTS IyR9UcoqKecYHq6/zvU1XC/lelSnxyl6J+VSzpIyW0j63mlvhZe4z9P3SAVaomakkCcVIomOmJEo 6I4ZWQ4aNiPHQf8yIwf5BXqbyiuN3jLzb/DoNPoBrVSF/r7F79JK0gUeBG8B/5hEaBB80ozsEfE/ Qv2j0E+Q2S4R/wqpk/XaaaW0v2zV+6EZ2oBej5mhr6LXoyQkez1shm7AetAM7Qe9YIaeAbWaQTHA rWZkHo9OoVtIviJiN5KgIkZSY/X4BFp+Brw8VXmZGRK1KkQHSfqYGVgAmitGeYEGSJ3sjpsB+Sdz SEA2MZME5KCzSVByBvXKwetktmSXGdiDVrTTwRv8n5Hz4o+Tm9RrHud/voD/txrqn2il2cV/fVZM l8kvh5I0eIZfCpznv8pP0tUm7w8lXXBcDCUV2sdPYZLjiFXoGd4b2sJ7AtLbGYAXn7o9Mp8fC9Tz l4LQTb4ndEEMg2zHP14N97rQZ3lNpIs/HkxSuI0IOjMm8SWBL/FHYV6cpJWJLr4gPymGUoI2us7w eehxTkAO5fOl55RFxEm/bIScu5wbnKudK5xLnQud8525zhznTGemy+/yuTJck12TXC6X5lJdiou4 MpMjA0YRwS7M1HyCNFVIVZZ9ipAQ4tRXqEvB3olPZdVK9cpyGvdXk+pV5fHSouqkc+Rz8cVF1XFX 3RfWnqL0e+ugxZV9SUpWrcUCFaa92XH/Y2vPEkqL9x7IFty098C6dbQ63r+RVG/Ijd9aif8xaUV9 3BEo/xT5D+tVH9vUdcXvvc9+jmPHn/HHi53Efs5zmpgkjhM7JHHi58SGggkDwtQYkcZJSBNAEIJj NgIlofRjY60C2korFTXZxqJtTMMmFEy6lS5jo5s0Ua3/bBXS2MYmNM0q2yidBgk79zmCVuKfSbt6 55zre36+595zzr3vPPOBkDVkaNc3r4k8gSVWuOdxs3o+36yl6VOx7p70D0vjaR/tPCyNx9Jrux3b ey6TMTIajVwm+6iI91zGE2QsuoWO44lI/BEM8WQfwFCQCgqbRzyFIR7PS7ANEgzSlI9GMjyfBy3i dRQE6bMogYbzc1WACZhrExUAI2WoQpqrgpRRGORDfjLt5ydTI6yVJtOqkTSZnYIyggCQVQKFZJoE AGSEJkl99rHaJeSXE0eCZEfAcckOxo8xT+UxkAUrGFIAGM//sw11/A9gPN9/Y8dgdMgVTbiiQ0CJ 9DcOjFjTUwMOR2bHDapwpBl3YmBwhMr+ofQN11AkvcMVcWT6B5+gHqTqflckgwajW3syg+JQ5Hy/ 2B919Ufi83OTnbEv2Pr6I1udk0+YbJJO1kltzcWeoI5R9Ry1FaO2YtTWnDgn2Ypt6cCxTT2ZAtQR 79yel/NEVQjnIWFzxjvMun3t0uFodVqP2BZkCF5bKk88rXZ1pIuAqKomXBOmKjidVKWBYe2Kynqk 1WlbwN9fUelgWO/qQB5kje6MPHqSyeQ4pVTKA3w8ZZXGxuHQOrtj6TWbt/Wkg+lgNC0mInFMw5Fa aZ09ou5K8HqQjAYng9PBmeC5oDyVisOw4Qp/nSd9/Cg/yU/zM/w5nqWK7T0XxeAM/wnPpCCb8Di0 aESymQIJD/05nkrShsBAEihvzpPydPaEeTQI1S6GyrwGGYFcQA1A3UBy9HPgHwH9GehfQDJ0DPg3 gb4LNE9HmBqmJmrdGaEW4x566VgZ37zX71udBdn/XF52b8vL6Ma8DIZ9VpDnQw2FYS0U3hgtAP81 0MdAfwP6D5Cc8TE+afJUPmvjSZT0YFg+gh/jlCU949gDHUzdPZ70eBAlmuAQAYB68BfzHuFkCoEr ICAgACSNJunfUlQ+BsIdbEdIbqfVMlKgrgzB75L3oExVkCvnkVyWJe9dYFChgnbewYgrYOVXQE8Q g6uQEu/GzyKrR3cvuBTcqLsb7FoKohD0dQ+A1XudeqdeAIbtMvTAwbz/QJSj+8ghex9sxR7+UX5f vhvVoza0DsdFN4rdjBFdDLMapU3lMGtsDi7Mrq0etUG52zDaMWFjZT4co5VrsbmRSnGVxtBYJTZU emOdlQOKhD1RlfANte3zjbd97FCrizxGtt0XrrKri0g1y2bxBpFvtxe3t9sZ2araGm+dAjfYq9lV nnZjWKmsfxORN+GVn2U2X1i9xsUos2RSVOnWXjebdap68FIWe+dR1M3+FAqWdnwNcaiK/PKSPVQe s1hKirL4mGjkyt3YfTThx/53WzOj5fvKCZQCNaItEuzjRrlJbpqb4c5xV7jr3B+4T7hCjlsPt+ex eefWbfCm2Xi3tyt3t5c++3VLG6NDkb926e7m6HMPHEr9qsvpcqHcXUkaLM0Y6BVNred53VWsNzTD I5HuV/Ve3AuhHevFvfvHsNPEskRhNjf4Ak0WlnXx7kqJ+xsDTW7gTYEGn9lUzCrMloC/sdJdKQRA ul08ayo2G90UDR34t8yEzzzTnd4bf3VtNFEsCGf2bPnBjsPXxr63+OM7dfyRgee/cupkdvJ4usxc tfzC4UPxjmfi/G9efK7tqwePp0IpZqegCC0vHh/pjq2zvfZyfNfeL6cnDv7j6MhLbWe3rXlteNds 359+8tsTtRU2uar11Pannz3YUn9wibswdyg617/7Oz5aMGxmXLgEckaNNou2Qs1U2XBAZa32N6pX A8uqPlD9TnVbJVOjLN56iWU0EBglBNQvFqrVyj3MVNHWMzRXc811uY066mAU6qJpivfDSTAy1COS KxTM2wFLY01Na0kADD51yCO2tHqFk8u/p2vYu3wWiv8PkAV1i5VxErdcNTNKS4L7kGOUGClkMm2B AV00iGqVrEVrKjdNmRhTFldDMabt0xItZz0Ni4Cz0tu11JtDodwtQzNEz9JMg4bHjP6AFAQXr1iJ UT44e4fHlAqFSjAU17fEAh3D08tnV/HTm4xFymJlS0P9mmTfcIaurhtPkR74tGBQSHQQ+VTpjsCk HNOCK80wiOjwJpzAJ/As/hCzkNKN76ApGU0/yLFemmR1OeBS/hidJmc3kS/dJ5Y36MwnH97Co2gR qZBHtCORVTGiUmzxK8WQv0+JZ5TnlET5knrXBJ1rDBxK91bvFaTV53eCUZ0Yrq0NhxclXlsnwu2D 1j+8zVySjyAdqkAL5/sLHFA9n5fLTVQUFZVksVY0KEuQW3QT0Z1wz7pvumVuPR3W9KFRNImm0Szc 4ZywgMtgoyu+hQD3jt3roougy+g8KG7AFa4KvoKwBDOYsArBbiu1ldkY1ujWCiq3lbNwhHXK9AOo nC0ZwMUa6JnV0KvAjgFsKwBm0JkGEFcITKotKKuWqLr6qLHRQA+SxawvJrDfSneTziIduYCenikp oGT9q+PbEqcPv/W1jwYWj+65Gm0eC4yX1XormqtaIv6nG8nbt/GXtoRnfrF87u/LF1//y88+W76d eb1//49w8+23kl5nW/fyaYjEHbiqWfCYGb0hFovWhHXWetMqQ1bRSg6glxHRhI14J3zjKfEs4uGe pv0C6LsgjP9GWrwTmWEE4X+K8PWiJUqC5coCNWHQAv4M4OtEg0ajFfV+r3ZSe0I7q5VpOcsCqcC3 VpzrCXbpcrekGykU1NP0bUaf5h7gTz2eei+CJO41Cg36YrPZYnL624mfOoDu/w5e7zQGty+TxGpz oUIoETpk1759/5X9q8uIIJDS+gly41vVjrJymm2rYI9nYY9leER8QWFVNVus9rZGqwiMo0xb9l+m yz+oiSsP4O+93c1mSTZssiSbDQluiElIQEADWFtGH6EH9UTB+gPRMiCtgkAPoQqCcgSKRUEK17s6 drzatFUs2s5JUYzo6HRGvXrnnPfbejPepQxzlc55d394N2dVvLcJVjOzuy/ZnWTy/fH5fp7F4mPz 2eXsKKvByiZ6o3aTtNHaoN1h3GH6ue59w3vGT3WfGq4x16QvrbekW9aocp++L5nJTo6WmWSzbJEl h5XlJJ1V58iRi+X90pDCWmWEJJuslzU8JSNGY5VUGog0wXsd5jicpF8W4iAXoQJYLzC2IRmqQEfy JBUggRsch0ifEoGDmAeaqVKxSmwSu0RajEAWi5j8KRtQsBJSqGolrCBFPg/vkz7lIcZJVagJdaEh dAndQH9D/0JaJM+bhG8/refp/HhFV64k80EgZZ1/91Flc/6yR81jGlS4dsPZIQ5e4m5wCFQ2V6RP q0CJZYbMAyTEHzndKQ/K5H6FIb9PYDovGy6TPm9uqSQZU0UgHVLOXADi5GddeXMo1LCIdS7Ky1tM nax6GIWboXLkR6994HHLNw4fu539w5H7S2FNY3mRDTKzD9wwCA+Ndo/sbD539Y/DtbUfnZn993PC QlW8akiXtzMlwAlTcOFRGpoqUraldDFdmi7HAXrQweaiXOc6ap1S7mywtzLt9j7Ub+u3f0x9woVd UVcicMFEwWgSzRZJm8QjiopAOzYqziSFohWnLdlOsVaaIZ9+MK4oTnGSRNZKiVjP83AKoCmnkzjd JFwKkmHxmRAbJv8pAv+DE7ALYle1C7ksEXh/QkBhJ3SqX4I5BQthAQly6iR8F87EsjBdScpeqFSn r5qIu9PfT+S7JjJRSBeoUe/TZqYzZCID9U088JhvgS2oRemBPahH0ZAMqIEncSdai3UNdJPptZTt zHYHU1lBRgDrZGm17DSaZyZADCUkNYQkkGpfNVtXAbnDe8t7V7/R3tGU6bJ5s1as3Dl2ZOD1C5Bm Sk5MeI/sizRMhLyL1yyypwvOnLGu3X96fgGLElXibiC5GCO9ZQVp4CH27+RaE9oMPdwt94xbo6Fg J9VBd1j2SnS+Nk3DUC45TdZQSpUWaiOwcEIhiuNJJKNjcNwKGBXW44k88VqI1Rxhk84G/NiPsL/a H/ZH/bRfjsed3AKiICpitojFYTEssqLse4rsh2QcTs8x+16+Su18NarEhVTReRrL0zpNsgbFQkiY nmF3cyaHPcWONEY373Fzrho4T0iuAU4DWc1P8NRAu0mpAal6cgJPmJ3u7+6OYQqaDRT7pM5VZhtz TPPzAlD1nScRJ81AHew9/nHD/OGfDFyv3XN9YPPFd2Di/xoeXTcVFwWWl+/f1+kpZ+rcfOlHv9z/ avTUiQMnXhmHjgn40uyGRy/2ran+Oph19NDJ7xTSBSWPp6ljpAt04ItzgH4cHReTlzKRx1GcThay FjKUnwsCzFfzYf5X8Br6Cn6FojwJKdRBwGOeQgxNR+BPsY1CSRSFaIpncHEuMwU15KKZgqTMI/C9 ibAO6mQ9M4nuAAp9g/WAFmhMl9FhmqEvoL8D/VzcBbWMY3y5pxIlXbibviy/j8lM7zN0Xp4rXm4H s0PTy/Rq6LnCJcRoIXEkfgBd0EnGGuv9Dbo5m78dvjs70Jy9NuBgSjzfXaSvJGdW69RdxR5Sb/2k 3mTgAQHYgScrIOQC8wJ+b1OgIzWkC+lDtlByjzvk6Q+MWo/ZjrvH9adtZz3nvVcSruhu8hYWJEAN j2yc18JLNjfvNqyAB+Cb/F7DKDC8AJ6HK8AKuDytCm7yvhKoB/VwG6r11HvrArvhHm9rxp7AED3E hNiQtsfYYxpKGrIcog9qf2Y8aDpsGfF85v0sEKEntDO6b/UzhhnvzCIfy3Pe58ES+Nwi5kUt0Nu8 dOwkSDE30TAL1IvIOwo4mEimLI4d2WQtwK1YALk4F+Hc6txwbjSXznVdIDco0gN+0gMJ2RKWhiVK knMm4T/nwBIT/xhU7k7fixuLWvBQdUJS5IvSs1JSjRZaa3Y7GRfRE9ZRAzOS/DUg05RdA1NpYiYp qp6kWxbUgCzjgnipz9V6N3mpsGlWs+Z5KpTE9uNm5lU/e1b5JfGJ8KsiCvd/WHl99OiXjSdPLSn5 y9gXjevb4cJduHXr1lDuwrw1ZYOvN/Z4itHJ3vD63kuft5Qcadi3amvz0K/bN7+xcezPjZ2l29pa S3Pqsma/KTpW3X24o/ylJfWEQatJJ3xCakICXqjHgd3eW8zN1Fteuo5uZzq1HVybfhffLrYpA9o3 xQROO+RDL2gZr9XptTJUipsGLDMJXwVWiE97y1hIaF6IuSx3k5uYBEhR02NgCKMOnJYkwFtVAtlg 4llgEkyKiTJF4BZCIx/2hXwU9lX7wr6oj/ZBlWFO8hhOuJSAEuQ0lU53vs/QdIz6j+LUXzYHJ7I7 i+28pPiojeXLnzxfa9R7BLfd4/LM4501wJGoaqSWrBRdCnFJIzmlcu5nkaQmKjYTJLIBMC2Okz8u lOYkROgE1QTFMxRDU2NP9He+97uGrm/dffV42zt/vfrhRRQwBdtXVrxVUVCV+WO7G+2E83+x5fbZ zwdG+08+mJpt765H53pWbf56V/jIH9rWZ6h7AuL0w9QpwiMJBMcoOQLd2MHX5g3LYSLDGLB6AvRE bCaqnzNsDpuR+QJ0k7nxewji9LgXc5GYYpMtA3xG9sVnxd+p6j45MrIKguqVOhXfAWQWPBKD8VVQ nUybZ4vYDOZtEARr4W1cPwJGCv5RQBFw2AXZbC+T19lbLSwUQNod8G1BdP1/f0BvKBsxj1h+u55W ypTVystVVtoJFEjsqpSuA1tQraMP0O2gHzwooMa0BcFgIAhKX14YLECA1tE2f2lBANGFyWSTGMSc sBQurQOFsJC8OxtMLPKAIGs/TwXJ7ydTxWdKuvNSiqTI/8kuG9gmzjOOv+/d+SuJfa8df97Zd/64 c0xtYidnk8Sk+PgKCRAS1oYmlAwYrCCYWGwChXZs0dTiBK2CwUoJFEpF0eiarV2yJA4M1iE2LSDU obEK2AeUiVBWgqqNVnzUZu+daddpJ7/vo3v8Ieu9//M8vz+5WJ6ma6iMTyv5xhqqtqqqbUlpwxMp 5udeNsbKLMkyS+pq6aaeJqLpWHnS64/5ZX+rn/K72pbk4OUh3+vfdOZgzcvh8CJFVNgCLsLHqNQ/ 1k80fwOk7ubxoeYn0I1UahJ91pnvvKHKq6gy/CE0nkWmelVp0+csqHlSE5vX2NA4t5HUTk/WJwlt JGgQbUGvaBaFYAgPxTlPNnWDBTVNHqCNUh6gn1raDe08htJNQ8Dpwf5q0yh0sy4GiUpO9gBTBf5E Y3J2N5xfu9ADNDGdB5SEdd3A6nOo33K5i9ESoHEchmVT6G4IHstY0TPCHjL8Pxc2SKq+lau2FjMq JL9sMpZEnBACfoqwWS2U5AXlEgF82KclkAVI1ZTFpvoppRq0xaj6LLujRqeMnsc/gm0WLg9Nz6aZ 7rC36fzuo4U/jdwsdN88B7suQh18uzu5tBAsXLhTWHv9HvzNww9g8y+OfNG3sNnyk8E58zacfH3j s7M7kO/0guZ06/R5kWTPj7y1TeSpQvraFsEb2Q0bB9+B/gOfFeL3Jgq9v4W4lxTuFAY+ggfvQT0c h/CdwujYaKH/rcaZtc8OrfvBuh/Dtemn5s7dUN7S/btd7amW9tFlb6yetQgrHAGgeU+zHrgBTzh/ SagT1gJ5juA8AHMM8PAQ04z1FHkdOPDS4VVCXpcdesLNkbTebfcAvgv2QAJCPU3oQTSlNKLzfzwf jSr6QJOTd27DaPFC27JnziC8qhRl6k00bUQlnIFv9WltdDlizAzLup0erS/36P1BMaGEoVh7XI3h SjUOTimmvcFimuGKaYeaHrSpQX4NlceNdCn+8Tp6Pt2AmrgWXwf9DGqztnPr6DVoLbcZ9VBZ0w46 i7KWPq6XP0AfQP3mA9wYPYZOMmPcOfos+oPnLPcX+hL6hP4Yfczdp++h+577XMRAL2AJHvMKPiTg 4Ti3wVTCGuxuB2vXEzpWbzNbWdsWjkZexLndfjOymrvM0IxokylHjMtmgrMSBMd7jgJQPLgcHJbL 9IgmbXa7Xm/Qu3PwgWyg8XeIoybZnCNiQy0c5HLEbdnklU2tpk9NpOmn3vU71I7nYnDNOhnFBCgu TJE63u9iW5Cvz5qK7J/tNFU6w1nsscJOgCYhev//9yzadqZeV49fqhn4qlJgBrsAn6prh82XwMKu gRK0F2+UiVxKkG/n/73MP/1bhbY2lzQD/i0AL9V1PpW/tbgutGHiNvz9hy0VfFQnirQztoda9nBf 72KNKFKVvshyaCSE/F8VJvMDQE1gEuVAGNQS2+TYUrCU6wO9XJ/UzxysGGAGKm4x/6y4GS2rBS9U bJX2V/dLR4WfSZeYSxWXQiVUMkfcHKLXTEsqqnD740qU/2FzxCXZF8Gbi4tXy4EQ3lhPfI4wR+xj LsMPhSvSDVFHCVA0ViPSpmUZK2cX7CFbrLJ6rjA//gxsdy2t2EuYEUDJNrhUWJHsSvYkDyf1TIyp bgUk0jECF3JFKS1Bcg6uReoV9guXJZ03KSdbk6uIVeQKzQrtCt2K2GbtRmYj28V1CxsrXgi9pN3O bud2Sj3Js9Er0U+EB4KrQ0/zrMHnRzxr9wUkAZBUBCTCvED6p9RGJLLSH0okDPYpIYfDTlSGFKXs wt5HkX0yoYZZSugZSs2MK7dDsxvUKFtxfuFyNyzhYm7C3UaF+dpIlfIGmpuwyJjB8ew5TF2jSEpJ lhjNcUBBLwUx2F+QxYi2vJxoi5TRtLIbjXj3Yy3TiGijvcotfagu+Wt4AfjASujEUxgPknC4vnkS ayffmQ53pme3j4EqcuotVg2THbgd1ysKzUyqAssUAQYvZeJMqkMFr6LJCofVwTIzGg+EnBzUMayL JbTaoIDBSgqGnEEJRnVVEgxwQYmMwyqJrGCnSDCmqZSA6PFLgKsmExL2FngA1H8NbhTLhQcA7vuZ TAZk0l8BKsDIA4soqg34ElI1buRmjJ2BQMKH2UfJi3a1w6t8qjM/tmUKCenIwVcaVvZcvZHvkdpE h6eiWSLmv7Vq76Hv5V8Ul9ft3rPo9PHVrd3p4VNLTu+c0c4Sv+JmLXv522Nt4rRAhvzO930R0SmM Pv/cm7ROl/ph8/PH7A+/yx7Z0rL7aUoDsFub/+gjDY17tQAJeZaBi8IoESWj/F66nztCH7GM0KOW Uj2H/z3cRr5o22J/hdxhP0juZQbIE6ShjDRRhKeR7CA1UT0yC5gxoGaYYCE8jmljwYh3vybkJmGO uDpsDr+HIMqRM4d3Gt8wEsYcGZWjVgMxACCE1WjgXTPkzSkzYWZkLEBDvdcJaSfvJJyqPJxN4upV KqSGOzPNGCc6P8+kMVCkcXvKp+923p1ITd6+i1uO4jHG1cfrtbHaMp3IBEuDdlHLGqaCMhve9C7N VFjiME5VuBR+nUoz6U5YHlAPXRnTyjOocWipgFcxDxZBoVTlydVQF3h+xsSb2SvbNk/ue+nsVv65 wqcnCu+O7RiBqZN7dj5hYa1MqWZ9QfpgpK9w8Wqu8K9d6WPW4WMPjn9xDj59otFezsYUDgzgKbkV dyc75nFS7ihlSz3b0avoz0izGW22ZtG+8n7bODvuuYj0TrPF6uFInQ1mmV6OCOm1PIv5QcezRl/A 4XPxIZPJSLhCdjvQu+tbLLBoAmIW2aKx5B79fUQ5Q0tTQKnFGamEHIDeAOwKHA5cC5ABn0OtRoda jQ71uB2YOsoQrkatmtQySlJ7yL/y8TNQajGv7tgvZMKfqw/lvyVX92WJuRmOtiHRGuT+Q3f1x7Zx luH77hz77CTOOXFydz67d9+dL3bixP5ix+lCk+bKmhqoRiPaprSbaUs7WtagJmn6a1JJJpimBUH3 BzAKLFRAkQqRKKLVvA11qTQmVWwoUlGnsaEGqS3pjyBA2YqW2OH9viRNuzFFd/f5uzsrfp7nfd7n rQr3olAtnCIBvRdpNWrvMvzPPEOT0mB+IPNwYRiQiiSPG8cAdQ68EurCyvRG68K0AuKIoM5L45dK h98b7p1G6dKf/7XjkL0aHxL6ho0me7R08UrpxsW/fDWMNiAZqWh9hGq9EfrBeUA8g9qcLie7L3w0 /BNyVhknr5GprNir9rv7PcPisHfEPeI5KZ70eqO6FsGmrWsJbIkOBUTEfr/u1UQPhRLTHQ/med2t ecKSxiML8kckw51JJLlmqZlvLvBXoFU0JUBQZyLadDgcEb3jouge7/IMe3jOI3k2eQT4rptOD/uu I8nxpoTenIJX+0LjBiSaa5C2N/dk+7Ons0KWkxhVEmNFYlRJph1lVEXZZpRRFR1rnXoFPcfGF0oT 4wpqJj8zm79eBLryMx0SI+wudHS4lFhrB6vsKHbQIU+auctJHyTQ0pXSCRaWRwFMKyATsOpjUCg4 EATbonUCe8Kisa0QSGsJVmgcNQ7FWt227fdXf2lr6aoUf+Tmof1k7br44bk7hCQMORTdQly1VbHa TDr+ZBlfnLaSQ6X4nrAVL63bEZON1NoTpXFblpw9wsAzq+J26Z0DPbVVlFEMjOrAaDNq/F08VUCr nNX23javy+s7lxJ+lHg18WbiXeFK4pbrlm/ONefz9pf1u4eB45GyEfdJ4Fj0+LyNvAdXVBRQvVMp ap6IrsnYdAOpdKehTHP7We9cpWv12Eo0xX1ihauMB6oBfrmZs+q5uBTn45RpOxar5+tkMZaIj3MN iGsgDU5Df4Or4QW3W/egTR70ugd5aDRLcn7GpJ+R5mdM+s1VEcZkhG1GGJORseQnim4Waq4DUtpA 8TpQCOz9M3+fvAAdoWibgxJcZK+4fAUKweGge6IApQxITPKWFQjK0JkymdoH+tIyf3Af/eLe1k2V to1i3evvVfqMJtJSfJVsqVcqfTqIQvh3pRXqfvIpIO3OxoOl7KYv2KXefVitVmy7xXha6Ftcl67u 3B6nfFHPewn46kZHF+eCl3MO/ZmcXVj48AJFxG4tLMw71XTZyhBoZWi01sADTg3drkFmBb2aDDWz sDDtMNhM9qAZWifBPBGBowmOFBxJrgLOXji64OiASaO8k4tGk518Muzjua4Umy/ehrHi7l12Qilq TBNvJ+j1b4mJFpLQnIH+3OncZG4q56rJjYWdth5Y8tW6Vo5NU9fC2GzVtSQ2u3VtLTZ5XfNhq0bX NGyBfTRjK6trndgCBKxoVFvb2Vle7uOTzc3hsCZW15i8Y6JrJjJMYvabp81Jc8p0mwXecEJSbldu IicYOZTrts1sT+uuVr51bMPu95XEY9LsIEiiQxoYZJIodqxkdfhbFMRyNoEAnk8gGrtXGK4FT4UJ 9RMSwJ8uiqVX0Bn+CKghQQi/npUwyKGJkOIfyOZ6tTjKbrUUX1sSCtzhuwFEaOfvoG/vX5SHLK3b O/+DFa2gl0p7HlDOgQceo8rJQMs8BsrRuUvOQcy8GDPpYCeeVfHuwN42Udd4bCq6Vo1NVdcQtry6 FsBWdQDKVVRUnqpGFalKVBd9VTW9/eKIOCUKCyIiYo+4SxR2ihPipCiILvqYyBQoFhb+e56+C4uS E2FtYLfRj0fwFBYI7sG7sDCBJzFPSfkiMMGKFULqwOBSxbIyXWSBnu1PwXWZCf7Yx6ADUBmk9kNV Rdfz32dr1t0W/i4EACGLu+Ws6a5GO2t2Bvm9cr/8bMVvqibssmoFEdux+ZC4CFSEQVSnhKU6lUc8 CTpBvieIggXBd0GNV3oj4cLCR+x3w2L2PMWDLhxMMQmbXi8RHfGk+DPxt2LZ6+I1cQFQ45dguu0E GUx1DL+QfQ2y31TULvAtv8dTP6d5/nqetab8AGSIJYxmZvIDXR0spN9PEFJI81WEKsJrULlPK1fX cOBmHSywDUKoHqhZQQ6itQlBbXVbJk0xTN9H9y0GoPLoL4e+0qfiJiMTk6NaiuFZFmMgFr9+6uJ3 8x0tqt74eNtntwhj9zFtgP7yMmBqcOccDeY1ZHAGcsxt/D7+KD9qnDLOGq8YFcgsoO85Gf/etq38 E6t4UJ2AzbrVWqDT9OmahC1DNzjCOTCS/iMckPiwxQsiN476+AL/hpOq+38BzOv1MVfzsV0fE6Jv DO/OrzSDRdxmZ2kjp8Hrep7CRit9ECodycLHRo3a+qViZz27zfVDPDR3M9Nr17JI9bW+bYZUkf7W np9+cz866im9YD9iDAkHaJyyUaNzfH58s14bTB4GVEyOc/8HUCHosjNdpSA/J8p+tTJe1VDV6CKe 6k7UmdquHET7lW+kjisvoh+n/qT8VZlGd5TKSgXCt5tsIEKb0kZyilBHYko9EdxKGZFlIcE1wKc1 3GfkdiWrZklXelN6P/c0d0Q5rg6RUe555VlyinuRnOV+RU6nz6Xfki8rE+n35XeVyfSMfFu5rU6l P+Q+ku8R+3Po8/KG1A60Xe5NPSUfU99U/kiuKlfJDeUG8Vfpmhebhq6FsJnUtThzbBFbEuv1WNdi kKsVxeRQkFNUDqmKUuAvO2tJKkgUmaQUmJPgf5dDqirzXlHkOEJicZE8Di6lppKmYeDT+BymrjCF 3XjMSaM04ulXVEpVRlWATrgtzC6AS+rhj9F0Rheg/1QJCGUWvmzlMtRE+3NiMlF2QnoDrgpbKCvO Dl4zMADt/dEnvuxoKSlY0YUWT1K7ogTaFam6nROVdrmwMHlBbpdJsJ3NpYvHdgSlhBFVxsOWXw+i QegBb3rgNhI2FGc1u4eU4gRSedC/cTMaQXfRdTSS2gYp3e5JFSfINquu+IHr8PyRE3qjbbcag8KR HfFIzJ57z8U+zo/evzE69x2ouIUbC7fLfg3aiqFLzsb/8V01sE1cd/z939m5c/x1Pn/E9tk+23d2 znF8dmI74CSQY4xBSmmqLoKAiCjaiui6khAChbCqfBUTVAH7oDAmQUdbFkQkaFJCoFSk02DTuqrR NGlpmQSV9tGt8mDatK0bXPbuHFg7VZPt9/4+nSzf+/9/Xwc54A4DSaZdxcMYuDCGepxxz3dvdx/H t/Aspt3xOMfqWhuP6Vobp/S+ih69ryLHuQDjOBf3cFycIPS06qwfhVqLBTAfZDgLZfTDxn3V5Yqy OVZlKXZy9vabLtIc9gHh6YURntiTKd3xsyQ8pSCagldSt1M45fboP+GNxXJxmIoTX2L4ENbwIZOz d9Vaw6EE5PWnH6C2yncPcxO5QOrf68rdUe11pVKuthkRG1cyWkyz7br9Hljco8oWLsCloAOVuC70 CLcOreH60De4Ie4HcBbegovcu/Av4O5g0N36akS83mYyEpcRnh0Zj3AdmDzDuM/eQTLhxxNkqNRQ SS/H5jbe2CYCJaKWejmjOrkS5+NKmPWST6BETNjMmLVEfma6uv3zoqeEVVcJzbkMmNv1qUK9FBmq wuf0TfzfKTMiAg/91AJ9YmBGnyXp3h4+2UUGSx+ktgVt4Tbzo/doyvFgVP49bPryvbcfDs75JY1u C8Jo2exH5u3mZ5AN8egNtekYN0KfrT3Lmp6DHXQZDtCmxYxdRpRXrrH42wUqS2FEsVSUylEqZaY6 w3p/gx3FaFgN47CrnbVELdhpESzY0hn6etWD6zF3Bbs5/fdq3q10VAyRagbembAmg0l30mFzZRAP /gx4aFL5zKRia+0ZCGCycIw3g+pMZPnsYaV3EwATZSEhN6av81rqyGG5WF3FOBdLMkUFGNirDWmf aB9re39z7R8Tm4YPPTt+7dPhTeZntD7tV9q72kY4BO2w+BdvdJZHtKvam+MHoAEWwdpzBwgl6Yxt ShvuqRG2X0YKedTvthazylb/ID8Y+pbcrxwN0Tv8l6Qr8k3+ZuhDqSZQzypyspQo1bfJOWVN/dP1 /couxXoDQTCUCi0P/TpwkzePyPBz6YO6D6UP6mfkT6SakCqGZcahU2kcBJ6OiYRovTERhaONDWG5 Q+wSSeSgvQ2yz+fFDM1wKMgGc0E12B80BzsVvQULO4pIAVW5oOBTypQyrVBKIxgCCYYUgiGQEHc6 DLTNJShDHx0nM8okPDce0yNT+rHPRKY5vPWuWEzAkKQyf+SNrbK6GqAqxHFkeyvEdnBVBSVNDUmp upA/ISdTdck8SCGy1Aca8pDgxTyaa97u3aizm5iUCKEfsc0Uj0TbSAsFBDppExAQm9KLNg/AgA7H 9BcwrA6NZnIWHt281PsM21IgvBun4bVQckXh/ltEnz080Wf4y8Qvj9z8WdPAouIT4Y3Hlu3rzj+O d2pbdwlEn+cLg9Q39Wr52NCZacfS2tof7uo5ttyto0LrM+8gqPCiJLqvppZAD30UqBoHrCLVBtgG ++EIepn5qfN3yGJyquhLQK1kqGOmSTytZhmfzFIoMsowun/pR7uQCT3BMHYqHW8X3Fk3Rm7WHXXn 3Krb7O6UHyBIVmUsB9tZe9SOnXbBju2d9V+EoN+SU6/0Ehy1d1TYv1WxpFqS0UQoabXV2nCNPyGJ CRHXCN54BsKWIAGPkyxJF/ka80Qy5Kl4G9ksTMDhy4DIkSWdJkdP3kaDGshrrgu9Zp+vzpuUJN0U 4mIVax4ED6E2r8XQPGr/hsqxg9oN7Q8bjnQPleEgEMsCLxLsDU30vXRo08WrW8qPlN52Xjhji5qf Gn+qddF64N+BHHxHe1Z771PtgOlPe17VLmiXxoaHT0P7X8/s2qEjUETIvJEgUEYFjNUxya+PbcIY 3nIcuBeT18XrGapT+lEG+4U6ZYNEWcCSSCaWoh7ow33STtiJtwhbotvi2xMHoRw9njkH5xKXklcz s5K3JroPXpL21Z+QXofX8BnpfOZaZiZ3JzObsXPIB0HMyQRlTa1Ka26D9HS2toHBoRB4Bd4Zi6OE zCOSCBwkC+g5VlRxY0KS4hg8JDZJoziK6YbU67Te3Dr979Is/Tj9JE0doV+hMY340VBhEr6tOpvl cDiEnQ4HAGK4GLl/rKeob+qSriKKnY/hLmKKcOwi2wJqS3/LdAvVUmAMZDPGOTAGspm4z2sg22tc 9BrI9p4srr8MAfRf82vAmu3Vk286raM6W0V1dg7Vc+apUmEJrHsHsun75EIgyFbKDmKfiL4CVwoS lmArwE6ly6z5+Z805fw67jNNEVFIZMRsHpoiZFHijXkkSrlocx7Qg8kiCWSATNWAYbkuo8Ts7TFb CYjmj3lKBAe3JzyGYJLy7kW2lGOdRCKhqozEbqXTsRgYkP9/lEADmVhoniMFwgnmjdrLWjEftUfY UPLRokEOhnmHP8+8d/jVc+B/8mDfvQXukOXH10/tbf0aHsIA2rbPU0TH2a3PTya1nft7bPh7MLLn hVNuPensmv3IZCY8MR+vUgPc0UZwghNbKeQ0yShlTndBF7a4WifhK+p0y/yWIMWb1vnXBdYF1/E1 ZrvZgRqmWk2D1kH7oGObsz/SL/Rn+3PDzH5r2V527HOW0yOmkTzL2fP2gr0YzocL4SKx0Dhjikai QiqVyS+EhbjDlAvkIjkhF1tQWFBcZl/W0G1daV/FrkytTIcFEDCfF4p8S7e/O9AdXN28Nr+2sLa4 tmXNPAdltabcVj4lWqOtbalc6wA34B6WjtPHs9/PjWSn5HcabqSnWu+2eh5j5vOoD/Pn4X3A8AIA XEGT1HLVXjzRFOLDfQIfiVwJ61cKgRMeQh7tNofHZnOkbQ0OU9JibDUi3CcJSG6iRNljwaOgRuIF ACEJyUkQVTbruubCt1wQdZ133XJRrklcviSMRtIsQbR+g3BKgWvKHWWWSJu6tKgq75MvFFKiSo4I nkm5Cv+hu9pjmzgP+N35nj7HvtzZ58c5dz475zvHCXdObMgFSk5rYUDSErZIxKEGJB4NDR0kYgjE AmhtB7SVxmtby7SJauuArGtJA2mg1dqtQlM1JtHtH7Q/NpgYZWqjUS2rxsDJvu9zeGjTYvn77mGf 4u/7PZdiLr4Uj9XgXqnkh4BYDk9PVYGJVYddO1/LHsi3YDUAA0B1Pgg7ASZ8Pg0gPQVaITyq4MLQ 1Jy0zm90GMnK8s1cG5YLQVOTwMA44NTfEmjD+EBz3hSAxYWCuSZDBDbH2jTEfB7ZGRpqmQWgH2C/ AgIpt4HfXPeMsCFPVsoVHHgsNoShFhLgYyGXdEJumxNC8bCM12fmEZk0HQGQj6oE8jzYMdI0k6lv U4kazM1sYzZbKs5va4WaPH+B7+eGWHnz6YGD+cV/++XLXX9/f2FR+ygRb2AMI9F3fuvIkQUd5sxP j3Vf+8XW3e3RhO4HiSh/4OTafasWt3WNbH7u+KoTf+aoTtXGPzl6ZP0L/a2bm9WPdrzSe/QPpbhm Q+QvBtnoLMpGX3gd/Xg/0d/Qrw7ig8Rgw6DK2nqnvlJ/lfqBcpr6mcIQeIMKZFLQ0xxUzwwTy2Aa IYRYfZL40JM4PI950WCnGAKP68HeBn45SVheguWQznFI0jikc1w6Kmt5FepjEH4DUwV1nXpSJdWL hIXJs597PFRBGemfDJ4+ntpYieUFUBqmK1DwVCCwfAk+4B0+VAQLnL8hLEKyOI12BvP4Enjfv3UT RZ3qIhBdhI+Fj2FrBKlEymThHmT+S4dgWgfbIpGvh7K8pD3T+wFI5Hb1VzCe/2SdVVzBZAWqe+bX vY0dC+5O34/iZCAobX0aXwxXlZ+9Ro2BVZ2HP38Bc0DtaLKLDqwfqUY0e71ysmjRHXQ3vTtEGhnD bM20mksyS8w3TCZnuibR4+zg94ROmB+Y/8rSi4LAogg9rWlKXE83aQquZyRNiemZeCwGfIowrDqu CXS0L87BVQMHN1GBQwdwBXOwqQkcx3oBl/VASGEdlmBBvfPqw2HoPciHaPhleHUCGVIC/adPdJYE B9/unHTOOtcc0tFSaDNTaDNTaDNTaVHcJ+HbJFxC3iUF4T1JhfekuD39sP/Bvoc26SkQSVEDzFdQ QEUXIa+RdeVRDO1atXtsAQuom9Utf31az+gEHTJMozGYasGE+mwg14Lzfl0wWjCLN2CrwGvhByQf yFHARWwIUhZ/0MDCNPKdLPCaR4tZGPFvzoF8n+DX2nrykVVTl/9000ktebKNWFHsbYw3dH934MXf PwkchzIN43FtqPrHy9dfP/Ht8j8JceQpwyg1DlfHVl4eXrHj/FXC2JdqBjgQQSt7C7KLEM/5Q7RG jBHE471952RcFeomfX95N6gRMhMEQcLuFN1OoXrlyoe4XXAULyAKOi6zvHtGxlGaiKE0Md5WKqK5 2Uaz93wqU/yHeFe7rfsuRi/E3kuc1e8w1Jn4m4n3qQn6AkONUqfoM8xo5JRM/ZA5HDosnpAP69SW yMboDnK3f79O9curoz36JnoLQ61hyuwa/9pgOUJ5eg/W61tNfZ2mUnqRbI8sxZYHKYPOMRZrRSyZ AglSd/T1+hWdGqPhj/KSWFBP+eWE3CT7ZKYO/kQlCHycYbUgAflXEaqXLl0CbaMCVNt1FS+MUbiC hSKCEgqy4MNaVFW0ydkDXr3M0CmWYUAaCoM0QNE0BHBJjoKzqBYCMQsjGJq7G8WjnzqyJx+Wb8uk fMuJeJGeyNnI7QiViqyPbI/sj5CRSeKziZT+fX3wpRgUj0p8unKjgsVQ9QGvA1TNO8AcQwd54CIw Fv3vWAayMVR5+IcSDWg2w1DyOX9MdEOe6JKTs7cmBJdlJRfExqsTkuu3JHj16ljIvd96yyAH4RGa AcuTwaEImQCMNHQHHK8ZgVmi3lpmlHIzpjFDmkJ8+WKiaW37PLyMe3bHEipAdRt1emHT3b3kkf6w lqEMg5vX2Prsvb/66ne0NJR4IApQiZTZ68wIQKDrU2vYm+Dw9lw2XA/Q54VElzCJJOcoJC8SPIvZ AIZRtxMB8QEU4xxdxwRYP8f4/Q7tMmIwJrkB8FYgEFmuCOb9cE6C2bsFDuZzJXsFVyb7uFMcnaXz bDNvBSzJSuSUJssszKfdRNH5Kv0E08UvU3rpPqaPLfv7An2JPqe3sIXeyGzlBxIDymDbTnInvZPZ 6d/F7wnsSexSRpK7Ut+0XyRfYV9KHrQPOocKR5nX+GPSsdhriVeV49b37OPOaXaUG+VHE6eVM8nR hlP2ODPOvuufTJxzfuPcYe/w9xrupFYM2JucgcIhjmxXtqrbtG+0kJuYTewA5+viurVlVpdNlpXV 9irH18P0sP28j2QwP4hZSdluSua0AuPy3BzqGzBxYYficEmSr6+trCKyDI/zrGuKEPYA94sQ8CH0 UWCB0G/mkkmW4/xJkLtUlcVoQAQpEVYky84plhgATzHVrGK6hXbFnZzdPq7w/tTk7DYv7LBMKsDz aQV8Wkkkkyrn90N2RJQkuJC0G1g27dhhx7ELNMPAO0mnAE4LkmhaluuKGMH7/SzLcAt/TL9RAHv2 jlcqQInpQJOXbXGKTmF/4XDBt7KwrrC+sB2dXCvcLrCFW+yn3Nd45XyCv0iksAT+b4/3Aj2BKwFf 4FTHwkni2fEa0b6sTN2ICzdiQnUalZR89eaDXoKmGvMOBEdqzHt4wI48wsX/T8ZHR0YILmLBixEW QY7e5yfQfyD+MLVBgoYtS67rVOGQcsCgxUS+E30AlpIyHknP0XGOkTV7QJSUTDNbez1ycY6nmRIz UvqKGs7PfMea+e3M7xpnnmsJhJcsxL+Mldqbcf66lQItTorHpRwhNLYXW3ASJ5ob5OxjgMHZYuaF u+/5Ntz7Ebl5bzRrGIaTzuytMsSB4TWtWalOZGlwKde2r6oRn33LiVpsELCawJbPTvkO+d7GWrHH fMtrvPZSnR403E4P2nPkP0xXf2wT1x1/737avnNy/pHLJTnbzzFnkpztS2o7iYOpTR0IP5tskABi HlZbwTS1a2w0NLoyzKCtALXNVI1NUxFlYt3WSiPNwq+yad4Kpe0WqauQxh/LGk2ZtLXLlElQIdE0 +75z2u6ku+97z+/d3fN9vp/v59MmJgyHJDGjhl2iDSQnwY3lJa+XGU2qdAr0/2bLhSTVAU20ZCft ucmMaEcxnqBwIE5YkkiiINcZ607JeSfcVM4HAvTqgZ/kK8u38kE6SZa5IxrW7FHNnqEpRlDMxjhk gWKHr1n0gn6HY8Zaomlwy5zBFnRsSqzVZk3zunJrpqfbNNvyT0r6ySTj3d6LvSSUqeZ+4bzkYr2m 9zA6nHwWnZJOpYWAVx1QctUc59S38luF9WR9+9aBfO5EwOFqEAlq34S3uDZJm9Jb+goDm9bulPZL zziPu45LjTvUYyoTyu3NMSVHEqWyic546hokoIzk5dolZ0bukDIy3XvrQFoBdDMU4iWZJXY4KHNy VgM+z3dKmWFtr/akxlraEY3RvhdSMN1xdzafZWDb4/FqnImn4X+7wm7IezgpUYvjeMlASbcsp1Lw x38KX0AYTV7D+9EqZNAnNmSQETKqxoTB5Y1Fg6ka2FDoJOMaU0AiaoJEDWWaruD9+WCblekR8w0Z Io6IVZFVRLwo4hGouIUHC9+q26dypWJuAw9kgsSCjgkaeSX9lE+KoLjuLM0XlYVybqEC/sr0ZOgc 07Tq5DbFyhgVd4PRytDPZfuoofQaPcL7+vp7+xnB6XA5GCHcTtoZIS1lCPIEfDry+hpDbh23R9bw GR31O1IEp1OSV1d03NAOlwEhq1NTVLdUK5qtqwtE21FcwWUQbeUK+KhdUzkvTcyiiWiFne6BnQIi 56YUO1xqyPQR2DuU2ymZhrm8JGU0ImWa4dQp2lslqL1Spq+DRhdEF0QnRKdtyv7/2A37NIAAQB6m U329vX2Q3LY4bPbXx2xP1qyCWFRVahP6mmwp6YE1QAcwxAw9v6p37d7vBjv/+O+d23NGlLGihjV5 9qmH1+heV3OjIjdlx/f1DOAfxYYHx/q3Hn/C0/L9bxZ6Br8zturEvvb22EDigVR8bKIz9JD5zGfv HlvjF93Z/tODL+FitiVWymzcC5m/fH95nr3Kv4BUtAp/UM/8N4I8zWCF5jLvl5HmotmryVT800SX KczokN2geS7T+W46X5a1ZsQxTh+VAx5/3gnT/E2ozXBK4d0gS0GRL+RmzQW7ctl5OmvWlLchaUEZ rFTAKNyChVvAOrqGrg3yfNRAGtCIMKoxFL30de5N0z40/nOZDsly1PDYhACJX6OtmZXnzdDHUelx SIni88Il4aL4UYjjowV3sZdEv80e5J5ln+NeZV93iEMiHnD4V7vX+YL+Qa1ZRlybikA6f/EmPSF+ gmdKfJW/wLP8x7KKkLZKlhX3iHvcPeHmqnCZdLPIrbiJuxuaNff7btEN2X85m3aXjD9sqbsXSAzq U2jiLBUrC/abVnKe5szdhU/xXTs1OloIK4lRwgYJbnVpOmrRJFl3QC/EhQlukdp0FBDaCKLgo8C3 vcrRowB4wHgRV0AVAsxA84p1bKWiFIOrjaTHQ0HXu4JJvOaZnzz/wU9PvT7ys7FGouldDdgXTz6R 2XPmzGPpdAfzydX//vnOD6sDA+zFlze2KpHxpY6lvz6QfOd3k79t84Mm3AAY2gzVI4zvTjk4/Hn9 YFoF274JtrUT7BogqEajUyyFx8MMtRsXKZ7CAWD8aR/4Rmi8d4lWlEAPCxQP9G0Wc9cXbKDMXKcI 8UYojR7oiqdQhH69ZvdOntF9O7jt4Cx2iLvadunifv4gX0XV8HTbDfI+mUP/4J19eAiPaaP63khJ K+kHtYp+0vuCb8Izob2KzzMXIr/Gv8c3xZst/3LM6x+RO1gTmM3end5ToVOkGlmMiB6Cf7M8hwic ISAMFECUgLsBF6VwNcygsALuZSRM9zURfiU8Ga6Bj5kLL4bd4X2BDxtx403VcIqwvdtT/gwN+X5v BjYphf8UkvGw/KLMyJaCulEeldA4mkCTqIbmkJMOMOi1A63HWpmRVny2FbdewXLeuyhgJCgCEbqF vMALhfbCVeYHyAZWpbxtoVgpL5WL82UbVqaZW1go29Q9711JMdf2wKOBAwH2pQDwcXk35EZ/fz/u BzdCYYMqtsKZRopGNfkiWA5eUTKYajqFMmPtDaVOeJgajzIWAF5MOoVsrEGb+o862/nr3MZuNm4f e/mfGE8/96ue2JqgR4pEHnxs7VfOnXjk4b4U/trFt7Dw4W3c8OK2qBVtOhgKbn7k3Pn7hcQh2P3g 8jzHA0OFUJzZsoKtqJWnyOoUNBtUjjrAbLAhElBtwlIlQmnJQ/FEZAo0Ys+G0Xt5G5JEoyuI/ib7 dxSghRp6gZCXUpfiyzsbmFGfH4EPEmMx1lYclLksOPGKwpgFfVGzwQka43P6+qoXViEisSxdqo8H cD5QCjCBkAS3kVSbw1SOEha8oZ9GwjU2wpWhvxBiJTrtOfbmhFFBsBI2q82YdXIzazNgE+nLFIsz uQXqr2Ype15FFtinoaGURVPkITORKllPc0/zJ7mqdcGqWWLeqloMstSuJnOUH3XsME+L4kYRE6vP NeQac/2Y+3nXK5ZYsxZNhhBEwm8C2iWoguuzZJh8nexzPU6eImfRWfKaeFV8u0uKOnyr5XXeoG+w KbBaXacHA4MhWCZxsSb7XwvFcCwWYqUQksIyoQLD21RSq+oFlQ2pEyqjftw5IlDL15FI0Xh5KC0U EoUjdX4ElbFUKWaXsvQAqQ/kuEDpUbH5ESlf0mRr1OQcq42oo5Mgk4NLh2gQ3MXHbGLEdUos9lOE A77LuFIuQn2G6lwvxF4oxOkvmbFejpv5SNqTYL7AMHOzUN18eu7eW4eGgSFbTTf2xBvDaltc+mwx IWQftXat3zP5+J79G9bev3EDD2375RmbKO/PnhvSPZHyu/j24Hhm+BvvvPcXQPRW4Mvt7CTyowB7 eAXRHQ71f1RXf2wT1x1/786+OzvO+Xz+jR3/AJ/jxHHiENvgkOJrEtLUIU2AtCTx3ESANHXSlMQq rEKaSEcZS1spEVXXBU0EbW03tX+UpqY1lSjpFLGVNWu0TahlaqES6qSVTGxFaNqWsu/3OWzr2e++ 3/fr7r133+/38/kC3lmsYIJEZkJmAVN2JnVCQxAaOEIUuMFBsViJim6z2UAjNT7NJhJRETkRu3G2 yKIrjBMNlXtX2QxQrryD3mBoralhgQEZNFgQWhWkN8ysAY5bVpb+B8Z1zmlyFsIRH2LRia8uovpG CV+iR9CEFTEknhN5Io4DcTwrGsRThp8ZFg08vkqEraEnRtGcHY5gAPaJKuwWzB53C0J2YZMsBwPf hPD4yiqieHG5WIxvZWuFlaK56151zFP0jpNxx1Xe6A35gab5sy7dnw3iqsxd+ZQURIgIMhOLpVjz vsbmlE/wmobtj7vG3KOewiaR8iZBNEkWo/NhYYZ7XjhpeVY5Ufdz7nXPefsfuU+s15Q73Fe8XR0X x6VJ2N2M6X3xN9bbIiCdWPsMx5vQTwTwk3zG1MM9ZBoIDnFDpgNciZuxz3jn7S+bXjZXpPOmc+Zf c3/mbljumB3SqkiJuCpyUyjx7Obg0M5Buvh9g4MkXU5cql3NqmPOY84F53Wnwen0/cFA4QuuAoAY kKLaUXys96pZPONv+Sh+EfFDyRXzZa0uOuE65pp18a47Dse0RJPSnMQlpVnpusQrki7BTqRz0g1J kF6TnQYyg3bFN+lqUtblQZknsiKHZP62TGVciQnOUu4KdG0wF0gB+tenkLZMFUGsAc9XEGhKaFLx kg0+EXDtCSdwbUgPOgB5AHoAYmiRbN9Opoq0a7gsEMpxUyMsOcCLMfILRIS31WzJWvREthaKhIgT y4pVgTFi0Vet+ap9GzVztWau1kyspsumrFPxZr0hW7YWCgsF32DpIyMjdsGNPGibewPBVEQwLQzo BeFAuEYPHTo5eiIRdF75yStf/u3t05fXT9JfGhXvwcy+49yOD5988uBTjpnPKf3kSyr+9rX24ch2 /WngQwOE8EeNz5M4J214t5ZgeJXQEXYSOjq2L04VWaCS3EAlrFMVzvovuooOKqvM9RlIyQLCkwkw ySxFtICbEGuDtUJ9i6ogkZbc2pKylFtZU9aqoLSEdHpZuYy/ZUx878PSBWJlcwhM1esahAg8SWqg zBGpgB5IGa9my/hYr2HeyNqhfo3xa1lONN2HoE/xBq9fWUHeiu6487nQvHM+ynfz3ZZe7wn+hMV4 2kBbEsfCc8KcuCAtmM4oZ2znEiZFgDg11jgW5/ySXA5IpzbTckCs8JIe3BJYCFwKcAFbRHPT+KBC lWRjg2oTJNGsgIFX6N63ZiHhrXB3F2ljvEIVvTbWQFWrTTlltdIIGutb4+MpJtvbqzKXq8pIK5O6 yx9OzckUTXxMnpSX5FVZkL1N7/ICL1YZVLFqlP1rYLoss+0A8UXxZglQKAdgtF7qyK1DZgsHwfBH 1eodrqjmjGqumJ/UOyJ+uoE6CDUECpAkmwMsrc0ZToO5ZdK2Lek2SAFZDsgYU5UwQebnbHPSV/3a zn3rnzbEOr2Li8Pnp54Ybk8F3G35YDDarPtv8bvXX53e3BSJxLoPcKO9HTPvHe5ObA+kw9+121u/ fbWzF8yPPPB1D/8n4OQ7yMNkhH9J/4HqGnwpOp/hSUIpcEcaj+zjSKPQLOx9LmTIbRsoTGw7HJ0s zBpmjcfdz3hm08/uPL5rtu+HAy+6X/TMD1QMF4xld9nzQeqDvqXCauFG4XbBtynkbFPSjkywYPyF lM/kfMTFZ8J5H/F2qTbFKtdaaswmk93uMEnTGlW1yr3PyirgkIafw2HJodRr1JrcgvaGdknjtQo9 c344Pg3JFgzVa3GsuhB+I3wpzIc35jAJU8IwVvfM5Wleh9a8Dk35JnSd/KCDOipU0u0TEj0mgWKD x0hpYb6LdlX4Vt3izZtbvHTQO+3lvBe53xMBnKufdECXWRC9e+iepiZr/3t8EvAuAPcs6eeTelBJ 0onkbHIhySc9iK9JC7pEMp1t5qeH6BDurRa8FZQrZcXBlM/KOASU27q5FhxpSAvGaIzZoHtTajZG B2KTsaXYaswQk3EkdN0po8uD8lddxYAROxwqJAt64SycubGAU/01llRBnv1xD+1RcFJPa8hFra5J 10cQ7Cv3/q7bcJ7LgsTAxdboqnAXdft8juZak/wgzw3ylPAKz/F4lN66FJPwVB5fjzQZlXdwj/wT o4V36VOQ15nfnPHE43fRLSCWr5XWmbIWL91U4lN3WSVewugfn1JuAneDhFZZ2wCF9S8QInLKWgmz 3iIIHA+DASXKH4WvhznAidKdNSBlcWzRrmvQUkLHswG5hYiDhaKEP/O4o33723dF0v46t4cao9rW 1rbWVCsvPBgdiDZrjdHHtCE/9e8I+Elfuj9EOmkuRB4w5vxkMNHvJ3vjQyHa7enx00fr9/vpY/vr 2n0w3LeD7G7Nh2hfPp3Rua4QxPGdhg4/faRlj5/sa9gTIrvcXX7CEETpiOPy7t+Yt//3agTHx4uW igh2UwzadHOzAjaaVtRsMxjEmyrLn0ZoFAgoRgHAHYwEIuDQlo0cSkDm6WY/1oNpVToFyVRmG5tF N8MABl/pVH2UCv9fg3p6aHTl7PHxX8VlXjDy1vj3ti+/0v1QUzCc9E/+7oHixHd++q/3T/TV2NLi WCqepc78oe7U4O4Du9q+/kdLsv3QxfLrbanTn9NHGl4Y+dGybhRM7k1mo9A7Of22I5p12EKigTea aif3Th08tX9rxuPROk0Hg63BLY9zJ48cPbO/s3R0YbTz30+3DWvJyM5jvSmXywCgT2ohOH0F2VyG m93AxrrtOjquYraZGRCaPRGsezZhxQPJGvMJUG7oLMPzyGikniiiZRAbouFUuj5BwwaLhXs0zJ4R TnjwGYnKvX+WsRWUu2XsSNz3MVBu6VYGyux5CQpZ2INmgFoVigYlBqWepAB4rWndBHPTGVJvq2sy iGDWLS2YCwLq3roFRrmRDzLSqixf3qosx6st/yG76mLbtq4wL2VRFnVlkpZskrItUjZt2VZEOZ5s SbFbUY1jt46SeI3lxMDceMWAAfuzY2DAsGyrt5e8BRqG7qF5SIABfdjL0jRpHGxDjSDI07wZ2NZh AzoEHdAlzYwaRRcMXaLsnEMpTTFBuvfq8PKSl/x+ztmBAvH2M7Xh6XwnUnKCWrhiOg+L4pJaWib7 lclyZbJl2aCQQSGDQoZRLLAUhVMUTlE4BbvZJ7WBwSfX8AAMHt3AY9lssdB0bTLt5ngHky7YBZSR OxrxCkDc4+WK3uiEXFyFvFkZVIY2i/Vi25XidnG3GMhIbKG4WlzHkFdkdrsxktS2Aoqn9WdHkun5 fnkkqc4PpEaSQ1uBDs8dmEi7lXxyYobZ6UmBdglplaapsmk44brMrshMkdflS/If5DYZRWowK6Qc 18ouZFez69m2zWw9K17JMnCs7HZ2N9uWXS28CdWh+hATSswsH/s9+DIyEfYyrZVKVBjiwyepiCd6 g+3SYM9Qb9DsZaH2RKgP7RlISwZ9dkNYYSBeGbRo9GOkIXp1d9OrC2DWVBxKISoNITpemGwFoWJk x9Z+Ujm+3hPrkMe8xvNd3rgcsGbGDn5jvqs02zj03EDcUKxEV66DdQYvPH71+0eWvuL9svGbU7bR 6zjpIfU4m/n5K7n8iUbvK67lODG5uBR4zq8eBUjLp6EJAV8iQr/4ks+Ym4IDRtCHcO6MEtyjKQOR nDIQ2amYEQiDg5CWw+AuAT+MVSAehsHv38HZ4ajRUnwYfHCtSbe7Lbq9d53YZm8BA/QTqbXUa2DD /WvA4VWJSZTJYkZ+AxeQ+qUYZIPvgajvrKjv+6UkgMxvgRKgmZnbiLEWE6I2cSBFLa5z7ejR5qBS 8QeeWShINU9ignRZEvGigmCn+kMx3N5DrxfPDIedgSjxISoi7KPEB9yZzwcDiU/8gcgNn0LOwDMc 8GtMuPf3d8o7K1SPNKlg1h226qw7deeys+8EbWfBET1sHDTM8fE89cVDfp8d8/uBQeo910zkgSCx +f7oSLITaJE2K3YyNcNNHqvDVkqC0M9DsU65HmbhEnrw1cMT2HlKeSLwTc6jZtQxvEzJwFhi8lC+ brAFg60a60bduGzsG0Hj6sDVXxAd8Lb3kANgvXt+mgrOC1tTm2SgLcEHoL7CNgDr4820E3wk9hTX BOt0C9cjo1NTo6PTUz8yD1Yahw+7PeFQMtE73MHiwQt4YHp0dKqRemwvlQDIieka++rrB2xTcdYB IZogtHFAbSHwblPlMwkSb5NamyPYNGoZtRCBuNWNLSj7PUIjDryML/GTaddiTXFvI5hLJPcuqbfb jXLvtlTebam8izzABWDQ8FQKqUyz2oZkPTE4TBfChOvXoPVDwgQgvXOStH6yIAyZnG6NAwHeCfMo cSfwwVuyBPqf2cs0LeBxZnt7GxOVZ0wgs30HMA8uAA/eLzkJUTeVklUSOyWVwfdn4dfleqTOLypv aBc737Auld6W5ZJZSpxRz2hnrG+pa9qadVEMP0juWeJm+McddwJ3lPvifWVP+7izvayVjbJVtMul WWVD/q7SnhNHVXvQHsqViqyohrrUGntZXbTbBtRT7JTyofpvNfiS9qJ1K3xL/occ1MPdqtVnWUfE FxQpoimxaIL3KckOSzoZqLWdDC6ri9piTDKVvr6kdVJsa5I2N2kgqWymBuT0BDyjH3DGzwGAZclM cw6XbnoTJ2+Ch/4hsRBTHmIhDD4jFrpuqfi5K5EpoRvtgHyQIelkSD1eTVWYqHXGYqppJZKmC0aT 7pfFcFJGn0kPTKZzlYnk5IyQEyIxVXVsK24z0bbA2ceYGGdMZLZgWzHWlhYVWVUNuSAI+hb7l1c1 +O8iEVkCvJumIUfG+CYX9znb5Xe5uM63uchzun7JYEbCKrESGJPg5HKCq7pX3G131w0uuGzTrbui u1osbbHvvZ168zuQIx//9OzGyvQxzH6PqxsPcfjpCvjVU5OaxkPlaRO3jCktAAcqzPMdrpHp+KF6 +3x7cyDABKPJX3WPqdt+ex6P3Q6FluH5bGychfpyZYOt0Ec4K5yFVPOmoAJt4pBtWsOQN8OvzwPg DSslEVUmUopgp5UUvwv7HYfuLa1EMtGC7DJbAVfEjHMiP5SeSHVJUigUo4wU9WISU02G6qH7rlh4 1hZP3J/n7akhduHlb1cePHi1f8wxn28cHuoZbvzTdI813NmBrojSYSe6RjWmBi88Wv/zTCfn8T7R tkV36q+Nv5xL5Tpkx2FdMf1L7OuN3eWiwRxHi+ipLwdeuDTXow2g0jwH/qiA0nSxn7bcUQdzIHeM c4mFGGkGI81gpBmMY5KEsgGDjyg/5C0D5GiTKBgw+Pt1PIcHfwvi0A6/kBADgYjE4qQQ8S4IoASM YxrIWvleBjM+9c4zOV86Rh4Xj2Mbg9MEIcTIphiRBW9NopvyLYv74kUD37I417u/kLaVgSO+S92o 69v6vh7Q0XvKs3nsvUOlqTzTr0a/NrmgM09f0Ff1db2uX4aJIT6SDM33s5GklB6Ip6OVWDI+A7cU kmSBOVHeXIaT6UxM5eucLXC2ytd5nV/m+zzIr3Y/Yzp+8lWe/txmoOBhqHbkMl90lhYyzpn5uUa5 7CY6LCMxrDEteOG/laViH7lIwLs45+c+5CLSWOBXwqnAH5suoi9TrbDs4bvSNXq1Wq061tL7MXyh +Pow4in4jscyNCtzsDDbmjXbmoURL4WzZitzFZpXIaBUCCiVahyvVm2dV235S7W1AAw+80ycW5Vx mWqGTs/Q6ZkCvEAvgoGCiqfB/z95ETyv0IsLF6iEwakFkY6LuEZBozU0WkOz0QNpDXuMjHLryS1/ DXsU14D/f/MiONUWm8cfAUZhHbvbzI0feRHTN3tusebhnFyNnait1V6rBWpL0txBY/BAJDR9IIgV DdY0AOeVFcjXHm/jp2VoCLr/HzahDi3gPUP9HcrxMk+RPw3Lw+qRUDC0WFsKGQfnNEK8ZreRjWSo hMlQLFOo0L8K/atUYR8fEfht+3QBi0AMF/xqkAaf0NFC4XQVPR6D1RaDYPAfOlqtLp9uEkd72qpw 5/SDLQi0551yGUUZ0HslenTx9LvC7JN7whH45eA39uTe9YRhGlB6+Z/lHq83H9pd/rg7sAkQX8Za KRNl9WUoieyRpLElPrrWX/gf29UW27Z1hnlIiqKoCynJom6WSF1pSop1pT3ZaUzHSRxHVuw2TWKn deJu3rI12WK7SFJnaWwEbbZ2xWr0ZQ8Dmu4hG1BgiAOkrdOtg9F1wQosjTFsA/pS7CHYECzuU4Ah QyfvP0eS46ITxKOjc8ijQ/H7v4seLULHtMdH9ejwgbhbj/ohFd1MZPVoYZVx3kwM6tF90DF3JQ5r 9cGno4f38Hpv3azqXTxlTQ0fOYofTCrnEOxWjrVYh/cVCwG/MOn3hyR3MlZQ0ay6otLqKjJMsVfv zia/UehFs70rvXQvHpPrRweTo6NKfbxOL9WX6zRVl+p0Her6vQ65Up+emFylj4FmLQZW0cwrWLey OEzVJYhVD3Gqutf82Hlw77f3/AOKHL8GyLtOBIxYHvhzqa281U5c8aRDdKYS6aQj1olcYtyV2p64 IHBl0dwUsAPoBQlc/yd2tbREI7nL6n/MI1vD1m157Cu+tYzGZzw7vls+ctF38qe1kbmY7BR6nmjs 9PbH/AIb1o4Yp0Zp2te3r1EcrdotsdxYj3FoR7BYa/QPlELE42oi6sjSD2bEdGbmxIu12uG+i41z R1QZ4plfSrjH0Wuz3aax355t1EhmA1V6CsaKZiTX2/Ad6wknk+H+w+j4z3Kxlh92UBTzb2CyMr3F ZAZhsgLxw0XSunhRTmBK6MbfEpGkzhNK4gkf8IQPeDmJL5NDeEJ24DqX2/QEnc8JK0HnCzONT5ep CLk4QhaKkCUiegAvoRPjrLcNst60aKTTJDkdc5uAr9CpTjpZwERiK5o2vN+S83cgiBIccThSeCYp JkvWUI4mXJLPgyY+eCCBQQaIfNUab+MPCRMIbjBrbNHG8byMqxj/NdzhIumTDRSb64tJnqgnT5iC J6zByzQeksmQzOMhWTYqVIScGSEDETIZITeKR/U2XeiYTPAZum5UHpvSpivd0tw83BZ2ptVqM0yF zT7DzBi8geu/YIwb08assWxYdrDIJP0l+LZicCvGukGvGGgaBtYMJsLLelRcZUTTHdf1aPJAnNej rgOJiB5NAEGY3YmilhksRIt7OqlEqUzuOJlIiKJL8MtJ6zKPVngk8rP8Vf4uz/Kr9IdmWC9HkhlF H9en9VmdXdKX9RWdoXRJp3Ws4zYoeH26AqUOsk2qHGr8v83PtivFBV2tbpUyKWRPIMhwbCrI+DuR hQtYQu0yhiqemoM3BVkym8WV/LUCbnlBqMjtg49NQBnVfvFm7bQqu+zF3Y1+r1kW2MH6+XN2Fy7E jn1FUWnX4cZHtSM7LzYWjipBCJpaWhxD51+au9yITMkRqLThGfT0tf0hXGc0kPY95hbUmUhFaEer 0jrBBhJH5yB2rpnpJLsd2hCLawdP4o7pxYMsOY31p3i7lKKaykjwe4cAF3xXG6c2PI/PC+GLwxhT IbaDIK7DIREHJxH7xhIfgLssG3U4lCgGFpEiDC7QIvIjsLC517PkQ7+S35P/gD6xfRz5zMZ5/img /ba98lHfK+h126viZ2GrYpYMVhkC2F1V0G3fJyHaVNAI396Nh8UPPQv+fwygyKJ13I6z0+wsu8yu sBz7wGHCpOm4ChFnKDpUC2QPSg/ns/WNKezpaitdh2or408eu+GIjtxQ2JGnjk18SDk21ygWDmVz DUvg0MRvqRBToliqgyndl+6Ht30FdZhs3RCAqAdFPClXmk51poUUl3aLHSoVQSEVyTboBazQ8zol FYUZaHx2v0oFLdA0A8jWC2QDYb8JqENDE6b7LH2WuyBccF3wvCifDZzt5KcmIQhB+DFtnZK7GobD B3/6DXsVrzQJEC0BPjs4LhHX0kalp8cf5zhfhwdjEpSDptYvnTp3d/HuhZMv/emQcWr31cvPXfre MHP9rR9d/+GXS9d+8utLj84PDrx18Y+Nz9/+/cPXpyF0bD5qHGA+AKxpVJWOt7Cm95uYVUtCBn8I HIaSEPAGKZXRvYSDvapMzBmQ6822XyO8q2IQOYmxY7qyHtbFhT4AbvXjyAH2ozvl6pnkrBphYYqw MIUAncCw4Nw2COESSc43iXZtTboNxJoniG1T6y2qtPnluxiIJQFjMoC7gtDfB7sjuPUSjvSqTQ3g 8Ka+MMPErKlwVhfn0igUdMFm7Hg3eAP4SQ9ITWZETcYE8lxvkuedLEb1JaEfo7UqjUjPSK+62Ss5 1J8b6K/lnsk9734+9wK/4F7Ivcxfs97nH9mchf6J8mTldIU1+1GeZ7p0jxdsVfBK3AvmSktQWmxM i1J7aE+2i2G7pR6Ed0Jb8Z6CAVepqAjLAj0tLAnXBUb4l0p7V9FJM6yq47HZGL0UQ1RMiq3E1mLr MUtsuu+jWivM7JQIK85v4ECzAbc17/ZXpRYjMi4J+x+CaDVvWJ18qpJ2pAspw1pSUd4JTdnWo6Ki vVulqC3oAlHOzU9Rc1MAQSZV9mGng3FoJTjU2gamLPc+DkiWJmGCBTJaRodGofTwG2OvPTv349l3 DvR0lfzVWkMN9mpen5SIBlKoYnN9/9DMriefNScK+SRTnf/bwnOnX/7Lxs8XfeKOxv3j5WgqhWR7 cYb55mQh4FpsvHMm0Tdx8Du3/jx3MODBScsJgH4fsNyF3m0huStDkMwpfrdGLIQWUFArcG3PJ0rb fSht36BgzLgxkBUSnxRiNBSSS8iJSGICcvA3AO4AlQY4u8a0M9qixmhd1oCDAUjdwTlkA1LI17yD 9PHttl9os3ACL5eGa8/YFm20DRYIcLBTAmc3yRl4j/8hcFZwbsPEjDvv4zlFyeiPJR/Wp/IDd+5M bSl92DwDJlss0SXRpE3xMms1M+hEBikYi8TVX0lomjqYjmp7KMGecXeoEmIDSzZkq0oO5JhkGMoK vv0Eh0wOcd1KBmUod1JRFBUtqcsqTakS+Pg1dV21qNP6L39AyHjLic/fm5vHeNwpbcxvTLmbjrtK tWEJTmQeVBjozYclGAguEW9745bqtq10S3fR6AsLvfsrycRRn8e3o+B17t7VyO6LBwWLMxFSNAH5 mOuffjqU03r2dujHGyOjGkhsUiau91tvP9GJZRbwMrN5j/4r4KXIVlp40coEL2UTayiNAvj5owB+ 3kgMh3jNgce1mLi6+XciuCKmuxKeF4tWXhNjrCdrQQsWdNqCLKk8QihjDf6P72qNjeMqo3Nn9jGP 3Z3X7noeu+vZl2ftHe8mXm/MRFU9gThPQoJAJC4sdhsqEV6yDaWVmsD2Bw0RVWNIJHANbBUJKQiJ poY421ZunMqCotQkEmkoP0IRiqIgZdtSmQgROeG7d+yQ/iHyvd83M3fvvZk59zvnPJlBBzMoU7QM NG5MGLShCNTwUqMBTFWFCKEBJW8YQwTYefnKsnTFr3f30TGQFW020JfMKJUg3bcx7E+jK7uD6KvB p4N0sNgX3ppBX8p8K0NnioqA8A4/9AyMFlGsDRhsjGhNW8HBtmsDa3VtyY9LwHSNBm7S0lJjWFpS XHgAm8LQ6eUc3aEVpeIJrlMSXC0+GnmkZ1Y6WQjyYb7E947XJmrNWkistZHlHYUSeTF6MbZUWCr+ OX+18BfnRuBG/kbhH46gDDsN5xv9R5zj6Dh9nGkmmkbTbKaO9R+vREUk0jzDRUIp3nkz94c8m2KS cSWVTOu9pjPDzfCz1on8iYKglKMlZ5eztzZWe6r3KefZ2On8S7WbzI1UpJfdmKEW6AzqRlVEozYq z1ELlTYyPLlPy+gLZsboNpBkWPDm8EN9IYkf5hSlkI8KAdEmIZhBv6cq1b6NFIVfqvEdXdfazDYv nqziF0u/pSCkXMq+m30/y2TbTNwTJkQ0Lk6I0yIjttEmT7cNvdLNItZp2WjcnrCbNmPZG2zafhVZ 1ACyXt69fjj2dKZWiIRdbXziwNy9LGqMulVg/7l7CFKo4J3r8ByICYvb61Jnzat2uaAdeFDThagQ j0aFo7FKOXZEWhrVKOnWSqcxhaTOSsfPSeqD6LcVi4sOUuVRUv5Tpd5uS5JD4W4Z7G2ol03BEc6k qHApmEJ+6X/mGayQYS3uTvi2dFu+Uwo0RsH4wlGFm3oLtegW0xJeiE4npo1pczo1k/txvtUfARFT RpMU6BwYJlTz1cIPnNnCrBNsjGJpI5cs3eVKuos83qWhmSD05njXwHpP590K3HJI49yIlFGGYxbu gOjnTJcE3S20792cU928HyIQ5lXX0VR/LsWfS1RgCQWWUFzHUvBvPvBEEYaJLiNFYZ0onuADT4nC OlEYA02TSaPK/+8fvJtRUq7kPK5HoMC6kl1dft0iXJeXa5j7gPp6CkSoYb7EboKezvY8+YVtn7O6 x350ceGJz34tm+iKZrOpnz82sv/Ru3/t7599etOemiwpEealu2+e+Mqu/o+VeivbD546MpPhDbT9 uec/7Y58cXqzu3/yJ11iTIMaFr/3T/qhwAXKRKtrNayY9hSoYWkPFyghomH2iiRUFFRJqhIiU9v3 /k0IT8XMRyQdfhcR/BtVYB0xGQ+0kTlHoRAw2erl5WpnaY3DroEmq360PuldxOUmSZ94IIfvcZO4 U2M90SHx4jibEJAgmihxKI52xhFZzgMowtqCiYJEwgWJ5Q0SFgzCBt8jU+CdEv6D5D/niOBT06kH LO/lZazcVy83GovSsrTU8K1uuQyf1XyFisIGtkTcMTRG08PpGXlGP584n2zrN/VwK42OGWhvZG90 LDIW/ZcGfjGh2RqTTGi6wSDcxc0XEZPYsLZbZgNNo1CkjjedvJR4N/F+gkk8HjffooQ2uuU5FpBn pZo+k6bTFEKBQLAQ36eipoooVVLPqIvqZfVvakgdT/3q2LqAWyVWVmqsgHboQJ0Ac7t6HVOn1IFH 1xHQJwVNgdoMkowosynsXuVaIg9SDMOshh1CT09dztc3AW8OoV1Xr9ZK2YdlO9/cWjnQ98Ohb/Z3 9QYu3P3TttVfjz7cW3rsYG3sIP3lbPLQjp7HMTPS4EBXmZNUkd6whqqk7WH0QGHDYEGCVcKX1n09 ZGXWfMB1TyXy3yADDSWFxynrcFPWHQMkK2fxQKWwbhBiWjEkWDEtlHZiQpiFM3wWGwSWp6rXysvw RUE0DEudWz4Ol8skLF4rP6ij9oc9dpydYBmWFyxBixWKXTCrP6WAWAwfxGPsIAIqZBkBfGUQiWXw +J6hsGyPRZBnhYh9sHpgtx8S7ClYH+JHOCHYUxS7Zw17Mu6hk5bhgnSLGIjDAEIixEAPLmNGrSN7 HGjSsjE/nLEDg8JQ92ZrR/cOK2iw6l7sD7J7M0U7z9poSzjDbrWEYpptoxFP5aliESgJ/39ivMAL QtbCxiBGnUFIRBOohS6hAGrTC15R0Y2CouxTp1W6Cd0ZlcGgs9ZgB6DreeO7H9VpQEUAP0AfhfE2 7AOxg3d+X6kBdUhmSpRTopGiJNmU0imqjKSHgC2oBmoQIMaJ8O8K5uvrOATdFq5n19AJV3adOShm k9127O57/d8+PLJn0kkN7UBbRofLX9/tPsKcXH27tT0l5yffaH589LkmmtkyYKLi6mxz36ZP0uFP DdFFwKgMGO0ARi36go/ReY6jDCUUfx3wJEOzoNHM31+moIR1OrduDVeBEarwAdawslHjOZPluFwW fifEk/j7xtWQ3EfkthKiyR043xZJLDzPcvl/f4rvFK8tg2/En5VTPsMf0D6vM1Dj3pkT6jnMQo8m 6nE9buS5HJ+VLaWgWbplbOZcfrPianV9s7GL3clt5Ue0EX2ncYj9KTvD/cx4wWzlfkmdZn/BndJP GafN19mz3Dw/r53TXzVeMxdzb2u3+dvaHaO/xSG8ym8GxgdJLG/0Y6bXj9u3+9G2/ZjP+1GWSfQ8 PTUo5g5TU2iKnggetp4Jfk8+nuM2s4P8oOaavwstZt8xwt/nj2lHdWZI2aHRqhbPqJRpZSiFlzNw Cp71HM7QLU3XN3B8nON40zAKHAsZGw4FAwEWJJmqgGyiQoYuaG0E9DTGI4kv8C1+nr/CB/kjnIlB LHmh6ovsK+wf4fQe4fQnjNeQSVkUB/sVlUEO71tPkzg3UMfhXKROcYtgl9ro/LyUQ82c/zZgFI7z ojqYxYVVl8rlyamVBq4Xxqp2QwfMaytGB8cpreNbE4J1XF2P+nLqaLCikaQMuqqDpMUHe2AUUO2T 64qAQL+MpkDfnOWtZHT4v3RXW2wcVxmeM7vruex658zeZmbXe8vu3DyzM87e7LGMdlDTNCF1Y6om kKBVKrWBBCG1jghJKixbQtTOA7IEbal4ScVDLYSgSRxywapwJSPlJZCXRjRSVR7c0ooYTBRQJGKH /8zabQp0Vuf85/xz25kz3/d/H5DXx1cgclXQy2AWQKXwEHw+6bElkCnQUK8iETFx6FCynO4JiWQS VIMOsqJVTveBA0IVpGm6povorQHdTL97S2KjO5rIaqYqA5tL5ua1jFEU66FXVK1UGdrso/tH8nFO iKpqWCzsfvC3UKTtYo4FtPQ/XI1cArTYoRtbaNHKBTFO21cJ81KcJrNhQy32CX3kM+90XFfy8MZN 2JYfwcw1SoPquYvwnjwQWIqgB58EAGF7vaxxYcoILn7GRjZ1UkVq9KSBjGjv6rZdK5edGoEOcCW5 V6fb6eL3u8HNxMB1BG81dyHhkI90oNPK6GAwRVUvOUec49yLzifqJ8Z99b4RIwdcTLaC467nis2y 45jPt/OKUsxVsBPmtbxma552QFqQFuQFjY2qw9VhfT/1JBpn9rJPVHfr48a4OcfM4BnxR+qcMWfO OD/Dr5CD1SV8Tb1m/M65rl433lPfM246RSoSZvrSYYlTGZ0z+syW9Bh+TJyIPM0clJ82z0bn8Zx8 VjlbmVPntBlHmuVelma1UD93CJ3Cp8QwYAJWU1V5xAAqsCQWcKlSLpQo0y5QAh8vCEWlUCgCqBZZ Q4diOuX7slotsQzLMVXTSJmmAV+Dqg+xXIplOVAnSrrKqymeVyvV6pCspGRZMbWKIks84I+HdVhC dwBEBXRnsYgEkcwwFQdtAlUQ42KxVKJokkSUDYcASOUl9G1KpVj0pi8YPvzZatWIlh4IR3nwVBcu LVNHzcpVxPppP+dOKOgNBb2t/FH5AFjvx1UX4J27UhJUhGHRCRSjsaa6hDClUWlAeMzn3SMa8rUZ jdZAIF3ipnSX/S3AnAU5xZcoA80Y6wZtkNoPpxpvMIQYchMmmjERZWKzZPrmeXPZvGky5rO1T1XT 2j2rO6lk1zZWwfRMbmEbUllIwG55NQtSijQCdgL1LNFTnTEisca2fr3xWs9nAfp7LBAHFmC36YB9 NGP9P2L4357B7Bg7FhDGJOoCU5wgFqJrEa7QcCrWIcZkEWKS8ETekx4JKRLWL0qeSkI6mF1I96iD bD3m6OsRh054okcb20SyNUeVUI9H+tEMlOGV3zdlPTOGLu0ppNib76R0D5W/Zm7+wfxw85/q5u38 yBjwSbgwULQ3/oF+NTsmxUOqGpJwJZXeuIv+3S4lC7Sq9h9/8Fd678aVEL230U80Y46iQn8BhhkJ 3d3SjDGNl5tauEbBpVzgmUu1JKZHYHCZqhXEHtG4LmGZ5aALDC4hG3828TiP5vvn4/PirDbbvBW9 Jd3Wbzc4wdF4NVqNneBPRj+qMwOjjnC4HXY6kQ7uiCNax/CaQ6N7o/vxfnF3Ya/2pLGv6Y8eVA6q E6MnmenoNJ4WpzPT0qvMOXxOXJCXtEI8ImBBFOwiLopF2+RNyR3l8egB7nB7YjS8pRSq8L/PjKAR 8iDfc5HraE2ZD1MOeYaCk897jjPqbROa63Y65EkCRlvu9eSZfq4BNqVMRm82W3w0FmuA/GAYRWu2 mo2WmpjPuCISWyBLM7H8lDJRQAVXfaEyXaEr8xVUUVTH8Rq1u6apNybgbU+1UCsSYVSFYaotNdVq qbGMrg81YqlGIwYrL3MxqaGrSnTE1WQ+FGsyLWEADRRhJVyHLAMUcFEkVdkJ11CtVijk+RhIzN+8 kEEZR72K4oslBSmEV2O45SvnlT8r60qYJEg1VpboNtWgGPStiy1HBz5YpBqosUS/Q3nUKD2+WL4B 0LT+1V27t4Y3rK41uQZ+poe97na1BakZdHisS4RUYGwI9OKONRuf6gGNDJCc8KZc+Q5e7ZJ3vBq8 6ITXdbuQwcEUf/8OjBgWj8XHZuN4bGplhYQVdoWBwEL2ECDwRLdLSvUkNQngu0ZFAVO8FwVrcoXz pFIh0YHxx4sQ08SkcgNip9/P4Y5MsjAh0U9K8U7ET0Q7jAxdm4xGiRSBaBoCudr6ZcFTSwIp+H+6 KHgMAbLg1SFc7ocd/UHGFxKeViJNhJxIzgPJGIiEi4leEHuSIdfvYXgBIjTJT3gYC54IzfbTXrLH CpleSJBSmPayMPOTaa/Npj1jKOWZ0EQ243HBxTKe6YvQ0l6dNLizRO4OjZx+QfyMWz6/Uf81R5/b EdBQoF8ykjRMiGdbvzDJTEZKl1t1ktV1Qk3BnNjSYaJzcugts1yJZr68b88ODbV3VncemFp9Zo+3 OVFTkv7LP9lVq22+W81ph5d//ZWvfgmIaUCS63jHsWPPZdN5oCV5x4mFzatndoaq1VRckrorK98Q ZZ2uViOp/KmHD74zDFiJbe4O3QNmqtM7tpgJ1Kk1GKJO60jPg2OQiRFNEWISg6FIhnQwpMmwHgzr V7fNhLVm3YFfx73R3aasLaYocBaVT4n0S3VUpxJAD5WXyD2EVKpBUc3Gp6Ln/e4K+MKAG4i/2jl0 Hu975utvU7mH9ynl4TqVBaLn8Qhsh3L+LzkMn1fcetWkk00n83z7B5Ef9tEcF0mwCpvlrFRW46qJ alazRlA70co9kTjGHeOPK9/MPpc7Zp9mz/BnlFPZ7+ZO22f5s8rr1OvcT7OvWUvUzeaHfRXQJJZl Dw7yKFDqCpH3dn1L3mtsSclmhwb5FBxgW1Yg7K1BOGUwy4V51oaogNJgK1sSXyeEEYd/q7sVLy80 JSmrELWQm+fRB/w6Tz/Lv8j/nQ/xUx1uP3eEC3FTYGzjft66JZSQUDpXokvzR2zk2h2btpVG8xfl N8GlWk+BUh9f7U6ubtzr3oNKuvHU40d3fUR1xjdWrR6dkIUI6IN9pHJDJNTyhYX6s+KMJgk1WF8k xQMtHtjZVrPdqEuBkx1GWlB0Y+g/7FdbTFxFGP7OZbnvni2w7EILnS235bYsVMCtSCEFCuW2haU3 e2EtZ2HtwuLuUqx3H6pN9cEYH4yJITbRFI2XRsWqiTGmT40mPLRNHzRNbBP7oIkxtDG1gP+cPaWa ELFp1ETPnHwz3/wz8883Z/+Z2fO2rarKeenrNckpGyqE8mKXIzV38fn697bf193gcXpdaQVbi1oW P1acuVb7Rorh0vzStsVa4UaZKzM13Ux/1h1Oy+ab40ePtVaWb8xRmnZPix+sdxdmWDMoesvoXg1T 9NqEmebqzBTZIU/L0+Zpy4x8Wk6etgtm+6S5pt6HXYrPJq2V7ZYsZb/cr1yS55RkPSpdgmTPkRTR YsroMgmPmQSfacgkmjwZSa2KEFeEA0pEERWPmIbNC3RIahk/kRNfuF76tMV1q7XFVoD000JRc63J 9GFaQbpsUZQiSc6WJFlKF2VFyLDYzXwW2WcSTB5zRpL1gCIoHkFMUz4Tm2CBLDY1V0qCe5qW5faZ BY+52Txhlsx51fbN9j67ZM9wp9dBFMTcHPvriSukd/7hnvkrvdZ91ykA5vddsdJD98hCtFHLbmnk Mgn07fbcE2ccgvVH+pt7TS+0ox/RCvpI0859y9Jccyqd8pKHMpkHrJmI0sxrRTle5fTSN7M5XtmV zenF2WyvPJHJ6YuzmV7ZYeP06qyNqKLRU8ofD006EXcLkrNOcG7gUVPY4LQJzlp+4El7029eFIcW zwUas9bKriQJC68KvaEuuzVdyF38vkgqzy2s3bZYfPNcYSUbwXI6vDrEtyhK3CvgK0AuITyZgOl9 IOllIGX4NlJ/AtIfAjKGAEscUG4A1uMrIysM2OaBXAeQ9xKwTgbyLwDrn03A+QWw4TugqD6B4m6g 9CRQRrbyRaDyF8D9NFDD6DjMA+omgIZHAC/Nef/cX0PLWaDVArSTls4moKcA6DsB+DcBO2kde1gC +0nvUBBQPcDoK8Ah0jo2lwBNi/gZYIo0HPkcePwH4Jle4OhV4NibwPETBgwYMGDAgAEDBgwYMGDA gAEDBgwYMGDAgAED/z4gQgBP2ZA4E/IISVg1SVqemsZzxboGWdk2wJGbt3ZdvtZSWFRcUuoqQ0Vl Fao9NbUb76mrb7jXu2nZQWtb+9aOzm1d3ejt823vH8Dgjp27du95YO++1Sf/J5KMCcodsNJSU8BQ CjdqsQnt2IadCFHro0tL1IOhBJXwoA7N6EA3AjiE6NLS0uWVHv1dr5ykVTUp+HS53+LymGRcpNot z08JF3QuwSEO6lwmPqbzJOJHdZ6MsPga/+XlVO5TStW5AI+crHMRFrlB5xLZ23QuE5/UeRLxN3RO euTznCvcf9D0Dvw4Qu9LRZDezkEqGWYIfoxqvAcRjBPiei+GLVSLEud5gOwhrQcjS5jGu4m1avbA XXqqXlbGMEAtYUwu94mRrZPKxHw18NLjQZXOajVrC40IU9lPY0ZIQ1wb1U/+YoQoDlM+THOEMKbZ GHqpnNL6RMgWIP/vavq5umFq47YoRRCj9uBdrIyRVSVNIZo1rmnhShjVeZ+47nWQVs3g08bzOObz 9VDeR3MHtRVyhXycSl5jmvZR3Zvbf2RCDQYOqmyG+UdV1hMZj8TJxLZEohORaCAeioyzifBBN2sN xAOrdKrmzthAJDzJLTHWOU7jarxeTxVltW7WEg6z/tDIaDzG+tWYGj2sDrf3dXS3tFf4Q2NqrFed 6o+MBcZ9Az3+O7VrBkYWpplOMn80MKyOBaKHWCT4p6JZVB0JxeJqVB1moXEWp66DA8wXiLMS5u9h fcGgmwXGh5kajqlTo9TN/T/fCO0UWPyIbCFW8bttkdgUt7eEjzT0UHu/FsKT5Jlvijsd/Xf3/49u a/qtE6vkkTBJrbzWTbWtdO0lVsN1h2g1KkXfpNaSUNVBvI08htClzZ9QkNBUor+dB+ldRWgWSnQD JR3Hz2ik8EimW8ZKYbgDMJ1Vsuj2SPwvofst7Dr17QGl8VpKbop2ZZ24nP8lLz85/5Hr1/jCC1ak WKjK7yztTvtNgAEA6fbjpgoNCmVuZHN0cmVhbQ1lbmRvYmoNMjA2IDAgb2JqPDwvU3RlbVYgODIv Rm9udE5hbWUvRk9ITEFGK1RpbWVzTmV3Um9tYW5QU01UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250 RmlsZTIgMjA1IDAgUi9Gb250V2VpZ2h0IDQwMC9GbGFncyAzNC9EZXNjZW50IC0yMTYvRm9udEJC b3hbLTU2OCAtMzA3IDIwMDAgMTAwN10vQXNjZW50IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBS b21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFs aWNBbmdsZSAwPj4NZW5kb2JqDTIwNyAwIG9iajw8L1N0ZW1WIDg4L0ZvbnROYW1lL0FyaWFsTVQv Rm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDMyL0Rlc2NlbnQgLTIxMS9G b250QkJveFstNjY1IC0zMjUgMjAwMCAxMDA2XS9Bc2NlbnQgOTA1L0ZvbnRGYW1pbHkoQXJpYWwp L0NhcEhlaWdodCA3MTgvWEhlaWdodCA1MTUvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmds ZSAwPj4NZW5kb2JqDTIwOCAwIG9iajw8L1N0ZW1WIDEzNi9Gb250TmFtZS9UaW1lc05ld1JvbWFu UFMtQm9sZE1UL0ZvbnRTdHJldGNoL05vcm1hbC9Gb250V2VpZ2h0IDcwMC9GbGFncyAzNC9EZXNj ZW50IC0yMTYvRm9udEJCb3hbLTU1OCAtMzA3IDIwMDAgMTAyNl0vQXNjZW50IDg5MS9Gb250RmFt aWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVpZ2h0IC01NDYvVHlwZS9Gb250 RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTIwOSAwIG9iajw8L1N0ZW1WIDExNi44 NjcvRm9udE5hbWUvVGltZXNOZXdSb21hblBTLUJvbGRJdGFsaWNNVC9Gb250U3RyZXRjaC9Ob3Jt YWwvRm9udFdlaWdodCA3MDAvRmxhZ3MgOTgvRGVzY2VudCAtMjE2L0ZvbnRCQm94Wy01NDcgLTMw NyAxMjA2IDEwMzJdL0FzY2VudCA4OTEvRm9udEZhbWlseShUaW1lcyBOZXcgUm9tYW4pL0NhcEhl aWdodCA2NTYvWEhlaWdodCAtNTMxL1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgLTE1 Pj4NZW5kb2JqDTIxMCAwIG9iajw8L1N0ZW1WIDcxLjc0Mi9Gb250TmFtZS9UaW1lc05ld1JvbWFu UFMtSXRhbGljTVQvRm9udFN0cmV0Y2gvTm9ybWFsL0ZvbnRXZWlnaHQgNDAwL0ZsYWdzIDk4L0Rl c2NlbnQgLTIxNi9Gb250QkJveFstNDk4IC0zMDcgMTEyMCAxMDIzXS9Bc2NlbnQgODkxL0ZvbnRG YW1pbHkoVGltZXMgTmV3IFJvbWFuKS9DYXBIZWlnaHQgNjU2L1hIZWlnaHQgLTU0Ni9UeXBlL0Zv bnREZXNjcmlwdG9yL0l0YWxpY0FuZ2xlIC0xNT4+DWVuZG9iag0yMTEgMCBvYmo8PC9MZW5ndGgg Njk5Mi9GaWx0ZXIvRmxhdGVEZWNvZGUvTGVuZ3RoMSAxMTA0MD4+c3RyZWFtDQpIidxXCVRTZxZ+ WYFEtiao41D9gaICSXgBg7JZQwj4HAiYhIjWOibhQZ5mI++xFRUSFUGrpYq4UlFbUZG6FJfpmTp4 dFyoUNwqOm4j41TrUq1bFdD5H1RBW2fOmXNmzpx57/znvXv/797/+/97b+4LwkAQZABSirCQcYka LPliUctkqDmOIEJhmiY8Yt796w74fgXqdMZ8CoQe6pyPIH5jEITDzrbnWB6ih3IRZEgclL1zzEXZ W+c3HECQYBq/y4Trs/7cMBVHkNDrUI4yQYW3mOVEkGEpUH7HZKEKC9KxsVC2Iwizy2wz6gfHDYa+ hlchCMNl0RfamSxOHbQ/CvHAqrfg/MIZExBk5GCI/9zuwO1zvA9A/4FmBGFBHgij56afiKAbPoVI zyV4iLoE97geoWXjyx57MtyYtS7BVai6xGQwpF7oAK577wyTw0HQ6VxeGJfBZrhGMxnsWjWajor6 afw3DC31R+J67jTEgJCIDTEjOELBMZa+UfCqP7bP0voF11p4XcviziXXP4uTH6p1eb+LuphNcIQw hYKKxhMLr9cd+kp2ZM3i8uZhzRrdx6jnS64MNqTk/EQ6DH2by8pg8wQDdbiD0BA5VqB15JEUUOFU gc0xUzoI9aMBfIHXC4AIYFajRCpCQ3sngvosCQsONJTeYiesOUCDO/IJIw7UNhslHYVG9KLDVGkg BZMnYCmYdjKQKxTKdK0yUQRGGkOiR4NX10CHDvKMHo3KpBHoaBReU6AYLY2IlP4s/u9vwLmu/5kz OAjLuRieewXT6UROScBd0yyRWOL038ndVcff6+s56bymPa/jWGTortOPPN4bdf9G5TOPAW1/+e2U P7R896h8Z03TguCbszN9yBmFX+f6dR/OfBRSnzmtmt0tNvhmOv2bc6vOBGaGnzku5MyL+rJqa2Pq hBt3YgMbdKvmBKw1lzVNSF4xo3FT1JkuD/Gpxug1TBZM6tdSggV5xfiunc8Ze/JGaWfxmS0PthV1 cbqWx+cGbQkbeflDAV7xTLSA8dGU1YZm37rSB3v3C/ee0K2a6W5QHt7w2XlZCSfwkkPMLuPUzfIY uEyouPt4YOq3bkvW+Jgzn/FkK5or1l1m29eGztYvOXCdn7t685FsQ0L88qrAiJWBFQufZrm/8/Dk U5i/LXBEMf2Qr3xXn1fcDuhMypxX0ZxUXhl8Rzj9/y+Jt0lHoMG9jof+cxovdsp/407/LYovzof3 i/PxRb3pCTeBO2alcIcVp1BnzS9SehGMwgI6pev1txsbFlcmV15o9J1GXOCVGCq50pbW5+UfJ53F YqpunOa+W9OwoXDKrSddRmXaPr4V/WFDVL3Y4/I924h6z4nTObK0klZtWtteUUI7v23xvmnP95S2 dVQ3lgRiCT7mUyt3MHQbD34jWRfzoGRz5qazgfi1D+sL1/7xXHKC6T3x7O7dTAbrVxLaMr1z1e8/ Jb44VWwPMwQNTQQTtwf5HaGYT7AfRwyZuq0sV+Ye9uijS1d2V19fVPe7DvLoeI+aHecXnfdb2sy6 5hGs436n+jT5sxOTkk6P0T0MaDk4PFYcHNG65uqfxiV/325Jzr/WhG70Lm0taY+dU/tkeag0zO/p UeHtiztuZMjtSWLRHNTlsQkO71oWk8Fk+hRlV1vn7mjbw3jLWtPUiOf2Z8yECa3/lVN/c4QiUWlv wENfZoTCZrHgDiOhNwONLZsq0DtwkJ5nMBOkCXeQQCHvSckx6ChpFIq+TElajIiURcuip6Auxvv/ cRLSJDSx1yi+oKBAkg8NSWgoMdos4bAD20iCsjmKwhXpGnoNm8MuAYYioMazJSI6ryUp2kQ6l6Ok Y9G4Xj+yRCKHoOCCWCJQmPUkCSKBGKQSRoeNhBT6eOj0ZiJLTxE2K8iPkPJRD9qeK2BmaKQC1JcW 3AW8SXrSBEuPslmlPqhX71G4qfEsi82aJR2K+tMaltCvz70CcrQ5ety+mOe/YR4eMHi9ilwMTwTq 3ZkuBgNprDw5fHPW32/6HXxuKZan8Z7YQnNbJYM1myKirpw2/VXWjb3VXt2Ff6MRgv3sYx88PGa3 VN06/sX2UHR1ROasPVtmBuesarpa8D3n2g8d1Y8b+L/Z9HncPPvVn2xT02bbvNXKhX5n8QuxgNMR v968IsaLHyy4HfA1WBL9gWEu51jQkC51zbaalOqzcarMeFfxHQ+ZbrepKUG5IVa6sbN9eWfGEdHm jQdD0lofLLvLGlZ8zy9my09b0+dyLIa7iwTlY851+HuRB7jjvhx58GbL0twj+7N3rdcGfsvPmfXT gqKKbdm8rROfdjsCusreP/xggtetTH1QatvOmKwrgk+mHZ1vSRm4Pd4NFvJGF+ci6uKc64nO2wI2 E0VQPv3qzWazmJxa1FlOSwy2sxSdU+pTXP23E4pu08r7Y45bY3/ku9Yb/wuF5OIwG+FXIRpAM2Ez GM/Zg1AhSn/59X3ZDWQx3UoRGG0I4bG5KCTPHYe62FH9MDza1MUOguphtSGlI0wUZSdjwsP/RWGs d7H2OV2sRq2JIIERd1BENmHUUzggegqGTjacpKvGgWfjDtxqxEVAb80CBEWCPBLCSEBSDsJImYt4 ZJ5hBm6kAGUTAcqEg75DeOmXrpd0h95I0Q0RtiYKt+BWCoyETEJ4kCZJA6QSFC6SryfMeoOZZvKq t74NAD0Vw3vTRmNp1kqxBbqBOABXEDvw3DycpMhxr+JsDh6EvgC+GlMRiJBFR8Iw6mGHlOfjUJFq y7NSeshKR+AFIhhCED0KHRXJy9DIIc5e5CByTBTdJKXR0VGvuQNAbjYDNY0g4Q8RCXsyniUBCqVa K8dUvElytVqu0mJKDUjENIoUOZaqTARyVWK/PpyCpWKwDUt4NFqFqZJjgHa8EmRolCAtCb5imh53 WBKmkGuVAIoarRpTaFMmA01GwgSlQgu0abQJT6dUY/CPlaofHktTgXS1XKHFFEpoBx2kKlVaSJte AtNoMuB6/2C+ysOiOLL4q6ruGRxUFMQDjLYiAmrYwQMPlMgxHHLKCIqoy3CKAqNcAQEzjugCKodn gijiuQSjkARFE0XIirri6opxDVETUcFl1Y8k3obpvEEBl939vv1rv+03PTNVXa/q/X7vqGrBKXCe h18A2iLrMlLZhUDw9PH39nxrs2KBf4BCqRR6UCEJvi7ega76WXp6ZWi3jyLAxQObXSj9AgQ3z3m+ enU3/O8k+DuhjS6B3k4Bgn9ggL+fUjGhc5H5nt7egq/fPJmzopMkb0Wngoufr1IxNxCN93TynoAq vp7zPIPe6nQZ64eoAgRXJx8nd4XSVlAqFDI9Tv1+oZ/DVYGjvJXItIsacz8eXaaO6h2L0TGJWBYi I4R4dbw+rKJiIiOUbxLBKQkzIywZE0gWmYr6ncGdoopNjhQSl6owDuLVSUJYpBCuxkcRnZOoEgVV eHhywpsMjFInxHXmjCzlzXaDIzBS9RZ4OtnK9tlrJv83ad7VH6uOVttGx0TJ1xzVVxKBW3NIrpFr JIah6z3I+hcKIiUEO6wlBlhVeB4r6ODh/3F+JEke1j2SyoPkpoN71UM5HlaI2ayuTqvETmZjenbi 7poixMaowmyF2CTMhX8+XULnJR/8TqUz5wzkEqx2+Ol17tGf1LZ5700LbEpatMGy7qDQHlv9Rbpb +u6SVSdXSjxMjSMbFtu8mOuQs7LyyaBpqU35Rww19gWLPXachWkyZc3sqWKuiVUcuE9+7uFtm/Bz fePqDlf16Py/bi65u/VRqwgX6h4nDP+umMUfqw1Pn5jq6rB7Xe7rrPVTrW1bD06b6njy11+0FnZa bjTW4BEIXZ78P9g//s1hsK/E4A0plOdhz5rD8mHdLPVhdu9uLByeMXpahna9th35yB5Fzs6YG8D/ IXFig09F9cW2Z4fjz/U7Jvd/Z3hfO2f57D1DNYNBCWkQB2GghlgQIAp/4yGpdIxmtD6a3gZTXNeh pjOakhKSI5PSVkT+rteRhtMSWHjO5Nyy1l05qh9PjnhUUCGrKjZ3fFjqNMQtKrI+7/za49rFzvm5 DwsuzfpxzrrPVw07+lPxYfYq+HRx3N2kK81NLj9FWNekvvRbtmXIcZ9+l+7lhm1a/tmAXaOXSn8Y NCwtZ0zwI6usMIthqcmUm1biNdus5m+KIEdr36HS98Kt4heO2/b3Ra/Sd32ZMCKz7NAz5cCdT1s2 ahtzSmpHrTJqbrsdsyB0UpEXPe3x6cf7s9c/cLit89t5tbXpXHPsuGunQr+qX3qtyEplfT6zUXWv MOiyaayxZ+g9EueZaPLJrlCTOwcsGlfVpwvVJqsODhUhJaehpfDOxeC8Zu3MC/mHsnUXT6bfn3Rj vHWpllzBU11Djy8kdlpyCrtO6INsTfX//fsrNYVTA4uaXB6Neu22ICvnz27ZBZaPB4X2CtRg+dB3 49SwuyElGKbdT3g7I/2rh50c3zXkdlMmTV74L2HaVljQ79peWeXqLeJzk21GXr2Dao1Gkb46LiRu inN6ynf3b6x4aTrQqzD4ekNmrRjt55j4NONm1BTp8kjFoP7m8JH46lRRmU1xSktVmnhkZub3i7Y9 eaxJLBlY1scsc8OFUVkT1wyqvXxfyGpqm5gdknbnhmhetrXQUZsbYrn51r6ncmPn0tWj/bL6ePx6 0n6nw9efNvq2bCxP1Bc1wl0iBcAD8EX8JGxavvlleyCKGvdlPE8okUooL4Vel486Xg2z24V2kd+o cyOTDAxJnab7Kb8Y7HhvGIn3cLYVzAHEO2/ve7pg8RG/HCx0y8SbVkY4+Mu395tLBZawBGxgDtRB O5wm48AfzohXIBwW0A/hfezPh+NwBm6DK0QABTOSAYJYDBthLKyFPTCdMxOrwBseGBjBYBgDM4ga JGAK0bCb3ARP8MI5HMAdciABv+di/3MyDZ8QkMFiXH0r7ITT8Bf4AYbhjLZwHV3/XPwKXLCihEM6 nIDbvDO/AUygEA5BGdTCfWJL9pM29lisEhvEf6CWDdiBPYRg9QmDzVCK4w7BRWrB9olmYrr4R/E8 DEfryxF1LZzFtZ4RgQSRcHqQpeleifFiOfLQF21G61GcEI0vJMEBHHkdXpM+KFoq0A9ouG6gOASk MBIr3Hi0LxAr3mrIhk2IoghK4Cg8IB+QpeQSeUz7UQ2t4f2lvlLfPjUd34ru4jNcoy+MQmvnw3JI Rc3NsAW2o2YprvUnlHboIPbEgTgSTxJA8sl6coC8oOPp9/Q168+M2AQWzEJZBmtmLw34Dj/dDt0V 0V9MRS4Jci5DT7ogznmwCFZAInwIGaBB6/JQCpC9cpQK5LMG5Ru4BXdRWuABPMSY4xGjjIxDkaM4 kNlkDgkkvyfRJJHsIMdINTlNzpI28oROpvZ0OvWjATSarqBJtIBW0EpaQ+/RX9DKGUzBEtlHrJzV sfPsKmvigJvDqbgYLpnbylVw33Lt3BNOxwNvgWLLq/g9HXt1XroQcazoIIaJm8QClAfI8QhEMxas EI8/ejUcd5RoRLUCVqKkIXfrENF22I3c6dk7BtXwNUZpHfq3Hq5AE+K7Bc3wHF4iOXp8pmQUeZ/Y Ib+ziDvKQvRTCskgGpJHipDnSlKFcobcRJQ6RBhEg+kSmkIz6Ca6g+6kJ+gZeh09ITIJemIoc2de bD4LYUtYEtvOPmafsN2shFWzM6yeo9wMzp9L4NZyBdxe7ih3jmvkbvJy3oHPRangq/hTfIvEWGIu mSxRSqqlEoM0g1YDHXwB56ASqnrnPskmA0glfEZaGcc0tIEuoIb0OtFyl4kVemAmAT4Pd9uf0cL3 yFU6lcxn4WQh8qclUSQEdrHhbC+bAw18PFEyfxIBSm4H/Mp/Ayo+l37OKJ/LOshLWg5LIY8u7ygT g0l/UJL99CBGTCbMBBvODK7T6dwJYkltaI30CKkGR6mETWczDIywtZ/dRTOVBkakDVTsN/KrLbiJ 6wz/Z3e1u5YvyMLYsoXRikVybFk2NhffVFuyJEMQdmzLUC2QVheL2gzFngTouJSUlqGkIniUyQxk eplmOkyaOJn2yEBHzqTUb+1LnphxO6UPEC7tQymZDKHTFKP+ZyUbO2XaPnamK33nv5//33PZs/sx 7p9buLeGubfxmXCP/FF6Aatb5H+BPiehm1x6Ug7vGjQuStZzl8juxdOLv+d/mPsJqeY+BlgsX/Rx flxxe3Iz3DV4ABef/F24Cde4G7AHnxoJfed8invvG/ik2QuPuVLcT2F8jkx6e3q6v+Tp6uxob9u2 dUtry+bmJnejq6H+uTqnY5O60a7YNtSut9ZUW6oq11WsNZeb1pSVlhQbi2RJNAj41gqNQbUvqlBn lApOdedON5PVGCpiKxRRqqCqb7UPVaK6m7La04ueB7/g6c17epc9iUnxgMfdqARVhX4UUJUs2TcU Qf58QNUUel/n+3VecOpCKQp2O0YoQctYQKEkqgRp3/GxVDAawP4yxUa/6k8a3Y2QMRYjW4wcrVIn M6Sqm+gMVxXszHAgl2JVtEYNBGm1GmAlUN4RjI3SwaFIMGC12zV3IyX+hBqnoPbSNS7dBfx6Gir6 qaSnUcbZ7cA5JdM4n3ota4J41FUyqo7GDkQoH9NYjnIX5g3Qqm/esTwVsXOzP3J2pdXKp4KWcYWJ qdRZhb41FFlptbNW07APjOUcfdFUH6Z+DUcxFFYwG3dGi1ByBlMq7E7YXeXvL6kGmSZ6SKFFaq86 ljoUxbmpSVEYnrLP1tR453I3oSaopEYiqp32WFUtFlifqYDU8NTlaq9SvdribsyYyvMDmylbU2BK SlcyyWWbzunujAsNL48sYRWpz+OKoEpCwUoiKt5TO2uS7ZBKtKMbXhrBKDqKMzJOi/zRlKmT6Vk8 NThMqpL6DHAFqPf/sloTK2hEh+kzYCxbJ8trDe1LPHW5aEMDWyKSH+cUa+zW5W3uxuNZzqdOmhQk OHwwiGMb0zqbcfjtdjbB57JeiKNATw1F8rICcesseJtdGuWizDK/ZFm3h1lOLVmWw6MqruQreH4B rKOyc/m/xlS5NjjWSUnlvzEn8/ZQWA0N7YsowVS0MLahkVVS3t6+bCtwdK0/wlu5AsdZed2Ki/LA sjMTIiVUcOBf1Bf1aFaScVXqGqL0UVN0Z77VjHb7fxmUzX3ConTyNKxQJu10rZa7VsmryitJ8Viw 4ORCI/tSKeNKG7BBk4ufdGO798l7j5vko/owrryuCR/hqcquzwFf7RAzcMdwBWICgEMYhSFxBnaI HbCTPw2daBtBuNH2Otoc6H+kQF/nOnI51O9CfIJoRIQRCiKO0BC7Ed9CDHEd8D7iHMZ6WDyj/HmI MN7wG6gw7IWNSM3CXagRbkOdaIWdwnVQUefE/FsMJTCAvMNwEiqkWhaT+zPKu0UH+vwVa3gZnMKH 0I6xXYYzUIm170Bbu6EeesUDmO82VGI/PxP/RA4h3WUIoA5yDwTg/4B9j2AdU4g+/iEEMfZ5wQU7 +F14f9fBzf0U/EiDaF+HaBF+hPfkgueQZ/W3Ia8hHUefAYx1oX0HjqcPax3kP4X9SJux3/387+A6 +QFcQrqA/luFR7CWfK7n9RCcLYzZjmMFoghzokg2I/0b4pG8F+qluxDC/l9covwWOMjGDk/48cKY TmH8Qczj438OhwpjzLCJ5ZIB7gnXuQ4Zcufx3hXxAs75SXDj2HxFuku+i2M1oOMCxJD2M2B/7Yg2 RFcBnYYrxIgoRnsY5V3iMCQYJBu0YmwT5hphawNtm7FOHYX6dxfq1ynW2Yzj6luKF3dBA8a4eDOE VwCW8RDfNx7id45OySWMOYbx3VwLfged5N7OA/y8OfcGb+ZezFNQkf+OTjGWXIL1vnVg5urw5+Sc MEEqcXd8VW9f0NsevW1mLdc822yzZbmm2bcYaZytrUeyyVt8q8bWUme2eeqYXOXtOlxvuzlTbbuF eK+u1faqp9V2GtGMOI4y86ubqbdN1E18feJ7E2eFNqisxFk2l8veLLn9yz0VRRVFbeks+bW3Q0r/ SkpfltJfk9KjUvrLUrpPSm+X0k1S2iWlHVJ6k1Qhm2WTXCaXyEZZlkVZkDkZ5Ips7qbXxTZ/hWhi RBRYK+i8iWMt2+j4JOCIzOHXHV3Lh7hQuJe2u0JZKTdM21whKg3uj2QImdZQS7lXswRGIlmSY6oz VnZqzwEhuTPnrQWqaSRE5xMQiiv0UVjNEiM+qAxqL6HmEIRGei1QebzH0mPuLu/oCzyjiRZa19PL 4lp5hQanPgQbOcY+vsjRy5LtDYlpw6hN69o006Z1raWWXgiFI3SmVqOtjMnVauSy76r3BHsPiKrB JCJKzx0fs9BTcUXJeK8WXhCc0XhijNFYkl5VkwHqVQNKxnfiGeYTzOxTAxk4ERyJZE54k4FZn9cX VGMBbQ4GSDzTML0q3feX0s1BA4n/a49ZEmddNrCMA9PPyDjNzAMs4zTLOM0yDngH9IzB8XAvCQ1G MjL0anj46PQyV2zEqYpa7VpvpWmyW5+3LrvlFesHApB3oBjP4hJ8rytFMJPb5/YxEy4YZipjr3wF k+WVLrv1A/JOwWRCdbnaC65jri9cL7MLLMHxAANWMpeb507Nmm2tLo2dMxw7gvDrD7cxTlqXd4Mo JVBnEBI8GEVDgue5miJJSBColuvbLa4B00NP/6JnwPTI029a9ECPZ9HD0LLZXm4vd2CDaxseK/z8 Y68B/oEnzrx+yl3nbuCzrxjsc8CTK96yIglqSsXqktIHdtata+CO6R709N9v2UwqRHWjc9vW7Vta K7kbCxffXFh48+IC58vTBf10bP0/+2n/Yz92GeGV5feXb+efYMBW0RqU8ryA/HSBF5H/MVpBKELp Cbxf4AlsIDMFnoMy8tsCz6N+ocALyD8s8CJs4MwjU5PJg7FEUnlXGRlLKv0TRyaOokrxT7w0OfFS 7Oj4xBFl8nCiSQnEjsb+g1Mz60wJTxw+xjT/JLXqWRoIgugjEDgIGP+AsH1IzKU7FDEY5AJ7BC7X y0XPu8AmkdszcJ3/xcrW2sLa2j+QysrS1vhuElNqEZb5ejOzbxamWKuGc/a5ntdtU/U6qm+MCqdp VlgVJjbJl8nN5cjXA90al7PJwgTR3yEilLhDglvEuKZVeKJEyMQPsMCcUmyrFC4Y5fQrHROfSoUi YtjfoTcQPN7zpuPdZApjZgzudzWW2JB2w+fC4+mivfV6gvbZYWhD9qScoZCukPdZSo4lNX9tGMGH 5swaLfKUmGEibAH5q+qUvIbz5f/U7pPdbOcrueqyjTUc8v3n9D7rTUGqfO0BbwdudtU8/XKOHIEf /ZeTyj7r99V6/X3mfDgNho3fzf8RYACKmDHNCg0KZW5kc3RyZWFtDWVuZG9iag0yMTIgMCBvYmo8 PC9TdGVtViAwL0ZvbnROYW1lL0ZPSExETCtTeW1ib2xNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9u dEZpbGUyIDIxMSAwIFIvRm9udFdlaWdodCA0MDAvRmxhZ3MgNC9EZXNjZW50IC0yMTkvRm9udEJC b3hbMCAtMjIwIDExMTMgMTAwNV0vQXNjZW50IDEwMDUvRm9udEZhbWlseShTeW1ib2wpL0NhcEhl aWdodCAwL1R5cGUvRm9udERlc2NyaXB0b3IvSXRhbGljQW5nbGUgMD4+DWVuZG9iag0yMTMgMCBv Ymo8PC9TdWJ0eXBlL0NJREZvbnRUeXBlMi9Gb250RGVzY3JpcHRvciAyMTIgMCBSL0Jhc2VGb250 L0ZPSExETCtTeW1ib2xNVC9XWzEyMFs0NTldXS9DSURTeXN0ZW1JbmZvPDwvU3VwcGxlbWVudCAw L09yZGVyaW5nKElkZW50aXR5KS9SZWdpc3RyeShBZG9iZSk+Pi9EVyAxMDAwL1R5cGUvRm9udD4+ DWVuZG9iag0yMTQgMCBvYmo8PC9MZW5ndGggMjE4L0ZpbHRlci9GbGF0ZURlY29kZT4+c3RyZWFt DQpIiVRQsU7EMAzd8xUeOTEkjZBgqLocSwcORAt7LnFLJOpEbjr070lKe4jBtvzsp/dseW6fW/IJ 5BsH22GCwZNjnMPCFuGKoyeoNDhv095t2U4mgszkbp0TTi0NAepayPc8nBOvcNf3VXWvTiBf2SF7 GjP0oD8+M9ItMX7jhJRAQdOAw0HI84uJFzMhyF/mH9qvEUFvfbWrB4dzNBbZ0IhQK/X41BwFyf2f H6zrYL8Mi2NbK60bkbd3vPDKVTcjdmHOHrfTNyPFgie8fSeGWNRKiB8BBgCACmrqCg0KZW5kc3Ry ZWFtDWVuZG9iag0yMTUgMCBvYmo8PC9MZW5ndGggMTMwODMvRmlsdGVyL0ZsYXRlRGVjb2RlL0xl bmd0aDEgMzAwMTY+PnN0cmVhbQ0KSInUVnlcU8cWnpuEsJewKULAy1ZZAsyNArIjCIoCQQiLoJYQ AwQNSZMgCFRJRFyogAhYqAoispUnKlitKOCKKFhU9Fmw1hZEVBQ0r6hPgd6wtNX3Xvvfe313fvc3 95w5c+bMPd/5ZgACAFADGYAIPBeH+C0ZfLBFjGs6ANDPY4TY0Skim2EADFbhujD2BjEqo/VIcLkR AMXLsYI43oVKQ9yDaToAZCxu/cbYoZXleQCEUHD7nngOa+23UYZbAEhSwmWHeFyhNaw1CoDlUVw2 i+eJU455zbqKy934ehbr+WwWIMlw3yFDuEzjsVIE6gjlCADiQdweTWTxOMc1KgMBSNTD1+sUCDmC /oUFFQB4vwNAQxu3QSabvAf6aXivAyYffRGU6vPJylZZS7NeqSOKhDKpfjSuWkVAEOwjqEZWmhoh KCgAGE1WsSYjJETqSEBIZcEwCNJ+p6GWG2VQgetkY4AYIAJ8sB5wgBh/3eUNou/7I1HuzxF91lfb xcxB+rOfd8Rxy6Q6Z6CUIH/NCZRlc24u/Fy6knp4tegT3dX3DkH1X+NESHg4kgPYXGhIJoaSVLRn hXGE3BBuXCLKFCaJxGggR5zMF67DZkNduYGq9kczBjTUL5Fti9Gg1dSA6W8zuTwOGiJm8QTcxDg0 hCPcwGVz0GA+X4wtgPQpa+tABurvt8jLz9+PuRJd5O3tE8T0WUxDLdiWTo7o+2tAo9nqTo7QHqPD ySdytjpcADHoSJ9v72TvFPnX34Ck9Pf/HFEARMku/L/vIEgk4JYtOhKfTrOxlVCPkY9XqZ7UVA/v Cbmb1Nc+3+p496hy1ALZ47xxZbWuXoPIbzofjW4/tr91m/nTzyIoooSUa5/qjl2OGLX8KmJNEWnM JkYzQkK9+mnBbZMIu9sdOgqZDqcLahsDlj1+7mLyt7DiTcb71me1LluyN6Gx0uH2O2WbW41OXxKI OKA/gAQRj4sV+pF7Wlu+1iZNSo5JR3eDtnXU4OJ+1ZQDFZtkVYpCo59WDndk9u0o8O8NZA03VLz1 dQtaoFoqCBvNsdo8+/pDdstGrqLI9mihxc6fn9XW3FzdqXKVopx7vaHeoujiRsvM/HsTp+O8llbm UfpbWK/3hTzcc0Pk8XpsPyOzLvTGmCabDaUkApQS15URCQiBQFFK5a3ix+xhnL445v2jjt7+/0cQ 45il0xe+D2KHX0FcNhOfyr/EN70z1f+4MxfoNGVAZ3KEPBHKj0WTRByUJUbjxWKByNnOLjk52XYD PlmET7Zl83l2QgFLHijEsHnQXD6ZqG30x7uHUsTkQxxLEQ2A61UIUgQBramsbU+PVxHZBtb6rPsZ J3UNy7Lz3Jrm5WfqOD3det0ynxy7tILI2DXIqBqpX3PDbk7b7hcnDqTtNr7+eKIvcORdfWHEKbbN QM6opV6nICfowrOiJs/eZvNBr9A7o1tfkh9lF1MxGVGj23+fmdU9A4NcqezocFVAn07Vg9w7bfHn WRE1wu7XcCnjOzs+G/1ux1Vp2vnlZywuSeIfDUg963ydy954OHT6NzG9IlM5aeOZ/W1LmHXfuA1l tOm/ujhfImm3Kny7eY3ztjyd3g7bpJfD6wbcaqKbvZBaRm1UtYcJVqql+0Z00EiaTbJ+4kvw5+XO DbItXG6VQs4Uu+3OpS3BJkvpkOQUlJyAnmQlnNEVFBRxeOKAgXBGhkiWmTwpeE74bJHg/aTINXYi MUucJILKeFIMtfEiAHCx/BMluUF5nlWjs5YiWa99ENw1tIIWM44JyCzqH2Ubasu9mJPUoMrMFKIS VJUrNUgkIoHc+m9YwEbGYEfT9Hp+NtMIblB72nAmbut502e5vurf6gc0y9JTUUjXi8/Ob6IXj+w5 5aJLnpfmTiCDCuP8TG2VS1889Ay/pGA+WF+vmVDz0OXaY9PRAsvVnqGywyH7rzg4O3GURKIK+s36 upY2BdcJn6ELgz1mN66zjyhXvf3JoG9skUpCEc4CWvgp9s8pFtAA50C2q+t2zRvuo+yhHzw/JAEB Zg0tpwrBxJsv2CjkxsWL5ShHMSe8IgO4bCFfxI8Vo958ocAWM4LUKWPd90f4QpaYy0/EjOHcqcLQ +21czgDooiRxPF/IFW+cPpowDELH6aqmQ4w+H5sW/wcR/VmR1hDOnhMMuLwMNLAo3ZuyBj4pr9ll /snr8UL/QyfH95ej7ukryr8sz42mr7vhtXbj87oN7cyel0/3ZVFzSzNjGy6tS40xvWPoel8DyR8s uthiE1tSEv9xcZczrUXtRMTH53wfqbgvLKLVWDhVD/lt8erL1GgqWR/KqpOmH4y2SfZ/XNy41qUk iIopmemU1jzaba034PYFWyc6QoFTaugYvO1V1XAB4bLBrZZQn4YdGS3OQ8yCwCNjVak8cWC9XkeR soUxCM+L5jo2LddSdA2biHpbEauiVHlTEhY+/LXLmlmSZFLPaPORjMLxo52b71TpC1e5Xj0zonTI BDaQt7Y3oMnaW3+YLtJqKDkMJeVy9CMkSQmU7M2gRHUJhrnCA6YrNukcD8iZuHZQ+N/Pn/RPME6U 57BwULV1l2yvnv2zU4jZ3WRN2apoeukB1WvuCru357Y7Dxi/HAnfQztRtuRKzPC7v3e4uETWODC5 42Y8j/aO2vsK6d9ju9xKKYKEpnEthh639V2Xd59mJMp4EpNWXzvnirWjuU0z56DWTnMN9qFXTOob 4/Y7urLgukRvuuKYdPbrh3Hr1VeMnn0R3Hb20UX4DsWUtxsWWuoH3DYkHH6R8YDYGPWPY99fCX/O 8WsLZn7dSLTQmsi7M6KUu+nU3ktfOdL6U/urk/s2lIGuBI9zNx12PlikVW2fYJDQa/9jN5XUX+1D uhI5f2FiAFU95qRK+ee3bjM9fDupoZWCXi3nbXuSSqtuluGs0I7fDY5N3w0SVIsZreB+rWb3Xc+S 6uaBvwQtQJwHcFpYOHPY22MYfoGdEqGkElOdJHgSWZvwC/VlHg/V+sfx2QyNvZAwGY1o8OPMoJjs Y5ctg5RiMsLVGMvEj6QxFaXphZSyZnSRGyVMjSx1Rdwmy00Ll7JcRAuie5P1d4YWt+X1++/3e3X+ Oed5vs9zzvOc5/N9f79fdzf8GkBa0BBZg/KkRASCMZcBfkcKkBB0Cq8R3u5PpdFDqB9Xhvreyr63 TUHi/NU2sYDK8jYUVlqoYNwHg4Yg7LuQzEFqYL6mibiAJiJLNMk/KuvWKQpI6J1dJCrWT+kcpG3B Ok49YA/NX51vhOkpqzYNcXrIr+JgDJvL3YQdcjKuOIM3ceWVbKIN19AphFyPFyPSZlta+C7ZileK Orvs1Uy5jfzk9AG7SVrnaLrJM6G2iUL3LaU6vi1MigXHjmwvKX/DoSstA9hpc4Ba2VH99PplsRxn XsRWeeIvlYnssuNljs7KTtJcXWavOJFKt2zSq7VPy6opRL8Xwjr54pLva0wezcwovdSNCj34WM88 peDGviZvRfRFXYksMlzB9HwK7/5zYwSDpJT8znC4osQ2JlhDYi+UYhgZMm9yXthB5g3Uel4W0mfz h/Og0CBzIwwKv8iCbgL/h+q34iv8x0CMFHLVh/JTFgpmAlDIUr6JlkDIIWRw3lWK11t0x6pzvQ69 G7qn3SCutwlY92mCDAwhth4FcYMcAEtVEsR8RUIBtQYkl3IYKHQRIQTAwdu3YGa1YyDT/PBczi3b qKgr7K7hdY2elQq1lVU+MI7VT4Ze76vUs//lmDuXP2iQZEDdYNFbpaPRduMx8t5LjVt9Csdiu11F jN9u6Hh4m3Y8XtbSh3qE2lB8RiupO2WLveSNkYeU5MjI/q6Ni6pHz55CeJDPcJSIJqyasYJEthLb IdqHazezhxBEVCaXHnDspT4HjLqpdpazsw1KFmHDecZWY8GQCyUWtTelKzwGZx/la8R3Kjvlu9ep J4cW5u9XXCQnsWriHQo51/bFFK8t4iNv27wsrBjFy7oZayBuLUbY9pxUJ835jYypJu6q2/z7CP4v Qtee3uiYm0BJUIL9LFv6luIpshfAEpIEYfZuGWYoirA0CSK49Fb+LCFBifOjQENAPwKgT9AHAH19 PQMB/XRB+OmD5Y6gCcRz/tcbIXzPjeDfedl/TaN+yag1vCSv/lbTWHSbaWyUdhGf+ztbvJ7IeJLG 7ctzMPXa02rlnBmNe2N3X8FmzL1exGQ1Ztp9csyno+9eeg3wbGFHszqh/Rh5ZCJVqnpKs27dEDxL NAE9VWbI5s2Loo0i1Eo8Ne/h8mVTWLIDURfNtsNP5tSH3lQe1ft7Sv+0k/uR6T+A65hnnkjuTgvk My/+ZG9hraxN2LqN2Ad8eta66N6fdr2JFIrGzd3xuJdsKXLMPYnfLGnt4M5np0fZJ44UmyObFsVH Az39wu8EeVaS2ghEoEdx9BFJTSN64Wz3hgDV33Ta9f4cnnW1S+AZtW/0efwqF05JLA40a5oegA+3 CS2nUSyoGfhHjJaOCi0p8PPlQuKbKPzMlODmu66YiUqdjrzrVw7vUSvnJW7HAfHFAjsWEc8B4nOZ 3+QOh/Hz/4OXXycY9oKlKiNIgDlgmmectzXB8ENJ5xe+X5v28T1LlVdocJCgVyc0nE494MeI0BG4 i8BbQE/RBg1fePkSEvWx82vIc6M9E0/FZGJmiipa54uIzTeHnv8Nn3XrLsoozsvanA1/ybJRUqmV 4T8PMFvVJJcKc28lWVS2KO4umyIgjFcPoYuEi5Ivxlm5Ryqmn00NmnhqMGV7YjzU7EY31515G96g fX1TD4ol0UT6M8Z2Nw954rTZ/pDGnunMcdE6FRRbh8h9XdQalhiI7a8YlD/Es4EWaDbs4Jef2O8z 36HVQOdhy8UXjSalrRiTq5AZ8k/ptxOg8qvRmnJXPcb9dTkvApzeOrAuj0r2QGd6fQ/vs9nN1wq9 f9CpC8kLYYst7F1v8T4tNv8yKrcdK3XF8aB6Kl2tLnCm0PQC9mVzTnUiniWEBbGoDAMr3HjuDwO+ f8BbDCmyfKww8FTz4icAmU8xcxMULwwHjxocJ4ikH05/FRwvhkR9GAKDIsDVf26J4iWAlVZZULWf JiLwqxFSs8iy9Q241yi5qvNS03eYeCBuxXAxfCgQkmfJtICQIUEQGsQfEgHBQJzAexR43w6hg30U SAj4bA0+h0AY4JMHaA0HxwUt9WAguhBtCAABOGpM1Q9ij4qK+kLsjOhQekA4JTQw+su0EcGCQigY xpnFtl19nGrj1ROH2CivI2JZcVhli/fEll7xB9ZXLW7NxeJUqAYYydN/FXiNs45H+xsqBkiIGVZ4 YwsylfgeC1yXKd76hlIVY6sSh8lc+DTM5HUDce1w+XTMCe+BJKjtVlR1RHDCgi27L6XtVedgULCn 2Ytao6ul4368sSt9kTHtQue6tFmLXZkvFUMeo11im2J79/seN66JyjnlkZ8xH036t/++KZWyUzu4 5/La0a/Dqa27mow7thyr+1n7Ag8tda3VLuvQVMF4mewRjXxaGBxTfC7r3W+RtL6cvlRk9ngp+UJn SJhbysPFxscJPfOxTm8ZuNeXyimbLz5pjFN718FhwbYBLJjt55ND4lkwQ7BLf0npFSD48MpLnARV K+fhHx4kUBeGHH4ggoFx8mdE0cOD8WsB2WXZSnwcoIWxC/HTxmsBGssG7OeZQTRQoQwKLVQgUTf/ 8MggP/8lvOH1AMLyaE0nZ8w2O3MLu212ZC+MOYlk5UK2stQSuAKI039+AyYlEkPzpu9Nc77ZME/q l5HP+ULnXoD8SkGLfmoIQ0E9f7II4SUFOQIewBsQ8PgtBN2dX+n5XI9NS/ev5b729ZFM1WrV7G/o yZaIG5Z9O1Ax41Nd19bA0HHFbXq68MS+vupukDcJur224y/TUZ/i8dTZpL2pr/p9PTZbj9CFxrtV HPayXt0NC5gDU9BD1+x6hWuYPlXMVUYH8eXrDZxNPT3qoP2Sztk7d/1q/qiakj7RDJltynt2YXyr Yxzz+UZX3ReGaJOd8qUofud02WCJBDOF2inpvTveMiddKU3k8sn+yRlAQyQvWGHBu9jlP1xXCVQU Vxa97/+qbsUlbthEHWlsQBQILrihUSI0ooj7Ao5GMC6gjoKJTjQmmBCDB9yPcZlxHQ9uZLQx0eCS ET3RGTVGjbsTRRONS0bjOCbHOWr/uXRmMdP3VPWrqvfr3f/+q/uqvul0JdjfdXd6VEL491Pj3OuP lD354bML5+aParSmYlX6ujbxB9bsrNhxoPPVTd63MvKLbk3xfXI8t0HrglYdUoOmbyss7Tc94U69 c8dG5w/KWDdu57gnHb5ZXYklOVX9Q3+/dS4guoMshg3Yv7Pb8zDi53+9HuNVA7GVcmjbYq+2gFlF cwLKhBrVu/SpU6YiEW7z1J7vT5H2zjDZlwgxxlRftRdy64tQbs30MjQFzHVuN7jd9vfhmEnw+Cea a7ohnf/47w2IwHKsQzgeSFscQiX6YBNewQAsQy+cxA7UxUw5DgseJGMLIiQUinrj4mquwiWMpNrc xDVEIQ1XpQHv40UeGqOLucN9GuaZPfQK4kfGduyVyTIYcbRTVYxEM/IiUwkXoswJc5FHa3BTwk05 Uml9h/poiQIsQQNMxDHzlEzD+bGyWWbLHYQhCyVWvFVsJqErduGcpNFKx0z7Ys1dmMxRG8UllabK 3MKfLKEmFuA9zCPjnahUL+kkez21MRIvU02zefUtXJKG0lYnmpamp1nFs5vxUEWrI9pJHtHojdFY gA3MxnncwI9SSzrIGikjTst9+yK5pfFTahbmkPkmjv0Ie6SttFUu5WK2XGiFoby2CKWM/zFOSZpk SqUc1KV2G38P08gEm1tcw9bIIMN1/M67gUfShj6MoFvoN6zm1ht2u2fvcoZjsRqncJo8rjLvP+Kx tCauq3dUgRlutpibgVoJRWcMxAj2gBnsFX/gqh7C5/i7PFE16XnSOmzPsh+YpcxtJHqSe396D+a9 S7hKO1FBnOcs64ubs+gs/WSQTJBFslwq5JJcUg4VpvLVXe3Tx/XXVkfbNgm8U2M0Z1wPhiOHK/AO s72U892CwzgqwRIpsZzReY7/SXVVycRGdVJd1XP1Iuup/YH/mv97/xNTDCerrBfzMB3bmIUfpDE5 tJKJ8rp8S+aL1Se6rq6nPbqDfkUP0Zl6nl6m/6K/tKZZZdZlu7edbZc5s/1T/KdNmnmfuRA4yKsl YhCPTqyf8aymSeSXR0zDbLyLYixkvSzFepRx3gdwFOdwBX/jCkDCyDmX0X/DqpsrC4lV8pEclMNy VK7LT9VQLYgo1VH1UEkqRU1Qc4ll6pQ6r27rZvo1XaDnEGv1bn3JgmVZxm5HpNol9mbHcWeUM9U5 psYXT+89a/0s89lVP/xN/L/2L/cf9N8yw8xM8o9ALHv4bBSR5SrWYCmxjZW4G0fwBS4EuD4UJTYr PkQ8rIYYrloP6SW9iXQZSAwlhssIIlvGSA5RIHPkPSmU92WBfBjASs6tVLbKbuJT2Uuckyr5Tu7K Q8UiVprVHKFaqjjVhTNNUr1UfzWImKCmEnlqmprBFdqsPlZ71HndUEfoWJ2t8/UqvV0f0mf1Py1l xVhxVjdrmDXBKrROWqeti9YTO9T22jn2WvuQo6kj3jHUMdGx0rHDcdvx1OlwDnCOcc52nnWaGhFU qz9z3rvw/C/OcVJetxtZb6oqPhchOs8ukqHMmEMN0ZP1Qv2VPV4eaLdclmKdqyeZjTpFPdZTZZg6 IC10qJ2gx2M+jJSp6+qRumUFyxB1R6KsJfKpmqqTlCOgq2esYKvQvg2oC0hQb0ulOqwLdaH5DAn2 Wqmy16rTcFvXVENU8akuUis46EuVq0qQYcXbT5DLvG+132S+u6t50lqftdbipvaof8gDWU7VOCF9 rHD1quoiZVTcZ9Ic9yQfefIhEmWfXJEKiGzRm6Wvqs3V8qk60kmAEzpMzuogZFZzlEgVLAPUAzVU 73ecYn8RqsRXmCVa2rB2/vPz851wPJapltQ0L9XkjLRDCFZQ7x/591crtn3RLmGdbdAxfL9sg1Hq OBL4bNwkMvAB2mEva3Ae2qiVmG3myFjqfjr1U6FCJiJOalEtXeRWwH7RWLWgFo5m1MfU/2NU/TS5 j9+Km09WJaKs6ivzLS+VKYv6W0KMxSgercZSxy77DPqLC7Dc/rWs8q/xKnvOt4zfBN3IbwQ2WDFk 7aYy53PEan8q+2IiGR4XhbfJuTuf8wFWKpV3uZnIGeayR/VlTzyKXLMCSVy7QabQlGC02WBGYgIG my3U3xlmJzqiyM5Uw+xoK54ae1Q+Zz/6q5RQt1NxmXoUISG4S2wn/+72PhRbF6idPcx8cw7BzEcL ZmgMu+gNvp3fZ95SdSXa+/upcpOi89ihqjDQbDahEoQcM5nKux+lTpvaMwfN7VLWLhJ7Dh2S2KP7 y926JnTp3Kljh/j2fOWKeyk2Jrp1q6iWkRHhnhZh7tDmv2rWtMmLIa7GjRo2qF/vhbp1atcKqlnD 6bAtrQQxXk9KltsXmeWzIj2pqbHVx55snsh+7kSWz81TKb/08bmzAm7uX3om0nP8/3km/uyZ+F9P qefuhm6xMW6vx+07kexxV8iIgRm0FyR7Mt2+ewE7PWAvDth1aIeFcYDbG5KT7PZJltvrS5mRU+zN SubtymsFJXmSxgXFxqA8qBbNWrR8Lk9eubi6S8BQLm9CuUKNOiTla+JJ9vpe9CRXM/DpCG/2WN+A gRne5KZhYZmxMT5Jes0zxgdPT98L0QEXJAXC+BxJPmcgjDu3ejYocZfHVBbPr6iHMVnRtcd6xmaP zPDp7MzqGPWjGTfZ55p1I+R/h7x5g6SMouevNtXF3pB/sV41sFEdR3jevp+7EIwP2/z5DLnjOFv+ w/zUhjPFXLDvYjANMTbmznWaA0wEuE2o+IlQo2AU8ZMjtCVtI4IIQqhNEW7DsyGtTSVkVCGUVpRW lUFJaJuS0pY2gQhBK4jk12/23bucD1poVcTn2ZnZ2Z2dndl5t87HbDK5y2cebo5lav38Nx7HGqYI RhPJKDZ+FSFsavFhL7EjHjOVHdjQx+fgM9mnWxOIsCSx3mc+ElgYWJtcn8DFFCZNWrbV31dYGB6w PqTCiC/ZGgv4zQXeQHxlQ1FvASWXbT0xKeybNFJTWdHrGWuHtXdMbmowOidzsCatkyM5nUdNy9Jx VdijwCKkg+lb7YMnsQDONJf/rJlLydVzMQ3/4gqszE7cxzrzkfpE0lMLuYftTT3oCfiStwn3H/jk 45GSlSmJEfTcJh5ylqQTDXpnbJaXm2VlnCCuetwofKyTfHVlxZZ+YQY2eHwgCB89hdiujNdWIfh+ P1/vnv4wrQJjdjfHbN5Hq7x9FK4qj5siwZpBRzNuOWu6HU3aPBFAHp9EvyYaZ7qL0/9zPePzI2tr TWX8f1CvsfVNLYGm5vaYL5JMpGLb1DqCs/Vz07rUSLEVCLipBRGpRQGk3rL2GAvwXw9GA5F1iUaU Gnw08+tjqlfE7ZHwqnIp5G9HemVmYqN5LS1oyPzv7He5kcBSoviipifRaP+Nj/L7H9Ko3/qUrST5 3Cx1JrO2fCQ/bwQ/wr3RSRUOa8WiqbU9mRw1QhfFY5VMRgO+aDKRXNlvda8K+DyB5IAaU2PJDZGE c/391qk9XjP6ahyHWKvUIrUFLewNKLube8PK7pb22ICHyLe7NdYnFFGfWBjvnQZdbMCH91lKBUtZ yIyPGfQ3VEWfcMv53oEwUbfUalIg+dX9CkmZ25EptLpf2DKPIxOQabYsLGX8j1+K+tZYZg7IwopX yg8AIpd/OEIrPPTZpuFij5Rk/jOSRkgp4pFwgC9stYF24GdmEPiqcYwajRBO8XVqhq4VmA75Pu1l CmL+c+BbQPeJEPFP08XAp0AF0AL4gFVADFgCvAg0Y64JfJPXcKDupQ7XV2ilfo48ehtNBRZjHNA+ ojJtI/kxbmQe+81WJ1MZxlOhK3VNxtxz1lXWY95UOa8NdhupG/o68I8Cea695AXNBfIhL8Q6R9ln 0Cb1DJ/VuoHxFvixCOPPQKPwtQF0CeRLMZ4P5MDmiyJkrcZ4LMbzEZuxGI8GIrC7wzaYnwMfO6Ev AC94LvbNAfXyXKxZql5SvMoBfFNdol6tlQqgHyOBc/OZnTOx/+zTv0GU/cuE7Z8E+yo+9+0eiCys UWfLu9qeOutBcZ42qIetmxgHjAKKMFyXaArO9zEQ0jppkmuy9Vf4uEg/SdXg3cBECV7zIO1Ub1EY unLjdeRNJ9WJmVBUW3fFN2iyEaQncF7Em0rge5xzD7kwDfNapH0nTdGuUiHGYYab6M/pOCE2uPsm 0HrE/bqbrE+wRj0D6wwAZ2A/AftXcQz43pW24R7MvQbdC8BG5MgkYAL0e2QOw4btsc/jvId9D+SR OQhw7gGzHKTux8GjDmT8j0mMByYAcwDe93XgZ8CTwHd5DtYdj/lT4MdLnDOcm5wfnBsy/5FPMmf5 HjciNpxjds38QDxLu4ECoAI/SnamUIa5sl74HtlnrgVem3OLc8ah0Bfbea/c4HNyTmXQgF4h95Y1 yLmVQUs595mqYXmGUjFINZyzdqwdKn2IcD1yTTjU8YfrU9YIqNpF+Rw7vneHOrFI08MUhG6J/h49 oc2kFepZ5H8Hxk+BzkF8DskavKF9j/4kdpBwDVIF7pJr940sup/hGlLWY71BxLJYO09vSDokpmpD iq73WNf0HvGSDWecSbOhDNo6poxM3X8r/18gLuo99CzGf9OHLEsbotdwVnL9XZkB+BwKeR/QDZS5 y5X97i6l37WcPMibW8DzWhi/X8M0RxukBdo4WXdByJdj7Sqti+bBTsUvtVfU5XTE6KEvqEO4R+wl LtLLDF4fdEM6j7Jz7t5cktTJ1/tQroEch8qaClm/l3UVsv4gazJkDduUQtwb+H2W/YHk2zzWydd0 Xr5JxertjPzMytOM/JwHO092XmbQMUxTvSXHqVPYjOdew+eX72ObrCf5zkHX58zPpmn7Y9Qvjlkf yHf4PLU7dQ3MBILQ/zz1juAdxn1zz9xrdRgvWB3qYqsD5/yJsQv0pnVClFi96Z4apFmpt6zQ6aUc J/08FaX7aJCWpt6zIPdT7Sh6uN1H82X//AtN1G/Kt22W9JfrkGuwCu9eCfr4P6y7Wh49p75CpKIu WY4caWad5qZx6h/x5i6mTeoh67fqPvkGRdRhiqvlqGHYImYTdUFFegM1wYbkejwHlGXsv6EhP/kt aASPu3LeZb574y7lACX6dbxHbZhzTJ41KN/x/TSN4yBtN6OvYC1XOeVpgspTc4LS5mv4XpDxwBuY EYtUb67jNY1lMmdzpc1s6647j0IM/S2qwf5BuVcj1bpDVKy3Wdfld0UePameoxlqIz2GcaHM+13o UaXol43oj4D6ETCM3PTYvOzVklp3ZL/fJvv5aL2KVsjvCdYZNMUopekMLQBdgirVt7DO88iruxi/ bVny++B3NJb3hjya+j7h7wQh6+U3sHuXKrnG2AfZb9ifA8i3C/QY90TXEcRwFNegoiDeRak+mAde gH4rA99OyYpsqvjFe9Qmda30oTgtjovTVhd/B6rv0zPq93F/x8mvtqN/n0VvnIcevhix+jXF1F9h PBXyQ8AWfPttolwtlzrVK5g3C7oNsDuPNY5Az9gJm8ugb9N89Re0Th3E98EV/kYgv7YZ9GmggeqV H1GXuENdRg168jzrTbk+Y5P1ZYkj6JtXUrYpSF8d3M/nrfi2u4+/0tdMP9nH+/jHa/C60g5zNI1y iazLQNCmw81iL/UAh8X7mPsl2qoctU4pBymqXAUOpvBjapS0F2hGjVUrLwLTtWr6KbAd4wrQ08Bx m6cDwAfADqx9BvSEgZ8KDLEQ+QwK2SFgP/BLR5cJ3ut+8kzoXuvUCP4d9BpAuYUz3Bqpk3tupxrs V6PNt04x1GvoIYCxjQpcW6hALYF8CuyyeN2Ld+4dmvYgfx4E5QLNkDG0EX6YMz4suHa5P/+/1ntY 4H63AU9LH67jPZY5RGOUi9Zl0DblIvr2ZrylAPhK8PlOPJ17gvw7Up51f8gVUsn6Z7Y8m8++1wfx 4gQ9kwknD9L58BrVMbQFmA9k8+53qY5hnIXu7L289sMHoB3fKAfYJ+Rgyb28sZRKGGIafC1kG9Qc kOYv4F0FeK60z0G/BGTtAuIkejGQ1lfjzQcy4lrDcVUP/Iv7ag+O6qrD59xz9+4uy80uS6CQEE7C ZiEhSxMWMTzW7m4aoHlMEwR5xJlu5FFmeEyCYDuOSUNVFLSYWBAoWJIi0Y5JzHKX0OWhZMaxnXZa iDOOOs4IQXH8w3FMH+CgCfE7Z++FEGDS1PqPu/P9vvN7nMc999xzfiflt96P9V5Gvx+ML6JeBmqQ z14mReBV4KjFd9e3uV/ct+ZXptb7XV3sJX8ZFXPvm7j3beBbeVSb/0/At/MO8Bbw5v+6L0qwVgEP IHPUpWSZthC55xqC6+rQu4QMpoMn41zAlzfYj/JvUN4AFKD8BmxHwfvA2GoG78A+jHOEgU+oGcjf CdkHoI079am6Q7eA51NtDF0g5N+/N7E7VX/wJWA5fMjMBs8ArwM/A0pRx2rn+9B3gn8JfUWqrUGU h64D3wYqgCMpHvwOIPxO9PE7kY885B76qfKj7h8fl817RsjiB+4Q4+GlH4vvu3NY738stu4SD2E5 D+b4tRHjedQd5z7G+nGOBHJpn8gpRR4tclkb8meRP95lcW97SvJksx2L3eIMFLmzyF9tC5Azp+55 BSPug8usc2Pk3ko/IicAD5Bp8jbE3MZd5zLOJjf21Jt4vlMC8mwT5xqA8V6R/t8OXxIx4PegZ4Fv Wmeatbc+sMeOcaZ92vp4z8hPcKYGTcRG4VF2C4tMlAmMPovHi7HO7k98lj/ijB55Tv+3unXOWxgr L30gDxhDH6u98eqj845x66PyEksfjQf8o9eelc9kkIy7GPXdjRfibqH23Mv9rTGM/o7vfm/WHaEJ Z+oIYB/Iw5mVD5zEflEEZAFe4GXYXnAMkqCjiwSh9wBnYfs7eJPwgVvpAWxut4aHoH8dukd9T8au M7FprPU8et2K/Fzmh5gzuQ+2iPGTQmAp4AVOAzusdy3unuj7r8pFQsQ9V60ZvqleBkblgGPyQrIT 6ILuhu4+T1YP97LriWXLgpEkuOBxyUZefvCccBgZM4I/Z9eVTjKHcBiuGVMzpeeqUVJiFj67KFVI zJ0XvBadwK6SfwAKu8quYdJlrUTe48GBqA4DZS9gp6aEkzb2RxIHFBJhf0jkzg62XmLvwv8Oe5ts ktXeNvRJQTT4FnuDeAlnZ1mP6elJpE0KkuguHCmU9EL2Af3AAKCSOvYT0gQ0A92AStyQHCgEqoSF dbAOjLMd9d2QhUAd0AyoZDX7KezbhGSvs61kFuq+xA6RKeDvsoOST4EzwCdhnwl+DbrgVlM/Dhb+ Y6b9FehTwUdNPgJ7JvgwdME/MPXnsKxFvd0mt7Fdxkzuic6EPxsoAhhKh1A6hKk7BI1AUvYNtl32 dBocBO9IMaar0cjxyXfUmHhserANU9qIqW/EzDVi5hqJCleDFdOQipnHGhDTgJgGxDRgVorYLvS3 SyQLkB4gG2CY912Yd2GPQ/YCfdL+TcgWoE1o7HnMYz5GtZ9tNfI4FtmWxOJIMHyBPYupjrBnE9Oz gs33NOcEsRDBaSa7Rexm6d2ccE4U1s2JjKwUI2pbNI1tJF8DFGyNG0ku8BmgFFDZRiO3kJ9nT5Md DhJJ401KE2tSm2xqUSn1XmJBUo1MmhMvm0dCCMjnsRAtrnXWO/c4mceZ7SxyRpzVTlsda2LNjHFW yMKsisWYLTnca9iXLABFVmhLFrS42lxxV6+rz2WLa71an9avDWi2bK1Ii2jVWq1Wr+3RWrQ2zdmi tdiVWle9a4+LeVzZriJXxFXtsnE7bYvuZRvwmATSA9QDLYCKOY7Bns2eAWJ4GzFMxTOwE0gCzQP0 odwPtkFzI86NODesbljdsBJI4akGaoF606vd9Vh1RPyA8AC4FrA0WNMwt/2QA6IElEPToenQdET1 KYMYoQcyG6gGmLT1A1g1kJavyPTXApr0D8gYyxcRdZXByJfm9ObTeD5ty6ct+TQSCkeDkVkQXq83 5ov5Y3mxdrXOV+evy6trV6t8Vf6qvKp2NewL+8N54Xa10FfoL8wrbFe5j/t5Hm9Xmyu7Ky9VXqlU Y5V1lU2VrBivLmEUFAUlz/IL7jGmZwSL3dGlSjceJwbZClwDGOGQhUAYqANUpRuSK12wdsHaRaqA GGBDjS6xvUBy0yfsrdInSsKv3OdnePBOY8mCqmg5ttwY0AowtN0Jf6eMTpW6pT0O2S/tVWZ8m7Rz SKsOwwZXI7e5Gnx+NSQMxIB6wEausLXkGoCWITlQD3QDKqvBfy1bq3Th36l0skBEnz+Fk6lTCSHe SQ5P1KNMxBrQcbgKeVTK/VKGpcyNpJXrt8r1X5Tr3yrX56Cg5JEoHIekzIm4ovqZqF4V1fOjOlp7 jOQQXZkipSYk/ZuUT0sZiKTn6Ldz9A9z9Pdz9Fdz9J05+udyRL0Z+HZ1JV1Kl5D0sJTlUs6OuLj+ JtfXcr2Y61GdnqDonZRIOVPKTCHpB2fcpW7ivEA/IKVoiRqhfJ5UiCQ6bISioDtGaAVoyAidAP3L CB3kF+ltKo80esvIvcGjU+hHtEwV+ocmv0/LSAd4ALwF/GMSon7wKSP0ooj/Eeofg36SzHKI+NdI tazXSsuk/VWz3g+NwAb0etwIfBW9HiMB2esRI3AD1oNGYD/oZSOwHdRs+MUAtxqhuTw6iW4huYqI 3Uj8ihhJpdnjU2h5O3hFqvIyIyBqlYoOkvRJwzcfNEeM8iL1kWrZHTd88iGziE82MYP45KAziV9y GnXLwetklmSH4XsRrWhn/Df4P0MXxIOTm9RtnOB/vojnWwP1T7TM6OC/Piemy+BXAknqP8sv+y7w X+Um6RqD9waSDjguBZIK7eGnMclxxCr0LO8ObOFdPult98GLV90amseP+2r4K37oBn8xcFEMg+zA E6+Be33gCV4Z6uDL/UkKdySEziIT+BLfl/limBclaVmig8/PTYqhFKGNjrN8Lnqc7ZND+ULxeWUh sdOvRAL23fYN9jX2lfal9gX2efZse5Z9hj3d4XV4HGmOiY4JDodDc6gOxUEc6cnh/kgBwVeYrnkE aaqQqix7FCEhxK6vUIeCbyc+mVUoFatKaNxbQSpWl8SLCyqS9uHPxxcVVMQd1V9cd5rS762HFlf2 JSlZvQ4LVJj2Zsa9T647Rygt3HsgU3DD3gPr19OKeO9GUrEhO35rFZ5jwsqauM1XMo1MfS48Lex9 YtLi5aUPEbWmLLj3m1Yw8jctK374P+xWW2wbRRS9s2snaRrqlEdl1BZN1nVVZJymhhYiVjSO7baR kzbELtioQLb2JrHq2MG7mwo+GiTERwGJD75RJZDCS4DdUPpAoqh8ICEkJCgPof4h8YEESLw+ShM4 M7skIFWg8vgA7SRn7p17z9x7d2bWs9lcofnixmIzIZSfNxazzd05fqBwWnlAqWfSp5UZIYqF0+wh 5YHMmLCzh9LFZRppygxopAshaAukCRppbEHShiUNx1TLpFua5pLOsSFBwvE5J0mTbqxNSIFYo0KA ptxAm2SsTcoNgobz4AYL/TZYF7GQDBbqIhlsgyC1olFQbooKSuvWKAit6K3S/dKKOxJ1yylSVOaJ sqLMw9gKZ4vLwSnwOEoHOLF/spmDV0BmC8aFciljRjLjkYwJjDcfn50KNx8+yHmrfEE4eFPdPH6w NCWkYTYvRMx0sxxJ85ZRuoy7JNxGJN2iUiZfaJUGzPRxY8DIRIx0cWF+LpX9Xa6jy7lSc5cJNieC pUSu+exl3Fnhnhe5siJXVuSaH5iXubJjgyw7Wmh10GAxdcCVC8rqTrwP4+t7ioPrumfukC/H7T3h I+vPBAjX1upYsdkVGWxeBQhXPBlPChfeTuFaA3PIc4WP3N6z/gx73nN1w7w2MkgxCmcq6eV/y7Js AceJobedsLTZeGl7ctnmrjvvKTT1pp5pDoyni0xsh+O1VGGg+6z+vq7U9Tn9Sf2Y/qoedJwizFef 1d7XlPu1ujanPakd017V2oTjQOH1Af2Y9o2mOjhNzEbLpGVOBxL/Ymg7lmiEBBbgpos5sVQhqVEJ X7sMX+ZxugaIADcDOSBIb6P/EPgc+A4I0CPonwKeBRaERY2r8Uy4khYZizHxoxNWEwt92xO3nYI0 JlyZu8eVmb2u1JOJMOTxnTd3JkP48GZ0Bv27wGfAl8BFIKgm1IQM7rintmiRFWMonzCwRWfFbBaD wsRy21YsRgLigGMHQI2x3597YpZDWApsCARI0mqJaY6QK0T8Bm8gCm4QX8vUTiMthb2hvInP1Hbl 7HEKBk4pb76mUme7UE4wur6jLXgWfoVUdiOtYofYfRSOdf+oL+p7u7/XRxZ12gm9+xK6bX09a3vW RtGxDQG6xNW3Lg0E6SfigbewEsfpaCCiXsT3SPzEya53uhRKdrH3UEIIl2YAWifkGvoA14RIsPgF bf1qWx+7lyXWrbvuWopotP2WHTuUQ7Xzs0tLr59cWpo9r15snG9AY8pJ68MG/dpmffjw4cOHj38A n/nw4cOHDx8+fPjw4cOHDx8+fPjw4eM/hxCdQa+SaEuyF3o7fYoRI7fNsY89XaWwst/TA9CnPb0N +qOe3k5V5WkRJbAKlj51lacrtEbt93QV9t2eHoB+2NPboD8HnUFHPeonno56Ah8JPSTiTwRfpjw9 SDNk0gQZVILk9AKQpympj1CdaoDtsTilMGpAF70Be0UyOCxVzO+FlpZ2429G2rpcGaccPFVyljkW bEOQbr5t1I+/Pop7WkJak5hRhRzDnEnUYMtZY4hnAQ2aRV9GjgpNSxunvZCHJacOm4H4r8j6RXVl +IStQYdgq2O1/vqTcVhN1FRBVlvWIirhGAuO7UXdj6fmNCrnc9os842g34fcE/IJRYVinomolqx9 yovWm39wxpwwSiZ/geenTD5Sr9VtmHiq3pipNwy7Uq/xmWqpl6cN2/gT0lYRjOfqVUdYLD5Uw7xt /f19cXSJXp6sVvlYZXLKtviYaZmNWbO8a9+e4WQmlq9Mm9Ze8/BYfdqojeZG8ldqlwYOC5em53m+ YZTNaaNxiNcn/rBo3jAnK5ZtNswyr9S4Der+HB81bL6Z50f4vomJXm7UytysWubhKdB6aReWdg8N 4+BkKPabg+Eei5VDMYqNGYF/TG6ig8UXx+JKZ//bfP+1/h++1lgdd4/F2jnwitEwRrvpbu9pRN0V PI2J/XKkx61qD/QMIlYoK/O7Fbg1bfZW5yDWqo4saLiB2h6jb0nHgrbjxunGxt1FFHw3dA1uD0Xe ULhp7u36euj+kP5Dx/Ud8sp65vON54Q8/dGJLT/Zi090U8caDMX9Je+0XwQYAMHAAwIKDQplbmRz dHJlYW0NZW5kb2JqDTIxNiAwIG9iajw8L1N0ZW1WIDgyL0ZvbnROYW1lL0ZPSExBRStUaW1lc05l d1JvbWFuUFNNVC9Gb250U3RyZXRjaC9Ob3JtYWwvRm9udEZpbGUyIDIxNSAwIFIvRm9udFdlaWdo dCA0MDAvRmxhZ3MgNi9EZXNjZW50IC0yMTYvRm9udEJCb3hbLTU2OCAtMzA3IDIwMDAgMTAwN10v QXNjZW50IDg5MS9Gb250RmFtaWx5KFRpbWVzIE5ldyBSb21hbikvQ2FwSGVpZ2h0IDY1Ni9YSGVp Z2h0IC01NDYvVHlwZS9Gb250RGVzY3JpcHRvci9JdGFsaWNBbmdsZSAwPj4NZW5kb2JqDTIxNyAw IG9iajw8L1N1YnR5cGUvQ0lERm9udFR5cGUyL0ZvbnREZXNjcmlwdG9yIDIxNiAwIFIvQmFzZUZv bnQvRk9ITEFFK1RpbWVzTmV3Um9tYW5QU01UL1dbNDA0WzYwNF1dL0NJRFN5c3RlbUluZm88PC9T dXBwbGVtZW50IDAvT3JkZXJpbmcoSWRlbnRpdHkpL1JlZ2lzdHJ5KEFkb2JlKT4+L0RXIDEwMDAv VHlwZS9Gb250Pj4NZW5kb2JqDTIxOCAwIG9iajw8L0xlbmd0aCAyMTkvRmlsdGVyL0ZsYXRlRGVj b2RlPj5zdHJlYW0NCkiJVFCxTsQwDN3zFR5BDGl7x4BUdSlC6sCBaGHPJW6JRJ3ITYf+PUnUHmKw LT/76T1btt1zRzaAfGenewwwWjKMi1tZI1xxsgRlBcbqsHc561l5kJHcb0vAuaPRQV0L+RGHS+AN 7obh9FDcg3xjg2xpisi5+vyKSL96/4MzUoACmgYMjkK2r8pf1IwgM/EPHDaPUOW+3LWdwcUrjaxo QqiL8uncHAXJ/J8frOuovxWLY7t6bF8aEbd3PPHSTTcfemWOFvPh2UiyYAlvv/HOJ7UU4leAAQDv CGqzCg0KZW5kc3RyZWFtDWVuZG9iag0yMTkgMCBvYmo8PC9PUE0gMS9PUCBmYWxzZS9vcCBmYWxz ZS9UeXBlL0V4dEdTdGF0ZS9TQSBmYWxzZS9TTSAwLjAyPj4NZW5kb2JqDTEgMCBvYmo8PC9GaXJz dCAyIDAgUi9Db3VudCA1L0xhc3QgMyAwIFIvVHlwZS9PdXRsaW5lcz4+DWVuZG9iag0yIDAgb2Jq PDwvUGFyZW50IDEgMCBSL0EgMTEgMCBSL05leHQgNiAwIFIvVGl0bGUo/v8AICk+Pg1lbmRvYmoN MyAwIG9iajw8L0ZpcnN0IDQgMCBSL1BhcmVudCAxIDAgUi9BIDUgMCBSL0NvdW50IDIvTGFzdCA0 IDAgUi9QcmV2IDYgMCBSL1RpdGxlKP7/AGgAdAB0AHAAOgAvAC8AdwB3AHcALgBpAGUAZQBlAC0A aQBuAGYAbwBjAG8AbQAuAG8AcgBnAC8AMgAwADAANwAvKT4+DWVuZG9iag00IDAgb2JqPDwvRmly c3QgOCAwIFIvUGFyZW50IDMgMCBSL0EgOSAwIFIvQ291bnQgMS9MYXN0IDggMCBSL1RpdGxlKP7/ ACApPj4NZW5kb2JqDTUgMCBvYmo8PC9EWzE4NCAwIFIvWFlaIDAgNTk0IG51bGxdL1MvR29Ubz4+ DWVuZG9iag02IDAgb2JqPDwvUGFyZW50IDEgMCBSL0EgNyAwIFIvTmV4dCAzIDAgUi9QcmV2IDIg MCBSL1RpdGxlKP7/AFQAaABlACAAQwBvAG4AZgBlAHIAZQBuAGMAZQAgAG8AbgAgAEMAbwBtAHAA dQB0AGUAcgAgAEMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4Acyk+Pg1lbmRvYmoNNyAwIG9iajw8 L0RbMTg0IDAgUi9YWVogMCA2NTMgbnVsbF0vUy9Hb1RvPj4NZW5kb2JqDTggMCBvYmo8PC9QYXJl bnQgNCAwIFIvQSAxMCAwIFIvVGl0bGUo/v8ASQBtAHAAbwByAHQAYQBuAHQAIABEAGEAdABlAHMA ICk+Pg1lbmRvYmoNOSAwIG9iajw8L0RbMTg0IDAgUi9YWVogMCAxMzQgbnVsbF0vUy9Hb1RvPj4N ZW5kb2JqDTEwIDAgb2JqPDwvRFsxODQgMCBSL1hZWiAwIDE0MCBudWxsXS9TL0dvVG8+Pg1lbmRv YmoNMTEgMCBvYmo8PC9EWzE4NCAwIFIvWFlaIDAgNzI2IG51bGxdL1MvR29Ubz4+DWVuZG9iag0x MiAwIG9iajw8L0ZpcnN0IDgxMy9MZW5ndGggMTU3Mi9GaWx0ZXIvRmxhdGVEZWNvZGUvTiAxMDAv VHlwZS9PYmpTdG0+PnN0cmVhbQ0KeNq0mNtuGzcQhl+FQG/ai2Z5Gh6AwIDtxKmRxDEiF7kQfKFY G0eIrRU2Uhu/fX5ydtdWksZk0V7IY+7y/2Y4M9yTikIKLYVSWmgllFFCa2GVF9oIJQOOWpw0JDTB Rie0E0rbKLSHjZgXoLI4H2FjEAYwa50ASZGUwmhYi+PgEeYb8Fw6D56LJAx43uI4eB58A14Az4AX ohUWvGgNYoKNiA0hSQxwSMsohbUIHJNTCCoEAbTWgAGpdYQuYCkQpZBNVIKwXgsoYaU2jcFL8RF4 BP8EngOMwHPwT+B5OCPwPPwTeAH+CbwA/w68CP8OvAj/TiMF8O8MbHDCWaQCi3VYkgpGOCxRIykO S9ZBCZdSg6S5COuj8EiZRVK9gvVeePAISffgkSfhwXMoik+pw0EPnkfNfEohxB68oMABLwAewIuo J1yZCOcoqZWKBEKxEsEFpBgFFoFgETxCtlopEZBCjcWllBoZRUCKDRafU44xUocyO5FKQuClVBN4 qWQOPJQWp7VASq0HL6aSgIcWsQHxRvACglboERtTV0kQI5alJLIsU99JpF361Iiog4JISRRGITVK olI69aD0+Mcneaph6lIER8antkWVbepjuCeLRKYuJ0p9jgARbPoH5NR2Ckug4FKTgxwBU0gaxZDk qGry/PRp83KuAJTiLZpfskVis1X5+GVzvujb9faib1vBUx4cOWu/bF+2d0I1b7ub9vVikzZdmnJx t2mb2bbfXeV5b7tue3AAf2e7289zmfZkYudDp+ub1bqdfVxAcbK63vVt86zvNseLzTh8s9umKc1s s1g3s937z1f9arMdh5u2f3jg4s0hfsf4nWSLIFaf2m43nkbER92X5tnqr+as628XN81587FdLFfr 61+0NHsjwuj5ernuti0m488J1nE/+nO9bPv7yP7AmtPwEw9Pupub7u92+c1hxHWaAjttTvrFbZsD 2Vs8FsATDg7mQ23QO9kQG8fGswlsYjZG7hkupdFsGGYYZhhmGGYYZhhmGGaZYplimWKZYplimWLd nmGYZZhlGDGMGEYMI4YRw4hhxBRiCjGFmOKY4pjimOKY4pjimOKY4pjimOKY4pnimeKZ4pnimeKZ 4pnimeKZ4pkSmDLsl8CUwJTAlMCUwJTAlMCUwJTIlMiUyJTIlMiUyJTIlMiUGPYMw9LFh+2wiaUe 7LDJpR0sfWPdYP1gw2AHrhq4KnMvsW0P54oTcNm8FLI5H5q0me1t6PPrdPdLJ/JeP8Q9M3vAhWe8 7uAKk+6gg3hvK34n5h6EQ51E3BOPikaPwmSRGUTj7v/n+bZyPu3NL1yJSyL9qBPuOaQNd76cMb4Y QHJ/FfpJaLHMyzRfyVqBKhNM61a6cOFhFOTy8cXvkWX7KapcQkuPOpkEVCtwtQKfBa5cEGoFsVKg c7H5ql0mULUCXSZQk8AUdocbryZ4zCXeGKFmY2hX2eja1wpC4VJoFKT68X3ysT63w+ppvO1fFvoy 4yWRKykHwaujbnn3s7qYXEh+oCgqpDG1AlsroFqBqxX4WkGoFcRKgZW1AlUrKKz01EqWKx1KW8ly oU15RFQrcLUCXysItYJYKSBZK1C1Al0rMLWCwkpPrURcaVfaSsSFtuUR+VpBqBXESoGTtQJVK9C1 AlMrsLUCqhUUVtpPj9eFt2t+F0yCVOkoC+6+evAxH97kXCy8+06r8fyULcsFqlagawWmVmBrBVQn mOMZj99yc3rV9+9X9CP19L7k8dqelNEX1PQ+yrjn7PFlBVkrUIWC8QUo6FoPplZgCwXjU3cgERyX peR1VI27MvhCR5Mg1ApipSDKWoGqFZTUb7ZZXLWHH7ZtL+QTmT9XHt6srtfpO2Tzpnm1uEufMt/1 qy16/3W3bJtX/cV7lh21H7q+nXSnqMR6m4cQPxjNtov+wdkp0PFtYvzCVPlNSf27b0kpKeOHnFl7 tcUa19e/Pj/7/cXRbzm04+5md7t+t1puP36ea3JPpMh/L4czx90OC9HD6MViMzf57Jit7woxfPX6 QTXy1JS7Z+1V1y+2q26dv2TfN/VUgv1Z8N31cyRTDL/Ln1czl+D/rOd/4tlVe/4qwACoN3d+DQpl bmRzdHJlYW0NZW5kb2JqDTEzIDAgb2JqPDwvRmlyc3QgNTQ5L0xlbmd0aCAxMzM2L0ZpbHRlci9G bGF0ZURlY29kZS9OIDYzL1R5cGUvT2JqU3RtL0V4dGVuZHMgMTIgMCBSPj5zdHJlYW0NCnjazFhL b9tIDP4rA+wlOUSeB+choCgQp0WRTbYNYhc9GD64sZIYdaTAcbDNv19yOJL8kuPdbRZ7iEcjkh85 /IacUZTKhRRKS+EtDkoop3HUQgO9NsI4wBGERUWlrbBR7oST9N4LBw7HIFwgeS68QQyDcB7l+Bwk yo0WwaKdMSK3qGdQJh0J0KnyBh8IRZKpJ/ekE8gfzgwBB1SkiIxCZSA9+gHEBJIDvo2RASLbHH8A DRxZUHwukBVieYxcASJ7R1b4FxzOLOrlCuUWQXOLphRtnhOqEVrSmizgQyB4KzRlBh0KrSltGKU2 knAC5i0q50Jbcuqk0C6mVeEDzii/Oih6g8iBQsAMGylJZPGB1o2pQTwK3AtD2ccVCKM9vcmFib68 FAYI0CthLGXVa2SLUosJNR6jU8iBCQF9YZQgiQmEABnfeAEq6gQB2hNgLsDgclWQAgApVagHELx4 9643LH4uPxQ31WKynFXl8OWx6H0tp8ViPiuL3pfe5eSlel5uaJ1V82oxkpkU6W/8/j1CncZ9JsV1 72KUxweRax4MD8CD5cHRMO5dibhVr3uD3qC4WaLL8u7o4+eTT/3jCIvenh/Kb7Pp8v5phKvKKDXN 7zjJz6rncilMmn2aPI48qnhSqFcR0QaPk5vi9HZZLCjwuLDT+eyu7P3+/LSc3b60a/62mC1n5d0f 1bToXS6G39m0X9xWi6KxPcdcoV+afiynK7PBcrJYkUbfFyOinNau44pj3dFoOFuGs2U4WwaSjkuj jyPYNA08TW/TjHGtSjo8DSzM5c6EM3cj2ndRfBHrh+RXsVGw5nDyfV7UNINmmnEzbyl+rhYPk/m2 pt2rOVK8AnZvDnQP7jVQ1YDuCLUFvYgtrZbX2Rn2q+lLzVwiRyV2FNMTs5mg0eC60U5EsLJlKi1T Z5lQy8xZJseygZM8MIGOfTrTulK1qw+NK8ZxDO4Y3KWXDO4YnBkWnsE9g3sO0XOI3u51xT48g3sG 92mTMXhg8MDggcEDgwc2Dxxi8N2u4rmR6OBEo/AyyXwrsrXovLELjdBs2DloRH7LDprtwUSv2Fnd iPJ1u6s5doQHLPFef17d/Gh7R9sLrMwg5PlaPzAOG0S/X/0c0RMeOnkWLJ3AKsPKNWAz58x4s13B Wrs6Q6Bi8abdKh66dU34XTVR9yJILQpaSsFs1gQzKtJ2NaFVhc2NlqqHORF1Ee9U5V4g2J0A6FQ9 gCvQmbRK7+MKwGWA7dG6PMtxhIBvgxrXGbEcsqo7MO+dGJCGXSl0qcu7tvAg32onqTsoJ/dqpdZk oVPrNN5l+IxOB0s6V3RLiNXrqTuNdyNuuco21bep1q8WeHEYLF/mxejoc1UWx0eDaj6bHq9NxkmP LxEjRQc5/42bK0WcdEraEz1BDe9nNz/K4ukpqpmkalbuJdxrY9CwfVB03gnevsi6c7aauoNz1pnA A3JmNu5yfOog5bo5uq3a2hhO1RvD6S61HYtc/X19X3RP/sa+kDv2BTQxu/oMvy8mU+T4N/w42B/8 oQQdtsMPCH6LoLwmqGnTVm4QNFLpJqBce79yrlN/tVScPSQlayW+h9Du2v4nhJpdhH7hGx19A2Bh lkL1rqs/49Nrce/h8rCedCiXZheXBxxNucy0A7XWQ3KbBc1nU3zEG6XO6PPcapV5PG7xo7h28Qs/ 81a6pVvrljG2t2yWnX36X3g+iQd8t28Sv9myT4Ld65zEv5q+t9kJ8N/uhP9nPto6Pi/XzesilfiZ Rv+XsIoMV+pz7z9B/hJgAGC0NAANCmVuZHN0cmVhbQ1lbmRvYmoNMTQgMCBvYmo8PC9OdW1zWzAg MTUgMCBSXT4+DWVuZG9iag0xNSAwIG9iajw8L1MvRD4+DWVuZG9iag0xNiAwIG9iajw8L0NvdW50 IDEvVHlwZS9QYWdlcy9LaWRzWzE4NCAwIFJdPj4NZW5kb2JqDTE3IDAgb2JqPDwvU3VidHlwZS9Y TUwvTGVuZ3RoIDQzNDYvVHlwZS9NZXRhZGF0YT4+c3RyZWFtDQo8P3hwYWNrZXQgYmVnaW49Iu+7 vyIgaWQ9Ilc1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9ImFk b2JlOm5zOm1ldGEvIiB4OnhtcHRrPSIzLjEtNzAxIj4KICAgPHJkZjpSREYgeG1sbnM6cmRmPSJo dHRwOi8vd3d3LnczLm9yZy8xOTk5LzAyLzIyLXJkZi1zeW50YXgtbnMjIj4KICAgICAgPHJkZjpE ZXNjcmlwdGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6cGRmPSJodHRwOi8vbnMu YWRvYmUuY29tL3BkZi8xLjMvIj4KICAgICAgICAgPHBkZjpQcm9kdWNlcj5BY3JvYmF0IERpc3Rp bGxlciA3LjAuNSAoV2luZG93cyk8L3BkZjpQcm9kdWNlcj4KICAgICAgPC9yZGY6RGVzY3JpcHRp b24+CiAgICAgIDxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5z OnBkZng9Imh0dHA6Ly9ucy5hZG9iZS5jb20vcGRmeC8xLjMvIj4KICAgICAgICAgPHBkZng6Q29t cGFueT5VU0MvSVNJPC9wZGZ4OkNvbXBhbnk+CiAgICAgICAgIDxwZGZ4OlNvdXJjZU1vZGlmaWVk PkQ6MjAwNjA1MTExMjExNTk8L3BkZng6U291cmNlTW9kaWZpZWQ+CiAgICAgIDwvcmRmOkRlc2Ny aXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4 bWxuczp4YXA9Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC8iPgogICAgICAgICA8eGFwOkNy ZWF0ZURhdGU+MjAwNi0wNS0xMVQxNToxMjoxOCswMzowMDwveGFwOkNyZWF0ZURhdGU+CiAgICAg ICAgIDx4YXA6Q3JlYXRvclRvb2w+QWNyb2JhdCBQREZNYWtlciA3LjAuNyBmb3IgV29yZDwveGFw OkNyZWF0b3JUb29sPgogICAgICAgICA8eGFwOk1vZGlmeURhdGU+MjAwNi0wNS0xMVQxNToxMjoy MSswMzowMDwveGFwOk1vZGlmeURhdGU+CiAgICAgICAgIDx4YXA6TWV0YWRhdGFEYXRlPjIwMDYt MDUtMTFUMTU6MTI6MjErMDM6MDA8L3hhcDpNZXRhZGF0YURhdGU+CiAgICAgIDwvcmRmOkRlc2Ny aXB0aW9uPgogICAgICA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIgogICAgICAgICAgICB4 bWxuczp4YXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyI+CiAgICAgICAgIDx4 YXBNTTpEb2N1bWVudElEPnV1aWQ6OTMyNDI0OWItMTgwNS00ODE5LWFkNGMtNzIxNTAzM2VmNjdh PC94YXBNTTpEb2N1bWVudElEPgogICAgICAgICA8eGFwTU06SW5zdGFuY2VJRD51dWlkOmU1YzZk YWE3LTRmNWMtNGI1Ni04OTEzLTE2NzRhMGRjZDlmODwveGFwTU06SW5zdGFuY2VJRD4KICAgICAg ICAgPHhhcE1NOlZlcnNpb25JRD4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAg IDxyZGY6bGk+NTwvcmRmOmxpPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwveGFw TU06VmVyc2lvbklEPgogICAgICA8L3JkZjpEZXNjcmlwdGlvbj4KICAgICAgPHJkZjpEZXNjcmlw dGlvbiByZGY6YWJvdXQ9IiIKICAgICAgICAgICAgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9k Yy9lbGVtZW50cy8xLjEvIj4KICAgICAgICAgPGRjOmZvcm1hdD5hcHBsaWNhdGlvbi9wZGY8L2Rj OmZvcm1hdD4KICAgICAgICAgPGRjOnRpdGxlPgogICAgICAgICAgICA8cmRmOkFsdD4KICAgICAg ICAgICAgICAgPHJkZjpsaSB4bWw6bGFuZz0ieC1kZWZhdWx0Ij5DQUxMIEZPUiBQQVBFUlM8L3Jk ZjpsaT4KICAgICAgICAgICAgPC9yZGY6QWx0PgogICAgICAgICA8L2RjOnRpdGxlPgogICAgICAg ICA8ZGM6Y3JlYXRvcj4KICAgICAgICAgICAgPHJkZjpTZXE+CiAgICAgICAgICAgICAgIDxyZGY6 bGk+Sm9lIFRvdWNoPC9yZGY6bGk+CiAgICAgICAgICAgIDwvcmRmOlNlcT4KICAgICAgICAgPC9k YzpjcmVhdG9yPgogICAgICAgICA8ZGM6c3ViamVjdD4KICAgICAgICAgICAgPHJkZjpTZXE+CiAg ICAgICAgICAgICAgIDxyZGY6bGkvPgogICAgICAgICAgICA8L3JkZjpTZXE+CiAgICAgICAgIDwv ZGM6c3ViamVjdD4KICAgICAgPC9yZGY6RGVzY3JpcHRpb24+CiAgICAgIDxyZGY6RGVzY3JpcHRp b24gcmRmOmFib3V0PSIiCiAgICAgICAgICAgIHhtbG5zOnBob3Rvc2hvcD0iaHR0cDovL25zLmFk b2JlLmNvbS9waG90b3Nob3AvMS4wLyI+CiAgICAgICAgIDxwaG90b3Nob3A6aGVhZGxpbmU+CiAg ICAgICAgICAgIDxyZGY6U2VxPgogICAgICAgICAgICAgICA8cmRmOmxpLz4KICAgICAgICAgICAg PC9yZGY6U2VxPgogICAgICAgICA8L3Bob3Rvc2hvcDpoZWFkbGluZT4KICAgICAgPC9yZGY6RGVz Y3JpcHRpb24+CiAgIDwvcmRmOlJERj4KPC94OnhtcG1ldGE+CiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAK ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIAogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIAogICAgICAgICAgICAgICAgICAgICAgICAgICAKPD94cGFja2V0IGVuZD0idyI/Pg0KZW5k c3RyZWFtDWVuZG9iag0xOCAwIG9iajw8L0NyZWF0aW9uRGF0ZShEOjIwMDYwNTExMTUxMjE4KzAz JzAwJykvQXV0aG9yKEpvZSBUb3VjaCkvQ3JlYXRvcihBY3JvYmF0IFBERk1ha2VyIDcuMC43IGZv ciBXb3JkKS9Qcm9kdWNlcihBY3JvYmF0IERpc3RpbGxlciA3LjAuNSBcKFdpbmRvd3NcKSkvTW9k RGF0ZShEOjIwMDYwNTExMTUxMjIxKzAzJzAwJykvQ29tcGFueShVU0MvSVNJKS9Tb3VyY2VNb2Rp ZmllZChEOjIwMDYwNTExMTIxMTU5KS9UaXRsZShDQUxMIEZPUiBQQVBFUlMpPj4NZW5kb2JqDXhy ZWYNCjAgMTgyDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwODk1OTAgMDAwMDAgbg0KMDAwMDA4 OTY1NCAwMDAwMCBuDQowMDAwMDg5NzE4IDAwMDAwIG4NCjAwMDAwODk4NzYgMDAwMDAgbg0KMDAw MDA4OTk1OSAwMDAwMCBuDQowMDAwMDkwMDExIDAwMDAwIG4NCjAwMDAwOTAxNjUgMDAwMDAgbg0K MDAwMDA5MDIxNyAwMDAwMCBuDQowMDAwMDkwMzAwIDAwMDAwIG4NCjAwMDAwOTAzNTIgMDAwMDAg bg0KMDAwMDA5MDQwNSAwMDAwMCBuDQowMDAwMDkwNDU4IDAwMDAwIG4NCjAwMDAwOTIxMjggMDAw MDAgbg0KMDAwMDA5MzU3NiAwMDAwMCBuDQowMDAwMDkzNjExIDAwMDAwIG4NCjAwMDAwOTM2MzUg MDAwMDAgbg0KMDAwMDA5MzY4OCAwMDAwMCBuDQowMDAwMDk4MTExIDAwMDAwIG4NCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1 MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAg NjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAw MDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAw MDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYN CjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1 IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1 NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAw IDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAw MDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQowMDAw MDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBmDQow MDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUzNSBm DQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2NTUz NSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAwMCA2 NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAwMDAw MCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAw MDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAw MDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUgZg0K MDAwMDAwMDAwMCA2NTUzNSBmDQowMDAwMDAwMDAwIDY1NTM1IGYNCjAwMDAwMDAwMDAgNjU1MzUg Zg0KdHJhaWxlcg0KPDwvU2l6ZSAxODI+Pg0Kc3RhcnR4cmVmDQoxMTYNCiUlRU9GDQo= ------=_NextPart_000_02BC_01C69954.D4A7FF00 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ ------=_NextPart_000_02BC_01C69954.D4A7FF00-- From mip4-bounces@ietf.org Thu Jun 29 17:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw44t-0004SE-R4; Thu, 29 Jun 2006 17:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvr5o-0006sh-NY for mip4@ietf.org; Thu, 29 Jun 2006 03:37:40 -0400 Received: from mx0.starentnetworks.com ([12.38.223.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvr5i-0002jp-Ox for mip4@ietf.org; Thu, 29 Jun 2006 03:37:40 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx0.starentnetworks.com (Postfix) with ESMTP id 7C4D890019 for ; Thu, 29 Jun 2006 03:37:31 -0400 (EDT) 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 19799-08 for ; Thu, 29 Jun 2006 03:37:27 -0400 (EDT) Received: from ames.starentnetworks.com (ames.starentnetworks.com [12.33.235.15]) by mx0.starentnetworks.com (Postfix) with ESMTP for ; Thu, 29 Jun 2006 03:37:27 -0400 (EDT) Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by ames.starentnetworks.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Jun 2006 03:34:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Date: Thu, 29 Jun 2006 03:34:19 -0400 Message-ID: <7CCD07160348804497EF29E9EA5560D73C5229@exchtewks2.starentnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails Thread-Index: AcaY/NomEWLUN4TVRMyi+mjOAyudVACUbknw From: "Chowdhury, Kuntal" To: "Sebastian Thalanany" , "Yoshi Tsuda (yotsuda)" X-OriginalArrivalTime: 29 Jun 2006 07:34:19.0835 (UTC) FILETIME=[6EFB38B0:01C69B4E] X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9f087b8cf866276548b66e374926ff59 X-Mailman-Approved-At: Thu, 29 Jun 2006 17:29:33 -0400 Cc: Mobile IPv4 Mailing List , "Venkateshwara Sastry \(vsastry\)" , Avi Lior X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0287830605==" Errors-To: mip4-bounces@ietf.org This is a multi-part message in MIME format. --===============0287830605== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69B4E.6EC0A37D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69B4E.6EC0A37D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "A configurable counter could be maintained at the HA to restrict the number of repeated RRPs with a Code 131 for the same MN. " =20 I agree with this statement. Furthermore, this can be a configuration option in the HA and mip4 protocol need not change to accommodate this. =20 -Kuntal =20 =20 ________________________________ From: Sebastian Thalanany [mailto:sebastn@attglobal.net]=20 Sent: Monday, June 26, 2006 3:48 AM To: Yoshi Tsuda (yotsuda) Cc: Venkateshwara Sastry (vsastry); Avi Lior; Chowdhury, Kuntal; Mobile IPv4 Mailing List Subject: Re: [Mip4] 3344 Sending a Reg Reply when the Authenticator fails =20 Hi Yoshi, Good points in this thread pertaining to the behavior associated with Code 131. A silent discard of the RRP, at the MN, in the case of Code 131 is reasonable to avoid further RRQs that do not contain the MHAE.=20 However, if an RRP containing Code 131 was generated by the HA, it is possible that it is a result of a corruption of the original RRQ, over the wireless link. In this case it is reasonable for the MN to use the receipt of an RRP with Code 131 to trigger a new RRP. A configurable counter could be maintained at the HA to restrict the number of repeated RRPs with a Code 131 for the same MN.=20 Thanks. Regards, Sebastian =20 =20 Yoshi Tsuda (yotsuda) wrote: Hi Sastry, =20 Oh, I see. Thank you for your pointing out the case. Then, I should have written the conditions like the following: a) An MN should stop sending RRQs, a-1) if it receives an RRP with 131, a-2) and if auth check fails, a-3) and if the MN has sent the original RRQ. <- This might be caused due to key differences between an HA and an MN. But, according to the current rfc3344, an MN can continue sending such RRQs. =20 b) An MN can re-send an RRQ, b-1) if the MN receives an RRP with 131, b-2) and if auth check succeeds, b-3) and if the MN has sent the original RRQ. <- This might be caused due to a corrupted RRQ. =20 This kind of description about error handling, other than 69, 133, 136 and so on, isn't so clear in rfc3344, I'm afraid. =20 Best regards. -Yoshi =20 =20 -----Original Message----- From: Venkateshwara Sastry (vsastry)=20 Sent: Monday, June 26, 2006 3:57 PM To: Yoshi Tsuda (yotsuda); 'Avi Lior'; 'Chowdhury, Kuntal' Cc: 'Mobile IPv4 Mailing List' Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 Authenticator fails =20 IMHO, if RRQ authentication failed at HA(may be packet was=20 corrupted when received by HA), and HA HAS a SA with that MN,=20 the HA can send an RRP with MHAE and error code 131. In such=20 a sceanrio, there is a possibility that MN can authenticate=20 the RRP and continue further processing. =20 Regards Sastry =20 =20 -----Original Message----- From: Yoshi Tsuda (yotsuda) Sent: Monday, June 26, 2006 10:31 AM To: Avi Lior; Venkateshwara Sastry (vsastry); Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the Authenticator=20 fails =20 Hi Avi and all, =20 Good point. =20 Personally, I believe, an MN should stop sending RRQs, if it=20 receives an RRP with 131, and if the MN has sent the=20 =20 original RRQ in=20 =20 spite of the meaning of "silently discard". The term, "silently discard" found to be used in rfc2002,=20 =20 too; so it=20 =20 might have a histrical reason, though... =20 Also, I agree with Kuntal that error handlings haven't been well=20 documented. If this causes deployment issues, should we=20 =20 have a new=20 =20 I-D about handling codes or ask modifications of rfc3344 to the=20 inventor of MIP? =20 Thanks. -Yoshi =20 =20 -----Original Message----- From: Avi Lior [mailto:avi@bridgewatersystems.com] Sent: Monday, June 26, 2006 8:38 AM To: Venkateshwara Sastry (vsastry); Chowdhury, Kuntal Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the=20 =20 Authenticator=20 =20 fails =20 I think the protocol does allow an HA to respond with an =20 auth failure. =20 =20 Code 131 was designed for that no? =20 However, as you point out an MN receiving a RRP which fails =20 its auth =20 check MUST silently discard. Silently discard means no more=20 processing. Does that mean that the MN is not allowed to use the=20 receipt of the RRP to stop sending any further RRQs? Some =20 would say =20 yes. =20 Therefore, why allow the HA to send an RRP when clearly=20 =20 the MN will=20 =20 silently discard it? =20 Is this a contradiction or is it by design? =20 =20 =20 =20 =20 ________________________________ =20 From: Venkateshwara Sastry (vsastry) [mailto:vsastry@cisco.com]=20 Sent: Friday, June 23, 2006 4:19 PM To: Chowdhury, Kuntal; Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply when the =20 Authenticator =20 fails =20 =20 We can not really claim that current protocol allows HA =20 to respond on =20 auth failure. If HA responding on auth failure was really the=20 intention of the designers, silently discarding such =20 packets by MN as =20 indicated in following text does not make sense. b) If the Code field indicates that service is =20 denied by the =20 home agent, or if the Code field indicates that the =20 registration =20 was accepted by the home agent, exactly one Mobile-Home Authentication Extension MUST be present in =20 the Registration =20 Reply, and the mobile node MUST check the =20 Authenticator =20 value in the Extension. If the Registration Reply =20 was generated =20 by the home agent but no Mobile-Home =20 Authentication Extension =20 is found, or if more than one Mobile-Home Authentication=20 Extension is found, or if the Authenticator is invalid, =20 the mobile =20 node MUST silently discard the Reply and SHOULD log =20 the event as =20 a security exception. =20 Regards Sastry =20 =20 ________________________________ =20 From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20 Sent: Friday, June 23, 2006 4:56 AM To: Avi Lior Cc: Mobile IPv4 Mailing List Subject: RE: [Mip4] 3344 Sending a Reg Reply =20 when the Authenticator =20 fails =20 =20 =20 Avi, =20 =20 =20 If a rogue MN can break into the network (i.e.=20 pass access auth), anything is possible. However, by =20 putting multiple =20 levels of auth (at least 1 or 2); the operators make this =20 possibility =20 extremely slim. So, let's not get hung-up with the fact =20 that rouge MNs =20 can do bad things. =20 =20 =20 The issue is simple: if the auth of a RRQ =20 fails, should the HA =20 respond back to the MN? There are some people who believe a =20 response =20 should be sent. There are some who believe that the HA =20 should silently =20 discard the packet. =20 =20 =20 In this context, the current mip4 protocol =20 allows the HA to send a =20 response upon auth failure. The current text also allows those HA=20 implementations which like to silently discard the packet. =20 So, let's =20 not change the protocol as it allows both the=20 behaviors/implementations. We can just clarify some text to =20 describe =20 how the response packet is formatted. =20 =20 =20 -Kuntal =20 =20 =20 =20 =20 =20 =20 ------_=_NextPart_001_01C69B4E.6EC0A37D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“A configurable counter could be maintained at = the HA to restrict the number of repeated RRPs with a Code 131 for the same MN. = “

 

I agree with this statement. = Furthermore, this can be a configuration option in the HA and mip4 protocol need not = change to accommodate this.

 

-Kuntal

 

 

From: Sebastian Thalanany [mailto:sebastn@attglobal.net] =
Sent: Monday, June 26, = 2006 3:48 AM
To: Yoshi Tsuda = (yotsuda)
Cc: Venkateshwara Sastry (vsastry); Avi Lior; Chowdhury, Kuntal; Mobile IPv4 Mailing List
Subject: Re: [Mip4] 3344 = Sending a Reg Reply when the Authenticator fails

 

Hi Yoshi,

            =     Good points in this thread pertaining to the behavior associated with Code = 131.

                A = silent discard of the RRP, at the MN, in the case of Code 131 is reasonable to = avoid further RRQs that do not contain the MHAE.

            =     However, if an RRP containing Code 131 was generated by the HA, it is = possible that it is a result of a corruption of the original RRQ, over the = wireless link. In this case it is reasonable for the MN to use the receipt of an = RRP with Code 131 to trigger a new RRP. A configurable counter could be = maintained at the HA to restrict the number of repeated RRPs with a Code 131 for = the same MN.

             =     Thanks.

Regards,
    Sebastian

   

   



Yoshi Tsuda (yotsuda) wrote:

Hi =
Sastry,
 
 Oh, I see.  Thank you for your pointing =
out the case.
 Then, I should have written the conditions =
like the following:
 a) An MN should stop sending =
RRQs,
 a-1) if it receives an RRP with =
131,
 a-2) and if auth check =
fails,
 a-3) and if the MN has sent the original =
RRQ.
 <- This might be caused due to key =
differences between
     an HA and an =
MN.  But, according to the current =
rfc3344,
     an MN can continue =
sending such RRQs.
 
 b) An MN can re-send an =
RRQ,
 b-1) if the MN receives an RRP with =
131,
 b-2) and if auth check =
succeeds,
 b-3) and if the MN has sent the original =
RRQ.
 <- This might be caused due to a =
corrupted RRQ.
 
 This kind of description about error =
handling, other than 69,
 133, 136 and so on, isn't so clear in =
rfc3344, I'm afraid.
 
Best =
regards.
-Yoshi
 
  
-----Original =
Message-----
From: Venkateshwara Sastry (vsastry) =

Sent: Monday, June 26, 2006 3:57 =
PM
To: Yoshi Tsuda (yotsuda); 'Avi Lior'; =
'Chowdhury, Kuntal'
Cc: 'Mobile IPv4 Mailing =
List'
Subject: RE: [Mip4] 3344 Sending a Reg Reply =
when the 
Authenticator =
fails
 
IMHO, if RRQ authentication failed at HA(may =
be packet was 
corrupted when received by HA), and HA HAS a =
SA with that MN, 
the HA can send an RRP with MHAE and error =
code 131. In such 
a sceanrio, there is a possibility that MN =
can authenticate 
the RRP and continue further =
processing.
 
Regards
Sastry
 
    =

-----Original =
Message-----
From: Yoshi Tsuda =
(yotsuda)
Sent: Monday, June 26, 2006 10:31 =
AM
To: Avi Lior; Venkateshwara Sastry (vsastry); =
Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing =
List
Subject: RE: [Mip4] 3344 Sending a Reg Reply =
when the Authenticator 
fails
 
Hi Avi and =
all,
 
 Good =
point.
 
 Personally, I believe, an MN should stop =
sending RRQs,  if it 
receives an RRP with 131, and if the MN has =
sent the 
      
original RRQ in =

    
spite of the meaning of "silently =
discard".
 The term, "silently discard" found =
to be used in rfc2002, 
      
too; so it =

    
might have a histrical reason, =
though...
 
 Also, I agree with Kuntal that error =
handlings haven't been well 
documented.  If this causes deployment =
issues,  should we 
      
have a new =

    
I-D about handling codes or ask  =
modifications of rfc3344 to the =

inventor of =
MIP?
 
Thanks.
-Yoshi
 
      =

-----Original =
Message-----
From: Avi Lior [mailto:avi@bridgewatersystems.=
com]
Sent: Monday, June 26, 2006 8:38 =
AM
To: Venkateshwara Sastry (vsastry); =
Chowdhury, Kuntal
Cc: Mobile IPv4 Mailing =
List
Subject: RE: [Mip4] 3344 Sending a Reg Reply =
when the 
       &nbs=
p;
Authenticator =

    
fails
 
I think the protocol does allow an HA to =
respond with an
        =

auth failure.  =

      
Code 131 was designed for that =
no?
 
However, as you point out an MN receiving a =
RRP which fails
        =

its =
auth
      =

check MUST silently discard.  Silently =
discard means no more 
processing.  Does that mean that the MN =
is not allowed to use the 
receipt of the RRP to stop sending any =
further RRQs?  Some
        =

would =
say
      =

yes.
 
Therefore, why allow the HA to send an RRP =
when clearly 
       &nbs=
p;
the MN will =

    
silently discard =
it?
 
Is this a contradiction or is it by =
design?
 
 
 
 
 
________________________________
 
    From: Venkateshwara Sastry =
(vsastry) [mailto:vsastry@cisco.com] =

    Sent: Friday, June 23, =
2006 4:19 PM
    To: Chowdhury, Kuntal; Avi =
Lior
    Cc: Mobile IPv4 Mailing =
List
    Subject: RE: [Mip4] 3344 =
Sending a Reg Reply when the
        =

Authenticator
      = 
fails
    =

    =

    We can not really claim =
that current protocol allows HA
        =

to respond =
on
      =

auth failure. If HA responding on auth =
failure was really the 
intention of the designers, silently =
discarding such
        =

packets by MN =
as
      =

indicated in following text does not make =
sense.
    =
      b) If the Code field indicates that =
service is
        =

denied by =
the
      =

home
    =
         agent, or if the Code =
field indicates that the
        =

registration
      = 
was
    =
         accepted by the home =
agent, exactly one Mobile-Home
    =
         Authentication =
Extension MUST be present in
        =

the =
Registration
      =

    =
         Reply, and the mobile =
node MUST check the
        =

Authenticator
      = 
value
    =
         in the Extension.  =
If the Registration Reply
        =

was =
generated
      =

by
    =
         the home agent but no =
Mobile-Home
        =

Authentication =
Extension
      =

is
    =
         found, or if more than =
one Mobile-Home Authentication 
Extension
<=
font
size=3D2 color=3D"#3366ff" face=3D"Courier New">    =
         is found, or if the =
Authenticator is invalid,
        =

the =
mobile
      =

node
    =
         MUST silently discard =
the Reply and SHOULD log
 =
       
= 
the event =
as
      =

a
    =
         security =
exception.
    =

    =
Regards
    =
Sastry
 
 
________________________________
 
       &nbs=
p;    From: Chowdhury, =
Kuntal
[mailto:kchowdhury@starentn=
etworks.com] 
       &nbs=
p;    Sent: Friday, June 23, 2006 4:56 =
AM
       &nbs=
p;    To: Avi =
Lior
       &nbs=
p;    Cc: Mobile IPv4 Mailing =
List
       &nbs=
p;    Subject: RE: [Mip4] 3344 Sending a Reg =
Reply
        =

when the =
Authenticator
      =

fails
       &nbs=
p;    
       &nbs=
p;    
 
       &nbs=
p;    Avi,
 
       &nbs=
p;     
 
       &nbs=
p;    If a rogue MN can break into the network (i.e. =

pass access auth), anything is possible. =
However, by
        =

putting =
multiple
      =

levels of auth (at least 1 or 2); the =
operators make this
        =

possibility
      = 
extremely slim. So, let's not get hung-up =
with the fact
        =

that rouge =
MNs
    =
  
can do bad =
things.
 
       &nbs=
p;     
 
       &nbs=
p;    The issue is simple: if the auth of a =
RRQ
        =

fails, should the =
HA
      =

respond back to the MN? There are some people =
who believe a
        =

response
      =

should be sent. There are some who believe =
that the HA
       =
 
should =
silently
      =

discard the =
packet.
 
       &nbs=
p;     
 
       &nbs=
p;    In this context, the current mip4 =
protocol
        =

allows the HA to send =
a
      =

response upon auth failure. The current text =
also allows those HA 
implementations which like to silently =
discard the packet.
        =

So, =
let's
      =

not change the protocol as it allows both the =

behaviors/implementations. We can just =
clarify some text to
        =

describe
      =

how the response packet is =
formatted.
 
       &nbs=
p;     
 
       &nbs=
p;    -Kuntal
 
       &nbs=
p;     
 
 
        =

 
 
------_=_NextPart_001_01C69B4E.6EC0A37D-- --===============0287830605== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0287830605==-- From mip4-bounces@ietf.org Thu Jun 29 21:10:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7Wf-0001Vq-H7; Thu, 29 Jun 2006 21:10:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw7We-0001Vl-H3 for mip4@ietf.org; Thu, 29 Jun 2006 21:10:28 -0400 Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw7Wd-0003g0-33 for mip4@ietf.org; Thu, 29 Jun 2006 21:10:28 -0400 Received: from wee.isi.edu (wee.isi.edu [128.9.168.112]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k5U19Wp05223 for ; Thu, 29 Jun 2006 18:09:32 -0700 (PDT) From: Wei Ye To: mip4@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Thu, 29 Jun 2006 18:09:32 -0700 Message-Id: <1151629772.10346.34.camel@wee.isi.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: weiye@isi.edu Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by boreas.isi.edu id k5U19Wp05223 X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Subject: [Mip4] Deadline extension: ACM Workshop on Underwater Networks (WUWNet 2006) X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mip4-bounces@ietf.org Submission deadline has been extended to July 7, 2006. Our Apologies if you have received multiple copies of the CFP. Volkan Rodoplu and Wei Ye WUWNet 2006 Publicity Co-Chairs ----------------------------------------------------- The First ACM International Workshop on UnderWater Networks (WUWNet 2006) http://wuwnet.engr.uconn.edu/ In conjunction with ACM MobiCom 2006 September 25, 2006 Los Angeles, California, USA Sponsored by ACM SIGMOBILE Technical Co-Sponsorship: IEEE Oceanographic Engineering Society Financial Support Pending From: MIT SeaGrant, Boeing, DARPA, NSF ----------------------------------------------------- Important Dates *************** Submission deadline: July 7, 2006 Acceptance notification: July 28, 2006 Camera-ready version: August 11, 2006 Workshop date: September 25, 2006 Overview & Scope **************** The oceans cover 71% of the earth's surface and represent one of the least explored frontiers, yet the oceans are integral to climate regulation, nutrient production, oil retrieval and transportation. As such, there is significant interest in monitoring aquatic environments for scientific, environmental, commercial, safety, and military reasons. While there is a need for highly precise, real-time, fine grained spatio-temporal sampling of the ocean environment, current methods such as remote telemetry and sequential local sensing cannot satisfy current needs, let alone future needs. The notion of an underwater network is relatively new due to the lack of maturity of underwater acoustic communication. However, networks are necessary in order to achieve the monitoring goals noted above. The physical challenges of acoustic underwater communication require us to completely re-think how a network should be designed and deployed in this environment. Challenges to be overcome by underwater acoustic modem and network designers include: severely limited range-dependent bandwidth and attenuation, extensive time-varying multipath propagation, and low speed of sound propagation in water resulting in long propagation delays. Moreover, a unique feature of underwater networks is that the environment is constantly mobile, naturally causing the node passive mobility. All the above distinct features of underwater networks yield new challenges for every level of the network protocol suite. The goal of the proposed workshop is to bring together researchers and practioners in areas relevant to underwater networks. Thus, many layers of the "stack" from the physical layer to the application layer will be represented. The objective is to serve as a forum for presenting state of the art research, exchanging ideas and experiences, and facilitating interaction and collaboration. The workshop will span one day, including presentations of technical papers, tutorial/survey papers, a panel session and a poster/demo session. Submissions for regular technical papers and poster/demo extended abstracts should describe original research, not published or currently under review for other workshops, conferences, or journals. Topics of interest include, but are not limited to: - Network architecture design - Efficient acoustic communications - Cooperative underwater communications - Medium access control - Routing and forwarding - Reliable data transfer - Security and robustness - Power management - Data storage and management - Localization and synchronization - Data fusion, dissemination, tracking - Network modeling and simulations - Capacity analysis - New techniques for aquatic applications - New applications for underwater networks Submission Guidelines ********************* All paper submissions will be handled electronically. Papers must be in PDF format, no longer than 8 pages for regular papers (10 pages for tutorial/survey papers and 4 pages for poster/demo papers), and must follow ACM single-space, double-column format, 10 pt. Submitted papers will be judged based on their quality and novelty through a rigorous review process. Over-length papers will be automatically rejected. Detailed instructions for paper submission are posted on the workshop website. Organizing Committee ******************** General Co-chairs: Jun-Hong Cui (University of Connecticut) Urbashi Mitra (University of Southern California) Technical Program Co-chairs: Kevin Fall (Intel Research, Berkeley) Milica Stojanovic (MIT/WHOI) Publicity Co-chairs: Volkan Rodoplu (University of California, Santa Barbara) Wei Ye (USC/ISI) Treasurer: Shengli Zhou (University of Connecticut) Publications Chair: Xiuzhen Cheng (George Washington University) Technical Program Committee *************************** Ian Akyildiz (Georgia Institute of Technology) Lee Freitag (Woods Hole Oceanographic Institution) Mario Gerla (University of California, Los Angeles) Jo=C3=A3o Pedro Gomes (Instituto Superior T=C3=A9cnico, Portugal) John Heidemann (USC/ISI) Ronald A. Iltis (University of California, Santa Barbara) Jim Kurose (University of Massachusetts, Amherst) Mehul Motani (National University of Singapore) Joseph A. Rice (Naval Postgraduate School) Daniela Rus (Massachusetts Institute of Technology) Mani Srivastava (University of California, Los Angeles) Yongguang Zhang (Microsoft Research Asia, China) Michele Zorzi (Universita'di Ferrara, Italy) -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ From mip4-bounces@ietf.org Fri Jun 30 05:08:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwEz8-0002hJ-Gz; Fri, 30 Jun 2006 05:08:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwEz7-0002hD-D2 for mip4@ietf.org; Fri, 30 Jun 2006 05:08:21 -0400 Received: from av8-2-sn3.vrr.skanova.net ([81.228.9.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwEz4-0001QI-Uq for mip4@ietf.org; Fri, 30 Jun 2006 05:08:21 -0400 Received: by av8-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 6EBFF383D5; Fri, 30 Jun 2006 11:08:18 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av8-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 5C8503814A for ; Fri, 30 Jun 2006 11:08:18 +0200 (CEST) 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 3498E37E49 for ; Fri, 30 Jun 2006 11:08:18 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FwEz0-0008Q0-PU; Fri, 30 Jun 2006 11:08:17 +0200 Message-ID: <44A4E9FE.6070608@levkowetz.com> Date: Fri, 30 Jun 2006 11:08:14 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: Mobile IPv4 Mailing List X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Subject: [Mip4] MIP4 Agenda for IETF-66 X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1557799331==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1557799331== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0A9340792E0F42D73E2FC596" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0A9340792E0F42D73E2FC596 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, Below you'll find the first take on an agenda for the upcoming meeting. If you want a slot, please send in a request as soon as possible. Regards, Henrik =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 Mobility for IPv4 WG =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 MONDAY, July 10, 2006 1740-1840 Afternoon Session III Room 518AB =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 CHAIRS: Henrik Levkowetz Pete McCann AGENDA: 1. Preliminaries 10 min Chairs - Blue sheets - Note takers - Jabber scribe - Agenda bashing 2. Document Status 15 min Chairs draft-ietf-mip4-rfc3344bis Waiting for a new revision from the editor. Believed ready for writeup and publication request. draft-ietf-mip4-vpn-problem-solution Last call announced 2006-04-24, running to 2006-05-13. Ready for Chair writeup and publication request draft-ietf-mip4-fmipv4 Ready for WGLC. draft-ietf-mip4-gen-ext Ready for WGLC ? draft-ietf-mip4-message-string-ext Last call announced 2006-06-13, running to 2006-06-27 One comment received and discussed, proposed text change exists. draft-ietf-mip4-mobike-connectivity Last call announced 2006-04-14, running to 2006-04-28 Some substantive comments received and discussed. New draft version submitted. A second last call will be issued. draft-ietf-mip4-radius-requirements Ready for WGLC. draft-ietf-mip4-reg-tunnel Submitted for publication draft-ietf-mip4-rfc2006bis New revision finally out :-) Ready for WGLC? draft-ietf-mip4-faerr Approved, in RFC Editor's queue draft-ietf-mip4-rfc3012bis Approved, in RFC Editor's queue draft-ietf-mobileip-lowlatency-handoffs-v4 Approved, in RFC Editor's queue 3. New charter proposals 20 min, Chairs It has been proposed to add IPv6 carrying capability to MIPv4, based on draft-tsirtsis-v4v6-mipv4 . This is now with the IESG for approval. It has also been proposed to standardise some moving network support, based on draft-tsirtsis-nemov4-dynamic and draft-tsirtsis-nemov4-fa . This has not yet gone to the IESG. Comments on this will be entertained. =3D=3D=3D=3D=3D=3D=3D=3D=3D Total time 40 min --------------enig0A9340792E0F42D73E2FC596 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEpOn+eVhrtTJkXCMRAiUSAJ93QU2NjsPQB6ktvLue4ambuWk7HgCdHxiH 2FRYtCfSvHs2BIw+HNx5Prw= =TS6G -----END PGP SIGNATURE----- --------------enig0A9340792E0F42D73E2FC596-- --===============1557799331== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============1557799331==-- From mip4-bounces@ietf.org Fri Jun 30 08:04:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHjz-0008Bt-PX; Fri, 30 Jun 2006 08:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwHjz-0008Bo-BP for mip4@ietf.org; Fri, 30 Jun 2006 08:04:55 -0400 Received: from static-ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwHjw-0006jD-9P for mip4@ietf.org; Fri, 30 Jun 2006 08:04:55 -0400 Received: (qmail 15866 invoked from network); 30 Jun 2006 12:04:32 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk1;74e8c16b398fb940e1d154eba1c5e0cc; Received: from unknown (HELO hitachihk5.hitachi.cn) (170.95.94.1)by static-ip-11-194-65-202.rev.dyxnet.com with SMTP; 30 Jun 2006 12:04:32 -0000 Received: (qmail 12399 invoked from network); 30 Jun 2006 12:04:32 -0000 X-NetworkBox-HamSign: 0101;OUT;hitachihk5;7fdfac040edeed6913425adf9b3b2307; Received: from hchidc204.hitachi-china.com (HELO hchidc204.hitachi.cn) (170.95.82.6)by 172.16.10.9 with SMTP; 30 Jun 2006 12:04:32 -0000 Received: from hcbjdc2.hitachi.cn ([170.95.81.2]) by hchidc204.hitachi.cn with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 20:04:31 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Mip4] MIP4 Agenda for IETF-66 Date: Fri, 30 Jun 2006 20:04:29 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3801923530@hcbjdc2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Mip4] MIP4 Agenda for IETF-66 Thread-Index: AcacJQOW0j4lgg7EQq+hv6iSsZgxUgAGAzDm From: "DENG, HUI -HCHBJ" To: "Henrik Levkowetz" , "Mobile IPv4 Mailing List" X-OriginalArrivalTime: 30 Jun 2006 12:04:31.0118 (UTC) FILETIME=[581272E0:01C69C3D] X-Scanned-By-hitachihk5: Virus scan performed by network-box X-Scanned-By-hitachihk5: Scanner file id is hitachihk5-1151669072.357-12396-000 X-Scanned-By-hitachihk5: No known viruses found in message (received+scanned in 0.02/0.05 secs) X-Scanned-By-hitachihk5: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Spam-Status: No X-Scanned-By-hitachihk1: Virus scan performed by network-box X-Scanned-By-hitachihk1: Scanner file id is hitachihk1-1151669072.670-15861-000 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 0.01/0.02 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=0 required=7 tests= autolearn=no version=2.0 X-Scanned-By-hitachihk1: Whitelisted with valid signature (outbound via Network Box hitachihk5) X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0369778544==" Errors-To: mip4-bounces@ietf.org --===============0369778544== content-class: urn:content-classes:message Content-Type: text/plain;charset="utf-8" Content-Transfer-Encoding: base64 SGksIEhlbnJpaw0KIA0KSWYgcG9zc2libGUsIHdlIHdvdWxkIGxpa2UgdG8gcHJlc2VudCB0aGUg dXBkYXRlZCBkcmFmdCwgDQpNYW55IHRoYW5rcyBmb3IgeW91ciBoZWxwDQogDQotSHVpDQogDQog ICAgIFRpdGxlICAgICAgICAgICA6IEdlbmVyaWMgTm90aWZpY2F0aW9uIE1lc3NhZ2UgZm9yIE1v YmlsZSBJUHY0DQogICAgICAgIEF1dGhvcihzKSAgICAgICA6IEguIERlbmcsIGV0IGFsLg0KICAg ICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1kZW5nLW1pcDQtZ2VuZXJpYy1ub3RpZmljYXRp b24tbWVzc2FnZS0wMi50eHQNCiAgICAgICAgUGFnZXMgICAgICAgICAgIDogMjMNCiAgICAgICAg RGF0ZSAgICAgICAgICAgIDogMjAwNi02LTI2DQogICAgICAgDQpUaGlzIGRvY3VtZW50IHNwZWNp ZmllcyBwcm90b2NvbCBlbmhhbmNlbWVudHMgdGhhdCBhbGxvdyBNb2JpbGUgSVB2NA0KZW50aXRp ZXMgdG8gc2VuZCBhbmQgcmVjZWl2ZSBleHBsaWNpdCBub3RpZmljYXRpb24gbWVzc2FnZXMgdXNp bmcgYQ0KbmV3IE1vYmlsZSBJUHY0IHR5cGUgZGVzaWduZWQgZm9yIHRoaXMgcHVycG9zZS4NCg0K QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2lu dGVybmV0LWRyYWZ0cy9kcmFmdC1kZW5nLW1pcDQtZ2VuZXJpYy1ub3RpZmljYXRpb24tbWVzc2Fn ZS0wMi50eHQNCg0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJRnJvbTogSGVucmlr IExldmtvd2V0eiBbbWFpbHRvOmhlbnJpa0BsZXZrb3dldHouY29tXSANCglTZW50OiAyMDA2LTYt MzAgKOaYn+acn+S6lCkgMTc6MDggDQoJVG86IE1vYmlsZSBJUHY0IE1haWxpbmcgTGlzdCANCglD YzogDQoJU3ViamVjdDogW01pcDRdIE1JUDQgQWdlbmRhIGZvciBJRVRGLTY2DQoJDQoJDQoNCglI aSwNCgkNCglCZWxvdyB5b3UnbGwgZmluZCB0aGUgZmlyc3QgdGFrZSBvbiBhbiBhZ2VuZGEgZm9y IHRoZSB1cGNvbWluZyBtZWV0aW5nLg0KCQ0KCUlmIHlvdSB3YW50IGEgc2xvdCwgcGxlYXNlIHNl bmQgaW4gYSByZXF1ZXN0IGFzIHNvb24gYXMgcG9zc2libGUuDQoJDQoJDQoJUmVnYXJkcywNCgkN CgkgICAgICAgIEhlbnJpaw0KCQ0KCT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoJICAgICAgICAgICAgICAgICAg ICAgICAgICAgTW9iaWxpdHkgZm9yIElQdjQgV0cNCgk9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KCQ0KCU1PTkRB WSwgSnVseSAxMCwgMjAwNg0KCTE3NDAtMTg0MCBBZnRlcm5vb24gU2Vzc2lvbiBJSUkNCglSb29t IDUxOEFCDQoJPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCgkNCglDSEFJUlM6IEhlbnJpayBMZXZrb3dldHogPGhl bnJpa0BsZXZrb3dldHouY29tPg0KCSAgICAgICAgUGV0ZSBNY0Nhbm4gPG1jY2FwQHBldHJvbmku b3JnPg0KCQ0KCUFHRU5EQToNCgkNCgkxLiBQcmVsaW1pbmFyaWVzICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDEwIG1pbiBDaGFpcnMNCgkgICAtIEJsdWUgc2hlZXRzDQoJ ICAgLSBOb3RlIHRha2Vycw0KCSAgIC0gSmFiYmVyIHNjcmliZQ0KCSAgIC0gQWdlbmRhIGJhc2hp bmcNCgkNCgkyLiBEb2N1bWVudCBTdGF0dXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIDE1IG1pbiBDaGFpcnMNCgkNCgkgICAgZHJhZnQtaWV0Zi1taXA0LXJmYzMzNDRiaXMN CgkgICAgICAgIFdhaXRpbmcgZm9yIGEgbmV3IHJldmlzaW9uIGZyb20gdGhlIGVkaXRvci4NCgkg ICAgICAgIEJlbGlldmVkIHJlYWR5IGZvciB3cml0ZXVwIGFuZCBwdWJsaWNhdGlvbiByZXF1ZXN0 Lg0KCQ0KCSAgICBkcmFmdC1pZXRmLW1pcDQtdnBuLXByb2JsZW0tc29sdXRpb24NCgkgICAgICAg IExhc3QgY2FsbCBhbm5vdW5jZWQgMjAwNi0wNC0yNCwgcnVubmluZyB0byAyMDA2LTA1LTEzLg0K CSAgICAgICAgUmVhZHkgZm9yIENoYWlyIHdyaXRldXAgYW5kIHB1YmxpY2F0aW9uIHJlcXVlc3QN CgkNCgkgICAgZHJhZnQtaWV0Zi1taXA0LWZtaXB2NA0KCSAgICAgICAgUmVhZHkgZm9yIFdHTEMu DQoJDQoJICAgIGRyYWZ0LWlldGYtbWlwNC1nZW4tZXh0DQoJICAgICAgICBSZWFkeSBmb3IgV0dM QyA/DQoJDQoJICAgIGRyYWZ0LWlldGYtbWlwNC1tZXNzYWdlLXN0cmluZy1leHQNCgkgICAgICAg IExhc3QgY2FsbCBhbm5vdW5jZWQgMjAwNi0wNi0xMywgcnVubmluZyB0byAyMDA2LTA2LTI3DQoJ ICAgICAgICBPbmUgY29tbWVudCByZWNlaXZlZCBhbmQgZGlzY3Vzc2VkLCBwcm9wb3NlZCB0ZXh0 DQoJICAgICAgICBjaGFuZ2UgZXhpc3RzLg0KCQ0KCSAgICBkcmFmdC1pZXRmLW1pcDQtbW9iaWtl LWNvbm5lY3Rpdml0eQ0KCSAgICAgICAgTGFzdCBjYWxsIGFubm91bmNlZCAyMDA2LTA0LTE0LCBy dW5uaW5nIHRvIDIwMDYtMDQtMjgNCgkgICAgICAgIFNvbWUgc3Vic3RhbnRpdmUgY29tbWVudHMg cmVjZWl2ZWQgYW5kIGRpc2N1c3NlZC4NCgkgICAgICAgIE5ldyBkcmFmdCB2ZXJzaW9uIHN1Ym1p dHRlZC4NCgkgICAgICAgIEEgc2Vjb25kIGxhc3QgY2FsbCB3aWxsIGJlIGlzc3VlZC4NCgkNCgkg ICAgZHJhZnQtaWV0Zi1taXA0LXJhZGl1cy1yZXF1aXJlbWVudHMNCgkgICAgICAgIFJlYWR5IGZv ciBXR0xDLg0KCQ0KCSAgICBkcmFmdC1pZXRmLW1pcDQtcmVnLXR1bm5lbA0KCSAgICAgICAgU3Vi bWl0dGVkIGZvciBwdWJsaWNhdGlvbg0KCQ0KCSAgICBkcmFmdC1pZXRmLW1pcDQtcmZjMjAwNmJp cw0KCSAgICAgICAgTmV3IHJldmlzaW9uIGZpbmFsbHkgb3V0IDotKQ0KCSAgICAgICAgUmVhZHkg Zm9yIFdHTEM/DQoJDQoJICAgIGRyYWZ0LWlldGYtbWlwNC1mYWVycg0KCSAgICAgICAgQXBwcm92 ZWQsIGluIFJGQyBFZGl0b3IncyBxdWV1ZQ0KCQ0KCSAgICBkcmFmdC1pZXRmLW1pcDQtcmZjMzAx MmJpcw0KCSAgICAgICAgQXBwcm92ZWQsIGluIFJGQyBFZGl0b3IncyBxdWV1ZQ0KCQ0KCSAgICBk cmFmdC1pZXRmLW1vYmlsZWlwLWxvd2xhdGVuY3ktaGFuZG9mZnMtdjQNCgkgICAgICAgIEFwcHJv dmVkLCBpbiBSRkMgRWRpdG9yJ3MgcXVldWUNCgkNCgkzLiBOZXcgY2hhcnRlciBwcm9wb3NhbHMg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIwIG1pbiwgQ2hhaXJzDQoJICAgIEl0IGhh cyBiZWVuIHByb3Bvc2VkIHRvIGFkZCBJUHY2IGNhcnJ5aW5nIGNhcGFiaWxpdHkgdG8gTUlQdjQs DQoJICAgIGJhc2VkIG9uIGRyYWZ0LXRzaXJ0c2lzLXY0djYtbWlwdjQgLiAgVGhpcyBpcyBub3cg d2l0aCB0aGUNCgkgICAgSUVTRyBmb3IgYXBwcm92YWwuDQoJDQoJICAgIEl0IGhhcyBhbHNvIGJl ZW4gcHJvcG9zZWQgdG8gc3RhbmRhcmRpc2Ugc29tZSBtb3ZpbmcgbmV0d29yaw0KCSAgICBzdXBw b3J0LCBiYXNlZCBvbiBkcmFmdC10c2lydHNpcy1uZW1vdjQtZHluYW1pYyBhbmQNCgkgICAgZHJh ZnQtdHNpcnRzaXMtbmVtb3Y0LWZhIC4gIFRoaXMgaGFzIG5vdCB5ZXQgZ29uZSB0byB0aGUgSUVT Ry4NCgkNCgkgICAgQ29tbWVudHMgb24gdGhpcyB3aWxsIGJlIGVudGVydGFpbmVkLg0KCQ0KCSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPT09 PT09PT09DQoJICAgIFRvdGFsIHRpbWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA0MCBtaW4NCgkNCgkNCgkNCg0K Disclaimer: The contents of this e-mail, and its attachments, if any, are confidential and may be protected by law against any unauthorized use. If you have received this e-mail by mistake or have reason to believe that you are not the intended recipient, please notify the sender by reply e-mail as soon as possible and delete it from your computer system immediately thereafter. If you are not the intended recipient, you must not copy this e-mail or attachment or disclose the contents to any other person. While we have made every effort to keep our network virus free, we take no responsibility for any computer virus which might be transferred by way of this e-mail. --===============0369778544== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0369778544==-- From mip4-bounces@ietf.org Fri Jun 30 09:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJVw-00085F-SS; Fri, 30 Jun 2006 09:58:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwJVv-000859-8K for mip4@ietf.org; Fri, 30 Jun 2006 09:58:31 -0400 Received: from av10-1-sn2.hy.skanova.net ([81.228.8.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwJVu-0001Fp-Kn for mip4@ietf.org; Fri, 30 Jun 2006 09:58:31 -0400 Received: by av10-1-sn2.hy.skanova.net (Postfix, from userid 502) id C204D37EC5; Fri, 30 Jun 2006 15:58:29 +0200 (CEST) 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 AA2EE37EC5; Fri, 30 Jun 2006 15:58:29 +0200 (CEST) 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 5074E37E4B; Fri, 30 Jun 2006 15:57:49 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.62) (envelope-from ) id 1FwJV6-0008Or-0K; Fri, 30 Jun 2006 15:57:48 +0200 Message-ID: <44A52DD3.3090308@levkowetz.com> Date: Fri, 30 Jun 2006 15:57:39 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060530) MIME-Version: 1.0 To: "DENG, HUI -HCHBJ" Subject: Re: [Mip4] MIP4 Agenda for IETF-66 References: <834B54D356AA8F46B9B233DD88BEAA3801923530@hcbjdc2> In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA3801923530@hcbjdc2> X-Enigmail-Version: 0.94.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Cc: Mobile IPv4 Mailing List X-BeenThere: mip4@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility for IPv4 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0815263629==" Errors-To: mip4-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0815263629== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD529D4BF1BF06BE603E9982D" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD529D4BF1BF06BE603E9982D Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Hui, on 2006-06-30 14:04 DENG, HUI -HCHBJ said the following: > Hi, Henrik > =20 > If possible, we would like to present the updated draft,=20 > Many thanks for your help Ok, I've added an item to the agenda for this. Best, Henrik > -Hui > =20 > Title : Generic Notification Message for Mobile IPv4 > Author(s) : H. Deng, et al. > Filename : draft-deng-mip4-generic-notification-message-= 02.txt > Pages : 23 > Date : 2006-6-26 > =20 > This document specifies protocol enhancements that allow Mobile IPv4 > entities to send and receive explicit notification messages using a > new Mobile IPv4 type designed for this purpose. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-deng-mip4-generic-notificatio= n-message-02.txt >=20 >=20 > -----Original Message-----=20 > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: 2006-6-30 (=E6=98=9F=E6=9C=9F=E4=BA=94) 17:08=20 > To: Mobile IPv4 Mailing List=20 > Cc:=20 > Subject: [Mip4] MIP4 Agenda for IETF-66 > =09 > =09 >=20 > Hi, > =09 > Below you'll find the first take on an agenda for the upcoming meeting= =2E > =09 > If you want a slot, please send in a request as soon as possible. > =09 > =09 > Regards, > =09 > Henrik > =09 > =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 > Mobility for IPv4 WG > =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 > =09 > MONDAY, July 10, 2006 > 1740-1840 Afternoon Session III > Room 518AB > =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 > =09 > CHAIRS: Henrik Levkowetz > Pete McCann > =09 > AGENDA: > =09 > 1. Preliminaries 10 min Chairs > - Blue sheets > - Note takers > - Jabber scribe > - Agenda bashing > =09 > 2. Document Status 15 min Chairs > =09 > draft-ietf-mip4-rfc3344bis > Waiting for a new revision from the editor. > Believed ready for writeup and publication request. > =09 > draft-ietf-mip4-vpn-problem-solution > Last call announced 2006-04-24, running to 2006-05-13. > Ready for Chair writeup and publication request > =09 > draft-ietf-mip4-fmipv4 > Ready for WGLC. > =09 > draft-ietf-mip4-gen-ext > Ready for WGLC ? > =09 > draft-ietf-mip4-message-string-ext > Last call announced 2006-06-13, running to 2006-06-27 > One comment received and discussed, proposed text > change exists. > =09 > draft-ietf-mip4-mobike-connectivity > Last call announced 2006-04-14, running to 2006-04-28 > Some substantive comments received and discussed. > New draft version submitted. > A second last call will be issued. > =09 > draft-ietf-mip4-radius-requirements > Ready for WGLC. > =09 > draft-ietf-mip4-reg-tunnel > Submitted for publication > =09 > draft-ietf-mip4-rfc2006bis > New revision finally out :-) > Ready for WGLC? > =09 > draft-ietf-mip4-faerr > Approved, in RFC Editor's queue > =09 > draft-ietf-mip4-rfc3012bis > Approved, in RFC Editor's queue > =09 > draft-ietf-mobileip-lowlatency-handoffs-v4 > Approved, in RFC Editor's queue > =09 > 3. New charter proposals 20 min, Chairs= > It has been proposed to add IPv6 carrying capability to MIPv4, > based on draft-tsirtsis-v4v6-mipv4 . This is now with the > IESG for approval. > =09 > It has also been proposed to standardise some moving network > support, based on draft-tsirtsis-nemov4-dynamic and > draft-tsirtsis-nemov4-fa . This has not yet gone to the IESG. > =09 > Comments on this will be entertained. > =09 > =3D=3D=3D=3D=3D= =3D=3D=3D=3D > Total time 40 min > =09 > =09 > =09 >=20 > =0E+=1C=EF=BF=BD=EF=BF=BD=EF=BF=BDz=EF=BF=BD=EF=BF=BDy=EF=BF=BD'=EF=BF=BD= =EF=BF=BD=EF=BF=BD=EF=BF=BD+=1E=EF=BF=BD=EF=BF=BD=EF=BF=BDjwb=EF=BF=BD=C6= =AD=EF=BF=BD=EF=BF=BD!=EF=BF=BD=EF=BF=BD=EF=BF=BD'=DA=9F&=EF=BF=BDy=EF=BF= =BD'~'^=EF=BF=BD=D8=9A=EF=BF=BD=EF=BF=BD=DD=99=EF=BF=BD=EF=BF=BDz=EF=BF=BD= =EF=BF=BD=EF=BF=BD-y=EF=BF=BD=EF=BF=BD=1A=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF= =BD=D6=A7=EF=BF=BD=EF=BF=BD=DA=BA=EF=BF=BDh=EF=BF=BD,=EF=BF=BDv=EF=BF=BD=1E= !=EF=BF=BD=16=EF=BF=BDz=EF=BF=BD=EF=BF=BDz+=EF=BF=BDv=EF=BF=BDb=EF=BF=BD=E9= =9A=8AV=EF=BF=BD+-jG=EF=BF=BD=EF=BF=BD=16=EF=BF=BDz=EF=BF=BD=EF=BF=BD=EF=BF= =BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=DE=B6=16=EF=BF=BD=CA=8B=EF= =BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD^=EF=BF=BD{^=EF=BF=BD=D7=9D=EF=BF= =BD=EF=BF=BD"=EF=BF=BD'=EF=BF=BD=EF=BF=BD=EF=BF=BD^j=C7=A7=EF=BF=BD=D8=9F= =EF=BF=BD=EF=BF=BD^=EF=BF=BD=EF=BF=BD=EF=BF=BDz=EF=BF=BD=EF=BF=BD=EF=BF=BD= e=EF=BF=BD=E9=9A=8AV=EF=BF=BD=EF=BF=BD=EF=BF=BD'j=EF=BF=BDh=EF=BF=BD=C8=9B= =EF=BF=BD=EF=BF=BDu=D7=A5z=D7=A2=EF=BF=BD=EF=BF=BD=EF=BF=BD*.=EF=BF=BD=EF= =BF=BD&=EF=BF=BD=EF=BF=BD^=EF=BF=BD=CC=AC=EF=BF=BD=E9=A2=9Ag=EF=BF=BD=EF=BF= =BD=EF=BF=BD^=EF=BF=BD+az=EF=BF=BD=EF=BF=BD~=D7=AB!=EF=BF=BD=DE=9E=EF=BF=BD= m=EF=BF=BD=E8=A7=B5=EF=BF=BD=EF=BF=BDy=EF=BF=BD=EF=BF=BDr*bz{r=EF=BF=BD=E9= =AE=B2=EF=BF=BD=EF=BF=BD=EF=BF=BD)=EF=BF=BD=EF=BF=BDb=EF=BF=BD=E9=9A=8AZ+= j=EF=BF=BDZr=19=EF=BF=BD=EF=BF=BD=EF=BF=BD+v+=1C=EF=BF=BD=EF=BF=BD=1E=EF=BF= =BD=17=EF=BF=BD=EF=BF=BD{^=EF=BF=BD=EF=BF=BD-=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF= =BF=BD^=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=D6=86)^=EF=BF=BD=EF=BF= =BDZ=EF=BF=BD=EF=BF=BDu=EF=BF=BDz=EF=BF=BD=EF=BF=BD}=EF=BF=BD+=EF=BF=BD=EF= =BF=BD$y=EF=BF=BDh=EF=BF=BD=EF=BF=BD=DE=B7 > +=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BDy=EF=BF=BD=1E=EF=BF=BD=EF=BF=BD=1E= =EF=BF=BD=EF=BF=BD=DE=B2=EF=BF=BD'=EF=BF=BD&=EF=BF=BD+r~=EF=BF=BD=DA=9F'(= =EF=BF=BD=EF=BF=BD=EF=BF=BDz=EF=BF=BD=EF=BF=BD=EF=BF=BD0=EF=BF=BD'!=EF=BF= =BD(!=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD}=EF=BF=BD=EF=BF= =BDy=EF=BF=BD=EF=BF=BD=EF=BF=BD=EF=BF=BD~=EF=BF=BDb=EF=BF=BD >=20 --------------enigD529D4BF1BF06BE603E9982D Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iD8DBQFEpS3TeVhrtTJkXCMRArU3AKDbi/oOOGQSCjFPSzYPYa4i+MYxCgCffTOU pXI5viZhYK6xCBDPkBV9SNY= =HjN2 -----END PGP SIGNATURE----- --------------enigD529D4BF1BF06BE603E9982D-- --===============0815263629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Mip4 mailing list: Mip4@ietf.org Web interface: https://www1.ietf.org/mailman/listinfo/mip4 Charter page: http://www.ietf.org/html.charters/mip4-charter.html Supplemental site: http://www.mip4.org/ --===============0815263629==--