From mip6-bounces@ietf.org Tue Feb 1 00:52:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28411 for ; Tue, 1 Feb 2005 00:52:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvrFo-0006t1-2N for mip6-web-archive@ietf.org; Tue, 01 Feb 2005 01:11:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvqjd-0007LD-Mi; Tue, 01 Feb 2005 00:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvqfq-0006bV-1j for mip6@megatron.ietf.org; Tue, 01 Feb 2005 00:34:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26133 for ; Tue, 1 Feb 2005 00:33:59 -0500 (EST) Received: from szxga02-in.huawei.com ([61.144.161.54] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvqx6-0006HZ-1D for mip6@ietf.org; Tue, 01 Feb 2005 00:52:44 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB700BXJWSDHS@szxga02-in.huawei.com> for mip6@ietf.org; Tue, 01 Feb 2005 13:33:49 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB700HF2WSD3J@szxga02-in.huawei.com> for mip6@ietf.org; Tue, 01 Feb 2005 13:33:49 +0800 (CST) Received: from sachin ([10.18.4.129]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB700LLJWWQP1@szxml01-in.huawei.com> for mip6@ietf.org; Tue, 01 Feb 2005 13:36:27 +0800 (CST) Date: Tue, 01 Feb 2005 11:02:00 +0530 From: Sachin D To: mip6@ietf.org Message-id: <000001c5081f$5b8ef0f0$8104120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Subject: [Mip6] Regarding RAND_ADV_DELAY need to be added X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sachind@huawei.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0555589256==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 This is a multi-part message in MIME format. --===============0555589256== Content-type: multipart/alternative; boundary="Boundary_(ID_QLDhD3VyfOHlps1E0Hxgkg)" This is a multi-part message in MIME format. --Boundary_(ID_QLDhD3VyfOHlps1E0Hxgkg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi All, I wanted to clarify that if I am getting something wrong or there is some issue with the calculation of RAND ADV DELAY value as specified by RFC Whenever prefix is added or other cases we are randomizing the PA sending by following values "MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime), where MaxMobPfxAdvInterval is as defined in Section 12. Then compute the final delay for the advertisement: RAND_ADV_DELAY = MinMobPfxAdvInterval + (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval)) " Now according to the values the minimum possible interval it can have is 10 MIN and worst this will give is of 1 Day = 86400 second. In Most cases this will normally be in HOURS. So are we trying to add some random delay in hours ??? Regards, Sachin --Boundary_(ID_QLDhD3VyfOHlps1E0Hxgkg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi All,

 

I wanted to clarify that if I am getting something wrong or there is some issue with the calculation of RAND ADV DELAY value as specified by RFC

 

Whenever prefix is added or other cases we are randomizing the PA sending by following values

 

“MaxScheduleDelay = min (MaxMobPfxAdvInterval, Preferred Lifetime),

 

   where MaxMobPfxAdvInterval is as defined in Section 12.  Then compute

   the final delay for the advertisement:

 

      RAND_ADV_DELAY = MinMobPfxAdvInterval +

            (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))

“

 

Now according to the values the minimum possible interval it can have is 10 MIN and worst this will give is of 1 Day = 86400 second. In Most cases this will normally be in HOURS. So are we trying to add some random delay in hours ???

 

 

Regards,

Sachin

 

 

 

 

--Boundary_(ID_QLDhD3VyfOHlps1E0Hxgkg)-- --===============0555589256== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0555589256==-- From mip6-bounces@ietf.org Wed Feb 2 03:00:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12808 for ; Wed, 2 Feb 2005 03:00:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFj3-0007JO-M8 for mip6-web-archive@ietf.org; Wed, 02 Feb 2005 03:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwFGQ-0001oj-Ta; Wed, 02 Feb 2005 02:49:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwFFA-0001V8-RP for mip6@megatron.ietf.org; Wed, 02 Feb 2005 02:48:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11314 for ; Wed, 2 Feb 2005 02:48:06 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwFXQ-0006xm-Lt for mip6@ietf.org; Wed, 02 Feb 2005 03:07:03 -0500 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 <0IB900CPNXG2QW@szxga01-in.huawei.com> for mip6@ietf.org; Wed, 02 Feb 2005 15:43:15 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IB900CLJXG2AW@szxga01-in.huawei.com> for mip6@ietf.org; Wed, 02 Feb 2005 15:43:14 +0800 (CST) Received: from sachin ([10.18.4.129]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IB900JPPXGYG6@szxml02-in.huawei.com> for mip6@ietf.org; Wed, 02 Feb 2005 15:43:48 +0800 (CST) Date: Wed, 02 Feb 2005 13:12:00 +0530 From: Sachin D To: mip6@ietf.org Message-id: <000001c508fa$aeb1eef0$8104120a@in.huawei.com> Organization: Huawei Technologies MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Subject: [Mip6] Regarding L Bit settings of BU X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sachind@huawei.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0800853204==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 This is a multi-part message in MIME format. --===============0800853204== Content-type: multipart/alternative; boundary="Boundary_(ID_UcEbmHCUxrk9uLtEVBSGIg)" This is a multi-part message in MIME format. --Boundary_(ID_UcEbmHCUxrk9uLtEVBSGIg) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi All , I wanted to clarify the behavior of Home Agent in the following scenario (though MN should not be doing this but what if HA receives) First HA receives BU Add request from an MN without L bit set. Here it will only do DAD for its global address and will act proxy only for global address Now for some reason MN sends BU with L bit set so what should be behavior of HA in such a scenario because RFC only says "Unless this home agent already has a binding for the given home address, the home agent MUST perform Duplicate Address Detection [13] on the mobile node's home link before returning the Binding Acknowledgement. " So now HA will update its flag here and will not do DAD for link local address. So in such a case though binding entry state in HA is defending link local address but actually it is not acting as proxy for that address and that address can be configured by any node on the network Can someone suggest how this second BU update request should be treated? Also what should be behavior in reverse case i.e when initially BU had L bit sent and in update request L bit was not should HA leave the solicited node multicast address for that link local address ? Regards Sachin --Boundary_(ID_UcEbmHCUxrk9uLtEVBSGIg) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi All ,

 

I wanted to clarify the behavior of Home Agent in the following scenario (though MN should not be doing this but what if HA receives)

 

First HA receives BU Add request from an MN without L bit set.

 

Here it will only do DAD for its global address and will act proxy only for global address

 

 

Now for some reason MN sends BU with L bit set so what should be behavior of HA in such a scenario because RFC only says

 

 

“Unless this home agent already has a binding for the given home

address, the home agent MUST perform Duplicate Address Detection [13]

on the mobile node's home link before returning the Binding

Acknowledgement.  “

 

So now HA will update its flag here and will not do DAD for link local address. So in such a case though binding entry state in HA is defending link local address but actually it is not acting as proxy for that address and that address can be configured by any node on the network

 

Can someone suggest how this second BU update request should be treated?

 

Also what should be behavior in reverse case i.e when initially BU had L bit sent and in update request L bit was not should HA leave the solicited node multicast address for that link local address ?

 

Regards

Sachin

 

 

--Boundary_(ID_UcEbmHCUxrk9uLtEVBSGIg)-- --===============0800853204== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0800853204==-- From oqihjj@o2.pl Wed Feb 2 03:14:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14193; Wed, 2 Feb 2005 03:14:44 -0500 (EST) Received: from [211.199.43.120] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwFxE-0007bn-Nu; Wed, 02 Feb 2005 03:33:42 -0500 Received: from symphony-62.iinet.net.au ([146.74.224.64]:1906 "HELO mail.ies.edu") by ies.edu with SMTP id ; Wed, 02 Feb 2005 14:12:36 +0600 Date: Wed, 02 Feb 2005 07:09:36 -0100 Message-Id: <9.2.35.2081924.0083fc70@ies.edu> From: "Aurora West" To: Subject: The cheapest you will find anywhere X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 9.3 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit meme only . septacro resorcinol cattail. sanctify throttle scuffle dentistry glenn simplicity cumberland egipt. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit adverse pompon
You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web
Guaranteed.
 
 
 
 
 
 
.
.
.
http://www.193.blueriseny.com/ You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web Guaranteed.
.  
   
NOMORE ------------A85031401794097-- ------------A48356845382213 Content-Type: image/jpeg; name="dreary.JPG" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAACQAA/+4AIUFkb2JlAGTAAAAAAQMA EAMCAwYAAAtUAAAZrAAANLH/2wCEABQRERoTGioZGSo1KCEoNTEpKCgpMUE4ODg4OEFERERERERE REREREREREREREREREREREREREREREREREREREQBFhoaIh0iKRoaKTkpIik5RDktLTlEREREOERE RERERERERERERERERERERERERERERERERERERERERERERERERP/CABEIAQUBkAMBIgACEQEDEQH/ xADOAAABBQEBAAAAAAAAAAAAAAADAAECBAUGBwEAAwEBAQAAAAAAAAAAAAAAAAECAwQFEAACAgIB BAEDBQEAAwEBAAABAgADEQQFECESEzEgFCUwMhUGFiJBMzRANREAAgECAwMIBAsHAwUBAQAAAQIR AAMhMRJBURMQIGFxgSIyBJGhQqIw8LHB0VKS4iMzQ+FicoLC0hTxsgVTY3MkNEAVEgABAgMGBQQB BQEAAAAAAAAAAREhMUEQIDBAgbFRoQISQvBhcSLBkeEyUmKi/9oADAMBAAIRAxEAAADkXZMdJBKZ Nuax+qe1lqHWxZOT8b0/KaRWezWBOmaSi4ndpMISKaJ6P5f2Evp5xoDJPJx507GPI1h9tPjXDro8 1MXSvytcfX2/PO3citcWdV1o+ZzQ7hcxXDsJ8HYH2Y+YOT0M8A7XAM6ebSe4qtdBT0ObpvQadTWy NzlWtQErEMOX0cI040W5jdXNBOrzU4FZNphahsZOmn3V3nejDOfQxE7EqZgNGruhmJhBZi9QLdsS FF6sAsuOuM8rmeBhpxTanoDI9hC8gYoxz1czey2t2KcMNd6GKtI0eS6rLVD18HWSvyqaMXk8x3mD rnzTkF0c5DR3U8YNyjUivUnDou88r9UQqNvCDWDnWwJpclqgdVagbobWYGjXxbQaEq1ENV6tQN+g BBfWLqhOObvBNJB59Q6CHJ3c70lK44jG9ZmqNsw6mpYqVIujoY3YaZ4t4kou9OBnOTkdQ1Tl2ZSj TF5voMHo5ws61yf2Dx72FCrWeTDqVzdgNmfNwDpwZow36OWg3mw64b8Y5ob0ccAdDQ0efDShRsBe Lz7h0iSDEz71Tm6asSiz0IQBAKwk0LK1c2qn1nCa7jaOF8rtTrGuHhIDKoCwioZG3WucCO9ZuOd9 Qwd7TNJK8wyrvRUNoIIyo02tpJQ0lRZeVFMvBrmCwlCSapXWJJISSDnM+YOTrJNg56WBjNcggwGW cw8m6N4iV6diB4kkqwHNypnRHZNXsxc5EsOK5LhLjN6LL1NsklDbGtcrWaEA/HUo2anSdC0Ulx1H zH07zHtmw+vY0WBX7WMupWw3pH6fn64eioZPOtJIOSVl+DupivMPOJeEMCkMExpjqNbQRKEIq+Xt NpGFsqoPYNl7+TmcZHJWCHSB9Dh7muaSW2NGwKVrnw9BhdCno5/Rw5TS53HzL03geyb9LuudDJME uqzj3tZAOU1ky51uVq8dJJZPlNKL8PaWbvWYKGsw8WM5LSuVQQZMyEmSFCUBxrWQNy2qtsUlIjgB C09EDpOX6bTOSCtMjVCpqtnbT2UdMSkKhpBENgKq0kzqDtSUUKSZMdMgdJBzGjRvcPaiDckjO9Tm jKEuLFqyysIqE7RHIE4AMDhqukJCcSQkJXFcklRR3eb6O4hn280kpasA0Y5J0X4LNa0tHA3mqtE9 Tm2aDJvR1at3r54RLkXGoqBGXFJgZ8nRueYM0/M9G5PMK50JxdxLI2AWsiKSoJYSmjPBJsAoR1LI 9BvQJAkzIkZ6ZvVtU2s/pc7V0mvn6icZLa6CjW13Zjy1kLOvzTMuj0IMdMjWsvpDQI+kBY6YCFtN AR0FYpUHMEETz+5BNEZrmVoVNlAkRUz93IogUNibUovDYBQjFfp6QEnGdSSUZaZtXaxSKcL9GAmz obYaqxbgX3o1B7SxLKNN8jWHIkZKnjALDEx9ppnUM6ImcHdkm7xQcmbmdbj7dFgNLk+azfRlyNKV ZjEjjHWpklGkIkUwiDAtwZQkSBLiTsG5rbFK5rlMcltlk1Nge2GOPYMGGPoIBgm3GDD1LjDcQwWy jiW1LaqvzaWcu08VWkdgtNXcM7RRrnyq/Tv8ncQoz46QmcyVbRrOi8akUVsTzc4xL2WUdw2pZyDK yU4K4mJS0ztkBHXM1qgak7AWlnQXEZBcDITiKhOgkWZy0gs4uOOU1NRcJJkiSZxJ2cPOW1Y4dFQ4 iYdFicCwlJ3CBoDZdLTMKzUOzMXUqXlU5xdxKLZFyS3xV3bPsC5uuk5Qm1WPTOLbasO4MqtZnMKU LhlnU1ql91oRGRckLUhokUJJb0blURUJBcUWCvaz7dzhTO/N0Z1TYy8tXLWLloZ4TQ8JRCB6ZWXC VTCYkXYVhiqW5vRo06IbVLfDp9/m93OrWhnS0xM2crz0nzEGm+Whaj5SRrLJQrV/GTnZfFSe02Mg 2VjINpYqFtrEQbhOfsDmxIR1CztOnF5TuXDoU3kkneaVetfptlPk26NBqruS1BzaDXuVyqFDUzts tPquH6VLcrsF8lGYRrzrUa0gV2iyNmoCNXaozrznZtUzOj1WYL9OEAvSoTHeelBu/VqHU2bOZadb cEn6w6aU1lmS5+ickkPJISAkzPSWhYCk1aKlCFWSVVc9LabF5JXu7SWnEFJXzpJAkkCSQJJAkkCS QJJAkkCSQJJAiJD/AP/aAAgBAgABBQDoWxGOYjTIgIP1GZmZmZmYDMmZmZmZme8JxPLvnMUd7DFY iK2R9B/V+ZYQIATPgK0sExEOJmFgsyCP1gxUuQYDD8AGPnGRB3gJEOZX2H6zDI6CKe7joOhOIrT2 RW8umO2RAhIgBM8GhVh0II6s2ID1BUQtnpnoYDAJX0b5rTyLsFWa3x5PkW4YVAMyrYvTEA+kQMBC Q0IxBMyroe8RlJfwzNcgCu4lyEybFwoRJaQzdcTH0iHvAJnArM8hA+ILcQv5HInkJ5CZmfrP0gdo IIvwT3JwQxhJyGyCcnEQdsdXQoZnriGZ6Z7CCYzEU48TPGeM8ZiGo5WsD68dMzMP0CCCJMTBmJgw gjoAYy4H0FCOmIe3Q/QOijET5z2zPKeXbyzAonYRyWPV3Ll4TCZn6RBFEzF7/qt3B+owQCY7DvEn bHads/8AgkT4+p/HJjD9ARe8z3U4nmJ5ieYnmJ5iewTzE8xPMTzE8xPIQxh26iYgHTMQxsZHx2mR ntMiHE7Q4hImRMiEiZGTD8H6B8Q9E6J+r//aAAgBAwABBQDoFzFGI6wAmFSPqAyQoJFYgrECiCsR lAhRZ6xnwGDWIUAhUeMC5mO3xG+KxD3jLg/TkzJmTMmZPXMyZmZ6EYlYMJxPmFYhmYw8hjECkwgg /rOFcIMAiYhIi4ziGEAwYxYO/wCspwehnYBeh6CEZnrGXXx/VVZiEGYniTFXxhOTiBehhMsOepg6 HpiZnx1zMzPTMz0IzAuITDPGW/QOhhE7zHQdDO8DTP0iGEz5NoxPEzxM8Z4zEwZ4mY+kw9B9P/iG Zj/MxCJiYgGOjHv1Vg3TEMB6DoIYYYI7AnImZmZmYHELZ+vMInj0H0GGGOZkTyGMiZEBB6ZgOfpB B6Y6Yg+g9GOY3x45PjPGePdVxCei9voVfGV/GPo+Op6McTExk+tZ4LPATwE8RConaATEx1Q4OfpH Q9D8ntB89vElZlfI/DlSD3gEP0LmCIf0MR+0MscJPukn3ST7pJ9yk+5Se+ufcVz7iue+ue+ue+uC 5CRFPf6xLB28SBsYCkrjyXyyohZISsBWMVMZlMDIJ5JhmUwFS4g+fpPQR4fi34/THz//2gAIAQEA AQUA6iCLSWjazVDUBZKQE2FsxNy/0Nu7jXsCZnPXPUCJC017317NS4bFXxCQAvK6rTb5HX0ztbtO mjb+uo2+R19KbO5Tq11cjRa9nJ69Vu3v0aS37tOvU3I661MwULzWmwG5S11O5TdYnI67328jRTav Jaz0jkNc0V7lNlOpu07q2cnro9fI69ltO7TsP9FFBsajjgh19INPDBuU5q3yz8h47FSaxZrdVqx4 kdD1EHaKY5gbE/qu55L8zm1d9Hi7Kn1OQ8t/Z2dv7rjHNutbus3IbF+4djiuSYum9aW5Hk3+92m2 ms4u/wBmtK2La2jRbt6im2vkNTaOttA2VDb2WPIa7BtJXs+3G044/jLW0tz+vtheb11GvwWv4VdM QdjrKGbWTzgjLHr7P/8AaSAKahhtfI2tM5ZSJjqIvaAkQ/8AUM/rlhXeTZCuRmLxlVb18albHiaZ bxldqVcbXWW4mnNPGJSL+Josg45Az8VSzPxldldNIrSjQShrtFLLLeNqsdeNr8F4qtYeLq8142vx HE1rLONrcWcZVYx1lsr1dca69FAmrrF2opCCo+MU+UbsLGAXX2w23ae1K9gO1lKuu/qZh/56YgER TPHAcTy8x/Xf/wCjy2wNROle5uNv6+xsnf8A5pE1z/YETpRyV22G5xTR9/bVf/Po7aG8m/TubLa4 0+YXZerlr7dV+UDNRfsNymzsJq1Pyd9VDcm7bKb72zU5F9fQ++89npjpW2DrXZlbdq8mVYWW7lYm z5W1svqK2+yUr2AhXttr22FKtBBEzAwMsSZweKu9W5/YQXu6WccrXU6SU3fxVBQUq6xeLWqfxGuK 79NL7V44VFFTUq2OPr2rauNSu2rj66tQ8ZWBTxy1bF1SXoeIRq10a12BoVi0aQo1OL49ePo6WVNU ZRUbXo1FqBda5/IBY33OwqUdqLDWOW0isorLom2tVdW+thrsSwXayuNziXEupasgGUUta1HBrjd0 m1YzGHvK7DU25vvumWMUXX2b9nS/kNnYeq66neS5qOI2Lr35BNy/Xuq29+/W17DZUtt9+9tbdt2n tWbGlq7e15bFXJ7J1XbYr0tnY29fjty3Y0Wt22utXmdgceKrFI5TYVa1ZE6O6vNvRNM1HFdijIbV DEVGqBbrgawq+UTDLvUNTZxlROubjTZr7TMUcsCmZvcet0TgQzU6lWodO9A/PAJUc4PQfHR9DWd2 qRm9SF/tafD1J5ipA7cfquwAUNxWtZd9vV671pFXp1d9QuolhqQo1FT12VJZNluNFtezoJVqnjQ9 epXVdTfVsL0fjxPXkfx1KMpxEcYrIENglj5B8qzdyL0yzZs27NbWFNOxrB5RV4ytcdLBmKksT2Qa VdU5ZW23sBUzE+Ot28lyXblj0VXD73T2KHVr9ttTk0fUUXqNp92/jX3hs6i6d9n3C21WaXD/APw7 5qHJ6oa7YTY27iq+I11ublOf801N/d0dmq+zZGqjnjdvpYMrdSay0HeAEQORBbHvFYa5mG2TOBpW zYb488sgxAcdDPLEaxg9jWOr+KV26vtLaLhdbQv2zZw+3WetutXcz3JW2taao3INXAwP6NOtXQ36 CPldiyEBoylYrzzEJEYhi/xfR4iq56LNHbuusWsKFfEFhEBhMtaO4jLkeIIsIWK2ZS5pKb1dn0be yazq6gpHTdpCjR5pdg9Pify+lP5fSn8vpT+X0pRu6+wZbalKjlNM/VW2G2bQ7qcBLFaNrZhqYRlY T2FI20oG3s+yU0kypAGpRsKjJAwI9gEa0CWXZhtyVyQvY+hCU1hkaamNx1Tdfiabm7rtbVWpXvbp 3Rx1Is3Oln7dUUJQBSR40zxpmNa1uB5i2yz+w7jb2xY9W6v9c5T72j6LbSLFr7+PZ18YlpENjENY 7EpaxOpkrqKsCAAqRNclk8YTiWXBZZu+RUPbFTxlfeIkSuKsAljBetn7NEg09N/YF2wtV52OM4uv j16WftprezUr/se4i3f2S6mvQ5ltvd/sehVsattz1oS2rr73B2cfqptnUvptW5OoqxDgQuojZeGl pWxrl9IYUpkFf+mSeuGsyi8VS3cRRfycuttvlYek6162gd5q19lWKIoltgrFrM56fM0CtY2dmrVr r5Tc3H5PjbNTj9fdq1eQP9i0letxYss/bRdZTqJwPJOvM6t2qupyNXHcpynOtyiiuu6zQsW2+z+0 6Fq69tQs/rG5ZVZ1VPJTUhja7KKFFsaplDAQgqFLQLiYhXMxgMgjaqmDVUQ0LGpEsoxNTZZmrXxA gOJ7yS3eN4gddlHQ621XtLtcTqbc3+P2OMq43UXZts16rT0cZVeD3hrUgrX/AGbj9ncZ9HlHavhe S2hyfDbCJscc2rx/2XIz7LkZxOm9S9aLXodqwwWsiPWrzxZJdqtXBGGJ3iHMBxCcgGEQ4EKiMoli zj9cNYBBLASNM+suPJtq/wAPpu0a7GNW3WNzV5BtjR4inUf/APCES5KK/UA2YJmEZAUo2BGHYMck YhGIO57tGyATmBsyztNOsJWBBAJjE2NiVV4LMFHtM9pntM9hnsM9hnsM9hnmZ5meZjXBZ92gg2Ua eU8pmZmZmZ+inVv1mJgMB6EGbagOO8evyip4QtklTApEJnjmMMyx/XFt9pTsBBBNi0iNrIEY+sW/ Mu5Wqqfy9Zerka7Ep3PY9W+lll++tNlfLU2Lr8tVe0vuM9hYl+/kZxlrE4M7xH8x3mTMmZMziCU8 gjEYMIinEBnzN1SCDmHtGfBVh5LmeWYxGQJnE2T7F0aSbwIoxF6NSHlh8FWv7+y35v8AL16fh7H+ 386286qdw2rq/v3P/fWVRKvAO/xf/wBMxy3/AJVCx1dca6dOKtyle35P7bPuYxwNXdusuVgrisGV WPTEtVx0WOgdWq9LMSY4Ag7OD3AwI+MucS15xSlrB2iwQdNtgteqrVy35l3FVWz+IrDjh0Ev0VtL cLWy18LXSRwtKrrcZVrkjI2EKM5lWtZcdfVWgRrXE91k9rie14pZX91k91kzYZTSKgsxGUqadzBA nxF7zco9iqSIwzMZA/5gtBhcmYMZGMNGZoV+IAiwCDpsUPssdNFDKGHqM9RnqM9ZnrM9ZnrM9Zng Z4GGvIGhWCEIniZ4zxmJiYmJj6F6HvGUGa1/kAYGxCczaogYiVgMfETwBgQCNgRjGmuviogggjsE GuRZPBQbrCkJJ/TCCeAhUCewL+khghPRgQa7Q6+UBh7zboNZqPbtAYTGjRF8mUYgEEHTcOVrrfxr R1mx+7a2rqrNjfsz99t4v2bfYu8PT99tktyd7Lp71ljPyF0DAhBC4Ea2NdNq4kBDjwMof3V4MwZg zBncRWDBLMwPPIGeWA1mJTd6mUwGAx0Di2k0sr5g6GNNdIIsEEzFY33r/wAAnE2P3b6+M19da7BY BLfZepfFtSsHVmtqDmqeJrt0LfGo2xro1sLkzW1zY3TjtdqpXXaHCE7cbJGprXpclgss1950lO4j gOIz5ltreS2nGhtlwrQNAZbWLBcjUlGyITD3lY8QsAg6bN3qr0qPt0XMAxNhDCAwp16qB/H6uaqK qZXr1VN9jrljrVM9mnRaworCLrVolqmseamFlEoQWlXQA+ZmLZ42zxtgrsE8LZ4Wz1OwRAgoEVe1 ZYQeyCvMGvmV0LWUs8grRWmZbWHFlbUFHDAysZYRRBAZmKotsVfKFgIGzCQAzVZ8qp5VTyqnlXPK uZrma5lJlJlI1dLz1a9cD5IImVmRO07TtO30Cs1MgyE7QEGJ2njmeEX/AIKtEeK0Mtq8hahoK2Ai pcBRB0zHfAqYCe2AliSXOyxz+mzBYflR7Ci+K/o2aWRVlYoixZmCYgPiVMRopnzNmoOKFPtURR0z GbE/k6nsrtgszKyXgwo2P3ck4aalq1hHGqLa0pT01LstWmwy6yCqldb12KqDiFCAv4hFnqOVQIMz xE8Fmhse6tb0ae9PPwWFVEq3arXVjlag0fQzPFkKd4sAmMdCMgMRFaK8DRu4rTxuUQQwticruGtH E1eTes691LQf8qMLNj92zr323WcdbXKtDYLfxuwU+32msOps1Oupt+vx37al0bscfW9Ko3lKQc9l GST8w2oJ7q5rU1a8WmpXUIdn3Vw21kV61FDUh3KUgw14mxR5BRiLAZnq65iPFaK0zCvdZmFsTYvF a3sbGcRP/ZxlqsFvXAtWW1+YNbCeDTwaeDTwaeDTwaeDTxMKEipLKSp7YYnBmDDWDPUs9Kz0rPSs 9KT0pBUq9Fr8RiOMy9fFw0VoGEDAzMJjnBSzIVoGmYDC0sswL3NhsWWCOSrU14lDi1QJyHK/ZWf6 Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6Kf6KafM/dXYhE YTbSHMVCYK4BiDvPGWLMmspZFeBoXjWYj2F40cSwS4YPEbwqlNdZhAE5DWW/bWoWPvVpr2byVVV8 br1WHe1/tr9jWrqqGhQBXrJ9qusn22tQNi/YelH2tNDs7mpSH260o2rdXWG5vazUDX0kto0NKlpp cfW63cfVTTt6dVa8lr10bHJa6a71010cmRCI02RlIogmIIIy5lwi2msrbiC6GzAa32FVjrGEtEuG SiduO2PbWLwZzF76+2d9wNjZ+4N+y1617tlVWztPsm/Za8Dk7Vf74msbp9a2FHs2/aTylnsHIXFL dz3PdvG+y7aa1ats1FuSvKW8nbYPvrfDYvbYs2N47DbO4dk8dd7t4wwza/YIsEHQQyyX5mv5+P8A 1hs5r9eBiWRpbjD/AL1xOP8AL3PibH2vl+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn4+fj5+Pn 4+fj5+Pn4+fj5+Pn4+U/Z+f/2gAIAQICBj8AuNmmzKWRsiOmQdLjLbAcbKd2C6n8Tu6bIISUii2R tbEWxT2GTT1+Zr8WdWg3b/0J09SM/u53pOie43THh8/vhQQjbAWzupUTth7cdSLys6u5eAidTIgn Wq9Lp7/gRvKGlf1FTpr/AKQVU1xWFeyBJB1tnkV7hRE4kaI4jzdlFYcjZG4y4qotkiRKyGVa8i5J rJDEbHuuuG+DHIQxvpLFfMPcXB1xVKFChQoUKFChQoUP/9oACAEDAgY/ALjkCN5iMEQjOInM0XkJ z1EaoqPJzb5YTTma8hVpQ7rrCqRybLdW7HHgMtx0tiMo+ThMa+mK+ImVhbETMOgmLHDZBMCFyFxs FM29jEKZVzVydGHfJtY2Xja1RWE+eQnMVUm9/wC1jYfcsCe5PcnuT3J7k9ye5PcnuT3J7jIu+Knd JyE/XsPQ6mrIl6gdPMV+PAhA6m0EVUlQZtdRWRuHM+v9kbFpqeJ4nieJ4nieJ4nieJ4nif/aAAgB AQEGPwDm4UCMJMfE0C2DRlQfIkaT07R8/p5DcGIK/H49NET3c+2OTHn4VjS3reDKaW6uTiR9HZyS cAKwckE6dWltM/xRp9dKt99Jbw4E/JXEvNpUmJgnHsmrbF8LpC2zBxJ+TtpeO+nV4cCcuoGuLebS kxME59U0LYaHOIV1ZCerUBPZXAYsLhyXhvj1d3EdIoNfbSGMDAn5Jrj3Gi2Y70E55ZUl4v8Ah3CF RoOJPZ0baLHIY0G1kKTAYo4Wf4iseuj5cN+IBq0wcuvKntI0vbwcQcPj0UfLK83RmsH5Yj11wGJ4 katKozGP5QabzCuDbXxGDh2Z+qv8rX+F9aDvjLPPor/IVvwoLaschn00XsNqUGDgRj20yFiWXxaV ZtPXpBjtoWVeXZdaiDiM8DEGnt221NbMPgcD15c0JvoEmdnx9VKzDwj4/wCvxGGQ2VI2VwnziQd9 FZgb6IGQqc/g38qxy769W349PJdFvxRs3SJ9U0hdgEAVP5vpmrulS6oOEhEZjrI2zlsq2GxZbiqe wGrXlm8C3FuWz0E040lxbXhrEeLfiR00FY95HVT2V5cIZvapG8AbasPt4Z/rrhAF0tJpwjxNtxI/ 1FPYfxW2VfX8RS+X/SLrdTo2EeumJ+q3yVwAQqapJkz2CPnqEIDC2olhOGHSK8zdczB1NAiYnZJ+ Wk85pOvWXZ8MQ3bPq20LtoaibQIxia8wQe80m4u4zR8pJ0FeP2aJj7UUnlk8V06QOicaNoAol0So aMx1EjfT2rh0srM1yc+2k87YaDbgoy/Val05HvMd5PNFz6vz0C2zEdPx3cxQPZVmb5Kx241141NS M6g4HnYVhyIo9oMPdJ+atLGJqK4iIurfpE1IAAzhRFEBV0kzGkZ76AYAsuRIyqQABtgRJpoVdLYk aRnRVAqznpAFAhEna2kTWoACcWgRJ6d9EhVhvENIxoI4BgyJGVaDiKJQALuAgULoADbWjH00W0r3 vF3R3uvfRRgCp2RhQIABGAMYxuosFXvCG7ox660EDTlGyN1YKojw90YdW6lMDUuTRjQuMqs37yg0 bdwBlPskYVpGXLjUigMMKw5TNPuc6fRlUdXKZFSMxUHnSKxzFWv5/wDY1M23ZPLesKqMiBCqs+mJ 2yLZMnaNmwmvNW7Y1heFAe4VVZXZg2fQOurt+8pU2XNt1BnvYZHDAz0UpucLSxC/h3w7id66R2wT 28jXPLWg1sEqGe5pLRnA0t6yKs37SFjduCzoJ0lWM9e6rdi/bC8XUEZH1YqJx7qx2TTi1wgqErN6 8LZYjculsOuKF63gDIIOwigw4cYybtzh/wBLT6quWoXVbXXNu4HQj+KB8lf5i2V4ekuQbvegZx3I 9JFWrdhNdy8vEUE6QE3sYPqBo27vdHA1aFcss688QuOzKmvXPCgkxQ81csgWYDGLkuFO3TpA7NVD y1i2H1WheDl9IgmPqk/HKr9l10XbSz3W1CGBIIMKfVXl790F0YAXbhbFZ9o7xvxw6aHlrS64XVce cEB8OzEtuwwx+BxqBTcPcYrDAilnbHMINY8uNSOSRyWn2ao9OHz0zXD3Rgi7z+zlPmLdx7bsAraN OMZYMreqrt9SS17RqnLuiBFXbbgst5uIwOw9EZZVr/yna2DGDW4w2agoPvdfIwsXLlpHMlEKxJzj UpK/ykVatLKrZdbqwc2G+ZmZxq3eYnVaLFYyxEY03AuPaDEuVTQRJ/iVo7MK77kqMS9xvlOVJ5gM y3FEK6aTgf4gw7YmnvF3d7ihGLach1KPo6K/wwW4elkkxqhp6I27qtlGZHtJw0uLGrT0yCp9HVR8 0Xd7hTh97TETOQUfR0UbdwalYQQaFh7txrIj8MlYgbJC64/mr/KEhuHwtPs6Zn441dvSdV5QjboA jDDpr/FsgOApRRcOB/igfIKFoYtm7fWPxwHRy6XEHkCit9d4xXdFFvAm8mgcSY21BrjWxKnOgwMH ZQuNl0VgjR1VAwPTUGiUxG6oYQeQKokndRNy4dW62MvT+yg2oMhmGyy39NY8gcZqZE0HuRqAjDLk LASQCY30fOnzGhoZtAVNCx7JkaveFeTCnhcdbjXBpB8KgiJ9XXjNDyrubiNbNwFwoIIaPZVRHZV6 4kahdaJAP6g2GRS+VS4Utm0XMKpM6o2g/OOivMWWJvC1bF1JADEwcO6AD6KHmU4mthqGFgWurFtc dMz0bKR2ADMoJAMiSN+2r3lxdKIi2yoVVnHPxKfn7K87aduItqFS7AGqcxhhK9FJ5lbpaOGDbKrp hoEeHVt+tRsWXu8RVBZLS24E7Sbg/qrzZY9+xIRiF1ZbdMpPVhTeaN5i4sl40ppnTP1Z96Oil88L xL6bblCiaDqj93Vt+tVh+KXFy6lp0ZViG2iACI6SauJ5d7xNs6XFtbOlT13AD6z6K/yDGvicIuRg omNRAMYdcUs+ZJ1AwGW3jh7MKMs/ao+SInzurQGjulT+rugDMb8KCs2pgMWMCfRhyxcAI6a4i+D5 KB6Y5JNYW56omtJXSu2ayqK0nKigMKcQBRBxEmK0kMBsruyR08uWNYkx0UBAE7emtLLpntFC3ta5 I7Afprq53Ea0hf6xRZ9MUrsoLLOliMROcHZNcTSNYGnVGMbp3UbWhdBMldIgnPLrriaRrjTqjGN0 7qNwKNZEFoxI661tZtls9RRZ9MVAwAp791RcZwoIcBgNO6RXB0Lw8tGkafRlR4qg21GogrIAXHLo pbzIlwMJVnQHA9Ymj5UKga4utkCYMowxwg9tcMqCkadMYRujdXCZFNuANBA0wMsMsKGtQ2khlkTB GRHTRPmDY4oieJo1dGeNHhvaFqYbSy6ZO/ZJr/1uBxP+3o1erGn8ySS7CJb2VGwbhtrVadXWYlCC PVyljgN9aWgiIMVIBEdPNiiTiDUBMN80CfETpAFLb3Csagc1YgwWmdlBlJIzNG4uS+Hq/wBaM864 9om241Qr+buLcBH/AGu8OzLsryNy5cKcQ/isG0z3duyrS+SuNdtEPx/xGuKPq4ktBnceyr3+X5hl YXboUcZlIAOGkAgnqx6BXlOKzo7+YRCw7rMh1RPWN9JwmuC07gX31s7KvRJOnpKirK+QutdVieMv EN1Qu+SW0ndjjup/KHVce4Z8qzYzqPhJP1Djj7NeXs62Ns6uNda4Vlo2vDFF7OiRUWbiMhRpti+9 /vbDqZe71aqdvNXm/wAoo+q3xWUg493hgjDrXpyqx/40+Sk4z8NOC0tr0e19bCPSKu2rNxn8o1sR cFwtpefZeScsczFf/wAwki6h/Evj/pbGH7zZdGJoKNmGONeb4LKuFmdaFvZ6GX56tm8yki9bJZV0 iO1m+Wmt6lvMQdKW++07I0zGMY4VZ/486n8xcX8XSRqW2M8SQJ9nE440ri01ny17TbcMUhXGCnus 2YwM8uFYTB5cOWTXdHprvmTu2UWb2RIrCtPOJgEbKMmAdgo7aLNgorVHooiyuqM8QPlioa3B6x9P MR3EtbOpMTgfjvoKxAZp0rtMbqI8tYbS7FyWaMWxJ73zYT0Y1N20yicx3u3Ls66gHH4F2QQ1w6nM kknt9QyGz4GKx2cnRy4VNYUXYya1WjBr8RsPRUgYmoqDztI9VRuy5JAic99RcienmC1bE3XyHRtP x/YdTnXcPiY/NynzCvw3QE6iTpy9ro+gZxTO/dtPcFqwSMWMfT6Jg8z8639sV+db+2K/Ot/bFfnW /tiotXFc7lYHkL3CFUZk5UALyY5d4c4ioHJDVK1jWFd4VnWlcak0BlUIzR6qxYt11B5mFZxWFSwk nfUgR1ViKxUcxr/e0t4VcREbug9PKbt46VFC95uU8tP4Plx47p2E7h0/ZxxKHzZHGC6rVhfDaUZT 07h2nZHIeo0129bNwh1QDVpzDH5qkeTeP42/tr/47n22/tr/AOO59tv7ahNXl7gPd1NqWeuAV68f oPkvOfmr4WOZjYenaDt+Vf8AjrByPfOyfoUYn9lN5S0Pyh/67Ri8eIHpfxDpw21w3P4tqAeldh+Y /t5rBanliSKwPqrTEGomBWJqeSaB5c67uPVUtlyYfAHqNKQAM8FyGJ3cvmPM3hrt+V0patHwlyYk 78RJ3iBQVfxPPOAzufBYU7umD2eyKMd662Ny42bH6PieU9RpwgLHiJgBPsvQX/GJgAe19FWna0A1 wsCpkRpI+mrvlCgAt6+9OelgtPeIAuWxqVvmry3m1P4gBWf/ABnCeyB2UWbG/wCZ9Itzietz7o6a tebQkXVIa50E5fZyPTVv/kbI7jki4g2N7a9viX7tLcQyrCQfgMK72ValzqTnWFTy6TlUkioQSa7x w3CtS9orDA/V5JOfwLeXEzbJ8W2ccMcvmijdvNpQZmifL3vLqCe6jag0bMxnTcQ63e6Lt519mdww nP8A0p710xb80itbfq2Hp+frrQ7Mp/eRh800HXIiRyHqNObbFSbiYqY9l6DDzOBE+N68tbvvreXO qSdq768xdvTpLXV7onHXPzV/i+TRtLYsTmQPUBvJPopbcz5by6zcce1jJj+JjpXog76b/kvNA8K2 wgKJ73sr1KPmoo6uVYQQVGXpp/Lk/gXTAZvZPst2ZHoJp/8Aj7oMqWK9EeIfRzAdhru+upGNGcCK xGHJAqBhyY8kVHJlyyMCKCN4qjl0p6anbzeNZALDxAASw6+jdWpcxmpzHx2HbR4ttST7QwPpFE2L puWG7hsXMZ1YQsfNBq3e8sWtW7HduJrZgXgFlWScBME7dg20GdFYjIsoMcpA3U1vhHUbiNErkFbp 6aUHMAVaby6atOqcRhlvos3l0LEySUtYk1w7umzaOYUKJ7Ez7aXynkrZNod645Il39OQoeX8tbW4 4IlWEgnaca/+S19hPpr/AOS19hPpo3/MKq33ADBRkq5D6ewbOZwrogHBTsrCu9WUGscRWtfDu3ck 10b+Wag1IqeYbh9nAdvLhRDDA40TkDWhM+brWUeCNS9R+SZ66AR1f+MR8me31ddWfMIEfhzKaoXH CcejrI6aN5AVdsSoclQejKe0ej/8Wxga0ySNk7OayHZyCo5MeSK31G3kyodOPNKJiak4tUn4TEgV nWDD4MFSCu0TzlO/5qio5enkwipro5NIzOA5oUYTRO7KtbGAM+WQCyg6dQKqs9bsoPZNcJUcvHh7 gPvMNW/uzVy4QVFvxA6T/tLCcMpmuGyMjEFhr04xE+Fm30ECsASyq5iCVmds7DmBXBCM7xMLpH+5 lnsmpAbVJAQQSYzxUlduJ1YZHGgoBEnTMownd3GaO3kwwFdBMTUVjumihyiRyZUGXEESDWVZGsjW RqThyQ4K9eVYc1WjDGp5J2cmOysOQ4181SKUnZJ5veqDkKIY9xfZ38jaPFpOnrirWWng9yeyfVFW v8fTHEbVp38N/juq3Z2Ncuu38KXGP+7T66a+SpNm5qGllb8M4GdJPsznuFWf/Je/rqz1XPkFW/aL 29BtzBiTkTAxxwkE7MqW53m0OtopcA1KSREGJwkGCSI3EUaC7Mz1VO7kgYmv3jny2kV9YNoFhh3S NMZYiccD9XrpLervm7dVl26RxI+Ra4E4fmT+5ER9v1chIxoK2IOyMq0DrjdyYYruqVPMg5VpbbUA 0DursqDUipYV0cmFMx2COcWOQrWPEcTywCVUnUVAVlnfDqwHZFC4rurxGruE+8p04Yd2KaLjjVIe NA1T1Jh1iCd+VAhmQgaO7pxXcdQYULZdygMhWW20faQn11qtuytvC2/7IH8sTtk0VDMC3iMJj1ro 0e7mSc6BBLacVnSAOpVCrPTE1FSeqsK7ow3nKt7b+TBZ7a8Hr/ZXg9f7KnR6/wBlNc0Es0DFtg2D CvB6/wBleD1/so6UCk+18RW8nM8upcDWm4I6eZh4hlRJ2EzNY0I2GpNYVA5caPSecqJGkGWruv6q g/Bwa1AY/DxUVoY95fWOZrXtrKss6x5wHNLHIVrWccdR+M0DUDM1j8Hjjy970/DalzFSOWK1Lka6 ecBztH1qiB6a7wkdlDqoqgWFXXBBJbfBkR6DmKJsaSqhPEpOpnyA7wjNd+eVSNOrXw9Gjb18SI6f Vsrh2ioKgFiwLYnZmvxig7DvklNA+sJ9WE9VFgqlAYJCEgRmJ1zhtISKLoFXToGkqWJLR++g2/PS rdjvyFKjTBWZBEtuOINNdTTwlJ7uk6mCnEg6vR3TUjEHKp5hAzrPGs/VS3FODANHWJ31mKzFZ+qs x6K31I5mPJ+6eZBrDLnaudGxcK6ak50OqkvfUMN/C2HyweyltT3Um63yIOz+ihdM6OMXnSfDjjll 00OGGNy43GMAHuiNMyy/u7cxlSXV/Lb8T3dJP+33jQUu+iXPdZ1UCZBDKwXHaDjNXC2LMbWJn92D gQenOg9tTOk2lH/TuExJ39Z/qpWUHg2wLJMCJMbdU7VnunLPOuEc7ZKdns+6R2jm628K5dJ/Z8vb y2wbfDKWtFzLvN3dxxiGxP1uukQoYW7cctIiG1xtn2hswoqPAIun+MjRHox6+QxnWpgQPaO+joyG Z30JxFbjU8nzCu8a0Ns8PSOZBro5kVHNLbdnXWt/GfVWo51JzoNUHEGiLSKgOelQPkrVwrc5zoX6 KPDRVnPSAJouiKrHMqoBNa+Emr62gT8lC4UUuMmKiR21re2jMcJZQTXDCqE+rAj0VotqEXOFED1V JyrAj01iRUkwu/f1fT6KABHpruth2V4/UPorx+ofRXj9Q+iiQ2eeA+ivH6h9FeP1D6Kh3wPRUDKs eTA1sFSxn+EVgI6TnWrNht5sGv3fgQzeFMe2tTejknZWNZeisj8e2sj8e2sjWRrI1kayNZGsqyrv KD1ipCKD0AVkBWI+Cg8/o5sV0c+BnQG7l0LkM6A+E6a7x7xGFDDvbaiSev4LA41pOfwunYMedw1a WmBu9NY8kLntO6tK0OqlsnJpd/4V+kx2TR4Y0pcRioGEOs+v+2lu2gA5WGgROod2d/fA9NKbUAnU rMM2gHM7aKgKuEjSEBy2R359UVau3QHNxH1BlBgqVG0YH6wymkBAbVa4sMF0hjGQjSPjNM1osLgX ZwoxwP5eP2sO2mTy4CiVW6iiBBgzHq6pq6igBQ+AGQ7i1AzNTOO+o9P0/srdU8mQq2LikM1tXkx3 spyyzGcZ9cL3fE72+1dX9taNPe1aPd1T1R68KyFSQK4ayCcjWls/lrAVqGdQwx58c1jvj5+bw08T eocmh+8Nh2/toTcAnZ/rWleQdVNCnS2lQ/dgJtwOM4t7MZVwrQLLIKP3F07wQNOeOS7aDaQulQkO RB6Rp1ZbJiha0+DV3yVhpnLGfSBU8JgpIaDozAIz4hwx+rNDuawNZ7hXNyCfEy5RAw6ZpQ9snSht DSVmMIJl49DeijYdAF0xJAGWWVx/kHXTXwhD6vASslYAO3TOEjH0TVx7qldTagpInBVGwkbN9asp 2isDht6eSTyYsB214h6aX8TUEXhpqK4Lhuichnu65DcTBWZ1WViWmen2jtwpr5IEKEXvZ7Sfm9Ne IemoLCOuuIG1RktcR8PqjdyYGp2/AY8yeZJos2Z5AN9cJxJGVAGRFYVhmKyNZGsjWRrI1kayNZGs jUQahgY2GpAmpNZcmIrKsqyrKsqyrAc08+R8B0csjMUtxcNQDCp28gt6NUrqnVG/oO6vyvf+7X5X v/dr8r3/ALtfle/92vyvf+7X5Xv/AHa/K9/7tfle/wDdr8r3/u1+V7/3a/K9/wC7X5Xv/dr8r3/u 1+V7/wB2vyvf+7X5Xv8A3a/K9/7tfle/92vyvf8Au1+V7/3a/K9/7tfle/8Adr8r3/u0trh6dU46 pyE7uZq5M+d0c7o5vBuiUJ7p3VK4VEE13/ClrWQNsE4Vb1WSiM6ie9BB69+8GiFtppBw75Ldo1z6 hVspbUG4momWw6u98s09y+JtoMes5U1sZAyvUcqtsiISyBmLOQZjYNY+SlLIOHwg7tqOoHqn+mku hFZyxBLvpw+0tLdCIXLMDreBHR3xS2jgGOz5qZFtgBWgHU2Mb8dvRHXVuxaUKGCk4nbnmTlVt7I/ DZtDYnMGPXTIqjQCO6Z+mfXXAICIBh3jiY2kk+qgWQLOTIxKn0zStaC3LhnWrMQR1AEeunbzCwNf DQScG/ZV5Lw76sEVpOBOA9cVbkTc4ircMnbjFXpThhI4bS3e9JM9lcO2IWFwpltogURjr7/o1/00 qWhCgZfynmH4GDl8nMgZc/A99cG+ntrvYGldM9AHWJalVVVVV+JAnxdpPqosyKGJksNXzsR6qRWA hBpEUbVs6ZOosshvTOVKbkSo0ztPXSKwEIukRupXAWUXhxsI6caFpkQoCWA72E9TChZZFZASwnVt 6mFB07pBkRsos1tJJljBx9eE7YiuKFQOF0z3svtVoc64YOC8kgjtriNbTUTJPe/uo3XRCSIOePrw 7IpbcBUXJV6esk+ugQi6lyaDPqMHtFBFbTBLErILE76cQo4mnURPs5RjQtmDD8STMz6aNxoBbdWt 0XV9Yatn80eqi7ous+0NX90eqkbSq+LBBA8J5hjn48uMadld2K/FnT+7l9NdzLmjkHD3d6d3x9fR XTX4/D1R7emY7a/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcr9 H3K/R9yv0fcr9H3K/R9yv0fcr9H3K/R9yv0fcocLha9mnTPqr//Z ------------A48356845382213-- From mip6-bounces@ietf.org Wed Feb 2 09:27:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08256 for ; Wed, 2 Feb 2005 09:27:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLlh-0000Ml-86 for mip6-web-archive@ietf.org; Wed, 02 Feb 2005 09:46:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLRF-0007fF-Ah; Wed, 02 Feb 2005 09:25:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CunFW-0003t8-Av for mip6@megatron.ietf.org; Sat, 29 Jan 2005 02:42:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18737 for ; Sat, 29 Jan 2005 02:42:29 -0500 (EST) From: Geoffrey.James@tip.CSIRO.AU Received: from act-ironport-ext-out3.csiro.au ([150.229.7.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CunX0-0005fw-RZ for mip6@ietf.org; Sat, 29 Jan 2005 03:00:35 -0500 Received: from crux.tip.csiro.au (130.155.194.32) by act-ironport-ext-out3.csiro.au with SMTP; 29 Jan 2005 18:41:57 +1100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAQAAA+k= X-IronPort-AV: i="3.88,163,1102251600"; d="scan'208"; a="28772557:sNHT19983244" Received: (from daemon@localhost) by crux.tip.CSIRO.AU (8.9.3/8.9.3/CIPAT-2.1a) id SAA10941 for ; Sat, 29 Jan 2005 18:41:46 +1100 (EST) Received: from minerva.tip.CSIRO.AU(130.155.194.95) via SMTP by crux.tip.CSIRO.AU, id smtpdAAAa03231; Sat Jan 29 18:18:03 2005 Received: (from jam122@localhost) by minerva.tip.CSIRO.AU (8.7.5/8.7.3) id SAA17883 for mip6@ietf.org; Sat, 29 Jan 2005 18:09:40 +1100 (EST) Date: Sat, 29 Jan 2005 18:09:40 +1100 (EST) Message-Id: <200501290709.SAA17883@minerva.tip.CSIRO.AU> To: mip6@ietf.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 X-Mailman-Approved-At: Wed, 02 Feb 2005 09:24:58 -0500 Subject: [Mip6] Final call for papers: EmNetS-II, Sydney, 30-31 May 2005, Embedded Networked Sensors X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: -4.0 (----) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Final call for Papers (submissions due 15th February): ====================================================== The Second IEEE Workshop On Embedded Networked Sensors (EmNetS-II) http://www.cse.unsw.edu.au/~emnet/ May 30th-31st 2005, Sydney, Australia The Second IEEE Workshop on Embedded Networked Sensors (EmNetS-II) will bring together researchers working in the broad area of embedded, networked sensors. The goal of the workshop is to promote community-wide discussion of ideas that will influence and foster continued research in the field. The workshop will provide a venue for researchers to present new ideas that have the potential to significantly impact the community in the long term, especially those exploring how practical considerations or novel application scenarios and requirements shape the design of these embedded and sensor networks. Topics of interest include, but are not limited to: * Validation or new architectural approaches for sensor networks * Tradeoffs between application specific, and modular approaches based on prototyping and implementation * Software and architectures for sensor network programmability * Approaches to ease deployment and improve manageability of embedded and sensor networks * Experimental and measurement tools for sensor networks * Reliability and fault-tolerance, debugging and troubleshooting for sensor networks * Novel applications for embedded and sensor networks * Sensor network security, vulnerabilities and defenses * Algorithms, protocols and systems for communication, coordination, data dissemination and storage, sensor tasking and control/actuation * Operational experiences from deployed sensor networks and prototypes EmNetS-II solicits papers (8 pages or less) about new work in these areas. Papers will be selected based on their originality, technical merit and topical relevance. Extended abstract of 2 pages may be submitted for poster session. Detailed submission instructions will be posted at the workshop website. IMPORTANT DATES Submissions due: Feb 15th, 2005 Notification of acceptance: Mar 30th, 2005 Camera-ready copy due: April 21st, 2005 Workshop: May 30th - 31st, 2005 ORGANIZERS General Chair: Sanjay Jha (NICTA/UNSW) Steering Committee: Deborah Estrin (UCLA) Nirupama Bulusu (Portland State University) Program Committee Co-Chairs: John Heidemann (USC ISI) Lakshman Krishnamurthy (Intel Corporation) Poster Session Chair: Dr Deepak Ganesan (UMASS) Program Committee Members: Anish Arora (Ohio State University) Philippe Bonnet (Datalogisk Institut Kobenhavns Universitet) Andrew T. Campbell (Columbia University) Wei Hong (Intel Corporation) Koen Langendoen (Delft University of Technology) Adrian Perrig (Carnegie Mellon University) Kang G. Shin (University of Michigan) Rajeev Shorey (IBM Research) Pavan Sikka (CSIRO) Mani Srivastava (UCLA) Yoshito Tobe (Tokyo Denki University) Jay Warrior (Agilent) Alec Woo (Microsoft) European Publicity Advisor: Philippe Bonnet (DIKU) US Publicity Advisor: Wendi Heinzelman (University of Rochester) Finance Chair: Dr Chun Tung Chou (UNSW) Sponsorship/Support Chair: Dr Stan Skafidas (NICTA) International Liaison: A/Prof Palani Swami (University of Melbourne) Publicity/Publication Chair: Dr Geoff James (CSIRO) Local Org. Chair: Dr Athanassios Boulis (NICTA) Registration Chair: Dr Salil Kanhere (UNSW) Webmistress/Webmaster: Tatiana Bokareva (NICTA/UNSW) SPONSORS University of NSW IEEE IEEE Computer Society SUPPORTERS Gold Supporters: Intel Corporation ARC Research Networks (Sensors) Bronze Supporters: CSIRO Australia National ICT Australia _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 2 09:32:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08651 for ; Wed, 2 Feb 2005 09:32:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLrI-0000Wb-DK for mip6-web-archive@ietf.org; Wed, 02 Feb 2005 09:51:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLRG-0007fN-5J; Wed, 02 Feb 2005 09:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvhMd-0003Q4-II for mip6@megatron.ietf.org; Mon, 31 Jan 2005 14:37:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10765 for ; Mon, 31 Jan 2005 14:37:34 -0500 (EST) Received: from msg-mx2.usc.edu ([128.125.137.7] ident=sjes) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvhed-0004Gk-Q8 for mip6@ietf.org; Mon, 31 Jan 2005 14:56:12 -0500 Received: from ceng.usc.edu ([128.125.72.78]) by msg-mx2.usc.edu (Sun Java System Messaging Server 6.1 HotFix 0.08 (built Dec 8 2004)) with ESMTP id <0IB700B2356LYT00@msg-mx2.usc.edu> for mip6@ietf.org; Mon, 31 Jan 2005 11:37:33 -0800 (PST) Received: from localhost (anrg@localhost) by ceng.usc.edu (8.10.1/8.10.1/usc) with ESMTP id j0VJbXq17543 for ; Mon, 31 Jan 2005 11:37:33 -0800 (PST) Date: Mon, 31 Jan 2005 11:37:33 -0800 (PST) From: anrg To: mip6@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Wed, 02 Feb 2005 09:24:58 -0500 Subject: [Mip6] ACM SenSys 2005 CFP X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7BIT ACM SenSys 2005: CALL FOR PAPERS November 2-4, 2005 http://sensys.csail.mit.edu/ The 3rd ACM Conference on Embedded Networked Sensor Systems (SenSys) is a highly selective single-track forum for the presentation of research results on systems issues in the emerging area of embedded, networked sensors. These distributed systems of smart sensors and actuators connecting computational capabilities to the physical world have the potential to revolutionize the way in which the real world is instrumented, monitored, and controlled. Such systems present a wide range of challenges to the system designer because of resource constraints, uncertainty, irregularity, and scale. SenSys provides a cross-disciplinary venue for researchers addressing the rich space of networked sensor system design issues to interact, present and exchange research results, and demonstrate their work in a hands-on research exhibition. We seek technical papers describing original, previously unpublished research results. Topics of interest include, but are not limited to, novel results in the following areas of research in sensor networks: - Sensor network architecture and protocols - Distributed coordination algorithms (e.g., for localization, time synchronization, clustering, topology control, etc.) - Failure resilience and fault isolation - Energy management - Operating systems - Data, information, and signal processing - Data storage - Distributed actuation and control - Programming methodology - Security and privacy - Network planning, provisioning, and deployment - Operational experience and testbeds - Experimental methodology (e.g., repeatable experimentation, measurement infrastructure, simulation, emulation, etc.) - Analysis of real-world systems and fundamental limits - Applications - Integration with other systems (e.g., Web-based information systems, process control, enterprise software, etc.) The conference time-line is as follows. All deadlines are firm. - Paper Registration & Abstract: April 1, 2005, Midnight Eastern Time - Paper Submission Deadline: April 8, 2005, Midnight Eastern - Time Notification of Paper Acceptance: July 1, 2005 - Camera Ready Paper Copy: August 25, 2005 CONFERENCE COMMITTEE ==================== General Chair: Jason Redi (BBN Technologies) Program Co-Chairs: Hari Balakrishnan (MIT), and Feng Zhao (Microsoft Research) Local Arrangements Chair: Curt Schurgers (UCSD) Publicity Co-Chairs: Bhaskar Krishnamachari (USC), and Wendi Heinzelman (University of Rochester) Publication Chair: Xenofon Koutsoukos (Vanderbilt University) Posters Co-Chairs: Matt Welsh (Harvard University) and John Byers (Boston University) Demos Co-Chairs: Chenyang Lu (Washington University in St. Louis) and Phil Gibbons (Intel Research) Web Site Chair: Michel Goraczko (MIT), Steering Committee: Deborah Estrin UCLA, Co Chair Victor Bahl Microsoft, SIGMOBILE Representative Taieb Znati University of Pittsburgh Craig Partridge BBN Technologies, SIGCOMM Representative _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 2 09:33:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08746 for ; Wed, 2 Feb 2005 09:33:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLry-0000XR-KG for mip6-web-archive@ietf.org; Wed, 02 Feb 2005 09:52:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLRG-0007fz-TF; Wed, 02 Feb 2005 09:25:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvfzy-0008QU-0A; Mon, 31 Jan 2005 13:10:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01732; Mon, 31 Jan 2005 13:10:02 -0500 (EST) Received: from sophia.inria.fr ([138.96.64.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvgHv-0002Fk-7f; Mon, 31 Jan 2005 13:28:41 -0500 Received: from localhost (localhost [127.0.0.1]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j0VI9NTB017624; Mon, 31 Jan 2005 19:09:23 +0100 Received: from sophia.inria.fr (penguin.inria.fr [138.96.240.36]) by sophia.inria.fr (8.12.10/8.12.9) with ESMTP id j0VI3HFp015296; Mon, 31 Jan 2005 19:03:17 +0100 Message-ID: <41FE72E5.7E92B109@sophia.inria.fr> Date: Mon, 31 Jan 2005 19:03:17 +0100 From: Sara Alouf X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.23 i686) X-Accept-Language: en, fr, pt MIME-Version: 1.0 To: Sara Alouf Content-Type: text/plain; charset=iso-8859-1 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.4 (sophia.inria.fr [138.96.64.20]); Mon, 31 Jan 2005 19:08:05 +0100 (MET) X-Virus-Scanned: by amavisd-new at sophia.inria.fr Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sophia.inria.fr id j0VI9NTB017624 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 02 Feb 2005 09:24:58 -0500 Subject: [Mip6] Performance 2005: Call for Papers X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f Content-Transfer-Encoding: quoted-printable Dear colleague, My sincere apologies if you receive multiple copies of this CFP. Please note the new page limit (22 pages instead of 20). I would=20 also like to bring to your attention that the submission site is=20 now ready and running. Best regards, Sara Alouf Publicity Chair of Performance 2005. ----------------------------------------------------------------- *************** CALL FOR PAPERS *************** PERFORMANCE 2005 The 24th IFIP WG 7.3 International Symposium on Computer=20 Performance Modeling, Measurement and Evaluation October 3-7, 2005 Juan-les-Pins, France http://www-sop.inria.fr/maestro/performance2005/ Sponsored by IFIP WG 7.3, the Computer Performance Foundation=20 and INRIA The PERFORMANCE 2005 conference solicits papers on the=20 development and application of state-of-the-art analytic,=20 simulation, and measurement-based performance evaluation=20 techniques. Topics of interest include, but are not=20 limited to: * Performance-oriented design and evaluation of: communication networks, mobile and wireless systems, Internet servers and E-commerce systems, Web services, Web architectures, peer-to-peer systems, grid computing, computer architectures, database systems, operating systems, software systems, distributed systems,=20 multimedia systems, file and I/O systems, memory systems, real-time systems, and fault-tolerant systems. * Techniques and algorithms: analytic modeling, performance optimization, queueing analysis, stochastic scheduling, model verification and validation, power analysis, hybrid models, experimental design, system or network measurement and monitoring, workload characterization, simulation,=20 and statistical analysis. ** SUBMISSION GUIDELINES ** PAPERS: Papers should not exceed 22 double-spaced pages=20 including figures, tables and references. A limited number=20 of submitted papers will be accepted for a poster session.=20 Submissions must be made electronically as Postscript or=20 Adobe PDF files through the Conference Web site=20 (http://www-sop.inria.fr/maestro/performance2005/). In case of problems, please send papers by email to=20 papers.perf2005@sophia.inria.fr. Papers will be selected=20 on the basis of their originality, technical standards,=20 relevance and clarity.=20 Full papers will be published in a special issue of the Journal=20 Performance Evaluation (Elsevier) available at the conference. TUTORIAL SESSIONS: Tutorial proposals, not exceeding 3 pages,=20 have to include title, abstract, duration (1H30 or 3H),=20 intended audience, assumed background of attendees, name,=20 affiliation and a biographical sketch of the instructors.=20 Proposals should be sent to the tutorials co-chairs (tutorials.perf2005@sophia.inria.fr). HOT/CONTROVERSIAL TOPIC SESSIONS: Proposals are solicited for=20 a hot topic session, in which a group of speakers will present=20 and discuss their recent results in an area. Send proposals to=20 proposals.perf2005(at)sophia.inria.fr, identifying the organizer of the session, the session title, three to five speakers, the=20 titles of their talks, and a short abstract of each talk. ** IMPORTANT DATES ** FEBRUARY 22, 2005, 11PM EST Title, abstract and author=20 affiliation due. MARCH 1, 2005, 11PM EST Submission of papers, hot topic=20 proposals and tutorial proposals.=20 JUNE 1, 2005 Notification of acceptance. JULY 1, 2005 Camera ready copy due. ** INFORMATION AND INQUIRIES ** http://www-sop.inria.fr/maestro/performance2005/ info.perf2005@sophia.inria.fr ** ORGANIZING COMMITTEE ** GENERAL CHAIR:=20 Philippe Nain, INRIA, France=20 PROGRAM COMMITTEE CO-CHAIRS:=20 Cheng-Shang Chang, National Tsing Hua U., Taiwan=20 Daniel A. Menasce, George Mason U., USA TUTORIALS CO-CHAIRS:=20 Eitan Altman, INRIA, France Zhen Liu, IBM T. J.Watson Reseach Center, USA LOCAL ARRANGEMENTS CO-CHAIRS:=20 Konstantin Avrachenkov, INRIA, France Ephie Deriche, INRIA, France =20 FINANCE CHAIR: Dany Sergeant, INRIA, France PUBLICITY CHAIR: Sara Alouf, INRIA, France PROCEEDINGS CHAIR:=20 Rudesindo N=FA=F1ez Queija, CWI, The Netherlands ** PROGRAM COMMITTEE ** Almeida, Virgilio UFMG, Brazil Baccelli, Francois ENS, France Bonald, Thomas France Telecom, France Borst, Sem CWI, the Netherlands Calzarossa, Mariacarla U. Pavia, Italy de Souza e Silva, Edmundo UFRJ, Brazil Duffield, Nick AT&T Research, USA Eager, Derek U. Saskatchewan, Canada Gelenbe, Erol Imperial College, UK=20 Golubchik, Leana USC, USA Harchol-Balter, Mor Carnegie Mellon U., USA Haring, Guenter U. Wien, Austria Harrison, Pete Imperial College, UK Haverkort, Boudewijn U. Twente, the Netherlands Herzog, Ulrich Friedrich Alexander U., Germany Hou, Jennifer U. Illinois Urbana Champaign, USA Hsu, Yarsun National Tsing Hua U., Taiwan Iazeolla, Giuseppe U. Roma "Tor Vergata", Italy Jean-Marie, Alain U. Montpellier & INRIA, France Kumar, Anurag IISc, India Kurose, Jim U. Massachusetts, USA Le Boudec, Jean-Yves EPFL, Switzerland Lee, Duan-Shin National Tsing Hua U., Taiwan Liebeherr, Jorg U. Virginia, USA Lindemann, Christoph U. Dortmund, Germany Lui, John Chinese U. of Hong Kong, China Marsan, Marco A. Politecnico di Torino, Italy Mazumdar, Ravi U. Waterloo, Canada Merchant, Arif HP Labs, USA Misra, Vishal Columbia U., USA Mitra, Debasis Bell Laboratories, USA Muntz, Richard R. UCLA, USA Nicol, David U. Illinois Urbana-Champaign, USA Perros, Harry North Carolina State U., USA Sanders, William U. Illinois Urbana-Champaign, USA Serazzi, Giuseppe Politecnico di Milano, Italy Setia, Sanjeev George Mason University, USA Smirni, Evgenia College of William and Mary, USA Squillante, Mark IBM Research, USA Stewart, William North Carolina State U., USA Thomasian, Alexander NJIT, USA Trivedi, Kishor Duke U., USA Tucci, Salvatore U. Roma "Tor Vergata", Italy Vernon, Mary U. Wisconsin-Madison, USA Verscheure, Olivier IBM Research, USA Williamson, Carey U. Calgary, Canada Woodside, C. Murray Carleton U., Canada Xia, Cathy IBM Research, USA Yao, David Columbia U., USA Zhang, Zhi-Li U. Minnesota, USA _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 2 09:34:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08843 for ; Wed, 2 Feb 2005 09:34:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLsX-0000YR-VD for mip6-web-archive@ietf.org; Wed, 02 Feb 2005 09:53:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLRH-0007gD-Gh; Wed, 02 Feb 2005 09:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvliv-0006SB-0Q; Mon, 31 Jan 2005 19:16:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27415; Mon, 31 Jan 2005 19:16:47 -0500 (EST) Received: from out010pub.verizon.net ([206.46.170.133] helo=out010.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvm0l-00085O-K5; Mon, 31 Jan 2005 19:35:29 -0500 Received: from cow ([4.12.170.137]) by out010.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050201001352.YLW25119.out010.verizon.net@cow>; Mon, 31 Jan 2005 18:13:52 -0600 From: "Dawn Akin" To: Date: Mon, 31 Jan 2005 18:12:45 -0600 Message-ID: <000201c507f2$e7388c10$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authentication-Info: Submitted using SMTP AUTH at out010.verizon.net from [4.12.170.137] at Mon, 31 Jan 2005 18:13:51 -0600 X-Spam-Score: 0.4 (/) X-Scan-Signature: f90770ef080cd30a3a9496366ec9eae7 X-Mailman-Approved-At: Wed, 02 Feb 2005 09:24:58 -0500 Subject: [Mip6] Call for Papers - Broadnets 2005 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1596711872==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 9b69b1193ec31d87dbcfc64057278e7d This is a multi-part message in MIME format. --===============1596711872== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C507C0.9C9E1C10" This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C507C0.9C9E1C10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ----------------------------------------------------------------------- CALL FOR PAPERS =20 Second Annual International Conference on Broadband Networks (BroadNets 2005) Broadband Applications and Services Symposium October 3 - 7, 2005 Boston, Massachusetts, USA http://www.broadnets.org =20 Submission Deadline Extended: February 25, 2005 ----------------------------------------------------------------------- =20 SCOPE ----- =20 BroadNets 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with high bandwidth available for both wireless and wireline networks. = The conference will consist of the following three symposia: =20 ** Broadband Wireless Networking Symposium: covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer optimization, MAC and emerging physical layer technologies = (UWB, MIMO) for high-speed wireless networking. =20 ** Broadband Optical Networking Symposium: covers WDM technologies, = Ethernet and MPLS integration into the optical layer,=20 Next-Generation SONET/SDH, as well as SAN extensions over = DWDM/SONET/SDH. =20 ** Broadband Applications/Services Symposium: covers middleware and = service architectures for broadband applications, pervasive computing and ubiquitous communications, and universal broadband access = for information services. =20 BroadNets 2005 will thus offer a unique forum for researchers from = academia, government and industry to share ideas and disseminate new results in these important areas. =20 This Call for Papers describes the details for the Broadband Applications/Services Symposium ONLY. (Refer to the www.broadnets.org website for the details of Broadband Optical Networking Symposium and Broadband Wireless Networking Symposium.) This Symposium invites academic and industry researchers to present issues and opportunities = for tomorrow's IT infrastructure as driven by broadband applications and services. We invite the research community to present the most recent advances in this field, to discuss exciting research topics and = development of test beds and applications, and to share their research and = development experiences. We hope to organize one or more panel sessions of industry leaders to offer them an opportunity to outline their vision = for future broadband networks, as well as to offer academic and national laboratory researchers an opportunity to ask questions/provide feedback = to these industry leaders. Our goal is to raise the awareness of new industry developments in the academic community, and, at the same time, = to establish a sound link between applied and theoretical research. =20 Topics of interest for which we are soliciting full-length papers = include, but are not limited to, the following: =20 . Applications for security and privacy . Applications and services for grid networks . Grid middleware . Collaborative remote visualization and virtual reality . Data mining and high-speed file transfer applications . Collaborative computational steering . Multimedia applications for wireless networks . Multimedia applications for optical networks . Video-conferencing and video-telephony . Video-on-demand, TV-on-demand . Ultra Wideband (UWB) applications . Applications in 3G/4G networks . Applications and services in integrated 3GPP-WLAN networks . Applications for wireless indoor & home networks . Applications in large-scale sensor networks . P2P applications . Applications for overlay networks . Multicast applications . Broadband access applications . Pricing models for new services . Standards, licensing and regulation . Economics and business cases . Applications for e-government, e-health and e-science . Storage applications =20 =20 IMPORTANT DATES --------------- =20 Submission Deadline: February 25, 2005 Acceptance Notification: May 15, 2005 Final Manuscript Due: June 1, 2005 =20 PAPER SUBMISSION INSTRUCTIONS ----------------------------- =20 Authors are invited to submit full papers of up to 10 pages in IEEE conference proceedings format. Papers should be submitted in PDF format to the respective symposium through the EDAS system at http://edas.info/Conference.cgi. =20 =20 CONFERENCE ORGANIZING COMMITTEE ------------------------------- =20 General Chair: Dr. Arun Somani, Iowa State University, arun@iastate.edu =20 General Vice Chair: Dr. Thomas Hou, Virginia Tech, thou@vt.edu =20 Technical Program Chairs - Services and Applications Symposium Dr. Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu Dr. Admela Jukan, Georgia Tech, admela.jukan@ece.gatech.edu =20 Technical Program Chair- Wireless Networking Symposium: Dr. Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca =20 Technical Program Chairs - Optical Networking Symposium Dr. David Griffith, NIST, david.griffith@nist.gov Dr. Srini Ramasubramanian, Univ. of Arizona, srini@ece.arizona.edu =20 Workshops Chair: Dr. Wendi Heinzelman, University of Rochester, = wheinzel@ece.rochester.edu Dr. Byrav Ramamurthy, University of Nebraska-Lincoln, byrav@cse.unl.edu Dr. Behcet Sarikaya, University of Northern British Columbia, sarikaya@unbc.ca =20 Tutorials Chair: Dr. Steven Low, Cal. Tech., slow@caltech.edu =20 Panels Chairs: Dr. Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu Dr. Rudra Dutta, NCSU, dutta@csc.ncsu.edu =20 Publicity Chairs: Dr. Bhaskar Krishnamachari, USC, bkrishna@usc.edu Dr. Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com =20 Website/Information Systems Chair: Dr. Shiwen Mao, Virginia Tech, smao@vt.edu =20 Local Arrangements Chairs: Dr. Aura Ganz, Univ. of Massachusetts, Amherst, ganz@ecs.umass.edu Dr. Ling Li, CIENA, linlisu@hotmail.com =20 Publications Chairs: Dr. Ahmed Kamal, Iowa State University, kamal@iastate.edu Dr. Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com =20 Exhibits and Sponsorships Chair: Dr. Sai Shankar N, Philips Research USA, sai.shankar@philips.com =20 Finance Chair: Karen Decker, ICST, karen@icst.org =20 Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, Univ. of Maryland, Baltimore County, krishna@umbc.edu =20 -------------------------------------------------------------------------= - =20 =20 =20 =20 =20 ------=_NextPart_000_0003_01C507C0.9C9E1C10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

--------------------------= ---------------------------------------------

CALL FOR = PAPERS

 

Second = Annual International Conference on Broadband Networks

(BroadNets 2005)

Broadband = Applications and Services Symposium

October 3 - 7, 2005

Boston, Massachusetts, USA

http://www.broadnets.org

 

Submission Deadline Extended: February 25, = 2005

--------------------------= ---------------------------------------------

 

SCOPE

-----

 

BroadNets 2005 is an international conference focusing on broadband networking and = covers the entire gamut of next generation networks

with = high bandwidth available for both wireless and wireline networks.  The conference will consist of the following three = symposia:

 

** = Broadband Wireless Networking Symposium: covers mobility, routing for multihop, multimedia QoS and traffic management,

cross-layer optimization, MAC and emerging physical = layer technologies (UWB, MIMO) for high-speed wireless networking.

 

** = Broadband Optical Networking Symposium: covers WDM technologies, Ethernet and MPLS integration into the optical layer,

Next-Generation SONET/SDH, as well as SAN = extensions over DWDM/SONET/SDH.

 

** = Broadband Applications/Services Symposium: covers middleware and service architectures for broadband applications, pervasive

computing and ubiquitous communications, and universal broadband access for = information services.

 

BroadNets 2005 will thus offer a unique forum for researchers from academia, government = and industry to share ideas and disseminate new

results in these important areas.

 

This = Call for Papers describes the details for the Broadband Applications/Services Symposium ONLY. (Refer to the www.broadnets.org

website for the details of Broadband Optical Networking Symposium and Broadband Wireless Networking Symposium.) This Symposium invites

academic and industry researchers to present issues and opportunities for = tomorrow’s IT infrastructure as driven by broadband applications = and

services.  We invite the research community to present the most recent advances in = this field, to discuss exciting research topics and = development

of = test beds and applications, and to share their research and development = experiences.  We hope to organize one or more panel sessions of

industry leaders to offer them an opportunity to outline their vision for future broadband networks, as well as to offer academic and = national

laboratory researchers an opportunity to ask questions/provide feedback to these = industry leaders.  Our goal is to raise the awareness of = new

industry developments in the academic community, and, at the same time, to = establish a sound link between applied and theoretical research.

 

Topics of interest for which we are soliciting full-length papers include, but are = not limited to, the following:

 

·   =         Applications for security and privacy

·   =         Applications and services for grid networks

·   =         Grid middleware

·   =         Collaborative remote visualization and virtual reality

·   =         Data mining and high-speed file transfer applications

·   =         Collaborative computational steering

·   =         Multimedia applications for wireless networks

·   =         Multimedia applications for optical networks

·   =         Video-conferencing and video-telephony

·   =         Video-on-demand, TV-on-demand

·   =         Ultra Wideband (UWB) applications

·   =         Applications in 3G/4G networks

·   =         Applications and services in integrated 3GPP-WLAN = networks

·   =         Applications for wireless indoor & home networks

·   =         Applications in large-scale sensor networks

·   =         P2P applications

·   =         Applications for overlay networks

·   =         Multicast applications

·   =         Broadband access applications

·   =         Pricing models for new services

·   =         Standards, licensing and regulation

·   =         Economics and business cases

·   =         Applications for e-government, e-health and e-science

·   =         Storage applications

 

 

IMPORTANT DATES

---------------

 

Submission Deadline:          &nbs= p;            = ; February 25, 2005

Acceptance Notification:        = May 15, = 2005

Final Manuscript = Due:           = June 1, = 2005

 

PAPER SUBMISSION INSTRUCTIONS

--------------------------= ---

 

Authors are invited to submit full papers of up to 10 pages in = IEEE

conference proceedings format.  Papers should be submitted in = PDF

format to the respective symposium through the EDAS = system at

http://edas.info/Conferenc= e.cgi.

 

 

CONFERENCE = ORGANIZING COMMITTEE

--------------------------= -----

 

General = Chair:

Dr. = Arun Somani, Iowa State University, arun@iastate.edu

 

General Vice Chair:

Dr. = Thomas Hou, Virginia Tech, thou@vt.edu

 

Technical Program Chairs - Services and Applications Symposium

Dr. = Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu

Dr. = Admela Jukan, Georgia Tech, admela.jukan@ece.gatech.edu

 

Technical Program Chair- Wireless Networking Symposium:

Dr. = Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca

 

Technical Program Chairs - Optical Networking Symposium

Dr. = David Griffith, NIST, david.griffith@nist.gov

Dr. = Srini Ramasubramanian, Univ. of Arizona, srini@ece.arizona.edu

 

Workshops = Chair:

Dr. = Wendi Heinzelman, University of Rochester, wheinzel@ece.rochester.edu=

Dr. = Byrav Ramamurthy, University of = Nebraska-Lincoln, byrav@cse.unl.edu

Dr. = Behcet Sarikaya, University of Northern British Columbia,

sarikaya@unbc.ca

 

Tutorials Chair:

Dr. = Steven Low, Cal. Tech., slow@caltech.edu

 

Panels = Chairs:

Dr. = Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu

Dr. = Rudra Dutta, NCSU, dutta@csc.ncsu.edu

 

Publicity Chairs:

Dr. = Bhaskar Krishnamachari, USC, bkrishna@usc.edu

Dr. = Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com

 

Website/Information Systems Chair:

Dr. = Shiwen Mao, Virginia Tech, smao@vt.edu

 

Local Arrangements Chairs:

Dr. = Aura Ganz, Univ. of Massachusetts, Amherst, ganz@ecs.umass.edu<= /font>

Dr. = Ling Li, CIENA, linlisu@hotmail.com

 

Publications Chairs:

Dr. = Ahmed Kamal, Iowa State University, kamal@iastate.edu

Dr. = Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com

 

Exhibits and Sponsorships Chair:

Dr. = Sai Shankar N, Philips Research USA, sai.shankar@philips.com

 

Finance = Chair:

Karen Decker, ICST, karen@icst.org

 

Steering Committee Co-Chairs:

Dr. = Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu

Dr. = Krishna Sivalingam, Univ. of Maryland, Baltimore County,

krishna@umbc.edu

 

--------------------------= ------------------------------------------------

 

 

 

 

 

------=_NextPart_000_0003_01C507C0.9C9E1C10-- --===============1596711872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1596711872==-- From mip6-bounces@ietf.org Wed Feb 2 09:36:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09083 for ; Wed, 2 Feb 2005 09:36:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLui-0000dl-Fz for mip6-web-archive@ietf.org; Wed, 02 Feb 2005 09:55:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLRI-0007gY-8k; Wed, 02 Feb 2005 09:25:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwB6k-0007JK-DI; Tue, 01 Feb 2005 22:23:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19079; Tue, 1 Feb 2005 22:23:06 -0500 (EST) Received: from out004pub.verizon.net ([206.46.170.142] helo=out004.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwBOz-0001HD-9z; Tue, 01 Feb 2005 22:42:02 -0500 Received: from cow ([4.12.170.137]) by out004.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050202032300.HAAA26988.out004.verizon.net@cow>; Tue, 1 Feb 2005 21:23:00 -0600 From: "Dawn Akin" To: Date: Tue, 1 Feb 2005 21:23:00 -0600 Message-ID: <000501c508d6$7fa747a0$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authentication-Info: Submitted using SMTP AUTH at out004.verizon.net from [4.12.170.137] at Tue, 1 Feb 2005 21:23:00 -0600 X-Spam-Score: 0.4 (/) X-Scan-Signature: f90f4746216faf1f6cbda6dd26dbc608 X-Mailman-Approved-At: Wed, 02 Feb 2005 09:24:58 -0500 Subject: [Mip6] MobiQuitous 2005 - Call for Papers X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0004593066==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8d5cbd3d5548af56dbea64a1d182f942 This is a multi-part message in MIME format. --===============0004593066== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C508A4.350CD7A0" This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C508A4.350CD7A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MobiQuitous 2005 =20 CALL FOR PAPERS =20 The Second Annual International Conference on Mobile and Ubiquitous = Systems: Networking and Services =20 http://www.mobiquitous.org =20 July 17-21, 2005, San Diego, California =20 PAPER SUBMISSION DEADLINE: February 2, 2005 =20 Sponsored by: =20 CreateNet (www.create-net.it) and ICST =20 Technically Co-Sponsored by IEEE Computer Society (Pending) Technically Co-Sponsored by IEEE Communications Society (Pending) Technically Co-Sponsored by ACM SIGMOBILE (Pending) In Cooperation with AAAI =20 Proceedings to be published by IEEE Computer Society Press and to be = made available on IEEE Xplore =20 *********************************************************************** =20 The combination of mobile and ubiquitous computing is emerging as a promising new paradigm with the goal to provide computing and = communication services all the time, everywhere, transparently and invisibly to the = user, using devices embedded in the surrounding physical environment. In this context, the communication devices, the objects with which they = interact, or both may be mobile. The implementation of such a paradigm requires = advances in wireless network technologies and devices, development of = infrastructures supporting cognitive environments, and discovery and identification of=20 ubiquitous computing applications and services. =20 The second Annual International Conference on Mobile and Ubiquitous = Systems: networking and services (Mobiquitous-05) will cover all these aspects, representing a forum where practitioners and researchers coming from the many areas involved in ubiquitous solutions design and deployment will = be able to interact exchanging the cross-layer experiences needed to build = the overall ubiquitous systems. Areas addressed by the conference include: applications, service-oriented computing, middleware, networking, = agents, knowledge management and databases. =20 PAPERS: Technical papers describing original, previously unpublished research, not currently under review by another conference or journal, = are solicited. The conference is interested in contributions addressing all = the areas associated with mobile and ubiquitous architectures, = infrastructure and services. Technical works clearly identifying how the specific contributions fit to an overall working solution are particularly of interest. Topics include, but are not limited to, the following: =20 * Ubiquitous architectures and systems * Wearable computing and personal area network * Wireless technologies for mobile and ubiquitous (Bluetooth, ZigBee, 802.15.x, WiFi) * Incentive-based deployment of ad hoc networks * Reconfigurability and personalization of wireless network * Service discovery mechanisms, knowledge discovery, matching and composition mechanisms * Wireless/mobile service management and delivery * Security, privacy and social issues of mobile and ubiquitous systems * Peer-to-peer knowledge management * Emerging industrial/business scenarios * Multimodal interfaces (speech, video kinetic, tactile) * Smart spaces * Ad hoc and sensor networking * Localization and tracking * Context and location aware application * Multimedia encoding and transcoding * Middleware services * Agent technologies in ubiquitous, wearable, and mobile systems * Hardware and software platforms for ubiquitous systems, and testbeds * User interfaces * Toolkits, development environments, and languages for ubiquitous = computing * Ontologies for mobile and ubiquitous computing =20 =20 SUBMISSION INSTRUCTIONS: All paper submissions will be handled electronically (see the conference web page for details). Authors should prepare a Portable Document Format (PDF) or postscript version of their = full paper. Papers must not exceed 8 pages double column (US Letter size, = 8.5 x 11 inches) including text, figures and references. The font size must be = at least 10 points. The deadline for registering the title and the abstract = of the paper with our electronic submission system is February 2, 2005. The deadline for submitting the actual paper is February 9, 2005. All = deadlines are 11:59PM PST. =20 PUBLICATION: All submitted papers will be rigorously reviewed by = technical program committee members. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in a ACM/Kluwer MONET special issue. =20 WORKSHOPS: Proposals for one-day workshops to be held in conjunction = with the conference are solicited. A maximum of 2 pages should be submitted which include the workshop name, its scope and a list of topic of = interests. Proposals should be submitted to both the Workshop co-Chairs by December = 17 2004. =20 DEMOS: Proposals for research and industrial demos are solicited. A = maximum of 2 pages should be submitted which include a description of the demo = and needed resources from the conference organizers. Proposals should be submitted to Dr. Ramiro Liscano (Demo Chair) rliscano@ieee.org by May = 29th, 2005. =20 IMPORTANT DATES: =20 Paper registration deadline February 2, 2005 Full paper submission deadline February 9, 2005 Notification of acceptance April 29, 2005 Camera-ready version due May 15, 2005 =20 ORGANIZING COMMITTEE =20 General Chair: Ramesh Rao (Univ. of California, San Diego) =20 General Co-Vice-Chairs: Chiara Petrioli (Universit di Roma La Sapienza) Krishna Sivalingam (University of Maryland, Baltimore County) =20 Technical Program Co-Chairs: =20 Networking: Suresh Singh (Portland State University) Philippe Bonnet (University of Copenhagen) =20 Services/Knowledge Management: Anupam Joshi (University of Maryland, Baltimore County) Ryusuke Masuoka (Fujitsu Labs of America) =20 Publicity Co-Chairs: Andreas Savvides (Yale University) and Mohamed Younis (University of Maryland, Baltimore County) =20 Panels Chairs: Jennifer Hou (University of Illinois Urbana Champaign) =20 Workshop Chairs: Stefano Basagni (Northeastern University) Prithwish Basu (BBN Technologies) =20 Demos Chair: Ramiro Liscano (University of Ottawa) =20 Publications Chair: Antonis Kalis (Athens Information Technology) =20 Local Arrangements Chair:=20 Kang Wang, Qualcomm Inc. =20 Finance Chair: Karen Decker (ICST Texas,USA) =20 Accommodations Chair: Kathy Kunz (ICST California,USA) =20 Registration Chair:=20 Vishal Anand, SUNY College at Brockport =20 Steering Committee:=20 Imrich Chlamtac (CreateNet, Inc.) Michele Zorzi (Universita di Padova) =20 =20 ------=_NextPart_000_0006_01C508A4.350CD7A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
MobiQuitous =
2005
 
CALL FOR PAPERS
 
The =
Second Annual International Conference on Mobile and =
Ubiquitous Systems: Networking and Services
 
http://www.mobiquitous.org
= 
 
July 17-21, 2005, San Diego, =
California
 
PAPER SUBMISSION DEADLINE: =
February 2, 2005
 
Sponsored =
by:
 
CreateNet =
(www.create-net.it) and ICST
 
Technically Co-Sponsored by IEEE =
Computer Society (Pending)
Technically Co-Sponsored by IEEE =
Communications Society (Pending)
Technically Co-Sponsored by ACM =
SIGMOBILE (Pending)
In Cooperation with =
AAAI
 
Proceedings to be published by IEEE =
Computer Society Press and to be made available on IEEE =
Xplore
 
**********************************************=
*************************
 
The =
combination of mobile and ubiquitous computing is emerging as a =
promising new paradigm with the goal to provide computing and =
communication services all the time, everywhere, transparently and =
invisibly to the user, using devices embedded in the surrounding =
physical environment. In this context, the communication devices, the =
objects with which they interact, or both may be mobile. The =
implementation of such a paradigm requires advances in wireless network =
technologies and devices, development of infrastructures supporting =
cognitive environments, and discovery and identification of =

ubiquitous computing applications and =
services.
 
The =
second Annual International Conference on Mobile and =
Ubiquitous Systems: networking and services (Mobiquitous-05) will cover =
all these aspects, representing a forum where practitioners and =
researchers coming from the many areas involved in ubiquitous solutions =
design and deployment will be able to interact exchanging the =
cross-layer experiences needed to build the overall ubiquitous systems. =
Areas addressed by the conference include: applications, =
service-oriented computing, middleware, networking, agents, knowledge =
management and databases.
 
PAPERS: Technical papers =
describing original, previously unpublished research, not currently =
under review by another conference or journal, are solicited. The =
conference is interested in contributions addressing all the areas =
associated with mobile and ubiquitous architectures, infrastructure and =
services. Technical works clearly identifying how the specific =
contributions fit to an overall working solution are particularly of =
interest. Topics include, but are not limited to, the =
following:
 
* =
Ubiquitous architectures and systems
* =
Wearable computing and personal area =
network
* =
Wireless technologies for mobile and ubiquitous (Bluetooth, =
ZigBee,
  =
802.15.x, WiFi)
* =
Incentive-based deployment of ad hoc =
networks
* =
Reconfigurability and personalization of wireless =
network
* Service =
discovery mechanisms, knowledge discovery, matching =
and
  =
composition mechanisms
* =
Wireless/mobile service management and =
delivery
* =
Security, privacy and social issues of mobile and ubiquitous =
systems
* =
Peer-to-peer knowledge management
* =
Emerging industrial/business scenarios
* =
Multimodal interfaces (speech, video kinetic, =
tactile)
* Smart =
spaces
* =
Ad hoc and sensor networking
* =
Localization and tracking
* Context =
and location aware application
* =
Multimedia encoding and transcoding
* =
Middleware services
* =
Agent technologies in ubiquitous, wearable, and mobile =
systems
* =
Hardware and software platforms for ubiquitous systems, and =
testbeds
* User =
interfaces
* =
Toolkits, development environments, and languages for ubiquitous =
computing
* =
Ontologies for mobile and ubiquitous computing
 
 
SUBMISSION INSTRUCTIONS:  =
All paper submissions will be handled electronically (see =
the conference web page for details). Authors should prepare a Portable =
Document Format (PDF) or postscript version of their full paper.  =
Papers must not exceed 8 pages double column (US Letter size, 8.5 x 11 =
inches) including text, figures and references. The font size must be at =
least 10 points. The deadline for registering the title and the abstract =
of the paper with our electronic submission system is February 2, 2005. =
The deadline for submitting the actual paper is February 9, 2005. All =
deadlines are 11:59PM PST.
 
PUBLICATION: All submitted =
papers will be rigorously reviewed by technical program committee =
members. Accepted papers will be published in the conference =
proceedings.  Papers of particular merit will be proposed for =
publication in a ACM/Kluwer MONET special issue.
 
WORKSHOPS: Proposals for one-day workshops to =
be held in conjunction with the conference are solicited.  =
A maximum of 2 pages should be submitted which include the =
workshop name, its scope and a list of topic of interests.  =
Proposals should be submitted to both the Workshop co-Chairs by December =
17 2004.
 
DEMOS: =
Proposals for research and industrial demos are solicited.  =
A maximum of 2 pages should be submitted which include a =
description of the demo and needed resources from the conference =
organizers. Proposals should be submitted to Dr. Ramiro Liscano (Demo =
Chair) rliscano@ieee.org by May 29th, 2005.
 
IMPORTANT DATES:
 
     Paper registration =
deadline         =
February 2, 2005
     Full paper =
submission deadline      February =
9, 2005
   Notification of =
acceptance          =
April 29, 2005
 Camera-ready version =
due            =
May 15, 2005
 
ORGANIZING COMMITTEE
 
General =
Chair:
Ramesh Rao (Univ. of =
California, San Diego)
 
General =
Co-Vice-Chairs:
Chiara Petrioli (Universit di Roma La =
Sapienza)
Krishna Sivalingam (University =
of Maryland, Baltimore County)
 
Technical Program =
Co-Chairs:
 
Networking:=

Suresh Singh (Portland State =
University)
Philippe Bonnet (University of =
Copenhagen)
 
Services/Knowledge =
Management:
Anupam Joshi (University of =
Maryland, Baltimore County)
Ryusuke Masuoka (Fujitsu Labs of =
America)
 
Publicity =
Co-Chairs:
Andreas Savvides (Yale =
University) and
Mohamed Younis (University of =
Maryland, Baltimore County)
 
Panels =
Chairs:
Jennifer Hou (University of =
Illinois Urbana Champaign)
 
Workshop =
Chairs:
Stefano Basagni (Northeastern =
University)
Prithwish Basu  (BBN =
Technologies)
 
Demos =
Chair:
Ramiro Liscano (University of =
Ottawa)
 
Publications =
Chair:
Antonis Kalis (Athens =
Information Technology)
 
Local =
Arrangements Chair: 
Kang Wang, Qualcomm =
Inc.
 
Finance =
Chair:
Karen Decker (ICST =
Texas,USA)
 
Accommodations Chair:
Kathy Kunz (ICST =
California,USA)
 
Registration Chair: =

Vishal Anand, SUNY College at =
Brockport
 
Steering Committee: =

Imrich Chlamtac (CreateNet, =
Inc.)
Michele Zorzi (Universita di =
Padova)
 



 
------=_NextPart_000_0006_01C508A4.350CD7A0-- --===============0004593066== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0004593066==-- From mip6-bounces@ietf.org Wed Feb 2 09:38:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09281 for ; Wed, 2 Feb 2005 09:38:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwLww-0000hH-QE for mip6-web-archive@ietf.org; Wed, 02 Feb 2005 09:57:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwLRI-0007gq-W4; Wed, 02 Feb 2005 09:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwBAT-0008B6-9A; Tue, 01 Feb 2005 22:27:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19338; Tue, 1 Feb 2005 22:26:59 -0500 (EST) Received: from out009pub.verizon.net ([206.46.170.131] helo=out009.verizon.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwBSj-0001Ml-Qt; Tue, 01 Feb 2005 22:45:54 -0500 Received: from cow ([4.12.170.137]) by out009.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20050202032652.EERD4172.out009.verizon.net@cow>; Tue, 1 Feb 2005 21:26:52 -0600 From: "Dawn Akin" To: Date: Tue, 1 Feb 2005 21:26:52 -0600 Message-ID: <002d01c508d7$0a007480$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Authentication-Info: Submitted using SMTP AUTH at out009.verizon.net from [4.12.170.137] at Tue, 1 Feb 2005 21:26:52 -0600 X-Spam-Score: 0.4 (/) X-Scan-Signature: e233469409eae36784776b094a259e13 X-Mailman-Approved-At: Wed, 02 Feb 2005 09:24:58 -0500 Subject: [Mip6] QShine 2005 - Call for Papers X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1282122777==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 2cf79100e158081ec662b95abd1ecd80 This is a multi-part message in MIME format. --===============1282122777== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C508A4.BF660480" This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C508A4.BF660480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable -------------------------------------------------------------------------= --- - Call for Papers - QShine 2005 -------------------------------------------------------------------------= --- - The Second International Conference on Quality of Service in Heterogeneous Wired/Wireless Networks August 22 - 24, 2005, Orlando Florida USA =20 Sponsored by (pending approval) IEEE COMSOC (TCCC and TCPC) and ACM SigMobile and SigComm Bell Mobility, Ericsson =20 Submission Deadline: March 15, 2005 =20 -------------------------------------------------------------------------= --- - http://www.qshine.org/ -------------------------------------------------------------------------= --- - =20 SCOPE ----- =20 Recent technological developments in broadband high-speed networks, peer-to-peer networks, wireless and mobile networks, and grid computing = have led to new challenging problems, such as providing QoS support to the emerging multimedia applications across both wired and wireless = networks. This conference will focus on all aspects of QoS support for = heterogeneous wired and wireless networks with the theme on cross-layer design. It = will serve as a forum for researchers from both electrical engineering and computer science to present latest research results on QoS issues for = both wired and wireless networks, with the hope that electrical engineers and computer scientists will work together to develop viable cross-layer = design methodologies. The conference will feature prominent invited speakers as well as papers by top researchers in the field. =20 Papers addressing QoS support, ranging from the link layer to the application layer, over wired and wireless networks are solicited. Authors are encouraged to submit theoretical and/or practical results of significance. The scope of the conference includes, but is = not limited to: =20 * QoS in WLAN, WPAN, WMAN and = WiMAX (IEEE 802.11/15/16/20) * QoS in wireless sensor and = ad-hoc networks * QoS in cellular and satellite networks * QoS support across heterogeneous wired and wireless subnetworks * MAC protocols with QoS support * Scheduling, resource management, queue management, and admission control * QoS in mobile environment, = handoff * QoS routing and mobile IP * Traffic engineering and shaping * MPLS and GMPLS * Restoration and survivability * Transport protocols for = end-to-end QoS support * Cross-layer error control and = delay control * Cross-layer optimization for = energy, network lifetime, and capacity * Topology control for QoS support = in wireless networks * Wireless multimedia applications/services * QoS support with multi-mode = radio * Middleware for QoS support * Security aspects of QoS systems * QoS pricing and billing * Variable and adaptive QoS * QoS modeling and measurement * QoS and differentiated services architectures, protocols, and systems * QoS specification, metrics, and analysis * QoS in peer-to-peer, grid, and overlay networks =20 Accepted papers will be published in the conference proceedings. Papers = of particular merit will be selected for consideration of a fast track publication in a special issue for = ACM/Kluwer Wireless Networks (WINET)(approved) and a special section in IEEE Transactions on Vehicular Technology (pending approval). =20 PAPER SUBMISSION GUIDELINES --------------------------- =20 Papers should not exceed 20 pages, must be unpublished and must not be submitted for publication elsewhere. All papers should be submitted electronically to EDAS system at http://edas.info/Conferences.cgi in Postscript or Adobe PDF format. Electronic submission instructions will be available at http://www.qshine.org/submission.html. =20 IMPORTANT DATES --------------- =20 Submission Deadline: March 15, 2005 Notification of Acceptance: May 15, 2005 Camera-ready Manuscripts Due: June 15, 2005 Conference Dates: August 22-24, 2005 =20 =20 ORGANIZING COMMITTEE -------------------- =20 General Chair: =20 Dr. Yuguang "Michael" Fang, University of Florida, USA fang@ece.ufl.edu =20 General Vice Chairs: =20 Dr. Hisashi Kobayashi, Princeton University, USA hisashi@princeton.edu =20 Mr. Vic DiCiccio, Bell-University Laboratory, Waterloo, Canada =20 =20 Technical Program Chair: =20 Dr. Xuemin (Sherman) Shen, University of Waterloo, Canada xshen@bbcr.uwaterloo.ca =20 =20 Steering Committee: =20 Dr. Imrich Chlamtac, President, CreateNet Research Consortium, USA, = Chair Dr. Michael Fang, University of Florida, USA, Co-Chair Dr. Hisashi Kobayashi, Princeton University, USA Dr. Ariel Orda, Technion, Israel Dr. Xuemin (Sherman) Shen, University of Waterloo, Canada =20 Publications Chair: =20 Dr. Xiuzhen Cheng, George Washington University, USA =20 Publicity Chair: =20 Dr. Jelena Misic, University of Manitoba, Canada jmisic@cs.umanitoba.ca =20 Dr. Mihaela Cardei, Florida Atlantic University, USA mihaela@cse.fau.edu =20 Poster Chair: =20 Dr. Jianping Pan, NTT MCL, USA jpan@nttmcl.com =20 Local Arrangement Chairs: =20 Dr. Damla Turgut, University of Central Florida, USA, Chair turgut@cs.ucf.edu =20 Dr. Lei Wei, University of Central Florida, USA, Co-Chair lei@ee.ucf.edu =20 Website/Information Chair: =20 Mr. Hongqiang Zhai, University of Florida, USA zhai@ecel.ufl.edu =20 ******************************************************** QShine 2005 TPC committee =20 Chair: Dr. Xuemin (Sherman) Shen, University of Waterloo, Canada =20 Sudhir Aggarwal, Florida State University Giuseppe Bianchi, University of Roma Tor Vergata, Italy Gregor V. Bochmann, University of Ottawa, Canada Luciano Bononi, University of Bologna, Italy Andrew T. Campbell, Columbia Guohong Cao, Penn State = University Lin Cai, University of Waterloo, Canada Xiuzhen Cheng, George Washington University Sunghyun Choi, National Seoul University Sajal K. Das, University of Texas at Arlington Ehab Elmallah, University of Alberta, Canada Guangbin Fan, University of Mississippi Alois Ferscha, University of Linz, Austria Mohsen Guizani, Western Michigan University Zhu Han, University of Maryland at College Park Hossam Hassanein, Queens University, Canada Hussein Mouftah , University of Ottawa, Canada Hisashi Kobayashi, Princeton University Tho Le-Ngoc, McGill = University, Canada Baochun Li, University of = Toronto Geoffrey Li, George Tech Wei Li, University of Toledo Lavy Libman, Nicta Yibei Ling, Telcordia Jiangchuan Liu, Simon Fraser University Mingyan Liu, University Michigan at Ann Arbor Songwu Lu, UCLA King-Shan Lui, Hong Kong University Brian Mark, George Mason University Jelena Misic, University of Manitoba, Canada Klara Nahrstedt, UUIC Mirela Notare Barddal, University of Brazil Stephan Olariu, Old Dominion University Mohamed Ould-Khaoua, University of Glasgow, UK Kihong Park, Purdue University Chunming Qiao, SUNY at Buffalo Aladdin O.M. Saleh, Bell Mobility, Canada Anthony Soong, Ericsson, USA Nikoletseas E. Sotiris, Computer Technology Institute, Greece Alex Sprintson, Caltech Violet Syrotiuk, Arizona State University Kun Tan, Microsoft Research = Asia Terence D. Todd, McMaster University, Canada Dapeng Wu, University of = Florida Hongyi Wu, University of Louisiana at Lafayette Jie Wu, Florida Atlantic University Geoffrey Xie, Naval Post Graduate School Qian Zhang, Microsoft Asia Research, China Weihua Zhuang, University of Waterloo, Canada Albert Zomaya, University of Sydney, Australia =20 =20 =20 ------=_NextPart_000_002E_01C508A4.BF660480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
----------------------------------------------=
-------------------------------
Call for Papers - QShine =
2005
----------------------------------------------=
-------------------------------
The Second International Conference on =
Quality of Service in
Heterogeneous Wired/Wireless =
Networks
August 22 - 24, 2005, Orlando =
Florida USA
 
Sponsored =
by (pending approval)
IEEE COMSOC (TCCC and TCPC) and ACM SigMobile =
and SigComm
Bell Mobility, =
Ericsson
 
Submission Deadline: March 15, =
2005
 
----------------------------------------------=
-------------------------------
http://www.qshine.org/
----------------------------------------------= -------------------------------
 
SCOPE
-----
 
Recent technological developments in =
broadband high-speed networks, peer-to-peer networks, wireless and =
mobile networks, and grid computing have led to new challenging =
problems, such as providing QoS support to the emerging multimedia =
applications across both wired and wireless networks. This conference =
will focus on all aspects of QoS support for heterogeneous wired and =
wireless networks with the theme on cross-layer design. It will serve as =
a forum for researchers from both electrical engineering and computer =
science to present latest research results on QoS issues for both wired =
and wireless networks, with the hope that electrical engineers and =
computer scientists will work together to develop viable cross-layer =
design methodologies. The conference will feature prominent invited =
speakers as well as papers by top researchers in the =
field.
 
Papers =
addressing QoS support, ranging from the link layer to the application =
layer, over wired and wireless networks are
solicited. Authors are encouraged to submit =
theoretical and/or practical results of significance. The scope of the =
conference includes, but is not limited to:
 
       &nbs=
p;            =
;            =
      * QoS in WLAN, WPAN, WMAN and WiMAX (IEEE =
802.11/15/16/20)
       &nbs=
p;            =
;            =
      * QoS in wireless sensor and ad-hoc =
networks
       &nbs=
p;            =
;            =
      * QoS in cellular and satellite =
networks
       &nbs=
p;            =
;            =
      * QoS support across heterogeneous wired =
and wireless subnetworks
       &nbs=
p;            =
;            =
      * MAC protocols with QoS =
support
       &nbs=
p;            =
;            =
      * Scheduling, resource management, queue =
management, and admission control
       &nbs=
p;            =
;            =
      * QoS in mobile environment, =
handoff
       &nbs=
p;            =
;            =
      * QoS routing and mobile =
IP
       &nbs=
p;            =
;            =
      * Traffic engineering and =
shaping
       &nbs=
p;            =
;            =
      * MPLS and =
GMPLS
        =
            &=
nbsp;           &n=
bsp;      * Restoration and =
survivability
       &nbs=
p;            =
;            =
      * Transport protocols for end-to-end QoS =
support
       &nbs=
p;            =
;            =
      * Cross-layer error control and delay =
control
       &nbs=
p;            =
;            =
      * Cross-layer optimization for energy, =
network lifetime, and capacity
       &nbs=
p;            =
;            =
      * Topology control for QoS support in =
wireless networks
       &nbs=
p;            =
;            =
      * Wireless multimedia =
applications/services
       &nbs=
p;            =
;            =
      * QoS support with multi-mode =
radio
       &nbs=
p;            =
;            =
      * Middleware for QoS =
support
       &nbs=
p;            =
;            =
      * Security aspects of QoS =
systems
       &nbs=
p;            =
;            =
      * QoS pricing and =
billing
       &nbs=
p;            =
;            =
      * Variable and adaptive =
QoS
       &nbs=
p;            =
;            =
      * QoS modeling and =
measurement
       &nbs=
p;            =
;            =
      * QoS and differentiated services =
architectures, protocols, and systems
       &nbs=
p;            =
;            =
      * QoS specification, metrics, and =
analysis
       &nbs=
p;            =
;            =
      * QoS in peer-to-peer, grid, and overlay =
networks
 
Accepted =
papers will be published in the conference proceedings. Papers of =
particular merit will be selected for
consideration of a fast track publication in =
a special issue for ACM/Kluwer Wireless Networks (WINET)(approved) =
and
a special section in IEEE Transactions on =
Vehicular Technology (pending approval).
 
PAPER =
SUBMISSION GUIDELINES
---------------------------
 
Papers =
should not exceed 20 pages, must be unpublished and must not be =
submitted for publication elsewhere. All papers should be submitted =
electronically to EDAS system at http://edas.info/Conferences.cgi in =
Postscript or Adobe PDF format.
Electronic submission instructions will be =
available at =
http://www.qshine.org/submission.html.
 
IMPORTANT =
DATES
---------------
 
  =
Submission =
Deadline:          &nbs=
p; March 15, 2005
Notification of =
Acceptance:     May 15, 2005
 Camera-ready Manuscripts Due:   =
June 15, 2005
      Conference =
Dates:           &=
nbsp;   August 22-24, 2005
 
 
ORGANIZING COMMITTEE
--------------------
 
General =
Chair:
 
Dr. =
Yuguang "Michael" Fang, University of Florida, =
USA
fang@ece.ufl.edu
 
General Vice =
Chairs:
 
Dr. =
Hisashi Kobayashi, Princeton University, USA
hisashi@princeton.edu
 
Mr. Vic =
DiCiccio, Bell-University Laboratory, Waterloo, =
Canada
 
 
Technical Program =
Chair:
 
Dr. =
Xuemin (Sherman) Shen, University of Waterloo, =
Canada
xshen@bbcr.uwaterloo.ca
 
 
Steering =
Committee:
 
Dr. =
Imrich Chlamtac, President, CreateNet Research Consortium, =
USA, Chair
Dr. Michael Fang, University of =
Florida, USA, Co-Chair
Dr. Hisashi Kobayashi, =
Princeton University, USA
Dr. Ariel Orda, Technion, =
Israel
Dr. Xuemin (Sherman) Shen, =
University of Waterloo, Canada
 
Publications =
Chair:
 
Dr. =
Xiuzhen Cheng, George Washington University, USA
 
Publicity =
Chair:
 
Dr. =
Jelena Misic, University of Manitoba, Canada
jmisic@cs.umanitoba.ca
 
Dr. =
Mihaela Cardei, Florida Atlantic University, USA
mihaela@cse.fau.edu
 
Poster =
Chair:
 
Dr. =
Jianping Pan, NTT MCL, USA
jpan@nttmcl.com
 
Local Arrangement =
Chairs:
 
Dr. Damla =
Turgut, University of Central Florida, USA, =
Chair
turgut@cs.ucf.edu
 
Dr. Lei =
Wei, University of Central Florida, USA, =
Co-Chair
lei@ee.ucf.edu
 
Website/Information =
Chair:
 
Mr. Hongqiang Zhai, University =
of Florida, USA
zhai@ecel.ufl.edu
 
**********************************************=
**********
QShine 2005 TPC =
committee
 
Chair: =
Dr. Xuemin (Sherman) Shen, University of Waterloo, =
Canada
 
  =
Sudhir Aggarwal, Florida State University
        =
         Giuseppe Bianchi, =
University of Roma Tor Vergata, Italy
       &nbs=
p; Gregor V. Bochmann, University of Ottawa, =
Canada
     Luciano Bononi, =
University of Bologna, Italy
       &nbs=
p;            =
;            =
          Andrew T. Campbell, =
Columbia
       &nbs=
p;            =
;            =
          Guohong Cao, =
Penn State University
 Lin Cai, University of =
Waterloo, Canada
     Xiuzhen Cheng, =
George Washington University
  Sunghyun Choi, National =
Seoul University
        =
Sajal K. Das, University of Texas at Arlington
     Ehab Elmallah, =
University of Alberta, Canada
Guangbin Fan, University of =
Mississippi
   Alois Ferscha, =
University of Linz, Austria
    Mohsen =
Guizani, Western Michigan University
      =
  Zhu Han, University of Maryland at College =
Park
    Hossam Hassanein, =
Queens University, Canada
       Hussein =
Mouftah , University of Ottawa, Canada
Hisashi Kobayashi, Princeton =
University
  =
            &=
nbsp;           &n=
bsp;           =
    Tho Le-Ngoc, McGill University, =
Canada
       &nbs=
p;      =
            &=
nbsp;           &n=
bsp;   Baochun Li, University of =
Toronto
       &nbs=
p;            =
;            =
          Geoffrey Li, =
George Tech
       &nbs=
p;            =
;            =
          Wei Li, =
University of Toledo
       &nbs=
p;            =
;            =
          Lavy Libman, =
Nicta
       &nbs=
p;            =
;            =
          Yibei Ling, =
Telcordia
Jiangchuan Liu, Simon Fraser =
University
      Mingyan Liu, =
University Michigan at Ann Arbor
       &nbs=
p;            =
;            =
          Songwu Lu, =
UCLA
       &nbs=
p;            =
;            =
          King-Shan Lui, =
Hong Kong University
       &nbs=
p;            =
;            =
          Brian Mark, =
George Mason University
     Jelena Misic, =
University of Manitoba, Canada
       &nbs=
p;            =
;            =
          Klara Nahrstedt, =
UUIC
    Mirela Notare Barddal, =
University of Brazil
Stephan Olariu, Old Dominion =
University
        =
Mohamed Ould-Khaoua, University of Glasgow, =
UK
       &nbs=
p;            =
;            =
          =
Kihong Park, Purdue University
       &nbs=
p;            =
;            =
          Chunming Qiao, =
SUNY at Buffalo
  Aladdin O.M. Saleh, Bell =
Mobility, Canada
       &nbs=
p;            =
;            =
          Anthony Soong, =
Ericsson, USA
       &nbs=
p;            =
;   Nikoletseas E. Sotiris, Computer Technology Institute, =
Greece
       &nbs=
p;            =
;            =
          Alex Sprintson, =
Caltech
  Violet Syrotiuk, Arizona =
State University
       &nbs=
p;            =
;            =
          Kun Tan, =
Microsoft Research Asia
     Terence D. Todd, =
McMaster University, Canada
       &nbs=
p;            =
;            =
          Dapeng Wu, =
University of Florida
       &nbs=
p; Hongyi Wu, University of Louisiana at =
Lafayette
       &nbs=
p;            =
;            =
          Jie =
Wu, Florida Atlantic University
 Geoffrey Xie, Naval Post =
Graduate School
   Qian Zhang, Microsoft Asia =
Research, China
      Weihua Zhuang, =
University of Waterloo, Canada
       Albert =
Zomaya, University of Sydney, Australia
 
 



 
------=_NextPart_000_002E_01C508A4.BF660480-- --===============1282122777== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1282122777==-- From ackzrcwmgfcpdr@msn.com Wed Feb 2 11:53:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28300; Wed, 2 Feb 2005 11:53:08 -0500 (EST) Received: from [200.162.197.93] (helo=132.151.6.1) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CwO32-0005MF-65; Wed, 02 Feb 2005 12:12:14 -0500 Received: from [110.26.120.98] (helo=..dearriba.com) by smtp2.cistron.nl with esmtp ( 3.35 #1 ()) id 409LFL-0027PT-26 Message-ID: <95773393144732.R37489@.noc..gr> Sender: freeradius-devel-ackzrcwmgfcpdr@msn.com X-Mailman-Version: 2.0.1 Date: Wed, 02 Feb 2005 21:43:06 +0500 From: "Rachelle Bishop" To: midcom-admin@ietf.org Subject: Via-gra, Xanaax are Che.ap Here Midcom-admin X-Spam-Score: 7.3 (+++++++) X-Spam-Flag: YES X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Wide range of medss available to choose in our stores. Saveee uup to 7o % Vicodiin, Viiagraa, Ciallis, Vallium, Xanaax and many moore.. http://vigra4.info/in.php?aid=56 Happy New Year Od3sE8fLrlM4FlsYOxIcSGCxrgE0RLRh62qlpeVULdo From fikgbz@o2.pl Wed Feb 2 14:19:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16372; Wed, 2 Feb 2005 14:19:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQL1-0002BG-Iq; Wed, 02 Feb 2005 14:38:57 -0500 Received: from [84.5.56.106] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CwQ2Q-00017K-9J; Wed, 02 Feb 2005 14:19:42 -0500 Received: from symphony-81.iinet.net.au ([240.84.208.246]:1906 "HELO mail.ies.edu") by ies.edu with SMTP id ; Wed, 02 Feb 2005 18:15:32 -0100 Date: Wed, 02 Feb 2005 16:13:32 -0300 Message-Id: <6.6.06.2081924.0083fc70@ies.edu> From: "Burt Darling" To: Subject: Absolutely lowest. X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 5.6 (+++++) X-Spam-Flag: YES X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit meme only . septacro resorcinol cattail. sanctify throttle scuffle dentistry glenn simplicity cumberland egipt. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit describe writ
You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web
Guaranteed.
 
 
 
 
 
 
.
.
.
http://www.193.blueriseny.com/ You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web Guaranteed.
.  
   
NOMORE ------------A85031401794097-- ------------A48356845382213 Content-Type: image/jpeg; name="imperceivable.JPG" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7RkSUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAAB AAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9m ZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4 AAAAAABwAAD/////////////////////////////A+gAAAAA//////////////////////////// /wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////////// A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAADOEJJTQQMAAAA ABeBAAAAAQAAAGsAAABwAAABRAAAjcAAABdlABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA//4AJkZp bGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDUuMP/uAA5BZG9iZQBkgAAAAAH/2wCEAAwI CAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDP/AABEIAHAAawMBIgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAA AAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggF AwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNU ZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH 1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNT FWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaW prbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOb+q+bXR1E5Fn0q63emfBziG7v+2967Kn6x 7omzcPBwD/8Aq9y4fpvRPrJYWX09JyLq7GyCAIc13DgX/mq9k4PUcGg5HUOn5uDS3nIdWTW08e99 Rdtb/ZWPzfJe5MzF7V6Dxfg9B7+KQHuH1bfrImH/AE4ve4vVcOxw9Vg2zqWEiP7Di5qpdbyOnZe4 NOyBNVroDmO5923/AAH+kqXG4me1zi2rJbaSNAHNB/6R3KxiW23dRoxy7ffa8NpxwQ4ucdB6np7n Mqb+fYqUOSmJgA0QbHp4Z/8AoqJRxCMsnFpR/S9P0dOyx+DZVT1bFtwshzfUrxyW2PeP9LurPoNp rc7b/Pet6v8AO11KzWzMvc23BxXgNmX2AHQ8t2j+T/KXe5+FiZ1TaMmltzqNr2AwS2wD27D+b7fa 7/g1Zow6KWBjWiBpHbTyW0eWAOhrq4wyAjUX+T5zfbU0H1WOpdwQBuH9l309un83YyxiyW5ruo3v x+k42Rm21/ztpaK6m7ve43ZD37Wt/d+gvUeqdA6P1OiyvMx2+4EG2ua7Bpy22ra5ctjjHxumY+Li DZj07msZoeA39JYYbvvsnfdb+fY+xTY8ZJoy6NPneZjhxiUYcUydATUXb+rRoxunU02uByPz2tAk OOuw1tLneptb/g/VZZs9Wv2LbbZWY5E8AtcD/wBJq4TJbVlUuoyK221OEFp+/wBrh7q3/uWs99b/ AHrj87r3VOjZd3S3Te0Niq1z3MD2PH6Ky6lvsf7f51n+lYnSiY7epHI80OZPCRwTFdPTK/3Xteu9 dvzPrQ3o/Sm/abG47Xv9Mja1xc/1ftFrT6dddFfo7n/9a/nf0a2XdNtswBhdRyKbLX/zW0E7CNR6 VlrhY/Zt/d/7+uS+oltdeBmZxm3Jyb66L3n2uDGD1GMrezc9u71GbPb9P/i2LpTY2pz6qLDlvLQx 1dP87tYA1jsy207Gen7vTyLvSos/62qM8lyPCD/W1/6MXYyQ9uQx2KgaE6+b+85P1a6l1zo/1rr6 N1kh9HUa3Nxr63A45sp/SN9GGs9OxzfVZfRtZdv9D/B+kvQl5d9YM60VC82udlYr22VV1++uuxjv Wba7Kur3W21fQZXTVjM9O39HbkV+ou6/5zdP/lf8n/tTj/Af+TUkcoOCWg9NaXprLuqeKYyY81i5 mUb4P3I/uv8A/9De/wCeOJU0iwtrd23e2fvWtf1/AuxTTt3ttZtNbgCCHN+i5iWNViPxhU+qt1e3 Z6ZY3ZtHt2ent2bNv5n0FzvXvqY641s6HlO6dTe/0snFaT6e1/8A3Gd7rcVu79Hbi1v+y2sf/gv8 JBLDMRPqvvp0VD4hiyziDj4AT6TxX6j8vE+fYf1bv6hkXHB2OxW3WMqe4yIa52xum7d7P+gu0+rf TumfVgHJL25vVnDbXtbFdU99D/6ms/0df84pV/4s+pdMosyundQ/WQ3THsYPRsaP8Fbth39v/BrO 6KbupXZdefacK3DJruw8Umu4A6eu3Js9X6Nn836P+F/nrPTu/SDJm4ImR2j/AC+Vs48XHKh17F63 oHX2ZPXz0ptu/Ipotycx2hhwdTTXj/8AGfpn23/6L06av9Iup9RxOmg8dD/0f/Ml5l0/6rP+rXUq frH0a9+f0tofVmY5AGQypw/SuY0e270Pbc+v9Hf7P8Iu6o6jTfUy6ixt1No3V2sMtcP3mpvvRlRE uIUr2TqCKo19jeybYoLg0vnsAD5S7f7dv9ZecYeZ6OVd06/R7HTWeN2nH9ayrZaxdrn2h9BAkuDQ AR2kfu/NeYfWTLrxusHHHuu1c8Aw+vX9F6n/AAv5+z6f/QShklxgAX3YeY5EZ8dEiMh8t/1npRcP 3hJ4KwvrB0bO6n1XBpwMZ+TlPoeS1o4rFnsfbY7bXXXvNnvsfsS6X1TKzCW2VANYQX5TnbGiPd7m Q91lzv3af/A13XSep2Yhb030g3OsJsLCWg21mfS9C4PfX69Nbf5u/wDnv5yu2pSHPilL2zKpnp/6 Ew8l8P5vlckc5xgwxgmz+l/W4Pn9Dzv1d+qf1l6U+yrOwxbh5YDnMrvbNdzAfRsvqD6/Xo92y6ut 1v8Ag/5a6Gjo/UA1lGRbVS2mHV00t9QtE+x/pVCjHxd8fT3/AOl/PWq3KqNbsjd7GA7g4EWBzdbK rGP/AMIud6vk5d1hroubXFm6wEB9b3FpFm9sj6P81XZv/m6VJ90xk2RbZPMZckjIkAy10/Yrr3Re iZlddL8q1r2autrLLHl0+43MrodS3c7b6my5UP2fd+zv6W31vsX7K+j/AIP7b/Sf53+b+xf4P/wV DOVkVj9PRLRqbMd28D+V6T9l7f8AwZWYt+h9nyJ2zHoW/wDG7P5n+lbfd9m/pP8AwKk+7YthAUdw ye5lMOAzJAPFE38v6P8A0ZP/0danqDmiNCBpr/enyerPrxrHuLvYJaWuAh0/oz7p/wAIuePVMRrd z72NHxk/JrVlda6pm2dNdk4rAMaq1rC9xklzw7ZYR/Jb+j27/wDCJ05xqr1loHC5PBzE8kRwyjCJ EpSI+UB9Op+sjMumssHvuAdHx8F5z1LG+sdv1ny87o2DfkenZBvprc+ovaNl9DrfbW//AEV9e76f 8tX/APF1ZldWy7HZlldGDh7dzN203XPl1NE2R7Gem++/03+p/MV/zdli9NsaWhsiwVgbW+ju2tj/ AIOn83/rfpqCGI7zo2Kro9HPNwmsZrrxeL590/r+RTeWupdh522cnpuW01lzP+Lt2erV9PbfV/NM /keoh9QpzK6MjrP1RyDUR+lzukua14Bj9LazHcDV79v87Sz9L/N/8Eu5y+nYHVahRmRl11kOYXjb dS/8yzHyWCm7Hu03fR3rzLq2XlfV/rF3Tcl5bfiEOxsysECyp4D6n2Mhuzez9Fksr/V/U9Vmz01V ycrLEeLF6o3rA/y+Vu4OYhzFwyEY8hFcf6M/739Z7X6vdP8ArDl4teX9Zs04nrCaunYrW49u0+6c rIrH2yuxzfpY+PdT6X+G/wAJWj/WT6ndN6j0puFiVNxG4xddj144bWXWx9HdG3ff9B9tqwvqozrl 1WNk9ReMbp7699VjZF9zQR6FNlji70Kn1fpN9Hp3ekz+cXTdQ6uyuWMMuPEcfBSmQo2OHy3Y/YlH IBGXuV1/QfMsvLFYGPTV6QrlnowQWEEtcxzXfpPW3fzu/wB6vfVXFzMnq+Pe57mUYjhda5k7i1h3 bGBvus9/87/oqf0iu9dwcbIy67nPbX1G4b/Rb9O2sez1nt/wbvzG3f8Aaj/rdt6hj4nW8DIZd0jF tzg9wF+Ozlhj2XV3HdVj/Q2WVW/o7P5z6f6RQYOXHFdaA8Vn5pOpzfxCEeX4MYAyTiYy7Q/edrre dkNzG213B1VjA2XaQRu9NznV+17f+Er/AHP5uveq+M+3LgVMLrnO91fcP/Obr7W+12/1Hez0/wBI n6pjdaNDr8jpGRjT9O1rqHgfn7ntoycr02Od777fQ/4+xYORm9RxdHUsruLeK3ObLD7am27m5Fd1 n5rXUV0f6Na0Jfi4ETdA6Vpfg9UwtxyfRc23ImTkDVrNOMXRvqf+G3f+g3+mQ/Tfs3e+N3i76W70 9/P87u/PWFT1DquPe+rq1d2NbXG3Hsd9IOG71D7K/Z+5/wClKl0fp0/ZfS+0tn9mfbd2x07PtH2n 1o/0ez9H/pU8yFA31puS5bhxRkT/ADnyy/qxjxmX/Nf/0tHpX1M6NnAP6pV6+SWhz6/UdVWwuj9H OP6duQ5v+lc//ran1n/F/Xk4P2LFybMHHa8WBrmDIrMTt3WbqshrVztX1jJdscWuIJET5+36S3ML 63ZDdrRkuaGEe15n+z7g7c1VBICvDZtZIZAST+k3/qF0HK6Fi53T+oGi1l9rbqra3B7HDZ6T63st ayytzfT/AMJWujOBjsedlHo+BxrTUY7OdWw01/8AVrEv+tPTX4hflMNT3kVi2jU+8Hc5v0Xtc1u5 3+EQ8G1+wfsrqDb6xG2ix0OAH5uz/q2+lUreISlEy6bKhykskTkPp10sHhP+E9A2nNAGzKfpyzJr bYB8LKfs1mz/AITfYuT+smB0jqbsjP6jSzIfQyvHHpuczc5p+hXYR6jffbt3f8Yr/Ver9ZfiOobU 3FtdobHNdsdP8tu9rf8Ai/8ACfyFzWRdQy3Gw8uwtprIstfqSd5Pq2f8J7fU+h/hLVX52c8cPlP9 4fLxNvkeRkZ8Ujf9WPq9P6X+M7PXvrLUOk4jbccYj8g+pQGu3Ma2v2tZa7ZVZTvqt/R7K7FmdIz8 vrT3U9KxrBe0gW5GQWOrqn89lbf59+3+b9bZR/pfW/m1jfWrPGZebWCKR+jx2+FbR9L+Tvctj/Fj msfc/CrBbmMDrHwDtfUS1jrX/mt9Dds2f8T6f+EVbCTkqUtT8v8AINzPhjg5YGI4ZEGdHWMb/Rt2 q/8AFl0p2X9tzMjJycixwfba614eXD87fV6Xu/NXW0Mx8WpuNQ0MZWAA3mPDc53ue938r3pr7/Th lethEidQ0T9N/wD31n+EWRm5gqaQzQ6k+Mn6TirfFwjdxQJZN3YsuY1p3OKzsTpOA7IGc2prntd+ igQGkf4Rs/4T9z/RrCt6lkvaffDAJJJ08At/BzsbHwK23WMHps4DpMfS32D/AAf/ABf/AG16qOPJ xEkbBbmxiIA6kvJ/4xaDkdY6Zi0mMnMYKKjOhJtDGsf+7/Ob2u/4xdr+w+nf6P8A7SfYP+sf6Nc9 0ml3XPra/rFrCMfplfp47T2seCGb/wDhG02XX2M/wf2jHXYpwlvLp/LVmyZZyx4cH+ajI/XJ6v8A ov8A/9PkepXV5mfdltb6bbTvIgNP8p21nsQqMy9jGua+WHhrtYP7qFc91pLn6kkucT3JMuVZ+Rdj 2htcODpDmHgqDFETib6Otz1Ys0av25jt+l+k678x79jdW7QSADIk/wBb3fmqxR1G+oAMdoDP+oP/ AH1ZLM7FcIePRd5+5v8A33/0WisvqJgWCewOo/H3NRiZw0Gzd5PnsHtxxyG3fuXq8H6259FRDrt4 jb6dnu0/kPd7v+ms/Kfd1RjK8at91tJLi1gLjtdtbu/z9rFmBry2WkEff9y9C/xfnB6f06y6xhGV kEOtsdGjW/zTP5DG/T/rpZOY9yPAaF7lnzZMWCBzYYCc7FRjo8Th9Gz8vrFfSsmt1FbYfHD37z6b GM3fzX6Vr969b6V0bpn1fxPs+BSxllsb3j6Vjm/nWPMv9Krd+97P+uLj/rF1/CxPrj04H2Pprecl 5EbDdP2Vlv7jm/zz9/8ANfaFuM+sDbS5x1LjAHgBoGqCNY5mzWlQ7f1pf35OXzUs3MQjO5GMiZT/ AL1+mH9yMW/mZYqBG6Xky93ieFg5F/qEuc4Na0EuJMAAaucT+61Sysz1TO4arm8rqTuo3fZsUzis d7nj/CuB5/8AC9bvof6T+cQnInQMEIiOh3X6hnZuQBbiFzcakk1siS88erdW7du3f4Jn+CZ/LVTC 6t9aM/KfhYmL6za3taHU1wAbP5r1HPc6up/5z9v5n6X+bW/RRXRj7r4axjS+xzuA1oL3uP8AYaux +rnS2YeE211QqtuJuc0j3B1gbvdZ/wAJtayr/iq02PEZjGI3xDWXTH3P/epyShECdDQ6D95s9D6T T0jptWFX7nCX3Wd32v8Adba4n3e5373+DV9JJX+EcPD0qmjxy4uO/VfFfi//1OEHKHVj35Gb9nqY 63Itcyuito9zi72ta3+U5yt42BmZZH2eh9k8OAhv+e72LZ6dbmdAzKrbsXHdfcxza7X7nPa0fz1L H1Payr1G2/zn85s/R/zP6NVMeWAnwGQBkDpfq9Pq+V2fimnLHIBxSxEED97j9DrdJ/xTdRDhkdTs oJgFuOx79CefVe6na5zf5HsV/I+pXRGk42VU/Ftj2ud7muj85r9o3N/q71p9C+tdWSPSFjsfIaJF DzvreB9P0XH9386n9HZ/olsPzOn9Xxn4l7f0rRvNbTBEafaMaz8x1e7/AK3+f6lH07gqr0I7uBi5 szPCLx5N+CX6Xk+ddT+qed0Vr8rFJysapvqPpmXenBc6yl0/pWMb7tv7n6StLpXVc+5ocwMw6nfR dU2bv6zLMh2R9nd/LprZb/xa1Oo9cyMDEy8C13q2MOyi0CNXw9t7W/4P1KXOfbX/AIPLrXK05T6y e+7krP5o61Aer97/AL16n4ZgnlwmWWjHaMa+137Oj9Hs3WOq3PsJc+x9jy9xP03vLnl/0vpPWVe/ qHTnkYNrrGT/ADNvu1/4N/738lQ/adxGpnsShOy3PeXO84HaVTgMoNyPGO0vU6I5bQxPynskxcrr fX724bXBlbv5wVgtEfneq/32bf5C6TGwKOmwK3C5zNHuOjJHLW/vbP31V+rVgdS+rDqLszIc9paw bnugM94j6Htt/wCL/wAIu66H9V242zJ6hFl7YNdA1rrI+jP+ltZ+99Bn/gq1MEYmPFQHg8X8Vycy ecny2EmEcZqeQd/5foMejdG+10tyOo0BlZ2mugz7gDvDrq3/AJu9rH+k5dGkkphEDYKHFwgSkZV1 KkkkkVP/1Vh2bmAdogBZ/wBaKt3TjewEuxXNtEeE+nb/AOBWOVnBpzK2ht1FtThoRZW9pB/ttarl 2M3IofTaIbYxzHfBwLXf9FcwCcHMRmbHDIE+X6T0WWAy4pw3E4kPH4mW4lpBLXNILHgw4EahzT+8 t8dXybHY11bwzJY/twTr6rfpN/R2V/8AbbFy2FjZTCK3UXb2nb7anuBI0lhrY5dJifUvrvVcdz/s 11FO0kF4NTnxpsbVZss/SRt/Sekt7JPh1F8J/dHE85g5IHNAmonGb9Z4f8GTz+d14ZmdYA0uY+zS 0n81u5rNrI/O3KW5b+H/AIp/rK654Lacarlrr7JP9UMxm3/9Jy6rpf8Aip6fRDup5lmWQQdlTRSz zY8zda/+w+lDJh4yDAEaa8Tvcl8Rhy8JwzTEvUTEY/VX9X0+l84qZZdY2qpjrLXmGMaC5xP7rWt9 zl13Q/8AFx1fPLL+pH9n45glrvde4aH+a+jT7f8ATfpK/wDQL0fpvRek9KZs6fi14+m0uaPe4c/p LnbrbP8Arj1dTocrEayN+DHzHxzLIGOGPtj9+Xqn9nyxc7o3Qel9Ex/QwKQzdHqWu91jyBG6yz/v jf0f7jFopJKcAAUNHHlKUpGUiZSkbJO5UkkkihSSSSSn/9kAOEJJTQQGAAAAAAAHAAEBAQABAQD/ 4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3Nw TVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAA AGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFlaAAAC QAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAAACRsdW1p AAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJDAAAEPAAACAxnVFJDAAAEPAAACAxi VFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5OCBIZXdsZXR0LVBhY2thcmQgQ29t cGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAABJzUkdCIElFQzYx OTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA WFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABvogAAOPUA AAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklF QyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMg NjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMg NjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAA AAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0y LjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsA A1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAA Ao8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsA QABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8AMEAxgDL ANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUB fAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJn AnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YD ogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUc BSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG 9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQ CSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4AL mAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5k Dn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwR qhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0 FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZ RRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2Z HcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUi giKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneier J9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEt di2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/ M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6 Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50Ep QWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI 10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7 UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZ aVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJ Ypxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr /2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXh dj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeA qIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuW i/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqX dZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2 o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACw dbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2P vgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbL tsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx 2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6Lzp RunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio +Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t/////gAmRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rv c2hvcKggNS4w/+4AIUFkb2JlAGSAAAAAAQMAEAMCAwYAAAAAAAAAAAAAAAD/2wCEAAwICAgJCAwJ CQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwB DQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDP/CABEIAMgAvwMBIgACEQEDEQH/xADYAAABBQEBAQAAAAAAAAAAAAAGAAMEBQcCAQgB AAIDAQEAAAAAAAAAAAAAAAMEAAIFAQYQAAICAgICAgEDBAMBAAAAAAIDAQQABREGEhMhBxQQICIw MRUWQTJCIxEAAgECAwQFBgoIBgIDAQAAAQIDABEhEgQxQSITUTJCUmJhcXKCIwUQgZGSorIzU2MU IKGxwcLSQ4Mw8HOTo7PTFdHyJAYSAAEDAgQDBgMGBwEAAAAAAAEAEQIhEhAxQQNRYSIgcYEyQlKh chMwkWKCktLwseGisiNDg//aAAwDAQECEQMRAAAACD/OCbH9ObvBkzKGXyRWQMLNe/P0gQequ4cS Zen1Rq8xa18wLjRA24uMg9qXYevohw5WdkBx7BHI5djmxOrfNFme2QX88c0POwWe9oJgi2+r5ZqT mf5KUgqiad8kDun64mP614iICDVmGresNTjPi1HRs4TrVAUJeBWzDNtJhMmzSoLgjnO15BEKCDuo lEJS+zXQOZU48meecFaW8COLFCrn2sdA+nlVdrHzcs84zQTo8G4+6xxXMQTR2XbzMijtZQNCHnG0 BoNeBb5yaIvQDeuFyDPegiwMB/NtYFrdD7+FJW0Sy3zYmJUvarYOthc107whYL9txLVzteh+Msa2 GMg29RgUWoi18ne1LwwszvLcBzNh/Qs3nk5p/ENHQz8b0MMT9JEPw25bybakuaN3JsrUT5IYn8pr 27gVCKiHNyQYI2IJ60TGo2YnWiuN8d7NzU+q6FyTVoF0rpM19I6E8wdv7FhOPKLXDojdKexe8zC0 L7MtcfLxU5ru1ltnklLM0tAdpYJMxFissED4wi2vBmJEQc6T1Bl6dKf5xo+iqf8AXEdnz6bZqqGu IFR1Wxj1HqGUwjXA4zqxgsB6KDSsJtE5Frtqt7LuFVwAPsd0IarOOjhqdWZBnNRdvTYXMTqsKrxW 9RwscQoVbXpfBCdbKImfSbS+d4rninpGpVe01gXXNfIE/K7iyaanpBSlQyaIAk+Z2x9Pfz28Fe8q mo3QuUMWw5Jj771O25Jw44ikkcfzd6vUvUQ+ndMb84BlmltXFn1Cfu8JmFlbDaO9fccys1ypgX1Q QnkWMXv4ke37da8rPJ/ZXdJJK3UkpPm/oiucb1AsSRh9vzWpWWWE7uMbg8iursxxvtjP9jM9hoTE ttjzsnlQlqjfl6oyd9cxEkodJKRJKTIp9RZeV9N6CHoe9n82NLO1MCyqFR90Zsyvmh3+1fmFTZyc Hr7GRGkpHykkpxJKRJKRJKTH52Trzfo9foc+VKkV0BrexNq4xhLP70SfMK0EPqpfKqsH6qXyqpPq pfKqk+ql8qqT6qXyqpPqpfKqk+ql8qqT/9oACAECAAEFAL6SIDrtiICM1yzOPX8gUjAeRR4kOeQx jYnnyicUUSLBA8KtxJU2QVVHhnxzPGKnJnGAONifIwGJplwUJdkQcmRfMFJTJfMli28F5xOGHlhV YKArLHCSPExjh+JmIlwtSwHSWeJcKCIl9mZmmx0HExJRGTxnxjpkhWqZwwExfUlcpacjM54AMpV4 zE5zzE8eItKYVMjkF+jCiB9i5iCIoAB4+Mg+Mk54hnxB8ZBxOIHyz15cIwhczMhHGf2yTiME/Ip/ jgf2XEFBL4xLvAQcM4yRkIWHNaSKCLDLnBLieCI8VPBFEZK5wokc9vyfBjDoGSZznjjoLisj1B+g /wAo/jhDGWBAMNzZlTZnFiE5ChiIAYn9G7BY5TskxQnBQZ8Qc+U+scgIjKozz+xw8TqWRDCmRlcC ROGPIUmWBWGM/t+2z4c0fL8k/DhH43sHx/of/9oACAEDAAEFAPZ7RJIYSD5vcBn94kImXwtWKtoZ kRM5EAtaT8SsjPkNlq5HYROBdROXXw0omYj5zZckYecZqzJuW/5NXM820yVItjU5AlyEDPMrgRkM 8Jy5QlkQkwzUWZrg24bC9hli3nArdHGvsT5r5KQ8HB6InJgYn2c4jWKOL+tAEQE+ETxkTznJZqE/ yc3iVtJZVrK7AuoTMiv+VKzHq2V0nyJTGLVB5KfBZa+qs/Fc4YzzA5XGJYfv5lMBjHfykp54mcFh DOxYH4JJnJXMZXRBQVSJyrTGIUuZfsJ8h45kV/EhACMeU2WyU2olIx4lFRYihlFZYmqS5tW4GL1o jIAwR4g1QUDC1rmecvDLUracYi+Q4i/BZYf5JqgwGuplE+HjEFMQBxjWeZZEc5YkEH7J4Tanmj5P GFQGeuWDsSiuDNhYaYEyQ/TnjN7XEnwRomrHtiksQR4jnAxnZw9hV6q0x+v/ADtEwaprwQqE0I1j ShL9nWTlndOZklJT+wfPLPh6g8fIvzfWz38fv//aAAgBAQABBQD2Rx19v4OrHaFMhbrni4rsxlUg VtKK2DXIDWiuRy5IiutcrlDE+MEt54+OJ6ySrN5CvGPHOM7VslURXuRGVNDY1NnsJ0tvoPYy2acj mJRs5FK9pxidpOI2Qljd22RPY/zrdDrPpQW3mzS6/atYfWSUFlT6ebXb20zq+o7m7GpqV9TjOy1a +I31RmWN1VQvuu6sbvcdf69U1CzugzNtr9Ztq2sqO6j3PmOBsryrsq8LUdVuShgShrRxtksoeRv0 ZROoua+q5lemsBgRjHVK1iNn1TR6vZWjkc9sxlmFPVfuv0dt/aFsr9Drezaj4bBnLhO3bTL95WYC dftju9C1/wBb6gK4fXnVhFv1h1Ikdn0Ox6xYTurMTO6Eh6prLu52D7SkYiRbHOeWeXA9ssmt5Phq /LInO4UosauuExPRLYK2SbjPa1rmDYPxrbv/AOA9MuyXUg34QSt8uXTt0cfYFivb1VXT2rGavpjm sRbo6StGzWgOoXi2GoIpmBIYgzgQ7eXmrU3haMnzMlzmzCD11KpZtHV6x3CjY5ds69bQ7IxqavWq LdaTS3C1GoXrtojrCmpudLtjFrb2dY7f7+Nlmj3y6+TdaYndQqd7vLt5n1jsxd1yG4TPKLDjGN6/ zEpZWfWujYXBTzR1a9suhrNXpqpWjnCs+IXNsqvFjbWrAkczCj4bUOMhkTm61dLb0dV0KhKG9F0p VuxaC5o3ddTr00G6zR9gXV1Vno+zTdW5UO5x7p52gkwNjsYnYzaYJag9hZCrZt6jKliXKS5Fkblh fldkbQFrfVMO2SpTc9qk2+MG5HEX5nNTfJdhlgYDvIqfrdHuy1rVWwOEXqm2VeDbdVsUvsfSyNXu usvuZ1q/tl906bVrVtbq4Wt9rjD3Fg1fX9+62zt9qKLJbD3RM8hMj4KoJrqbaNzBd8+/IdM4G1IN jG0Judmr27VCl9UdtYsOs9v61CNlUuhR3ibKtv0F9rbaPVaPrdNdiG40F+XZqbtVbYZNKvTNk6Go rWUdywLKvEpyq38mAUnXwwzcwF+TYbExDJmbu4SlAb9ft65tLW32FWsmmmVuPJG4MbjqOu2whdJN ixtrVZNDtJ2C163161i3Ajtjr302NRZp2GULQRo+0V2RZmo7LT4rlG0qFk9jiJo7B9qdSBtJuxdX xu8stLU68XL9UQX1TSZW1U7NC5FlV5eN0YGJjPtjVCN/XovbK5W63T1dWNrEw+0xhX7tPVVq/Yx2 b9dpm31j9W6Zj4+uerCOx6YNFl7XN9uv+vJ2FAgZrj6w9jutafSL2KFdQ0Apt9VWxF/6+7DSz6xI 16RjDAWq1bpHWpnPTt1Ru1TeMP8ADaTZ2uw0p1s7eohkbyjMI6Oe4yn9c6dR1K1amiWc5PjlmAJa NUiTGIgO2wH+Y1euKl9frvLjEdjjmL2tsD+MloyFhRf7EhdhWzrNH1KmdlsU01V9hDmKJm12HcbI ElhsZHRdbUWtcCMY58kU3YHDvrx+w8iQHgk/+tqlO+7n6w9cbJgMTtTxO0A8pbdtfJ7QpdUW6XY4 ereERs9lUzZhbvTcP0I096jVDbWTeTZKWdM2i9gpYyK7FiSlzoEbVicOwycreX5CHSK+w7r1o6Dq RhmdhpLp3VWmrxOwXOKtll/ZGa03ZgqvYXVyrdpSUOdqnJ2JDYrRadzbt+VfXaTYbQumdOToFWGl GGYKG1Y5xpyeW7iaSKm6STC31YR9tjbXKVRNKpl2424TSgFj/IVFMTLjk4OME+MRakCm/AiF8+R6 /siaWmsxtupa5aaz3+uDIVRbs4xslNh666mi28dyqwZ1Ws2lmx0Hr9ihT/RzoYZDzMWZryltexJK nIznjIKclkZ03R/5LYkhAB3gU03a66qvTC0JxbtRjm8y2wtKnXGX3VER4HTWY9b0FanUiIiP0+M4 jytRMQC+IC89UDcJsDc4xRrZH4/lnV2TSWGyNo913objZ6fsROqK2PMFb5l9tYRc2LNi+hSkpWjw GgltzbISCFfr85/5nllgojNR1m7dZW6pSiHdJS1V7qlurNaz+OxPYkrMyv7ZP+vaoYt6JIZ/ktlr 5/2s/Fl69sz1+kdC6zFIjXrHYO12uRQX+0fmWVne7pfWqGqQn0MC1ra1kbyrWrYpyLodv6/Xs1KC U18TYGM/LGIfYEgs+JZYo+tvWtKFdb7EOnXauxsX6/XV9ej9vxgRMlQt7HUto9rtRGt2FO8pG4lU vlLk7CC1d7sm7l9UWlBRbOY/NLkrkzAt5KpYXFuXzCdP1yzsCq1a9RP7qWgpRCalauO9rS6hXteQ VLz6zq20C6nX7yalns14CC6fnZ5yJ4znOc8pjNXrb+xt6TqSqmRERH76x8wBci/goZE1biHTlOya WWpBpb3cGNqrdc90TnOc5S196+7SfWJlNHXUdcj+jUZyKi+CHkez1vVsK8zgF8WLNpZMU6GpV64R JNLWdF7Jsc1P1frK+U6NOin+mnUbevKq7hiAmI7ZSN9WvT2cZr+ub28yh9fPBJ/VZ241/wBXdbqx Q0+q1o/1v//aAAgBAgIGPwCMYnVyuPfVES26+m1SjI5BwmZMQnAXUs1cJARKqaDVAAuyYxITCWek gntB7kSRUo4PxwJKAPlRYluGqya4JyPig4ZlVMGAHNF9MG0wAQBWTpwGI4KiB5qmqvraS6cnPVVB V0virNr9QQjImUT7jcm7DQqnkFbMBldBzFAEO3FVRsQmU+uBPJFwi5zxdGoBGmGT4MmCMMSTkqI9 NOKBesjVR15YgDiqpzqmVFbzVaKQLFwiTQQqvqSDA+WOrYvxo6ELrhnLlHDvxy+5PIog0DK00Aoq HC2AeRyC6i85VnLnw/LiCExwfM8F5iBoyaYuHPNCwZ4Pri0QZfBPGhBqFUVwJNVkqJ2p2pbZPmH+ KpknJB5ImIWTd6eXUfh2jbd4qFubo3O7aL/pd+LL+xUb7D//2gAIAQMCBj8AqMs3VA3cULZU1BUT 4JzJwqFXbm4IAptsgJgFbMH6ntReDg6Or7LBN2j8qa+Mx8qJMf0p7m7wunIJsCCS0WouksoRFbSA T3InIgUVR+1Xmp2pCX5ZdCaJMn5K6Pq0TABXVz4KmuF8R1FG6JW4bLpGVHVxDdyd2CntmRMZxIIl X5UyMBVx9yromBaQDfwFaRbOOnuH4VoWVkVduRd9CFLdAjCUfYLRKPy+5CQ1wpFUqV9SfSE0ShKB Ktm0ZxPT/RGVwrm3q5rpyTbjCYGfuCO3EtCJ01Vuiz8FKZo0SW56Loi7aoCItZFsBnzUQATCRAfk skQSKItTDgy2z69y390kTgZTjIxycL/XJ+9AO8pGqDxaG15e9TADMfNiZFeKjB3G2LfFAyFCrm0U Yto57ynGacHIvVAbQv3JdIkMo/MjtRyHmPulix0qjuEdWQ+dOVIUcBwm0QDnxVfgpDbLSlRA1kx6 v5IybMuqhOyJJoM0/p0wbjRThMgEGj8FdEgqoyReLRHqC6QwRDsdOCMtzPQD1IfTOZYRCAmQ+tvY +pIMJD4oGJeKEgGcOogDMVx24QIBbqr5V0h5HzT17N3tzQHFCEQR+JkI7hqCWfgjduCUh6YdckY7 I+lHj5tz7/SiZEknMnPs9VvgpX+VqoWMz0uRayxtG8v/AKLrut5+X7D/2gAIAQEBBj8AqCJGKkrn ax3txVx5ZB4gP2rXFGU8qH+erLLa+5xasylcBj5qafS2jlTFkXBXHor26zllCd4kW6KMtiFbCM+H tMfSaiXYADeTQha6hTYSbrVmtmF7rIuJ/VRjALh+synC232idlsKaQYd5jYGw8VIqAvmxVzsJHRW It8MCscsszMFIOOVQMPnPQcuVIOBGy9FZ4mYsuDFWsfo0IVjTiu0TOoDYdknw1PotQ4M8B5kfSY2 Nj/tv8GIpBfCwAvhsFWuaFzQsbeWiplbLa1r0MpxJuvTev8A2eldjqpM0yaaQ2hzMb8u3Z/Dp9PN zIJUNmhHDl8lAyMxB3k3/bV1F2tj/kUeIpbcDb5qmhGjnmbrKC1z1VXDrNS6j35qG00RxWA8c3kH J4I4PTkorpw8sZUK0crZrlTdXRlHs29Ck/Mah4g+AZ480YPZjaWLtt2asup07HoJMZ82WQUXmmjR ezy2Dsx8CitBpfd8b5kUxxRqbuzSN2v9vNSvrMur17YSSkAhWt9lp17NSRwpzuWQHVDYjfb0vDX5 bWaddQNoN7Mt+qyTLxJWm1XM5mgmLQ83AnIbZ4p8vDzYu/V74bb1jhQSR8pGy4BFqAWRDfowr2bX HnvXE2Hx0bMaWRmLBdw237KLUD2KgoOE7R5KSdkHMHBm3kdlT6NC42dmsABWWeJJAdzKD+0VD710 qMswzMsBIaINwjnrzMzo638dRqDgFFhjbiGa/F/FVqaKVQ8bizoQDcV+VnDywsM+nkBBzJ4r9pOr Qi0yMZXOJcBQB6tNr5nRnjR8t24hsV2ZRdkzK3LWhIA/PicOCgNrDMq8OGfrVecflzGCsyhgSyDt cA6+b16/Lx82WdgHMMYBy7/aZeqnjepZtXqBeZSI9PAAygj76Xqsy/hVLrVb28WimVm3iSKN0zfQ z0i6pOdPa8jXIGbtKvhoD8mpJwxLH99FV0rRyEYSLI4IPk4stezneTSP9mz2NvA9XeNHtt2isNMA T5cKjln4NPAQ2VRZV8R8TVHpI9otmA3DsD0qDnsG4Hlt8JNQkqVUo1vLY0jjYVFviHwdFNOgzSaV uYLbbdWT6Jq+7dWphkIVZYcwJ/DPQfA7Uy6aN9UwYxqVHCL7mkYiNHpV1WozRqLrHp75r+PUuOHL +HF/crle7gNPgTJFGBmIIweaRvtcz0VkBawOY3IQN0oBxcXbzV//AEGgY4xaaWZAeh4pFb/rq2YW JttpLkZbi5BrBripSbEoAyefNlr2aFgLZjbDGlfVuYkO5cSR0WoabRgGbcBjl8cv8lPq9VIFjXik kY3B/wDt2e/X/sHBVtVLI4U9lFbkwR+pDHHQAXNf4rfHV1a/Su0froE4+al1EQa0ZPFtQg2DZKMD EZ0xXHaN/wA2rjAD4NXc2UQSXvh2WoQ6SF9RKR9nEpdvmoC1Ra+D3VOzQsGClVOYdqN482bI68FQ to9PNp5ApvpHVo5EcW4JI5FTKsXVSX+rWedk0ijcWzso7Ssq5cub/VpSrPrHQEKWJKLc45V+z+fV tZHDBZr8Mkhc2v2YssSbfHWp0SuzaH3jotRCVY4jh5mEqjq8tXyS8vmfeUnNnJkI4pY0yg+ipPDX M93a32im4jnXhPrx5mX5lcj3wraGW2Be7IwHagljDJL6H2lDT6YMumU3ZmwaRh1eHsIvWpdPqgMo 6kowPovV4Wyow2x7SPSxpg2aR0GcxRAuxUeAfXegrLydMl+XCN1/6kp/qSfU/p0NPcZtNIylb42Y 51rA1ib0AihjbeQB5mJp1yAERlCLYKCRm8NZoyQVN1O8gVmGEg6y/wAS+GlsSSTstT6J25aTxssj qAXEeAdo83Dm7CdzjoafQQLBGOyg4mPedzxyN6dXAAF8fN8lF5DdVFz8Xmrm6zK0xswRzaKK5sg9 PL2+3WEgyHYUwHzr8VE9a54jt/bSuCbIJAQdtmjePL9Oid5NyaFPpNWgYHGNx1kfsunipXbjzEgk jHDA08R063IsHtjRRZHOkc2UgkAeFhUWp93nKHAaRj1y4+0Sb1u/Rh1WnQT2xIFmHQ0TimmUmf3P qbLK9rvFjg0ir1sn4dLLEweNxdWBuCOmhfyUwG/yU65bltttpA/z1qKaVwyRXDPtVmvxZfw/FQZb qw2EGx+Wll1sgi04Xh4QZH8oz9RPSptby1aKVURw7FzkGxI2v7LrZ/ZrX5z3ex1GnP2umY3kjP4R PWoSxuxyjjS9gPCyUsNxlUGSXHYB9mrf6jVIs1iHYEocRtutX0srwHoBuvzatJEuoGwMhysf4aeZ Y5AIr5lZCrXKvwq32Tvh36sxy0CH+WrA3bf5am00vCTaSMHoNYny1ICBfavnHFVyc2nmtzo91/vP VpNRA5BOKsMDfwmjoNcAsr4YHKHA7j9h/wAOi+hvLoH4zp5L2AJPCjdaGThofmVmgdTcrlDrf+3a hpvdcGq12pYXCxoI1/uSSsv/AFVl97SrpNK2LaLSk3bw6nVnLI/oRJGlQn3PpeW0F8VxaTeyv6K8 VLqNcOIi6Qb/ACSS5f8Aqo3ax2EbsOrRieRmUYKuY2rURxJzI441JsQtjm4et1makkiGQyA8wAWO cHbKveogm4kRcg6AM38VMCbi2FXCi240mo1oOVsU0+x5PT7kdIXC8mI3SAXCBRw5e9xZuJvtKA3e WrXwrBj04G1ZhIXUtYEnsg0Fzbd+6jBpIn1Orm4IYYxmYk9s/dxfiyezoGZ9PpSRgjyZj/xJJRaa JdbpB9wxcj0FYK3qUTDJxx4yREWdCN+Trdbt0NJ72HMjwyTsMw/u/wDlqAe7nVIdU/G5IsotneRe /wAHdpdPpcplt7STa7t8VXGA/wA76LMASQQb9B22oknPp5iTC/7Yn/EirpY1YC5xvhgOni8NBtOA 6SANqGUcatbLmVe1FloPJiQMyzKMRbcSOvw0AilZlN13emrejQZdp4Su8GgWtNriAQm2OP0+zPMn /HRkkJZ22sxuaVRiCrndsVTJm/46Jv5vgZY3Bdrh3OxR/FVyGCDZ02FQ+7vdwvK/E8jDgiRcJJpO /wCCPtvQghB4QA0h6zW2k+tV+eyX2KFUra+/MM2dqIUxzjaVxjPyNzFan1emQ+7veqg8udQACbdW ZF4ZIH7dS6DWRnTa2BiksLGwzA9hvQ6tNFG5KZgyKewy4h4vumzdyoodLppJdXKwRAxCJnPj4my+ rV9VKJZ2xfIMsa92OBety1779f4JNPqFLxuMbWuCOq6eNaMdi0ZuFnA4SOjN2Ze+lJqdI2WaDqIT wvf+kw/EoIW5MoNmgkOVgd4ifqsvp1nyNgczILhHPjUD/ryUz6hg69awxa/kpZoGfSu5OaOdOAnv x8rmt86OjbVILY2EbWv4Ry6Ep1AfTm4XKhUkg+NVrVai3sYdNM2Y9JRkw+dV5IvjJwoxgcsNhYYX qWTUKMsilMRuIvTAHAEgVqvekem/MTaqYw8LKpWKLi4c/wB5NJJn/wBKOrTxS6c786YD1xWfTarK TiVUqwP9uXq/2660UgO0kMmH/LQF723mtH7ygTi1CNFOQNrRWaJ/S5b5P7UdQe7Y2ZnmYIoO1Rfi 2+GknhjHM0ihlYgX2e0okW8g6RauE4V+b1zFQTaOIYvIfu4VPW/EmagupCwqxywopJVR2V9P8T+p VtMoK7DKSco9Jv5eOm1Gs1E8jvYskeWJLjb2ZH4vSrLHBNHbYV1M31WlZPnLQszTwOeF8AVt2HC/ Xoqqkx9W38NSTauT8tPICYEUCy4cLS5u93KbSHbpjy2O8kHif1q97zufZxQyoht0RvI/7UpdVq88 WnkF0hHC58TydhfRoBfdsZBGLZTm9LPm5lSQ6DUNpC6lRcZwD5uF/wDkrNGi62O/Wgxe3lgf2lNo plaKeCaQSRspVhc5hmVqwVpMeqoB/U1H8xAisd7KUPzuGidHqZ4MpsQGzph4ZKuksOqtsDgxsfjX hrTw6uHI6ZnKXVhstmzCl1J07SanlkBkCjKrG7Zmcjiag0xbSHUDLHzQFBv1QXW6Lm9KimrZoVvh IoLKR6t6ZPdt9dqdygMsa/iSuw+rQ1nvKR5p2GJZiABuWKNfslXuUOZp1YCxJbMTgf8AUpdPpkWK JNiLgBXCfjq5JNMMDfcdlDUyqG3ooGysPjHRWqCG0qN7RN5vislTw5TzZ9HPMy780sbso+ZkoBcL AC3moB0GTAXGBArMXTy5sDWeCQMu4bV+WszXNu3tt61PDMmZI8Gddx7d1q6Sh1bBcMSTsQrSsUGd djW/+KILASEfIO07VLq2vlOA8iL07OvQd1IErAlTujXpqLRJiVbN5gFK1yicwHVBxI9Go11CDmPZ lPi63FVhs+DKv2Y6zdJ7tY4VtoKpuSQAPjpQTcgYnz40Tvt5vlpY4upPPxMPuo+uf9tK5WUZLZcu 61rZacFtvVx20Lg/uoLmx6Dsq0Thb7RuJp5dQtsgxZTtPx1eMrzTt7D331nhcOBtz8Jt0Z161ZJC wHS/EPVcUCsxKH7RXBzHyczueGk05NjLgV6QOtU0sjjmsAsa23WqXUPgXNlHkoFSQRs89A4fm4gF kjG0tsWVB9239TuUobFgMfPRhjNrfaOOyPB4qyjC26iLmrdNIGYK17i+Iv4qDTlVNsADmB9Gmgg+ 1lUjyqpGN+7K3drUe9XXb7DTk9AtznX6MfwH8vJmifiCnAofu79ta2m2+uLhbpFAxNn85tSQEkAn OwPk2cVDE7aVOYVttVjnBv4T1ay6iMDxJj8qPTzRFRJlJsvAT50NPcAEYo+wq1uH51XDWIrNIQMh tfpJ6KH5dOEmwdsAb93vU2onIm18wytJYgInW5Ua/XauXEeM7T3R/NRUWA3GjY/AZZBnbYkYO092 uadRypDtz2VvNjV21K5u8zgn1FWo9Foblp2s8x61j12+bUWkhFo4VCL8W/1vgzyqF8xwokbSLCgw xO+rqSB0irE3sABXRXCb0M1yu8VaMkDfc40wtdWFreI9WrGB8oONhspNPq7mO3MUWtcE2y29Lr1z 8o7seG4bxQVcZG6q/wAVYdY4sek0aIppZTwjC28k9VB6VNNJg+xFGxV7lMrLdSCCbdNSxaOEusB4 n2KvdTN36bXa9MurnwRTYlU6cPvfhd8oQOSQi4AX7K15quRmW+Iq6MM28A2Yerhmrv8AmwNWQ+q2 2rMpB6RWFj8CajUC2k07Bsp7b9hPR79McouwxrRalQFkd9RGp8gCP9F2+nSrsEahQPLWdiMzYmsD Rp5pWCoguSazkFY1wjToB2sfE1bKJygm2AO8nC1RwIvBGc8rd+U4s5qw2foDoOFZd++gTif11a+Z RuO71qBMZ+MfvqzXAO4/zUABt6asoxO+rK1mOJPnpgjC6C7Mx4VA7ch7lJHo2LaPRKY4nPbZjmmn 9dhweCkjmNpoyFfoPQ1baxNM7nKo2t0UAoy6aM8K7z4mq5HxGgKg0Ua4xqdRO+5QPZxL67F6WKMW VRb9E9O6mDDBaAG04ADE38lc2eGSGFTYZkYFj5MKAkJDb7qf3UXhs694YgUX05sBtGJU00WqRo5E PFGxtb5e9QXT6IyyA2AeQ5T6Si1cnWT8rSm3/wCTSgRxG33j8Uk/r0bRAnylifrVm07NEd+8Vll9 qm5rk/FesISTu4sKCubIThGooSSBVXpJqxBbzbP10sMSkAYuDuHpUwjF5ZTmmk3sRh81ez+lao+U hkaY5UVRclu4o7VLqveBv7wlF3OUsIlPVgEmXKv4tDluHBx23+ixoh1s250wNByS8JwE67j3ZE6t ZHCrMRcd1vR8XhpplAj1UAvG/SL4wux73YoxmzNiC3SQfq1YNY7aCixI2tvojcNlbQb7VIuCKURg 8tzYXxse0tfmpxZrXFx1R3qwssIwRd3nrlQrwjryHqqKEMIue056zHpb9Oygk9AxpJ1jCBmyh3W5 Gb7tj1M3hpRqkWQ3uXUBTh5qM+llxHWU4Op8VZdSc8Y2yDavibvVe6yRSC1jirKaEKMTpZiW07E9 Vh1428cdRQiwlYnm23ZeqfWoNvFYGxq5I+KiAdtZjjut++ouauZS4DYbr7qMaHA2B/loTTgw6XpO 1v8ATU/XpYNOgSNdw3+Vv0wZbyt8g+SrRRqvmAv8tShRxoudPSU5vpUBfDC2NLPp2yyLv3EeOhKh Ia/ELbG8lHSSnNBLiL9k7pP9w5ZasSCwkVl38W+mO29sf0o4dBC00gZScuxQD1nfqpXP17DUagnM E7C/+SrDAD/AHwYi9rG3T5Km02wRuQt9ttqfR+AMDwtgR++kDXNmupDFTj1sU4uyjUIkszoBzCcR mP8ALTNKQS2y2Aw/QEGigfUSHsoCbekeqvrUs/vqXKNv5aE4/wByb/x0NPooUgiHZQWv5WPWb1v8 IfB56SdRYTIAT0shy/U+DE2oSQLeUYKdtri16vLclzi3STtoECgiKWcmwVRck+alZdMdNE1jzNRw YHwfa/QpZPeczayQYmNfZx/q9o/zqEGjhSCIdlAFH6v8TLNop0tvaNgPly1xRsp8oIrGkMIJljcM thfA3DUFOinc9Mcbt9VaSJPd+pjVv6s0UkaDzsy0xns0pUhBcBQbYZu1QGq1aRDfy0Ln4sxipfzP O1rL94+VT6kPL+vWXQ6SLT+WNAG+N+u3+P8A/9k= ------------A48356845382213-- From mip6-bounces@ietf.org Wed Feb 2 15:29:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25437 for ; Wed, 2 Feb 2005 15:29:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRQp-0004dA-1i for mip6-web-archive@ietf.org; Wed, 02 Feb 2005 15:48:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQwe-00017E-HD; Wed, 02 Feb 2005 15:17:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQur-0008AR-M5 for mip6@megatron.ietf.org; Wed, 02 Feb 2005 15:15:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23493 for ; Wed, 2 Feb 2005 15:15:53 -0500 (EST) Received: from ztxmail04.ztx.compaq.com ([161.114.1.208]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRDH-00048h-TO for mip6@ietf.org; Wed, 02 Feb 2005 15:35:00 -0500 Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 884E6ACC; Wed, 2 Feb 2005 14:15:25 -0600 (CST) Received: from kitche.zk3.dec.com (kitche3.zk3.dec.com [16.140.160.165]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 44D393B4B; Wed, 2 Feb 2005 14:15:25 -0600 (CST) Received: from [127.0.0.1] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j12KFOs0001778491; Wed, 2 Feb 2005 15:15:24 -0500 (EST) Message-ID: <420134D1.2060709@hp.com> Date: Wed, 02 Feb 2005 15:15:13 -0500 From: Brian Haley Organization: HP Linux and Open Source Lab User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sachind@huawei.com Subject: Re: [Mip6] Regarding L Bit settings of BU References: <000001c508fa$aeb1eef0$8104120a@in.huawei.com> In-Reply-To: <000001c508fa$aeb1eef0$8104120a@in.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Hi Sachin, Yes, I agree it's not exactly clear what to do in this case, someone=20 should add it to the issues list when 3775 is revised. My implementation follows the rule a little farther down in 10.3.1: The specific addresses, which are to be tested before accepting the Binding Update and later to be defended by performing Duplicate Address Detection, depend on the setting of the Link-Local Address Compatibility (L) bit, as follows: o L=3D0: Defend only the given address. Do not derive a link-local address. o L=3D1: Defend both the given non link-local unicast (home) address and the derived link-local. adds and does DAD on the "new" link-local address. It also does the opposite when it gets L=3D0 when the current binding has= =20 L=3D1 and stops defending the link-local address. I checked TAHI and couldn't find anything that tests this, so there is=20 no standard way to do it. Linux seems to ignore the bit change. -Brian Sachin D wrote: > Hi All , >=20 > =20 >=20 > I wanted to clarify the behavior of Home Agent in the following scenari= o=20 > (though MN should not be doing this but what if HA receives) >=20 > =20 >=20 > First HA receives BU Add request from an MN without L bit set. >=20 > =20 >=20 > Here it will only do DAD for its global address and will act proxy only= =20 > for global address >=20 > =20 >=20 > =20 >=20 > Now for some reason MN sends BU with L bit set so what should be=20 > behavior of HA in such a scenario because RFC only says >=20 > =20 >=20 > =20 >=20 > =93Unless this home agent already has a binding for the given home >=20 > address, the home agent MUST perform Duplicate Address Detection [13] >=20 > on the mobile node's home link before returning the Binding >=20 > Acknowledgement. =93 >=20 > =20 >=20 > So now HA will update its flag here and will not do DAD for link local=20 > address. So in such a case though binding entry state in HA is defendin= g=20 > link local address but actually it is not acting as proxy for that=20 > address and that address can be configured by any node on the network >=20 > =20 >=20 > Can someone suggest how this second BU update request should be treated= ? >=20 > =20 >=20 > Also what should be behavior in reverse case i.e when initially BU had = L=20 > bit sent and in update request L bit was not should HA leave the=20 > solicited node multicast address for that link local address ? >=20 > =20 >=20 > Regards >=20 > Sachin >=20 > =20 >=20 > =20 >=20 >=20 > -----------------------------------------------------------------------= - >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From oczfdq@o2.pl Thu Feb 3 06:01:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09966; Thu, 3 Feb 2005 06:01:30 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwf2O-0001ZM-8v; Thu, 03 Feb 2005 06:20:43 -0500 Received: from [211.197.172.224] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Cwejo-0001Qr-DC; Thu, 03 Feb 2005 06:01:29 -0500 Received: from symphony-92.iinet.net.au ([64.220.90.21]:1906 "HELO mail.ies.edu") by ies.edu with SMTP id ; Thu, 03 Feb 2005 06:59:18 -0400 Date: Thu, 03 Feb 2005 15:55:18 +0500 Message-Id: <1.2.80.2081924.0083fc70@ies.edu> From: "Rosendo Ohara" To: Subject: Here you go. X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 6.3 (++++++) X-Spam-Flag: YES X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit meme only . septacro resorcinol cattail. sanctify throttle scuffle dentistry glenn simplicity cumberland egipt. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit shovel skit
You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web
Guaranteed.
 
 
 
 
 
 
.
.
.
http://www.193.boprjdncmdhe.com/ You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web Guaranteed.
.  
   
NOMORE ------------A85031401794097-- ------------A48356845382213 Content-Type: image/jpeg; name="kruse.JPG" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAEAsLCwwLEAwMEBcPDQ8XGxQQEBQbHxcXFxcXHx4XGhoaGhceHiMlJyUjHi8vMzMvL0BAQEBA QEBAQEBAQEBAQAERDw8RExEVEhIVFBEUERQaFBYWFBomGhocGhomMCMeHh4eIzArLicnJy4rNTUw MDU1QEA/QEBAQEBAQEBAQEBA/8AAEQgA5QCdAwEiAAIRAQMRAf/EAI4AAAIDAQEBAAAAAAAAAAAA AAMFAgQGAAEHAQADAQEBAAAAAAAAAAAAAAABAgMEAAUQAAICAQMDAgMFBgQHAAAAAAECAAMRIRIE MUEFURNhcQaBoSIyFJHR4UJSI7FyklPBYoLiMyQlEQACAgEDAwUBAAMAAAAAAAAAARECAyExEkFR ImFxMhMEgfByI//aAAwDAQACEQMRAD8AXLoJzMcayG5h0njMxnpwea7aEW1nqdZDOsLUMnEYSZZc 4uhBGhjei/TDCLaKDLqK6jEjeGUTLhvqA9IE8lTp2lZ0Y94I1uPlE4oaWWQ6k6yFpHaeVq3pJWUv jpiGNTkUbdZXYGWbVI6wLEYlEKyrYZXYw9xgNuTHWxJ7nIJaqXvI1VCXUqULFbHVSs3SOfBcRRm5 hlj0iw1/iHpNB4usJWCDJ5H4+5Sq1GtYAEl+HdIBxiA/UL723PaZoLtpIwgsyZOBQEQoM3mRakSJ a4SqGy2ogDDUMBOewEtRtUVxpCNaoGJQHICiV35DE9ZPjI42FqnvDVlTEH6l1PWWaOeR1gdGcmaK mqvGcT26tdsV1eVVRrOu8urDCyfC0leSgDzQAxxKW3IyfsE9u5BfvOrcMmO4lkoRPdlW2rPTrBoA JafTUyqSAYyA0k5LVeBLFZzpFwuxLXFuBYA9IGgJpuC8vGZ9QIw4vuVYB0hONWNolpkG3pIWt0Kq pA34WUPf/wDa69oXkNocaRXvb3s951a6N+gHuha9ZRipGqnBkdsY+WqFfkLlA03Z/bKe0S6tKT7g tSG0CxPRkQmye+3DIvEgXOIItrDMkEyQgaZHMksjtnoBgCkTye08Jb1nuDOwZwYPBmTBxIgGSCmc A5jmAdSTDEGdtzOQttSvtMNSSrCT9ueiuGRVVpyPeDzQECv26GXW5lZXrM9TYVGDDe5p1kbUUl1Z wXnuVyVzBbF3bpSFjBsgyfvH+E7icWvNoH59jD4CLShEt38pbrXsP8xJgiVMaqhJBbltggsIqSQU QigQgIGjIleynEYqARBXJAmAXe1rPfZhymslthkJW2TtkOVkSpnHEAkIqAyPSSV8TjiRrXErsuGh zYMSu5y0KFaLFNe6H/SNjQTzhDJEcVUgrJ2tByUib9Mw7TvaI6x4eMMdJXsoWD7B+IqKayOw5lm2 rB0gvxZxiNJ0C4uRO95hPGUiQwZUk2w45BhF5REqhZ2DOhHcmMF5Q9Z6eRmLskT0WGDiFXLwcEwy LmUarNYz41T2LuGi+p/4RLaFK+WwJqzBssuutanDEn1wIejxVPMUtRyNR1UrqPvifZVbsp9duwnM iY05fgebShsrxco1IXRv9PeJmY5j1srbORLVa3UBNJ2wGDDGTDmMIWuIdriPuMcgTOVOQQY44fIG ACZLIgoZkaSreMSytgIgrgrCRW5QWMNzTz2hmGsTHSQ9t9m7tKzoKdb9N2kZSxSfQ6Ssfp3mDuuf SM+P5yljstyp9esaVsly5XDAxPuuuqLPBV9DJWeF59fWrd/l1lV+PbWcWIV+Ym59p1/Icj0MiUrt Pt2Vjd6EQr9D6pMR/nXRtGDZYPGs2nK+nuLyAfbX2nPQjp+yZrneNv4N3tXDrqrDoRLUy1tot+xG +G1dXseeP4wut/F/40G5z8PT7YystycL+FB0AguMns8Nf6rTvPyGizs95K9pt7GnFXjVd2cTI8Xk vx+R71RwEOo9fhIXPtXHc9JJa9tew9Tq3zk3roVRsePbXyKUur/K4z8og+p/EIEPkaFwQQL1HQ56 P++XPpy8tXZQTnbhl+3QxxbUl1b1WDKWKVYfAjEnWzpeV/iOvVWUM+bDE9BncituPfZQ35qmZD/0 nEFum9amBuNC7TgmXUda8Exbxid4jCwKUES7grjryLtXLrx1hvdRho0QPlToSJyci5ejSM19in1D xkJ75EsbV/TEfERdwuQ9gw0ue7ps+2BvYatIT9UZ6s5umu8UP7QMyPGCNaCHAPo2k2PjFC0rqPsO ZJvxLIZKJLaOuOk8WTkwHmBMz9Utv5NVf9CE/wCo/wAJp5j/ADtps8lbg5C4UfYJb86857Inmfh7 sjcAorQdFrUfdmBJhb9Sjf1Ip+4SrcxxsHVpRvqMuh5X/csLn8qdPn2hc6zlQIoQdup+M6BBGf06 2Oayj+ZWz/jNLM19PLu5zMOiq37ppZC/yG7GB+pKSnmeTtGjlX+1lBMV4YdQY6+orv8A7N4xkLtH 7FEq0X1D86zdRvhX/VGG9U7216sr8dsHMtvaCJCxVdiyDSBsVhEytxoi2FQeu0ip1gHNgnLaw6iZ my6GfGt2GXPe1zFCXiG/UDbOVtGgwecTVgGAx8ZpOFQhUFAB/lyIl4nDs3Dbgn1j/hpcgG4faNZS 9IUSTreRhUHUfmP2w4LesHWdIXSQaHkjZuKEE406iY7l01ixsHOpzma3lNilsHBxMjeDvIb1+6aP z9SGd7EgQ3GRv9vKH5DUQFKl2NzdtF+cnWFIeoEYcaj0I6GEKBMIOi6Q3Xl6bj47J19VoQxOOgJ9 JI4Gs9qps5Nq1VjLMdP3wNwOkOPpqgqlt5HXCg/eY8JCgsxwoGSfgIHicdeLx0oX+Uan1PcxZ9Re QFPGPDrb+9cPx4/lT/ukFV2tC6nWskm+xkudceTy7uR/uuzD5E6fdBDcIQoQdRpOSvc2J6C0XsY9 37hePvOghrKHYdNZc4XHVQCRGHtVMMYkrXUl60cGdfhcgIbNv4RABddRNfT4tH1OQp7TzkeA47od gw3rJ88bcMbjZbGUFaHtJ+yuIXkcWzj2mtxqOhkMnGJzx1lPoFXcPuOaHCHJAHyl6rnUdCOneLdp xjGJ7t0Gsd1T3Myu0O08hx/XEJ+uoIyrCZ/qZPBONdIjx1H+1jXl8xHrIGoiPkBQC5OB98I7E6A/ LWVL2y2Ccgdo9aqoG3dgdrMwIwoPQnrCE2KMEhwOmNIN3ywksg9oLWb0LVoq6ovcXgPyVDjdt74G cffHPHr4vjKGu9uxm/nfblsfIHpEfjuY3HuB12HRhNQjB0B65EheU9divTQSc36rQIU4VTbyNLLN APkveIf1TW2NZcxexzkuTrmOvNeJpX+9XhA3bGm6IDTg40/jNOJU4zVQZcnOdXJaWtXXIIz1xPa6 wrdJUXcunaWKnPWNdwgY1LGNb7RgS9wlNtmOw6xQlms0XiKdtO89Wma70NaGCKFGJLGk6dInGf8A PUAOlgHXSKNn7ZpPM1GypcdQYo/TN6azTW3/ADfsyL+f9RJST30hABiBRX9IUZ9I7MwT2x6T32tO k5ZPOkWQlY0dT3i7lArZgxyRpFXkUO/dGq5GroymTJgwRyZJSREa1NKYddMTUeLcvx1BOSNJlUOu TND4S0GthEuvEKGHKpF1DowzkHExHLr9ux19DN6SMTHeZqA5DlfXMb871aJ5lpIrzrDo2BAAawgE bPbZHYFo2XOKDZaqDuZs+OgSpVHYTK+Dq38tc9tZr1GBM9nJdnTp06IAo+SICL8/lF2/XOTiXPKW V7lUsAygtgxb7lOPc+z/AJcy6Xh/GRb8/wCoPWFGhhvaU9IM1kSallMZs7giXsSJplhCWhBWTF5C vH2KOw95T5tYKGOWo0i3l0kZEaltRLVaM652tiTSxcSXK45BJlP8SnEs6zqhq36MvowJj7w1Y2kg 9ZmKmbM0virfbq1krp8StXqNbAwU4My3lBYbWzrH9/NAU4iDl3ByfjOwppyLlcoXBMGT2zlGWhAs Gb5DYviOfp2v+4z+k0kR/T64rY/GPJC25RnTw6CdBciwVUs50AEC1YHsJefcr8hj/ToDKWE37sHX qO2R3kbbfcJfvqYHc2Os1qvjHpBj5eU+pp1pDCejjDMLWNIYCZuTNsIClAEIEAhAJ0EsBEqMRfza hiMjKXLGTiGj1EyLQQ8rj57RXbxyD0mitrzKdnHUmaq3M0CmmolhHNClKwOkEtVaa9569uBpOs5K VtBHmXbUIB6xTY59ZZ5DM0psDHqoRO9pCU5JlsVmUq2KHMvU8lG0MTLXqWwW0geeCGK2HxjiJvEW puKg9e0ciZLbl2dFXmb8Ve0p1br8oyutWpCzdBM5yrWvtLt9nyj4qy57EstoUdymyHGIPafXvDOd ILdNXQzGwQaQogK3yIYNMRuZKezzM7MADj0la5cmHYwLmMhbFOxJVsrl9hAOJRMhZC9q4KxNJdZY CxZRMQWXKZXK6xhYmTA2VgDMomArbAdISugDUQQb8UPW2TJ5X0NOKqSkv8BLVsUr2mlqYlRnrFHi 6cjcY3Ggme25Vg+TX7i4PSKL6ACY5c6RVymwTHxt7EsiW4ttTB0lbB3Ylq1tYHK5zNC2IRqaGm04 llXMV03y5XcJldTZJcDT3dALaJIOCYIAwhMG0lmRacTYJoFxDEQbiOhGV2WBdBLLCDZYyZNlGysy pyMhYzdMyjzE0MpV6iirP4pa44LOBKp0bEYeOTdYIuT5GrG/E0nAr2VCW4GgYQCFJmd7lAdrYUxH zL8MY35NgCGZvm2Zc6y2FEsj0PGsBgd53YgTZjvI+5rNEEJHVW+W6986dIM0h13Q9XXXrOnRGBh9 JFsTp0UAMwbTp0IjBN8JA7p06MibPD0lHm7dpnTo9dwMSN+eNvF7dwnTp19zRj2NHV+USTZxOnSH UoUOdv2HEzfI37jmdOmjFsSyFQ7pH8WZ06WIdT//2Q== ------------A48356845382213-- From mip6-bounces@ietf.org Fri Feb 4 08:32:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25501 for ; Fri, 4 Feb 2005 08:32:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx3s5-0001Sp-VJ for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 08:51:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx3Rj-0006qR-PN; Fri, 04 Feb 2005 08:24:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx0Hm-0002aY-3Y for mip6@megatron.ietf.org; Fri, 04 Feb 2005 05:01:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08325 for ; Fri, 4 Feb 2005 05:01:54 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx0aQ-0003pf-Hw for mip6@ietf.org; Fri, 04 Feb 2005 05:21:20 -0500 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 <0IBD001YQT0597@szxga01-in.huawei.com> for mip6@ietf.org; Fri, 04 Feb 2005 17:57:41 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBD00CMXT05P1@szxga01-in.huawei.com> for mip6@ietf.org; Fri, 04 Feb 2005 17:57:41 +0800 (CST) Received: from keshavaak ([10.18.4.181]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IBD000TPT11KU@szxml02-in.huawei.com> for mip6@ietf.org; Fri, 04 Feb 2005 17:58:14 +0800 (CST) Date: Fri, 04 Feb 2005 15:26:24 +0530 From: keshav To: mip6@ietf.org Message-id: <000001c50a9f$ca094490$b504120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a X-Mailman-Approved-At: Fri, 04 Feb 2005 08:24:26 -0500 Subject: [Mip6] MIP6 Mobile Node ( MN) available X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: keshavak@huawei.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0569279613==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 This is a multi-part message in MIME format. --===============0569279613== Content-type: multipart/alternative; boundary="Boundary_(ID_cXHFM0Zvjt01TmbtcDkT9w)" This is a multi-part message in MIME format. --Boundary_(ID_cXHFM0Zvjt01TmbtcDkT9w) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, Any MN is available with MIP6 support? (Of course other than Linux support) Regards, Keshava --Boundary_(ID_cXHFM0Zvjt01TmbtcDkT9w) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

Any MN is available with MIP6 support?

(Of course other than Linux support)

 

Regards,

Keshava

--Boundary_(ID_cXHFM0Zvjt01TmbtcDkT9w)-- --===============0569279613== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0569279613==-- From mip6-bounces@ietf.org Fri Feb 4 10:32:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06943 for ; Fri, 4 Feb 2005 10:32:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx5ku-0004Qs-Uy for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 10:52:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5JA-0006EQ-Ev; Fri, 04 Feb 2005 10:23:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5Gh-0004qr-M7 for mip6@megatron.ietf.org; Fri, 04 Feb 2005 10:21:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05870 for ; Fri, 4 Feb 2005 10:21:09 -0500 (EST) Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx5ZU-0004Ae-WE for mip6@ietf.org; Fri, 04 Feb 2005 10:40:37 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id j14FRKoO023893; Fri, 4 Feb 2005 08:27:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j14FLsDk004409; Fri, 4 Feb 2005 09:21:55 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C0CFC86602B; Fri, 4 Feb 2005 16:20:59 +0100 (CET) Message-ID: <420392D6.60103@motorola.com> Date: Fri, 04 Feb 2005 16:20:54 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] HA prefix = HoA prefix? References: <16888.2098.511732.472518@gargle.gargle.HOWL> <41F8C846.50008@iprg.nokia.com> In-Reply-To: <41F8C846.50008@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: mip6@ietf.org, Pete McCann X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1463353781==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1463353781== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig64DA0D637F0070F7CD3B8E6E" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig64DA0D637F0070F7CD3B8E6E Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > it is actually a bit restrictive. I find it not restricctive but allowing one-interface HAs non-default-routers to exist. > our HA implementation does not do this check. Ours does. > instead, it just checks if the HoA of the MN falls in one of the > prefixes that the HA is configured to serve. Ours doesn't. Our HA is a standalone one-interface machine, does not serve a link's prefix, the link is served by a separate Gateway that is the Default Router for that link. > RFC 3963 relaxes this requirement for Mobile Routers. a Mobile Router > has an option of configuring its HoA from the Mobile Network Prefix > (delegated to the Mobile Router for use in the Mobile Network). the > Mobile Network Prefix can be different from the home prefix. That's another issue. Alex > > Vijay > > Pete McCann wrote: > >> Hi, >> >> My apologies if this question has been raised/answered here before. >> >> >> Given the following text in RFC 3775, section 6.1.7: >> >> >>> Home Registration (H) >>> >>> The Home Registration (H) bit is set by the sending mobile node >>> to request that the receiving node should act as this node's home >>> agent. The destination of the packet carrying this message MUST >>> be that of a router sharing the same subnet prefix as the home >>> address of the mobile node in the binding. >> >> >> >> does this imply that the HA address (the destination of the packet) >> must share the same prefix with the home address? >> >> A possible alternative interpretation is that the router must have >> some interface on the home link but this is not necessarily used as >> the the destination of the packet. >> >> Thoughts? >> >> -Pete >> >> >> _______________________________________________ Mip6 mailing list >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ Mip6 mailing list > Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------enig64DA0D637F0070F7CD3B8E6E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCA5LbMmC0w56zj54RAqxwAKCs7HzCjCRUaNVowlS+IkfP2LGC6QCfRsoK sOCB252XcBhboSjnJVpVSYI= =IiEd -----END PGP SIGNATURE----- --------------enig64DA0D637F0070F7CD3B8E6E-- --===============1463353781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1463353781==-- From mip6-bounces@ietf.org Fri Feb 4 11:52:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13911 for ; Fri, 4 Feb 2005 11:52:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx70O-0006KV-N9 for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 12:12:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx6g3-0005FS-5G; Fri, 04 Feb 2005 11:51:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx6fU-000570-K7 for mip6@megatron.ietf.org; Fri, 04 Feb 2005 11:50:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13785 for ; Fri, 4 Feb 2005 11:50:49 -0500 (EST) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx6yG-0006HZ-7k for mip6@ietf.org; Fri, 04 Feb 2005 12:10:18 -0500 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j14GoBeD013075 for ; Fri, 4 Feb 2005 08:50:12 -0800 (PST) Received: from WLAU.qualcomm.com (qconnect-10-50-68-169.qualcomm.com [10.50.68.169]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j14Go95J020316 for ; Fri, 4 Feb 2005 08:50:10 -0800 (PST) Message-Id: <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> X-Sender: wlau@qcmail1.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 6.0.0.22 Date: Fri, 04 Feb 2005 08:50:07 -0800 To: mip6@ietf.org From: Wing Cheong Lau Subject: Re: [Mip6] HA prefix = HoA prefix? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.0.111621 X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 >Date: Fri, 04 Feb 2005 08:47:37 -0800 >To: Alexandru Petrescu >From: Wing Cheong Lau >Subject: Re: [Mip6] HA prefix = HoA prefix? > >At 07:20 AM 2/4/2005, you wrote: >>Vijay Devarapalli wrote: >>>it is actually a bit restrictive. >> >>I find it not restricctive but allowing one-interface HAs >>non-default-routers to exist. Dear Alex, Removing the "HA prefix = HoA prefix" restriction would only make the system more flexible, e.g. allowing virtual home-links for which the MS never returns home. It would not preclude your case of a one-interface HAs non-default-routers, right ? Or am I missing something here ? Regards, Wing >>>our HA implementation does not do this check. >> >>Ours does. >> >>>instead, it just checks if the HoA of the MN falls in one of the >>>prefixes that the HA is configured to serve. >> >>Ours doesn't. Our HA is a standalone one-interface machine, does not >>serve a link's prefix, the link is served by a separate Gateway that is >>the Default Router for that link. >> >>>RFC 3963 relaxes this requirement for Mobile Routers. a Mobile Router >>>has an option of configuring its HoA from the Mobile Network Prefix >>>(delegated to the Mobile Router for use in the Mobile Network). the >>>Mobile Network Prefix can be different from the home prefix. >> >>That's another issue. >> >>Alex >> >>>Vijay >>>Pete McCann wrote: >>> >>>>Hi, >>>>My apologies if this question has been raised/answered here before. >>>> >>>>Given the following text in RFC 3775, section 6.1.7: >>>> >>>>>Home Registration (H) >>>>>The Home Registration (H) bit is set by the sending mobile node >>>>>to request that the receiving node should act as this node's home >>>>> agent. The destination of the packet carrying this message MUST >>>>> be that of a router sharing the same subnet prefix as the home >>>>> address of the mobile node in the binding. >>>> >>>>does this imply that the HA address (the destination of the packet) >>>> must share the same prefix with the home address? >>>>A possible alternative interpretation is that the router must have some >>>>interface on the home link but this is not necessarily used as >>>> the the destination of the packet. >>>>Thoughts? >>>>-Pete >>>> >>>>_______________________________________________ Mip6 mailing list >>>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >>> >>>_______________________________________________ Mip6 mailing list >>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 4 13:02:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20072 for ; Fri, 4 Feb 2005 13:02:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx85c-00086a-Qk for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 13:22:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx7hY-0005Jq-QX; Fri, 04 Feb 2005 12:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx7gK-00054C-GZ for mip6@megatron.ietf.org; Fri, 04 Feb 2005 12:55:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19514 for ; Fri, 4 Feb 2005 12:55:44 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx7z7-0007xz-VT for mip6@ietf.org; Fri, 04 Feb 2005 13:15:15 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j14Hth821843 for ; Fri, 4 Feb 2005 19:55:44 +0200 (EET) X-Scanned: Fri, 4 Feb 2005 19:55:17 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j14HtHc2022766 for ; Fri, 4 Feb 2005 19:55:17 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00O18gZ4; Fri, 04 Feb 2005 19:55:15 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j14Ht9x04966 for ; Fri, 4 Feb 2005 19:55:10 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Feb 2005 11:54:11 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Feb 2005 11:54:11 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C794@daebe101.NOE.Nokia.com> Thread-Topic: Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcUK4og2KJLwUVU5Q4mdYxbVSMhNdg== To: X-OriginalArrivalTime: 04 Feb 2005 17:54:11.0810 (UTC) FILETIME=[8873BC20:01C50AE2] X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable The goals/reasons for a standardized interface between the HA and AAA were discussed at IETF61 in Gerardo's I-D : draft-giaretta-mip6-aaa-ha-goals-00.txt=20 Such an interface is required from the perspective of bootstrapping a MN in operator owned network environments.=20 We would like to make this I-D a working group document that captures the goals and requirements for the interface between the HA and AAA and is used as input in the design of the bootstrapping solution that relies on AAA. Please comment if you do not agree to making this a WG document and your reasons by Feb 10th, 05.=20 -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 4 13:42:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22623 for ; Fri, 4 Feb 2005 13:42:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx8ii-0000U3-Jn for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 14:02:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx8Gj-00065k-Vh; Fri, 04 Feb 2005 13:33:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx8EA-0005bw-2p for mip6@megatron.ietf.org; Fri, 04 Feb 2005 13:30:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21759 for ; Fri, 4 Feb 2005 13:30:41 -0500 (EST) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx8Wx-0000At-FV for mip6@ietf.org; Fri, 04 Feb 2005 13:50:13 -0500 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j14IU3W21404; Fri, 4 Feb 2005 19:30:03 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id j14IU3Sj005210; Fri, 4 Feb 2005 19:30:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200502041830.j14IU3Sj005210@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Wing Cheong Lau Subject: Re: [Mip6] HA prefix = HoA prefix? In-reply-to: Your message of Fri, 04 Feb 2005 08:50:07 PST. <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> Date: Fri, 04 Feb 2005 19:30:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 In your previous mail you wrote: Removing the "HA prefix = HoA prefix" restriction would only make the system more flexible, e.g. allowing virtual home-links for which the MS never returns home. => they are already allowed... Or am I missing something here ? => more flexible = more error prone. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 4 15:22:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01033 for ; Fri, 4 Feb 2005 15:22:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxAH1-0002eg-2j for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 15:41:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9sy-000848-R5; Fri, 04 Feb 2005 15:17:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx9nB-0003zK-Rx for mip6@megatron.ietf.org; Fri, 04 Feb 2005 15:11:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29188 for ; Fri, 4 Feb 2005 15:10:59 -0500 (EST) 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.33) id 1CxA60-0002ET-JY for mip6@ietf.org; Fri, 04 Feb 2005 15:30:30 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Feb 2005 12:18:14 -0800 Received: from alpeshw2k03 (dhcp-171-68-149-11.cisco.com [171.68.149.11]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j14KAMoQ015776; Fri, 4 Feb 2005 12:10:23 -0800 (PST) Message-Id: <200502042010.j14KAMoQ015776@sj-core-1.cisco.com> From: "Alpesh" To: "'Wing Cheong Lau'" , Subject: RE: [Mip6] HA prefix = HoA prefix? Date: Fri, 4 Feb 2005 12:10:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> Thread-Index: AcUK2jIfef9ZGQUASnK4gkuuO0inoQAGyAvg X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Lau: Support for "virtual homes" can be done in various ways. I don't see a strong reason to remove this aspect from the spec.. Plus, what happens to the "DHAAD mechanism" mechanism? -a > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > Behalf Of Wing Cheong Lau > Sent: Friday, February 04, 2005 8:50 AM > To: mip6@ietf.org > Subject: Re: [Mip6] HA prefix = HoA prefix? > > > >Date: Fri, 04 Feb 2005 08:47:37 -0800 > >To: Alexandru Petrescu > >From: Wing Cheong Lau > >Subject: Re: [Mip6] HA prefix = HoA prefix? > > > >At 07:20 AM 2/4/2005, you wrote: > >>Vijay Devarapalli wrote: > >>>it is actually a bit restrictive. > >> > >>I find it not restricctive but allowing one-interface HAs > >>non-default-routers to exist. > > > Dear Alex, > > Removing the "HA prefix = HoA prefix" restriction would only > make the system more flexible, e.g. allowing virtual > home-links for which the MS never returns home. > > It would not preclude your case of a one-interface HAs > non-default-routers, right ? > > Or am I missing something here ? > > Regards, > > Wing > > > >>>our HA implementation does not do this check. > >> > >>Ours does. > >> > >>>instead, it just checks if the HoA of the MN falls in one of the > >>>prefixes that the HA is configured to serve. > >> > >>Ours doesn't. Our HA is a standalone one-interface > machine, does not > >>serve a link's prefix, the link is served by a separate > Gateway that > >>is the Default Router for that link. > >> > >>>RFC 3963 relaxes this requirement for Mobile Routers. a > Mobile Router > >>>has an option of configuring its HoA from the Mobile > Network Prefix > >>>(delegated to the Mobile Router for use in the Mobile > Network). the > >>>Mobile Network Prefix can be different from the home prefix. > >> > >>That's another issue. > >> > >>Alex > >> > >>>Vijay > >>>Pete McCann wrote: > >>> > >>>>Hi, > >>>>My apologies if this question has been raised/answered > here before. > >>>> > >>>>Given the following text in RFC 3775, section 6.1.7: > >>>> > >>>>>Home Registration (H) > >>>>>The Home Registration (H) bit is set by the sending > mobile node to > >>>>>request that the receiving node should act as this node's home > >>>>> agent. The destination of the packet carrying this > message MUST > >>>>> be that of a router sharing the same subnet prefix as > the home > >>>>>address of the mobile node in the binding. > >>>> > >>>>does this imply that the HA address (the destination of > the packet) > >>>> must share the same prefix with the home address? > >>>>A possible alternative interpretation is that the router > must have > >>>>some interface on the home link but this is not > necessarily used as > >>>> the the destination of the packet. > >>>>Thoughts? > >>>>-Pete > >>>> > >>>>_______________________________________________ Mip6 mailing list > >>>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >>> > >>>_______________________________________________ Mip6 mailing list > >>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> > >> > >> > >>_______________________________________________ > >>Mip6 mailing list > >>Mip6@ietf.org > >>https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 4 17:31:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14402 for ; Fri, 4 Feb 2005 17:31:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCIC-0006XF-BN for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 17:51:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxBxi-0006kB-OX; Fri, 04 Feb 2005 17:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxBvV-00025t-Iv for mip6@megatron.ietf.org; Fri, 04 Feb 2005 17:27:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14082 for ; Fri, 4 Feb 2005 17:27:42 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24] helo=mailout1) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCEL-0006Qh-K8 for mip6@ietf.org; Fri, 04 Feb 2005 17:47:15 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IBE00601RP60D@mailout1.samsung.com> for mip6@ietf.org; Sat, 05 Feb 2005 07:27:06 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBE00G87RP6FO@mailout1.samsung.com> for mip6@ietf.org; Sat, 05 Feb 2005 07:27:06 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IBE00348RP47O@mmp1.samsung.com> for mip6@ietf.org; Sat, 05 Feb 2005 07:27:06 +0900 (KST) Date: Fri, 04 Feb 2005 14:27:04 -0800 From: Alper Yegin Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <456943D540CFC14A8D7138E64843F85308C794@daebe101.NOE.Nokia.com> To: Basavaraj.Patil@nokia.com, mip6@ietf.org Message-id: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7BIT Before we get to listing the requirements, we (MIP6 WG) should identify different frameworks where "mip6" gets mixed up with "aaa". Following that, we can discuss which one of the frameworks we'd like to standardize in IETF, and drive the requirements based on that. This was the motivation behind writing draft-yegin-mip6-aaa-fwk-00.txt. 4 different frameworks are mentioned in that I-D, with one being detailed. I have no objection to using mip6-aaa-ha-goals, but I recommend we capture the framework discussions. For that, my recommendation is to produce a WG I-D combining both individual I-Ds. Besides, mip6-aaa-fwk has detailed discussions on call flow (good for finding out the exact requirements), EAP considerations, why we need a new AAA application, and relation to mip6 bootstrapping -- which are worth capturing in the WG I-D. Alper > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of > Basavaraj.Patil@nokia.com > Sent: Friday, February 04, 2005 9:54 AM > To: mip6@ietf.org > Subject: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt > > > The goals/reasons for a standardized interface between the HA and AAA > were discussed at IETF61 in Gerardo's I-D : > draft-giaretta-mip6-aaa-ha-goals-00.txt > Such an interface is required from the perspective of bootstrapping a > MN in operator owned network environments. > > We would like to make this I-D a working group document that captures > the goals and requirements for the interface between the HA and AAA > and is used as input in the design of the bootstrapping solution that > relies on AAA. > > Please comment if you do not agree to making this a WG document and > your reasons by Feb 10th, 05. > > -Basavaraj > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 4 17:59:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16318 for ; Fri, 4 Feb 2005 17:59:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCjM-00077g-F9 for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 18:19:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxCJS-0002Rs-J0; Fri, 04 Feb 2005 17:52:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxCFb-0001o9-Vo for mip6@megatron.ietf.org; Fri, 04 Feb 2005 17:48:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15465 for ; Fri, 4 Feb 2005 17:48:28 -0500 (EST) Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxCYS-0006tq-Ip for mip6@ietf.org; Fri, 04 Feb 2005 18:08:01 -0500 Received: from az33mta03.mot.com (az33exr03.mot.com [10.64.251.233]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id j14MmSED003156; Fri, 4 Feb 2005 15:48:29 -0700 (MST) Received: from [10.181.32.11] (mvp-10-181-32-11.ea.mot.com [10.181.32.11]) by az33mta03.mot.com (8.13.1/8.13.0) with ESMTP id j14MmSFM001617; Fri, 4 Feb 2005 16:48:29 -0600 (CST) Message-ID: <4203FBB3.6020101@motorola.com> Date: Fri, 04 Feb 2005 23:48:19 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wing Cheong Lau Subject: Re: [Mip6] HA prefix = HoA prefix? References: <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> In-Reply-To: <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1130200646==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1130200646== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2F784EEF1242D5E4D16E5883" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2F784EEF1242D5E4D16E5883 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Wing Cheong Lau wrote: > Removing the "HA prefix = HoA prefix" restriction would only make the > system more flexible, > e.g. allowing virtual home-links for which the MS never returns home. Let me turn your below question back: do you think that without the HoA's prefix matching exactly the Home Link prefix there could exist no virtual home-links? It's not true: just make the HoA's prefix match exactly the prefix of that virtual link. RAs work over virtual links. > It would not preclude your case of a one-interface HAs > non-default-routers, right ? I didn't say so. If you wish to know my rhetorics, it is that removing that restriction makes it possible to have some particular cases of Home Networks. Ok, possible. But what is the _need_ for these configurations? Why would a MH connecting to a Home Link _need_ a HoA that is _not_ matching the home link prefix? Vijay, if the implementation checks the HoA be in the prefix "served" by the HA, then will the implementation work when the HA does not "serve" the prefix? MUST that particular implementation be configured to "serve" the Home Network prefix in order to be able to have MIP6 tunnels to MHs? Where is this checking more exactly? In the NC? In the routing table? Alex --------------enig2F784EEF1242D5E4D16E5883 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCA/u5MmC0w56zj54RAp5LAKCC2KQ/1t/XQ98Kt5NJv/fQd5dMwwCdHmrL QModO4qmONv4vmnFvjaurX0= =0iRW -----END PGP SIGNATURE----- --------------enig2F784EEF1242D5E4D16E5883-- --===============1130200646== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1130200646==-- From mip6-bounces@ietf.org Fri Feb 4 20:54:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29805 for ; Fri, 4 Feb 2005 20:54:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxFSt-0002PS-DT for mip6-web-archive@ietf.org; Fri, 04 Feb 2005 21:14:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxF7h-0005b8-Jj; Fri, 04 Feb 2005 20:52:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxF6S-0005Gu-L6 for mip6@megatron.ietf.org; Fri, 04 Feb 2005 20:51:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29606 for ; Fri, 4 Feb 2005 20:51:14 -0500 (EST) Message-Id: <200502050151.UAA29606@ietf.org> Received: from smtp814.mail.sc5.yahoo.com ([66.163.170.84]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CxFPJ-0002LB-WF for mip6@ietf.org; Fri, 04 Feb 2005 21:10:47 -0500 Received: from unknown (HELO ed3GHZP4) (elmic@sbcglobal.net@64.170.248.130 with login) by smtp814.mail.sc5.yahoo.com with SMTP; 5 Feb 2005 01:51:08 -0000 From: "Ed Remmell" To: , Subject: RE: [Mip6] MIP6 Mobile Node ( MN) available Date: Fri, 4 Feb 2005 17:51:24 -0800 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcUKvfXevbiDpc2pRCCg0fVA/SO/tAAZtFrQ In-Reply-To: <000001c50a9f$ca094490$b504120a@in.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.3 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0174289522==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba This is a multi-part message in MIME format. --===============0174289522== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C50AE2.24FA7E90" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C50AE2.24FA7E90 Content-Type: text/plain; charset="windows-1250" Content-Transfer-Encoding: 7bit Keshava - We have MIPv6 MN + CN protocols for real-time embedded systems as a product. See HYPERLINK "http://www.treck.com/PDF/Mobile_IPv6.pdf"http://www.treck.com/PDF/Mobile_IP v6.pdf. We also have a port of this to Win32 preemptive threads (runs over winpcap at our device driver level so it bypasses the Win32 protocol stack) available for download as a Win32 binary executable, it can be used to interop test MIPv6, it is here: HYPERLINK "http://www.treck.com/TreckDemo.zip"http://www.treck.com/TreckDemo.zip Thanks. - Ed Remmell Treck, Inc. (formerly Elmic Systems, USA) Best of Show Winner, ESC 2003 _____ From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of keshav Sent: Friday, February 04, 2005 1:56 AM To: mip6@ietf.org Subject: [Mip6] MIP6 Mobile Node ( MN) available Hi, Any MN is available with MIP6 support? (Of course other than Linux support) Regards, Keshava -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.5 - Release Date: 2/3/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.5 - Release Date: 2/3/2005 ------=_NextPart_000_0010_01C50AE2.24FA7E90 Content-Type: text/html; charset="windows-1250" Content-Transfer-Encoding: quoted-printable
Keshava -
 
We have MIPv6 MN + CN protocols for real-time = embedded=20 systems as a product. See http://www.treck.com/PD= F/Mobile_IPv6.pdf.=20 We also have a port of this to Win32 preemptive threads (runs over = winpcap at=20 our device driver level so it bypasses the Win32 protocol stack) = available for=20 download as a Win32 binary executable, it can be used to interop test = MIPv6, it=20 is here: http://www.treck.com/TreckDem= o.zip

Thanks.
- Ed Remmell

Treck, Inc. (formerly Elmic Systems, USA)

Best of Show Winner, ESC 2003

 

From: mip6-bounces@ietf.org=20 [mailto:mip6-bounces@ietf.org] On Behalf Of = keshav
Sent:=20 Friday, February 04, 2005 1:56 AM
To:=20 mip6@ietf.org
Subject: [Mip6] MIP6 Mobile Node ( MN)=20 available

Hi,

Any MN is available with = MIP6=20 support?

(Of course other than = Linux=20 support)

 

Regards,

Keshava


--
No virus found in this incoming = message.
Checked by=20 AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.5 - = Release Date:=20 2/3/2005


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.5 - Release Date: 2/3/2005

------=_NextPart_000_0010_01C50AE2.24FA7E90-- --===============0174289522== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0174289522==-- From bhomhdir@o2.pl Sat Feb 5 01:48:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20345; Sat, 5 Feb 2005 01:48:31 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxK33-0008VS-9e; Sat, 05 Feb 2005 02:08:06 -0500 Received: from [221.140.167.99] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CxJk0-0004Kb-4a; Sat, 05 Feb 2005 01:48:24 -0500 Received: from symphony-16.iinet.net.au ([223.240.6.204]:1906 "HELO mail.ies.edu") by ies.edu with SMTP id ; Sat, 05 Feb 2005 00:40:04 -0600 Date: Sat, 05 Feb 2005 12:41:04 +0600 Message-Id: <0.5.14.2081924.0083fc70@ies.edu> From: "Alfreda Bates" To: Subject: Did you see this? X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 4.1 (++++) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit meme only . septacro resorcinol cattail. sanctify throttle scuffle dentistry glenn simplicity cumberland egipt. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit deflector homebound
You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web
Guaranteed.
 
 
 
 
 
 
.
.
.
http://www.193.csuhqwiyeo.com You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web Guaranteed.
.  
   
NOMORE ------------A85031401794097-- ------------A48356845382213 Content-Type: image/jpeg; name="puppyish.JPG" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAEAsLCwwLEAwMEBcPDQ8XGxQQEBQbHxcXFxcXHx4XGhoaGhceHiMlJyUjHi8vMzMvL0BAQEBA QEBAQEBAQEBAQAERDw8RExEVEhIVFBEUERQaFBYWFBomGhocGhomMCMeHh4eIzArLicnJy4rNTUw MDU1QEA/QEBAQEBAQEBAQEBA/8AAEQgA5QCdAwEiAAIRAQMRAf/EAI4AAAIDAQEBAAAAAAAAAAAA AAMFAgQGAAEHAQADAQEBAAAAAAAAAAAAAAABAgMEAAUQAAICAQMDAgMFBgQHAAAAAAECAAMRIRIE MUEFURNhcQaBoSIyFJHR4UJSI7FyklPBYoLiMyQlEQACAgEDAwUBAAMAAAAAAAAAARECAyExEkFR ImFxMhMEgfByI//aAAwDAQACEQMRAD8AXLoJzMcayG5h0njMxnpwea7aEW1nqdZDOsLUMnEYSZZc 4uhBGhjei/TDCLaKDLqK6jEjeGUTLhvqA9IE8lTp2lZ0Y94I1uPlE4oaWWQ6k6yFpHaeVq3pJWUv jpiGNTkUbdZXYGWbVI6wLEYlEKyrYZXYw9xgNuTHWxJ7nIJaqXvI1VCXUqULFbHVSs3SOfBcRRm5 hlj0iw1/iHpNB4usJWCDJ5H4+5Sq1GtYAEl+HdIBxiA/UL723PaZoLtpIwgsyZOBQEQoM3mRakSJ a4SqGy2ogDDUMBOewEtRtUVxpCNaoGJQHICiV35DE9ZPjI42FqnvDVlTEH6l1PWWaOeR1gdGcmaK mqvGcT26tdsV1eVVRrOu8urDCyfC0leSgDzQAxxKW3IyfsE9u5BfvOrcMmO4lkoRPdlW2rPTrBoA JafTUyqSAYyA0k5LVeBLFZzpFwuxLXFuBYA9IGgJpuC8vGZ9QIw4vuVYB0hONWNolpkG3pIWt0Kq pA34WUPf/wDa69oXkNocaRXvb3s951a6N+gHuha9ZRipGqnBkdsY+WqFfkLlA03Z/bKe0S6tKT7g tSG0CxPRkQmye+3DIvEgXOIItrDMkEyQgaZHMksjtnoBgCkTye08Jb1nuDOwZwYPBmTBxIgGSCmc A5jmAdSTDEGdtzOQttSvtMNSSrCT9ueiuGRVVpyPeDzQECv26GXW5lZXrM9TYVGDDe5p1kbUUl1Z wXnuVyVzBbF3bpSFjBsgyfvH+E7icWvNoH59jD4CLShEt38pbrXsP8xJgiVMaqhJBbltggsIqSQU QigQgIGjIleynEYqARBXJAmAXe1rPfZhymslthkJW2TtkOVkSpnHEAkIqAyPSSV8TjiRrXErsuGh zYMSu5y0KFaLFNe6H/SNjQTzhDJEcVUgrJ2tByUib9Mw7TvaI6x4eMMdJXsoWD7B+IqKayOw5lm2 rB0gvxZxiNJ0C4uRO95hPGUiQwZUk2w45BhF5REqhZ2DOhHcmMF5Q9Z6eRmLskT0WGDiFXLwcEwy LmUarNYz41T2LuGi+p/4RLaFK+WwJqzBssuutanDEn1wIejxVPMUtRyNR1UrqPvifZVbsp9duwnM iY05fgebShsrxco1IXRv9PeJmY5j1srbORLVa3UBNJ2wGDDGTDmMIWuIdriPuMcgTOVOQQY44fIG ACZLIgoZkaSreMSytgIgrgrCRW5QWMNzTz2hmGsTHSQ9t9m7tKzoKdb9N2kZSxSfQ6Ssfp3mDuuf SM+P5yljstyp9esaVsly5XDAxPuuuqLPBV9DJWeF59fWrd/l1lV+PbWcWIV+Ym59p1/Icj0MiUrt Pt2Vjd6EQr9D6pMR/nXRtGDZYPGs2nK+nuLyAfbX2nPQjp+yZrneNv4N3tXDrqrDoRLUy1tot+xG +G1dXseeP4wut/F/40G5z8PT7YystycL+FB0AguMns8Nf6rTvPyGizs95K9pt7GnFXjVd2cTI8Xk vx+R71RwEOo9fhIXPtXHc9JJa9tew9Tq3zk3roVRsePbXyKUur/K4z8og+p/EIEPkaFwQQL1HQ56 P++XPpy8tXZQTnbhl+3QxxbUl1b1WDKWKVYfAjEnWzpeV/iOvVWUM+bDE9BncituPfZQ35qmZD/0 nEFum9amBuNC7TgmXUda8Exbxid4jCwKUES7grjryLtXLrx1hvdRho0QPlToSJyci5ejSM19in1D xkJ75EsbV/TEfERdwuQ9gw0ue7ps+2BvYatIT9UZ6s5umu8UP7QMyPGCNaCHAPo2k2PjFC0rqPsO ZJvxLIZKJLaOuOk8WTkwHmBMz9Utv5NVf9CE/wCo/wAJp5j/ADtps8lbg5C4UfYJb86857Inmfh7 sjcAorQdFrUfdmBJhb9Sjf1Ip+4SrcxxsHVpRvqMuh5X/csLn8qdPn2hc6zlQIoQdup+M6BBGf06 2Oayj+ZWz/jNLM19PLu5zMOiq37ppZC/yG7GB+pKSnmeTtGjlX+1lBMV4YdQY6+orv8A7N4xkLtH 7FEq0X1D86zdRvhX/VGG9U7216sr8dsHMtvaCJCxVdiyDSBsVhEytxoi2FQeu0ip1gHNgnLaw6iZ my6GfGt2GXPe1zFCXiG/UDbOVtGgwecTVgGAx8ZpOFQhUFAB/lyIl4nDs3Dbgn1j/hpcgG4faNZS 9IUSTreRhUHUfmP2w4LesHWdIXSQaHkjZuKEE406iY7l01ixsHOpzma3lNilsHBxMjeDvIb1+6aP z9SGd7EgQ3GRv9vKH5DUQFKl2NzdtF+cnWFIeoEYcaj0I6GEKBMIOi6Q3Xl6bj47J19VoQxOOgJ9 JI4Gs9qps5Nq1VjLMdP3wNwOkOPpqgqlt5HXCg/eY8JCgsxwoGSfgIHicdeLx0oX+Uan1PcxZ9Re QFPGPDrb+9cPx4/lT/ukFV2tC6nWskm+xkudceTy7uR/uuzD5E6fdBDcIQoQdRpOSvc2J6C0XsY9 37hePvOghrKHYdNZc4XHVQCRGHtVMMYkrXUl60cGdfhcgIbNv4RABddRNfT4tH1OQp7TzkeA47od gw3rJ88bcMbjZbGUFaHtJ+yuIXkcWzj2mtxqOhkMnGJzx1lPoFXcPuOaHCHJAHyl6rnUdCOneLdp xjGJ7t0Gsd1T3Myu0O08hx/XEJ+uoIyrCZ/qZPBONdIjx1H+1jXl8xHrIGoiPkBQC5OB98I7E6A/ LWVL2y2Ccgdo9aqoG3dgdrMwIwoPQnrCE2KMEhwOmNIN3ywksg9oLWb0LVoq6ovcXgPyVDjdt74G cffHPHr4vjKGu9uxm/nfblsfIHpEfjuY3HuB12HRhNQjB0B65EheU9divTQSc36rQIU4VTbyNLLN APkveIf1TW2NZcxexzkuTrmOvNeJpX+9XhA3bGm6IDTg40/jNOJU4zVQZcnOdXJaWtXXIIz1xPa6 wrdJUXcunaWKnPWNdwgY1LGNb7RgS9wlNtmOw6xQlms0XiKdtO89Wma70NaGCKFGJLGk6dInGf8A PUAOlgHXSKNn7ZpPM1GypcdQYo/TN6azTW3/ADfsyL+f9RJST30hABiBRX9IUZ9I7MwT2x6T32tO k5ZPOkWQlY0dT3i7lArZgxyRpFXkUO/dGq5GroymTJgwRyZJSREa1NKYddMTUeLcvx1BOSNJlUOu TND4S0GthEuvEKGHKpF1DowzkHExHLr9ux19DN6SMTHeZqA5DlfXMb871aJ5lpIrzrDo2BAAawgE bPbZHYFo2XOKDZaqDuZs+OgSpVHYTK+Dq38tc9tZr1GBM9nJdnTp06IAo+SICL8/lF2/XOTiXPKW V7lUsAygtgxb7lOPc+z/AJcy6Xh/GRb8/wCoPWFGhhvaU9IM1kSallMZs7giXsSJplhCWhBWTF5C vH2KOw95T5tYKGOWo0i3l0kZEaltRLVaM652tiTSxcSXK45BJlP8SnEs6zqhq36MvowJj7w1Y2kg 9ZmKmbM0virfbq1krp8StXqNbAwU4My3lBYbWzrH9/NAU4iDl3ByfjOwppyLlcoXBMGT2zlGWhAs Gb5DYviOfp2v+4z+k0kR/T64rY/GPJC25RnTw6CdBciwVUs50AEC1YHsJefcr8hj/ToDKWE37sHX qO2R3kbbfcJfvqYHc2Os1qvjHpBj5eU+pp1pDCejjDMLWNIYCZuTNsIClAEIEAhAJ0EsBEqMRfza hiMjKXLGTiGj1EyLQQ8rj57RXbxyD0mitrzKdnHUmaq3M0CmmolhHNClKwOkEtVaa9569uBpOs5K VtBHmXbUIB6xTY59ZZ5DM0psDHqoRO9pCU5JlsVmUq2KHMvU8lG0MTLXqWwW0geeCGK2HxjiJvEW puKg9e0ciZLbl2dFXmb8Ve0p1br8oyutWpCzdBM5yrWvtLt9nyj4qy57EstoUdymyHGIPafXvDOd ILdNXQzGwQaQogK3yIYNMRuZKezzM7MADj0la5cmHYwLmMhbFOxJVsrl9hAOJRMhZC9q4KxNJdZY CxZRMQWXKZXK6xhYmTA2VgDMomArbAdISugDUQQb8UPW2TJ5X0NOKqSkv8BLVsUr2mlqYlRnrFHi 6cjcY3Ggme25Vg+TX7i4PSKL6ACY5c6RVymwTHxt7EsiW4ttTB0lbB3Ylq1tYHK5zNC2IRqaGm04 llXMV03y5XcJldTZJcDT3dALaJIOCYIAwhMG0lmRacTYJoFxDEQbiOhGV2WBdBLLCDZYyZNlGysy pyMhYzdMyjzE0MpV6iirP4pa44LOBKp0bEYeOTdYIuT5GrG/E0nAr2VCW4GgYQCFJmd7lAdrYUxH zL8MY35NgCGZvm2Zc6y2FEsj0PGsBgd53YgTZjvI+5rNEEJHVW+W6986dIM0h13Q9XXXrOnRGBh9 JFsTp0UAMwbTp0IjBN8JA7p06MibPD0lHm7dpnTo9dwMSN+eNvF7dwnTp19zRj2NHV+USTZxOnSH UoUOdv2HEzfI37jmdOmjFsSyFQ7pH8WZ06WIdT//2Q== ------------A48356845382213-- From gmazyj@o2.pl Sat Feb 5 06:51:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23641; Sat, 5 Feb 2005 06:51:57 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxOml-0005oL-VM; Sat, 05 Feb 2005 07:11:37 -0500 Received: from [218.147.94.78] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CxOTf-0005vl-RU; Sat, 05 Feb 2005 06:51:52 -0500 Received: from symphony-32.iinet.net.au ([194.246.220.186]:1906 "HELO mail.ies.edu") by ies.edu with SMTP id ; Sat, 05 Feb 2005 07:43:35 -0400 Date: Sat, 05 Feb 2005 14:42:35 +0300 Message-Id: <0.7.67.2081924.0083fc70@ies.edu> From: "Evelyn Raines" To: Subject: Incredible and true. X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 7.9 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 111b48b3edee1f6fe0a892c95423c18d This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit meme only . septacro resorcinol cattail. sanctify throttle scuffle dentistry glenn simplicity cumberland egipt. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit byron pinochle
You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web
Guaranteed.
 
 
 
 
 
 
.
.
.
http://www.193.cakjsldkjw.com You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web Guaranteed.
.  
   
NOMORE ------------A85031401794097-- ------------A48356845382213 Content-Type: image/jpeg; name="schoolmarm.JPG" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7RkSUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQQNAAAAAAAEAAAAeDhCSU0D8wAAAAAACAAAAAAAAAAAOEJJTQQKAAAAAAAB AAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgABAGxmZgAGAAAAAAABAC9m ZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4 AAAAAABwAAD/////////////////////////////A+gAAAAA//////////////////////////// /wPoAAAAAP////////////////////////////8D6AAAAAD///////////////////////////// A+gAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBBQAAAAAAAQAAAADOEJJTQQMAAAA ABeBAAAAAQAAAGsAAABwAAABRAAAjcAAABdlABgAAf/Y/+AAEEpGSUYAAQIBAEgASAAA//4AJkZp bGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDUuMP/uAA5BZG9iZQBkgAAAAAH/2wCEAAwI CAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAwMDAwMDP/AABEIAHAAawMBIgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAA AAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggF AwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNU ZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH 1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNT FWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaW prbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/AOb+q+bXR1E5Fn0q63emfBziG7v+2967Kn6x 7omzcPBwD/8Aq9y4fpvRPrJYWX09JyLq7GyCAIc13DgX/mq9k4PUcGg5HUOn5uDS3nIdWTW08e99 Rdtb/ZWPzfJe5MzF7V6Dxfg9B7+KQHuH1bfrImH/AE4ve4vVcOxw9Vg2zqWEiP7Di5qpdbyOnZe4 NOyBNVroDmO5923/AAH+kqXG4me1zi2rJbaSNAHNB/6R3KxiW23dRoxy7ffa8NpxwQ4ucdB6np7n Mqb+fYqUOSmJgA0QbHp4Z/8AoqJRxCMsnFpR/S9P0dOyx+DZVT1bFtwshzfUrxyW2PeP9LurPoNp rc7b/Pet6v8AO11KzWzMvc23BxXgNmX2AHQ8t2j+T/KXe5+FiZ1TaMmltzqNr2AwS2wD27D+b7fa 7/g1Zow6KWBjWiBpHbTyW0eWAOhrq4wyAjUX+T5zfbU0H1WOpdwQBuH9l309un83YyxiyW5ruo3v x+k42Rm21/ztpaK6m7ve43ZD37Wt/d+gvUeqdA6P1OiyvMx2+4EG2ua7Bpy22ra5ctjjHxumY+Li DZj07msZoeA39JYYbvvsnfdb+fY+xTY8ZJoy6NPneZjhxiUYcUydATUXb+rRoxunU02uByPz2tAk OOuw1tLneptb/g/VZZs9Wv2LbbZWY5E8AtcD/wBJq4TJbVlUuoyK221OEFp+/wBrh7q3/uWs99b/ AHrj87r3VOjZd3S3Te0Niq1z3MD2PH6Ky6lvsf7f51n+lYnSiY7epHI80OZPCRwTFdPTK/3Xteu9 dvzPrQ3o/Sm/abG47Xv9Mja1xc/1ftFrT6dddFfo7n/9a/nf0a2XdNtswBhdRyKbLX/zW0E7CNR6 VlrhY/Zt/d/7+uS+oltdeBmZxm3Jyb66L3n2uDGD1GMrezc9u71GbPb9P/i2LpTY2pz6qLDlvLQx 1dP87tYA1jsy207Gen7vTyLvSos/62qM8lyPCD/W1/6MXYyQ9uQx2KgaE6+b+85P1a6l1zo/1rr6 N1kh9HUa3Nxr63A45sp/SN9GGs9OxzfVZfRtZdv9D/B+kvQl5d9YM60VC82udlYr22VV1++uuxjv Wba7Kur3W21fQZXTVjM9O39HbkV+ou6/5zdP/lf8n/tTj/Af+TUkcoOCWg9NaXprLuqeKYyY81i5 mUb4P3I/uv8A/9De/wCeOJU0iwtrd23e2fvWtf1/AuxTTt3ttZtNbgCCHN+i5iWNViPxhU+qt1e3 Z6ZY3ZtHt2ent2bNv5n0FzvXvqY641s6HlO6dTe/0snFaT6e1/8A3Gd7rcVu79Hbi1v+y2sf/gv8 JBLDMRPqvvp0VD4hiyziDj4AT6TxX6j8vE+fYf1bv6hkXHB2OxW3WMqe4yIa52xum7d7P+gu0+rf TumfVgHJL25vVnDbXtbFdU99D/6ms/0df84pV/4s+pdMosyundQ/WQ3THsYPRsaP8Fbth39v/BrO 6KbupXZdefacK3DJruw8Umu4A6eu3Js9X6Nn836P+F/nrPTu/SDJm4ImR2j/AC+Vs48XHKh17F63 oHX2ZPXz0ptu/Ipotycx2hhwdTTXj/8AGfpn23/6L06av9Iup9RxOmg8dD/0f/Ml5l0/6rP+rXUq frH0a9+f0tofVmY5AGQypw/SuY0e270Pbc+v9Hf7P8Iu6o6jTfUy6ixt1No3V2sMtcP3mpvvRlRE uIUr2TqCKo19jeybYoLg0vnsAD5S7f7dv9ZecYeZ6OVd06/R7HTWeN2nH9ayrZaxdrn2h9BAkuDQ AR2kfu/NeYfWTLrxusHHHuu1c8Aw+vX9F6n/AAv5+z6f/QShklxgAX3YeY5EZ8dEiMh8t/1npRcP 3hJ4KwvrB0bO6n1XBpwMZ+TlPoeS1o4rFnsfbY7bXXXvNnvsfsS6X1TKzCW2VANYQX5TnbGiPd7m Q91lzv3af/A13XSep2Yhb030g3OsJsLCWg21mfS9C4PfX69Nbf5u/wDnv5yu2pSHPilL2zKpnp/6 Ew8l8P5vlckc5xgwxgmz+l/W4Pn9Dzv1d+qf1l6U+yrOwxbh5YDnMrvbNdzAfRsvqD6/Xo92y6ut 1v8Ag/5a6Gjo/UA1lGRbVS2mHV00t9QtE+x/pVCjHxd8fT3/AOl/PWq3KqNbsjd7GA7g4EWBzdbK rGP/AMIud6vk5d1hroubXFm6wEB9b3FpFm9sj6P81XZv/m6VJ90xk2RbZPMZckjIkAy10/Yrr3Re iZlddL8q1r2autrLLHl0+43MrodS3c7b6my5UP2fd+zv6W31vsX7K+j/AIP7b/Sf53+b+xf4P/wV DOVkVj9PRLRqbMd28D+V6T9l7f8AwZWYt+h9nyJ2zHoW/wDG7P5n+lbfd9m/pP8AwKk+7YthAUdw ye5lMOAzJAPFE38v6P8A0ZP/0danqDmiNCBpr/enyerPrxrHuLvYJaWuAh0/oz7p/wAIuePVMRrd z72NHxk/JrVlda6pm2dNdk4rAMaq1rC9xklzw7ZYR/Jb+j27/wDCJ05xqr1loHC5PBzE8kRwyjCJ EpSI+UB9Op+sjMumssHvuAdHx8F5z1LG+sdv1ny87o2DfkenZBvprc+ovaNl9DrfbW//AEV9e76f 8tX/APF1ZldWy7HZlldGDh7dzN203XPl1NE2R7Gem++/03+p/MV/zdli9NsaWhsiwVgbW+ju2tj/ AIOn83/rfpqCGI7zo2Kro9HPNwmsZrrxeL590/r+RTeWupdh522cnpuW01lzP+Lt2erV9PbfV/NM /keoh9QpzK6MjrP1RyDUR+lzukua14Bj9LazHcDV79v87Sz9L/N/8Eu5y+nYHVahRmRl11kOYXjb dS/8yzHyWCm7Hu03fR3rzLq2XlfV/rF3Tcl5bfiEOxsysECyp4D6n2Mhuzez9Fksr/V/U9Vmz01V ycrLEeLF6o3rA/y+Vu4OYhzFwyEY8hFcf6M/739Z7X6vdP8ArDl4teX9Zs04nrCaunYrW49u0+6c rIrH2yuxzfpY+PdT6X+G/wAJWj/WT6ndN6j0puFiVNxG4xddj144bWXWx9HdG3ff9B9tqwvqozrl 1WNk9ReMbp7699VjZF9zQR6FNlji70Kn1fpN9Hp3ekz+cXTdQ6uyuWMMuPEcfBSmQo2OHy3Y/YlH IBGXuV1/QfMsvLFYGPTV6QrlnowQWEEtcxzXfpPW3fzu/wB6vfVXFzMnq+Pe57mUYjhda5k7i1h3 bGBvus9/87/oqf0iu9dwcbIy67nPbX1G4b/Rb9O2sez1nt/wbvzG3f8Aaj/rdt6hj4nW8DIZd0jF tzg9wF+Ozlhj2XV3HdVj/Q2WVW/o7P5z6f6RQYOXHFdaA8Vn5pOpzfxCEeX4MYAyTiYy7Q/edrre dkNzG213B1VjA2XaQRu9NznV+17f+Er/AHP5uveq+M+3LgVMLrnO91fcP/Obr7W+12/1Hez0/wBI n6pjdaNDr8jpGRjT9O1rqHgfn7ntoycr02Od777fQ/4+xYORm9RxdHUsruLeK3ObLD7am27m5Fd1 n5rXUV0f6Na0Jfi4ETdA6Vpfg9UwtxyfRc23ImTkDVrNOMXRvqf+G3f+g3+mQ/Tfs3e+N3i76W70 9/P87u/PWFT1DquPe+rq1d2NbXG3Hsd9IOG71D7K/Z+5/wClKl0fp0/ZfS+0tn9mfbd2x07PtH2n 1o/0ez9H/pU8yFA31puS5bhxRkT/ADnyy/qxjxmX/Nf/0tHpX1M6NnAP6pV6+SWhz6/UdVWwuj9H OP6duQ5v+lc//ran1n/F/Xk4P2LFybMHHa8WBrmDIrMTt3WbqshrVztX1jJdscWuIJET5+36S3ML 63ZDdrRkuaGEe15n+z7g7c1VBICvDZtZIZAST+k3/qF0HK6Fi53T+oGi1l9rbqra3B7HDZ6T63st ayytzfT/AMJWujOBjsedlHo+BxrTUY7OdWw01/8AVrEv+tPTX4hflMNT3kVi2jU+8Hc5v0Xtc1u5 3+EQ8G1+wfsrqDb6xG2ix0OAH5uz/q2+lUreISlEy6bKhykskTkPp10sHhP+E9A2nNAGzKfpyzJr bYB8LKfs1mz/AITfYuT+smB0jqbsjP6jSzIfQyvHHpuczc5p+hXYR6jffbt3f8Yr/Ver9ZfiOobU 3FtdobHNdsdP8tu9rf8Ai/8ACfyFzWRdQy3Gw8uwtprIstfqSd5Pq2f8J7fU+h/hLVX52c8cPlP9 4fLxNvkeRkZ8Ujf9WPq9P6X+M7PXvrLUOk4jbccYj8g+pQGu3Ma2v2tZa7ZVZTvqt/R7K7FmdIz8 vrT3U9KxrBe0gW5GQWOrqn89lbf59+3+b9bZR/pfW/m1jfWrPGZebWCKR+jx2+FbR9L+Tvctj/Fj msfc/CrBbmMDrHwDtfUS1jrX/mt9Dds2f8T6f+EVbCTkqUtT8v8AINzPhjg5YGI4ZEGdHWMb/Rt2 q/8AFl0p2X9tzMjJycixwfba614eXD87fV6Xu/NXW0Mx8WpuNQ0MZWAA3mPDc53ue938r3pr7/Th lethEidQ0T9N/wD31n+EWRm5gqaQzQ6k+Mn6TirfFwjdxQJZN3YsuY1p3OKzsTpOA7IGc2prntd+ igQGkf4Rs/4T9z/RrCt6lkvaffDAJJJ08At/BzsbHwK23WMHps4DpMfS32D/AAf/ABf/AG16qOPJ xEkbBbmxiIA6kvJ/4xaDkdY6Zi0mMnMYKKjOhJtDGsf+7/Ob2u/4xdr+w+nf6P8A7SfYP+sf6Nc9 0ml3XPra/rFrCMfplfp47T2seCGb/wDhG02XX2M/wf2jHXYpwlvLp/LVmyZZyx4cH+ajI/XJ6v8A ov8A/9PkepXV5mfdltb6bbTvIgNP8p21nsQqMy9jGua+WHhrtYP7qFc91pLn6kkucT3JMuVZ+Rdj 2htcODpDmHgqDFETib6Otz1Ys0av25jt+l+k678x79jdW7QSADIk/wBb3fmqxR1G+oAMdoDP+oP/ AH1ZLM7FcIePRd5+5v8A33/0WisvqJgWCewOo/H3NRiZw0Gzd5PnsHtxxyG3fuXq8H6259FRDrt4 jb6dnu0/kPd7v+ms/Kfd1RjK8at91tJLi1gLjtdtbu/z9rFmBry2WkEff9y9C/xfnB6f06y6xhGV kEOtsdGjW/zTP5DG/T/rpZOY9yPAaF7lnzZMWCBzYYCc7FRjo8Th9Gz8vrFfSsmt1FbYfHD37z6b GM3fzX6Vr969b6V0bpn1fxPs+BSxllsb3j6Vjm/nWPMv9Krd+97P+uLj/rF1/CxPrj04H2Pprecl 5EbDdP2Vlv7jm/zz9/8ANfaFuM+sDbS5x1LjAHgBoGqCNY5mzWlQ7f1pf35OXzUs3MQjO5GMiZT/ AL1+mH9yMW/mZYqBG6Xky93ieFg5F/qEuc4Na0EuJMAAaucT+61Sysz1TO4arm8rqTuo3fZsUzis d7nj/CuB5/8AC9bvof6T+cQnInQMEIiOh3X6hnZuQBbiFzcakk1siS88erdW7du3f4Jn+CZ/LVTC 6t9aM/KfhYmL6za3taHU1wAbP5r1HPc6up/5z9v5n6X+bW/RRXRj7r4axjS+xzuA1oL3uP8AYaux +rnS2YeE211QqtuJuc0j3B1gbvdZ/wAJtayr/iq02PEZjGI3xDWXTH3P/epyShECdDQ6D95s9D6T T0jptWFX7nCX3Wd32v8Adba4n3e5373+DV9JJX+EcPD0qmjxy4uO/VfFfi//1OEHKHVj35Gb9nqY 63Itcyuito9zi72ta3+U5yt42BmZZH2eh9k8OAhv+e72LZ6dbmdAzKrbsXHdfcxza7X7nPa0fz1L H1Payr1G2/zn85s/R/zP6NVMeWAnwGQBkDpfq9Pq+V2fimnLHIBxSxEED97j9DrdJ/xTdRDhkdTs oJgFuOx79CefVe6na5zf5HsV/I+pXRGk42VU/Ftj2ud7muj85r9o3N/q71p9C+tdWSPSFjsfIaJF DzvreB9P0XH9386n9HZ/olsPzOn9Xxn4l7f0rRvNbTBEafaMaz8x1e7/AK3+f6lH07gqr0I7uBi5 szPCLx5N+CX6Xk+ddT+qed0Vr8rFJysapvqPpmXenBc6yl0/pWMb7tv7n6StLpXVc+5ocwMw6nfR dU2bv6zLMh2R9nd/LprZb/xa1Oo9cyMDEy8C13q2MOyi0CNXw9t7W/4P1KXOfbX/AIPLrXK05T6y e+7krP5o61Aer97/AL16n4ZgnlwmWWjHaMa+137Oj9Hs3WOq3PsJc+x9jy9xP03vLnl/0vpPWVe/ qHTnkYNrrGT/ADNvu1/4N/738lQ/adxGpnsShOy3PeXO84HaVTgMoNyPGO0vU6I5bQxPynskxcrr fX724bXBlbv5wVgtEfneq/32bf5C6TGwKOmwK3C5zNHuOjJHLW/vbP31V+rVgdS+rDqLszIc9paw bnugM94j6Htt/wCL/wAIu66H9V242zJ6hFl7YNdA1rrI+jP+ltZ+99Bn/gq1MEYmPFQHg8X8Vycy ecny2EmEcZqeQd/5foMejdG+10tyOo0BlZ2mugz7gDvDrq3/AJu9rH+k5dGkkphEDYKHFwgSkZV1 KkkkkVP/1Vh2bmAdogBZ/wBaKt3TjewEuxXNtEeE+nb/AOBWOVnBpzK2ht1FtThoRZW9pB/ttarl 2M3IofTaIbYxzHfBwLXf9FcwCcHMRmbHDIE+X6T0WWAy4pw3E4kPH4mW4lpBLXNILHgw4EahzT+8 t8dXybHY11bwzJY/twTr6rfpN/R2V/8AbbFy2FjZTCK3UXb2nb7anuBI0lhrY5dJifUvrvVcdz/s 11FO0kF4NTnxpsbVZss/SRt/Sekt7JPh1F8J/dHE85g5IHNAmonGb9Z4f8GTz+d14ZmdYA0uY+zS 0n81u5rNrI/O3KW5b+H/AIp/rK654Lacarlrr7JP9UMxm3/9Jy6rpf8Aip6fRDup5lmWQQdlTRSz zY8zda/+w+lDJh4yDAEaa8Tvcl8Rhy8JwzTEvUTEY/VX9X0+l84qZZdY2qpjrLXmGMaC5xP7rWt9 zl13Q/8AFx1fPLL+pH9n45glrvde4aH+a+jT7f8ATfpK/wDQL0fpvRek9KZs6fi14+m0uaPe4c/p LnbrbP8Arj1dTocrEayN+DHzHxzLIGOGPtj9+Xqn9nyxc7o3Qel9Ex/QwKQzdHqWu91jyBG6yz/v jf0f7jFopJKcAAUNHHlKUpGUiZSkbJO5UkkkihSSSSSn/9kAOEJJTQQGAAAAAAAHAAEBAQABAQD/ 4gxYSUNDX1BST0ZJTEUAAQEAAAxITGlubwIQAABtbnRyUkdCIFhZWiAHzgACAAkABgAxAABhY3Nw TVNGVAAAAABJRUMgc1JHQgAAAAAAAAAAAAAAAAAA9tYAAQAAAADTLUhQICAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABFjcHJ0AAABUAAAADNkZXNjAAABhAAA AGx3dHB0AAAB8AAAABRia3B0AAACBAAAABRyWFlaAAACGAAAABRnWFlaAAACLAAAABRiWFlaAAAC QAAAABRkbW5kAAACVAAAAHBkbWRkAAACxAAAAIh2dWVkAAADTAAAAIZ2aWV3AAAD1AAAACRsdW1p AAAD+AAAABRtZWFzAAAEDAAAACR0ZWNoAAAEMAAAAAxyVFJDAAAEPAAACAxnVFJDAAAEPAAACAxi VFJDAAAEPAAACAx0ZXh0AAAAAENvcHlyaWdodCAoYykgMTk5OCBIZXdsZXR0LVBhY2thcmQgQ29t cGFueQAAZGVzYwAAAAAAAAASc1JHQiBJRUM2MTk2Ni0yLjEAAAAAAAAAAAAAABJzUkdCIElFQzYx OTY2LTIuMQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA WFlaIAAAAAAAAPNRAAEAAAABFsxYWVogAAAAAAAAAAAAAAAAAAAAAFhZWiAAAAAAAABvogAAOPUA AAOQWFlaIAAAAAAAAGKZAAC3hQAAGNpYWVogAAAAAAAAJKAAAA+EAAC2z2Rlc2MAAAAAAAAAFklF QyBodHRwOi8vd3d3LmllYy5jaAAAAAAAAAAAAAAAFklFQyBodHRwOi8vd3d3LmllYy5jaAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABkZXNjAAAAAAAAAC5JRUMg NjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAC5JRUMg NjE5NjYtMi4xIERlZmF1bHQgUkdCIGNvbG91ciBzcGFjZSAtIHNSR0IAAAAAAAAAAAAAAAAAAAAA AAAAAAAAZGVzYwAAAAAAAAAsUmVmZXJlbmNlIFZpZXdpbmcgQ29uZGl0aW9uIGluIElFQzYxOTY2 LTIuMQAAAAAAAAAAAAAALFJlZmVyZW5jZSBWaWV3aW5nIENvbmRpdGlvbiBpbiBJRUM2MTk2Ni0y LjEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHZpZXcAAAAAABOk/gAUXy4AEM8UAAPtzAAEEwsA A1yeAAAAAVhZWiAAAAAAAEwJVgBQAAAAVx/nbWVhcwAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAA Ao8AAAACc2lnIAAAAABDUlQgY3VydgAAAAAAAAQAAAAABQAKAA8AFAAZAB4AIwAoAC0AMgA3ADsA QABFAEoATwBUAFkAXgBjAGgAbQByAHcAfACBAIYAiwCQAJUAmgCfAKQAqQCuALIAtwC8AMEAxgDL ANAA1QDbAOAA5QDrAPAA9gD7AQEBBwENARMBGQEfASUBKwEyATgBPgFFAUwBUgFZAWABZwFuAXUB fAGDAYsBkgGaAaEBqQGxAbkBwQHJAdEB2QHhAekB8gH6AgMCDAIUAh0CJgIvAjgCQQJLAlQCXQJn AnECegKEAo4CmAKiAqwCtgLBAssC1QLgAusC9QMAAwsDFgMhAy0DOANDA08DWgNmA3IDfgOKA5YD ogOuA7oDxwPTA+AD7AP5BAYEEwQgBC0EOwRIBFUEYwRxBH4EjASaBKgEtgTEBNME4QTwBP4FDQUc BSsFOgVJBVgFZwV3BYYFlgWmBbUFxQXVBeUF9gYGBhYGJwY3BkgGWQZqBnsGjAadBq8GwAbRBuMG 9QcHBxkHKwc9B08HYQd0B4YHmQesB78H0gflB/gICwgfCDIIRghaCG4IggiWCKoIvgjSCOcI+wkQ CSUJOglPCWQJeQmPCaQJugnPCeUJ+woRCicKPQpUCmoKgQqYCq4KxQrcCvMLCwsiCzkLUQtpC4AL mAuwC8gL4Qv5DBIMKgxDDFwMdQyODKcMwAzZDPMNDQ0mDUANWg10DY4NqQ3DDd4N+A4TDi4OSQ5k Dn8Omw62DtIO7g8JDyUPQQ9eD3oPlg+zD88P7BAJECYQQxBhEH4QmxC5ENcQ9RETETERTxFtEYwR qhHJEegSBxImEkUSZBKEEqMSwxLjEwMTIxNDE2MTgxOkE8UT5RQGFCcUSRRqFIsUrRTOFPAVEhU0 FVYVeBWbFb0V4BYDFiYWSRZsFo8WshbWFvoXHRdBF2UXiReuF9IX9xgbGEAYZRiKGK8Y1Rj6GSAZ RRlrGZEZtxndGgQaKhpRGncanhrFGuwbFBs7G2MbihuyG9ocAhwqHFIcexyjHMwc9R0eHUcdcB2Z HcMd7B4WHkAeah6UHr4e6R8THz4faR+UH78f6iAVIEEgbCCYIMQg8CEcIUghdSGhIc4h+yInIlUi giKvIt0jCiM4I2YjlCPCI/AkHyRNJHwkqyTaJQklOCVoJZclxyX3JicmVyaHJrcm6CcYJ0kneier J9woDSg/KHEooijUKQYpOClrKZ0p0CoCKjUqaCqbKs8rAis2K2krnSvRLAUsOSxuLKIs1y0MLUEt di2rLeEuFi5MLoIuty7uLyQvWi+RL8cv/jA1MGwwpDDbMRIxSjGCMbox8jIqMmMymzLUMw0zRjN/ M7gz8TQrNGU0njTYNRM1TTWHNcI1/TY3NnI2rjbpNyQ3YDecN9c4FDhQOIw4yDkFOUI5fzm8Ofk6 Njp0OrI67zstO2s7qjvoPCc8ZTykPOM9Ij1hPaE94D4gPmA+oD7gPyE/YT+iP+JAI0BkQKZA50Ep QWpBrEHuQjBCckK1QvdDOkN9Q8BEA0RHRIpEzkUSRVVFmkXeRiJGZ0arRvBHNUd7R8BIBUhLSJFI 10kdSWNJqUnwSjdKfUrESwxLU0uaS+JMKkxyTLpNAk1KTZNN3E4lTm5Ot08AT0lPk0/dUCdQcVC7 UQZRUFGbUeZSMVJ8UsdTE1NfU6pT9lRCVI9U21UoVXVVwlYPVlxWqVb3V0RXklfgWC9YfVjLWRpZ aVm4WgdaVlqmWvVbRVuVW+VcNVyGXNZdJ114XcleGl5sXr1fD19hX7NgBWBXYKpg/GFPYaJh9WJJ Ypxi8GNDY5dj62RAZJRk6WU9ZZJl52Y9ZpJm6Gc9Z5Nn6Wg/aJZo7GlDaZpp8WpIap9q92tPa6dr /2xXbK9tCG1gbbluEm5rbsRvHm94b9FwK3CGcOBxOnGVcfByS3KmcwFzXXO4dBR0cHTMdSh1hXXh dj52m3b4d1Z3s3gReG54zHkqeYl553pGeqV7BHtje8J8IXyBfOF9QX2hfgF+Yn7CfyN/hH/lgEeA qIEKgWuBzYIwgpKC9INXg7qEHYSAhOOFR4Wrhg6GcobXhzuHn4gEiGmIzokziZmJ/opkisqLMIuW i/yMY4zKjTGNmI3/jmaOzo82j56QBpBukNaRP5GokhGSepLjk02TtpQglIqU9JVflcmWNJaflwqX dZfgmEyYuJkkmZCZ/JpomtWbQpuvnByciZz3nWSd0p5Anq6fHZ+Ln/qgaaDYoUehtqImopajBqN2 o+akVqTHpTilqaYapoum/adup+CoUqjEqTepqaocqo+rAqt1q+msXKzQrUStuK4trqGvFq+LsACw dbDqsWCx1rJLssKzOLOutCW0nLUTtYq2AbZ5tvC3aLfguFm40blKucK6O7q1uy67p7whvJu9Fb2P vgq+hL7/v3q/9cBwwOzBZ8Hjwl/C28NYw9TEUcTOxUvFyMZGxsPHQce/yD3IvMk6ybnKOMq3yzbL tsw1zLXNNc21zjbOts83z7jQOdC60TzRvtI/0sHTRNPG1EnUy9VO1dHWVdbY11zX4Nhk2OjZbNnx 2nba+9uA3AXcit0Q3ZbeHN6i3ynfr+A24L3hROHM4lPi2+Nj4+vkc+T85YTmDeaW5x/nqegy6Lzp RunQ6lvq5etw6/vshu0R7ZzuKO6070DvzPBY8OXxcvH/8ozzGfOn9DT0wvVQ9d72bfb794r4Gfio +Tj5x/pX+uf7d/wH/Jj9Kf26/kv+3P9t/////gAmRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rv c2hvcKggNS4w/+4AIUFkb2JlAGSAAAAAAQMAEAMCAwYAAAAAAAAAAAAAAAD/2wCEAAwICAgJCAwJ CQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwB DQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDP/CABEIAMgAvwMBIgACEQEDEQH/xADYAAABBQEBAQAAAAAAAAAAAAAGAAMEBQcCAQgB AAIDAQEAAAAAAAAAAAAAAAMEAAIFAQYQAAICAgICAgEDBAMBAAAAAAIDAQQABREGEhMhBxQQICIw MRUWQTJCIxEAAgECAwQFBgoIBgIDAQAAAQIDABEhEgQxQSITUTJCUmJhcXKCIwUQgZGSorIzU2MU IKGxwcLSQ4Mw8HOTo7PTFdHyJAYSAAEDAgQDBgMGBwEAAAAAAAEAEQIhEhAxQQNRYSIgcYEyQlKh chMwkWKCktLwseGisiNDg//aAAwDAQECEQMRAAAACD/OCbH9ObvBkzKGXyRWQMLNe/P0gQequ4cS Zen1Rq8xa18wLjRA24uMg9qXYevohw5WdkBx7BHI5djmxOrfNFme2QX88c0POwWe9oJgi2+r5ZqT mf5KUgqiad8kDun64mP614iICDVmGresNTjPi1HRs4TrVAUJeBWzDNtJhMmzSoLgjnO15BEKCDuo lEJS+zXQOZU48meecFaW8COLFCrn2sdA+nlVdrHzcs84zQTo8G4+6xxXMQTR2XbzMijtZQNCHnG0 BoNeBb5yaIvQDeuFyDPegiwMB/NtYFrdD7+FJW0Sy3zYmJUvarYOthc107whYL9txLVzteh+Msa2 GMg29RgUWoi18ne1LwwszvLcBzNh/Qs3nk5p/ENHQz8b0MMT9JEPw25bybakuaN3JsrUT5IYn8pr 27gVCKiHNyQYI2IJ60TGo2YnWiuN8d7NzU+q6FyTVoF0rpM19I6E8wdv7FhOPKLXDojdKexe8zC0 L7MtcfLxU5ru1ltnklLM0tAdpYJMxFissED4wi2vBmJEQc6T1Bl6dKf5xo+iqf8AXEdnz6bZqqGu IFR1Wxj1HqGUwjXA4zqxgsB6KDSsJtE5Frtqt7LuFVwAPsd0IarOOjhqdWZBnNRdvTYXMTqsKrxW 9RwscQoVbXpfBCdbKImfSbS+d4rninpGpVe01gXXNfIE/K7iyaanpBSlQyaIAk+Z2x9Pfz28Fe8q mo3QuUMWw5Jj771O25Jw44ikkcfzd6vUvUQ+ndMb84BlmltXFn1Cfu8JmFlbDaO9fccys1ypgX1Q QnkWMXv4ke37da8rPJ/ZXdJJK3UkpPm/oiucb1AsSRh9vzWpWWWE7uMbg8iursxxvtjP9jM9hoTE ttjzsnlQlqjfl6oyd9cxEkodJKRJKTIp9RZeV9N6CHoe9n82NLO1MCyqFR90Zsyvmh3+1fmFTZyc Hr7GRGkpHykkpxJKRJKRJKTH52Trzfo9foc+VKkV0BrexNq4xhLP70SfMK0EPqpfKqsH6qXyqpPq pfKqk+ql8qqT6qXyqpPqpfKqk+ql8qqT/9oACAECAAEFAL6SIDrtiICM1yzOPX8gUjAeRR4kOeQx jYnnyicUUSLBA8KtxJU2QVVHhnxzPGKnJnGAONifIwGJplwUJdkQcmRfMFJTJfMli28F5xOGHlhV YKArLHCSPExjh+JmIlwtSwHSWeJcKCIl9mZmmx0HExJRGTxnxjpkhWqZwwExfUlcpacjM54AMpV4 zE5zzE8eItKYVMjkF+jCiB9i5iCIoAB4+Mg+Mk54hnxB8ZBxOIHyz15cIwhczMhHGf2yTiME/Ip/ jgf2XEFBL4xLvAQcM4yRkIWHNaSKCLDLnBLieCI8VPBFEZK5wokc9vyfBjDoGSZznjjoLisj1B+g /wAo/jhDGWBAMNzZlTZnFiE5ChiIAYn9G7BY5TskxQnBQZ8Qc+U+scgIjKozz+xw8TqWRDCmRlcC ROGPIUmWBWGM/t+2z4c0fL8k/DhH43sHx/of/9oACAEDAAEFAPZ7RJIYSD5vcBn94kImXwtWKtoZ kRM5EAtaT8SsjPkNlq5HYROBdROXXw0omYj5zZckYecZqzJuW/5NXM820yVItjU5AlyEDPMrgRkM 8Jy5QlkQkwzUWZrg24bC9hli3nArdHGvsT5r5KQ8HB6InJgYn2c4jWKOL+tAEQE+ETxkTznJZqE/ yc3iVtJZVrK7AuoTMiv+VKzHq2V0nyJTGLVB5KfBZa+qs/Fc4YzzA5XGJYfv5lMBjHfykp54mcFh DOxYH4JJnJXMZXRBQVSJyrTGIUuZfsJ8h45kV/EhACMeU2WyU2olIx4lFRYihlFZYmqS5tW4GL1o jIAwR4g1QUDC1rmecvDLUracYi+Q4i/BZYf5JqgwGuplE+HjEFMQBxjWeZZEc5YkEH7J4Tanmj5P GFQGeuWDsSiuDNhYaYEyQ/TnjN7XEnwRomrHtiksQR4jnAxnZw9hV6q0x+v/ADtEwaprwQqE0I1j ShL9nWTlndOZklJT+wfPLPh6g8fIvzfWz38fv//aAAgBAQABBQD2Rx19v4OrHaFMhbrni4rsxlUg VtKK2DXIDWiuRy5IiutcrlDE+MEt54+OJ6ySrN5CvGPHOM7VslURXuRGVNDY1NnsJ0tvoPYy2acj mJRs5FK9pxidpOI2Qljd22RPY/zrdDrPpQW3mzS6/atYfWSUFlT6ebXb20zq+o7m7GpqV9TjOy1a +I31RmWN1VQvuu6sbvcdf69U1CzugzNtr9Ztq2sqO6j3PmOBsryrsq8LUdVuShgShrRxtksoeRv0 ZROoua+q5lemsBgRjHVK1iNn1TR6vZWjkc9sxlmFPVfuv0dt/aFsr9Drezaj4bBnLhO3bTL95WYC dftju9C1/wBb6gK4fXnVhFv1h1Ikdn0Ox6xYTurMTO6Eh6prLu52D7SkYiRbHOeWeXA9ssmt5Phq /LInO4UosauuExPRLYK2SbjPa1rmDYPxrbv/AOA9MuyXUg34QSt8uXTt0cfYFivb1VXT2rGavpjm sRbo6StGzWgOoXi2GoIpmBIYgzgQ7eXmrU3haMnzMlzmzCD11KpZtHV6x3CjY5ds69bQ7IxqavWq LdaTS3C1GoXrtojrCmpudLtjFrb2dY7f7+Nlmj3y6+TdaYndQqd7vLt5n1jsxd1yG4TPKLDjGN6/ zEpZWfWujYXBTzR1a9suhrNXpqpWjnCs+IXNsqvFjbWrAkczCj4bUOMhkTm61dLb0dV0KhKG9F0p VuxaC5o3ddTr00G6zR9gXV1Vno+zTdW5UO5x7p52gkwNjsYnYzaYJag9hZCrZt6jKliXKS5Fkblh fldkbQFrfVMO2SpTc9qk2+MG5HEX5nNTfJdhlgYDvIqfrdHuy1rVWwOEXqm2VeDbdVsUvsfSyNXu usvuZ1q/tl906bVrVtbq4Wt9rjD3Fg1fX9+62zt9qKLJbD3RM8hMj4KoJrqbaNzBd8+/IdM4G1IN jG0Judmr27VCl9UdtYsOs9v61CNlUuhR3ibKtv0F9rbaPVaPrdNdiG40F+XZqbtVbYZNKvTNk6Go rWUdywLKvEpyq38mAUnXwwzcwF+TYbExDJmbu4SlAb9ft65tLW32FWsmmmVuPJG4MbjqOu2whdJN ixtrVZNDtJ2C163161i3Ajtjr302NRZp2GULQRo+0V2RZmo7LT4rlG0qFk9jiJo7B9qdSBtJuxdX xu8stLU68XL9UQX1TSZW1U7NC5FlV5eN0YGJjPtjVCN/XovbK5W63T1dWNrEw+0xhX7tPVVq/Yx2 b9dpm31j9W6Zj4+uerCOx6YNFl7XN9uv+vJ2FAgZrj6w9jutafSL2KFdQ0Apt9VWxF/6+7DSz6xI 16RjDAWq1bpHWpnPTt1Ru1TeMP8ADaTZ2uw0p1s7eohkbyjMI6Oe4yn9c6dR1K1amiWc5PjlmAJa NUiTGIgO2wH+Y1euKl9frvLjEdjjmL2tsD+MloyFhRf7EhdhWzrNH1KmdlsU01V9hDmKJm12HcbI ElhsZHRdbUWtcCMY58kU3YHDvrx+w8iQHgk/+tqlO+7n6w9cbJgMTtTxO0A8pbdtfJ7QpdUW6XY4 ereERs9lUzZhbvTcP0I096jVDbWTeTZKWdM2i9gpYyK7FiSlzoEbVicOwycreX5CHSK+w7r1o6Dq RhmdhpLp3VWmrxOwXOKtll/ZGa03ZgqvYXVyrdpSUOdqnJ2JDYrRadzbt+VfXaTYbQumdOToFWGl GGYKG1Y5xpyeW7iaSKm6STC31YR9tjbXKVRNKpl2424TSgFj/IVFMTLjk4OME+MRakCm/AiF8+R6 /siaWmsxtupa5aaz3+uDIVRbs4xslNh666mi28dyqwZ1Ws2lmx0Hr9ihT/RzoYZDzMWZryltexJK nIznjIKclkZ03R/5LYkhAB3gU03a66qvTC0JxbtRjm8y2wtKnXGX3VER4HTWY9b0FanUiIiP0+M4 jytRMQC+IC89UDcJsDc4xRrZH4/lnV2TSWGyNo913objZ6fsROqK2PMFb5l9tYRc2LNi+hSkpWjw GgltzbISCFfr85/5nllgojNR1m7dZW6pSiHdJS1V7qlurNaz+OxPYkrMyv7ZP+vaoYt6JIZ/ktlr 5/2s/Fl69sz1+kdC6zFIjXrHYO12uRQX+0fmWVne7pfWqGqQn0MC1ra1kbyrWrYpyLodv6/Xs1KC U18TYGM/LGIfYEgs+JZYo+tvWtKFdb7EOnXauxsX6/XV9ej9vxgRMlQt7HUto9rtRGt2FO8pG4lU vlLk7CC1d7sm7l9UWlBRbOY/NLkrkzAt5KpYXFuXzCdP1yzsCq1a9RP7qWgpRCalauO9rS6hXteQ VLz6zq20C6nX7yalns14CC6fnZ5yJ4znOc8pjNXrb+xt6TqSqmRERH76x8wBci/goZE1biHTlOya WWpBpb3cGNqrdc90TnOc5S196+7SfWJlNHXUdcj+jUZyKi+CHkez1vVsK8zgF8WLNpZMU6GpV64R JNLWdF7Jsc1P1frK+U6NOin+mnUbevKq7hiAmI7ZSN9WvT2cZr+ub28yh9fPBJ/VZ241/wBXdbqx Q0+q1o/1v//aAAgBAgIGPwCMYnVyuPfVES26+m1SjI5BwmZMQnAXUs1cJARKqaDVAAuyYxITCWek gntB7kSRUo4PxwJKAPlRYluGqya4JyPig4ZlVMGAHNF9MG0wAQBWTpwGI4KiB5qmqvraS6cnPVVB V0virNr9QQjImUT7jcm7DQqnkFbMBldBzFAEO3FVRsQmU+uBPJFwi5zxdGoBGmGT4MmCMMSTkqI9 NOKBesjVR15YgDiqpzqmVFbzVaKQLFwiTQQqvqSDA+WOrYvxo6ELrhnLlHDvxy+5PIog0DK00Aoq HC2AeRyC6i85VnLnw/LiCExwfM8F5iBoyaYuHPNCwZ4Pri0QZfBPGhBqFUVwJNVkqJ2p2pbZPmH+ KpknJB5ImIWTd6eXUfh2jbd4qFubo3O7aL/pd+LL+xUb7D//2gAIAQMCBj8AqMs3VA3cULZU1BUT 4JzJwqFXbm4IAptsgJgFbMH6ntReDg6Or7LBN2j8qa+Mx8qJMf0p7m7wunIJsCCS0WouksoRFbSA T3InIgUVR+1Xmp2pCX5ZdCaJMn5K6Pq0TABXVz4KmuF8R1FG6JW4bLpGVHVxDdyd2CntmRMZxIIl X5UyMBVx9yromBaQDfwFaRbOOnuH4VoWVkVduRd9CFLdAjCUfYLRKPy+5CQ1wpFUqV9SfSE0ShKB Ktm0ZxPT/RGVwrm3q5rpyTbjCYGfuCO3EtCJ01Vuiz8FKZo0SW56Loi7aoCItZFsBnzUQATCRAfk skQSKItTDgy2z69y390kTgZTjIxycL/XJ+9AO8pGqDxaG15e9TADMfNiZFeKjB3G2LfFAyFCrm0U Yto57ynGacHIvVAbQv3JdIkMo/MjtRyHmPulix0qjuEdWQ+dOVIUcBwm0QDnxVfgpDbLSlRA1kx6 v5IybMuqhOyJJoM0/p0wbjRThMgEGj8FdEgqoyReLRHqC6QwRDsdOCMtzPQD1IfTOZYRCAmQ+tvY +pIMJD4oGJeKEgGcOogDMVx24QIBbqr5V0h5HzT17N3tzQHFCEQR+JkI7hqCWfgjduCUh6YdckY7 I+lHj5tz7/SiZEknMnPs9VvgpX+VqoWMz0uRayxtG8v/AKLrut5+X7D/2gAIAQEBBj8AqCJGKkrn ax3txVx5ZB4gP2rXFGU8qH+erLLa+5xasylcBj5qafS2jlTFkXBXHor26zllCd4kW6KMtiFbCM+H tMfSaiXYADeTQha6hTYSbrVmtmF7rIuJ/VRjALh+synC232idlsKaQYd5jYGw8VIqAvmxVzsJHRW It8MCscsszMFIOOVQMPnPQcuVIOBGy9FZ4mYsuDFWsfo0IVjTiu0TOoDYdknw1PotQ4M8B5kfSY2 Nj/tv8GIpBfCwAvhsFWuaFzQsbeWiplbLa1r0MpxJuvTev8A2eldjqpM0yaaQ2hzMb8u3Z/Dp9PN zIJUNmhHDl8lAyMxB3k3/bV1F2tj/kUeIpbcDb5qmhGjnmbrKC1z1VXDrNS6j35qG00RxWA8c3kH J4I4PTkorpw8sZUK0crZrlTdXRlHs29Ck/Mah4g+AZ480YPZjaWLtt2asup07HoJMZ82WQUXmmjR ezy2Dsx8CitBpfd8b5kUxxRqbuzSN2v9vNSvrMur17YSSkAhWt9lp17NSRwpzuWQHVDYjfb0vDX5 bWaddQNoN7Mt+qyTLxJWm1XM5mgmLQ83AnIbZ4p8vDzYu/V74bb1jhQSR8pGy4BFqAWRDfowr2bX HnvXE2Hx0bMaWRmLBdw237KLUD2KgoOE7R5KSdkHMHBm3kdlT6NC42dmsABWWeJJAdzKD+0VD710 qMswzMsBIaINwjnrzMzo638dRqDgFFhjbiGa/F/FVqaKVQ8bizoQDcV+VnDywsM+nkBBzJ4r9pOr Qi0yMZXOJcBQB6tNr5nRnjR8t24hsV2ZRdkzK3LWhIA/PicOCgNrDMq8OGfrVecflzGCsyhgSyDt cA6+b16/Lx82WdgHMMYBy7/aZeqnjepZtXqBeZSI9PAAygj76Xqsy/hVLrVb28WimVm3iSKN0zfQ z0i6pOdPa8jXIGbtKvhoD8mpJwxLH99FV0rRyEYSLI4IPk4stezneTSP9mz2NvA9XeNHtt2isNMA T5cKjln4NPAQ2VRZV8R8TVHpI9otmA3DsD0qDnsG4Hlt8JNQkqVUo1vLY0jjYVFviHwdFNOgzSaV uYLbbdWT6Jq+7dWphkIVZYcwJ/DPQfA7Uy6aN9UwYxqVHCL7mkYiNHpV1WozRqLrHp75r+PUuOHL +HF/crle7gNPgTJFGBmIIweaRvtcz0VkBawOY3IQN0oBxcXbzV//AEGgY4xaaWZAeh4pFb/rq2YW JttpLkZbi5BrBripSbEoAyefNlr2aFgLZjbDGlfVuYkO5cSR0WoabRgGbcBjl8cv8lPq9VIFjXik kY3B/wDt2e/X/sHBVtVLI4U9lFbkwR+pDHHQAXNf4rfHV1a/Su0froE4+al1EQa0ZPFtQg2DZKMD EZ0xXHaN/wA2rjAD4NXc2UQSXvh2WoQ6SF9RKR9nEpdvmoC1Ra+D3VOzQsGClVOYdqN482bI68FQ to9PNp5ApvpHVo5EcW4JI5FTKsXVSX+rWedk0ijcWzso7Ssq5cub/VpSrPrHQEKWJKLc45V+z+fV tZHDBZr8Mkhc2v2YssSbfHWp0SuzaH3jotRCVY4jh5mEqjq8tXyS8vmfeUnNnJkI4pY0yg+ipPDX M93a32im4jnXhPrx5mX5lcj3wraGW2Be7IwHagljDJL6H2lDT6YMumU3ZmwaRh1eHsIvWpdPqgMo 6kowPovV4Wyow2x7SPSxpg2aR0GcxRAuxUeAfXegrLydMl+XCN1/6kp/qSfU/p0NPcZtNIylb42Y 51rA1ib0AihjbeQB5mJp1yAERlCLYKCRm8NZoyQVN1O8gVmGEg6y/wAS+GlsSSTstT6J25aTxssj qAXEeAdo83Dm7CdzjoafQQLBGOyg4mPedzxyN6dXAAF8fN8lF5DdVFz8Xmrm6zK0xswRzaKK5sg9 PL2+3WEgyHYUwHzr8VE9a54jt/bSuCbIJAQdtmjePL9Oid5NyaFPpNWgYHGNx1kfsunipXbjzEgk jHDA08R063IsHtjRRZHOkc2UgkAeFhUWp93nKHAaRj1y4+0Sb1u/Rh1WnQT2xIFmHQ0TimmUmf3P qbLK9rvFjg0ir1sn4dLLEweNxdWBuCOmhfyUwG/yU65bltttpA/z1qKaVwyRXDPtVmvxZfw/FQZb qw2EGx+Wll1sgi04Xh4QZH8oz9RPSptby1aKVURw7FzkGxI2v7LrZ/ZrX5z3ex1GnP2umY3kjP4R PWoSxuxyjjS9gPCyUsNxlUGSXHYB9mrf6jVIs1iHYEocRtutX0srwHoBuvzatJEuoGwMhysf4aeZ Y5AIr5lZCrXKvwq32Tvh36sxy0CH+WrA3bf5am00vCTaSMHoNYny1ICBfavnHFVyc2nmtzo91/vP VpNRA5BOKsMDfwmjoNcAsr4YHKHA7j9h/wAOi+hvLoH4zp5L2AJPCjdaGThofmVmgdTcrlDrf+3a hpvdcGq12pYXCxoI1/uSSsv/AFVl97SrpNK2LaLSk3bw6nVnLI/oRJGlQn3PpeW0F8VxaTeyv6K8 VLqNcOIi6Qb/ACSS5f8Aqo3ax2EbsOrRieRmUYKuY2rURxJzI441JsQtjm4et1makkiGQyA8wAWO cHbKveogm4kRcg6AM38VMCbi2FXCi240mo1oOVsU0+x5PT7kdIXC8mI3SAXCBRw5e9xZuJvtKA3e WrXwrBj04G1ZhIXUtYEnsg0Fzbd+6jBpIn1Orm4IYYxmYk9s/dxfiyezoGZ9PpSRgjyZj/xJJRaa JdbpB9wxcj0FYK3qUTDJxx4yREWdCN+Trdbt0NJ72HMjwyTsMw/u/wDlqAe7nVIdU/G5IsotneRe /wAHdpdPpcplt7STa7t8VXGA/wA76LMASQQb9B22oknPp5iTC/7Yn/EirpY1YC5xvhgOni8NBtOA 6SANqGUcatbLmVe1FloPJiQMyzKMRbcSOvw0AilZlN13emrejQZdp4Su8GgWtNriAQm2OP0+zPMn /HRkkJZ22sxuaVRiCrndsVTJm/46Jv5vgZY3Bdrh3OxR/FVyGCDZ02FQ+7vdwvK/E8jDgiRcJJpO /wCCPtvQghB4QA0h6zW2k+tV+eyX2KFUra+/MM2dqIUxzjaVxjPyNzFan1emQ+7veqg8udQACbdW ZF4ZIH7dS6DWRnTa2BiksLGwzA9hvQ6tNFG5KZgyKewy4h4vumzdyoodLppJdXKwRAxCJnPj4my+ rV9VKJZ2xfIMsa92OBety1779f4JNPqFLxuMbWuCOq6eNaMdi0ZuFnA4SOjN2Ze+lJqdI2WaDqIT wvf+kw/EoIW5MoNmgkOVgd4ifqsvp1nyNgczILhHPjUD/ryUz6hg69awxa/kpZoGfSu5OaOdOAnv x8rmt86OjbVILY2EbWv4Ry6Ep1AfTm4XKhUkg+NVrVai3sYdNM2Y9JRkw+dV5IvjJwoxgcsNhYYX qWTUKMsilMRuIvTAHAEgVqvekem/MTaqYw8LKpWKLi4c/wB5NJJn/wBKOrTxS6c786YD1xWfTarK TiVUqwP9uXq/2660UgO0kMmH/LQF723mtH7ygTi1CNFOQNrRWaJ/S5b5P7UdQe7Y2ZnmYIoO1Rfi 2+GknhjHM0ihlYgX2e0okW8g6RauE4V+b1zFQTaOIYvIfu4VPW/EmagupCwqxywopJVR2V9P8T+p VtMoK7DKSco9Jv5eOm1Gs1E8jvYskeWJLjb2ZH4vSrLHBNHbYV1M31WlZPnLQszTwOeF8AVt2HC/ Xoqqkx9W38NSTauT8tPICYEUCy4cLS5u93KbSHbpjy2O8kHif1q97zufZxQyoht0RvI/7UpdVq88 WnkF0hHC58TydhfRoBfdsZBGLZTm9LPm5lSQ6DUNpC6lRcZwD5uF/wDkrNGi62O/Wgxe3lgf2lNo plaKeCaQSRspVhc5hmVqwVpMeqoB/U1H8xAisd7KUPzuGidHqZ4MpsQGzph4ZKuksOqtsDgxsfjX hrTw6uHI6ZnKXVhstmzCl1J07SanlkBkCjKrG7Zmcjiag0xbSHUDLHzQFBv1QXW6Lm9KimrZoVvh IoLKR6t6ZPdt9dqdygMsa/iSuw+rQ1nvKR5p2GJZiABuWKNfslXuUOZp1YCxJbMTgf8AUpdPpkWK JNiLgBXCfjq5JNMMDfcdlDUyqG3ooGysPjHRWqCG0qN7RN5vislTw5TzZ9HPMy780sbso+ZkoBcL AC3moB0GTAXGBArMXTy5sDWeCQMu4bV+WszXNu3tt61PDMmZI8Gddx7d1q6Sh1bBcMSTsQrSsUGd djW/+KILASEfIO07VLq2vlOA8iL07OvQd1IErAlTujXpqLRJiVbN5gFK1yicwHVBxI9Go11CDmPZ lPi63FVhs+DKv2Y6zdJ7tY4VtoKpuSQAPjpQTcgYnz40Tvt5vlpY4upPPxMPuo+uf9tK5WUZLZcu 61rZacFtvVx20Lg/uoLmx6Dsq0Thb7RuJp5dQtsgxZTtPx1eMrzTt7D331nhcOBtz8Jt0Z161ZJC wHS/EPVcUCsxKH7RXBzHyczueGk05NjLgV6QOtU0sjjmsAsa23WqXUPgXNlHkoFSQRs89A4fm4gF kjG0tsWVB9239TuUobFgMfPRhjNrfaOOyPB4qyjC26iLmrdNIGYK17i+Iv4qDTlVNsADmB9Gmgg+ 1lUjyqpGN+7K3drUe9XXb7DTk9AtznX6MfwH8vJmifiCnAofu79ta2m2+uLhbpFAxNn85tSQEkAn OwPk2cVDE7aVOYVttVjnBv4T1ay6iMDxJj8qPTzRFRJlJsvAT50NPcAEYo+wq1uH51XDWIrNIQMh tfpJ6KH5dOEmwdsAb93vU2onIm18wytJYgInW5Ua/XauXEeM7T3R/NRUWA3GjY/AZZBnbYkYO092 uadRypDtz2VvNjV21K5u8zgn1FWo9Foblp2s8x61j12+bUWkhFo4VCL8W/1vgzyqF8xwokbSLCgw xO+rqSB0irE3sABXRXCb0M1yu8VaMkDfc40wtdWFreI9WrGB8oONhspNPq7mO3MUWtcE2y29Lr1z 8o7seG4bxQVcZG6q/wAVYdY4sek0aIppZTwjC28k9VB6VNNJg+xFGxV7lMrLdSCCbdNSxaOEusB4 n2KvdTN36bXa9MurnwRTYlU6cPvfhd8oQOSQi4AX7K15quRmW+Iq6MM28A2Yerhmrv8AmwNWQ+q2 2rMpB6RWFj8CajUC2k07Bsp7b9hPR79McouwxrRalQFkd9RGp8gCP9F2+nSrsEahQPLWdiMzYmsD Rp5pWCoguSazkFY1wjToB2sfE1bKJygm2AO8nC1RwIvBGc8rd+U4s5qw2foDoOFZd++gTif11a+Z RuO71qBMZ+MfvqzXAO4/zUABt6asoxO+rK1mOJPnpgjC6C7Mx4VA7ch7lJHo2LaPRKY4nPbZjmmn 9dhweCkjmNpoyFfoPQ1baxNM7nKo2t0UAoy6aM8K7z4mq5HxGgKg0Ua4xqdRO+5QPZxL67F6WKMW VRb9E9O6mDDBaAG04ADE38lc2eGSGFTYZkYFj5MKAkJDb7qf3UXhs694YgUX05sBtGJU00WqRo5E PFGxtb5e9QXT6IyyA2AeQ5T6Si1cnWT8rSm3/wCTSgRxG33j8Uk/r0bRAnylifrVm07NEd+8Vll9 qm5rk/FesISTu4sKCubIThGooSSBVXpJqxBbzbP10sMSkAYuDuHpUwjF5ZTmmk3sRh81ez+lao+U hkaY5UVRclu4o7VLqveBv7wlF3OUsIlPVgEmXKv4tDluHBx23+ixoh1s250wNByS8JwE67j3ZE6t ZHCrMRcd1vR8XhpplAj1UAvG/SL4wux73YoxmzNiC3SQfq1YNY7aCixI2tvojcNlbQb7VIuCKURg 8tzYXxse0tfmpxZrXFx1R3qwssIwRd3nrlQrwjryHqqKEMIue056zHpb9Oygk9AxpJ1jCBmyh3W5 Gb7tj1M3hpRqkWQ3uXUBTh5qM+llxHWU4Op8VZdSc8Y2yDavibvVe6yRSC1jirKaEKMTpZiW07E9 Vh1428cdRQiwlYnm23ZeqfWoNvFYGxq5I+KiAdtZjjut++ouauZS4DYbr7qMaHA2B/loTTgw6XpO 1v8ATU/XpYNOgSNdw3+Vv0wZbyt8g+SrRRqvmAv8tShRxoudPSU5vpUBfDC2NLPp2yyLv3EeOhKh Ia/ELbG8lHSSnNBLiL9k7pP9w5ZasSCwkVl38W+mO29sf0o4dBC00gZScuxQD1nfqpXP17DUagnM E7C/+SrDAD/AHwYi9rG3T5Km02wRuQt9ttqfR+AMDwtgR++kDXNmupDFTj1sU4uyjUIkszoBzCcR mP8ALTNKQS2y2Aw/QEGigfUSHsoCbekeqvrUs/vqXKNv5aE4/wByb/x0NPooUgiHZQWv5WPWb1v8 IfB56SdRYTIAT0shy/U+DE2oSQLeUYKdtri16vLclzi3STtoECgiKWcmwVRck+alZdMdNE1jzNRw YHwfa/QpZPeczayQYmNfZx/q9o/zqEGjhSCIdlAFH6v8TLNop0tvaNgPly1xRsp8oIrGkMIJljcM thfA3DUFOinc9Mcbt9VaSJPd+pjVv6s0UkaDzsy0xns0pUhBcBQbYZu1QGq1aRDfy0Ln4sxipfzP O1rL94+VT6kPL+vWXQ6SLT+WNAG+N+u3+P8A/9k= ------------A48356845382213-- From mip6-bounces@ietf.org Sat Feb 5 10:04:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06731 for ; Sat, 5 Feb 2005 10:04:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxRml-0001PZ-49 for mip6-web-archive@ietf.org; Sat, 05 Feb 2005 10:23:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxRRx-0002Ga-Sr; Sat, 05 Feb 2005 10:02:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxGG9-00008Y-5C for mip6@megatron.ietf.org; Fri, 04 Feb 2005 22:05:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04836 for ; Fri, 4 Feb 2005 22:05:18 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxGZ1-0003sn-SX for mip6@ietf.org; Fri, 04 Feb 2005 22:24:53 -0500 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 04 Feb 2005 19:04:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.88,180,1102320000"; d="scan'208,217"; a="196382890:sNHT31283380" Received: from hadron.jnpr.net ([172.24.15.25]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Feb 2005 19:04:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 4 Feb 2005 19:04:44 -0800 Message-ID: Thread-Topic: what is the status of draft-ietf-mip6-firewalls-00.txt? Thread-Index: AcULL3FKYDg4HF53QfqFPiYEq7IBxQ== From: "Changming Liu" To: X-OriginalArrivalTime: 05 Feb 2005 03:04:45.0019 (UTC) FILETIME=[71C76AB0:01C50B2F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 X-Mailman-Approved-At: Sat, 05 Feb 2005 10:02:16 -0500 Subject: [Mip6] what is the status of draft-ietf-mip6-firewalls-00.txt? X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0861611372==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f This is a multi-part message in MIME format. --===============0861611372== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50B2F.713A59AA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50B2F.713A59AA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just came across this draft.. Anyone knows what is the status of this draft? =20 It is a very interesting draft. Thanks the authors to bring the firewall issue up for MIP6 in its early stages. But if we can turn this one into MIP6 firewall traversal requirement document for both firewall implementation and MIP6 protocol to make it firewall friendly. It will be much more valuable. =20 =20 I have lots of other comments on the draft, I will save them for later. First, I want to know whether the authors or anyone else are interested in making such changes as I mentioned above?=20 =20 Changming Liu =20 ------_=_NextPart_001_01C50B2F.713A59AA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just came across this draft.. Anyone knows what is = the status of this draft?

 

It is a very interesting draft. Thanks the authors to = bring the firewall issue up for MIP6 in its early stages. But if we can turn = this one into MIP6 firewall traversal requirement document for both firewall = implementation and MIP6 protocol to make it firewall friendly. It will be much more = valuable.  

 

I have lots of other comments on the draft, I will = save them for later. First, I want to know whether the authors or anyone else are interested in making such changes as I mentioned above? =

 

Changming Liu

 

=00 ------_=_NextPart_001_01C50B2F.713A59AA-- --===============0861611372== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0861611372==-- From rmrrjs@o2.pl Sun Feb 6 09:38:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26077; Sun, 6 Feb 2005 09:38:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cxnrw-0006gJ-G1; Sun, 06 Feb 2005 09:58:39 -0500 Received: from [211.201.26.217] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CxnYh-0007nA-RN; Sun, 06 Feb 2005 09:38:44 -0500 Received: from symphony-11.iinet.net.au ([224.1.189.248]:1906 "HELO mail.ies.edu") by ies.edu with SMTP id ; Sun, 06 Feb 2005 19:30:27 +0500 Date: Sun, 06 Feb 2005 19:36:27 +0500 Message-Id: <0.1.20.2081924.0083fc70@ies.edu> From: "Jermaine Baird" To: Subject: Fw: Everything and more. X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 4.6 (++++) X-Scan-Signature: 0634ec58aad05a6aa9ac7d4670be9c6c This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit meme only . septacro resorcinol cattail. sanctify throttle scuffle dentistry glenn simplicity cumberland egipt. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit paulsen bloch
You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web
Guaranteed.
 
 
 
 
 
 
.
.
.
http://www.193.esbxgchdyru.com You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web Guaranteed.
.  
   
NOMORE ------------A85031401794097-- ------------A48356845382213 Content-Type: image/jpeg; name="fasten.JPG" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7RRsUGhvdG9zaG9wIDMuMAA4QklNBAQHQ2FwdGlvbgAAAI4c AgAAAgACHAJ4AA5GYWxsaW5nIFBpbGxzDRwCGQAMSGVhbHRoIGNhcmUuHAIZAAVQaWxscxwCGQAH VGFibGV0cxwCGQAEQmx1ZRwCGQAFV2hpdGUcAhkACE1lZGljaW5lHAIZAAZSZW1lZHkcAhkAB01l ZGljYWwcAhkAEUZhbWlseSBIZWFsdGhjYXJlOEJJTQPpClByaW50IEluZm8AAAAAeAAAAAAASABI AAAAAAL0AkD/7v/uAwYCUgNHBSgD/AACAAAASABIAAAAAAMNAhoAAQAAAGQAAAABAAMDAwD/AAEn DwABAAEAAAAAAAAAAAAAAABgCAAZAZAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAADhC SU0D7QpSZXNvbHV0aW9uAAAAABAASAAAAAEAAgBIAAAAAQACOEJJTQQNGEZYIEdsb2JhbCBMaWdo dGluZyBBbmdsZQAAAAAEAAAAHjhCSU0EGRJGWCBHbG9iYWwgQWx0aXR1ZGUAAAAABAAAAB44QklN A/MLUHJpbnQgRmxhZ3MAAAAJAAAAAAAAAAABADhCSU0ECg5Db3B5cmlnaHQgRmxhZwAAAAABAAA4 QklNJxAUSmFwYW5lc2UgUHJpbnQgRmxhZ3MAAAAACgABAAAAAAAAAAI4QklNA/UXQ29sb3IgSGFs ZnRvbmUgU2V0dGluZ3MAAABIAC9mZgABAGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIA AAABAFoAAAAGAAAAAAABADUAAAABAC0AAAAGAAAAAAABOEJJTQP4F0NvbG9yIFRyYW5zZmVyIFNl dHRpbmdzAAAAcAAA/////////////////////////////wPoAAAAAP////////////////////// //////8D6AAAAAD/////////////////////////////A+gAAAAA//////////////////////// /////wPoAAA4QklNBAgGR3VpZGVzAAAAABAAAAABAAACQAAAAkAAAAAAOEJJTQQeDVVSTCBvdmVy cmlkZXMAAAAEAAAAADhCSU0EGgZTbGljZXMAAAAAbwAAAAYAAAAAAAAAAAAAAP8AAADKAAAABwAw ADkAOAAwADIANQBBAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAADKAAAA/wAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4QklNBBERSUNDIFVudGFnZ2VkIEZsYWcAAAAB AQA4QklNBBQXTGF5ZXIgSUQgR2VuZXJhdG9yIEJhc2UAAAAEAAAAAThCSU0EDBVOZXcgV2luZG93 cyBUaHVtYm5haWwAAA+cAAAAAQAAAFkAAABwAAABDAAAdUAAAA+AABgAAf/Y/+AAEEpGSUYAAQIB AEgASAAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEM DAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQR DAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAcABZAwEiAAIR AQMRAf/dAAQABv/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAA AAAAAQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIj JBVSwWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU 5PSltcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITES BEFRYXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi 8rOEw9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMR AD8A0KajbcxgBO5zQYE6EwV02Zgtx6RsbLe58EHoGNWzAGQRL7CST8CQruRnN9JzCJkRCtczlMp8 I04TTS5HlxDHxmicgEv7ocC6trgdOFXoxrrzFbZA5cdArGTkw1zQIWpj0+j06o1jUgEn4+4lPE5Y seupJ0WSxY8+eo6CI9VONZhXVifpeMKuVukFwIcVk5jWtt04KfgzmZ4SGPmuUjjjxxOmxBQIzcLM ezeyh5b4xH3bla6Jh15WUXWDcykA7excT7ZXT6cBDNzHBLhAs9bRy3J+7DjlIgbCnnaukV10izIM vP5vAH8n+Uq+RgVwTXoe0LR62H1+9h4buhZGLm2XuiNByq4z5Cbv6N37ph4OHhG2/wCk1HNLXFru Rym2hEySDe5D3eS0LPDfWrcbhHucF6cXDfhb/9DsuiV9RxsI05WORV9JmrdwB1ILAdyp5WbTvcKw 4u4DYMz4LpwuS67lfYbH5lAAIeWTHb/zpTDJGUzKUd9fT3YPanHHGGOe3puep4fo0rhfJdYxzQfE ELc6X1Kh2E3GyDBaIB7EDhYeD1f7YSx5LieQe4K0L8CrFfDnEveA4sGjWz+apZZoZI8Mxw1tTDDl cuGfHjlx8WkuL0prr6GucN42BUbsbKvPqNrIr/NJgSPFXel4eO+x91kWtGlbDwD4uVzIs/RgjQSd PgmDJHGfR6j+9JklinnjWX0RB+WG/wBXN6LkfY8p7bhta8AT5hdC6+ljS8vG1cpk3EEk/Sa6JR6M d11YfZYWA8MBT8kY5AMpPBeh+jHilLFKWCMfc4fUP0fTL95sdUz2W7o/OG0DyWX6/ptIrAEqebjP pG4O3V9z3CNi9NrOC3NvJcLXFtbOBAJbud9ykjHDDGJn1a7/ANZhyT5nJmOKI4DV1enD+9bmkyST yVFaFmDS/wDm/Ye3cKv9gyPEfipPvOLhu/p1YPuHMcdUO/Ffpf/R73P6pTTTNTg4vBh4IgLmczDP WqxRVcKXMM7Xfn/D+UmycLKaG3urY/e0OmlwfofzohqDj05V7TdU1oqaY3vO1pP7rPznu/qq5HBj 4CeMf3ukXPlzmYZIx9o/3alxTH+KrC6K/p1o3OG5pmToFvZrWZlLM2lwIIDLG9w5vtWBe66sgWtO v0TMtP8AVcug+rLcJ+JZb7XZRO21roO1o/m9rT+Y9MyYBGHHxcXatmTFzhyZva4OCgbEj6mpgWHH uNTgXC2TA5EfnI+XaGtAIJDZJ85Km3EGL1Oy1zNlNrXNa5slmsO3N/d2x7mKlk5XLRBJOpnSB9H3 KIgGuGzpr5tmJlrx0NdNf0WGBgtz7H23E+ix30RpuPx/krQuxqa65oGySdo5BA07rP6dntpFlO4b SZaT4n6StZeZUwAbhDBDWg6mE/J7hIiQRoOGLHi9mMZTjIGyeOZOun7x/wCi5l+WbKLGuEfmwfEF b3TnV5HSase6ssfS3aNwjQcWMn95YnS6ftNmRlO0+zND2gfvvdE/2FoNeSdTD+xnQ/P81yOYCEfa 3IPEZf1j0WcuTlmeY+WMh7cY/wBWMvmv+8jdVYLTW2C0H6U/wTzT++PvTZPT7sgbq3elt/nnPJDA 3+UB+fu/NWd9hw/+5f8A4H/5km8MeC+P1fu0ze5k93h9v0f5y/8AuX//0uoxHfq7WHmmy6k/Btjr K/8AwG+tT6sysY+M/GA+z7S328B8l1k/y3OduWXbn01vtbXbvrssNrgwEEktrqczc+Nn8z7lXq6r ktNjWPHp2GbaXCazGjYn3N2tG3erEOXySBNcNfvaNbLzuDGYjiE709Hq4W05j8il2Oxu+12tbRzu HxRun4uZhs9Wt1Yv8Gu3SD+Y7TY7/PVnpzG5XTrsrY0PNorlkiGNDbPa6d3utP02ogmQ15/SEw2w kAPn82zjZd+a38y7/jUPcnjBx0Drreq72ceaUc4MgeGokaf4X95rZXXMp1LqjUBkDRrhqA7jSv6W /wDcas93TeotH6RrGO/cc4F4/rNZua1aWM5h6w0QPUZVa5k9rGNbtOv51e6xSqc6+DXpW7i1w+l5 0s/wv/GfzSf7/tge3ER4hxSv/FYjypzSl72SUvbPBERqO44+I/4zhMxss5LMZtZ9a4wxp4P8rd+6 385af7OxA1zRvscz6b52y0na22tjf8E53t/kLUya6cT07gz9KySLDq5ocNj9p/e2OWVbl2V3cy9g Ow/Ee5h/eqtZ7XoT5qcqr0fvcP6RTh+H4sZlxfrAT6OPXhj/AN8zwnV9MfboX42Q0NsDtS0j6LtP zUK7qWKCRUd/k6QquXnNsotLJaNA0O5BMO2z+f7fz1XxMbJy2utBbXSwhrrXzG4/mMa332Wf6vT4 YxlgcuSXDR4TL95jy8xLl8seXw4+PijxxgP0DIy4v8H9N6GvLGV9Xryz6TLdjx32w3b/AJzT7Vkb mo2K2/Ce5uPY28PrjIpe0sa9k7Wa7n7bNzv0X/XEH1K/+4Vv+eVH7ePivj/Vd/0v8Vm97P7de1+v 34f8nX73HxcH+Dx8b//T1/rTQwZT7aYaWFjbg3T3PBcP+oUPq1g49zrszKaLG421tdThIdY6Yc8f nMr2/RVPrNmZ6Yx6K38l1tjgfc4/nbk31fty8Vz6sx0V2FsPdptcPobnfuOVqOeXs+2L4thLrXZp ZORgeaHMEjh3lAj08XD871r7X5GSA5xLKKy944BL/wBDSyB+7+ksWNnk0tuDrixlUS5w3BzHjcyf 5bfoK/Veyul9lrg31Hkkz+awenX/AN/csjPsHUXuxqXAPuc3U8AM4b/39QRiTdC6Fn6N2U4xqyBx ERj4mS2JmYVtrbmtssvb/hnvIP8AK/RN9m1/5/qepvVnM6ndS4XBk7jqW/k2yoYv1efhV77XNrB0 3WENk/yWqv1R7G4xa1wdJAluusz/AN9TsY45xibIsR8gx55e1hyZI0JAGe2kp/1nVOZb1HDGR6ZY 5pLHCQZj89sLLe2yNxIa9rS1gOv9WU3TeqNbQarXbS3g9iEQ5FORaxjHhz7HNYwDX3OO1pP8lqfP FKOQxETQOnXRjwczDJgjMzGo9X6MhLy/6LjWXF8AnjxW3iVv/ZmI5v0DvmP3i8/99CsvpowycXFb DK/a6wgF73D6Vj3/APfEK02GpzGu0cCC3sZTs+eM4iEI8MQbH/orFyfJTxZDmy5PcyTjwyFbfLL5 /wBL5VqS017wZ9c7yf5Df0dDf6v85d/19L1m/vLKs6na9+57dBoKgYboNrWw38xqH+0sv98fcEPu uar4fpeq/wD0jyvFw+50viqXD/df/9Tdd17pmZQx+QDRdEWADc0nuW/nJ/2Pd1GlvoziYZO4WXNm 2zw9OkfQp/4xCzfq5hY1lWRRY70q7GG+uwzLNw37XAN/NXV3QXBw1aR7fgrE5Y4cMsN2b+b9D6NT FHPkjLHzNcIAHo/ysf60nkc76s5GPQbaLvXDBLmEbf8ANhyqfV6uu/rOPXdoxhc7bxJa0kbv7S6n qWbTj47mlwNjxtawc6ri3XnH6ibqjBY6QfiPcp8GWeWOSB34Twy23anOcvh5eeHNEER9yInC+LQe q/U2eu9SvzOoXbnfo6rC2tnYBp5Qcdoe+yp2rHg/Ijhyp5VzrMh9u0xadxI8StrpPSsnMbvaPTre BNrtND/o1W4Z4yCQY0d6dIZcWaBEZRyAx+UHp/WDiSj4V/oZtF54qsa6PgVvdV+rWJj4Rsx9wtYJ 1dIdCxuk9Ns6jm144Oys+6x/g0c7f5a0Y58c4SN1EXxW8/LkuYw5oRoSkSDAx+V6DLNVjnZNDw+t +umsFZmR1CtjXBo4Gk6S780NCs5basa5+NjtDK2aHuSfFzisrOxmhpur0A+m3/vyz8MMcsgBJEb0 sfN4O7zWTNjwSnGIMwPVR+T+vH97hRYOIcu7YSQxo3PcOf8AVy1P2PheNn+cP/Iql0fMpx3WstO3 1ANrj4jstD7ZV/pG/er3Fk+8cNHg4fp/ecb2sH3D3LHvcX+Hv8n/AIX63//V0OrdYtsa+gsNZcC0 tPmq+P8AWDqjaW4rLdDDWOdqR+aFY6vk4Qlu+svPJ3NlYJsZvLmOAEyDIV3lYxnGUJRB634ud8Rn kwzx5ccyCfQYf1d9nXyMDqs+rZeLXkfSPb4LPtovZuNp3OGs+Kv/APOFpxwx7N9jREhwg/es+7O9 cEENYD23AoYcWWOQaUAdT04V3Nc1y2Tl5AyEpSj6Y16uPp/dRSeF2GD9Z+nVYNbXgixjQCwDwHZc buZ+8PvCW5v7w+8K3mxRygCRIrs5PK8zk5cyMYiXEKIl4Ox17r3UsiosZQ+plgOzTse6zPqlk5nT +pCy4n0nja4c/Nbw6l0/MwWCyxjLahBaXAcLGt6pghxrohzuC6QAFmmEhIx4T2ejhlhKAnxDhq76 O31vMxW5AvDxtfo4efiqGRk0HFfDg4vENA81kWmq0/pNrh4EgpbqwIaWgeEhWsfKUYylLajTmZ/i olGcIYzrcBI7V8vE2MZ+OQd43EduyNOF/o/xP96Dvwm1Bwsax/DmyFH1sX/Ss+9Djze9+l83y/o8 LL7HKfdNofJ8/p4+Ph7/ADcXE//ZOEJJTQQhGlZlcnNpb24gY29tcGF0aWJpbGl0eSBpbmZvAAAA AFUAAAABAQAAAA8AQQBkAG8AYgBlACAAUABoAG8AdABvAHMAaABvAHAAAAATAEEAZABvAGIAZQAg AFAAaABvAHQAbwBzAGgAbwBwACAANgAuADAAAAABADhCSU0EBgxKUEVHIFF1YWxpdHkAAAAABwAC AAAAAQEA/+4ADkFkb2JlAGSAAAAAAf/bAIQACAYGBgYGCAYGCAwIBwgMDgoICAoOEA0NDg0NEBEM DAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAEJCAgJCgkLCQkLDgsNCw4RDg4ODhER DAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgA/wDKAwEiAAIR AQMRAf/dAAQADf/EAaIAAAAHAQEBAQEAAAAAAAAAAAQFAwIGAQAHCAkKCwEAAgIDAQEBAQEAAAAA AAAAAQACAwQFBgcICQoLEAACAQMDAgQCBgcDBAIGAnMBAgMRBAAFIRIxQVEGE2EicYEUMpGhBxWx QiPBUtHhMxZi8CRygvElQzRTkqKyY3PCNUQnk6OzNhdUZHTD0uIIJoMJChgZhJRFRqS0VtNVKBry 4/PE1OT0ZXWFlaW1xdXl9WZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3OEhYaHiImKi4yNjo+Ck5SVlp eYmZqbnJ2en5KjpKWmp6ipqqusra6voRAAICAQIDBQUEBQYECAMDbQEAAhEDBCESMUEFURNhIgZx gZEyobHwFMHR4SNCFVJicvEzJDRDghaSUyWiY7LCB3PSNeJEgxdUkwgJChgZJjZFGidkdFU38qOz wygp0+PzhJSktMTU5PRldYWVpbXF1eX1RlZmdoaWprbG1ub2R1dnd4eXp7fH1+f3OEhYaHiImKi4 yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8AMiBlgb7ZZpisKGR1 VVJNR0GdGTQeMjGyAGR6XphWFWZdyK4Omtwg3GHNjAvoJtTYYF1S3ZfjUVXNJlzSlM+96rT4IQxg AdGOzIN8ByRA9sHTbHA5qcOPNIHmnLp4Tidkskj4HE+uDLldjgVEaRgiCrHpTNrCXFEEvPZsfBkM Q1m7YaQ6Q7DlKfoGKtpca9BkTnxg1dtkdFmIuq96Tb9MqmD5bDjutcBsrISDk4zjLkWnJgyYz6hS zNmzZJqapmy82KraZsEwWN1cbxRkjxOwxdtHvVFSoyJyQBoyA+LYMGWQuMJEe5AKjSEIilmPQDDG LR5mUNIePsMN9J0sQxiSVf3jdfb2wwlRIxU7ZiZtZwnhg7HS9miURLLdnoxh9LVRsTXAc1iybjJL IUbpgWSMMDlcNZIHdyMnZmIx9IpjTKVNCMbhrdWwI6b4VsOJoeozYYsonGw6XU6eWGVHkeS2hObh ljbHV9sstooU/wD/0Dqzt3vJxEo27n2yZ2GkxQoAF+eEvlWEO0khG4IGTSgRRmy12eQnwDYB1HZe lh4QyyFmSrbnggTwy5wjoQd8BNccT1xKW9oOua7m7aqSvULdVc02GAeCqMEXtzzrhW9yabdcy8OA yFuJqNVHH6TzUrwilBhnpGnhYxKw+JsJamSVQ3dgMm1pEFiUAdsyNRM48YiOrg6SAzZ5ZD05Id1W PriDEHtjrkyNK21AOmIcT3Oa/idyAByWyhDhXdQA1NMOAntga5UUy3DklGQ3aNRhjkxkEMeYcTTK xS4FJDiWbcGwC8zMcMjHuLeHmi6N9apcTj4OqL4++FFpD9YuY4ezEV+WdEsoViiVVFABsMxtXmOO PCOcnP7N0wyyM5i4x5DvLobOONQAAAMe1shHTFq5q5qjI3zd6IgCqQE6CJar27YQ3l4Wep6DbJPc IGQ5EdQio7gdMRvzZBT+tL444XCnvkekumicqT0xaC6LkAHJUlN5SGFR0wluRSU4agn098KblqyH NjoQadF2vW3epZdMbXbfNyzPdNez/9GceT3WssZ61BH3ZMpl+Co6ZzLSL17K6Eo+z0YeIzoFpqkN xECGBr1GZ+uxS8QzAsF1fZWeJwDGTUo7IS5YqcL3kYmmGV7JC24OFEsyKDvmNCEjyDsZZYRFkhD3 JAUknClpMEXl1yqq9O+F5bNrgxmMd3ntZnE8h4VVH4zI3YMDnQtP4vCpG9RnNwd65MNA1IemIZDR l2GVa3GZQBHRu7LzCM5Rl/FyTC9tuLF1+nC8nfpvh/K0cqYSXa8WNM1Yd9ai0nEbnAk7FlxXjXc4 GupVRTX7suwwMpBp1GSMMZJPRKLo/vfliFcfI3NycTO2bmIqIHc8vkNzlLvKZaKV/SEdffOgw/3d c5pYymK5ST+U750SynWWIEHYjNd2hE8QPlTuOyJjglHrdojLByjtmLBRvmvdssnYLGSfDIzeUYuT htqF4AOCnI/eXARDvlmKBkaDDJkjjjxSNMdurYvMxHjgqytAhBbMXUmp7476wFG2ZY0sy4cu0cQC JuJFjTCZ25EnxxWaZpDucQzYYcXBF0Ws1BzTvoHdsquWcquWuK//0uq2HlfT7RQTGJH7u+5we+lw FSEUKfbbB+bLJZckjZkSWuGDFAcMIADyDCtWtri2Y+mxK+H9MJA01w/ppVm7jw+eTfXY19NX71pk Qu5k0+T1aUVutPHMvDqQIESAJHJwtRoZTmDCRETzC9dFkZayyBfZRXEpNI4j4JCSPEYm2v8AqUCE L74tFqBk6tXB+cy2y/kzT1RB+aXzW0sP2hUeIxa1nKEEGhHQ4ZELMuAv0XcM/OMcYq/aPj7Zk49T DJEidRIcDPoMmCYliuYJ5dQmseryKlCa+4xCbU+Z64h9SK7czXAk8MsW4FRkYwwSlsRbZOeqxxsg gIpr0023wRa6bLen1J6qnZelfng7R9IUIJ7gVcioB6DDdwkVAm2U5c8IExxjfvb8OlyZQJ55bHcR /WlR0mGJaKo2wDcWEdD8Iw7uHKge+FV1KACRlAz5Ab4i5h0uEx4TAJJJb+g9V+zhxpupNbrxY1Ts fDAErh1OBI5uJK+G2Z8D4+P1Oqyw/KZrgaB3DNk1iErucC3WspQhCMjHNnNEqSewx4s7pxUinzyk 6TGDZlTfHtDLIemHEfJGT3/Ikk4WXE5kO52x8tvNEKspPywDI9TTMnDhhH6aPm4Or1WWW2S4+S71 MY0lcTJwwstHuLtPWb93F2Pc/LL5GEBxSIAcPHHJllwYwZHyS5icquHT6RAmxqT4k4Gk0xf2CRlY 1WImrbpdm6oC+EH3FLScqpxWa1lh3O6+IxDLuOPDxWKcXwcnH4fAeLuf/9PuebNiU86QoWPUYqlG vS19OHxNT9GQzzLxFofEdMkF1cGednY/LIf5qumCiKh3yYBViovCrcScNdNv29QRsag9DkcaKSR9 sONOtpNiRuMmUAs90hTczLGeh64farxtoURAATt9Awl8tMvrJy2YbYea9EWSOQdBscr6surHmlJN ScqGZXlVG8cY4IwH8Szq3gclEkHZEgCKItnEDgRADpiUzEuoxKzkEkCkHp1y3P7xciearLsjYe2F NweSkYYXjfGRhbOwSNmbDEE0AgkAEnYBK+R3r0GAy1ZDTxxaSTY074IsdFvbqkgAjXqOXXNrpwMO MymRG+90OtlLU54wwgy4eZCN0+JEUFt27nDTmtKAYGTS7iAgcg30UzO3pfDJsc1+XIZyJt3ODDHH jjEDkFSTiwpTCPUrQJWVBv8AtAYZtOOxwPcuHiYHJ6bLKGSIvYmmrW6eGTDKwLAJBSezgN1dQ26/ 7sYD6O+T+6hFrY8UAHEUGRHywE/Syc/2VPH550C8tUuYuDdPDLe0JnjjHoBfzcTsbEBink6ylXwi wtnBNSd8byr0GDby0Fux4jb8cCVzDDt1jIHFCAMDfo9P5f2q9MF1ri3E/wDC5Ljlw8NmmvwocfHQ uqf/1O1SXcXDmhqPbI3qepPISg+Fe5OEc15eQV9KU8PA74XS3dzOf3j/AHZnw0JJviFfa62fakIC uCXF9iYT3wTZTU4slnZ6xCqT05joT2OEo8Ti1vctC9UahzIlpIeHwx2Pe4cO0snjeJP6TtwhGzeV IYjsgI8cQXTUhNFWlMMV1uYJxb4hgKbUDISQtDmJ+Vy8nZfyjp6syrypF2wFqwlBoRkqhmg1SyIB qSN/Y5AXuJH2Jwdpc17FcRxWnxNIQAnYnJy0fouxxD5NEe0xLKAInh5edo+5s2hcqw3HfATQfF0y X3GlXEsdZJU9SnShpXIrqaXlmxSVKD+cbrmPihxy4QRbnZswxQM5RkfcF1hdyQzeku698OWkBAcD fwwp0C3E6yyncg9cNJCEBHhk88YxnwgcgAT5teknKeIZJH6iSB3BBXE1WJI38MKLy4qOLDbDcgFW kbv0wmvFU1yqBINjo3yiJRMTyKppFkLmb1HFUQ7V8cl8SiNQBthLoBjFtQU5DrhpNNwQkde2Tz5p ZJWeQ2pp02nhghwxG5Nkr0ozPIeg2H0YXXqrKCO574O5elbqp+0RU4WzvVtspDkMbnnkhlaIncHL kmPomvU47UwPrZPtgWOKS6lESfSfAZn6fTmxlntEb7ur12tFS0+L1TkeHZfYSyQTrPF9tTsPH2zo unait5ApIKv3BFMjVlbW9pEPSXm37THrXBkd46Gq0GVavNDKdo8uRbOz9Jl08PXIercx8/emeoJF Ih5DfxyMz278z6bmmG8t20q0PXxwoubhoPidKr4jMfHCUjURZc/JOMI8czQHMqlvbtsXauLeqn48 cKZtXcqViWm3XCz63P8Az/tcsyvyeXg4q37nC/lPTeIIcW1H1Vtb/9WQLbamYw0lpKAehIwFIxRq SKUPgRQ5L9PvZbnTplc1e2uGjJPUgjkMD3VpHdqVkUH2Pj882UNdv6oUPIupy9kkx9GUmQ/njYsU aXwxsSTTNSFGkbwUE4aQeW7q61GKzhJEMgLNMd+Cr9rl/lfy4fXAttMjFnZLxRNi37TH+Zjl+XWY 4RHB6zIWPIf0nB0/ZmfNOQyk4owNE9Sf6LF2ju4V/eQsB4kYiZx2w+NwzHfAd5YJcKZYAFlG9B0b IYdbCUqnERvqOTfqey8sIGeGZycPOJHq+CVeqxO2TLyQsEjXEzUM6UVB4A9SMhB2NOh74ZaLqFxp 96ksG4O0idiMyNTj48UoxNGnA0Ofw9RCWTcXXuvr8HqknxCnT3yM65HcIpJSsZNOXWvzw7tr1LuE Sxkb9V8MdLGkyGOUhkbYr1zR7xPcQ9WCJCxuCxnQClu8kZHFJN6dgfbHai7ROUPTsfbF57Jbab93 X0zup7/LCa/v2SV7eX4wp+E9xl0YzzE1vID5tM549PEX6YE0PI827i6UKEU7Ab4XuxkJ8MRe4Umt CRiUlyStBsMuho8hIsUHHy9paeESYy4jWwCP0689C4Kg/A2HvrCRkUHY7n6MhcctGwyttTkhIJHI dBluo0Z2OPu3Di6PtSBBjmNbkiXdfQslnn5HrsMATTKlXY7DfC59Y5CipvgC4u5ZQeZ28MqxaLIZ escIcnP2nghA+GeOVbAcvipXVyZpnfsenyyReW7JfqM164qSSF+QyJlt650Hy7Gr6EifzA/fmXrT wacRjsCQPg6zsr97rJZJ7kRMviUto8bl4zQ9x2OLRtHOPh+CUdVPf5Yx1aNyjbEbHGEA79/Edc1L 0ivuDQjfKlgWaJkbuMuKYNSO4/2Mo/42w0sbH1pAGoYxufcYYy4SCOm6JRBiYkWCKYfb6Je3KNJT 0oAaeq/en8q/tYp+grf/AJaG606D7WSHzBe+ivpRbfsIB2A6nIv6jeJ8fpzK/P5b4qHD3ftdd/JG Dgq5cV3xfo4e5//WmujtxutZtT/xTcKPY1Un8MHJscLrM+l5lMdKfXLGRfm0TBv1HBymmTSyDSkT jKwFGYca5FNT5CZq7UJFMNtP1eK2uKSMBCx4O3YHscrzDYlm+tQiqNu9Ox8fpwdbUEbhjIbfBEL0 OIFDXKDFWVQKsxoBhVL9VjEV2xUbSAP9/XH6WUMhqRkgi0qznZrm7X15IgFMFaKtPEd8GpLFGOMM EUa9KBRmw/OxGOMKMiAATyFul/kqZ1M8vFGMTImI+o0Uqiu57STnC1D3HY4aQeY4n+G4Bjbx7ZU0 dvOpEkQ5Hoy/CfwwjvbRoTUfFGeh7j2OQicGY1IVJuyR1OlHFEicOo6BPNR1y1jtmeNxJL/utR4+ +Qt7mSR2dzVmNScE+mSeIFSdgB1rh/ZeWbW0iFzq9ZJn+JLQGgUf5f8AMcvj4GliSTZl/pj5ODl/ Na/JGMQIiHPpEeZYoZsY0lcmkscFOEVvHGnZVUYAn02GYUZBXxpT9WAdoQujAgd9sp9iZTHbNEnu IIHz/wCOsX5EdMXhMszrFEpeRjRVA3JxW+0yS0rIoJjBoa9V/syR+VrBILCXVpFrLITHDXso2NP9 ZsyMupxjD4sTxdB73CwaHPLVflpgwIFyP9DvHeoWugx8Ha7k5SR7yQx9Vr4nvlvY6cwp6Bp48j/X BE4uIpheQbzJuy9nXupxV1iniW8tv7mTqO6N3U5qpanNI2Zke7YPSQ0OmhHh8OMu8yHET80iudGi +1bOVPZX3H34eeXL4W0bWFx8J6rX9WIEYCvEIXmpoyfED7ZbHPLKPBymwTtLqD0ceekx6cnU6ePC Yj1QH0yj1ruLIbxYpT6infx/rhW8iR15GmEkmp3NPtHkOjePzwK1/cvs5rkJaTKD9NjybMfaOmkP 7wRPUS2P2p+L+PkFTc+JyUeXLiOe3m4GvB+J+dK5zU3DkUG3vkq8k3ohnuLKQ0aUCWP3K7MPuxlp MkccskhVdEDtLBPNDDjPFxGjIcvLdZr7MblQfA/fXCnD7zJAUn5U+Eksh9j1GR6uY/Rz+j//15ez LF5i0u4b7KtLDIfASRt/TGzX7zOYbVfEcz0G+IX+q2Mrc4eQNagcaUOFjam4HGBeP+Uf6Zlw0uWR +kj37OLk7R0sBfiRJ7o+o/Yjr+VYoltVbk77ucXsfMdzaR/Vrms0A2Un7Sjw91yOyzkVZm5OTUk9 8esqyivQ5sY6SAxCEhxDmT5+TosnaWSWollhLhNUI9OHukygXukTfH6nAnqKEfhg/R7a0u3mvo1Z o7bZWbarkV2HsMhqADcsKZO/KIWbR7lF6+q34qKZh6nTQxYzKNk2Bu7LRa/NnyxhMRiKJNczSBlS ZZTdQNxn7+DD+VhgiJo7xGeJfTnT+9gPUe6/5OKyRlTQilDvgSWE8xNC3pzJujj9Te2YLt1/Q0xC 6UMhB6NsfpwVHKl6ChURXi7vH2cfzJgG+k4oEOzE9PlhBIII5jdBAkCDuDsp+WIUudUd5BVbRS9P 8uvFfuw0up2nmZ27nb2GFXk+4Q6jfxVoZRVfoJ/ri17drbTNAAZJ60Ea7knwy/VknNR6RFfEW4XZ sQNOCOZnOz/VkY/oV2ZVFSaZoVkuSVt1qoPxSNsi/M9/oxGGykZhNqbcf5bRDv8A89GHT/VXDq2T mFRQFQbKiiij5DMdzkP+ioHiPqksCKPIepHdUH7K4mGW2sktLb4YYarwrU161JPjhjevwXiuwGwH yyPyXHpzkMaJL8Lex7HEE1V7XdebHhjxcdCwKvrXcse8ZG3ow8DjIbxLKVpVHKzuNriP+U/78Hy/ awJdkoxU9jgZZT6bDwFQPlhZJtcsIn+Fg0bDlG46EHANzMDBIeoCNX7sKW1BoI/ReptmP7pupjf+ Q/5Lfs5d3P6dkwJ+KX4QPbvluGBllhEdZBo1WSOLT5ckv4YSP2bIIXAYbn78xmXtgOuHOi6G2pBr m4cwWUZo0n7TEfspX/iWb7IYY4mczQDxGDx8+SOLFHikfxZS9rgcgBg+OeW2liu7duMsZDKfcZIY /wBHWg9OxtEUDYyuOTH3qcQv7xvSCLGjyzMsUScRuzmgzXy7Qxk0MZrkbPMHyd9h7EzRFyzREtiO EH0kf0kz/S1nrln6Un7ucbstd1bxXxXCX9HSf79X7dOp6eP9mXqOlQrIwszxdDQgH4SR1p/LhTW7 8JOvDv18Mx/D0397xHhv6P4r7nN8XXf4v4cfEIsZb/d8I5yr+d/Rf//QmnmTRI1Bnt1CM1aEbAnw YZB2n41XoRsR751DzLIqafQ/aLDj885zrtqLa8DqKLOof6ejZtuzsxkTimb2uPw6PP8Abul4IR1O IAb8M68+UkvMhY1ODtNs7nULqO1s1LSyHbwA8T7YXZ0byJaxWunTam4/eynireCjMzVZvBxGfXkB 5un7M0x1WpGMkgbykevCO5M7Dy3pekxK10ou7ulWdxVQf8hOmLahfi1tZJYlCBRsAKb9umU05kdm Jr74X3xN1cW9iu/quC/+qu5zQTyTmbnIkvbYsOPFERxxEQO79arcfWY9PguH+OVxzkX2O4wre9pH 6yfElaN4g++SK6YM3CnwqOIGRmeIWuoGMD9zcDde1ciG0KE9/EaOWIkXeNl2IOB7q/mvaSKhkuOP ABBXkf56dsdeQ2EPIs/xKaGp6YFi12KAelZqEHd6bnLAKIJF+TA+qJETV2L50q6TZaxp12l59WcB T8QJFSp2YUrkp9O3hjaW2AWeTeSZt3Neor+z9GR2HUppfiMhNffBHrNIKctz3yWfKcs+MgRNVs1a XSx02Pw4ylIWT6vNHerRviPTck4bafdQgqC4+/IRfXU0AIckxnav+1gWLWJYxxiB+dP64IYZzHpi T7mWXUYcX95OMfed3oWpGhbIzenkCPDB+m3s+p6eGnWkqfCrfzAYXXispIINfDIygYExlzDLHOOS AnA2JbjohbiX1YVc/bX4X+jocDxOER3c0AFB9OOSKRiVp8LdSegyrm2iaH0a/ENw3vkoRiZASNA9 VyylHHKUI8cgLEbq0vknhBIA5k/s9vpwJdSvIRzPxHt4DwypHEdVA3HUYHZixqeubvT6WGL1Dc9/ 6nju0e08upHhn0xv6R/vlSJDLIkS9XYKPpNMm90VtoILGH4Yo1AA8TkQ0hQ+pWwPTmD92TLU4jyS QDalDmH2pM8UIdKJ+LsvZvFHw82Uj1GQjfkBaEBxlnSfVGnbePTk5jwM0gKp/wAAtWypXWGJ5XPw oCT9GKWcRttNjD7T3bG5n8fi+wv+xTNa9EVQsWJOXzH+fjjK7EfdjfVGK0//0Zlql9+lLxUQ/wCj QmtfE4QeYnhkaMuxBQHYU74YPLHaQE1oAMg+sX0007Hdg32SOmXYpyhISiaI6sM+HHmxnHljxRPM K6y2rtwVyrduXT8M6BoF3w0Vbfuh3GchEVxI1RUHJt5Tupoq2twfhb7JOX5dRPLj4J+qjYLiabs/ Bp8xy4RwXHhIux72dJLXfGaUfW1C4u2+zCvpp8z1wJK5giYnsNjgzTVMGnLXZ5jzb6cxC7BFs5Yk +OE2q0a4t6faB/DDJpFRSzGgGElzcq8rXDH4UqF+eMYkkAdVMhEGR2AFsc8xzFp2jU0Wu4Hc4QQP IZAow9vbWe8nT0xUOCSfpxe10MxkFhvk52JEHpsxxkShGUeRFj4rrENwFcNY60GXDYuoFFJ+QOCP QK9RTIs0FdoHQ16EHCCBladY/E0yQXbUDEdFU1yJhyr812YGoza9mgmGQdLFPNe0E4wy6eVbkG/6 oL0DSZVjs44x2rgicxyg8hv45HNH1AOgjc0J3GGrTdswNTCUMshLvdzossMunxygduED3UoTxha8 fowukUlxg6WSuwxIqEAJFZH+GJO5Y5CIJIAHNyJSEYmUuQDHTaT3d7JBaxmSQsdl7fM9sNo/Kroo N5cLGx/YQciPpOSqCzh0OwCIAbmb4pZD1LHC13ZyWY1JzMy9oT+nF6RHa+pdPpuw8FnJqQZymTLh uoxvptzSuDRIrWdZ4rhiU3FVHUZIpLq2nj4tsad/HC7GutVzEyZsmUg5DdO00+kwacGOGPAJGyAS RfxUbi2+tXMNku8TtznYdBGnxGv+t0wRdXEZlZiwUDZR7DCm7upbI7EhX2r/AAwsa7SRvjP68Y4c kgCIkg9wZT1OCBInkjEjmDIBPfrKSn04fiJ2Jx/KD/fw6+n1/b8MIjqQjjKW68aihfv8hgD1X/m7 8vpzI/IZfD463v6etd7gfy1pPHGLjHDRuf8ADxbUL/S//9KW6noLOSGrTsMj1xoAWopnRbO9tdYs kliYepxFVPXC66tDyKld8sIMSYkUQsJxnESibBF7MHXS0OxUBx08DiwtjbRNJTiV6HJP+igT6klE QbnI9r10rn6paAueh4ip/DL9NCU8sa5A2XF1+eGHTzJ5kERHW/JXttaSaBYLzoKfEOuG0uuWvFRG 44oKAZE4NI1hxUWknE92HH9eNuNPv4BWa3dQO9K/qzNnpNPKfpmIk9AQ6fF2rrseIceCUgBzlGQ/ 2Sb3eteqSOVV7AYWyXjznj0UdBhcGQdTv4ZmmAXiu1cvxaPHjNxFnvLh6ntbPmFTIjH+bHr72T+X Z455EjbdqkKP4ZOBp1nAvrTKCetD0yJeQtPV2kvJBXiaJ/XB/m7Wmt1+rQt8R2zV60R8eQj8fe9D 2VLJLR4jk222/q9G9W8xwWp9OAgAbbDCS610lhQ1Vt8i88jSAsxJPc4sTyijb2ygB2HuTe7uDPav 6O7MN8j2GVjKVfgTscQ1CARTVUfC+/05tezsoo4qo8/e8z7Q6WZMdSCSAOEj+aowzGM1Bp4Uwb+l JwNmrTvhZXL5Zm5MOPJ9cbdJp9dqNP8A3UzHy6fJMRqlx1O598MPL8j3utQeq3LjuPDI7yOHPlic QatG7dKEZTk0+PHiyHHGjwnfq5uDtHUZ9TgjnyEx447DYM21tj6qjt2wow91SL1kDj5jCMgg0Oxz RPZhrLxtcZJMkY3O56DFUt1nibY16g7ZHa4b63MOKRA7n4jhNXN7oQRgjfWy8Z25OMtdIR/hiAfe uNTvlYNsNNmvmqDwiHVz/DDf/Dtv/v1+nt1y7xsfieHxDi7v0OH+S1PgfmOA+H3+Xf8A1X//026d qc1p8CuUp9lgfww1/wATagNjKGI7nCu48v6xbDlLatx7laN+rAUUUkk6QUIZ2C0OxBPzzojjwZLl 6Zd/V4uGo1unEcXrx3sLBj97M9Ji1bzG/wAcxS1X7bjv7DJfaaPYaagW3iHP9pzux+ZxfRrKPT9O iijFKKKn3xY7n55pc+bikYw9MOgG3zer02m4IxllPiZK3lLf4RUyo8MSmtY5lIZRgimbKASHKee+ Y9ESJjLEoVutR3+eRE7Gh6986d5hKsnHqc5xeR+ncOviaj6c3PZ2cziYSNkcnl+3tHDHKOfHHh49 pVyvvZ75JuETTynffI15pmaTUGr0GN8u6ibRnQmgO4xLzBKs8wmTv1zC1mMxzyJ5SNu47JzRyaTG I84xESPdslRNVpgiPeBfbAYYEdcFW5rEV8MxnYjmr24PqrTFdW6R+OKWkVCHbplz2F3qEwWFfgHc 5l6Ixjl45SEQBzLrO2ITyaY4scDOUyKACS5sPJvK2oRRmRSrEfs7jCSRHicpICrLsQe2bjHlx5Po kJPI59HnwV42MwvlfL5tYtaTGGdXGxGIVy40eV1SMFmY0AHfJGiDfLq14yYziY8wRXvegabrcVxE IZjRxtU4+6VGBZCD3wrsNCEEKzXpq9K8ewxaSeNapGNhmg1AxCZ8M39z3OilqZYonPERNd+9eaCu 7ieMkJTC43Ppn1Jn5N2GDbq39dTwcqT4ZHriKSCQpJuex8cv0umhlNmY2/h6uL2n2jm00ahiJvYT P0h1xM1xIZT36D2zW8TTzRwr1c0xHDLQ+J1GPl0FTm1n6MZMR9MTQ9zy2EHPqYDIbOSY4j7zuym2 txbxLGBQAdMWxSYhT7YH9QZz/HLj47N3dvd+HHg8Ohw1VdKf/9Tq8pUihAI75F9b0y19WO9RQssT BuQ7gHocPriUCuEOq3aGF1JrtTLsEpRmOEnfZq1GOM8UhMAgCxfQjkWZadOlzZoymoKjMykGmQLy v5k+rIbadqhW+E+2S5tatHTmGHTHPhljmQQx0ueGfFGcDdjcdxCOrgW6vIrdCzNuMINR8z28AID7 5FbvX5L1yFai5WIlyaTi/wBQN1MaH4RkT1Jw1yadhvgw3yRpQnc4WTOkzl0O56jNhoJwhM8RokUH T9t4cubAI4o8QibPe3bycHJr1FMq4maRafjiWXXNpPFDIKkLBeZwarNpz+7lwkHl+tCiWRDQrthn p5LtTiST2GBTQ5L/AChYQy/vWALE5r9Ro8WOBnZ8g77Qdr6jUZY4TCHKzLfkPJEaXok10ytOCieG TC00uCBAFUbYKhgSNQAKUxU0UVzVku/Qs0C8CCO2c4802axz+ug9myfX+oxwoRyzm3mnWB8XE75f psxxTEuY6hxdbpI6nBLEdieR7j3pNQ9aGmTjyVosUim+nWrH7AI6DOYQ69IkgDdK52Tydexz2CFT 1GZWp1xnjMYgxvr5Ou0PY0cGYZZzGThGwrke9U18iIcV2GRmuSzzDB6kfqDtkRNK0zXB3oK6uBry 2S5iNR8XY+BxfLAqCMtxTlCQkDVNWfFDNjljmLBDFWUoSrdQaHH207W8yyr1U4vqSBLio/aGBFFS ABUnpTOgjITgCeRG7wmXHLDnlCN3CW1eXJmMOqQ3MK1YBsr6wn82RmO0u6VUcfpx/o6h/N+OYH5T D4l+IK7vN3v8qaz8vX5eXHVcVHhrvf/VP7rXnkJArhHfX0ksbUbc9sO9U04FiIxT5ZHbixkiNTmR gmITEiLotepxHLilCMjEyHMIGORozVDQ+OCxqVyF4liR88CSIUNex6/PG12983gGPNAEgEHveLM9 To8soQmYmJ6cimdvpbaiBIzHfti0mhSRD4Dthl5clV4wp6jb7sPpolI3GaXVREMsoxFAPX6DIcun hOUuIkblgT6XNWhOIG1eJtxTJhcRAVIGFU6K2UxJtyiAkcycaN47HEzgu9AUBffAeb/TSJwxJ7ni O04Rjq8gjsObeSHy1qv1KUxuaKd1yO1xysVNRsfHJ5ccckDA9WjTaiWnyxyw6cx3h68mv23pcuQr TCTVfNqICkVSfbIGLy5UUD7e+D9Ih+vXPGbcDNXk7P4BKZkKG70uDtvHllDHHGeKW2/Jbfa/PLyL kj2yIandTXTnqQc6bqXl63MPJUoaZGZdFQE/D0zBsA7O63IDBUtpWYbHOm+Sb97aNYXPTCUaUoNe OGNnEbb4l2piTagU9EubhJ4TUg1GQy/ZbeYkH4SemIya5LGpFemRzVNVnnaqAn5ZKGHIRxRiSPJr nqcGOXBPJGJ7iaZNHOkg+E4vyVELMchVlqVypq1Rhg9/cTJSpA8e+X4tJlnLlwjqTs4mq7U02CBP GJyPIRNt6hOss5Ybhds1nLGtD+0cAyAt8C98fCjq2+ZuskceKOOJdT2RjGo1GXU5ADvt7yngutsd 9aGFtTTG8jmrt6Og/wD/1pvcIoqzZHNRZCT4YJ1HW9iEtroj/mEuR+uLIxd6s7Mf9GuAPe3mH648 siLNMiaBK28oFB98C1GJTXpcgvHKq9qxSD/jTE/rUf8ALJ/yKk/5ozd6eUIYxGU4373j+0cWXNqZ zhimRyvhO6b6ZftZTBq/AeuSsa1BJGCWGc/F0n8sn/IqT/mjHC6FNllp7RS/80ZDUYcGbfxIxPvb dDqtZpY+GcE5w6CiCGWXes2oqOVThVLqUb7g0BwjeeCtX9SvvHJ/zTlrc24+yrn5RSf805Rj0eIG 5ZQR5Odm7W1UokYtLOJPUgn9CNllMr8jsO2M2wP9aj/lk/5FSf8ANGb61H/LJ/yKk/5ozPjkxRAA nGh5uhyafVZJGc8WQmW59JRGbA/1qP8Alk/5FSf80ZvrUf8ALJ/yKk/5pw+Nj/nx+bD8pqP9Rn/p SiK4Y6Ndi2vFJNA21cJvrUf8sn/IqT/mnLW6Wo4rJXt+6k/5owSninExM47iubZhw6rFkjkjhncT f0l62skd1B26YRXluqscI7DW9RhQL9SupAOhW3mP/GmXf67cuprY3at720w/40zS5dPKMjRBHkQ9 hp9ZDJEcQlA90okIqT0U3Zhhdc3sQ+GPI5dalqMjmtvOo/yoZR/xplQ3LdXWQN7xSH/jXBjwSkRZ AHeSyzauGOJNSkegjElMpn5kD6TiZVe4wN9aTusle/7qT/mnL+tJ/LJ/yKk/5ozcYjixwEBOO3m8 lq4arPmllOGYvl6TyRACjoMuuBvrSfyyf8ipP+aM31qM9Vk/5FSf80ZZ4uP+fH5uP+U1P+pZP9KU XBx9ZK9OmGzWqOvJeuR4XUdfsyf8ipP+aMGRaldItFgmdfH0Zv8AmjMTVQjlAMZxsebtuysuXTGU MuHJwyN3wkox4yu2J0HhgGXU7kvtbTD5wy/80Yz9J3P/ACzSf8iZOv8AwGYHgzutvmHe/m8VXU/d wSv7n//Z ------------A48356845382213-- From omvkm@o2.pl Sun Feb 6 15:29:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24740; Sun, 6 Feb 2005 15:29:46 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxtLh-0005LV-8N; Sun, 06 Feb 2005 15:49:42 -0500 Received: from [220.122.96.120] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1Cxt2N-0006vg-Pb; Sun, 06 Feb 2005 15:29:44 -0500 Received: from symphony-01.iinet.net.au ([0.224.72.245]:1906 "HELO mail.ies.edu") by ies.edu with SMTP id ; Mon, 07 Feb 2005 01:21:19 +0500 Date: Sun, 06 Feb 2005 18:22:19 -0200 Message-Id: <1.3.48.2081924.0083fc70@ies.edu> From: "Percy Chang" To: Subject: Forget the rest X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 4.1 (++++) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit meme only . septacro resorcinol cattail. sanctify throttle scuffle dentistry glenn simplicity cumberland egipt. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit coloratura thermionic
You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web
Guaranteed.
 
 
 
 
 
 
.
.
.
http://www.193.edhcbxgsyi.com You Will Not Find it Cheaper With This Quality and Range of Choice, Anywhere on the Web Guaranteed.
.  
   
NOMORE ------------A85031401794097-- ------------A48356845382213 Content-Type: image/jpeg; name="trite.JPG" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAEAsLCwwLEAwMEBcPDQ8XGxQQEBQbHxcXFxcXHx4XGhoaGhceHiMlJyUjHi8vMzMvL0BAQEBA QEBAQEBAQEBAQAERDw8RExEVEhIVFBEUERQaFBYWFBomGhocGhomMCMeHh4eIzArLicnJy4rNTUw MDU1QEA/QEBAQEBAQEBAQEBA/8AAEQgA5QCdAwEiAAIRAQMRAf/EAI4AAAIDAQEBAAAAAAAAAAAA AAMFAgQGAAEHAQADAQEBAAAAAAAAAAAAAAABAgMEAAUQAAICAQMDAgMFBgQHAAAAAAECAAMRIRIE MUEFURNhcQaBoSIyFJHR4UJSI7FyklPBYoLiMyQlEQACAgEDAwUBAAMAAAAAAAAAARECAyExEkFR ImFxMhMEgfByI//aAAwDAQACEQMRAD8AXLoJzMcayG5h0njMxnpwea7aEW1nqdZDOsLUMnEYSZZc 4uhBGhjei/TDCLaKDLqK6jEjeGUTLhvqA9IE8lTp2lZ0Y94I1uPlE4oaWWQ6k6yFpHaeVq3pJWUv jpiGNTkUbdZXYGWbVI6wLEYlEKyrYZXYw9xgNuTHWxJ7nIJaqXvI1VCXUqULFbHVSs3SOfBcRRm5 hlj0iw1/iHpNB4usJWCDJ5H4+5Sq1GtYAEl+HdIBxiA/UL723PaZoLtpIwgsyZOBQEQoM3mRakSJ a4SqGy2ogDDUMBOewEtRtUVxpCNaoGJQHICiV35DE9ZPjI42FqnvDVlTEH6l1PWWaOeR1gdGcmaK mqvGcT26tdsV1eVVRrOu8urDCyfC0leSgDzQAxxKW3IyfsE9u5BfvOrcMmO4lkoRPdlW2rPTrBoA JafTUyqSAYyA0k5LVeBLFZzpFwuxLXFuBYA9IGgJpuC8vGZ9QIw4vuVYB0hONWNolpkG3pIWt0Kq pA34WUPf/wDa69oXkNocaRXvb3s951a6N+gHuha9ZRipGqnBkdsY+WqFfkLlA03Z/bKe0S6tKT7g tSG0CxPRkQmye+3DIvEgXOIItrDMkEyQgaZHMksjtnoBgCkTye08Jb1nuDOwZwYPBmTBxIgGSCmc A5jmAdSTDEGdtzOQttSvtMNSSrCT9ueiuGRVVpyPeDzQECv26GXW5lZXrM9TYVGDDe5p1kbUUl1Z wXnuVyVzBbF3bpSFjBsgyfvH+E7icWvNoH59jD4CLShEt38pbrXsP8xJgiVMaqhJBbltggsIqSQU QigQgIGjIleynEYqARBXJAmAXe1rPfZhymslthkJW2TtkOVkSpnHEAkIqAyPSSV8TjiRrXErsuGh zYMSu5y0KFaLFNe6H/SNjQTzhDJEcVUgrJ2tByUib9Mw7TvaI6x4eMMdJXsoWD7B+IqKayOw5lm2 rB0gvxZxiNJ0C4uRO95hPGUiQwZUk2w45BhF5REqhZ2DOhHcmMF5Q9Z6eRmLskT0WGDiFXLwcEwy LmUarNYz41T2LuGi+p/4RLaFK+WwJqzBssuutanDEn1wIejxVPMUtRyNR1UrqPvifZVbsp9duwnM iY05fgebShsrxco1IXRv9PeJmY5j1srbORLVa3UBNJ2wGDDGTDmMIWuIdriPuMcgTOVOQQY44fIG ACZLIgoZkaSreMSytgIgrgrCRW5QWMNzTz2hmGsTHSQ9t9m7tKzoKdb9N2kZSxSfQ6Ssfp3mDuuf SM+P5yljstyp9esaVsly5XDAxPuuuqLPBV9DJWeF59fWrd/l1lV+PbWcWIV+Ym59p1/Icj0MiUrt Pt2Vjd6EQr9D6pMR/nXRtGDZYPGs2nK+nuLyAfbX2nPQjp+yZrneNv4N3tXDrqrDoRLUy1tot+xG +G1dXseeP4wut/F/40G5z8PT7YystycL+FB0AguMns8Nf6rTvPyGizs95K9pt7GnFXjVd2cTI8Xk vx+R71RwEOo9fhIXPtXHc9JJa9tew9Tq3zk3roVRsePbXyKUur/K4z8og+p/EIEPkaFwQQL1HQ56 P++XPpy8tXZQTnbhl+3QxxbUl1b1WDKWKVYfAjEnWzpeV/iOvVWUM+bDE9BncituPfZQ35qmZD/0 nEFum9amBuNC7TgmXUda8Exbxid4jCwKUES7grjryLtXLrx1hvdRho0QPlToSJyci5ejSM19in1D xkJ75EsbV/TEfERdwuQ9gw0ue7ps+2BvYatIT9UZ6s5umu8UP7QMyPGCNaCHAPo2k2PjFC0rqPsO ZJvxLIZKJLaOuOk8WTkwHmBMz9Utv5NVf9CE/wCo/wAJp5j/ADtps8lbg5C4UfYJb86857Inmfh7 sjcAorQdFrUfdmBJhb9Sjf1Ip+4SrcxxsHVpRvqMuh5X/csLn8qdPn2hc6zlQIoQdup+M6BBGf06 2Oayj+ZWz/jNLM19PLu5zMOiq37ppZC/yG7GB+pKSnmeTtGjlX+1lBMV4YdQY6+orv8A7N4xkLtH 7FEq0X1D86zdRvhX/VGG9U7216sr8dsHMtvaCJCxVdiyDSBsVhEytxoi2FQeu0ip1gHNgnLaw6iZ my6GfGt2GXPe1zFCXiG/UDbOVtGgwecTVgGAx8ZpOFQhUFAB/lyIl4nDs3Dbgn1j/hpcgG4faNZS 9IUSTreRhUHUfmP2w4LesHWdIXSQaHkjZuKEE406iY7l01ixsHOpzma3lNilsHBxMjeDvIb1+6aP z9SGd7EgQ3GRv9vKH5DUQFKl2NzdtF+cnWFIeoEYcaj0I6GEKBMIOi6Q3Xl6bj47J19VoQxOOgJ9 JI4Gs9qps5Nq1VjLMdP3wNwOkOPpqgqlt5HXCg/eY8JCgsxwoGSfgIHicdeLx0oX+Uan1PcxZ9Re QFPGPDrb+9cPx4/lT/ukFV2tC6nWskm+xkudceTy7uR/uuzD5E6fdBDcIQoQdRpOSvc2J6C0XsY9 37hePvOghrKHYdNZc4XHVQCRGHtVMMYkrXUl60cGdfhcgIbNv4RABddRNfT4tH1OQp7TzkeA47od gw3rJ88bcMbjZbGUFaHtJ+yuIXkcWzj2mtxqOhkMnGJzx1lPoFXcPuOaHCHJAHyl6rnUdCOneLdp xjGJ7t0Gsd1T3Myu0O08hx/XEJ+uoIyrCZ/qZPBONdIjx1H+1jXl8xHrIGoiPkBQC5OB98I7E6A/ LWVL2y2Ccgdo9aqoG3dgdrMwIwoPQnrCE2KMEhwOmNIN3ywksg9oLWb0LVoq6ovcXgPyVDjdt74G cffHPHr4vjKGu9uxm/nfblsfIHpEfjuY3HuB12HRhNQjB0B65EheU9divTQSc36rQIU4VTbyNLLN APkveIf1TW2NZcxexzkuTrmOvNeJpX+9XhA3bGm6IDTg40/jNOJU4zVQZcnOdXJaWtXXIIz1xPa6 wrdJUXcunaWKnPWNdwgY1LGNb7RgS9wlNtmOw6xQlms0XiKdtO89Wma70NaGCKFGJLGk6dInGf8A PUAOlgHXSKNn7ZpPM1GypcdQYo/TN6azTW3/ADfsyL+f9RJST30hABiBRX9IUZ9I7MwT2x6T32tO k5ZPOkWQlY0dT3i7lArZgxyRpFXkUO/dGq5GroymTJgwRyZJSREa1NKYddMTUeLcvx1BOSNJlUOu TND4S0GthEuvEKGHKpF1DowzkHExHLr9ux19DN6SMTHeZqA5DlfXMb871aJ5lpIrzrDo2BAAawgE bPbZHYFo2XOKDZaqDuZs+OgSpVHYTK+Dq38tc9tZr1GBM9nJdnTp06IAo+SICL8/lF2/XOTiXPKW V7lUsAygtgxb7lOPc+z/AJcy6Xh/GRb8/wCoPWFGhhvaU9IM1kSallMZs7giXsSJplhCWhBWTF5C vH2KOw95T5tYKGOWo0i3l0kZEaltRLVaM652tiTSxcSXK45BJlP8SnEs6zqhq36MvowJj7w1Y2kg 9ZmKmbM0virfbq1krp8StXqNbAwU4My3lBYbWzrH9/NAU4iDl3ByfjOwppyLlcoXBMGT2zlGWhAs Gb5DYviOfp2v+4z+k0kR/T64rY/GPJC25RnTw6CdBciwVUs50AEC1YHsJefcr8hj/ToDKWE37sHX qO2R3kbbfcJfvqYHc2Os1qvjHpBj5eU+pp1pDCejjDMLWNIYCZuTNsIClAEIEAhAJ0EsBEqMRfza hiMjKXLGTiGj1EyLQQ8rj57RXbxyD0mitrzKdnHUmaq3M0CmmolhHNClKwOkEtVaa9569uBpOs5K VtBHmXbUIB6xTY59ZZ5DM0psDHqoRO9pCU5JlsVmUq2KHMvU8lG0MTLXqWwW0geeCGK2HxjiJvEW puKg9e0ciZLbl2dFXmb8Ve0p1br8oyutWpCzdBM5yrWvtLt9nyj4qy57EstoUdymyHGIPafXvDOd ILdNXQzGwQaQogK3yIYNMRuZKezzM7MADj0la5cmHYwLmMhbFOxJVsrl9hAOJRMhZC9q4KxNJdZY CxZRMQWXKZXK6xhYmTA2VgDMomArbAdISugDUQQb8UPW2TJ5X0NOKqSkv8BLVsUr2mlqYlRnrFHi 6cjcY3Ggme25Vg+TX7i4PSKL6ACY5c6RVymwTHxt7EsiW4ttTB0lbB3Ylq1tYHK5zNC2IRqaGm04 llXMV03y5XcJldTZJcDT3dALaJIOCYIAwhMG0lmRacTYJoFxDEQbiOhGV2WBdBLLCDZYyZNlGysy pyMhYzdMyjzE0MpV6iirP4pa44LOBKp0bEYeOTdYIuT5GrG/E0nAr2VCW4GgYQCFJmd7lAdrYUxH zL8MY35NgCGZvm2Zc6y2FEsj0PGsBgd53YgTZjvI+5rNEEJHVW+W6986dIM0h13Q9XXXrOnRGBh9 JFsTp0UAMwbTp0IjBN8JA7p06MibPD0lHm7dpnTo9dwMSN+eNvF7dwnTp19zRj2NHV+USTZxOnSH UoUOdv2HEzfI37jmdOmjFsSyFQ7pH8WZ06WIdT//2Q== ------------A48356845382213-- From mip6-bounces@ietf.org Mon Feb 7 02:26:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00728 for ; Mon, 7 Feb 2005 02:26:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy3bM-0000kC-Bu for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 02:46:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3GF-0003ML-Nf; Mon, 07 Feb 2005 02:24:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3EJ-0002cn-7g for mip6@megatron.ietf.org; Mon, 07 Feb 2005 02:22:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00293 for ; Mon, 7 Feb 2005 02:22:41 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy3Xe-0000fG-7L for mip6@ietf.org; Mon, 07 Feb 2005 02:42:42 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j177qet05460; Sun, 6 Feb 2005 23:52:40 -0800 X-mProtect: <200502070752> Nokia Silicon Valley Messaging Protection Received: from danira-pool05416.americas.nokia.com (10.241.54.16, claiming to be "[10.241.54.16]") by darkstar.iprg.nokia.com smtpdonGsYq; Sun, 06 Feb 2005 23:52:38 PST Message-ID: <42071710.8000102@iprg.nokia.com> Date: Sun, 06 Feb 2005 23:21:52 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alpesh Subject: Re: [Mip6] HA prefix = HoA prefix? References: <200502042010.j14KAMoQ015776@sj-core-1.cisco.com> In-Reply-To: <200502042010.j14KAMoQ015776@sj-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7bit Alpesh wrote: > Lau: > > Support for "virtual homes" can be done in various ways. I don't see a > strong reason to remove this aspect from the spec.. > > Plus, what happens to the "DHAAD mechanism" mechanism? nothing. the MN still constructs the DHAAD anycast address from the home prefix and send the DHAAD request to the DHAAD anycast address. and it gets a DHAAD reply with a list of Home Agents that service the home prefix. Vijay > > -a > > >>-----Original Message----- >>From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On >>Behalf Of Wing Cheong Lau >>Sent: Friday, February 04, 2005 8:50 AM >>To: mip6@ietf.org >>Subject: Re: [Mip6] HA prefix = HoA prefix? >> >> >> >>>Date: Fri, 04 Feb 2005 08:47:37 -0800 >>>To: Alexandru Petrescu >>>From: Wing Cheong Lau >>>Subject: Re: [Mip6] HA prefix = HoA prefix? >>> >>>At 07:20 AM 2/4/2005, you wrote: >>> >>>>Vijay Devarapalli wrote: >>>> >>>>>it is actually a bit restrictive. >>>> >>>>I find it not restricctive but allowing one-interface HAs >>>>non-default-routers to exist. >> >> >>Dear Alex, >> >>Removing the "HA prefix = HoA prefix" restriction would only >>make the system more flexible, e.g. allowing virtual >>home-links for which the MS never returns home. >> >>It would not preclude your case of a one-interface HAs >>non-default-routers, right ? >> >>Or am I missing something here ? >> >>Regards, >> >>Wing >> >> >> >>>>>our HA implementation does not do this check. >>>> >>>>Ours does. >>>> >>>> >>>>>instead, it just checks if the HoA of the MN falls in one of the >>>>>prefixes that the HA is configured to serve. >>>> >>>>Ours doesn't. Our HA is a standalone one-interface >> >>machine, does not >> >>>>serve a link's prefix, the link is served by a separate >> >>Gateway that >> >>>>is the Default Router for that link. >>>> >>>> >>>>>RFC 3963 relaxes this requirement for Mobile Routers. a >> >>Mobile Router >> >>>>>has an option of configuring its HoA from the Mobile >> >>Network Prefix >> >>>>>(delegated to the Mobile Router for use in the Mobile >> >>Network). the >> >>>>>Mobile Network Prefix can be different from the home prefix. >>>> >>>>That's another issue. >>>> >>>>Alex >>>> >>>> >>>>>Vijay >>>>>Pete McCann wrote: >>>>> >>>>> >>>>>>Hi, >>>>>>My apologies if this question has been raised/answered >> >>here before. >> >>>>>>Given the following text in RFC 3775, section 6.1.7: >>>>>> >>>>>> >>>>>>>Home Registration (H) >>>>>>>The Home Registration (H) bit is set by the sending >> >>mobile node to >> >>>>>>>request that the receiving node should act as this node's home >>>>>>> agent. The destination of the packet carrying this >> >>message MUST >> >>>>>>> be that of a router sharing the same subnet prefix as >> >>the home >> >>>>>>>address of the mobile node in the binding. >>>>>> >>>>>>does this imply that the HA address (the destination of >> >>the packet) >> >>>>>> must share the same prefix with the home address? >>>>>>A possible alternative interpretation is that the router >> >>must have >> >>>>>>some interface on the home link but this is not >> >>necessarily used as >> >>>>>> the the destination of the packet. >>>>>>Thoughts? >>>>>>-Pete >>>>>> >>>>>>_______________________________________________ Mip6 mailing list >>>>>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >>>>> >>>>>_______________________________________________ Mip6 mailing list >>>>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>>> >>>> >>>> >>>>_______________________________________________ >>>>Mip6 mailing list >>>>Mip6@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mip6 >> >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 02:28:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00963 for ; Mon, 7 Feb 2005 02:28:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy3dh-0000mk-66 for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 02:48:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3Gz-0003d2-7q; Mon, 07 Feb 2005 02:25:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3GD-0003Ll-Mw for mip6@megatron.ietf.org; Mon, 07 Feb 2005 02:24:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00501 for ; Mon, 7 Feb 2005 02:24:40 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy3ZZ-0000hp-Ad for mip6@ietf.org; Mon, 07 Feb 2005 02:44:41 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j177sb007989; Sun, 6 Feb 2005 23:54:37 -0800 X-mProtect: <200502070754> Nokia Silicon Valley Messaging Protection Received: from danira-pool05416.americas.nokia.com (10.241.54.16, claiming to be "[10.241.54.16]") by darkstar.iprg.nokia.com smtpdDKBh6W; Sun, 06 Feb 2005 23:54:31 PST Message-ID: <42071781.7030505@iprg.nokia.com> Date: Sun, 06 Feb 2005 23:23:45 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] HA prefix = HoA prefix? References: <16888.2098.511732.472518@gargle.gargle.HOWL> <41F8C846.50008@iprg.nokia.com> <420392D6.60103@motorola.com> In-Reply-To: <420392D6.60103@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Pete McCann X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Alex, it doesnt matter whether the check is restrictive or not. you can have your one-interface, non-default-router, HA implementation either way. Vijay Alexandru Petrescu wrote: > Vijay Devarapalli wrote: > >> it is actually a bit restrictive. > > > I find it not restricctive but allowing one-interface HAs > non-default-routers to exist. > >> our HA implementation does not do this check. > > > Ours does. > >> instead, it just checks if the HoA of the MN falls in one of the >> prefixes that the HA is configured to serve. > > > Ours doesn't. Our HA is a standalone one-interface machine, does not > serve a link's prefix, the link is served by a separate Gateway that is > the Default Router for that link. > >> RFC 3963 relaxes this requirement for Mobile Routers. a Mobile Router >> has an option of configuring its HoA from the Mobile Network Prefix >> (delegated to the Mobile Router for use in the Mobile Network). the >> Mobile Network Prefix can be different from the home prefix. > > > That's another issue. > > Alex > >> >> Vijay >> >> Pete McCann wrote: >> >>> Hi, >>> >>> My apologies if this question has been raised/answered here before. >>> >>> >>> Given the following text in RFC 3775, section 6.1.7: >>> >>> >>>> Home Registration (H) >>>> >>>> The Home Registration (H) bit is set by the sending mobile node >>>> to request that the receiving node should act as this node's home >>>> agent. The destination of the packet carrying this message MUST >>>> be that of a router sharing the same subnet prefix as the home >>>> address of the mobile node in the binding. >>> >>> >>> >>> >>> does this imply that the HA address (the destination of the packet) >>> must share the same prefix with the home address? >>> >>> A possible alternative interpretation is that the router must have >>> some interface on the home link but this is not necessarily used as >>> the the destination of the packet. >>> >>> Thoughts? >>> >>> -Pete >>> >>> >>> _______________________________________________ Mip6 mailing list >>> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >> >> >> >> >> _______________________________________________ Mip6 mailing list >> Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 02:32:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01205 for ; Mon, 7 Feb 2005 02:32:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy3hc-0000r6-Ba for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 02:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3M0-0005PY-T2; Mon, 07 Feb 2005 02:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3Kk-000561-Ij for mip6@megatron.ietf.org; Mon, 07 Feb 2005 02:29:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01012 for ; Mon, 7 Feb 2005 02:29:21 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy3e6-0000mi-7n for mip6@ietf.org; Mon, 07 Feb 2005 02:49:22 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j177xMm12286; Sun, 6 Feb 2005 23:59:22 -0800 X-mProtect: <200502070759> Nokia Silicon Valley Messaging Protection Received: from danira-pool05416.americas.nokia.com (10.241.54.16, claiming to be "[10.241.54.16]") by darkstar.iprg.nokia.com smtpds2Kqdi; Sun, 06 Feb 2005 23:59:20 PST Message-ID: <420718A2.9020104@iprg.nokia.com> Date: Sun, 06 Feb 2005 23:28:34 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] HA prefix = HoA prefix? References: <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> <4203FBB3.6020101@motorola.com> In-Reply-To: <4203FBB3.6020101@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Alex, Alexandru Petrescu wrote: > Vijay, if the implementation checks the HoA be in the prefix "served" by > the HA, then will the implementation work when the HA does not "serve" > the prefix? when the HA receieves a BU from the MN, it checks if the HoA in the BU belongs to one of the prefixes that the HA serves (ofcourse it performs lot more checks). if the check fails, the HA sends a binding ack with status 132. > MUST that particular implementation be configured to > "serve" the Home Network prefix in order to be able to have MIP6 tunnels > to MHs? Where is this checking more exactly? In the NC? In the > routing table? depends on your implementation. how do you implement binding ack status value 132? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 03:51:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06882 for ; Mon, 7 Feb 2005 03:51:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy4vG-0002c6-9X for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 04:11:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy4Sg-0006Dg-9n; Mon, 07 Feb 2005 03:41:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy4Qz-0005oL-EK for mip6@megatron.ietf.org; Mon, 07 Feb 2005 03:39:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06131 for ; Mon, 7 Feb 2005 03:39:50 -0500 (EST) Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy4kI-0002FV-KM for mip6@ietf.org; Mon, 07 Feb 2005 03:59:53 -0500 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 <0IBJ00EGD9F039@szxga01-in.huawei.com> for mip6@ietf.org; Mon, 07 Feb 2005 16:40:12 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IBJ0026B9F049@szxga01-in.huawei.com> for mip6@ietf.org; Mon, 07 Feb 2005 16:40:12 +0800 (CST) Received: from htipl80103 ([10.18.4.242]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IBJ008G39FY9N@szxml02-in.huawei.com>; Mon, 07 Feb 2005 16:40:48 +0800 (CST) Date: Mon, 07 Feb 2005 14:08:51 +0530 From: suraj Subject: RE: [Mip6] HA prefix = HoA prefix? In-reply-to: <420718A2.9020104@iprg.nokia.com> To: "'Vijay Devarapalli'" , "'Alexandru Petrescu'" Message-id: <000001c50cf0$743f5880$f204120a@in.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: b058151374d77ee76edaac850f7449fb Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: surajs@huawei.com List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1787778587==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 441f623df000f14368137198649cb083 This is a multi-part message in MIME format. --===============1787778587== Content-type: multipart/alternative; boundary="Boundary_(ID_3QT9ScEEmQK94ll8YIlFIQ)" This is a multi-part message in MIME format. --Boundary_(ID_3QT9ScEEmQK94ll8YIlFIQ) Content-type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Hi, Sorry for bringing a different aspect into this discussion. But I suppose the following section of the RFC also talks about the same problem. 10.6. Sending Prefix Information to the Mobile Node 10.6.1. List of Home Network Prefixes .... If there are multiple home agents, differences in the advertisements sent by different home agents can lead to an inability to use a particular home address when changing to another home agent. " In order to ensure that the mobile nodes get the same information from different home agents, it is preferred that all of the home agents on the same link be configured in the same manner". Such a configuration, in a way obviates the condition of a Home Address (MN) getting a Home Agent address which is not able to serve the Home Address Prefix, unless it is statically configured at the MN. Any comments? Regards, Suraj. -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Vijay Devarapalli Sent: Monday, February 07, 2005 12:59 PM To: Alexandru Petrescu Cc: mip6@ietf.org Subject: Re: [Mip6] HA prefix = HoA prefix? Alex, Alexandru Petrescu wrote: > Vijay, if the implementation checks the HoA be in the prefix "served" by > the HA, then will the implementation work when the HA does not "serve" > the prefix? when the HA receieves a BU from the MN, it checks if the HoA in the BU belongs to one of the prefixes that the HA serves (ofcourse it performs lot more checks). if the check fails, the HA sends a binding ack with status 132. > MUST that particular implementation be configured to > "serve" the Home Network prefix in order to be able to have MIP6 tunnels > to MHs? Where is this checking more exactly? In the NC? In the > routing table? depends on your implementation. how do you implement binding ack status value 132? Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --Boundary_(ID_3QT9ScEEmQK94ll8YIlFIQ) Content-type: text/html; charset=us-ascii Content-Transfer-Encoding: 7BIT

Hi,

 

Sorry for bringing a different aspect into this discussion. But I suppose the following section of the RFC also talks about the same problem.

 

10.6.  Sending Prefix Information to the Mobile Node

 

10.6.1.  List of Home Network Prefixes

 

      ....

 

   If there are multiple home agents, differences in the advertisements

   sent by different home agents can lead to an inability to use a

   particular home address when changing to another home agent. “ In

   order to ensure that the mobile nodes get the same information from

   different home agents, it is preferred that all of the home agents on

   the same link be configured in the same manner”.

 

 

Such a configuration, in a way obviates the condition of a Home Address (MN) getting a Home Agent address which is not able to serve the Home Address Prefix, unless it is statically configured at the MN.

 

Any comments?

 

Regards,

Suraj.

 

-----Original Message-----
From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of Vijay Devarapalli
Sent: Monday, February 07, 2005 12:59 PM
To: Alexandru Petrescu
Cc: mip6@ietf.org
Subject: Re: [Mip6] HA prefix = HoA prefix?

 

Alex,

 

Alexandru Petrescu wrote:

 

> Vijay, if the implementation checks the HoA be in the prefix "served" by

>  the HA, then will the implementation work when the HA does not "serve"

> the prefix? 

 

when the HA receieves a BU from the MN, it checks if the

HoA in the BU belongs to one of the prefixes that the HA

serves (ofcourse it performs lot more checks). if the

check fails, the HA sends a binding ack with status 132.

 

> MUST that particular implementation be configured to

> "serve" the Home Network prefix in order to be able to have MIP6 tunnels

> to MHs?  Where is this checking more exactly?  In the NC?  In the

> routing table?

 

depends on your implementation. how do you implement

binding ack status value 132?

 

Vijay

 

_______________________________________________

Mip6 mailing list

Mip6@ietf.org

https://www1.ietf.org/mailman/listinfo/mip6

--Boundary_(ID_3QT9ScEEmQK94ll8YIlFIQ)-- --===============1787778587== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1787778587==-- From mip6-bounces@ietf.org Mon Feb 7 06:13:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16469 for ; Mon, 7 Feb 2005 06:13:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy78c-0005VL-Kl for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 06:33:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy6np-0008BU-9M; Mon, 07 Feb 2005 06:11:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy6eq-0006jp-Kz for mip6@megatron.ietf.org; Mon, 07 Feb 2005 06:02:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15914 for ; Mon, 7 Feb 2005 06:02:17 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy6yD-0005KJ-6b for mip6@ietf.org; Mon, 07 Feb 2005 06:22:22 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j17B5OMa019394; Mon, 7 Feb 2005 04:05:24 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j17B2OHI027456; Mon, 7 Feb 2005 05:02:25 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3CE1686602B; Mon, 7 Feb 2005 12:02:15 +0100 (CET) Message-ID: <42074AB0.5090306@motorola.com> Date: Mon, 07 Feb 2005 12:02:08 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] HA prefix = HoA prefix? References: <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> <4203FBB3.6020101@motorola.com> <420718A2.9020104@iprg.nokia.com> In-Reply-To: <420718A2.9020104@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0185170006==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0185170006== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7168016C76AD767F2BFC76F3" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7168016C76AD767F2BFC76F3 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > Alex, > > Alexandru Petrescu wrote: > >> Vijay, if the implementation checks the HoA be in the prefix "served" >> by the HA, then will the implementation work when the HA does not >> "serve" the prefix? > > > when the HA receieves a BU from the MN, it checks if the > HoA in the BU belongs to one of the prefixes that the HA > serves (ofcourse it performs lot more checks). if the > check fails, the HA sends a binding ack with status 132. Ok, status 132 if HoA not in the prefix that the HA serves. So I was wondering what does it mean that the HA serves a certain prefix. Is it that it has entries for that prefix in the routing table? How is it actually checking: first-come first-served or longest match? >> MUST that particular implementation be configured to "serve" the Home >> Network prefix in order to be able to have MIP6 tunnels to MHs? Where >> is this checking more exactly? In the NC? In the routing table? > > depends on your implementation. how do you implement > binding ack status value 132? I don't think I do... Alex --------------enig7168016C76AD767F2BFC76F3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCB0q3MmC0w56zj54RAoi9AJ0Q3AAl0J5zX3rxXjAWrnzI9lzTqwCg1nf+ WsyQPKOo4YlFC52yLXmtRFo= =bkUi -----END PGP SIGNATURE----- --------------enig7168016C76AD767F2BFC76F3-- --===============0185170006== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0185170006==-- From mip6-bounces@ietf.org Mon Feb 7 12:25:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19598 for ; Mon, 7 Feb 2005 12:25:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyCxJ-0005sh-K6 for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 12:45:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyCTc-0000cs-DG; Mon, 07 Feb 2005 12:15:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyCPs-0007Ng-2N for mip6@megatron.ietf.org; Mon, 07 Feb 2005 12:11:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17806 for ; Mon, 7 Feb 2005 12:11:12 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyCjI-0005Sh-Lf for mip6@ietf.org; Mon, 07 Feb 2005 12:31:21 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 07 Feb 2005 09:10:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from alpeshw2k03 (sjc-vpn7-284.cisco.com [10.21.145.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j17HAfYO023783; Mon, 7 Feb 2005 09:10:42 -0800 (PST) Message-Id: <200502071710.j17HAfYO023783@sj-core-4.cisco.com> From: "Alpesh" To: "'Vijay Devarapalli'" Subject: RE: [Mip6] HA prefix = HoA prefix? Date: Mon, 7 Feb 2005 09:10:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUM5cRHAq7DcVYzQS2XvspDhgAF2QAUiOOw In-Reply-To: <42071710.8000102@iprg.nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Content-Transfer-Encoding: 7bit Vijay: All the prefixes on router? -a > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Sunday, February 06, 2005 11:22 PM > To: Alpesh > Cc: 'Wing Cheong Lau'; mip6@ietf.org > Subject: Re: [Mip6] HA prefix = HoA prefix? > > Alpesh wrote: > > Lau: > > > > Support for "virtual homes" can be done in various ways. I > don't see a > > strong reason to remove this aspect from the spec.. > > > > Plus, what happens to the "DHAAD mechanism" mechanism? > > nothing. > > the MN still constructs the DHAAD anycast address from the > home prefix and send the DHAAD request to the DHAAD anycast address. > and it gets a DHAAD reply with a list of Home Agents that > service the home prefix. > > Vijay > > > > > -a > > > > > >>-----Original Message----- > >>From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] > On Behalf > >>Of Wing Cheong Lau > >>Sent: Friday, February 04, 2005 8:50 AM > >>To: mip6@ietf.org > >>Subject: Re: [Mip6] HA prefix = HoA prefix? > >> > >> > >> > >>>Date: Fri, 04 Feb 2005 08:47:37 -0800 > >>>To: Alexandru Petrescu > >>>From: Wing Cheong Lau > >>>Subject: Re: [Mip6] HA prefix = HoA prefix? > >>> > >>>At 07:20 AM 2/4/2005, you wrote: > >>> > >>>>Vijay Devarapalli wrote: > >>>> > >>>>>it is actually a bit restrictive. > >>>> > >>>>I find it not restricctive but allowing one-interface HAs > >>>>non-default-routers to exist. > >> > >> > >>Dear Alex, > >> > >>Removing the "HA prefix = HoA prefix" restriction would > only make the > >>system more flexible, e.g. allowing virtual home-links for > which the > >>MS never returns home. > >> > >>It would not preclude your case of a one-interface HAs > >>non-default-routers, right ? > >> > >>Or am I missing something here ? > >> > >>Regards, > >> > >>Wing > >> > >> > >> > >>>>>our HA implementation does not do this check. > >>>> > >>>>Ours does. > >>>> > >>>> > >>>>>instead, it just checks if the HoA of the MN falls in one of the > >>>>>prefixes that the HA is configured to serve. > >>>> > >>>>Ours doesn't. Our HA is a standalone one-interface > >> > >>machine, does not > >> > >>>>serve a link's prefix, the link is served by a separate > >> > >>Gateway that > >> > >>>>is the Default Router for that link. > >>>> > >>>> > >>>>>RFC 3963 relaxes this requirement for Mobile Routers. a > >> > >>Mobile Router > >> > >>>>>has an option of configuring its HoA from the Mobile > >> > >>Network Prefix > >> > >>>>>(delegated to the Mobile Router for use in the Mobile > >> > >>Network). the > >> > >>>>>Mobile Network Prefix can be different from the home prefix. > >>>> > >>>>That's another issue. > >>>> > >>>>Alex > >>>> > >>>> > >>>>>Vijay > >>>>>Pete McCann wrote: > >>>>> > >>>>> > >>>>>>Hi, > >>>>>>My apologies if this question has been raised/answered > >> > >>here before. > >> > >>>>>>Given the following text in RFC 3775, section 6.1.7: > >>>>>> > >>>>>> > >>>>>>>Home Registration (H) > >>>>>>>The Home Registration (H) bit is set by the sending > >> > >>mobile node to > >> > >>>>>>>request that the receiving node should act as this > node's home > >>>>>>>agent. The destination of the packet carrying this > >> > >>message MUST > >> > >>>>>>> be that of a router sharing the same subnet prefix as > >> > >>the home > >> > >>>>>>>address of the mobile node in the binding. > >>>>>> > >>>>>>does this imply that the HA address (the destination of > >> > >>the packet) > >> > >>>>>> must share the same prefix with the home address? > >>>>>>A possible alternative interpretation is that the router > >> > >>must have > >> > >>>>>>some interface on the home link but this is not > >> > >>necessarily used as > >> > >>>>>> the the destination of the packet. > >>>>>>Thoughts? > >>>>>>-Pete > >>>>>> > >>>>>>_______________________________________________ Mip6 > mailing list > >>>>>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >>>>> > >>>>>_______________________________________________ Mip6 > mailing list > >>>>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 > >>>> > >>>> > >>>> > >>>> > >>>>_______________________________________________ > >>>>Mip6 mailing list > >>>>Mip6@ietf.org > >>>>https://www1.ietf.org/mailman/listinfo/mip6 > >> > >> > >>_______________________________________________ > >>Mip6 mailing list > >>Mip6@ietf.org > >>https://www1.ietf.org/mailman/listinfo/mip6 > >> > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 13:18:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26108 for ; Mon, 7 Feb 2005 13:18:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDmq-0007J4-5w for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 13:39:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDNK-0005rb-GJ; Mon, 07 Feb 2005 13:12:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDGB-0004HN-Rz for mip6@megatron.ietf.org; Mon, 07 Feb 2005 13:05:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24854 for ; Mon, 7 Feb 2005 13:05:16 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDZc-0006z0-24 for mip6@ietf.org; Mon, 07 Feb 2005 13:25:25 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j17IZEX09749; Mon, 7 Feb 2005 10:35:14 -0800 X-mProtect: <200502071835> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141206.americas.nokia.com (172.18.141.206, claiming to be "[172.18.141.206]") by darkstar.iprg.nokia.com smtpdEtNza4; Mon, 07 Feb 2005 10:35:11 PST Message-ID: <4207ADAB.9010906@iprg.nokia.com> Date: Mon, 07 Feb 2005 10:04:27 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alpesh Subject: Re: [Mip6] HA prefix = HoA prefix? References: <200502071710.j17HAfYO023783@sj-core-4.cisco.com> In-Reply-To: <200502071710.j17HAfYO023783@sj-core-4.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 Content-Transfer-Encoding: 7bit Alpesh wrote: > Vijay: > > All the prefixes on router? I am not sure I understand. DHAAD reply contains Home Agents addresses. the DHAAD reply will only include those Home Agents that serve the prefix the MN sent a request for. the same prefix based on which the MN derived the DHAAD anycast address. Vijay > > -a > > >>-----Original Message----- >>From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] >>Sent: Sunday, February 06, 2005 11:22 PM >>To: Alpesh >>Cc: 'Wing Cheong Lau'; mip6@ietf.org >>Subject: Re: [Mip6] HA prefix = HoA prefix? >> >>Alpesh wrote: >> >>>Lau: >>> >>>Support for "virtual homes" can be done in various ways. I >> >>don't see a >> >>>strong reason to remove this aspect from the spec.. >>> >>>Plus, what happens to the "DHAAD mechanism" mechanism? >> >>nothing. >> >>the MN still constructs the DHAAD anycast address from the >>home prefix and send the DHAAD request to the DHAAD anycast address. >>and it gets a DHAAD reply with a list of Home Agents that >>service the home prefix. >> >>Vijay >> >> >>>-a >>> >>> >>> >>>>-----Original Message----- >>>>From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] >> >>On Behalf >> >>>>Of Wing Cheong Lau >>>>Sent: Friday, February 04, 2005 8:50 AM >>>>To: mip6@ietf.org >>>>Subject: Re: [Mip6] HA prefix = HoA prefix? >>>> >>>> >>>> >>>> >>>>>Date: Fri, 04 Feb 2005 08:47:37 -0800 >>>>>To: Alexandru Petrescu >>>>>From: Wing Cheong Lau >>>>>Subject: Re: [Mip6] HA prefix = HoA prefix? >>>>> >>>>>At 07:20 AM 2/4/2005, you wrote: >>>>> >>>>> >>>>>>Vijay Devarapalli wrote: >>>>>> >>>>>> >>>>>>>it is actually a bit restrictive. >>>>>> >>>>>>I find it not restricctive but allowing one-interface HAs >>>>>>non-default-routers to exist. >>>> >>>> >>>>Dear Alex, >>>> >>>>Removing the "HA prefix = HoA prefix" restriction would >> >>only make the >> >>>>system more flexible, e.g. allowing virtual home-links for >> >>which the >> >>>>MS never returns home. >>>> >>>>It would not preclude your case of a one-interface HAs >>>>non-default-routers, right ? >>>> >>>>Or am I missing something here ? >>>> >>>>Regards, >>>> >>>>Wing >>>> >>>> >>>> >>>> >>>>>>>our HA implementation does not do this check. >>>>>> >>>>>>Ours does. >>>>>> >>>>>> >>>>>> >>>>>>>instead, it just checks if the HoA of the MN falls in one of the >>>>>>>prefixes that the HA is configured to serve. >>>>>> >>>>>>Ours doesn't. Our HA is a standalone one-interface >>>> >>>>machine, does not >>>> >>>> >>>>>>serve a link's prefix, the link is served by a separate >>>> >>>>Gateway that >>>> >>>> >>>>>>is the Default Router for that link. >>>>>> >>>>>> >>>>>> >>>>>>>RFC 3963 relaxes this requirement for Mobile Routers. a >>>> >>>>Mobile Router >>>> >>>> >>>>>>>has an option of configuring its HoA from the Mobile >>>> >>>>Network Prefix >>>> >>>> >>>>>>>(delegated to the Mobile Router for use in the Mobile >>>> >>>>Network). the >>>> >>>> >>>>>>>Mobile Network Prefix can be different from the home prefix. >>>>>> >>>>>>That's another issue. >>>>>> >>>>>>Alex >>>>>> >>>>>> >>>>>> >>>>>>>Vijay >>>>>>>Pete McCann wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>>Hi, >>>>>>>>My apologies if this question has been raised/answered >>>> >>>>here before. >>>> >>>> >>>>>>>>Given the following text in RFC 3775, section 6.1.7: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>Home Registration (H) >>>>>>>>>The Home Registration (H) bit is set by the sending >>>> >>>>mobile node to >>>> >>>> >>>>>>>>>request that the receiving node should act as this >> >>node's home >> >>>>>>>>>agent. The destination of the packet carrying this >>>> >>>>message MUST >>>> >>>> >>>>>>>>>be that of a router sharing the same subnet prefix as >>>> >>>>the home >>>> >>>> >>>>>>>>>address of the mobile node in the binding. >>>>>>>> >>>>>>>>does this imply that the HA address (the destination of >>>> >>>>the packet) >>>> >>>> >>>>>>>>must share the same prefix with the home address? >>>>>>>>A possible alternative interpretation is that the router >>>> >>>>must have >>>> >>>> >>>>>>>>some interface on the home link but this is not >>>> >>>>necessarily used as >>>> >>>> >>>>>>>>the the destination of the packet. >>>>>>>>Thoughts? >>>>>>>>-Pete >>>>>>>> >>>>>>>>_______________________________________________ Mip6 >> >>mailing list >> >>>>>>>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >>>>>>> >>>>>>>_______________________________________________ Mip6 >> >>mailing list >> >>>>>>>Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>_______________________________________________ >>>>>>Mip6 mailing list >>>>>>Mip6@ietf.org >>>>>>https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>>> >>>>_______________________________________________ >>>>Mip6 mailing list >>>>Mip6@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/mip6 >>>> >>> >>> >>>_______________________________________________ >>>Mip6 mailing list >>>Mip6@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mip6 >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 13:20:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26287 for ; Mon, 7 Feb 2005 13:20:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDoN-0007Lv-Qx for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 13:40:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDQD-0006OD-Hy; Mon, 07 Feb 2005 13:15:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDLp-0005iz-Ae for mip6@megatron.ietf.org; Mon, 07 Feb 2005 13:11:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25426 for ; Mon, 7 Feb 2005 13:11:05 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDfF-000789-Iv for mip6@ietf.org; Mon, 07 Feb 2005 13:31:15 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j17Ieha16150; Mon, 7 Feb 2005 10:40:43 -0800 X-mProtect: <200502071840> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141206.americas.nokia.com (172.18.141.206, claiming to be "[172.18.141.206]") by darkstar.iprg.nokia.com smtpd91FvMT; Mon, 07 Feb 2005 10:40:34 PST Message-ID: <4207AEEE.5030801@iprg.nokia.com> Date: Mon, 07 Feb 2005 10:09:50 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: surajs@huawei.com Subject: Re: [Mip6] HA prefix = HoA prefix? References: <000001c50cf0$743f5880$f204120a@in.huawei.com> In-Reply-To: <000001c50cf0$743f5880$f204120a@in.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 8bit Cc: mip6@ietf.org, "'Alexandru Petrescu'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 8bit Suraj, suraj wrote: > 10.6. Sending Prefix Information to the Mobile Node > 10.6.1. List of Home Network Prefixes > If there are multiple home agents, differences in the advertisements > > sent by different home agents can lead to an inability to use a > > particular home address when changing to another home agent.*  In* > > * order to ensure that the mobile nodes get the same information from* > > * different home agents, it is preferred that all of the home agents on* > > * _the same link be configured in the same manner_.* > > Such a configuration, in a way obviates the condition of a Home Address > (MN) getting a Home Agent address which is not able to serve the Home > Address Prefix, unless it is statically configured at the MN. there are many reasons why the MN might end up with the wrong HA. configuration mistakes is one of them. different deployments might use different bootstrapping mechanisms. a non-IETF standardized mechanism might be used in a certain deployment. binding ack status 132 should enable the MN to recover in such cases. Vijay > > > > Any comments? > > > > Regards, > > Suraj. > > > > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On Behalf Of > Vijay Devarapalli > Sent: Monday, February 07, 2005 12:59 PM > To: Alexandru Petrescu > Cc: mip6@ietf.org > Subject: Re: [Mip6] HA prefix = HoA prefix? > > > > Alex, > > > > Alexandru Petrescu wrote: > > > >> Vijay, if the implementation checks the HoA be in the prefix "served" by > >> the HA, then will the implementation work when the HA does not "serve" > >> the prefix? > > > > when the HA receieves a BU from the MN, it checks if the > > HoA in the BU belongs to one of the prefixes that the HA > > serves (ofcourse it performs lot more checks). if the > > check fails, the HA sends a binding ack with status 132. > > > >> MUST that particular implementation be configured to > >> "serve" the Home Network prefix in order to be able to have MIP6 tunnels > >> to MHs? Where is this checking more exactly? In the NC? In the > >> routing table? > > > > depends on your implementation. how do you implement > > binding ack status value 132? > > > > Vijay > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 13:29:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27084 for ; Mon, 7 Feb 2005 13:29:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDxQ-0007Y2-T0 for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 13:50:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDVr-0007Oo-Mk; Mon, 07 Feb 2005 13:21:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDSf-0006fh-Ln for mip6@megatron.ietf.org; Mon, 07 Feb 2005 13:18:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26070 for ; Mon, 7 Feb 2005 13:18:10 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDm5-0007Hj-Tb for mip6@ietf.org; Mon, 07 Feb 2005 13:38:19 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j17ImB724250; Mon, 7 Feb 2005 10:48:11 -0800 X-mProtect: <200502071848> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141206.americas.nokia.com (172.18.141.206, claiming to be "[172.18.141.206]") by darkstar.iprg.nokia.com smtpdCjAdMV; Mon, 07 Feb 2005 10:48:08 PST Message-ID: <4207B0B4.3010906@iprg.nokia.com> Date: Mon, 07 Feb 2005 10:17:24 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [Mip6] HA prefix = HoA prefix? References: <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> <4203FBB3.6020101@motorola.com> <420718A2.9020104@iprg.nokia.com> <42074AB0.5090306@motorola.com> In-Reply-To: <42074AB0.5090306@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: >>> Vijay, if the implementation checks the HoA be in the prefix "served" >>> by the HA, then will the implementation work when the HA does not >>> "serve" the prefix? >> >> >> >> when the HA receieves a BU from the MN, it checks if the >> HoA in the BU belongs to one of the prefixes that the HA >> serves (ofcourse it performs lot more checks). if the >> check fails, the HA sends a binding ack with status 132. > > > Ok, status 132 if HoA not in the prefix that the HA serves. So I was > wondering what does it mean that the HA serves a certain prefix. Is it > that it has entries for that prefix in the routing table? How is it > actually checking: first-come first-served or longest match? again, it is implementation specific. you can have a configuration file on the HA which says what prefixes it is supposed to serve. you can have a flag in your _ifnet_ structure which says the interface is configured with a prefix that is a home link for some mobile nodes. >>> MUST that particular implementation be configured to "serve" the Home >>> Network prefix in order to be able to have MIP6 tunnels to MHs? >>> Where is this checking more exactly? In the NC? In the routing table? >> >> >> depends on your implementation. how do you implement >> binding ack status value 132? > > > I don't think I do... dont you think you should implement it? Vijay > > Alex > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 13:38:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27978 for ; Mon, 7 Feb 2005 13:38:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyE5b-0007lF-2k for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 13:58:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDey-0000gD-Vt; Mon, 07 Feb 2005 13:30:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyDca-00008y-1k for mip6@megatron.ietf.org; Mon, 07 Feb 2005 13:28:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26976 for ; Mon, 7 Feb 2005 13:28:24 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyDw0-0007X2-Gz for mip6@ietf.org; Mon, 07 Feb 2005 13:48:33 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j17ISE715933; Mon, 7 Feb 2005 20:28:14 +0200 (EET) X-Scanned: Mon, 7 Feb 2005 20:28:08 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j17IS8Se008688; Mon, 7 Feb 2005 20:28:08 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00yAYDDa; Mon, 07 Feb 2005 20:27:31 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j17IRUU09411; Mon, 7 Feb 2005 20:27:30 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 7 Feb 2005 12:26:22 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] MIP6 Mobile Node ( MN) available Date: Mon, 7 Feb 2005 12:26:19 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C79D@daebe101.NOE.Nokia.com> Thread-Topic: [Mip6] MIP6 Mobile Node ( MN) available Thread-Index: AcUKvx51QnKB/UkjRKS7THqiRJ6SAACgvF8w To: , X-OriginalArrivalTime: 07 Feb 2005 18:26:22.0969 (UTC) FILETIME=[86C07690:01C50D42] X-Spam-Score: 0.5 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0659944747==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 This is a multi-part message in MIME format. --===============0659944747== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50D42.8685BF01" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50D42.8685BF01 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIP6 Mobile node has been implemented and tested on Series40 and = Series60 Symbian terminals. There was a press release about this at the 3G World Congress in Hong = Kong ( http://www.theregister.co.uk/2004/11/18/nokia_ipv6_mobile/) =20 Note that the MIP6 capability is not a standard feature or functionality = that is included in the current S40/60 terminals. =20 -Basavaraj =20 -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On Behalf Of = ext keshav Sent: Friday, February 04, 2005 3:56 AM To: mip6@ietf.org Subject: [Mip6] MIP6 Mobile Node ( MN) available Hi, Any MN is available with MIP6 support? (Of course other than Linux support) =20 Regards, Keshava ------_=_NextPart_001_01C50D42.8685BF01 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
MIP6=20 Mobile node has been implemented and tested on Series40 and=20 Series60 Symbian terminals.
There=20 was a press release about this at the 3G World Congress in Hong=20 Kong
(http:= //www.theregister.co.uk/2004/11/18/nokia_ipv6_mobile/)<= /DIV>
 
Note=20 that the MIP6 capability is not a standard feature or functionality that = is=20 included in the
current S40/60 terminals.
 
-Basavaraj
 
-----Original Message-----
From: = mip6-bounces@ietf.org=20 [mailto:mip6-bounces@ietf.org]On Behalf Of ext = keshav
Sent:=20 Friday, February 04, 2005 3:56 AM
To:=20 mip6@ietf.org
Subject: [Mip6] MIP6 Mobile Node ( MN)=20 available

Hi,

Any MN is available with = MIP6=20 support?

(Of course other than = Linux=20 support)

 

Regards,

Keshava

------_=_NextPart_001_01C50D42.8685BF01-- --===============0659944747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0659944747==-- From mip6-bounces@ietf.org Mon Feb 7 17:16:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04804 for ; Mon, 7 Feb 2005 17:16:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHUa-0001IS-5J for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 17:36:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGRb-0001ff-5Y; Mon, 07 Feb 2005 16:29:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGGX-0008SG-E8 for mip6@megatron.ietf.org; Mon, 07 Feb 2005 16:17:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20180 for ; Mon, 7 Feb 2005 16:17:50 -0500 (EST) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyGZz-0004xK-Hv for mip6@ietf.org; Mon, 07 Feb 2005 16:38:00 -0500 Received: from MINDLAP2 (177-62.mam.umd.edu [129.2.177.62]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j17LHGOj002312 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 7 Feb 2005 16:17:19 -0500 (EST) Message-Id: <200502072117.j17LHGOj002312@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Mon, 7 Feb 2005 16:17:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Subject: [Mip6] CFP: IEEE WirelessCom Symposium on Mobile Computing, 2005 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Second Call for Papers Symposium on Mobile Computing http://www.csee.umbc.edu/~younis/WC_MobCom05.htm as part of IEEE WirelessCom 2005 Sheraton Maui Resort, Kaanapali Beach, Maui, Hawaii, USA http://www.ece.queensu.ca/hpages/faculty/safwat/wirelesscom/05/ June 13-16, 2005 Technical Sponsorship: IEEE TCCC, TCPC, and SSCTC Recent years have witnessed an enormous growth in the development and applications of mobile computing environments and devices. Many practitioners envision a future empowered with context and location aware computation and communication infrastructure that allow users to access data and receive service at any place and any time. Compared to conventional platforms, the mobility of computing nodes introduces many challenges to the design of almost all systems components. This symposium will foster a forum for discussing and presenting recent research results on mobile computer systems. Original papers are invited in the broader area of mobile computing. Papers must report high-quality and previously unpublished work. Topics of interest include, but are not limited to, the following: - Architecture and infrastructure support - Middleware and operating systems services - Development platforms and environments - Adaptive resource management schemes - Pervasive and Context-aware Computing - Performance metrics and studies - Power aware computation and communication - Data consistency and synchronization protocols - Fault-tolerant architectural and operation models - Wearable computing devices and systems - Time constrained mobile systems - Robust ad-hoc networking techniques - Efficient localization techniques - Wireless sensor networks - Mobile peer to peer systems - Quality of service provisioning - Context-conscious computing - Web caching and services - Emerging applications and systems - Mobile agents - Mobile commerce - Security and privacy issues Submission Guidelines --------------------- Prospective authors should submit their paper electronically to younis@csee.umbc.edu. All papers are limited to 6 pages in MS-Word, PS or PDF using standard IEEE double-column format. The first page should include title, authors' contact information, an abstract and five keywords. Authors should attach the paper abstract to their message. Important Dates --------------- Paper Submission Deadline: March 15, 2005 Notification of Acceptance: April 15, 2005 Camera-Ready Papers: May 1, 2005 Symposium Co-Chairs ------------------- Mohamed Younis Department of Computer Science and Electrical Engineering University of Maryland Baltimore County, E-mail: younis@csee.umbc.edu Hesham El-Rewini Department of Computer Science and Engineering Southern Methodist University E-mail: rewini@engr.smu.edu Publicity Chair ---------------- Moustafa Youssef Department of Computer Science University of Maryland at College Park, E-mail: moustafa@cs.umd.edu _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 17:37:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07373 for ; Mon, 7 Feb 2005 17:37:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHpT-00023q-34 for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 17:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHFF-0003or-1n; Mon, 07 Feb 2005 17:20:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyGt0-0003yG-RP for mip6@megatron.ietf.org; Mon, 07 Feb 2005 16:57:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29796 for ; Mon, 7 Feb 2005 16:57:36 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHCS-00086o-Ta for mip6@ietf.org; Mon, 07 Feb 2005 17:17:46 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j17LvYHr027886; Tue, 8 Feb 2005 06:57:34 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j17LvXVu015600; Tue, 8 Feb 2005 06:57:33 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id GAA15598 ; Tue, 8 Feb 2005 06:57:33 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j17LvX8q011400; Tue, 8 Feb 2005 06:57:33 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j17LvWqc021709; Tue, 8 Feb 2005 06:57:32 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j17LvW8a004548; Tue, 8 Feb 2005 06:57:32 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IBK00AJDABQI1@tsbpo1.po.toshiba.co.jp>; Tue, 8 Feb 2005 06:57:29 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1CyG2a-00018T-00; Mon, 07 Feb 2005 13:03:28 -0800 Date: Mon, 07 Feb 2005 16:03:24 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <456943D540CFC14A8D7138E64843F85308C794@daebe101.NOE.Nokia.com> To: Basavaraj.Patil@nokia.com Message-id: <20050207210324.GM1002@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <456943D540CFC14A8D7138E64843F85308C794@daebe101.NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 On Fri, Feb 04, 2005 at 11:54:11AM -0600, Basavaraj.Patil@nokia.com wrote: > > The goals/reasons for a standardized interface between the HA and AAA > were discussed at IETF61 in Gerardo's I-D : > draft-giaretta-mip6-aaa-ha-goals-00.txt > Such an interface is required from the perspective of bootstrapping a > MN in operator owned network environments. > > We would like to make this I-D a working group document that captures > the goals and requirements for the interface between the HA and AAA > and is used as input in the design of the bootstrapping solution that > relies on AAA. I agree on making the I-D as a WG document, but I think the I-D needs to be revised in terms of Scenario 2. Scenario 2 would need more discussion, considering potential variations and complexity in integrating MIPv6 bootstrapping and network access authentication. Especially, I don't think there is a WG consensus as to whether piggybacking MIPv6 parameters in EAP, or carrying them in some other ways (using AAA protocol, EAP lower layer and/or DHCP), or both should be supported. Having said that, I think Scenario 2 should be described in most generic way at this moment, perhaps with integration of Figures 3 and 4 without mentioning piggybacking MIPv6 parameters in EAP, RADIUS or L2 specific extensions. Best regards, Yoshihiro Ohba > > Please comment if you do not agree to making this a WG document and > your reasons by Feb 10th, 05. > > -Basavaraj > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 17:48:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08526 for ; Mon, 7 Feb 2005 17:48:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHzp-0002NL-V8 for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 18:08:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHWg-0004Ar-21; Mon, 07 Feb 2005 17:38:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHNM-0000US-F4 for mip6@megatron.ietf.org; Mon, 07 Feb 2005 17:29:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06828 for ; Mon, 7 Feb 2005 17:28:57 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyHgo-0001u7-TK for mip6@ietf.org; Mon, 07 Feb 2005 17:49:08 -0500 Message-ID: <01b001c50d64$87601980$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Mon, 7 Feb 2005 14:29:39 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Mip6] HA Unavailability Alerting X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit In the context of the bootstrapping discussion, I've written a draft about how to inform a mobile node that its home agent is about to become unavailable, and therefore that the mobile node should look for a new home agent or otherwise perform bootstrapping if necessary. AFICT, there's no way to do this in RFC 3775. The draft is available at: http://www.geocities.com/kempf42/draft-kempf-mip6-ha-alert-00.txt until it shows up in the drafts repository. The draft proposes a minor modification to home agent discovery for this purpose, but it is meant to be more for discussion, as there are a couple of open questions posed. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 21:24:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29466 for ; Mon, 7 Feb 2005 21:24:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyLMf-0007cj-HD for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 21:44:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyL1h-0003PH-4J; Mon, 07 Feb 2005 21:22:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyL0f-0003FZ-T6 for mip6@megatron.ietf.org; Mon, 07 Feb 2005 21:21:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29302 for ; Mon, 7 Feb 2005 21:21:47 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyLKA-0007Zi-Kp for mip6@ietf.org; Mon, 07 Feb 2005 21:42:00 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j182pgT28589; Mon, 7 Feb 2005 18:51:42 -0800 X-mProtect: <200502080251> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141206.americas.nokia.com (172.18.141.206, claiming to be "[172.18.141.206]") by darkstar.iprg.nokia.com smtpdVp3iXZ; Mon, 07 Feb 2005 18:51:39 PST Message-ID: <42082208.80302@iprg.nokia.com> Date: Mon, 07 Feb 2005 18:20:56 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] HA Unavailability Alerting References: <01b001c50d64$87601980$016115ac@dcml.docomolabsusa.com> In-Reply-To: <01b001c50d64$87601980$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Jim, the HAHA protocol already defines such a message, "Home Agent Switch Request". http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-spec-00.txt the HA can send this message to MN to indicate to the MN that it should perform DHAAD again and pick another Home Agent. the message MAY also contain another Home Agent's address. Vijay James Kempf wrote: > In the context of the bootstrapping discussion, I've written a draft about > how to inform a mobile node that its home agent is about to become > unavailable, and therefore that the mobile node should look for a new home > agent or otherwise perform bootstrapping if necessary. AFICT, there's no way > to do this in RFC 3775. The draft is available at: > > http://www.geocities.com/kempf42/draft-kempf-mip6-ha-alert-00.txt > > until it shows up in the drafts repository. The draft proposes a minor > modification to home agent discovery for this purpose, but it is meant to be > more for discussion, as there are a couple of open questions posed. > > jak > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 21:49:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01777 for ; Mon, 7 Feb 2005 21:49:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyLl4-00089x-E1 for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 22:09:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyLP9-00089W-SW; Mon, 07 Feb 2005 21:47:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyLLO-0007LA-Dm for mip6@megatron.ietf.org; Mon, 07 Feb 2005 21:43:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01209 for ; Mon, 7 Feb 2005 21:43:12 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CyLes-00081l-Mv for mip6@ietf.org; Mon, 07 Feb 2005 22:03:24 -0500 Received: (qmail 19998 invoked by uid 104); 8 Feb 2005 02:42:33 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 12.514982 secs); 08 Feb 2005 02:42:33 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk1110783054051119902 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 12.514982 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-97.7 required=7.0 tests=AWL, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 8 Feb 2005 02:42:19 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Feb 2005 10:40:47 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] HA Unavailability Alerting content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 8 Feb 2005 10:40:45 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA38590F0C@hcbjdc2> Thread-Topic: [Mip6] HA Unavailability Alerting Thread-Index: AcUNhcqACUw20onyRmS1tNb7kvNCNAAAV9Sg From: "DENG, HUI -HCHIBJ" To: "Vijay Devarapalli" , "James Kempf" X-OriginalArrivalTime: 08 Feb 2005 02:40:47.0250 (UTC) FILETIME=[980A8720:01C50D87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Vijay and Jim We also already defined this message in our draft long time ago. and clearly mentioned that it will be used during home agent will = shortly become unavailable http://www.ietf.org/internet-drafts/draft-deng-mip6-ha-loadbalance-02.txt= Thanks for your checking -Hui -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20 Sent: 2005?2?8? 10:21 To: James Kempf Cc: mip6@ietf.org Subject: Re: [Mip6] HA Unavailability Alerting Jim, the HAHA protocol already defines such a message, "Home Agent Switch = Request".=20 http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-spec-00= .txt the HA can send this message to MN to indicate to the MN that it should = perform DHAAD again and pick another Home Agent. the message MAY also = contain another Home Agent's address. Vijay James Kempf wrote: > In the context of the bootstrapping discussion, I've written a draft=20 > about how to inform a mobile node that its home agent is about to=20 > become unavailable, and therefore that the mobile node should look for = > a new home agent or otherwise perform bootstrapping if necessary.=20 > AFICT, there's no way to do this in RFC 3775. The draft is available=20 > at: >=20 > http://www.geocities.com/kempf42/draft-kempf-mip6-ha-alert-00.txt >=20 > until it shows up in the drafts repository. The draft proposes a minor = > modification to home agent discovery for this purpose, but it is meant = > to be more for discussion, as there are a couple of open questions=20 > posed. >=20 > jak >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 21:58:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02481 for ; Mon, 7 Feb 2005 21:58:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyLtK-0008LE-5o for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 22:18:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyLVT-0000rS-SS; Mon, 07 Feb 2005 21:53:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyLSJ-0000EC-An for mip6@megatron.ietf.org; Mon, 07 Feb 2005 21:50:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01829 for ; Mon, 7 Feb 2005 21:50:20 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyLlo-0008Ay-8b for mip6@ietf.org; Mon, 07 Feb 2005 22:10:33 -0500 Message-ID: <003a01c50d89$1346b9d0$5c6015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" References: <01b001c50d64$87601980$016115ac@dcml.docomolabsusa.com> <42082208.80302@iprg.nokia.com> Subject: Re: [Mip6] HA Unavailability Alerting Date: Mon, 7 Feb 2005 18:51:18 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Hi Vijay, Thanx for the reference. HAHA seems to cover a lot of ground, I think it would be more useful to have a discussion focussing on just this specific issue. I'm not tied to any particular way to solve the problem (even the one I suggested), but I think the problem should be solved specifically in the context of bootstrapping, even though "home agent reliability" is in the charter and HAHA would presumably cover that. jak ----- Original Message ----- From: "Vijay Devarapalli" To: "James Kempf" Cc: Sent: Monday, February 07, 2005 6:20 PM Subject: Re: [Mip6] HA Unavailability Alerting > Jim, > > the HAHA protocol already defines such a message, "Home Agent > Switch Request". > http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-spec-00.txt > the HA can send this message to MN to indicate to the MN that > it should perform DHAAD again and pick another Home Agent. > the message MAY also contain another Home Agent's address. > > Vijay > > James Kempf wrote: > > In the context of the bootstrapping discussion, I've written a draft about > > how to inform a mobile node that its home agent is about to become > > unavailable, and therefore that the mobile node should look for a new home > > agent or otherwise perform bootstrapping if necessary. AFICT, there's no way > > to do this in RFC 3775. The draft is available at: > > > > http://www.geocities.com/kempf42/draft-kempf-mip6-ha-alert-00.txt > > > > until it shows up in the drafts repository. The draft proposes a minor > > modification to home agent discovery for this purpose, but it is meant to be > > more for discussion, as there are a couple of open questions posed. > > > > jak > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 7 22:00:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02633 for ; Mon, 7 Feb 2005 22:00:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyLvR-0008Nj-Ei for mip6-web-archive@ietf.org; Mon, 07 Feb 2005 22:20:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyLau-0001xb-M0; Mon, 07 Feb 2005 21:59:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyLYW-0001Wr-5d for mip6@megatron.ietf.org; Mon, 07 Feb 2005 21:56:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02333 for ; Mon, 7 Feb 2005 21:56:45 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyLs2-0008IJ-68 for mip6@ietf.org; Mon, 07 Feb 2005 22:16:58 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j183Qdp21025; Mon, 7 Feb 2005 19:26:39 -0800 X-mProtect: <200502080326> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141206.americas.nokia.com (172.18.141.206, claiming to be "[172.18.141.206]") by darkstar.iprg.nokia.com smtpdycwTHZ; Mon, 07 Feb 2005 19:26:36 PST Message-ID: <42082A38.9080707@iprg.nokia.com> Date: Mon, 07 Feb 2005 18:55:52 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "DENG, HUI -HCHIBJ" Subject: Re: [Mip6] HA Unavailability Alerting References: <834B54D356AA8F46B9B233DD88BEAA38590F0C@hcbjdc2> In-Reply-To: <834B54D356AA8F46B9B233DD88BEAA38590F0C@hcbjdc2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit cool... we all atleast agree that we need such a message from the HA to the MN. :) Vijay DENG, HUI -HCHIBJ wrote: > Vijay and Jim > > We also already defined this message in our draft long time ago. > and clearly mentioned that it will be used during home agent will shortly become unavailable > http://www.ietf.org/internet-drafts/draft-deng-mip6-ha-loadbalance-02.txt > > Thanks for your checking > > -Hui > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: 2005?2?8? 10:21 > To: James Kempf > Cc: mip6@ietf.org > Subject: Re: [Mip6] HA Unavailability Alerting > > > Jim, > > the HAHA protocol already defines such a message, "Home Agent Switch Request". > http://www.ietf.org/internet-drafts/draft-wakikawa-mip6-nemo-haha-spec-00.txt > the HA can send this message to MN to indicate to the MN that it should perform DHAAD again and pick another Home Agent. the message MAY also contain another Home Agent's address. > > Vijay > > James Kempf wrote: > >>In the context of the bootstrapping discussion, I've written a draft >>about how to inform a mobile node that its home agent is about to >>become unavailable, and therefore that the mobile node should look for >>a new home agent or otherwise perform bootstrapping if necessary. >>AFICT, there's no way to do this in RFC 3775. The draft is available >>at: >> >>http://www.geocities.com/kempf42/draft-kempf-mip6-ha-alert-00.txt >> >>until it shows up in the drafts repository. The draft proposes a minor >>modification to home agent discovery for this purpose, but it is meant >>to be more for discussion, as there are a couple of open questions >>posed. >> >> jak >> >> >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 8 00:54:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13000 for ; Tue, 8 Feb 2005 00:54:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyOeS-000362-5q for mip6-web-archive@ietf.org; Tue, 08 Feb 2005 01:15:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyOJ0-0004Bg-Mg; Tue, 08 Feb 2005 00:52:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyOHs-0003ui-Da for mip6@megatron.ietf.org; Tue, 08 Feb 2005 00:51:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12838 for ; Tue, 8 Feb 2005 00:51:39 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CyObJ-00031w-95 for mip6@ietf.org; Tue, 08 Feb 2005 01:11:55 -0500 Received: (qmail 21768 invoked by uid 104); 8 Feb 2005 05:51:07 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 10.576056 secs); 08 Feb 2005 05:51:07 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk1110784185651121712 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 10.576056 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-97.5 required=7.0 tests=AWL, J_CHICKENPOX_17, J_CHICKENPOX_27, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 8 Feb 2005 05:50:56 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Tue, 8 Feb 2005 13:51:23 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 8 Feb 2005 13:51:22 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3804D4A7@hcbjdc2> Thread-Topic: Workshop on Deployment of Mobile IPv6 in China Thread-Index: AcUNihXJ/Gn9dSRaTOa3WmcsPRxXAgAFmi9A From: "DENG, HUI -HCHIBJ" To: X-OriginalArrivalTime: 08 Feb 2005 05:51:23.0312 (UTC) FILETIME=[38771B00:01C50DA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: quoted-printable Cc: tq@cae.cn, ayh@cae.cn, wuhq@catt.ac.cn Subject: [Mip6] Workshop on Deployment of Mobile IPv6 in China X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Hello, all Tomorrow is Chinese lunar new year. By taking this opportunity, we'd like to announce a workshop information to all researchers. If you are interested in and would like to attend this workshop, Please don't hestitate to let us know it. By the way, this workshop don't need any registration fee since the intention of this workshop is not to make any benefit. Best wishes to you Sincerely yours Dr. Hequan Wu Chief Scientist=20 China Next-Generation Internet Experts Commission =20 Vice President Chinese Academy of Engineering -------------------------------------------------------------------------= --------------------------------------------------------- Workshop on Deployment of Mobile IPv6 in China (1) Organizers: China Next-Generation Internet Experts Commission & Hitachi (China),Ltd. = =20 (2) Date/Time: Feb. 25th-26th. Friday/Saturday, 2005 (3) Place: Guo Hong Hotel = (4) Program: = =20 Feb. 25th ????Chair: Prof. Hequan Wu (Chief Scientist of CNGI = Experts Commission) 9:00-9:15 Opening Address(1) =20 Prof. Hequan Wu (Chief Scientist of CNGI Experts Commission) 9:15-9:30 Opening Address(2) =20 Dr. M(General Manager of NDRC) 9:30-10:20 Mobility in IPv6: Technology and Deployment Dr.Gopal Dommety (Vice Chairman of MIP6 WG in IETF) 10:20-11:00 IPv6 and Mobile IPv6 in China Telecom Mr. Leping Wei (CTO of China Telecom) 11:00-11:50 IPv6 and Mobile IPv6 in China Mobile Mr. Mofang Li (CTO of China Mobile) < Lunch > 12:20-14:00 =20 Chair: Gopal Dommety (Vice Chairman of MIP6 = WG) 14:00-14:50 Cisco's solution in Mobile IPv6 and Mobile Networks Mr. Kent Leung (Distinguished Engineer, Cisco)=20 14:50-15:30 IPv6 and Mobile IPv6 in China Unicom Mr.Yunjie Liu (Pre-CTO of China Unicom) 15:30-15:50 < Demonstration & Coffee Break > 15:50-16:30 IPv6 and Mobile IPv6 in China Netcom=20 Ms. Yan Ma(General Manager, Department of Technology, China = Netcom) 16:30-17:20 IPv6 and Mobile IPv6 from HP Mr. Brian Haley (Hewlett Packard Company) 17:20-18:00 IPv6 and Mobile IPv6 solution in Hitachi Dr. (Hitachi) 18:20-20:00 Feb. 26th ????Chair: Prof. () 9:00-9:40 IPv6 and Mobile IPv6 in CERNET Dr. Jianping Wu (Director of CERNET) 9:40-10:30 Network Mobility (NEMO) =20 Dr. Thierry Ernst (Vice Chairman of NEMO WG in IETF) 10:30-11:00 Closing Address Dr.=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 8 06:09:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27441 for ; Tue, 8 Feb 2005 06:09:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyTYb-0001M8-TH for mip6-web-archive@ietf.org; Tue, 08 Feb 2005 06:29:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyTCy-0000Lf-SB; Tue, 08 Feb 2005 06:07:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyT4a-0007A6-81 for mip6@megatron.ietf.org; Tue, 08 Feb 2005 05:58:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25223 for ; Tue, 8 Feb 2005 05:58:21 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyTO7-00012Q-Hw for mip6@ietf.org; Tue, 08 Feb 2005 06:18:38 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id j18B0LJD010415; Tue, 8 Feb 2005 04:00:21 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id j18Auu7i012677; Tue, 8 Feb 2005 04:56:56 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6B99C86602B; Tue, 8 Feb 2005 11:58:17 +0100 (CET) Message-ID: <42089B43.3030403@motorola.com> Date: Tue, 08 Feb 2005 11:58:11 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] HA prefix = HoA prefix? References: <6.0.0.22.2.20050204084906.041fb7b0@qcmail1.qualcomm.com> <4203FBB3.6020101@motorola.com> <420718A2.9020104@iprg.nokia.com> <42074AB0.5090306@motorola.com> <4207B0B4.3010906@iprg.nokia.com> In-Reply-To: <4207B0B4.3010906@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1380778370==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1380778370== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig88A02F6EA02960BC566AB3B9" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig88A02F6EA02960BC566AB3B9 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: >>> depends on your implementation. how do you implement >>> binding ack status value 132? >> >> I don't think I do... > > dont you think you should implement it? You're right, maybe yes. Alex --------------enig88A02F6EA02960BC566AB3B9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCCJtJMmC0w56zj54RAh4rAKDcmh1bp9URRbPowmkC0KsBqWF1WACeKr+Z AW0BpjOwdmi9IZk2CXbHwT8= =dLK9 -----END PGP SIGNATURE----- --------------enig88A02F6EA02960BC566AB3B9-- --===============1380778370== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1380778370==-- From mip6-bounces@ietf.org Tue Feb 8 09:39:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13235 for ; Tue, 8 Feb 2005 09:39:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyWq2-00062A-Ba for mip6-web-archive@ietf.org; Tue, 08 Feb 2005 09:59:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWRL-0004So-Nj; Tue, 08 Feb 2005 09:34:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWLZ-0002hl-9H for mip6@megatron.ietf.org; Tue, 08 Feb 2005 09:28:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12476 for ; Tue, 8 Feb 2005 09:28:06 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyWf9-0005nX-Gj for mip6@ietf.org; Tue, 08 Feb 2005 09:48:24 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IBL00J65K2399@dns1.cselt.it> for mip6@ietf.org; Tue, 08 Feb 2005 15:25:15 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Tue, 08 Feb 2005 15:30:06 +0100 Date: Tue, 08 Feb 2005 15:27:32 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt To: Yoshihiro Ohba Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt thread-index: AcUNZxXx0QVV0GZlQKmICkm9s+lBOwAgt4Iw Content-Class: urn:content-classes:message X-OriginalArrivalTime: 08 Feb 2005 14:30:06.0875 (UTC) FILETIME=[AF8DEEB0:01C50DEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: quoted-printable Hi Yoshi, thanks for your comments. Please see below..=20 >=20 > On Fri, Feb 04, 2005 at 11:54:11AM -0600,=20 > Basavaraj.Patil@nokia.com wrote: > >=20 > > The goals/reasons for a standardized interface between the=20 > HA and AAA > > were discussed at IETF61 in Gerardo's I-D : > > draft-giaretta-mip6-aaa-ha-goals-00.txt=20 > > Such an interface is required from the perspective of=20 > bootstrapping a > > MN in operator owned network environments.=20 > >=20 > > We would like to make this I-D a working group document=20 > that captures > > the goals and requirements for the interface between the HA and AAA > > and is used as input in the design of the bootstrapping=20 > solution that > > relies on AAA. >=20 > I agree on making the I-D as a WG document, but I think the I-D needs > to be revised in terms of Scenario 2. >=20 > Scenario 2 would need more discussion, considering potential > variations and complexity in integrating MIPv6 bootstrapping and > network access authentication. Especially, I don't think there is a > WG consensus as to whether piggybacking MIPv6 parameters in EAP, or > carrying them in some other ways (using AAA protocol, EAP lower layer > and/or DHCP), or both should be supported. >=20 Surely there is no WG consensus on any of these mechanisms. This draft aims at describing the possible scenarios/frameworks for the integration between AAA and MIP6 and at identifying the related goals for AAA-HA interface. It is not a solution draft.=20 In particular, the purpose of section 4.2 was to list existing proposals that fall in scenario 2 and to highlight that a single AAA-HA interface can be designed for all these proposals, no matter if bootstrapping parameters are carried by EAP, AAA protocol, EAP lower layer or DHCP.=20 =20 > Having said that, I think Scenario 2 should be described in most > generic way at this moment, perhaps with integration of Figures 3 and > 4 without mentioning piggybacking MIPv6 parameters in EAP, RADIUS or > L2 specific extensions. >=20 Figures 3 and 4 have been included in order to highlight that the design of the AAA-HA interface is independent from the bootstrapping solution peculiarities in the AAA-MN path.=20 Comments? Regards, --Gerardo > Best regards, >=20 > Yoshihiro Ohba >=20 >=20 >=20 > >=20 > > Please comment if you do not agree to making this a WG document and > > your reasons by Feb 10th, 05.=20 > >=20 > > -Basavaraj > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 8 11:14:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21179 for ; Tue, 8 Feb 2005 11:14:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyYK0-000854-9S for mip6-web-archive@ietf.org; Tue, 08 Feb 2005 11:34:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyXuz-0002rw-Ll; Tue, 08 Feb 2005 11:08:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyXtN-0002W1-W3 for mip6@megatron.ietf.org; Tue, 08 Feb 2005 11:07:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20694 for ; Tue, 8 Feb 2005 11:07:08 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyYD0-0007w2-UR for mip6@ietf.org; Tue, 08 Feb 2005 11:27:27 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j18G75c22289; Tue, 8 Feb 2005 18:07:05 +0200 (EET) X-Scanned: Tue, 8 Feb 2005 18:06:25 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j18G6P3Z016605; Tue, 8 Feb 2005 18:06:25 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00UATvCf; Tue, 08 Feb 2005 18:05:43 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j18G5hx04832; Tue, 8 Feb 2005 18:05:43 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Feb 2005 10:00:11 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Mip6] what is the status of draft-ietf-mip6-firewalls-00.txt? Date: Tue, 8 Feb 2005 10:00:11 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C7B4@daebe101.NOE.Nokia.com> Thread-Topic: what is the status of draft-ietf-mip6-firewalls-00.txt? Thread-Index: AcULL3FKYDg4HF53QfqFPiYEq7IBxQCx70GA To: , X-OriginalArrivalTime: 08 Feb 2005 16:00:11.0886 (UTC) FILETIME=[453128E0:01C50DF7] X-Spam-Score: 0.6 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1001049292==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 This is a multi-part message in MIME format. --===============1001049292== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50DF7.44FBB97B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50DF7.44FBB97B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The draft has completed WG last call. It is being progressed for = publication as an Informational RFC. =20 -Basavaraj -----Original Message----- From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On Behalf Of = ext Changming Liu Sent: Friday, February 04, 2005 9:05 PM To: mip6@ietf.org Subject: [Mip6] what is the status of draft-ietf-mip6-firewalls-00.txt? Just came across this draft.. Anyone knows what is the status of this = draft? =20 It is a very interesting draft. Thanks the authors to bring the firewall = issue up for MIP6 in its early stages. But if we can turn this one into = MIP6 firewall traversal requirement document for both firewall = implementation and MIP6 protocol to make it firewall friendly. It will = be much more valuable. =20 =20 I have lots of other comments on the draft, I will save them for later. = First, I want to know whether the authors or anyone else are interested = in making such changes as I mentioned above?=20 =20 Changming Liu =20 ------_=_NextPart_001_01C50DF7.44FBB97B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The=20 draft has completed WG last call. It is being progressed for publication = as an=20 Informational RFC.
 
-Basavaraj
-----Original Message-----
From: = mip6-bounces@ietf.org=20 [mailto:mip6-bounces@ietf.org]On Behalf Of ext Changming=20 Liu
Sent: Friday, February 04, 2005 9:05 PM
To:=20 mip6@ietf.org
Subject: [Mip6] what is the status of=20 draft-ietf-mip6-firewalls-00.txt?

Just came across this = draft..=20 Anyone knows what is the status of this draft?

 

It is a very interesting = draft.=20 Thanks the authors to bring the firewall issue up for MIP6 in its = early=20 stages. But if we can turn this one into MIP6 firewall traversal = requirement=20 document for both firewall implementation and MIP6 protocol to make it = firewall friendly. It will be much more valuable. =  

 

I have lots of other = comments on=20 the draft, I will save them for later. First, I want to know whether = the=20 authors or anyone else are interested in making such changes as I = mentioned=20 above?

 

Changming = Liu

 

------_=_NextPart_001_01C50DF7.44FBB97B-- --===============1001049292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1001049292==-- From mip6-bounces@ietf.org Tue Feb 8 17:42:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09503 for ; Tue, 8 Feb 2005 17:42:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyeNV-0005Yt-Hd for mip6-web-archive@ietf.org; Tue, 08 Feb 2005 18:02:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CydgW-0004eR-E8; Tue, 08 Feb 2005 17:18:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cycyt-0000cI-JT for mip6@megatron.ietf.org; Tue, 08 Feb 2005 16:33:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26382 for ; Tue, 8 Feb 2005 16:33:08 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CydIY-0001Ju-HH for mip6@ietf.org; Tue, 08 Feb 2005 16:53:31 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j18LX1v07987; Tue, 8 Feb 2005 23:33:02 +0200 (EET) X-Scanned: Tue, 8 Feb 2005 23:31:51 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j18LVp6f030630; Tue, 8 Feb 2005 23:31:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00Byd6NK; Tue, 08 Feb 2005 23:31:50 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j18LVmU08929; Tue, 8 Feb 2005 23:31:48 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 8 Feb 2005 15:31:24 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Tue, 8 Feb 2005 15:31:22 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C7C2@daebe101.NOE.Nokia.com> Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcULCO4xT3Xk5ohvTEilaX/8ix7BTwDHIFIA To: , X-OriginalArrivalTime: 08 Feb 2005 21:31:24.0048 (UTC) FILETIME=[89EC7100:01C50E25] X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable >Before we get to listing the requirements, we (MIP6 WG) should identify >different frameworks where "mip6" gets mixed up with "aaa". Following >that, we can discuss which one of the frameworks we'd like to >standardize in IETF, and drive the requirements based on that. Okay. I think it is possible to have a discussion of the frameworks based on your I-D on the ML in a constrained timeframe and proceed to the next step of identifying what are the requirements for AAA-MIP6 network elements interactions.=20 > >This was the motivation behind writing draft-yegin-mip6-aaa-fwk-00.txt. >4 different frameworks are mentioned in that I-D, with one being >detailed.=20 The I-D can be a good source for the discussion itself and then we can simply choose to incorporate the one that we agree on as the basis for the goals I-D.=20 > >I have no objection to using mip6-aaa-ha-goals, but I recommend we >capture the framework discussions. For that, my recommendation is to >produce a WG I-D combining both individual I-Ds. Not sure if we really need to do a merge of the I-Ds here. I think we can have a discussion on the list about the frameworks that you propose in your I-D and then based on consensus we can incorporate the one that we agree on in the giaretta draft as a section. > >Besides, mip6-aaa-fwk has detailed discussions on call flow (good for >finding out the exact requirements), EAP considerations, why we need a >new AAA application, and relation to mip6 bootstrapping -- which are >worth capturing in the WG I-D. Some of this can go in an appendix of the giaretta draft. > >Alper > -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 8 18:38:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22389 for ; Tue, 8 Feb 2005 18:38:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyfFO-0000Un-4v for mip6-web-archive@ietf.org; Tue, 08 Feb 2005 18:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyenr-0005au-UC; Tue, 08 Feb 2005 18:29:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyekQ-0002tA-SI for mip6@megatron.ietf.org; Tue, 08 Feb 2005 18:26:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21402 for ; Tue, 8 Feb 2005 18:26:20 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25] helo=mailout2) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyf44-0000AL-DM for mip6@ietf.org; Tue, 08 Feb 2005 18:46:43 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IBM00B0192YID@mailout2.samsung.com> for mip6@ietf.org; Wed, 09 Feb 2005 08:25:46 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBM0004C92Y8K@mailout2.samsung.com> for mip6@ietf.org; Wed, 09 Feb 2005 08:25:46 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IBM000RO92VP2@mmp2.samsung.com> for mip6@ietf.org; Wed, 09 Feb 2005 08:25:46 +0900 (KST) Date: Tue, 08 Feb 2005 15:25:43 -0800 From: Alper Yegin Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <456943D540CFC14A8D7138E64843F85308C7C2@daebe101.NOE.Nokia.com> To: Basavaraj.Patil@nokia.com, mip6@ietf.org Message-id: <0ba101c50e35$84198e10$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7BIT > >Before we get to listing the requirements, we (MIP6 WG) should identify > >different frameworks where "mip6" gets mixed up with "aaa". Following > >that, we can discuss which one of the frameworks we'd like to > >standardize in IETF, and drive the requirements based on that. > > Okay. I think it is possible to have a discussion of the frameworks > based on your I-D on the ML in a constrained timeframe and proceed to > the next step of identifying what are the requirements for AAA-MIP6 > network elements interactions. The implications of some of the frameworks are not confined to a AAA-HA interface. For example, delivery of MIP6 information to NAS calls for new attributes for AAA server-to-NAS communication (as opposed to AAA server to HA, which requires a new AAA application). We shall capture those in the WG document as well. > > > >This was the motivation behind writing draft-yegin-mip6-aaa-fwk-00.txt. > >4 different frameworks are mentioned in that I-D, with one being > >detailed. > > The I-D can be a good source for the discussion itself and then we can > simply choose to incorporate the one that we agree on as the basis for > the goals I-D. > > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend we > >capture the framework discussions. For that, my recommendation is to > >produce a WG I-D combining both individual I-Ds. > > Not sure if we really need to do a merge of the I-Ds here. I think we > can have a discussion on the list about the frameworks that you > propose in your I-D and then based on consensus we can incorporate the > one that we agree on in the giaretta draft as a section. I'm not suggesting a full merge or anything, but to make sure we address various issues and angles thoroughly. If someone wants to rewrite things, I don't mind :-) > >Besides, mip6-aaa-fwk has detailed discussions on call flow (good for > >finding out the exact requirements), EAP considerations, why we need a > >new AAA application, and relation to mip6 bootstrapping -- which are > >worth capturing in the WG I-D. > > Some of this can go in an appendix of the giaretta draft. I think some of these discussions are for the main text. For example, the relation to MIP6 bootstrapping must be spelled out. Some parts of the mip6-aaa-ha draft gives the impression that such an interface handles the MIP6 bootstrapping single-handedly. That's not always the case. Also, I think we need some words on why we need a new AAA application when we already have MIP4 and EAP applications. For framework classification, here are my slides: http://yegin.org/IETF/MIP6-AAA-fwk.ppt. This is what I missed to present at IETF 61. Alper > > > > >Alper > > > > -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 8 18:50:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23076 for ; Tue, 8 Feb 2005 18:50:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyfRG-0000jg-Qm for mip6-web-archive@ietf.org; Tue, 08 Feb 2005 19:10:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyf5Y-00032y-T2; Tue, 08 Feb 2005 18:48:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyf4N-0002kR-6q for mip6@megatron.ietf.org; Tue, 08 Feb 2005 18:47:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22933 for ; Tue, 8 Feb 2005 18:46:56 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyfNy-0000gX-Mg for mip6@ietf.org; Tue, 08 Feb 2005 19:07:20 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j18NkoHr005658; Wed, 9 Feb 2005 08:46:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j18Nkorn011912; Wed, 9 Feb 2005 08:46:50 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id JAA11905 ; Wed, 9 Feb 2005 08:46:50 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j18Nknc0003824; Wed, 9 Feb 2005 08:46:49 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j18Nkne2027613; Wed, 9 Feb 2005 08:46:49 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j18Nkn8a023943; Wed, 9 Feb 2005 08:46:49 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IBM005B4A1VB1@tsbpo1.po.toshiba.co.jp>; Wed, 9 Feb 2005 08:46:46 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Cye7Q-00023o-00; Tue, 08 Feb 2005 14:46:04 -0800 Date: Tue, 08 Feb 2005 17:46:04 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: To: Gerardo Giaretta Message-id: <20050208224604.GB1002@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: mip6@ietf.org, Yoshihiro Ohba , Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Hi Gerardo, On Tue, Feb 08, 2005 at 03:27:32PM +0100, Gerardo Giaretta wrote: > Hi Yoshi, > > thanks for your comments. Please see below.. > > > > > On Fri, Feb 04, 2005 at 11:54:11AM -0600, > > Basavaraj.Patil@nokia.com wrote: > > > > > > The goals/reasons for a standardized interface between the > > HA and AAA > > > were discussed at IETF61 in Gerardo's I-D : > > > draft-giaretta-mip6-aaa-ha-goals-00.txt > > > Such an interface is required from the perspective of > > bootstrapping a > > > MN in operator owned network environments. > > > > > > We would like to make this I-D a working group document > > that captures > > > the goals and requirements for the interface between the HA and AAA > > > and is used as input in the design of the bootstrapping > > solution that > > > relies on AAA. > > > > I agree on making the I-D as a WG document, but I think the I-D needs > > to be revised in terms of Scenario 2. > > > > Scenario 2 would need more discussion, considering potential > > variations and complexity in integrating MIPv6 bootstrapping and > > network access authentication. Especially, I don't think there is a > > WG consensus as to whether piggybacking MIPv6 parameters in EAP, or > > carrying them in some other ways (using AAA protocol, EAP lower layer > > and/or DHCP), or both should be supported. > > > > Surely there is no WG consensus on any of these mechanisms. This draft > aims at describing the possible scenarios/frameworks for the integration > between AAA and MIP6 and at identifying the related goals for AAA-HA > interface. It is not a solution draft. OK. If the draft has more explicit description on this about Scenario 2 in particular, I am fine. Regards, Yoshihiro Ohba > > In particular, the purpose of section 4.2 was to list existing proposals > that fall in scenario 2 and to highlight that a single AAA-HA interface > can be designed for all these proposals, no matter if bootstrapping > parameters are carried by EAP, AAA protocol, EAP lower layer or DHCP. > > > > Having said that, I think Scenario 2 should be described in most > > generic way at this moment, perhaps with integration of Figures 3 and > > 4 without mentioning piggybacking MIPv6 parameters in EAP, RADIUS or > > L2 specific extensions. > > > > Figures 3 and 4 have been included in order to highlight that the design > of the AAA-HA interface is independent from the bootstrapping solution > peculiarities in the AAA-MN path. > > Comments? > > Regards, > --Gerardo > > > > Best regards, > > > > Yoshihiro Ohba > > > > > > > > > > > > Please comment if you do not agree to making this a WG document and > > > your reasons by Feb 10th, 05. > > > > > > -Basavaraj > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 9 09:06:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03845 for ; Wed, 9 Feb 2005 09:06:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cysnh-00081P-1l for mip6-web-archive@ietf.org; Wed, 09 Feb 2005 09:26:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CysQL-0008IU-FG; Wed, 09 Feb 2005 09:02:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CysLz-0007Ks-1D for mip6@megatron.ietf.org; Wed, 09 Feb 2005 08:58:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03248 for ; Wed, 9 Feb 2005 08:58:01 -0500 (EST) Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cysfm-0007pd-Qf for mip6@ietf.org; Wed, 09 Feb 2005 09:18:32 -0500 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate7.mot.com (Motorola/Motgate7) with ESMTP id j19DmPT7027054; Wed, 9 Feb 2005 06:48:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id j19Dw9ac027643; Wed, 9 Feb 2005 07:58:09 -0600 (CST) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id AE9DB86602B; Wed, 9 Feb 2005 14:57:57 +0100 (CET) Message-ID: <420A16DE.90506@motorola.com> Date: Wed, 09 Feb 2005 14:57:50 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [Mip6] HA prefix = HoA prefix? References: <000001c50cf0$743f5880$f204120a@in.huawei.com> <4207AEEE.5030801@iprg.nokia.com> In-Reply-To: <4207AEEE.5030801@iprg.nokia.com> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0338494884==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0338494884== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2511A3DD88EF36E097C102F5" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2511A3DD88EF36E097C102F5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Vijay Devarapalli wrote: > binding ack status 132 should enable the MN to recover in such cases. On which Operating System? Alex --------------enig2511A3DD88EF36E097C102F5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFCChblMmC0w56zj54RAjCfAKDH2T9a114ci3QvKiUUGMozZ4Ky1QCgmD0q kWIWlMQBuq0WvGuFXKOkQGc= =ie/F -----END PGP SIGNATURE----- --------------enig2511A3DD88EF36E097C102F5-- --===============0338494884== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0338494884==-- From mip6-bounces@ietf.org Wed Feb 9 11:35:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15330 for ; Wed, 9 Feb 2005 11:35:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyv8O-0002qM-BC for mip6-web-archive@ietf.org; Wed, 09 Feb 2005 11:56:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyukW-0007KJ-Mr; Wed, 09 Feb 2005 11:31:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyuht-0006Ht-4n for mip6@megatron.ietf.org; Wed, 09 Feb 2005 11:28:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14926 for ; Wed, 9 Feb 2005 11:28:46 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyv1f-0002gK-Pu for mip6@ietf.org; Wed, 09 Feb 2005 11:49:19 -0500 Received: from FlyToWorld ([192.168.250.8]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 01:28:56 +0900 Message-ID: <004801c50ec4$615a3d90$08faa8c0@FlyToWorld> From: "Junghoon Jee" To: , References: <456943D540CFC14A8D7138E64843F85308C794@daebe101.NOE.Nokia.com> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Thu, 10 Feb 2005 01:28:25 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 09 Feb 2005 16:28:56.0761 (UTC) FILETIME=[73B5F290:01C50EC4] X-Spam-Score: 2.2 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0485135841==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 --===============0485135841== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8sIEJhc2F2YXJhaiBhbmQgQUxMLg0KDQpJIGRvbid0IGFncmVlIHRvIG1ha2luZyB0aGlz IEktRCBhcyBhIFdHIGRvY3VtZW50cyBhdCB0aGlzIHRpbWUNCnRob3VnaCB0aGlzIEktRCBjYXB0 dXJlcyB0aGUgTUlQdjYgYm9vdHN0YXBwaW5nIHByb2JsZW1zIHZlcnkgd2VsbC4NCg0KSSBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IHRoaXMgSS1EIGNhbiBiZSB1c2VkIGFzIGlucHV0IGluIHRoZSBkZXNp Z24gb2YgdGhlIGJvb3RzdHJhcHBpbmcNCnNvbHV0aW9uIHJlbHlpbmcgb24gQUFBLg0KDQpIb3dl dmVyLCBJTUhPLCB3ZSBuZWVkIHRvIGhhdmUgYSBjb25zZW5zdXMgYWJvdXQgYm9vdHN0cmFwcGlu ZyBmcmFtZXdvcmsgdXNpbmcgQUFBLg0KSW4gdGhpcyBJLUQsIHRoZXJlIGFyZSBmb3VyIGJvb3Rz dHJhcHBpbmcgc2NlbmFyaW9zLg0KSW4gbXkgb3BpbmlvbiwgdGhlIHNjZW5hcmlvIDMgYW5kIDQg YXJlIG5vdCB3aXRoaW4gdGhlIHNjb3BlIG9mIE1JUHY2IGJvb3RzdHJhcHBpbmcuDQpSZWdhcmRp bmcgdGhlIHNjZW5hcmlvIDEsIHdlIGRvbid0IGhhdmUgYSBzZWN1cmUgaG9tZSBhZ2VudCBkaXNj b3ZlcnkgbWVjaGFuaXNtIHlldC4NClNvIEknZCBzYXkgdGhhdCBvbmx5IHRoZSBzY2VuYXJpbyAy IGhhcyBhIG1lYW5pbmcgYXQgdGhpcyB0aW1lLg0KDQpNeSBzdWdnZXN0aW9uIGFib3V0IE1JUHY2 IGJvb3RzdHJhcHBpbmcgaXMgdGhhdCwNCkxldCdzIGZpcnN0IGZvY3VzIG91ciBkaXNjdXNzaW9u IG9uIHRoZSBNSVB2NiBib290c3RyYXBwaW5nIGZyYW1ld29yayB3b3Jrcy4NCg0KQWZ0ZXIgdGhh dCwgd2UgY2FuIHByb2NlZWQgdG8gdGhlIHdvcmsgYWJvdXQgZGVmaW5pbmcgdGhlIGludGVyZmFj ZSBiZXR3ZWVuIHRoZSBBQUEgc2VydmVyIGFuZCBIQS4NCg0KSnVuZ2hvb24uDQoNCg0KLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANCkZyb206IDxCYXNhdmFyYWouUGF0aWxAbm9raWEuY29t Pg0KVG86IDxtaXA2QGlldGYub3JnPg0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDA1LCAyMDA1 IDI6NTQgQU0NClN1YmplY3Q6IFtNaXA2XSBDb25zZW5zdXMgY2FsbDogZHJhZnQtZ2lhcmV0dGEt bWlwNi1hYWEtaGEtZ29hbHMtMDAudHh0DQoNCg0KDQoNClRoZSBnb2Fscy9yZWFzb25zIGZvciBh IHN0YW5kYXJkaXplZCBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgSEEgYW5kIEFBQQ0Kd2VyZSBkaXNj dXNzZWQgYXQgSUVURjYxIGluIEdlcmFyZG8ncyBJLUQgOg0KZHJhZnQtZ2lhcmV0dGEtbWlwNi1h YWEtaGEtZ29hbHMtMDAudHh0IA0KU3VjaCBhbiBpbnRlcmZhY2UgaXMgcmVxdWlyZWQgZnJvbSB0 aGUgcGVyc3BlY3RpdmUgb2YgYm9vdHN0cmFwcGluZyBhDQpNTiBpbiBvcGVyYXRvciBvd25lZCBu ZXR3b3JrIGVudmlyb25tZW50cy4gDQoNCldlIHdvdWxkIGxpa2UgdG8gbWFrZSB0aGlzIEktRCBh IHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgdGhhdCBjYXB0dXJlcw0KdGhlIGdvYWxzIGFuZCByZXF1 aXJlbWVudHMgZm9yIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiB0aGUgSEEgYW5kIEFBQQ0KYW5kIGlz IHVzZWQgYXMgaW5wdXQgaW4gdGhlIGRlc2lnbiBvZiB0aGUgYm9vdHN0cmFwcGluZyBzb2x1dGlv biB0aGF0DQpyZWxpZXMgb24gQUFBLg0KDQpQbGVhc2UgY29tbWVudCBpZiB5b3UgZG8gbm90IGFn cmVlIHRvIG1ha2luZyB0aGlzIGEgV0cgZG9jdW1lbnQgYW5kDQp5b3VyIHJlYXNvbnMgYnkgRmVi IDEwdGgsIDA1LiANCg0KLUJhc2F2YXJhag0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KTWlwNiBtYWlsaW5nIGxpc3QNCk1pcDZAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21pcDY= --===============0485135841== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0485135841==-- From mip6-bounces@ietf.org Wed Feb 9 12:38:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20611 for ; Wed, 9 Feb 2005 12:38:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyw7Y-0004O7-A9 for mip6-web-archive@ietf.org; Wed, 09 Feb 2005 12:59:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyvip-0006EN-Du; Wed, 09 Feb 2005 12:33:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyveV-0004P0-5J for mip6@megatron.ietf.org; Wed, 09 Feb 2005 12:29:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19688 for ; Wed, 9 Feb 2005 12:29:20 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyvyJ-00045Y-0q for mip6@ietf.org; Wed, 09 Feb 2005 12:49:53 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IBN0063SMQ1QB@dns2.cselt.it> for mip6@ietf.org; Wed, 09 Feb 2005 18:18:01 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 09 Feb 2005 18:28:22 +0100 Date: Wed, 09 Feb 2005 18:28:41 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt To: Basavaraj.Patil@nokia.com, alper.yegin@samsung.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcULCO4xT3Xk5ohvTEilaX/8ix7BTwDHIFIAACnEZ3A= Content-class: urn:content-classes:message X-OriginalArrivalTime: 09 Feb 2005 17:28:22.0296 (UTC) FILETIME=[C0EF6980:01C50ECC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 Content-Transfer-Encoding: quoted-printable Hi Raj and Alper, see my comments below... >=20 >=20 > >Before we get to listing the requirements, we (MIP6 WG)=20 > should identify > >different frameworks where "mip6" gets mixed up with "aaa". Following > >that, we can discuss which one of the frameworks we'd like to > >standardize in IETF, and drive the requirements based on that. >=20 > Okay. I think it is possible to have a discussion of the frameworks > based on your I-D on the ML in a constrained timeframe and proceed to > the next step of identifying what are the requirements for AAA-MIP6 > network elements interactions.=20 Despite its title, draft-giaretta-mip6-aaa-ha-goals does not provide just a list of goals for AAA-HA interface. We have also described 4 different scenarios for AAA and MIP6 interaction. I think that almost all the frameworks described in Alper's draft are covered by the scenarios described in mip6-aaa-ha-goals. In particular, referring to Alper's slides, this is the matching: framework 1 and 2 of draft-yegin <-----> scenario 2 in draft-giaretta framework 4 of draft-yegin <-----> scenario 1 in draft-giaretta In our draft we have put together framework 1 and 2 because they have common goals for the AAA-HA interface. Nonetheless, I agree that they have different requirements on the AAAH-MN path. We should probably separate them if we are going to expand the draft to encompass all AAA requirements or goals for MIP6. Framework 3 (Piggybacking MIP6 signaling with network access AAA) is not covered in our draft. However, I don't understand very well this framework: it seems to be similar to MIP4 AAA framework but I wonder how it can be applied to Mobile IPv6, due to MIP6 architecture peculiarities (e.g. lack of Foreign Agent, usage of IPsec to protect BUs). > > > >This was the motivation behind writing=20 > draft-yegin-mip6-aaa-fwk-00.txt. > >4 different frameworks are mentioned in that I-D, with one being > >detailed.=20 >=20 > The I-D can be a good source for the discussion itself and then we can > simply choose to incorporate the one that we agree on as the basis for > the goals I-D.=20 >=20 Raj, are you suggesting to choose one framework/solution and list the goals for it? It seems that there is not any consensus in MIP6 WG about the framework to be used for AAA and MIP6 interaction. I wonder even if there is a consensus to have a unique framework for MIP6 bootstrapping and AAA interactions. This is the reason why we described 4 scenarios and tried to list the common AAA goals for all of them. --Gerardo > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend we > >capture the framework discussions. For that, my recommendation is to > >produce a WG I-D combining both individual I-Ds. >=20 > Not sure if we really need to do a merge of the I-Ds here. I think we > can have a discussion on the list about the frameworks that you > propose in your I-D and then based on consensus we can incorporate the > one that we agree on in the giaretta draft as a section. >=20 > > > >Besides, mip6-aaa-fwk has detailed discussions on call flow (good for > >finding out the exact requirements), EAP considerations, why=20 > we need a > >new AAA application, and relation to mip6 bootstrapping -- which are > >worth capturing in the WG I-D. >=20 > Some of this can go in an appendix of the giaretta draft. >=20 > > > >Alper > > >=20 > -Basavaraj >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 > Behalf Of Basavaraj.Patil@nokia.com > Sent: Tuesday, February 08, 2005 10:31 PM > To: alper.yegin@samsung.com; mip6@ietf.org > Subject: RE: [Mip6] Consensus call:=20 > draft-giaretta-mip6-aaa-ha-goals-00.txt >=20 >=20 >=20 > >Before we get to listing the requirements, we (MIP6 WG)=20 > should identify > >different frameworks where "mip6" gets mixed up with "aaa". Following > >that, we can discuss which one of the frameworks we'd like to > >standardize in IETF, and drive the requirements based on that. >=20 > Okay. I think it is possible to have a discussion of the frameworks > based on your I-D on the ML in a constrained timeframe and proceed to > the next step of identifying what are the requirements for AAA-MIP6 > network elements interactions.=20 > > > >This was the motivation behind writing=20 > draft-yegin-mip6-aaa-fwk-00.txt. > >4 different frameworks are mentioned in that I-D, with one being > >detailed.=20 >=20 > The I-D can be a good source for the discussion itself and then we can > simply choose to incorporate the one that we agree on as the basis for > the goals I-D.=20 >=20 > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend we > >capture the framework discussions. For that, my recommendation is to > >produce a WG I-D combining both individual I-Ds. >=20 > Not sure if we really need to do a merge of the I-Ds here. I think we > can have a discussion on the list about the frameworks that you > propose in your I-D and then based on consensus we can incorporate the > one that we agree on in the giaretta draft as a section. >=20 > > > >Besides, mip6-aaa-fwk has detailed discussions on call flow (good for > >finding out the exact requirements), EAP considerations, why=20 > we need a > >new AAA application, and relation to mip6 bootstrapping -- which are > >worth capturing in the WG I-D. >=20 > Some of this can go in an appendix of the giaretta draft. >=20 > > > >Alper > > >=20 > -Basavaraj >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 9 12:40:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20817 for ; Wed, 9 Feb 2005 12:40:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyw8s-0004Ru-Qf for mip6-web-archive@ietf.org; Wed, 09 Feb 2005 13:00:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyvnB-00074j-3s; Wed, 09 Feb 2005 12:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyvij-0006CW-JF for mip6@megatron.ietf.org; Wed, 09 Feb 2005 12:33:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20093 for ; Wed, 9 Feb 2005 12:33:42 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyw2a-0004Dq-20 for mip6@ietf.org; Wed, 09 Feb 2005 12:54:16 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IBN0063JMXJWW@dns2.cselt.it> for mip6@ietf.org; Wed, 09 Feb 2005 18:22:31 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 09 Feb 2005 18:32:52 +0100 Date: Wed, 09 Feb 2005 18:33:13 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt To: Alper Yegin Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcUON0Gdaz/Z7lzdTue+TqUdaChHFQAlaL2Q Content-class: urn:content-classes:message X-OriginalArrivalTime: 09 Feb 2005 17:32:52.0328 (UTC) FILETIME=[61E30680:01C50ECD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable Hi Alper, please see below.. > > >Before we get to listing the requirements, we (MIP6 WG) should > identify > > >different frameworks where "mip6" gets mixed up with=20 > "aaa". Following > > >that, we can discuss which one of the frameworks we'd like to > > >standardize in IETF, and drive the requirements based on that. > >=20 > > Okay. I think it is possible to have a discussion of the frameworks > > based on your I-D on the ML in a constrained timeframe and=20 > proceed to > > the next step of identifying what are the requirements for AAA-MIP6 > > network elements interactions. >=20 > The implications of some of the frameworks are not confined=20 > to a AAA-HA > interface. For example, delivery of MIP6 information to NAS calls for > new attributes for AAA server-to-NAS communication (as opposed to AAA > server to HA, which requires a new AAA application). We shall capture > those in the WG document as well. >=20 I agree that some frameworks imply requirements also on AAAH-NAS communication. In draft-giaretta-mip6-aaa-ha-goals-00 we list only the requirements on AAA-HA interface because the goals for such an interface seem to be independent from the protocol used between MN, NAS and AAA server (e.g. EAP, PANA, RADIUS/Diameter). I think the WG should decide if we need a draft that lists all AAA-MIP6 requirements or for the moment only a draft listing the goals for the design of an interface between AAA and HA.=20 If the WG draft has to cover all AAA-MIP6 requirements, before listing the goals we surely need to decide which framework(s) we want to address. Otherwise, if we accept to limit the scope of the WG draft to the AAA-HA interface, it might be possible to identify the design goals for this interface in a way to address any possible framework.=20 Regards, --Gerardo > > > > > >This was the motivation behind writing > draft-yegin-mip6-aaa-fwk-00.txt. > > >4 different frameworks are mentioned in that I-D, with one being > > >detailed. > >=20 > > The I-D can be a good source for the discussion itself and=20 > then we can > > simply choose to incorporate the one that we agree on as=20 > the basis for > > the goals I-D. > >=20 > > > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend we > > >capture the framework discussions. For that, my=20 > recommendation is to > > >produce a WG I-D combining both individual I-Ds. > >=20 > > Not sure if we really need to do a merge of the I-Ds here.=20 > I think we > > can have a discussion on the list about the frameworks that you > > propose in your I-D and then based on consensus we can=20 > incorporate the > > one that we agree on in the giaretta draft as a section. >=20 > I'm not suggesting a full merge or anything, but to make sure=20 > we address > various issues and angles thoroughly. If someone wants to rewrite > things, I don't mind :-)=20 >=20 > > >Besides, mip6-aaa-fwk has detailed discussions on call=20 > flow (good for > > >finding out the exact requirements), EAP considerations,=20 > why we need > a > > >new AAA application, and relation to mip6 bootstrapping --=20 > which are > > >worth capturing in the WG I-D. > >=20 > > Some of this can go in an appendix of the giaretta draft. >=20 > I think some of these discussions are for the main text. For example, > the relation to MIP6 bootstrapping must be spelled out. Some parts of > the mip6-aaa-ha draft gives the impression that such an interface > handles the MIP6 bootstrapping single-handedly. That's not always the > case. Also, I think we need some words on why we need a new AAA > application when we already have MIP4 and EAP applications.=20 >=20 > For framework classification, here are my slides: > http://yegin.org/IETF/MIP6-AAA-fwk.ppt. This is what I missed=20 > to present > at IETF 61. >=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 > >=20 > > > > > >Alper > > > > >=20 > > -Basavaraj >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 9 14:07:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27933 for ; Wed, 9 Feb 2005 14:07:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyxVF-0006eQ-AB for mip6-web-archive@ietf.org; Wed, 09 Feb 2005 14:27:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyx2z-0003ze-0h; Wed, 09 Feb 2005 13:58:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cywy0-0002yy-Qe for mip6@megatron.ietf.org; Wed, 09 Feb 2005 13:53:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26582 for ; Wed, 9 Feb 2005 13:53:35 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24] helo=mailout1) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyxHr-0006E2-EC for mip6@ietf.org; Wed, 09 Feb 2005 14:14:08 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IBN00001R4FX0@mailout1.samsung.com> for mip6@ietf.org; Thu, 10 Feb 2005 03:53:03 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBN00H2ER4F8J@mailout1.samsung.com> for mip6@ietf.org; Thu, 10 Feb 2005 03:53:03 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IBN000FHR4C7X@mmp2.samsung.com> for mip6@ietf.org; Thu, 10 Feb 2005 03:53:03 +0900 (KST) Date: Wed, 09 Feb 2005 10:53:00 -0800 From: Alper Yegin Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: To: "'Gerardo Giaretta'" , Basavaraj.Patil@nokia.com Message-id: <0c0b01c50ed8$9521eb00$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: 7BIT Hi Giaretta, > > >Before we get to listing the requirements, we (MIP6 WG) > > should identify > > >different frameworks where "mip6" gets mixed up with "aaa". Following > > >that, we can discuss which one of the frameworks we'd like to > > >standardize in IETF, and drive the requirements based on that. > > > > Okay. I think it is possible to have a discussion of the frameworks > > based on your I-D on the ML in a constrained timeframe and proceed to > > the next step of identifying what are the requirements for AAA-MIP6 > > network elements interactions. > > Despite its title, draft-giaretta-mip6-aaa-ha-goals does not provide > just a list of goals for AAA-HA interface. We have also described 4 > different scenarios for AAA and MIP6 interaction. I think that almost > all the frameworks described in Alper's draft are covered by the > scenarios described in mip6-aaa-ha-goals. In particular, referring to > Alper's slides, this is the matching: > > framework 1 and 2 of draft-yegin <-----> scenario 2 in draft-giaretta > framework 4 of draft-yegin <-----> scenario 1 in draft-giaretta > > In our draft we have put together framework 1 and 2 because they have > common goals for the AAA-HA interface. Nonetheless, I agree that they > have different requirements on the AAAH-MN path. We should probably > separate them if we are going to expand the draft to encompass all AAA > requirements or goals for MIP6. I think framework 1 and 2 are fundamentally different. The protocols used, and the end-points used are not the same. This makes a big difference. > Framework 3 (Piggybacking MIP6 signaling with network access AAA) is not > covered in our draft. However, I don't understand very well this > framework: it seems to be similar to MIP4 AAA framework but I wonder how > it can be applied to Mobile IPv6, due to MIP6 architecture peculiarities > (e.g. lack of Foreign Agent, usage of IPsec to protect BUs). It is possible to realize that framework in some deployments, but not necessarily all. But of course that does not mean IETF will/should standardize it. I'm not advocating this framework. But for completeness we shall identify this framework, and explicitly state we are not going to standardize it (possibly give reasons, so that people don't keep rehashing). > > >This was the motivation behind writing > > draft-yegin-mip6-aaa-fwk-00.txt. > > >4 different frameworks are mentioned in that I-D, with one being > > >detailed. > > > > The I-D can be a good source for the discussion itself and then we can > > simply choose to incorporate the one that we agree on as the basis for > > the goals I-D. > > > > Raj, are you suggesting to choose one framework/solution and list the > goals for it? It seems that there is not any consensus in MIP6 WG about > the framework to be used for AAA and MIP6 interaction. That's what we must build first -- consensus on the standards track frameworks. I don't think we had this discussion yet. > I wonder even if > there is a consensus to have a unique framework for MIP6 bootstrapping > and AAA interactions. This is the reason why we described 4 scenarios > and tried to list the common AAA goals for all of them. Alper > > --Gerardo > > > > > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend we > > >capture the framework discussions. For that, my recommendation is to > > >produce a WG I-D combining both individual I-Ds. > > > > Not sure if we really need to do a merge of the I-Ds here. I think we > > can have a discussion on the list about the frameworks that you > > propose in your I-D and then based on consensus we can incorporate the > > one that we agree on in the giaretta draft as a section. > > > > > > > >Besides, mip6-aaa-fwk has detailed discussions on call flow (good for > > >finding out the exact requirements), EAP considerations, why > > we need a > > >new AAA application, and relation to mip6 bootstrapping -- which are > > >worth capturing in the WG I-D. > > > > Some of this can go in an appendix of the giaretta draft. > > > > > > > >Alper > > > > > > > -Basavaraj > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > -----Original Message----- > > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > > Behalf Of Basavaraj.Patil@nokia.com > > Sent: Tuesday, February 08, 2005 10:31 PM > > To: alper.yegin@samsung.com; mip6@ietf.org > > Subject: RE: [Mip6] Consensus call: > > draft-giaretta-mip6-aaa-ha-goals-00.txt > > > > > > > > >Before we get to listing the requirements, we (MIP6 WG) > > should identify > > >different frameworks where "mip6" gets mixed up with "aaa". Following > > >that, we can discuss which one of the frameworks we'd like to > > >standardize in IETF, and drive the requirements based on that. > > > > Okay. I think it is possible to have a discussion of the frameworks > > based on your I-D on the ML in a constrained timeframe and proceed to > > the next step of identifying what are the requirements for AAA-MIP6 > > network elements interactions. > > > > > >This was the motivation behind writing > > draft-yegin-mip6-aaa-fwk-00.txt. > > >4 different frameworks are mentioned in that I-D, with one being > > >detailed. > > > > The I-D can be a good source for the discussion itself and then we can > > simply choose to incorporate the one that we agree on as the basis for > > the goals I-D. > > > > > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend we > > >capture the framework discussions. For that, my recommendation is to > > >produce a WG I-D combining both individual I-Ds. > > > > Not sure if we really need to do a merge of the I-Ds here. I think we > > can have a discussion on the list about the frameworks that you > > propose in your I-D and then based on consensus we can incorporate the > > one that we agree on in the giaretta draft as a section. > > > > > > > >Besides, mip6-aaa-fwk has detailed discussions on call flow (good for > > >finding out the exact requirements), EAP considerations, why > > we need a > > >new AAA application, and relation to mip6 bootstrapping -- which are > > >worth capturing in the WG I-D. > > > > Some of this can go in an appendix of the giaretta draft. > > > > > > > >Alper > > > > > > > -Basavaraj > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 9 14:24:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01212 for ; Wed, 9 Feb 2005 14:24:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyxlK-0007Vt-Ik for mip6-web-archive@ietf.org; Wed, 09 Feb 2005 14:44:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyxDs-00075G-GJ; Wed, 09 Feb 2005 14:10:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyx4j-0004MR-Vo for mip6@megatron.ietf.org; Wed, 09 Feb 2005 14:00:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27095 for ; Wed, 9 Feb 2005 14:00:31 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33] helo=mailout3) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyxOa-0006Mg-0W for mip6@ietf.org; Wed, 09 Feb 2005 14:21:04 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IBN00801RFZ3H@mailout3.samsung.com> for mip6@ietf.org; Thu, 10 Feb 2005 03:59:59 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBN0089WRFZG7@mailout3.samsung.com> for mip6@ietf.org; Thu, 10 Feb 2005 03:59:59 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IBN00FR3RFXFB@mmp2.samsung.com> for mip6@ietf.org; Thu, 10 Feb 2005 03:59:59 +0900 (KST) Date: Wed, 09 Feb 2005 10:59:57 -0800 From: Alper Yegin Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: To: "'Gerardo Giaretta'" Message-id: <0c0c01c50ed9$8d44de00$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Content-Transfer-Encoding: 7BIT Hi Gerardo, > > > >Before we get to listing the requirements, we (MIP6 WG) should > > identify > > > >different frameworks where "mip6" gets mixed up with > > "aaa". Following > > > >that, we can discuss which one of the frameworks we'd like to > > > >standardize in IETF, and drive the requirements based on that. > > > > > > Okay. I think it is possible to have a discussion of the frameworks > > > based on your I-D on the ML in a constrained timeframe and > > proceed to > > > the next step of identifying what are the requirements for AAA-MIP6 > > > network elements interactions. > > > > The implications of some of the frameworks are not confined > > to a AAA-HA > > interface. For example, delivery of MIP6 information to NAS calls for > > new attributes for AAA server-to-NAS communication (as opposed to AAA > > server to HA, which requires a new AAA application). We shall capture > > those in the WG document as well. > > > > I agree that some frameworks imply requirements also on AAAH-NAS > communication. In draft-giaretta-mip6-aaa-ha-goals-00 we list only the > requirements on AAA-HA interface because the goals for such an interface > seem to be independent from the protocol used between MN, NAS and AAA > server (e.g. EAP, PANA, RADIUS/Diameter). > > I think the WG should decide if we need a draft that lists all AAA-MIP6 > requirements or for the moment only a draft listing the goals for the > design of an interface between AAA and HA. I think the MIP6 WG should discuss all "mip6" and "aaa" work needed in IETF. Once we agree on the work, documentation strategy can be worked out. Framework 2 should be standardized at IETF. I know at least one SDO is using that framework in a vendor-specific way. I anticipate more users (SDOs, deployments). > If the WG draft has to cover all AAA-MIP6 requirements, before listing > the goals we surely need to decide which framework(s) we want to > address. Otherwise, if we accept to limit the scope of the WG draft to > the AAA-HA interface, it might be possible to identify the design goals > for this interface in a way to address any possible framework. I think we must identify all possible frameworks, but not necessarily standardize all of them at IETF. Alper > > > Regards, > --Gerardo > > > > > > > > >This was the motivation behind writing > > draft-yegin-mip6-aaa-fwk-00.txt. > > > >4 different frameworks are mentioned in that I-D, with one being > > > >detailed. > > > > > > The I-D can be a good source for the discussion itself and > > then we can > > > simply choose to incorporate the one that we agree on as > > the basis for > > > the goals I-D. > > > > > > > > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend we > > > >capture the framework discussions. For that, my > > recommendation is to > > > >produce a WG I-D combining both individual I-Ds. > > > > > > Not sure if we really need to do a merge of the I-Ds here. > > I think we > > > can have a discussion on the list about the frameworks that you > > > propose in your I-D and then based on consensus we can > > incorporate the > > > one that we agree on in the giaretta draft as a section. > > > > I'm not suggesting a full merge or anything, but to make sure > > we address > > various issues and angles thoroughly. If someone wants to rewrite > > things, I don't mind :-) > > > > > >Besides, mip6-aaa-fwk has detailed discussions on call > > flow (good for > > > >finding out the exact requirements), EAP considerations, > > why we need > > a > > > >new AAA application, and relation to mip6 bootstrapping -- > > which are > > > >worth capturing in the WG I-D. > > > > > > Some of this can go in an appendix of the giaretta draft. > > > > I think some of these discussions are for the main text. For example, > > the relation to MIP6 bootstrapping must be spelled out. Some parts of > > the mip6-aaa-ha draft gives the impression that such an interface > > handles the MIP6 bootstrapping single-handedly. That's not always the > > case. Also, I think we need some words on why we need a new AAA > > application when we already have MIP4 and EAP applications. > > > > For framework classification, here are my slides: > > http://yegin.org/IETF/MIP6-AAA-fwk.ppt. This is what I missed > > to present > > at IETF 61. > > > > > > Alper > > > > > > > > > > > > > > > > > > > > >Alper > > > > > > > > > > -Basavaraj > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 9 23:14:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00837 for ; Wed, 9 Feb 2005 23:14:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz63D-0000fH-11 for mip6-web-archive@ietf.org; Wed, 09 Feb 2005 23:35:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz5gQ-0003TE-2K; Wed, 09 Feb 2005 23:12:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz5fl-0003Ha-Nn for mip6@megatron.ietf.org; Wed, 09 Feb 2005 23:11:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00698 for ; Wed, 9 Feb 2005 23:11:15 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz5zd-0000c9-B9 for mip6@ietf.org; Wed, 09 Feb 2005 23:31:54 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j1A4B9Hr000513; Thu, 10 Feb 2005 13:11:09 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j1A4B9PY000529; Thu, 10 Feb 2005 13:11:09 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id PAA00526 ; Thu, 10 Feb 2005 13:11:08 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j1A4B8Lj007873; Thu, 10 Feb 2005 13:11:08 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1A4B79C013779; Thu, 10 Feb 2005 13:11:08 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1A4B78a015735; Thu, 10 Feb 2005 13:11:07 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IBO006PWGYEKN@tsbpo1.po.toshiba.co.jp>; Thu, 10 Feb 2005 13:11:04 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1Cz0Ok-00073t-00; Wed, 09 Feb 2005 14:33:26 -0800 Date: Wed, 09 Feb 2005 17:33:25 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <0c0c01c50ed9$8d44de00$291d9069@sisa.samsung.com> To: Alper Yegin Message-id: <20050209223325.GJ25508@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <0c0c01c50ed9$8d44de00$291d9069@sisa.samsung.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Cc: "'Gerardo Giaretta'" , mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 I agree with Alper that we must identify all possible bootstrapping frameworks. I'd like to mention that draft-ohba-mip6-boot-arch-dhcp-00.txt also contains a framework for Scenario 2 of draft-giaretta-mip6-aaa-ha-goals-00.txt, and the framework should be identified. Regards, Yoshihiro Ohba On Wed, Feb 09, 2005 at 10:59:57AM -0800, Alper Yegin wrote: > Hi Gerardo, > > > > > >Before we get to listing the requirements, we (MIP6 WG) should > > > identify > > > > >different frameworks where "mip6" gets mixed up with > > > "aaa". Following > > > > >that, we can discuss which one of the frameworks we'd like to > > > > >standardize in IETF, and drive the requirements based on that. > > > > > > > > Okay. I think it is possible to have a discussion of the > frameworks > > > > based on your I-D on the ML in a constrained timeframe and > > > proceed to > > > > the next step of identifying what are the requirements for > AAA-MIP6 > > > > network elements interactions. > > > > > > The implications of some of the frameworks are not confined > > > to a AAA-HA > > > interface. For example, delivery of MIP6 information to NAS calls > for > > > new attributes for AAA server-to-NAS communication (as opposed to > AAA > > > server to HA, which requires a new AAA application). We shall > capture > > > those in the WG document as well. > > > > > > > I agree that some frameworks imply requirements also on AAAH-NAS > > communication. In draft-giaretta-mip6-aaa-ha-goals-00 we list only the > > requirements on AAA-HA interface because the goals for such an > interface > > seem to be independent from the protocol used between MN, NAS and AAA > > server (e.g. EAP, PANA, RADIUS/Diameter). > > > > I think the WG should decide if we need a draft that lists all > AAA-MIP6 > > requirements or for the moment only a draft listing the goals for the > > design of an interface between AAA and HA. > > I think the MIP6 WG should discuss all "mip6" and "aaa" work needed in > IETF. Once we agree on the work, documentation strategy can be worked > out. > > Framework 2 should be standardized at IETF. I know at least one SDO is > using that framework in a vendor-specific way. I anticipate more users > (SDOs, deployments). > > > If the WG draft has to cover all AAA-MIP6 requirements, before listing > > the goals we surely need to decide which framework(s) we want to > > address. Otherwise, if we accept to limit the scope of the WG draft to > > the AAA-HA interface, it might be possible to identify the design > goals > > for this interface in a way to address any possible framework. > > I think we must identify all possible frameworks, but not necessarily > standardize all of them at IETF. > > Alper > > > > > > > > Regards, > > --Gerardo > > > > > > > > > > > >This was the motivation behind writing > > > draft-yegin-mip6-aaa-fwk-00.txt. > > > > >4 different frameworks are mentioned in that I-D, with one being > > > > >detailed. > > > > > > > > The I-D can be a good source for the discussion itself and > > > then we can > > > > simply choose to incorporate the one that we agree on as > > > the basis for > > > > the goals I-D. > > > > > > > > > > > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend > we > > > > >capture the framework discussions. For that, my > > > recommendation is to > > > > >produce a WG I-D combining both individual I-Ds. > > > > > > > > Not sure if we really need to do a merge of the I-Ds here. > > > I think we > > > > can have a discussion on the list about the frameworks that you > > > > propose in your I-D and then based on consensus we can > > > incorporate the > > > > one that we agree on in the giaretta draft as a section. > > > > > > I'm not suggesting a full merge or anything, but to make sure > > > we address > > > various issues and angles thoroughly. If someone wants to rewrite > > > things, I don't mind :-) > > > > > > > >Besides, mip6-aaa-fwk has detailed discussions on call > > > flow (good for > > > > >finding out the exact requirements), EAP considerations, > > > why we need > > > a > > > > >new AAA application, and relation to mip6 bootstrapping -- > > > which are > > > > >worth capturing in the WG I-D. > > > > > > > > Some of this can go in an appendix of the giaretta draft. > > > > > > I think some of these discussions are for the main text. For > example, > > > the relation to MIP6 bootstrapping must be spelled out. Some parts > of > > > the mip6-aaa-ha draft gives the impression that such an interface > > > handles the MIP6 bootstrapping single-handedly. That's not always > the > > > case. Also, I think we need some words on why we need a new AAA > > > application when we already have MIP4 and EAP applications. > > > > > > For framework classification, here are my slides: > > > http://yegin.org/IETF/MIP6-AAA-fwk.ppt. This is what I missed > > > to present > > > at IETF 61. > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Alper > > > > > > > > > > > > > -Basavaraj > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > > > ==================================================================== > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please send an e_mail to > > MailAdmin@tilab.com. Thank you > > ==================================================================== > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 10 01:32:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07485 for ; Thu, 10 Feb 2005 01:32:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz8CY-0002td-DG for mip6-web-archive@ietf.org; Thu, 10 Feb 2005 01:53:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz7qp-0000hB-MN; Thu, 10 Feb 2005 01:30:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz7qL-0008WU-SH for mip6@megatron.ietf.org; Thu, 10 Feb 2005 01:30:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07428 for ; Thu, 10 Feb 2005 01:30:18 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cz8A9-0002rD-MY for mip6@ietf.org; Thu, 10 Feb 2005 01:50:57 -0500 Received: (qmail 26648 invoked by uid 104); 10 Feb 2005 06:29:38 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 7.837551 secs); 10 Feb 2005 06:29:38 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk1110801697051126601 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 7.837551 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-97.7 required=7.0 tests=AWL, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 10 Feb 2005 06:29:30 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Thu, 10 Feb 2005 14:27:56 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Thu, 10 Feb 2005 14:27:55 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3804D4AB@hcbjdc2> Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcUK4og2KJLwUVU5Q4mdYxbVSMhNdgEVeXdg From: "DENG, HUI -HCHIBJ" To: , X-OriginalArrivalTime: 10 Feb 2005 06:27:56.0906 (UTC) FILETIME=[A8C67CA0:01C50F39] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: Gerardo.Giaretta@TILAB.COM X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: quoted-printable I support this interface. But I would like to mention that in scenary 1 of this draft. MN AAAH HA <---------- IKEv2(EAP) --------> <---------> AAA-HA protocol Figure 2 - Dynamic MIPv6 bootstrapping through IKEv2 and EAP should also consider the one draft: http://www.ietf.org/internet-drafts/draft-deng-mip6-bootstrap-bcf-00.txt That is to say, there are one possibility for AAAH HA <---------> AAA-HA protocol change to two stages: Stage 1: AAAH BCF <----------> AAA-BCF protocol Stage 2: BCF / | \ / | \ HA ... HA ... HA BCF-HA Protocol In this possibility, BCF (Bootstrap Control Function) can act as the = proxy of the HA, there are mightbe one BCF for each HA, also one BCF for multiple = HAs. -Hui _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 10 06:12:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18602 for ; Thu, 10 Feb 2005 06:12:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzCZP-0000ZY-Nl for mip6-web-archive@ietf.org; Thu, 10 Feb 2005 06:33:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzC9L-0001YA-AE; Thu, 10 Feb 2005 06:06:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzC48-0007KC-8o for mip6@megatron.ietf.org; Thu, 10 Feb 2005 06:00:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17980 for ; Thu, 10 Feb 2005 06:00:52 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzCO6-0000LP-Ew for mip6@ietf.org; Thu, 10 Feb 2005 06:21:35 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AB0o0o006559; Thu, 10 Feb 2005 20:00:50 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AB0nWN006315; Thu, 10 Feb 2005 20:00:49 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AB0nsH006312; Thu, 10 Feb 2005 20:00:49 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AB0m1r000749; Thu, 10 Feb 2005 20:00:49 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AB0mF4000746; Thu, 10 Feb 2005 20:00:48 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AB0m7f004219; Thu, 10 Feb 2005 20:00:48 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AB0m93020491; Thu, 10 Feb 2005 20:00:48 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1AB0l2I020488; Thu, 10 Feb 2005 20:00:47 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id UAA01675; Thu, 10 Feb 2005 20:00:47 +0900 (JST) Message-ID: <420B3F52.3060801@lab.ntt.co.jp> Date: Thu, 10 Feb 2005 20:02:42 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Basavaraj.Patil@nokia.com, mip6@ietf.org Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt References: <456943D540CFC14A8D7138E64843F85308C794@daebe101.NOE.Nokia.com> In-Reply-To: <456943D540CFC14A8D7138E64843F85308C794@daebe101.NOE.Nokia.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id j1AB0o0o006559 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Hi all, I agree to discuss about the interface between HA and AAA. But I=92m not sure that we should describe all scenarios in one draft. IMHO, it seems to me that the purpose of mip6-aaa-ha-goalsis is not to=20 identify general framework, but to classify existing bootstrapping=20 solutions. And it seems to me that most goals except goals related with=20 bootstrapping are common to all scenarios. In order to simplify discussion, I think that we should describe=20 goal/requirement based on simple scenario at the start. After making=20 consensus of general goals, we should discuss requirement and solutions=20 which depend on each bootstrapping solution. Best Regards, --Mayumi > The goals/reasons for a standardized interface between the HA and AAA > were discussed at IETF61 in Gerardo's I-D : > draft-giaretta-mip6-aaa-ha-goals-00.txt > Such an interface is required from the perspective of bootstrapping a > MN in operator owned network environments. > > We would like to make this I-D a working group document that captures > the goals and requirements for the interface between the HA and AAA > and is used as input in the design of the bootstrapping solution that > relies on AAA. > > Please comment if you do not agree to making this a WG document and > your reasons by Feb 10th, 05. > > -Basavaraj > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 10 06:33:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19879 for ; Thu, 10 Feb 2005 06:33:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzCtP-0000xY-US for mip6-web-archive@ietf.org; Thu, 10 Feb 2005 06:53:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzCUf-0007pu-Gd; Thu, 10 Feb 2005 06:28:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzCQJ-0005wb-L5 for mip6@megatron.ietf.org; Thu, 10 Feb 2005 06:23:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19333 for ; Thu, 10 Feb 2005 06:23:48 -0500 (EST) Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzCkH-0000nH-BN for mip6@ietf.org; Thu, 10 Feb 2005 06:44:31 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1ABNWW11558; Thu, 10 Feb 2005 13:23:36 +0200 (EET) X-Scanned: Thu, 10 Feb 2005 13:21:47 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1ABLl9s030197; Thu, 10 Feb 2005 13:21:47 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00zI1S18; Thu, 10 Feb 2005 13:20:08 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1ABK7J07856; Thu, 10 Feb 2005 13:20:07 +0200 (EET) Received: from nam.ext.nokia.com ([147.243.59.4]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Feb 2005 13:20:07 +0200 Message-ID: <9544487.1108034604175.JavaMail.root@nam.ext.nokia.com> Date: Thu, 10 Feb 2005 13:23:24 +0200 (EET) From: John Loughney To: alper.yegin@samsung.com, yohba@tari.toshiba.com Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_458_3717968.1108034604159" X-OriginalArrivalTime: 10 Feb 2005 11:20:07.0532 (UTC) FILETIME=[79D7BAC0:01C50F62] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: Gerardo.Giaretta@TILAB.COM, mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f ------=_Part_458_3717968.1108034604159 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi all, I also think that covering the possible scenarios are important. I don't think that means that a solutions need to cover all of these scenarios. It might be that a specific scenario may not actually require any specific solution. There have been some discussions about different deployment models on the list earlier - I'm not sure the working group needs to develop a solution that covers all of them, as some of these models are fairly specific - I think we should have WG consensus about which scenario(s) we want to work on. John --- Original Message --- From: ext Yoshihiro Ohba To: Alper Yegin CC: 'Gerardo Giaretta' , mip6@ietf.org, Basavaraj.Patil@nokia.com Date: Thu Feb 10 00:33:25 EET 2005 Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt I agree with Alper that we must identify all possible bootstrapping frameworks. I'd like to mention that draft-ohba-mip6-boot-arch-dhcp-00.txt also contains a framework for Scenario 2 of draft-giaretta-mip6-aaa-ha-goals-00.txt, and the framework should be identified. Regards, Yoshihiro Ohba On Wed, Feb 09, 2005 at 10:59:57AM -0800, Alper Yegin wrote: > Hi Gerardo, > > > > > >Before we get to listing the requirements, we (MIP6 WG) should > > > identify > > > > >different frameworks where "mip6" gets mixed up with > > > "aaa". Following > > > > >that, we can discuss which one of the frameworks we'd like to > > > > >standardize in IETF, and drive the requirements based on that. > > > > > > > > Okay. I think it is possible to have a discussion of the > frameworks > > > > based on your I-D on the ML in a constrained timeframe and > > > proceed to > > > > the next step of identifying what are the requirements for > AAA-MIP6 > > > > network elements interactions. > > > > > > The implications of some of the frameworks are not confined > > > to a AAA-HA > > > interface. For example, delivery of MIP6 information to NAS calls > for > > > new attributes for AAA server-to-NAS communication (as opposed to > AAA > > > server to HA, which requires a new AAA application). We shall > capture > > > those in the WG document as well. > > > > > > > I agree that some frameworks imply requirements also on AAAH-NAS > > communication. In draft-giaretta-mip6-aaa-ha-goals-00 we list only the > > requirements on AAA-HA interface because the goals for such an > interface > > seem to be independent from the protocol used between MN, NAS and AAA > > server (e.g. EAP, PANA, RADIUS/Diameter). > > > > I think the WG should decide if we need a draft that lists all > AAA-MIP6 > > requirements or for the moment only a draft listing the goals for the > > design of an interface between AAA and HA. > > I think the MIP6 WG should discuss all "mip6" and "aaa" work needed in > IETF. Once we agree on the work, documentation strategy can be worked > out. > > Framework 2 should be standardized at IETF. I know at least one SDO is > using that framework in a vendor-specific way. I anticipate more users > (SDOs, deployments). > > > If the WG draft has to cover all AAA-MIP6 requirements, before listing > > the goals we surely need to decide which framework(s) we want to > > address. Otherwise, if we accept to limit the scope of the WG draft to > > the AAA-HA interface, it might be possible to identify the design > goals > > for this interface in a way to address any possible framework. > > I think we must identify all possible frameworks, but not necessarily > standardize all of them at IETF. > > Alper > > > > > > > > Regards, > > --Gerardo > > > > > > > > > > > >This was the motivation behind writing > > > draft-yegin-mip6-aaa-fwk-00.txt. > > > > >4 different frameworks are mentioned in that I-D, with one being > > > > >detailed. > > > > > > > > The I-D can be a good source for the discussion itself and > > > then we can > > > > simply choose to incorporate the one that we agree on as > > > the basis for > > > > the goals I-D. > > > > > > > > > > > > > >I have no objection to using mip6-aaa-ha-goals, but I recommend > we > > > > >capture the framework discussions. For that, my > > > recommendation is to > > > > >produce a WG I-D combining both individual I-Ds. > > > > > > > > Not sure if we really need to do a merge of the I-Ds here. > > > I think we > > > > can have a discussion on the list about the frameworks that you > > > > propose in your I-D and then based on consensus we can > > > incorporate the > > > > one that we agree on in the giaretta draft as a section. > > > > > > I'm not suggesting a full merge or anything, but to make sure > > > we address > > > various issues and angles thoroughly. If someone wants to rewrite > > > things, I don't mind :-) > > > > > > > >Besides, mip6-aaa-fwk has detailed discussions on call > > > flow (good for > > > > >finding out the exact requirements), EAP considerations, > > > why we need > > > a > > > > >new AAA application, and relation to mip6 bootstrapping -- > > > which are > > > > >worth capturing in the WG I-D. > > > > > > > > Some of this can go in an appendix of the giaretta draft. > > > > > > I think some of these discussions are for the main text. For > example, > > > the relation to MIP6 bootstrapping must be spelled out. Some parts > of > > > the mip6-aaa-ha draft gives the impression that such an interface > > > handles the MIP6 bootstrapping single-handedly. That's not always > the > > > case. Also, I think we need some words on why we need a new AAA > > > application when we already have MIP4 and EAP applications. > > > > > > For framework classification, here are my slides: > > > http://yegin.org/IETF/MIP6-AAA-fwk.ppt. This is what I missed > > > to present > > > at IETF 61. > > > > > > > > > Alper > > > > > > > > > > > > > > > > > > > > > > > > > > > > >Alper > > > > > > > > > > > > > -Basavaraj > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia > S.p.A. > > > > ==================================================================== > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please send an e_mail to > > MailAdmin@tilab.com. Thank you > > ==================================================================== > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ------=_Part_458_3717968.1108034604159 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ------=_Part_458_3717968.1108034604159-- From mip6-bounces@ietf.org Thu Feb 10 08:37:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29388 for ; Thu, 10 Feb 2005 08:37:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzEpW-0003nA-LW for mip6-web-archive@ietf.org; Thu, 10 Feb 2005 08:58:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzER4-00052Q-Qu; Thu, 10 Feb 2005 08:32:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz77b-0006C2-Nb; Thu, 10 Feb 2005 00:44:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05564; Thu, 10 Feb 2005 00:44:07 -0500 (EST) Received: from [69.72.240.66] (helo=fox.whbdns.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz7RX-0002El-Fc; Thu, 10 Feb 2005 01:04:48 -0500 Received: from wbar5.dal1-4-12-170-137.dsl-verizon.net ([4.12.170.137] helo=cow) by fox.whbdns.com with esmtpa (Exim 4.43) id 1Cz7Ek-0002p5-Ja; Thu, 10 Feb 2005 00:51:36 -0500 From: "Dawn " To: Date: Wed, 9 Feb 2005 23:43:22 -0600 Message-ID: <002801c50f33$7004aaf0$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - fox.whbdns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - icst.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: 2822ab89c35e6a93e4f72d8e025158b9 X-Mailman-Approved-At: Thu, 10 Feb 2005 08:32:44 -0500 Subject: [Mip6] Call for Papers - BroadNets 2005 (Broadband Optical Networking Symposium) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2088076553==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: e2b52ed63f0b1853d90cc5ec6749519c This is a multi-part message in MIME format. --===============2088076553== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01C50F01.256A3AF0" This is a multi-part message in MIME format. ------=_NextPart_000_0029_01C50F01.256A3AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We apologize if you receive this announcement multiple times =20 ----------------------------------------------------------------------- CALL FOR PAPERS =20 Second Annual International Conference on Broadband Networks (BROADNETS 2005) Broadband Optical Networking Symposium October 3 - 7, 2005 Boston, Massachusetts, USA http://www.broadnets.org =20 Submission Deadline Extended: February 25, 2005 ----------------------------------------------------------------------- =20 SCOPE ----- =20 BROADNETS 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with high bandwidth available for both wireless and wireline networks. =20 The conference will consist of the following three symposia: =20 ** Broadband Optical Networking Symposium: covers WDM technologies, = Ethernet and MPLS integration into the optical layer, Next-Generation SONET/SDH, = as well as SAN extensions over DWDM/SONET/SDH. =20 ** Broadband Wireless Networking Symposium: covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer = optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed wireless networking. =20 ** Broadband Applications/Services Symposium: covers middleware and = service architectures for broadband applications, pervasive computing and = ubiquitous communications, and universal broadband access for information services. =20 BROADNETS 2005 will thus offer a unique forum for researchers from = academia, government and industry to share ideas and disseminate new=20 results in these important areas. =20 This Call for Papers describes the details for the Broadband Optical Networking Symposium ONLY. (Refer to the www.broadnets.org website for the details of Broadband Wireless Symposium and Broadband Applications/Services Symposium.) We are soliciting full papers in all research, development, and deployment areas on broadband optical = networking. Topics of interest include, but not limited to, the following: =20 - Wavelength-routed WDM networks - Integration of Ethernet and RPR into the optical layer - IP and MPLS over DWDM: integration and interworking - Next-generation SONET/SDH and MSPP - SAN over SONET/SDH and DWDM - Network control and management, GMPLS - Survivability in the data, TDM or optical layers - Optical packet switching and burst switching - High-speed switch and router architectures - Optical multicasting - Standards for multi-service networks - Long-haul optical transport networks - Metropolitan and regional optical networks - Access optical networks, PONs - Optical networking for video-on-demand - Trial implementations and test-beds - Multi-layer network design and optimization - Grid computing over optical networks - Optical technologies: switching, transmission and multiplexing =20 Conference proceedings will be published by IEEE Computer Society. =20 A set of selected papers from the symposium will be published in a = special issue of Elsevier Optical Switching and Networking Journal. =20 IMPORTANT DATES --------------- =20 Submission Deadline (Extended): February 25, 2005 Acceptance Notification: May 15, 2005 Final Manuscript Due: June 1, 2005 =20 PAPER SUBMISSION INSTRUCTIONS ----------------------------- =20 Authors are invited to submit full papers of up to 10 pages in IEEE conference proceedings format. Papers should be submitted in PDF format to the respective symposium through the EDAS system at http://edas.info/Conference.cgi. =20 =20 CONFERENCE ORGANIZING COMMITTEE ------------------------------- =20 General Chair: Dr. Arun Somani, Iowa State University, arun@iastate.edu =20 General Vice Chair: Dr. Thomas Hou, Virginia Tech, thou@vt.edu =20 Technical Program Chairs - Optical Networking Symposium Dr. David Griffith, NIST, david.griffith@nist.gov Dr. Srini Ramasubramanian, University of Arizona, srini@ece.arizona.edu =20 Technical Program Chair- Wireless Networking Symposium: Dr. Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca =20 Technical Program Chairs - Services and Applications Symposium Dr. Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu Dr. Admela Jukan, Georgia Tech, admela.jukan@ece.gatech.edu =20 Workshops Chairs: Dr. Wendi Heinzelman, University of Rochester, = wheinzel@ece.rochester.edu Dr. Byrav Ramamurthy, University of Nebraska-Lincoln, byrav@cse.unl.edu Dr. Behcet Sarikaya, University of Northern British Columbia, sarikaya@unbc.ca =20 Tutorials Chair: Dr. Steven Low, CalTech., slow@caltech.edu =20 Panels Chairs: Dr. Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu Dr. Rudra Dutta, NCSU, dutta@csc.ncsu.edu =20 Publicity Chairs: Dr. Bhaskar Krishnamachari, USC, bkrishna@usc.edu Dr. Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com =20 Website/Information Systems Chair: Dr. Shiwen Mao, Virginia Tech, smao@vt.edu =20 Local Arrangements Chairs: Dr. Aura Ganz, Univ. of Massachusetts, Amherst, ganz@ecs.umass.edu Dr. Ling Li, CIENA, linlisu@hotmail.com =20 Publications Chairs: Dr. Ahmed Kamal, Iowa State University, kamal@iastate.edu Dr. Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com =20 Exhibits and Sponsorships Chair: Dr. Sai Shankar N, Philips Research USA, sai.shankar@philips.com =20 Finance Chair: Karen Decker, ICST, karen@icst.org =20 Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, Univ. of Maryland, Baltimore County, krishna@umbc.edu =20 -------------------------------------------------------------------------= - =20 =20 =20 =20 =20 ------=_NextPart_000_0029_01C50F01.256A3AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We = apologize if you receive this announcement multiple times

 

--------------------------= ---------------------------------------------

CALL = FOR PAPERS

 

Second Annual International Conference on Broadband Networks

(BROADNETS 2005)

Broadband Optical Networking Symposium

October 3 - 7, 2005

Boston, Massachusetts, USA

http://www.broadnets.org

 

Submission Deadline Extended: February 25, = 2005

--------------------------= ---------------------------------------------

 

SCOPE

-----

 

BROADNETS 2005 is an international conference focusing on broadband networking and = covers the entire gamut of next generation networks

with = high bandwidth available for both wireless and wireline = networks.

 

The = conference will consist of the following three symposia:

 

** Broadband Optical = Networking Symposium: covers WDM technologies, Ethernet and MPLS integration into = the optical layer, Next-Generation SONET/SDH, as well as SAN extensions over DWDM/SONET/SDH.

 

** Broadband Wireless = Networking Symposium: covers mobility, routing for multihop, multimedia QoS and = traffic management, cross-layer optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed wireless = networking.

 

** Broadband = Applications/Services Symposium: covers middleware and service architectures for broadband applications, pervasive computing and ubiquitous communications, and = universal broadband access for information services.

 

BROADNETS 2005 will thus offer a unique forum for researchers from academia, government = and industry to share ideas and disseminate new

results in these important areas.

 

This = Call for Papers describes the details for the Broadband Optical Networking = Symposium ONLY. (Refer to the www.broadnets.org website

for = the details of Broadband Wireless Symposium and Broadband Applications/Services Symposium.)  We are soliciting full papers in all

research, development, and deployment areas on broadband optical networking. = Topics of interest include, but not limited to, the following:

 

- = Wavelength-routed WDM networks

- = Integration of Ethernet and RPR into the optical layer

- IP = and MPLS over DWDM: integration and interworking

- Next-generation SONET/SDH and MSPP

- = SAN over SONET/SDH and DWDM

- = Network control and management, GMPLS

- = Survivability in the data, TDM or optical layers

- = Optical packet switching and burst switching

- = High-speed switch and router architectures

- = Optical multicasting

- = Standards for multi-service networks

- = Long-haul optical transport networks

- = Metropolitan and regional optical networks

- = Access optical networks, PONs

- = Optical networking for video-on-demand

- = Trial implementations and test-beds

- = Multi-layer network design and optimization

- = Grid computing over optical networks

- = Optical technologies: switching, transmission and multiplexing

 

Conference proceedings will be published by IEEE Computer = Society.

 

A = set of selected papers from the symposium will be published in a special issue = of Elsevier Optical Switching and Networking Journal.

 

IMPORTANT = DATES

---------------

 

Submission Deadline (Extended):     February 25, 2005

Acceptance Notification:        = May 15, = 2005

Final Manuscript = Due:           = June 1, = 2005

 

PAPER SUBMISSION INSTRUCTIONS

--------------------------= ---

 

Authors are invited to submit full papers of up to 10 pages in IEEE conference = proceedings format.  Papers should be submitted in PDF

format to the respective symposium through the EDAS system at = http://edas.info/Conference.cgi.

 

 

CONFERENCE ORGANIZING COMMITTEE

--------------------------= -----

 

General = Chair:

Dr. = Arun Somani, Iowa State University, arun@iastate.edu

 

General Vice Chair:

Dr. = Thomas Hou, Virginia Tech, thou@vt.edu

 

Technical Program Chairs - Optical Networking Symposium

Dr. = David Griffith, NIST, david.griffith@nist.gov

Dr. = Srini Ramasubramanian, University of Arizona, srini@ece.arizona.edu

 

Technical Program Chair- Wireless Networking Symposium:

Dr. = Sherman Shen, Univ. of Waterloo, = xshen@bbcr.uwaterloo.ca

 

Technical Program Chairs - Services and Applications Symposium

Dr. = Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu

Dr. = Admela Jukan, Georgia Tech, admela.jukan@ece.gatech.edu

 

Workshops Chairs:

Dr. = Wendi Heinzelman, University of = Rochester, wheinzel@ece.rochester.edu

Dr. = Byrav Ramamurthy, University of = Nebraska-Lincoln, byrav@cse.unl.edu

Dr. = Behcet Sarikaya, University of Northern British Columbia,

sarikaya@unbc.ca

 

Tutorials Chair:

Dr. = Steven Low, CalTech., slow@caltech.edu

 

Panels = Chairs:

Dr. = Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu

Dr. = Rudra Dutta, NCSU, dutta@csc.ncsu.edu

 

Publicity Chairs:

Dr. = Bhaskar Krishnamachari, USC, bkrishna@usc.edu

Dr. = Takeo Hamada, Fujitsu Labs of America, = thamada@fla.fujitsu.com

 

Website/Information Systems Chair:

Dr. = Shiwen Mao, Virginia Tech, smao@vt.edu

 

Local Arrangements Chairs:

Dr. = Aura Ganz, Univ. of Massachusetts, Amherst, ganz@ecs.umass.edu

Dr. = Ling Li, CIENA, linlisu@hotmail.com

 

Publications Chairs:

Dr. = Ahmed Kamal, Iowa State University, kamal@iastate.edu

Dr. = Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com

 

Exhibits and Sponsorships Chair:

Dr. = Sai Shankar N, Philips Research USA, sai.shankar@philips.com

 

Finance = Chair:

Karen Decker, ICST, karen@icst.org

 

Steering Committee Co-Chairs:

Dr. = Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu

Dr. = Krishna Sivalingam, Univ. of Maryland, Baltimore County,

krishna@umbc.edu

 

--------------------------= ------------------------------------------------

 

 

 

 

 

------=_NextPart_000_0029_01C50F01.256A3AF0-- --===============2088076553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============2088076553==-- From mip6-bounces@ietf.org Thu Feb 10 08:42:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29799 for ; Thu, 10 Feb 2005 08:42:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzEuj-0003vr-MU for mip6-web-archive@ietf.org; Thu, 10 Feb 2005 09:03:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzER7-00052u-M0; Thu, 10 Feb 2005 08:32:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz77p-0006Fb-I0; Thu, 10 Feb 2005 00:44:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05568; Thu, 10 Feb 2005 00:44:22 -0500 (EST) Received: from [69.72.240.66] (helo=fox.whbdns.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz7Rl-0002F1-QW; Thu, 10 Feb 2005 01:05:02 -0500 Received: from wbar5.dal1-4-12-170-137.dsl-verizon.net ([4.12.170.137] helo=cow) by fox.whbdns.com with esmtpa (Exim 4.43) id 1Cz7FI-0002qT-I2; Thu, 10 Feb 2005 00:52:09 -0500 From: "Dawn " To: Date: Wed, 9 Feb 2005 23:43:56 -0600 Message-ID: <002d01c50f33$843f0b00$f922fea9@cow> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Antivirus-Scanner: Clean mail though you should still use an Antivirus X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - fox.whbdns.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - icst.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: 65f9f20e6212ab1b1166e2f05fca161e X-Mailman-Approved-At: Thu, 10 Feb 2005 08:32:44 -0500 Subject: [Mip6] Call for Papers - BroadNets 2005 (Broadband Wireless Networking Symposium) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0495776245==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 3.2 (+++) X-Scan-Signature: d218084ddbe377e2f3e2feb2f1c852fb This is a multi-part message in MIME format. --===============0495776245== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C50F01.39A49B00" This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C50F01.39A49B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We apologize if you receive this announcement multiple times =20 ----------------------------------------------------------------------- CALL FOR PAPERS =20 Second Annual International Conference on Broadband Networks (BROADNETS 2005) Broadband Wireless Networking Symposium October 3 - 7, 2005 Boston, Massachusetts, USA http://www.broadnets.org =20 Submission Deadline Extended: February 25, 2005 ----------------------------------------------------------------------- =20 SCOPE ----- =20 BroadNets 2005 is an international conference focusing on broadband networking and covers the entire gamut of next generation networks with high bandwidth available for both wireless and wireline networks. = The conference will consist of the following three symposia: =20 ** Broadband Wireless Networking Symposium: covers mobility, routing for multihop, multimedia QoS and traffic management, cross-layer = optimization, MAC and emerging physical layer technologies (UWB, MIMO) for high-speed wireless networking. =20 ** Broadband Optical Networking Symposium: covers WDM technologies, = Ethernet and MPLS integration into the optical layer, Next- Generation = SONET/SDH, as well as SAN extensions over DWDM/SONET/SDH. =20 ** Broadband Applications/Services Symposium: covers middleware and = service architectures for broadband applications, pervasive computing and = ubiquitous communications, and universal broadband access for information services. =20 BroadNets 2005 will thus offer a unique forum for researchers from = academia, government and industry to share ideas and disseminate new results in these important areas. =20 This Call for Papers describes the details for the Broadband Wireless Networking Symposium ONLY. (Refer to the www.broadnets.org website for the details of Broadband Optical Symposium and Broadband Applications/Services Symposium.) We are soliciting full papers in all research, development, and deployment areas on broadband wireless networking. Topics of interest include, but not limited to, the = following: =20 - 3G/4G Systems - Fixed Broadband Wireless Access - Wireless Local Area Networks - Wireless Indoor & Home Networks - Wireless Mesh Networks - Wireless Sensor Networks - Ultra Wideband (UWB) Networks - Ad-hoc Networks - Wireless Personal Area Networks - Free-Space Optics - Internetworking Heterogeneous Wireless/Wireline Networks - Network Topology Management - Unicast and Multicast Routing - Resource Management - Neighbour Discovery - MAC Protocol Design and Analysis including IEEE 802.11/15/16 - Software-Defined Radio - Space-Time Processing, MIMO Systems - Joint Physical/MAC Design - Smart (directional) Antennas - Power Control - Mobility, Location and Handoff Management - Routing in Multihop, Ad-hoc and Sensor Networks - Multimedia QoS and Traffic Management - Security Techniques and Systems =20 Conference proceedings will be published by IEEE Computer Society. =20 A set of selected papers from the symposium will be published in a = special issue of ACM/Kluwer Mobile Networks (MONET) Journal. =20 IMPORTANT DATES --------------- =20 Submission Deadline (Extended): February 25, 2005 Acceptance Notification: May 15, 2005 Final Manuscript Due: June 1, 2005 =20 PAPER SUBMISSION INSTRUCTIONS ----------------------------- =20 Authors are invited to submit full papers of up to 10 pages in IEEE conference proceedings format. Papers should be submitted in PDF format to the respective symposium through the EDAS system at http://edas.info/Conference.cgi. =20 =20 CONFERENCE ORGANIZING COMMITTEE ------------------------------- =20 General Chair: Dr. Arun Somani, Iowa State University, arun@iastate.edu =20 General Vice Chair: Dr. Thomas Hou, Virginia Tech, thou@vt.edu =20 Technical Program Chair- Wireless Networking Symposium: Dr. Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca =20 Technical Program Chairs - Optical Networking Symposium Dr. David Griffith, NIST, david.griffith@nist.gov Dr. Srini Ramasubramanian, Univ. of Arizona, srini@ece.arizona.edu =20 Technical Program Chairs - Services and Applications Symposium Dr. Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu Dr. Admela Jukan, Georgia Tech, admela.jukan@ece.gatech.edu =20 Workshops Chairs: Dr. Wendi Heinzelman, University of Rochester, = wheinzel@ece.rochester.edu Dr. Byrav Ramamurthy, University of Nebraska-Lincoln, byrav@cse.unl.edu Dr. Behcet Sarikaya, University of Northern British Columbia, sarikaya@unbc.ca =20 Tutorials Chair: Dr. Steven Low, CalTech., slow@caltech.edu =20 Panels Chairs: Dr. Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu Dr. Rudra Dutta, NCSU, dutta@csc.ncsu.edu =20 Publicity Chairs: Dr. Bhaskar Krishnamachari, USC, bkrishna@usc.edu Dr. Takeo Hamada, Fujitsu Labs of America, thamada@fla.fujitsu.com =20 Website/Information Systems Chair: Dr. Shiwen Mao, Virginia Tech, smao@vt.edu =20 Local Arrangements Chairs: Dr. Aura Ganz, Univ. of Massachusetts, Amherst, ganz@ecs.umass.edu Dr. Ling Li, CIENA, linlisu@hotmail.com =20 Publications Chairs: Dr. Ahmed Kamal, Iowa State University, kamal@iastate.edu Dr. Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com =20 Exhibits and Sponsorships Chair: Dr. Sai Shankar N, Philips Research USA, sai.shankar@philips.com =20 Finance Chair: Karen Decker, ICST, karen@icst.org =20 Steering Committee Co-Chairs: Dr. Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu Dr. Krishna Sivalingam, Univ. of Maryland, Baltimore County, krishna@umbc.edu =20 -------------------------------------------------------------------------= - =20 =20 =20 =20 =20 ------=_NextPart_000_002E_01C50F01.39A49B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We = apologize if you receive this announcement multiple times

 

--------------------------= ---------------------------------------------

CALL = FOR PAPERS

 

Second Annual International Conference on Broadband Networks

(BROADNETS 2005)

Broadband Wireless Networking Symposium

October 3 - 7, 2005

Boston, Massachusetts, USA

http://www.broadnets.org

 

Submission Deadline Extended: February 25, = 2005

--------------------------= ---------------------------------------------

 

SCOPE

-----

 

BroadNets 2005 is an international conference focusing on broadband networking and = covers the entire gamut of next generation networks

with = high bandwidth available for both wireless and wireline networks. The = conference will consist of the following three symposia:

 

** Broadband Wireless = Networking Symposium: covers mobility, routing for multihop, multimedia QoS and = traffic management, cross-layer  optimization, MAC and emerging physical = layer technologies (UWB, MIMO) for high-speed wireless = networking.

 

** Broadband Optical = Networking Symposium: covers WDM technologies, Ethernet and MPLS integration into = the optical layer, Next-   Generation SONET/SDH, as well as SAN extensions over DWDM/SONET/SDH.

 

** Broadband = Applications/Services Symposium: covers middleware and service architectures for broadband applications, pervasive computing and ubiquitous communications, and = universal broadband access for information services.

 

BroadNets 2005 will thus offer a unique forum for researchers from academia, government and industry to share ideas and disseminate new

results in these important areas.

 

This = Call for Papers describes the details for the Broadband Wireless Networking = Symposium ONLY. (Refer to the www.broadnets.org website

for = the details of Broadband Optical Symposium and Broadband Applications/Services Symposium.)  We are soliciting full papers in all research, = development, and deployment areas on broadband wireless networking. Topics of = interest include, but not limited to, the following:

 

- = 3G/4G Systems

- = Fixed Broadband Wireless Access

- = Wireless Local Area Networks

- = Wireless Indoor & Home Networks

- = Wireless Mesh Networks

- = Wireless Sensor Networks

- = Ultra Wideband (UWB) Networks

- = Ad-hoc Networks

- = Wireless Personal Area Networks

- = Free-Space Optics

- Internetworking Heterogeneous Wireless/Wireline = Networks

- = Network Topology Management

- = Unicast and Multicast Routing

- = Resource Management

- = Neighbour Discovery

- = MAC Protocol Design and Analysis including IEEE 802.11/15/16

- = Software-Defined Radio

- = Space-Time Processing, MIMO Systems

- = Joint Physical/MAC Design

- = Smart (directional) Antennas

- = Power Control

- = Mobility, Location and Handoff Management

- = Routing in Multihop, Ad-hoc and Sensor Networks

- = Multimedia QoS and Traffic Management

- = Security Techniques and Systems

 

Conference proceedings will be published by IEEE Computer = Society.

 

A = set of selected papers from the symposium will be published in a special issue = of ACM/Kluwer Mobile Networks (MONET) Journal.

 

IMPORTANT = DATES

---------------

 

Submission Deadline (Extended):     February 25, 2005

Acceptance Notification:        = May 15, = 2005

Final Manuscript = Due:           = June 1, = 2005

 

PAPER SUBMISSION INSTRUCTIONS

--------------------------= ---

 

Authors are invited to submit full papers of up to 10 pages in IEEE conference = proceedings format.  Papers should be submitted in PDF

format to the respective symposium through the EDAS system at http://edas.info/Conference.cgi.

 

 

CONFERENCE ORGANIZING COMMITTEE

--------------------------= -----

 

General = Chair:

Dr. = Arun Somani, Iowa State University, arun@iastate.edu

 

General Vice Chair:

Dr. = Thomas Hou, Virginia Tech, thou@vt.edu

 

Technical Program Chair- Wireless Networking Symposium:

Dr. = Sherman Shen, Univ. of Waterloo, xshen@bbcr.uwaterloo.ca

 

Technical Program Chairs - Optical Networking Symposium

Dr. = David Griffith, NIST, david.griffith@nist.gov

Dr. = Srini Ramasubramanian, Univ. of = Arizona, srini@ece.arizona.edu

 

Technical Program Chairs - Services and Applications Symposium

Dr. = Malathi Veeraraghavan, Univ. of Virginia, mv@cs.virginia.edu

Dr. = Admela Jukan, Georgia Tech, admela.jukan@ece.gatech.edu

 

Workshops Chairs:

Dr. = Wendi Heinzelman, University of = Rochester, wheinzel@ece.rochester.edu

Dr. = Byrav Ramamurthy, University of = Nebraska-Lincoln, byrav@cse.unl.edu

Dr. = Behcet Sarikaya, University of Northern British Columbia,

sarikaya@unbc.ca

 

Tutorials Chair:

Dr. = Steven Low, CalTech., slow@caltech.edu

 

Panels = Chairs:

Dr. = Surendar Chandra, Univ. of Notre Dame, surendar@cse.nd.edu

Dr. = Rudra Dutta, NCSU, dutta@csc.ncsu.edu

 

Publicity Chairs:

Dr. = Bhaskar Krishnamachari, USC, bkrishna@usc.edu

Dr. = Takeo Hamada, Fujitsu Labs of America, = thamada@fla.fujitsu.com

 

Website/Information Systems Chair:

Dr. = Shiwen Mao, Virginia Tech, smao@vt.edu

 

Local Arrangements Chairs:

Dr. = Aura Ganz, Univ. of Massachusetts, Amherst, ganz@ecs.umass.edu

Dr. = Ling Li, CIENA, linlisu@hotmail.com

 

Publications Chairs:

Dr. = Ahmed Kamal, Iowa State University, kamal@iastate.edu

Dr. = Hui Zang, Sprint Adv. Tech. Labs, hzang@sprintlabs.com

 

Exhibits and Sponsorships Chair:

Dr. = Sai Shankar N, Philips Research USA, sai.shankar@philips.com

 

Finance = Chair:

Karen Decker, ICST, karen@icst.org

 

Steering Committee Co-Chairs:

Dr. = Imrich Chlamtac, UT Dallas, chlamtac@utdallas.edu

Dr. = Krishna Sivalingam, Univ. of Maryland, Baltimore County,

krishna@umbc.edu

 

--------------------------= ------------------------------------------------

 

 

 

 

 

------=_NextPart_000_002E_01C50F01.39A49B00-- --===============0495776245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0495776245==-- From mip6-bounces@ietf.org Thu Feb 10 09:11:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01974 for ; Thu, 10 Feb 2005 09:11:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzFMl-0004ZQ-Gt for mip6-web-archive@ietf.org; Thu, 10 Feb 2005 09:32:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzEro-0002lK-Me; Thu, 10 Feb 2005 09:00:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzEof-0000lb-QE for mip6@megatron.ietf.org; Thu, 10 Feb 2005 08:57:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01055 for ; Thu, 10 Feb 2005 08:57:08 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzF8g-0004H7-US for mip6@ietf.org; Thu, 10 Feb 2005 09:17:51 -0500 Received: from ipv6-5.int-evry.fr (ipv6-5.int-evry.fr [157.159.100.78]) by smtp2.int-evry.fr (Postfix) with ESMTP id 72E1C8207; Thu, 10 Feb 2005 14:56:34 +0100 (CET) Received: from jb by ipv6-5.int-evry.fr with local (Exim id 1CzEl8-0009sO-Jp; Thu, 10 Feb 2005 14:53:30 +0100 Date: Thu, 10 Feb 2005 14:53:30 +0100 From: Julien Bournelle To: Junghoon Jee Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Message-ID: <20050210135330.GF37557@ipv6-5.int-evry.fr> References: <456943D540CFC14A8D7138E64843F85308C794@daebe101.NOE.Nokia.com> <004801c50ec4$615a3d90$08faa8c0@FlyToWorld> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004801c50ec4$615a3d90$08faa8c0@FlyToWorld> X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@ipv6-5.int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Hi all, On Thu, Feb 10, 2005 at 01:28:25AM +0900, Junghoon Jee wrote: > I agree with you that this I-D can be used as input in the design of the bootstrapping > solution relying on AAA. As its name implies, the aim of this I-D is to discuss needs and requirements on the AAA-HA communication. It does not propose a solution to the boostrapping problem. However, the solution for the bootstrapping problem will certainly include a AAA-HA communication. > However, IMHO, we need to have a consensus about bootstrapping framework using AAA. > In this I-D, there are four bootstrapping scenarios. > In my opinion, the scenario 3 and 4 are not within the scope of MIPv6 bootstrapping. you are right, however even in these scenarios you can see that we may need a communication between HA and AAA. This is why I think that we can work on the AAA-HA independently of a solution to the bootstrapping problem. -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 10 14:33:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27810 for ; Thu, 10 Feb 2005 14:33:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzKOh-0003Sb-T7 for mip6-web-archive@ietf.org; Thu, 10 Feb 2005 14:54:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzJxx-0002DR-NF; Thu, 10 Feb 2005 14:27:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzJvk-0001KA-Rt for mip6@megatron.ietf.org; Thu, 10 Feb 2005 14:24:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27209 for ; Thu, 10 Feb 2005 14:24:46 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25] helo=mailout2) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzKFn-0003Gw-Go for mip6@ietf.org; Thu, 10 Feb 2005 14:45:32 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IBP00A04N8CQF@mailout2.samsung.com> for mip6@ietf.org; Fri, 11 Feb 2005 04:24:12 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBP0086ZN8CPV@mailout2.samsung.com> for mip6@ietf.org; Fri, 11 Feb 2005 04:24:12 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IBP002NRN8AMD@mmp2.samsung.com> for mip6@ietf.org; Fri, 11 Feb 2005 04:24:12 +0900 (KST) Date: Thu, 10 Feb 2005 11:24:09 -0800 From: Alper Yegin Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <20050210135330.GF37557@ipv6-5.int-evry.fr> To: "'Julien Bournelle'" , "'Junghoon Jee'" Message-id: <0dbf01c50fa6$19c202a0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org, Basavaraj.Patil@nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7BIT > Hi all, > > On Thu, Feb 10, 2005 at 01:28:25AM +0900, Junghoon Jee wrote: > > I agree with you that this I-D can be used as input in the design of the > bootstrapping > > solution relying on AAA. > > As its name implies, the aim of this I-D is to discuss needs and > requirements on the AAA-HA communication. It does not propose a solution > to the boostrapping problem. However, the solution for the bootstrapping > problem will certainly include a AAA-HA communication. > > > However, IMHO, we need to have a consensus about bootstrapping framework > using AAA. > > In this I-D, there are four bootstrapping scenarios. > > In my opinion, the scenario 3 and 4 are not within the scope of MIPv6 > bootstrapping. > > you are right, however even in these scenarios you can see that we may > need a communication between HA and AAA. > > This is why I think that we can work on the AAA-HA independently of a > solution to the bootstrapping problem. There is significant overlap between MIP6-AAA work and solving the MIP6 bootstrapping problem. Depending on the specific MIP6-AAA framework used, any one or more of the HA address, home address, or MN-HA SA can be setup using the AAA facilities. For example please see Section 4 of mip6-aaa-fwk for a relevant discussion. While doing the MIP6-AAA work, we shall keep an eye on what part of the bootstrapping problems are already solved, and tackle the rest elsewhere. Alper > > -- > julien.bournelle@int-evry.fr > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 11 08:42:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27866 for ; Fri, 11 Feb 2005 08:42:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzbOW-00074n-FU for mip6-web-archive@ietf.org; Fri, 11 Feb 2005 09:03:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzawG-0005zE-4l; Fri, 11 Feb 2005 08:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzHgy-0001GO-5N; Thu, 10 Feb 2005 12:01:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16691; Thu, 10 Feb 2005 12:01:21 -0500 (EST) Received: from struggle.mr.itd.umich.edu ([141.211.14.79]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzI0z-00004x-TE; Thu, 10 Feb 2005 12:22:07 -0500 Received: from [127.0.0.1] (c-67-182-52-27.client.comcast.net [67.182.52.27]) by struggle.mr.itd.umich.edu (smtp) with ESMTP id j1AH1GdX028820; Thu, 10 Feb 2005 12:01:19 -0500 Message-ID: <420B934F.6040003@umich.edu> Date: Thu, 10 Feb 2005 09:01:03 -0800 From: subrata goswami User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: undisclosed-recipients:; Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 11 Feb 2005 08:34:26 -0500 Subject: [Mip6] New ID for End Node Based Mobility X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit A new Internet Draft is available on mobility support in IP networks. Title: IPv4 Mobility through Peer Signaling ID: draft-goswami-mip4-peer-signaling-00.txt Abstract: This document describes a way to perform mobility in IPv4 (potentially IPv6) without requiring any new entity in networks infrastructure (e.g. Home Agent, Foreign Agent, etc.). Instead of using infrastructure entities this method delegates all the mobility function to the end nodes. The method relies on source and destination address translation at the end nodes, and signaling between end nodes to perform hand offs - all these function can be encapsulated in an entity called Mobility Agent (MA) in the end nodes. URL: https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12788 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 11 08:42:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27868 for ; Fri, 11 Feb 2005 08:42:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzbOW-00074m-F2 for mip6-web-archive@ietf.org; Fri, 11 Feb 2005 09:03:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzawG-0005zJ-G0; Fri, 11 Feb 2005 08:34:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzLoG-0000si-Mc; Thu, 10 Feb 2005 16:25:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13127; Thu, 10 Feb 2005 16:25:09 -0500 (EST) Received: from nova.ceas.rochester.edu ([128.151.162.1] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzM8L-0007OR-7L; Thu, 10 Feb 2005 16:45:57 -0500 Received: from hpn307pc2 (h318fw1.ceas.rochester.edu [128.151.164.245]) by nova.ceas.rochester.edu (8.13.1/8.13.0) with SMTP id j1ALO5DY026473; Thu, 10 Feb 2005 16:24:05 -0500 (EST) Message-ID: <005801c50fb6$e76fde60$c000a8c0@hpn307pc2> From: "Wendi Heinzelman" To: "Wendi Heinzelman" Date: Thu, 10 Feb 2005 16:24:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 11 Feb 2005 08:34:26 -0500 Subject: [Mip6] MobiCom 2005 Call for Papers-- February 22 paper registration deadline X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: 7bit ******************************************************************* Call for Papers 11th International Conference on Mobile Computing and Networking (ACM MobiCom 2005) August 28 - September 2, 2005 InterContinental Cologne Cologne, Germany http://www.cologne.intercontinental.com/ http://www.sigmobile.org/mobicom/2005/ ******************************************************************* ACM MobiCom 2005 is the eleventh in a series of annual conferences sponsored by ACM SIGMOBILE dedicated to addressing the challenges in the areas of mobile computing and networking. This highly selective, single-track conference serves as the premier international forum addressing networks, systems, algorithms, and applications that support the symbiosis of mobile computers and wireless networks. Papers Authors are invited to submit full papers presenting new research related to the theory or practice of mobile computing and networking with respect to topics above the physical layer. All submissions must describe original results that are not published nor currently under review by another conference or journal. Areas of interest include, but are not limited to: * Architectures, protocols, and algorithms to cope with mobility, limited bandwidth, or intermittent connectivity * Applications and services for mobile users * Distributed systems aspects of mobile computing * Mobile ad hoc and wireless sensor networks * Performance of mobile and wireless networks and systems * Wireless multimedia systems * Algorithms and protocols for power management and control * Implementations and experimental mobile systems * Integration and interworking of wired and wireless networks * Modeling and simulation aspects of mobile networks * Operating system and middleware support for mobile computing and networking * Security, privacy, and fault-tolerance of mobile/wireless systems * Service creation and management environments for mobile/wireless systems * Database and data management issues in mobile computing The program committee will referee all papers. Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in the ACM/Kluwer Wireless Networks (WINET) journal. Challenges Papers The conference strongly encourages the submission of short papers that challenge the research community with revolutionary new approaches, technologies, or applications in the field of mobile computing and wireless networking. These "challenge papers" should provide stimulating ideas or visions that may open up exciting avenues of far-reaching future research. Descriptions of new products or simple evolution of existing work are not appropriate. Challenges Papers will be reviewed and should be submitted using the same submission procedure as full papers. The title of such papers must start with the word "Challenges," i.e., "Challenges: `rest of the title'." Submission Instructions Papers must be no longer than 15 pages (5 pages for Challenges Papers), font size not smaller than 10 points, and must fit properly on U.S. "letter"-sized paper (8.5x11 inches) with reasonable margins. All paper submissions will be handled electronically. Authors should prepare a PDF or PostScript version. Detailed instructions for the paper submission procedure and format will be available on the conference web pages. The deadline for registering the title and the abstract of the paper with our electronic submission system is February 22, 2005, and the deadline for submitting the actual paper is March 1, 2005. All deadlines are 11:59 PM EST. All submitted papers will be judged based on their quality through a double-blind review process, where the identities of the authors are withheld from the reviewers. Authors should not be identifiable by any means from the paper or from the PDF or the Postscript file. Guidelines for preparing the paper for blind reviewing, as well as electronic paper submission instructions, will be available on the conference web pages. Submitted or substantially similar papers must not be currently under review for any other publication. Please direct any questions regarding paper submission to the Program Co-Chairs, Elizabeth Belding-Royer and Songwu Lu at mobicom_pcchairs @ acm.org. Tutorials Proposals for tutorials are solicited. Evaluation of tutorial proposals will be based on the expertise and experience of the instructors and on the relevance of the subject matter. Potential instructors are requested to submit a tutorial proposal of at most 5 pages, including a biographical sketch, to the Tutorial Chair Luca Salgarelli (luca.salgarelli at ing.unibs.it). The deadline for tutorial proposals is March 8, 2005. Panels Panel proposals are solicited that examine innovative, controversial, or otherwise provocative issues of interest. Panel proposals should not exceed 3 pages, including biographical sketches of the panelists. Potential panel organizers should contact the Panel Co-Chairs, Mario Gerla (gerla at cs.ucla.edu) and Jean-Pierre Hubaux (jean- pierre.hubaux at epfl.ch). The deadline for panel proposals is March 25, 2005. Research Demonstrations and Exhibits Proposals for research demos are strongly solicited. They should include a 3-page description of the demo and equipment to be used. Send proposals to the Research Demo Chair Dirk Westhoff (dirk.westhoff at netlab.nec.de) by June 13, 2005. We are also planning an Expo featuring exhibits of the latest mobile computing products and services. Student Poster Session Student posters are solicited that present recent and on-going research by students on mobile computing and mobile wireless networking. The poster submissions should include a 2-page description of the student's research. See above for paper formatting requirements. Accepted posters will be put on the conference web page; however, they will not be printed in the conference proceedings. Please send submissions to the Student Poster Chair Haiyun Luo (haiyun at cs.uiuc.edu). The deadline is June 20, 2005. Best Student Paper Award Papers with a student as a primary author will be considered for the Best Student Paper Award, with a cash award of 1000 US$. Students must indicate with their submission that they would like to be considered for this award. The student author of the awarded paper is expected to present the paper at the conference. Important Dates All deadlines are 11:59 PM EST. These are *firm* deadlines. Paper registration deadline: February 22, 2005 Paper submission deadline: March 1, 2005 Tutorial proposals due: March 8, 2005 Panel proposals due: March 25, 2005 Notification of acceptance: May 30, 2005 Camera-ready versions due: June 24, 2005 Demo proposals due: June 13, 2005 Student poster submissions due: June 20, 2005 For More Information For questions about the paper submission and review process, please contact the Program Co-Chairs at mobicom_pcchairs @ acm.org. For other questions or comments about the conference or for more information, please send email to mobicom_chairs @ acm.org. Organizing Committee General Co-Chairs Tom La Porta, Pennsylvania State University, USA Christoph Lindemann, University of Dortmund, Germany Program Co-Chairs Elizabeth Belding-Royer, UC, Santa Barbara, USA Songwu Lu, UCLA, USA Industrial Liaison Co-Chairs Volker Gruhn, University of Leipzig, Germany Venkat Padmanabhan, Microsoft Research, USA Finance Chair Guohong Cao, Pennsylvania State University, USA Registration Chair Sneha Kasera, University of Utah, USA Publicity Co-Chairs Christian Bettstetter, NTT DoCoMo, Germany Wendi Heinzelman, University of Rochester, USA Workshop Co-Chairs Suman Banerjee, University of Wisconsin, USA Martina Zitterbart, University of Karlsruhe, Germany Tutorial Chair Luca Salgarelli, University of Brescia, Italy Panels Co-Chairs Mario Gerla, UCLA, USA Jean-Pierre Hubaux, EPFL, Switzerland Research Demos Chair Dirk Westhoff, NEC Research Europe, Germany Student Poster Session Chair Haiyun Luo, U. of Illinois Urbana Champaign, USA Local Arrangement Chair Oliver Waldhorst, University of Dortmund, Germany Web Chair Lars Littig, University of Dortmund, Germany Steering Committee Chair Imrich Chlamtac, CreateNet Research Consortium, University of Trento, Italy University of Texas at Dallas, USA ---------------------------------------------------------- Wendi B. Heinzelman Assistant Professor of Electrical and Computer Engineering University of Rochester P.O. Box 270126, Hopeman Building, Room 307 Rochester, NY 14627-0126 Phone: 585-275-4053 Fax: 585-273-4919 http://www.ece.rochester.edu/~wheinzel ---------------------------------------------------------- _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 11 16:46:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25338 for ; Fri, 11 Feb 2005 16:46:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cziwc-0007NV-6w for mip6-web-archive@ietf.org; Fri, 11 Feb 2005 17:07:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czi1F-0005ff-5t; Fri, 11 Feb 2005 16:08:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzhRx-0002Zr-OD; Fri, 11 Feb 2005 15:31:37 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06218; Fri, 11 Feb 2005 15:31:36 -0500 (EST) Message-Id: <200502112031.PAA06218@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 11 Feb 2005 15:31:35 -0500 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-auth-protocol-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Authentication Protocol for Mobile IPv6 Author(s) : K. Leung, et al. Filename : draft-ietf-mip6-auth-protocol-04.txt Pages : 20 Date : 2005-2-11 IPsec is specified as the sole means of securing all signaling messages between the Mobile Node and Home agent for Mobile IPv6. A flexible model for security between the mobile node and home agent is required from the perspective of deployment of the Mobile IPv6 protocol. One instance of such deployment need comes from networks that are built on 3GPP2 standards. This document proposes an alternate method for securing the signaling messages that are responsible for performing Registration of a mobile node at a home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-auth-protocol-04.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-mip6-auth-protocol-04.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-mip6-auth-protocol-04.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: <2005-2-11154108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-auth-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-auth-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-11154108.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Feb 11 16:49:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25990 for ; Fri, 11 Feb 2005 16:49:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czizh-0007Zk-Lt for mip6-web-archive@ietf.org; Fri, 11 Feb 2005 17:10:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czi1I-0005gs-Pw; Fri, 11 Feb 2005 16:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzhSS-0002v6-NR; Fri, 11 Feb 2005 15:32:08 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06314; Fri, 11 Feb 2005 15:32:07 -0500 (EST) Message-Id: <200502112032.PAA06314@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Fri, 11 Feb 2005 15:32:06 -0500 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-mn-ident-option-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile Node Identifier Option for Mobile IPv6 Author(s) : K. Leung, et al. Filename : draft-ietf-mip6-mn-ident-option-02.txt Pages : 11 Date : 2005-2-11 Mobile IPv6 defines a new Mobility header which is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include NAI, FQDN, IMSI, MSISDN, etc. This document defines a new mobility option that can be used by Mobile IP6 entities to identify themselves in messages containing a mobility header. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-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-mip6-mn-ident-option-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-mip6-mn-ident-option-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: <2005-2-11154114.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-mn-ident-option-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-mn-ident-option-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-11154114.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Fri Feb 11 19:11:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15005 for ; Fri, 11 Feb 2005 19:11:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzlCn-0003jx-DQ for mip6-web-archive@ietf.org; Fri, 11 Feb 2005 19:32:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czkiw-0002jH-Qf; Fri, 11 Feb 2005 19:01:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czkh0-0001qn-RC for mip6@megatron.ietf.org; Fri, 11 Feb 2005 18:59:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14061 for ; Fri, 11 Feb 2005 18:59:19 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czl1J-0003Ut-53 for mip6@ietf.org; Fri, 11 Feb 2005 19:20:22 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1C0TCr32023 for ; Fri, 11 Feb 2005 16:29:12 -0800 X-mProtect: <200502120029> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141124.americas.nokia.com (172.18.141.124, claiming to be "[172.18.141.124]") by darkstar.iprg.nokia.com smtpd9IL67S; Fri, 11 Feb 2005 16:29:09 PST Message-ID: <420D46AB.6050406@iprg.nokia.com> Date: Fri, 11 Feb 2005 15:58:35 -0800 From: Rajeev Koodli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Mip6] IP Address Location Privacy and Mobile IPv6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hello folks, here are couple of drafts focussing on the problems of revealing CoA and HoA. They should appear in the ID pool at some point. Regards, -Rajeev http://people.nokia.net/~rajeev/draft-koodli-mip6-location-privacy-00.txt http://people.nokia.net/~rajeev/draft-koodli-mip6-location-privacy-solutions-00.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Feb 12 09:10:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03869 for ; Sat, 12 Feb 2005 09:10:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzyIq-0003gd-Nz for mip6-web-archive@ietf.org; Sat, 12 Feb 2005 09:31:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czxsu-00068b-R2; Sat, 12 Feb 2005 09:04:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzxrJ-0005QM-Ik; Sat, 12 Feb 2005 09:02:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02801; Sat, 12 Feb 2005 09:02:52 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzyBk-0003TS-GX; Sat, 12 Feb 2005 09:24:01 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j1CDvpJH001870; Sat, 12 Feb 2005 14:57:51 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1CDvpiQ009185; Sat, 12 Feb 2005 14:57:51 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRHT84>; Sat, 12 Feb 2005 14:57:51 +0100 Message-ID: From: Tschofenig Hannes To: "'ietf-enroll@mit.edu'" , "'pana@ietf.org'" , "'mip6@ietf.org'" , "'eap@frascone.com'" Date: Sat, 12 Feb 2005 14:56:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Mip6] new draft: Enriching Bootstrapping with Authorization Information X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 hi all, we (gerardo, antonio and myself) have written a document relevant for bootstrapping (which again is relevant for a number of working groups in the meanwhile). please find the draft in the indicated url (before it appears in the id-directory). ------------ Abstract Some work has been done in the area of bootstrapping in the IETF recently. Bootstrapping refers to the process of creating state (typically security associations) between two or more entities based on a trust relationship between these two or more parties and a trusted third party. So far work has mostly focused on creating security associations. This document aims to attach authorization information to the bootstrapping process. http://www.tschofenig.com/drafts/draft-tschofenig-enroll-bootstrapping-saml- 00.txt http://www.tschofenig.com/drafts/draft-tschofenig-enroll-bootstrapping-saml- 00.html ------------ ciao hannes, gerardo, antonio _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 14 03:35:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04423 for ; Mon, 14 Feb 2005 03:35:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0c2U-0003oC-PL for mip6-web-archive@ietf.org; Mon, 14 Feb 2005 03:57:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0bce-0002jt-7H; Mon, 14 Feb 2005 03:30:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0bbl-0002fh-I5 for mip6@megatron.ietf.org; Mon, 14 Feb 2005 03:29:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04119; Mon, 14 Feb 2005 03:29:27 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0bwZ-0003hn-24; Mon, 14 Feb 2005 03:50:59 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1E8TGW22648; Mon, 14 Feb 2005 10:29:16 +0200 (EET) X-Scanned: Mon, 14 Feb 2005 10:28:07 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1E8S7dh021498; Mon, 14 Feb 2005 10:28:07 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00D4psEz; Mon, 14 Feb 2005 10:27:40 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1E86tM12312; Mon, 14 Feb 2005 10:06:55 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Feb 2005 02:06:51 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2005 02:06:49 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C7F6@daebe101.NOE.Nokia.com> Thread-Topic: Request to progress I-D: draft-ietf-mip6-mn-ident-option-02.txt Thread-Index: AcUSbCJq66yGMDNoSgOTxL3ZAPK5GQ== To: , , X-OriginalArrivalTime: 14 Feb 2005 08:06:51.0854 (UTC) FILETIME=[23EEAEE0:01C5126C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable Cc: gdommety@cisco.com, mip6@ietf.org Subject: [Mip6] Request to progress I-D: draft-ietf-mip6-mn-ident-option-02.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Hello, The following I-D has completed WG last call and we would like to request the ADs to review the I-D and progress it forward. Details below: WG: MIP6 Title: Mobile Node Identifier Option for Mobile IPv6 I-D: draft-ietf-mip6-mn-ident-option-02.txt Status requested: Standards track 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication?=20 Yes. The chairs have reviewed it not only for technical correctness but also for spelling and grammar. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes. The I-D has been reviewed sufficiently by WG members. As WG chairs, we do not have any concerns about the depth or breadth of reviews that this I-D has had. The I-D is fairly straightforward and does not have a great deal of complexity. 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?=20 No. The I-D proposes the use of identifiers such as NAI, FQDN etc. in the mobility header of MIP6 signaling messages. There is not a need for broader review at this time. Especially since a similar concept is used today in MIP4. =20 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. No specific concerns/issues. It should be noted that this I-D is needed by 3GPP2 for Revision D of the TIA-835 specification which is currently being worked on. =20 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG as a whole understands the need for this I-D and there is strong support for standardizing it. 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. There have been no appeals against this I-D. =20 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes.=20 =20 8) Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note: the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) The document includes 3 normative references. Of these 2 are already RFCs. The 3rd is a reference to RFC2486bis (Radext WG) which is currently in state: AD Followup.=20 9) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary Mobile IPv6 defines a new Mobility header which is used by mobile nodes, correspondent nodes, and home agents in all messaging related to the creation and management of bindings. Mobile IPv6 nodes need the capability to identify themselves using an identity other than the default home IP address. Some examples of identifiers include NAI, FQDN, IMSI, MSISDN, etc. This document defines a new mobility option that can be used by Mobile IP6 entities to identify themselves in messages containing a mobility header. - Working Group Summary The working group has discussed the need for such an identifier at several WG meetings as well as on the mailing list. The need for alternate identifiers such as NAI, IMSI etc. arises from the deployment needs of Mobile IPv6 by 3GPP2. 3GPP2 specification 835-Rev D is currently being worked on and this feature has been identified as a necessity for incorporating Mobile IPv6 in the standard. WG LC has been completed. No major issues were identified during the last call process.=20 - Protocol Quality No known implementations of the protocol exist at this time. However there exist plans to implement this protocol since it is required for deployment in 3GPP2 based networks. Revision D of TIA 835 specifies the need for such an identifier to be included in the mobility header of the registration messages.=20 =20 -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 14 05:32:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12443 for ; Mon, 14 Feb 2005 05:32:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0drc-000697-Ps for mip6-web-archive@ietf.org; Mon, 14 Feb 2005 05:54:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0dV2-0003Gn-4k; Mon, 14 Feb 2005 05:30:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0dQ9-0002kf-UJ for mip6@megatron.ietf.org; Mon, 14 Feb 2005 05:25:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11959; Mon, 14 Feb 2005 05:25:35 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0dkt-00062l-Oy; Mon, 14 Feb 2005 05:47:08 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1EAO7928223; Mon, 14 Feb 2005 12:24:07 +0200 (EET) X-Scanned: Mon, 14 Feb 2005 12:16:42 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1EAGgRn031689; Mon, 14 Feb 2005 12:16:42 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 001ccSsA; Mon, 14 Feb 2005 12:14:54 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1EA0FM04947; Mon, 14 Feb 2005 12:00:15 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Feb 2005 04:00:13 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Feb 2005 04:00:12 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C7F7@daebe101.NOE.Nokia.com> Thread-Topic: Request to progress I-D: draft-ietf-mip6-mn-ident-option-02.txt Thread-Index: AcUSbCJq66yGMDNoSgOTxL3ZAPK5GQ== To: , , X-OriginalArrivalTime: 14 Feb 2005 10:00:13.0576 (UTC) FILETIME=[FA131880:01C5127B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Cc: gdommety@cisco.com, mip6@ietf.org Subject: [Mip6] Request to progress I-D: draft-ietf-mip6-auth-protocol-04.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: quoted-printable Hello, The following I-D has completed WG LC and is ready to be progressed through the IESG. Title: Authentication Protocol for Mobile IPv6=20 I-D: draft-ietf-mip6-auth-protocol-04.txt Status: Informational 1) Have the chairs personally reviewed this version of the ID and do they believe this ID is sufficiently baked to forward to the IESG for publication?=20 The chairs have reviewed the I-D and suggested changes/corrections to the authors which have been incorporated in the above revision of the I-D. There has been a good deal of discussion as a result of the WG LC and prior to it as well on the WG mailing list. The I-D is sufficiently baked for IESG consideration and publication. 2) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? The I-D has been reviewed sufficiently by key WG members. Several people from other WGs such as v6ops have reviewed the I-D as well. We (Chairs) are satisfied with the degree of review in terms of depth and breadth.=20 3) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)?=20 There have been some concerns regarding security especially the replay protection. However there has been a good deal of discussion on this topic and has been adequately dealt with in the I-D. A broader review of this I-D is not essential at this time. Operational aspects as well as deployment in scenarios that use AAA have been also thought out. =20 =20 4) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or whether there really is a need for it, etc., but at the same time these issues have been discussed in the WG and the WG has indicated it wishes to advance the document anyway. No specific concerns/issues with any part of this I-D.=20 =20 5) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is a fairly strong consensus to progress this I-D on an Informational track. Most people in the WG understand the reason for this I-D. It should also be noted that this I-D is a requirement for 3GPP2s 835 Revision D specification.=20 6) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize what are they upset about. There has been an appeal on progressing this I-D on standards track. The appeal was made to the ADs prior to IETF61 and was resolved at the WG meeting. The conclusion was to progress this I-D on an Informational track. =20 7) Have the chairs verified that the document adheres to _all_ of the ID nits? (see http://www.ietf.org/ID-nits.html). Yes. =20 8) Does the document a) split references into normative/informative, and b) are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (Note: the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) The I-D has only normative references. There is a normative reference to I-D: draft-ietf-mip6-mn-ident-option. However that I-D is also being put before the IESG at the same time, and both should be progressed in parallel. =20 9) For Standards Track and BCP documents, the IESG approval announcement includes a writeup section with the following sections: - Technical Summary - Working Group Summary - Protocol Quality This is an Informational track I-D. -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 14 17:29:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26989 for ; Mon, 14 Feb 2005 17:29:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0p3z-00076O-Me for mip6-web-archive@ietf.org; Mon, 14 Feb 2005 17:51:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0ohV-0000fT-A1; Mon, 14 Feb 2005 17:28:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0obb-0008Cy-L5 for mip6@megatron.ietf.org; Mon, 14 Feb 2005 17:22:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26220 for ; Mon, 14 Feb 2005 17:22:08 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0owV-0006sF-TW for mip6@ietf.org; Mon, 14 Feb 2005 17:43:48 -0500 Message-ID: <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Mon, 14 Feb 2005 14:23:06 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit So far as I can tell, the only comments on this concensus call have been from authors of similar drafts. Here's my 0.02 yen (I'm not an author of a similar draft). As I high level comment, I think we need to consider exactly what the purpose of defining any requirements for standardization of the HA-AAA interface are, and similarly for any other AAA interfaces (like HA-AAA-NAS/DHCP server). From a service provider perspective, I believe the top level goal should be to facilitate inter-operator roaming. That is, the interface is primarily defined so that a roaming user can obtain mobility service on a foreign network by being able to bootstrap on the foreign network (both HA and IPsec SA). The reason is because we need to have interoperability between operators' networks; otherwise, roaming isn't possible. I don't think the primary motivation should be to define an interface within a service provider's network. Modulo vendor interoperability, a service provider should be able to use any protocols they want to provision within their own network (including those between networks), and we should make sure data models such as MIBs reflect this goal, but we shouldn't define protocols for it. With that in mind, I think draft-giaretta does a good job of breaking out the different scenarios and provides a good collection of requirements of sufficient specificity. I support the call for making it a WG draft. Something I think it is lacking and that should be added for each of the scenarios is the high level, functional protocol flows in draft-yegin, for example, Fig. 2. This should give a better idea about what protocols are involved and which need modification or enhancement, especially from an optimization standpoint. Personally, I don't see the need to define a HA-AAA-NAS/DHCP interface, as draft-ohba recommends, because I believe this is and should remain an intra-operator interface that should not cross administrative boundaries. As I mentioned in San Diego and Washington, DC, I don't believe inter-domain AA A flows to the DHCP server or NAS should be used for inter-domain bootstrapping due to the complexity involved in carrying the configuration information between network operator domains and making sure it is consistent. I don't believe anything needs to be standardized for intra-domain bootstrapping using DHCP except for the format of the record in DHCP for the MIP6 information, which impacts the MN-DHCP server interface. In a roaming situation, a home IMSP can indicate during the network access authentication that the MN should bootstrap off the local DHCP server, if a local HA, is available through the AAA-H to MN protocol (i.e. end to end), without having to do anything through the local DHCP server itself. For a nonintegrated MSP, the mobility service is being provided by the MSP itself, it becomes a bit more difficult to do local HA service, since there is no way the DNS SRV RR can be specialized to the local domain, but there are some other possibilities (like preprovisioning the MN with domain names where local service is available, like iPASS does with telephone numbers of NASes). jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 01:48:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05717 for ; Tue, 15 Feb 2005 01:48:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0wqG-0004F1-O0 for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 02:09:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0wTJ-00060u-Qf; Tue, 15 Feb 2005 01:46:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0wSM-0005vo-OY for mip6@megatron.ietf.org; Tue, 15 Feb 2005 01:45:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05470 for ; Tue, 15 Feb 2005 01:45:09 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0wnL-0004An-MM for mip6@ietf.org; Tue, 15 Feb 2005 02:06:52 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IBX00G6AXE934@mailout2.samsung.com> for mip6@ietf.org; Tue, 15 Feb 2005 15:44:33 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IBX00MIEXE71H@mailout2.samsung.com> for mip6@ietf.org; Tue, 15 Feb 2005 15:44:31 +0900 (KST) Received: from Alperyegin ([105.253.155.12]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IBX00GK8XE4PT@mmp2.samsung.com> for mip6@ietf.org; Tue, 15 Feb 2005 15:44:31 +0900 (KST) Date: Mon, 14 Feb 2005 22:44:19 -0800 From: Alper Yegin In-reply-to: <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> To: mip6@ietf.org Message-id: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7BIT Subject: [Mip6] mip6-aaa frameworks X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7BIT This is an attempt to enumerate possible MIP6-AAA frameworks, and start discussions on for which one(s) IETF shall pursue standardization. Framework 1: ------------ Using network access AAA to deliver MIP6 configuration parameters from the AAA server to the MN. MIP6 configuration is directly delivered from the AAA server to the MN during network access AAA, in-band with the authentication (e.g., transported by EAP or EAP methods). Related I-Ds: draft-giaretta-mip6-authorization-eap-01 draft-le-aaa-mipv6-requirements-03 draft-ohnishi-mip6-aaa-problem-statement-00 Discussion: The end2end transport between the AAA and the MN is the key. Use of EAP for this somewhat network access unrelated "configuration" is not recommended as far as I understand. One can design his own EAP method to do that, yet that would have limited applicability. Framework 2: ------------ Using network access AAA to deliver MIP6 configuration parameters from the AAA server to the NAS. It is assumed that parameters will be delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, etc.) Related I-Ds: draft-chowdhury-mip6-bootstrap-radius-00 draft-jang-dhc-haopt-00 Discussion: This is similar to NAS learning the IP address for the connected host via RADIUS, and delivering it to the host via DHCP. James had a comment regarding not having to support intra-operator interoperability. I think regardless of the deployment, interoperability between vendors is the important. Also, I was not sure on the complexity argument. 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the suit. Framework 3: ------------ Piggybacking MIP6 signaling (BU) with network access AAA. In-band with the network access authentication execution, the MN delivers (piggybacks) a BU to the AAA server. The AAA server may have to relay the BU to the HA (unless collocated). Related I-D: draft-le-aaa-mipv6-requirements-03 Discussion: While the performance benefits are clear, limited applicability (not always the network access and mobility services are bundled) and complexity are concerning. Framework 4: ------------ A backend AAA protocol is executed between the HA and the AAA server in response to the MIP6 signaling between the MN and the HA. Similar to the use of AAA protocols with MIPv4 co-located care-of address case. Related I-Ds: draft-giaretta-mip6-aaa-ha-goals-00.txt draft-yegin-mip6-aaa-fwk-00.txt Discussion: This one appears to be the most needed framework. It is assumed that MN already knows the HA address. Are there other frameworks to add? I am sure I have missed some references, please let us know which ones. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 05:38:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15343 for ; Tue, 15 Feb 2005 05:38:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D10R1-0000cF-Ck for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 06:00:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D103U-0008K0-D8; Tue, 15 Feb 2005 05:35:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0zxe-0007dL-Tv for mip6@megatron.ietf.org; Tue, 15 Feb 2005 05:29:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14823 for ; Tue, 15 Feb 2005 05:29:40 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D10If-0000RQ-Er for mip6@ietf.org; Tue, 15 Feb 2005 05:51:26 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FATXc17051 for ; Tue, 15 Feb 2005 12:29:35 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 12:39:27 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1FAdRAT007835 for ; Tue, 15 Feb 2005 12:39:27 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00l4Zr5k; Tue, 15 Feb 2005 12:39:26 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FA8uM00972 for ; Tue, 15 Feb 2005 12:08:56 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 04:08:55 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Feb 2005 04:08:53 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C7FF@daebe101.NOE.Nokia.com> Thread-Topic: IETF62: Timeslot requests on mip6 agenda Thread-Index: AcUTRlpWIaDw82xAS2miiqQn/j6NVA== To: X-OriginalArrivalTime: 15 Feb 2005 10:08:55.0469 (UTC) FILETIME=[5B8F65D0:01C51346] X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] IETF62: Timeslot requests on mip6 agenda X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Hello, If you need a timeslot for presenting at the MIP6 WG meeting in Minneapolis (IETF62), please send the same to the chairs. Note that WG items have priority. It is essential that you have an I-D that has been submitted=20 in order to get a slot on the agenda. Please state why this I-D is relevant to the MIP6 WG in the request along with the duration of time needed. -Basavaraj _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 05:55:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17171 for ; Tue, 15 Feb 2005 05:55:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D10hG-00013s-5m for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 06:16:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D10K4-0002IO-CD; Tue, 15 Feb 2005 05:52:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D10If-00029C-Ac for mip6@megatron.ietf.org; Tue, 15 Feb 2005 05:51:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16703 for ; Tue, 15 Feb 2005 05:51:23 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D10df-0000wx-Vd for mip6@ietf.org; Tue, 15 Feb 2005 06:13:09 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FApAc25321; Tue, 15 Feb 2005 12:51:13 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 12:57:38 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1FAvcL3011577; Tue, 15 Feb 2005 12:57:38 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00EUiWQC; Tue, 15 Feb 2005 12:57:36 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FAjJM12484; Tue, 15 Feb 2005 12:45:19 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 12:43:03 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 12:43:02 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Tue, 15 Feb 2005 12:43:02 +0200 Message-ID: Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcUS5QQVvYeq7nP6QkGpGtxKxz1DhAAZafLw To: , X-OriginalArrivalTime: 15 Feb 2005 10:43:02.0768 (UTC) FILETIME=[1FD86F00:01C5134B] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable James, Before going into detail about your mail, can you clarify one thing: > As I high level comment, I think we need to consider exactly what the > purpose of defining any requirements for standardization of the HA-AAA > interface are, and similarly for any other AAA interfaces (like > HA-AAA-NAS/DHCP server). From a service provider perspective, I = believe the > top level goal should be to facilitate inter-operator roaming.=20 I would say this is too simplistic. I agree that facilitating = inter-operator roaming is a good thing, but I think we need to also consider = intra-operator roaming as well. Its a complicated business landscape at the moment, = mergers, acquisitions, etc. Its likely that a service provider may have more = than one access technology, maybe more than one AAA system, or they may have = some relationship with a parent, sister or daughter company. I think getting = a=20 solution that works for inter-operator and intra-operator roaming would = be a good thing. Do you think that this is within your proposal? John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 06:02:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17784 for ; Tue, 15 Feb 2005 06:02:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D10ok-0001Ee-VV for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 06:24:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D10SE-0003NE-B9; Tue, 15 Feb 2005 06:01:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D10Qv-0003Cf-V7 for mip6@megatron.ietf.org; Tue, 15 Feb 2005 05:59:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17576 for ; Tue, 15 Feb 2005 05:59:55 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D10lu-0001Ay-HE for mip6@ietf.org; Tue, 15 Feb 2005 06:21:41 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FAxqr17468; Tue, 15 Feb 2005 12:59:52 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 13:09:30 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1FB9UTx021023; Tue, 15 Feb 2005 13:09:30 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00E7Xllr; Tue, 15 Feb 2005 13:09:28 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FAkdM13909; Tue, 15 Feb 2005 12:46:39 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 12:45:56 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 12:45:55 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Tue, 15 Feb 2005 12:45:55 +0200 Message-ID: Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcUS5QQVvYeq7nP6QkGpGtxKxz1DhAAZiPDw To: , X-OriginalArrivalTime: 15 Feb 2005 10:45:55.0718 (UTC) FILETIME=[86EE8260:01C5134B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable One more comment. > Personally, I don't see the need to define a HA-AAA-NAS/DHCP = interface, as > draft-ohba recommends, because I believe this is and should remain an > intra-operator interface that should not cross administrative = boundaries.=20 For this, is this a SHOULD or do you mean should =3D usually doesn't? = At least talking to some carriers, they do currently have very strong = adminstrative boundries between their cellular networks and non-cellular networks = (WLAN, DSL, etc.). Philosophically, cellular networks are often seen as high-value = networks, often ones that are regulated quite strongly, not to mention issues = about licensing, etc. Therefore, some operators feel that they need to administer these = networks seperately. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 06:15:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18840 for ; Tue, 15 Feb 2005 06:15:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1111-0001Un-ED for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 06:37:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D10bz-0004H7-5z; Tue, 15 Feb 2005 06:11:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D10Wu-0003qI-Ix for mip6@megatron.ietf.org; Tue, 15 Feb 2005 06:06:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18097 for ; Tue, 15 Feb 2005 06:06:06 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D10rw-0001IB-DI for mip6@ietf.org; Tue, 15 Feb 2005 06:27:52 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 88B428131; Tue, 15 Feb 2005 12:05:35 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.34) id 1D10Vs-0001fo-Qh; Tue, 15 Feb 2005 12:05:04 +0100 Date: Tue, 15 Feb 2005 12:05:04 +0100 From: Julien Bournelle To: Alper Yegin Subject: Re: [Mip6] mip6-aaa frameworks Message-ID: <20050215110504.GD6344@ipv6-3.int-evry.fr> References: <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> User-Agent: Mutt/1.5.6+20040907i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 hi alper, all, thanks for this enumeration. I've just added some references to your proposed framework and some comments. On Mon, Feb 14, 2005 at 10:44:19PM -0800, Alper Yegin wrote: > > Framework 1: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the MN. > > MIP6 configuration is directly delivered from the AAA server to the MN > during network access AAA, in-band with the authentication (e.g., > transported by EAP or EAP methods). > > Related I-Ds: > > draft-giaretta-mip6-authorization-eap-01 > draft-le-aaa-mipv6-requirements-03 > draft-ohnishi-mip6-aaa-problem-statement-00 > > > The end2end transport between the AAA and the MN is the key. Use of EAP > for this somewhat network access unrelated "configuration" is not > recommended as far as I understand. I'd like to understand why this is not recommended. Because it has not been designed for this purpose ? > Framework 2: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the NAS. It is assumed that parameters will be > delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, > etc.) > > Related I-Ds: > > draft-chowdhury-mip6-bootstrap-radius-00 > draft-jang-dhc-haopt-00 we can add: draft-jee-mip6-bootstrapping-pana-00.txt (PANA between MN and PAA and a specific Diameter Mobile IPv6 application between PAA and AAA) > Discussion: > > This is similar to NAS learning the IP address for the connected host > via RADIUS, and delivering it to the host via DHCP. > > James had a comment regarding not having to support intra-operator > interoperability. I think regardless of the deployment, interoperability > between vendors is the important. Also, I was not sure on the complexity > argument. > > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the > suit. > > Framework 3: > ------------ > Piggybacking MIP6 signaling (BU) with network access AAA. In-band with > the network access authentication execution, the MN delivers > (piggybacks) a BU to the AAA server. The AAA server may have to relay > the BU to the HA (unless collocated). > > Related I-D: > > draft-le-aaa-mipv6-requirements-03 > > Discussion: > > While the performance benefits are clear, limited applicability (not > always the network access and mobility services are bundled) and > complexity are concerning. I'm not sure that this is a particular framework since the BU is carried in the AAA protocol. This piggybacking can be done with Framewrok 1 and 2. > > > Framework 4: > ------------ > A backend AAA protocol is executed between the HA and the AAA server in > response to the MIP6 signaling between the MN and the HA. Similar to the > use of AAA protocols with MIPv4 co-located care-of address case. > > Related I-Ds: > > draft-giaretta-mip6-aaa-ha-goals-00.txt > draft-yegin-mip6-aaa-fwk-00.txt I would add: draft-chakrabati-mip6-bmip-00.txt (DNS to discover HA + IKEv2 and AAA-HA) draft-tschofenig-mip6-bootstrapping-pana (needs to relax PANA on the one IP hop between PaC and PAA) assumption > Discussion: > This one appears to be the most needed framework. It is assumed that MN > already knows the HA address. > > > Are there other frameworks to add? I also wrote a proposition draft-bournelle-pana-mip6-00. This proposition rely on PANA. The PAA is in charge of allocating the HA and of providing necessary information to HA and MN. The problem with this approach is that the HA allocation is only in the visited domain. However, the idea is that the AAA server explicitely authorize the service but delegate configuration process to an agent. Do you think that we can make a framework with this ? -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 06:27:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19532 for ; Tue, 15 Feb 2005 06:27:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D11Ce-0001iu-3m for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 06:49:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D10px-0005YY-El; Tue, 15 Feb 2005 06:25:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D10ns-0005ON-IC for mip6@megatron.ietf.org; Tue, 15 Feb 2005 06:23:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19348 for ; Tue, 15 Feb 2005 06:23:37 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D118s-0001eJ-Ef for mip6@ietf.org; Tue, 15 Feb 2005 06:45:23 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FBNVr29147; Tue, 15 Feb 2005 13:23:31 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 13:23:23 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1FBNNGX007428; Tue, 15 Feb 2005 13:23:23 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00XSIKft; Tue, 15 Feb 2005 13:23:22 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FBNMJ19067; Tue, 15 Feb 2005 13:23:22 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 13:22:11 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 13:22:11 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] mip6-aaa frameworks Date: Tue, 15 Feb 2005 13:22:10 +0200 Message-ID: Thread-Topic: [Mip6] mip6-aaa frameworks Thread-Index: AcUTUBd6hZWWvLKyQWeMI7STv8PxQwAACPsQ To: , X-OriginalArrivalTime: 15 Feb 2005 11:22:11.0729 (UTC) FILETIME=[97EF7010:01C51350] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Hi Julien, > > The end2end transport between the AAA and the MN is the key. Use of = EAP > > for this somewhat network access unrelated "configuration" is not > > recommended as far as I understand.=20 >=20 > I'd like to understand why this is not recommended. Because it has not > been designed for this purpose ? EAP is not a configuration protocol, it is an authentication protocol. RFC 3748 (http://www.ietf.org/rfc/rfc3748.txt) says: EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED. Since EAP does not require IP connectivity, it provides just enough support for the reliable transport of authentication protocols, and no more. So that is why many people feel that using EAP would not be a good idea = here. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 07:37:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25241 for ; Tue, 15 Feb 2005 07:37:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D12Hv-0003G6-Hg for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 07:58:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D11sH-0004xe-JU; Tue, 15 Feb 2005 07:32:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D11qG-0004mK-Ao for mip6@megatron.ietf.org; Tue, 15 Feb 2005 07:30:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24710 for ; Tue, 15 Feb 2005 07:30:10 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D12BG-00037A-PQ for mip6@ietf.org; Tue, 15 Feb 2005 07:51:56 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j1FCU7FF016599; Tue, 15 Feb 2005 13:30:07 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1FCU6iQ005993; Tue, 15 Feb 2005 13:30:06 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNR26FL>; Tue, 15 Feb 2005 13:30:06 +0100 Message-ID: From: Tschofenig Hannes To: "'Alper Yegin'" , mip6@ietf.org Subject: AW: [Mip6] mip6-aaa frameworks Date: Tue, 15 Feb 2005 13:28:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Content-Transfer-Encoding: quoted-printable hi alper,=20 thanks for your classification attempt.=20 in http://www.tschofenig.com/drafts/draft-tschofenig-enroll-bootstrapping-s= aml- 00.txt we also tried to create a classification. you might want to take = a look at section 3. please take a look at this figure: +---------------+ +---------------+ | | (A) | | | Bootstrapping |<-------------------> | Bootstrapping | | Client (BC) | Protocol or | Agent (BA) | | | API | | +---------------+ +---------------+ ^ | Protocol or |(B) API | v +---------------+ | | | Bootstrapping | | Target (BT) | | | +---------------+ we think that there are three categories to consider: o Which protocol is used between the BC and the BA? o Which protocol is used between the BA and the BT? o What information is bootstrapped? we have also tried to classify a few proposals (as listed in the draft) according to these questions.=20 to us it seems that the most important question is which protocol is = used between BC and BA (some proposals even use two protocols). since a number of proposals have been published that want to bootstrap something we think that a proposal that is a bit more generic would be = quite helpful here. in http://www.ietf.org/internet-drafts/draft-tschofenig-enroll-next-steps-0= 0.tx t we argue that this might be job for enroll to look at.=20 finally, the protocol used for communication between the BA and the BT = is in many cases interchangeable.=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: Alper Yegin [mailto:alper.yegin@samsung.com]=20 > Gesendet: Dienstag, 15. Februar 2005 07:44 > An: mip6@ietf.org > Betreff: [Mip6] mip6-aaa frameworks >=20 >=20 >=20 > This is an attempt to enumerate possible MIP6-AAA frameworks,=20 > and start > discussions on for which one(s) IETF shall pursue standardization.=20 >=20 > Framework 1: > ------------ > Using network access AAA to deliver MIP6 configuration parameters = from > the AAA server to the MN.=20 >=20 > MIP6 configuration is directly delivered from the AAA server to the = MN > during network access AAA, in-band with the authentication (e.g., > transported by EAP or EAP methods). >=20 > Related I-Ds: >=20 > draft-giaretta-mip6-authorization-eap-01 > draft-le-aaa-mipv6-requirements-03 > draft-ohnishi-mip6-aaa-problem-statement-00 >=20 > Discussion: >=20 > The end2end transport between the AAA and the MN is the key.=20 > Use of EAP > for this somewhat network access unrelated "configuration" is not > recommended as far as I understand. One can design his own=20 > EAP method to > do that, yet that would have limited applicability. >=20 >=20 > Framework 2: > ------------ > Using network access AAA to deliver MIP6 configuration parameters = from > the AAA server to the NAS. It is assumed that parameters will be > delivered from the NAS to the MN via another protocol (e.g.,=20 > DHCP, PANA, > etc.) >=20 > Related I-Ds: >=20 > draft-chowdhury-mip6-bootstrap-radius-00 > draft-jang-dhc-haopt-00 >=20 > Discussion: >=20 > This is similar to NAS learning the IP address for the connected host > via RADIUS, and delivering it to the host via DHCP. >=20 > James had a comment regarding not having to support intra-operator > interoperability. I think regardless of the deployment,=20 > interoperability > between vendors is the important. Also, I was not sure on the=20 > complexity > argument. >=20 > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow = the > suit. >=20 > Framework 3: > ------------ > Piggybacking MIP6 signaling (BU) with network access AAA. In-band = with > the network access authentication execution, the MN delivers > (piggybacks) a BU to the AAA server. The AAA server may have to relay > the BU to the HA (unless collocated). =20 >=20 > Related I-D: >=20 > draft-le-aaa-mipv6-requirements-03 >=20 > Discussion: >=20 > While the performance benefits are clear, limited applicability (not > always the network access and mobility services are bundled) and > complexity are concerning. >=20 >=20 > Framework 4: > ------------ > A backend AAA protocol is executed between the HA and the AAA=20 > server in > response to the MIP6 signaling between the MN and the HA.=20 > Similar to the > use of AAA protocols with MIPv4 co-located care-of address case. >=20 > Related I-Ds: >=20 > draft-giaretta-mip6-aaa-ha-goals-00.txt > draft-yegin-mip6-aaa-fwk-00.txt >=20 > Discussion: > This one appears to be the most needed framework. It is=20 > assumed that MN > already knows the HA address.=20 >=20 >=20 > Are there other frameworks to add? >=20 > I am sure I have missed some references, please let us know=20 > which ones. >=20 > Alper >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 07:46:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26179 for ; Tue, 15 Feb 2005 07:46:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D12R0-0003d2-RS for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 08:08:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D123l-0006G0-NF; Tue, 15 Feb 2005 07:44:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D11zz-0005oc-Aw for mip6@megatron.ietf.org; Tue, 15 Feb 2005 07:40:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25600 for ; Tue, 15 Feb 2005 07:40:14 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D12L0-0003Tj-So for mip6@ietf.org; Tue, 15 Feb 2005 08:02:00 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id ABD22813A; Tue, 15 Feb 2005 13:39:33 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.34) id 1D11yo-0000S0-SD; Tue, 15 Feb 2005 13:39:02 +0100 Date: Tue, 15 Feb 2005 13:39:02 +0100 From: Julien Bournelle To: john.loughney@nokia.com Subject: Re: [Mip6] mip6-aaa frameworks Message-ID: <20050215123902.GK6344@ipv6-3.int-evry.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: alper.yegin@samsung.com, julien.bournelle@int-evry.fr, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hi john, On Tue, Feb 15, 2005 at 01:22:10PM +0200, john.loughney@nokia.com wrote: > EAP is not a configuration protocol, it is an authentication protocol. > RFC 3748 (http://www.ietf.org/rfc/rfc3748.txt) says: > > EAP was designed for use in network access authentication, where IP > layer connectivity may not be available. Use of EAP for other > purposes, such as bulk data transport, is NOT RECOMMENDED. > > Since EAP does not require IP connectivity, it provides just enough > support for the reliable transport of authentication protocols, and > no more. > > So that is why many people feel that using EAP would not be a good idea here. In our proposal, we use EAP for network access authentication and after the authentication process we piggyback Mobile IPv6 configuration information in the exchange. However, some EAP methods can't support this. As you mention EAP is not a configuration protocol but we could also add that AAA protocol are not configuration protocol. Thus should we avoid using AAA protocol for Mobile IPv6 bootstrapping ? -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 09:47:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06167 for ; Tue, 15 Feb 2005 09:47:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14Jk-0006SR-5v for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 10:08:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13tK-0002s8-Bp; Tue, 15 Feb 2005 09:41:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13s6-0002g0-IH for mip6@megatron.ietf.org; Tue, 15 Feb 2005 09:40:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05604 for ; Tue, 15 Feb 2005 09:40:12 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14D7-0006Ic-5A for mip6@ietf.org; Tue, 15 Feb 2005 10:02:00 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FEdv904479; Tue, 15 Feb 2005 16:39:57 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 16:36:27 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1FEaRMJ017163; Tue, 15 Feb 2005 16:36:27 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00oeiJ6u; Tue, 15 Feb 2005 16:09:43 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FE9hJ27354; Tue, 15 Feb 2005 16:09:43 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 16:09:42 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 16:09:42 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] mip6-aaa frameworks Date: Tue, 15 Feb 2005 16:09:41 +0200 Message-ID: Thread-Topic: [Mip6] mip6-aaa frameworks Thread-Index: AcUTW90zNnLqPOOjQCCo0hYpsfPTdgAAcrLA To: X-OriginalArrivalTime: 15 Feb 2005 14:09:42.0529 (UTC) FILETIME=[FEADCF10:01C51367] X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: alper.yegin@samsung.com, mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Hi Julien, > > EAP was designed for use in network access authentication, where = IP > > layer connectivity may not be available. Use of EAP for other > > purposes, such as bulk data transport, is NOT RECOMMENDED. > >=20 > > Since EAP does not require IP connectivity, it provides just = enough > > support for the reliable transport of authentication protocols, = and > > no more. > >=20 > > So that is why many people feel that using EAP would not be=20 > a good idea here. >=20 > In our proposal, we use EAP for network access authentication and = after > the authentication process we piggyback Mobile IPv6 configuration > information in the exchange.=20 >=20 > However, some EAP methods can't support this.=20 Exactly - and EAP doesn't handle fragmentation well, which can be = problematic depending upon what you want to try to configure. =20 > As you mention EAP is not a configuration protocol but we could also = add > that AAA protocol are not configuration protocol. Thus should we avoid > using AAA protocol for Mobile IPv6 bootstrapping ? Well, its a complicated picture and I don't have a clear answer. For = example, PPP does some configuration, like DNS servers - however, the PPPext WG = decided that doing configuration (like DNS servers for PPPv6) is not the right = thing to do. DHCP is a good potential solution, but what should be done if = there isn't a local DHCP server? =20 I'm thinking we need to cover the general problem spaces well, not cover = which protocols to use, yet. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 13:24:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07425 for ; Tue, 15 Feb 2005 13:24:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17hu-00088e-Ip for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 13:45:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15L2-0005m5-0Q; Tue, 15 Feb 2005 11:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D14gG-0001ob-O7 for mip6@megatron.ietf.org; Tue, 15 Feb 2005 10:32:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13561 for ; Tue, 15 Feb 2005 10:32:02 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D151J-0007tP-Ao for mip6@ietf.org; Tue, 15 Feb 2005 10:53:50 -0500 Received: from FlyToWorld ([192.168.250.19]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 00:32:12 +0900 Message-ID: <001301c51373$6fb1feb0$13faa8c0@FlyToWorld> From: "Junghoon Jee" To: "Julien Bournelle" , "Alper Yegin" References: <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com><11d201c51329$c83d61e0$291d9069@sisa.samsung.com> <20050215110504.GD6344@ipv6-3.int-evry.fr> Subject: Re: [Mip6] mip6-aaa frameworks Date: Wed, 16 Feb 2005 00:31:36 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 15 Feb 2005 15:32:12.0437 (UTC) FILETIME=[850DD450:01C51373] X-Spam-Score: 2.2 (++) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0896010096==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 --===============0896010096== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGkgSnVsaWVuIGFuZCBBTEwuDQpQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS4NCg0KPiA+ IEZyYW1ld29yayAyOg0KPiA+IC0tLS0tLS0tLS0tLQ0KPiA+IFVzaW5nIG5ldHdvcmsgYWNjZXNz IEFBQSB0byBkZWxpdmVyIE1JUDYgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIGZyb20NCj4gPiB0 aGUgQUFBIHNlcnZlciB0byB0aGUgTkFTLiBJdCBpcyBhc3N1bWVkIHRoYXQgcGFyYW1ldGVycyB3 aWxsIGJlDQo+ID4gZGVsaXZlcmVkIGZyb20gdGhlIE5BUyB0byB0aGUgTU4gdmlhIGFub3RoZXIg cHJvdG9jb2wgKGUuZy4sIERIQ1AsIFBBTkEsDQo+ID4gZXRjLikNCj4gPiANCj4gPiBSZWxhdGVk IEktRHM6DQo+ID4gDQo+ID4gZHJhZnQtY2hvd2RodXJ5LW1pcDYtYm9vdHN0cmFwLXJhZGl1cy0w MA0KPiA+IGRyYWZ0LWphbmctZGhjLWhhb3B0LTAwDQo+IA0KPiB3ZSBjYW4gYWRkOg0KPiBkcmFm dC1qZWUtbWlwNi1ib290c3RyYXBwaW5nLXBhbmEtMDAudHh0DQoNClRoYW5rIHlvdSBmb3IgcG9p bnRpbmcgb3V0IHRoaXMuDQoNCj4+ID4gRnJhbWV3b3JrIDM6DQo+ID4gLS0tLS0tLS0tLS0tDQo+ ID4gUGlnZ3liYWNraW5nIE1JUDYgc2lnbmFsaW5nIChCVSkgd2l0aCBuZXR3b3JrIGFjY2VzcyBB QUEuIEluLWJhbmQgd2l0aA0KPiA+IHRoZSBuZXR3b3JrIGFjY2VzcyBhdXRoZW50aWNhdGlvbiBl eGVjdXRpb24sIHRoZSBNTiBkZWxpdmVycw0KPiA+IChwaWdneWJhY2tzKSBhIEJVIHRvIHRoZSBB QUEgc2VydmVyLiBUaGUgQUFBIHNlcnZlciBtYXkgaGF2ZSB0byByZWxheQ0KPiA+IHRoZSBCVSB0 byB0aGUgSEEgKHVubGVzcyBjb2xsb2NhdGVkKS4gIA0KPiA+IA0KPiA+IFJlbGF0ZWQgSS1EOg0K PiA+IA0KPiA+IGRyYWZ0LWxlLWFhYS1taXB2Ni1yZXF1aXJlbWVudHMtMDMNCj4gPiANCj4gPiBE aXNjdXNzaW9uOg0KPiA+IA0KPiA+IFdoaWxlIHRoZSBwZXJmb3JtYW5jZSBiZW5lZml0cyBhcmUg Y2xlYXIsIGxpbWl0ZWQgYXBwbGljYWJpbGl0eSAobm90DQo+ID4gYWx3YXlzIHRoZSBuZXR3b3Jr IGFjY2VzcyBhbmQgbW9iaWxpdHkgc2VydmljZXMgYXJlIGJ1bmRsZWQpIGFuZA0KPiA+IGNvbXBs ZXhpdHkgYXJlIGNvbmNlcm5pbmcuDQo+IA0KPiBJJ20gbm90IHN1cmUgdGhhdCB0aGlzIGlzIGEg cGFydGljdWxhciBmcmFtZXdvcmsgc2luY2UgdGhlIEJVIGlzIGNhcnJpZWQNCj4gaW4gdGhlIEFB QSBwcm90b2NvbC4gVGhpcyBwaWdneWJhY2tpbmcgY2FuIGJlIGRvbmUgd2l0aCBGcmFtZXdyb2sg MSBhbmQNCj4gMi4NCg0KUmlnaHQsIEkgYWdyZWUgd2l0aCB5b3UuDQpUaGlzIGlzIG5vdCBhIHNl cGFyYXRlIGZyYW1ld29yayBidXQgYSBwb3NzaWJsZSBvcHRpbXphdGlvbiBjYXNlIGFib3V0IGZy YW13b3JrIDEgYW5kIDIuDQoNCk9uZSBtb3JlIHRoaW5nIGFib3V0IHRoaXMuDQpQaWdneWJhY2tp bmcgdGhlIEJVIG1lZXNzYWdlIHRvIHRoZSBBQUEgcmVxdWVzdCB3YXMgcHJldmlvdXNseSBwcm9w b3NlZCBieQ0KdGhlIHByZXZpb3VzIGV4cGlyZWQgZHJhZnQsIGRyYWZ0LWxlLWFhYS1kaWFtZXRl ci1tb2JpbGVpcHY2LTAzLnR4dC4NClRoaXMgYXBwcm9hY2ggaW5oZXJpdHMgdGhpcyBmZWF0dXJl IGZyb20gdGhlIHByZXZpb3VzIE1JUHY0ICsgQUFBIHdvcmsgd2hpY2ggY2FuIGJlIGZvdW5kIGlu IHRoZSBkcmFmdC1pZXRmLWFhYS1kaWFtZXRlci1tb2JpbGVpcC0yMC50eHQNCkJ1dCBpbiBjYXNl IG9mIE1JUHY2LCB0aGUgZmVhc2liaWxpdHkgb2YgdGhlIHBpZ2d5YmFja2luZyB0aGUgQlUgbWVz c2FnZSB0byB0aGUgQUFBIHJlcXVlc3QgZGVwZW5kcyBvbiB0aGUgdmFyeWluZyBzaXR1YXRpb24u DQpBcyBvbmUgZXhhbXBsZSBhYm91dCB0aGlzLCANCkluIGNhc2Ugb2YgYm9vdHN0cmFwcGluZywg aWYgd2UgdXNlIHRoZSBJUHNlYyBTQSB0byBwcm90ZWN0IHRoZSBCVSBmb2xsb3dpbmcgdGhlIFJG QyAzNzc1LCANCml0IGlzIG5vdCBwb3NzYmlsZSB0byBwaWdneWJhY2tzIHRoZSBCVSB0byB0aGUg QUFBIHJlcXVlc3QgbWVzc2FnZSBiZWNhdXNlIHRoZSBJUHNlYyBTQSBjYW4gYmUgc2V0dXAgYWZ0 ZXIgdGhlDQpib290c3RyYXBwaW5nIHByb2Nlc3MuDQpJIHRoaW5rIGNvbmZpZ3VyYXRpb24gb2Yg YSBDb0EgYW5kIElQc2VjIFNBIGNhbiBiZSBhbiBpc3N1ZSByZWxhdGVkIHdpdGggdGhpcy4NCg0K IA0KUmVnYXJkcywNCkp1bmdob29u --===============0896010096== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0896010096==-- From mip6-bounces@ietf.org Tue Feb 15 14:39:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27917 for ; Tue, 15 Feb 2005 14:39:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D18sz-0006ED-0i for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:01:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D16uP-0004PO-PZ; Tue, 15 Feb 2005 12:54:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15JK-0004jO-TM for mip6@megatron.ietf.org; Tue, 15 Feb 2005 11:12:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26936 for ; Tue, 15 Feb 2005 11:12:24 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15eO-0003Xt-CG for mip6@ietf.org; Tue, 15 Feb 2005 11:34:13 -0500 Received: from FlyToWorld ([192.168.250.19]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 01:12:40 +0900 Message-ID: <002f01c51379$16ad16a0$13faa8c0@FlyToWorld> From: "Junghoon Jee" To: "Alper Yegin" , References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> Subject: Re: [Mip6] mip6-aaa frameworks Date: Wed, 16 Feb 2005 01:12:03 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 15 Feb 2005 16:12:40.0082 (UTC) FILETIME=[2C0B0F20:01C51379] X-Spam-Score: 2.2 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1011560598==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f --===============1011560598== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gQWxwZXIuDQoNCj4gRnJhbWV3b3JrIDQ6DQo+IC0tLS0tLS0tLS0tLQ0KPiBBIGJhY2tl bmQgQUFBIHByb3RvY29sIGlzIGV4ZWN1dGVkIGJldHdlZW4gdGhlIEhBIGFuZCB0aGUgQUFBIHNl cnZlciBpbg0KPiByZXNwb25zZSB0byB0aGUgTUlQNiBzaWduYWxpbmcgYmV0d2VlbiB0aGUgTU4g YW5kIHRoZSBIQS4gU2ltaWxhciB0byB0aGUNCj4gdXNlIG9mIEFBQSBwcm90b2NvbHMgd2l0aCBN SVB2NCBjby1sb2NhdGVkIGNhcmUtb2YgYWRkcmVzcyBjYXNlLg0KPiANCj4gUmVsYXRlZCBJLURz Og0KPiANCj4gZHJhZnQtZ2lhcmV0dGEtbWlwNi1hYWEtaGEtZ29hbHMtMDAudHh0DQo+IGRyYWZ0 LXllZ2luLW1pcDYtYWFhLWZ3ay0wMC50eHQNCj4gDQo+IERpc2N1c3Npb246DQo+IFRoaXMgb25l IGFwcGVhcnMgdG8gYmUgdGhlIG1vc3QgbmVlZGVkIGZyYW1ld29yay4gSXQgaXMgYXNzdW1lZCB0 aGF0IE1ODQo+IGFscmVhZHkga25vd3MgdGhlIEhBIGFkZHJlc3MuIA0KDQpBYm91dCB0aGUgYXNz dW1wdGlvbiBvZiBrbm93aW5nIHRoZSBIQSBhZGRyZXNzLA0KQ291bGQgd2UgZGVhbCB3aXRoIHRo aXMgb25seSB0aHJvdWdoIHRoZSBhc3N1bXB0aW9uID8NCkFzIEkga25vdywgZHluYW1pYyBIQSBh c3NpZ25tZW50IGlzIG93aW5nIHRvIHRoZSBpc3N1ZXMgb2YgdGhlIGhvbWUgYWdlbnQgZGlzY292 ZXJ5LA0KaW5kZXBlbmRlbnQgbmV0d29yayBtYW5hZ2VtZW50LCBsb2NhbCBob21lIGFnZW50cyBh bmQgZWFzZSBvZiBkZXBsb3ltZW50DQphcyBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0LWlldGYtbWlw Ni1ib290c3RyYXAtcHMtMDEudHh0LiBBbHNvIGl0IGlzIHZlcnkgcmVsYXRlZCB3aXRoIHRoZSBo b21lIGFkZHJlc3MgYXNzaWdubWVudC4NCg0KSnVuZ2hvb24uDQo= --===============1011560598== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1011560598==-- From mip6-bounces@ietf.org Tue Feb 15 14:54:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01663 for ; Tue, 15 Feb 2005 14:54:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D196u-0007JE-Um for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:15:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18TY-0001F7-R5; Tue, 15 Feb 2005 14:35:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D16G6-0002zZ-Ij for mip6@megatron.ietf.org; Tue, 15 Feb 2005 12:13:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14179 for ; Tue, 15 Feb 2005 12:13:07 -0500 (EST) Received: from smtp.um.es ([155.54.212.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D16b7-0000dm-Tv for mip6@ietf.org; Tue, 15 Feb 2005 12:34:57 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 232BA1541; Tue, 15 Feb 2005 18:12:26 +0100 (CET) Received: from correo.um.es (zape.um.es [155.54.212.102]) by smtp.um.es (Postfix) with ESMTP id F05D314FF; Tue, 15 Feb 2005 18:12:25 +0100 (CET) Received: from [155.54.210.9] (dibulibu.um.es [155.54.1.250]) by correo.um.es (Postfix) with ESMTP id 9BF085CC8; Tue, 15 Feb 2005 18:12:24 +0100 (MET) Message-ID: <42122D78.3010304@dif.um.es> Date: Tue, 15 Feb 2005 18:12:24 +0100 From: Rafa Marin Lopez User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Mip6] mip6-aaa frameworks References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> In-Reply-To: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Hi Alper,all I think this classification could be summarized in two models (agent sequence and pull sequence) in this sense: Taking into account that HA would be service equipment for Mobile IPv6 service then: if people want pull sequence then they need to know HA address and execute some kind of protocol between MT and NAS(HA) and HA contacts AAA server (framework 4) MT------HA------AAA if people want (framework 1, framework 2, framework 3) to deliver MIP6 configuration parameters with network access, agent sequence could fit in the majority of these cases MT-----AAA-----HA note1 : you may want to include draft-ohba-mip6-boot-arch-dhcp-00.txt in framework 2. note2 : draft-bournelle-pana-mip6-00 can match with sequences shown by draft-ohba-aaaarch-authorization-delegation-00 Regards. Alper Yegin wrote: >This is an attempt to enumerate possible MIP6-AAA frameworks, and start >discussions on for which one(s) IETF shall pursue standardization. > >Framework 1: >------------ >Using network access AAA to deliver MIP6 configuration parameters from >the AAA server to the MN. > >MIP6 configuration is directly delivered from the AAA server to the MN >during network access AAA, in-band with the authentication (e.g., >transported by EAP or EAP methods). > >Related I-Ds: > >draft-giaretta-mip6-authorization-eap-01 >draft-le-aaa-mipv6-requirements-03 >draft-ohnishi-mip6-aaa-problem-statement-00 > >Discussion: > >The end2end transport between the AAA and the MN is the key. Use of EAP >for this somewhat network access unrelated "configuration" is not >recommended as far as I understand. One can design his own EAP method to >do that, yet that would have limited applicability. > > >Framework 2: >------------ >Using network access AAA to deliver MIP6 configuration parameters from >the AAA server to the NAS. It is assumed that parameters will be >delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, >etc.) > >Related I-Ds: > >draft-chowdhury-mip6-bootstrap-radius-00 >draft-jang-dhc-haopt-00 > >Discussion: > >This is similar to NAS learning the IP address for the connected host >via RADIUS, and delivering it to the host via DHCP. > >James had a comment regarding not having to support intra-operator >interoperability. I think regardless of the deployment, interoperability >between vendors is the important. Also, I was not sure on the complexity >argument. > >3GPP2 has already chosen this scheme. Some other SDO(s) may follow the >suit. > >Framework 3: >------------ >Piggybacking MIP6 signaling (BU) with network access AAA. In-band with >the network access authentication execution, the MN delivers >(piggybacks) a BU to the AAA server. The AAA server may have to relay >the BU to the HA (unless collocated). > >Related I-D: > >draft-le-aaa-mipv6-requirements-03 > >Discussion: > >While the performance benefits are clear, limited applicability (not >always the network access and mobility services are bundled) and >complexity are concerning. > > >Framework 4: >------------ >A backend AAA protocol is executed between the HA and the AAA server in >response to the MIP6 signaling between the MN and the HA. Similar to the >use of AAA protocols with MIPv4 co-located care-of address case. > >Related I-Ds: > >draft-giaretta-mip6-aaa-ha-goals-00.txt >draft-yegin-mip6-aaa-fwk-00.txt > >Discussion: >This one appears to be the most needed framework. It is assumed that MN >already knows the HA address. > > >Are there other frameworks to add? > >I am sure I have missed some references, please let us know which ones. > >Alper > > > > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 > > > > > -- ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 15:02:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03131 for ; Tue, 15 Feb 2005 15:02:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Ei-0007kD-TK for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:23:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18WR-00021G-Ht; Tue, 15 Feb 2005 14:38:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D16m7-00007Q-HD for mip6@megatron.ietf.org; Tue, 15 Feb 2005 12:46:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24217 for ; Tue, 15 Feb 2005 12:46:12 -0500 (EST) Received: from iramx2.ira.uni-karlsruhe.de ([141.3.10.81] ident=[U2FsdGVkX199UhqqB2UGUtuZmZPDTjDjCSi4Gg7bSJ0=]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D177C-0003uj-TA for mip6@ietf.org; Tue, 15 Feb 2005 13:08:03 -0500 Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5] helo=irams1.ira.uka.de) by iramx2.ira.uni-karlsruhe.de with esmtps (Exim 4.43 #1) id 1D16m3-0000lx-EO; Tue, 15 Feb 2005 18:46:13 +0100 Received: from i72archimedes.tm.uni-karlsruhe.de ([141.3.71.83]) by irams1.ira.uka.de with esmtp (Exim 3.30 #7 ) id 1D16m2-0006SS-00; Tue, 15 Feb 2005 18:46:10 +0100 Message-ID: <42123562.8010609@tm.uka.de> Date: Tue, 15 Feb 2005 18:46:10 +0100 From: Christian Vogt User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: MIP6 X-Enigmail-Version: 0.90.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -9.4 (---------) X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: Gopal Dommety , Jari Arkko , Basavaraj Patil Subject: [Mip6] New I-D's: draft-vogt-mobopts-early-binding-updates-00.txt, draft-vogt-mobopts-credit-based-authorization-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Hi folks, Early Binding Updates and Credit-Based Authorization have been under discussion in the MIP6 and Mobopts groups for a while now. Below, you find links to updated documents about both. The predecessors of these documents had different prefixes, so the documents below start over with a -00 version. http://doc.tm.uka.de/2005/draft-vogt-mobopts-early-binding-updates-00.txt http://doc.tm.uka.de/2005/draft-vogt-mobopts-credit-based-authorization-00.txt We would greatly appreciate to hear your opinions and comments on EBU and CBA. Kind regards, - Christian ++++++++ Title...: Early Binding Updates for Mobile IPv6 Author..: Christian Vogt http://doc.tm.uka.de/2005/draft-vogt-mobopts-early-binding-updates-00.txt Abstract Mobile IPv6 defines a return-routability procedure for secure use of route optimization between unacquainted nodes. The handover latency caused by the procedure can significantly impact delay-sensitive applications, however. This document presents an optimization to Mobile IPv6 that eliminates the latency. The optimization is realized as an optional, and fully backward-compatible, extension to Mobile IPv6. ++++++++ Title...: Credit-Based Authorization for Mobile IPv6 Early Binding Updates Authors.: Christian Vogt, Jari Arkko http://doc.tm.uka.de/2005/draft-vogt-mobopts-credit-based-authorization-00.txt Abstract The latency associated with Mobile IPv6's Return Routability test can have an adverse impact on delay-sensitive applications. Early Binding Updates mitigate this issue by already using a new care-of address in parallel with testing it. We propose and analyze a credit-based mechanism that prevents misuse of Early Binding Updates for amplified flooding attacks and discourages such misuse for non-amplified flooding attacks. ++++++++ -- Christian Vogt, Institute of Telematics, University of Karlsruhe www.tm.uka.de/~chvogt/pubkey/ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 15:06:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03894 for ; Tue, 15 Feb 2005 15:06:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Ib-0007xS-N3 for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:27:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18Yu-0007vv-38; Tue, 15 Feb 2005 14:40:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D175E-0001K6-V1 for mip6@megatron.ietf.org; Tue, 15 Feb 2005 13:06:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01533 for ; Tue, 15 Feb 2005 13:05:53 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17QD-00069M-4w for mip6@ietf.org; Tue, 15 Feb 2005 13:27:43 -0500 Message-ID: <02e601c51389$21dd84a0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alper Yegin" , References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> Subject: Re: [Mip6] mip6-aaa frameworks Date: Tue, 15 Feb 2005 10:06:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Hi Alper, Overall comment: I think this is a good way of classifying the proposed solution space, but I like the scenario approach in draft-giaretta-mip6-aaa-ha-goals better for classifying the problem space. I think what we need now is some matching of solutions to problem space, to see where there are gaps or overlaps. Specific comments below. > > This is an attempt to enumerate possible MIP6-AAA frameworks, and start > discussions on for which one(s) IETF shall pursue standardization. > > Framework 1: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the MN. > > MIP6 configuration is directly delivered from the AAA server to the MN > during network access AAA, in-band with the authentication (e.g., > transported by EAP or EAP methods). > > Related I-Ds: > > draft-giaretta-mip6-authorization-eap-01 > draft-le-aaa-mipv6-requirements-03 > draft-ohnishi-mip6-aaa-problem-statement-00 > > Discussion: > > The end2end transport between the AAA and the MN is the key. Use of EAP > for this somewhat network access unrelated "configuration" is not > recommended as far as I understand. One can design his own EAP method to > do that, yet that would have limited applicability. > > > Framework 2: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the NAS. It is assumed that parameters will be > delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, > etc.) > > Related I-Ds: > > draft-chowdhury-mip6-bootstrap-radius-00 > draft-jang-dhc-haopt-00 > > Discussion: > > This is similar to NAS learning the IP address for the connected host > via RADIUS, and delivering it to the host via DHCP. > > James had a comment regarding not having to support intra-operator > interoperability. I think regardless of the deployment, interoperability > between vendors is the important. Also, I was not sure on the complexity > argument. > Consider the following. Suppose RADIUS is used to transfer operator A's HA addresses from operator A's AAA server to operator B's NAS. First question is whether the addresses are delivered every time a roamed host makes a DHCP request for the HA address? If not and there is any caching going on, then the addresses could get stale. Second question is how the NAS differentiates which home operator to ask for the addresses? Presumably an NAI but is that separate or combined with DHCP? This is a big change in the basic IETF DHCP architecture, IMHO. Managing DHCP configuration information within an operator's domain is difficult enough. > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the > suit. > Can someone provide more details here? As far as I know, in the current 3GPP2 MIP4 system, the PDSN is both home and foreign agent (please correct if this is wrong), so I don't see how DHCP would come into the picture. How are they planning on changing that for MIP6? Are they really planning on distributing the addresses of home agents between operators or just within a single operator? jak > Framework 3: > ------------ > Piggybacking MIP6 signaling (BU) with network access AAA. In-band with > the network access authentication execution, the MN delivers > (piggybacks) a BU to the AAA server. The AAA server may have to relay > the BU to the HA (unless collocated). > > Related I-D: > > draft-le-aaa-mipv6-requirements-03 > > Discussion: > > While the performance benefits are clear, limited applicability (not > always the network access and mobility services are bundled) and > complexity are concerning. > > > Framework 4: > ------------ > A backend AAA protocol is executed between the HA and the AAA server in > response to the MIP6 signaling between the MN and the HA. Similar to the > use of AAA protocols with MIPv4 co-located care-of address case. > > Related I-Ds: > > draft-giaretta-mip6-aaa-ha-goals-00.txt > draft-yegin-mip6-aaa-fwk-00.txt > > Discussion: > This one appears to be the most needed framework. It is assumed that MN > already knows the HA address. > > > Are there other frameworks to add? > > I am sure I have missed some references, please let us know which ones. > > Alper > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 15:06:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04019 for ; Tue, 15 Feb 2005 15:06:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19JE-0007z1-Ha for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:28:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18Z8-0008R0-5T; Tue, 15 Feb 2005 14:40:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D177H-0002dk-UP for mip6@megatron.ietf.org; Tue, 15 Feb 2005 13:08:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02221 for ; Tue, 15 Feb 2005 13:08:04 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17SJ-0006OD-9J for mip6@ietf.org; Tue, 15 Feb 2005 13:29:54 -0500 Message-ID: <02f401c51389$701886b0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Tue, 15 Feb 2005 10:08:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit John, OK, then how about "inter-administrative domain roaming"? If two operators merge and originally used some kind of inter-operator solution because they are two different administrative domains, then they could continue to use that. jak ----- Original Message ----- From: To: ; Sent: Tuesday, February 15, 2005 2:43 AM Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt James, Before going into detail about your mail, can you clarify one thing: > As I high level comment, I think we need to consider exactly what the > purpose of defining any requirements for standardization of the HA-AAA > interface are, and similarly for any other AAA interfaces (like > HA-AAA-NAS/DHCP server). From a service provider perspective, I believe the > top level goal should be to facilitate inter-operator roaming. I would say this is too simplistic. I agree that facilitating inter-operator roaming is a good thing, but I think we need to also consider intra-operator roaming as well. Its a complicated business landscape at the moment, mergers, acquisitions, etc. Its likely that a service provider may have more than one access technology, maybe more than one AAA system, or they may have some relationship with a parent, sister or daughter company. I think getting a solution that works for inter-operator and intra-operator roaming would be a good thing. Do you think that this is within your proposal? John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 15:08:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04359 for ; Tue, 15 Feb 2005 15:08:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Kb-00084F-Cn for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:30:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18aF-0003fD-2K; Tue, 15 Feb 2005 14:42:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D17Hr-00084n-HL for mip6@megatron.ietf.org; Tue, 15 Feb 2005 13:19:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05493 for ; Tue, 15 Feb 2005 13:19:00 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17cx-0007VS-4g for mip6@ietf.org; Tue, 15 Feb 2005 13:40:51 -0500 Message-ID: <030201c5138a$f8c805c0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Tue, 15 Feb 2005 10:19:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit John, I think the issue is administrative boundaries from the network operator perspective. If an operator manages multiple kinds of networks separated by administrative boundaries, then these are, effectively, separate administrative domains, and the boundaries should be respected. It is basically a question of managability. Issues such as exposure of detailed topology information (not only for security purposes, but also for purposes of effective routing information and address management) need to be kept within an administrative boundary inside which the network operator can effectively manage. That's why there are two types of routing information distribution protocols, one for inside an administrative domain and one for outside. Exposing detailed address and topology information outside an administrative domain through protocols that were originally designed for configuring hosts within an administrative domain is not such a good idea in my opinion, because it adds more complexity to the management task. Naturally, others have different opinions. jak ----- Original Message ----- From: To: ; Sent: Tuesday, February 15, 2005 2:45 AM Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt One more comment. > Personally, I don't see the need to define a HA-AAA-NAS/DHCP interface, as > draft-ohba recommends, because I believe this is and should remain an > intra-operator interface that should not cross administrative boundaries. For this, is this a SHOULD or do you mean should = usually doesn't? At least talking to some carriers, they do currently have very strong adminstrative boundries between their cellular networks and non-cellular networks (WLAN, DSL, etc.). Philosophically, cellular networks are often seen as high-value networks, often ones that are regulated quite strongly, not to mention issues about licensing, etc. Therefore, some operators feel that they need to administer these networks seperately. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 15:18:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06871 for ; Tue, 15 Feb 2005 15:18:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Uv-00006k-9h for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:40:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18lF-0002Ey-1T; Tue, 15 Feb 2005 14:53:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18L6-0004nP-Bt for mip6@megatron.ietf.org; Tue, 15 Feb 2005 14:26:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25721 for ; Tue, 15 Feb 2005 14:26:26 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D18gB-0005ZW-9z for mip6@ietf.org; Tue, 15 Feb 2005 14:48:16 -0500 Message-ID: <036c01c51394$62e2b780$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tschofenig Hannes" , References: Subject: Re: [Mip6] new draft: Enriching Bootstrapping with AuthorizationInformation Date: Tue, 15 Feb 2005 11:27:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Hi Hannes, Can you perhaps explain what the advantages and disadvantages of using SAML are w.r.t. attribute certificates for authorization (RFC 3281)? jak ----- Original Message ----- From: "Tschofenig Hannes" To: ; ; ; Sent: Saturday, February 12, 2005 5:56 AM Subject: [Mip6] new draft: Enriching Bootstrapping with AuthorizationInformation > hi all, > > we (gerardo, antonio and myself) have written a document relevant for > bootstrapping (which again is relevant for a number of working groups in the > meanwhile). > > please find the draft in the indicated url (before it appears in the > id-directory). > > ------------ > > Abstract > > Some work has been done in the area of bootstrapping in the IETF recently. > Bootstrapping refers to the process of creating state (typically security > associations) between two or more entities based on a trust relationship > between these two or more parties and a trusted third party. So far work > has mostly focused on creating security associations. This document aims to > attach authorization information to the bootstrapping process. > > > http://www.tschofenig.com/drafts/draft-tschofenig-enroll-bootstrapping-saml- > 00.txt > > http://www.tschofenig.com/drafts/draft-tschofenig-enroll-bootstrapping-saml- > 00.html > > ------------ > > ciao > hannes, gerardo, antonio > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 15:18:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06889 for ; Tue, 15 Feb 2005 15:18:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Uw-00006v-Px for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:40:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18lJ-0002MM-PZ; Tue, 15 Feb 2005 14:53:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18OU-0006Dc-54 for mip6@megatron.ietf.org; Tue, 15 Feb 2005 14:29:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25984 for ; Tue, 15 Feb 2005 14:29:56 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D18jZ-0005dk-81 for mip6@ietf.org; Tue, 15 Feb 2005 14:51:46 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id j1FJTPbj005589; Tue, 15 Feb 2005 13:29:25 -0600 (CST) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Tue, 15 Feb 2005 13:29:13 -0600 Received: from [142.133.116.23] (142.133.116.23 [142.133.116.23]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1913VJG3; Tue, 15 Feb 2005 14:29:20 -0500 In-Reply-To: <456943D540CFC14A8D7138E64843F85308C7FF@daebe101.NOE.Nokia.com> References: <456943D540CFC14A8D7138E64843F85308C7FF@daebe101.NOE.Nokia.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48186891bfe182c04208856e54dbe1bf@ericsson.com> Content-Transfer-Encoding: 7bit From: Wassim Haddad Subject: Re: [Mip6] IETF62: Timeslot requests on mip6 agenda Date: Tue, 15 Feb 2005 14:31:42 -0500 To: Basavaraj.Patil@nokia.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: mip6 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Hi Raj, I would like to ask please for a slot to present draft-haddad-mip6-cga-omipv6-03 (Optimizing Mobile IPv6 with CGAs, OMIPv6-CGA). IMHO, this draft is relevant to the mip6 WG because it presents an efficient optimization to the RO mode. Slot Duration: 10 minutes. Regards, Wassim H. On 15-Feb-05, at 5:08 AM, Basavaraj.Patil@nokia.com wrote: > > > Hello, > > If you need a timeslot for presenting at the MIP6 WG meeting > in Minneapolis (IETF62), please send the same to the chairs. > Note that WG items have priority. > It is essential that you have an I-D that has been submitted > in order to get a slot on the agenda. > Please state why this I-D is relevant to the MIP6 WG in the > request along with the duration of time needed. > > -Basavaraj > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 15:34:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09047 for ; Tue, 15 Feb 2005 15:34:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19kC-0000dt-5y for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:56:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19CP-00045D-0R; Tue, 15 Feb 2005 15:21:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D193e-00060I-9o for mip6@megatron.ietf.org; Tue, 15 Feb 2005 15:12:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05465 for ; Tue, 15 Feb 2005 15:12:28 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Ok-0008FV-2G for mip6@ietf.org; Tue, 15 Feb 2005 15:34:19 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 15 Feb 2005 12:12:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1FKBuYO001702 for ; Tue, 15 Feb 2005 12:11:56 -0800 (PST) Received: from gdommety-w2k05.cisco.com (dhcp-171-69-220-164.cisco.com [171.69.220.164]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHT53074; Tue, 15 Feb 2005 12:11:49 -0800 (PST) Message-Id: <4.3.2.7.2.20050215120213.026355d0@mira-sjc5-d.cisco.com> X-Sender: gdommety@mira-sjc5-d.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Feb 2005 12:11:50 -0800 To: From: Gopal Dommety In-Reply-To: <697DAA22C5004B4596E033803A7CEF4403B1C2C4@daebe007.americas .nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for bootstrapping Mobile IPv6 ) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hello All, This is a Working Group Last Call for the following I-D: draft-ietf-mip6-bootstrap-ps-01.txt Title: Problem Statement for bootstrapping Mobile IPv6 Please note that the status intended for this I-D is Proposed Standard. Please review and post your comments by March 3rd, 2005. -Chairs, URL-ID is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 15:34:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09068 for ; Tue, 15 Feb 2005 15:34:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19kC-0000du-6t for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 15:56:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19CX-00049F-El; Tue, 15 Feb 2005 15:21:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D195e-0006pV-CC for mip6@megatron.ietf.org; Tue, 15 Feb 2005 15:14:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05845 for ; Tue, 15 Feb 2005 15:14:32 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Qk-0008ML-VZ for mip6@ietf.org; Tue, 15 Feb 2005 15:36:23 -0500 Received: from jurassic.eng.sun.com ([129.146.82.37]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j1FKEWPD007716; Tue, 15 Feb 2005 12:14:32 -0800 (PST) Received: from shubho (shubho.SFBay.Sun.COM [129.146.73.85]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with SMTP id j1FKEV3Q480281; Tue, 15 Feb 2005 12:14:31 -0800 (PST) Message-Id: <200502152014.j1FKEV3Q480281@jurassic.eng.sun.com> Date: Tue, 15 Feb 2005 12:12:29 -0800 (PST) From: Samita Chakrabarti Subject: Re: [Mip6] mip6-aaa frameworks To: julien.bournelle@int-evry.fr, alper.yegin@samsung.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 10gl0pYpu3I4c5/posObFA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_54 SunOS 5.10 sun4u sparc X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Samita Chakrabarti List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi Alper, Thanks for providing an analysis of different proposals/framework. I'd agree with Julien, that draft-chakrabati-mip6-bmip-00.txt goes with Framework 4 very well for retrieving Home Agent address and initial security association for bootstrap. Although the BMIP draft is not about AAA and MIPv6, it can co-exist with having a AAA server in the foreign network and a AAA back-end server tied to HA. So, it makes sense to add this draft to the list for completeness. In the next version of the draft we are going to clarify that the BMIP draft can be used for different types of access networks (802.1X, PANA, UAM, physical access , Local AAA) in order to gain access to the local network. Thanks, -Samita > > > > Framework 4: > > ------------ > > A backend AAA protocol is executed between the HA and the AAA server in > > response to the MIP6 signaling between the MN and the HA. Similar to the > > use of AAA protocols with MIPv4 co-located care-of address case. > > > > Related I-Ds: > > > > draft-giaretta-mip6-aaa-ha-goals-00.txt > > draft-yegin-mip6-aaa-fwk-00.txt > > I would add: > draft-chakrabati-mip6-bmip-00.txt > (DNS to discover HA + IKEv2 and AAA-HA) > > draft-tschofenig-mip6-bootstrapping-pana > (needs to relax PANA on the one IP hop between PaC and PAA) assumption > > > Discussion: > > This one appears to be the most needed framework. It is assumed that MN > > already knows the HA address. > > > > > > Are there other frameworks to add? > > I also wrote a proposition draft-bournelle-pana-mip6-00. This > proposition rely on PANA. The PAA is in charge of allocating the HA and > of providing necessary information to HA and MN. The problem with this > approach is that the HA allocation is only in the visited domain. > However, the idea is that the AAA server explicitely authorize the service but > delegate configuration process to an agent. > > Do you think that we can make a framework with this ? > > -- > julien.bournelle@int-evry.fr > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 16:55:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17112 for ; Tue, 15 Feb 2005 16:55:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1B0T-0002wW-IK for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 17:17:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1AdK-0000cy-Om; Tue, 15 Feb 2005 16:53:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1AZX-0008O4-9v for mip6@megatron.ietf.org; Tue, 15 Feb 2005 16:49:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16487 for ; Tue, 15 Feb 2005 16:49:29 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Auc-0002n9-HM for mip6@ietf.org; Tue, 15 Feb 2005 17:11:21 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1FMJ8o01363; Tue, 15 Feb 2005 14:19:08 -0800 X-mProtect: <200502152219> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdSPtQ85; Tue, 15 Feb 2005 14:18:31 PST Message-ID: <42126E14.9070608@iprg.nokia.com> Date: Tue, 15 Feb 2005 13:48:04 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gopal Dommety Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for bootstrapping Mobile IPv6 ) References: <4.3.2.7.2.20050215120213.026355d0@mira-sjc5-d.cisco.com> In-Reply-To: <4.3.2.7.2.20050215120213.026355d0@mira-sjc5-d.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit isnt it supposed to be Informational? AFAIK, problem statement drafts are Informational. Vijay Gopal Dommety wrote: > Hello All, > > > This is a Working Group Last Call for the following I-D: > draft-ietf-mip6-bootstrap-ps-01.txt > Title: > Problem Statement for bootstrapping Mobile IPv6 > > Please note that the status intended for this I-D is Proposed Standard. > > Please review and post your comments by March 3rd, 2005. > > -Chairs, > > URL-ID is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 17:53:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23456 for ; Tue, 15 Feb 2005 17:53:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1BuR-0004SW-53 for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 18:15:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1BXD-0000ea-Kk; Tue, 15 Feb 2005 17:51:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1BRS-00074z-Uj for mip6@megatron.ietf.org; Tue, 15 Feb 2005 17:45:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22476 for ; Tue, 15 Feb 2005 17:45:12 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1BmZ-0004Cm-Ud for mip6@ietf.org; Tue, 15 Feb 2005 18:07:05 -0500 Received: from jurassic.eng.sun.com ([129.146.87.31]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1FMjCnK025273; Tue, 15 Feb 2005 15:45:12 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j1FMjBDl550074; Tue, 15 Feb 2005 14:45:12 -0800 (PST) Message-ID: <42127B53.9030200@sun.com> Date: Tue, 15 Feb 2005 14:44:35 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Mip6] mip6-aaa frameworks References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> In-Reply-To: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Alper Yegin wrote: > This is an attempt to enumerate possible MIP6-AAA frameworks, and start > discussions on for which one(s) IETF shall pursue standardization. Good summary. FWIW I think that framework 4 is the key one to standardize, because it allows the network access AAA being decoupled from the MIP6 AAA. Not that it doesn't require that they be completely separate, since the same AAA backend and the same NAI (and perhaps even EAP method) could be used for the cases when the same identity is used for noth the network access and for MIP6. And AFAIK it is this backend infrastructure concern that is key for the operators. I think that degree of separation is the right thing for an IETF standard. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 18:58:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00374 for ; Tue, 15 Feb 2005 18:58:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Cv4-00063F-Ds for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 19:19:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1CUd-00018x-4C; Tue, 15 Feb 2005 18:52:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1CTc-0000lX-NT; Tue, 15 Feb 2005 18:51:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29770; Tue, 15 Feb 2005 18:51:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Coi-0005sM-TG; Tue, 15 Feb 2005 19:13:23 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1D1CKo-0006xH-Ie; Tue, 15 Feb 2005 18:42:26 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 15 Feb 2005 18:42:26 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: mip6@ietf.org Subject: [Mip6] Last Call: 'Mobile Node Identifier Option for Mobile IPv6' to Proposed Standard X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has received a request from the Mobility for IPv6 WG to consider the following document: - 'Mobile Node Identifier Option for Mobile IPv6 ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-03-01. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mip6-mn-ident-option-02.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 20:50:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12485 for ; Tue, 15 Feb 2005 20:50:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Efr-0000tH-7z for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 21:12:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1EFW-0007Hd-Ny; Tue, 15 Feb 2005 20:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1EBu-0006h3-PU for mip6@megatron.ietf.org; Tue, 15 Feb 2005 20:41:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11703 for ; Tue, 15 Feb 2005 20:41:20 -0500 (EST) Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1EX1-0000fS-TR for mip6@ietf.org; Tue, 15 Feb 2005 21:03:14 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 16 Feb 2005 01:41:18 -0000 Message-ID: <011101c513c8$9a1d5e10$861167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> Subject: Re: [Mip6] mip6-aaa frameworks Date: Tue, 15 Feb 2005 17:41:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Alper, Thanks for summarizing this. A few comments below. > > Framework 1: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the MN. > > MIP6 configuration is directly delivered from the AAA server to the MN > during network access AAA, in-band with the authentication (e.g., > transported by EAP or EAP methods). > > Related I-Ds: > > draft-giaretta-mip6-authorization-eap-01 > draft-le-aaa-mipv6-requirements-03 > draft-ohnishi-mip6-aaa-problem-statement-00 > > Discussion: > > The end2end transport between the AAA and the MN is the key. Use of EAP > for this somewhat network access unrelated "configuration" is not > recommended as far as I understand. One can design his own EAP method to > do that, yet that would have limited applicability. > Perhaps, you don't need a new method. But something like EAP-TLV (there was a draft around sometime back) is sufficient i guess. Anyway, the key issue is using EAP for configuration. > Framework 3: > ------------ > Piggybacking MIP6 signaling (BU) with network access AAA. In-band with > the network access authentication execution, the MN delivers > (piggybacks) a BU to the AAA server. The AAA server may have to relay > the BU to the HA (unless collocated). > > Related I-D: > > draft-le-aaa-mipv6-requirements-03 > > Discussion: > > While the performance benefits are clear, limited applicability (not > always the network access and mobility services are bundled) and > complexity are concerning. > Can you elaborate on the complexity issue ? > > Framework 4: > ------------ > A backend AAA protocol is executed between the HA and the AAA server in > response to the MIP6 signaling between the MN and the HA. Similar to the > use of AAA protocols with MIPv4 co-located care-of address case. > > Related I-Ds: > > draft-giaretta-mip6-aaa-ha-goals-00.txt > draft-yegin-mip6-aaa-fwk-00.txt > > Discussion: > This one appears to be the most needed framework. It is assumed that MN > already knows the HA address. > Agreed. We can always use a simpler mechanism e.g. DNS to discover the HA address i suppose. -mohan > > Are there other frameworks to add? > > I am sure I have missed some references, please let us know which ones. > > Alper > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 21:33:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17831 for ; Tue, 15 Feb 2005 21:33:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1FLg-0002Jy-W0 for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 21:55:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1EpY-0000nx-Tc; Tue, 15 Feb 2005 21:22:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1EoI-0000Fx-Jj for mip6@megatron.ietf.org; Tue, 15 Feb 2005 21:21:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16049 for ; Tue, 15 Feb 2005 21:21:00 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1F9R-0001mY-GM for mip6@ietf.org; Tue, 15 Feb 2005 21:42:54 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 15 Feb 2005 18:20:54 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1G2KSYO017839 for ; Tue, 15 Feb 2005 18:20:28 -0800 (PST) Received: from gdommety-w2k05.cisco.com (dhcp-128-107-178-154.cisco.com [128.107.178.154]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHT83499; Tue, 15 Feb 2005 18:20:28 -0800 (PST) Message-Id: <4.3.2.7.2.20050215182010.026af688@mira-sjc5-d.cisco.com> X-Sender: gdommety@mira-sjc5-d.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Feb 2005 18:20:27 -0800 To: From: Gopal Dommety Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for bootstrapping Mobile IPv6 ) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hello All, This is a Working Group Last Call for the following I-D: draft-ietf-mip6-bootstrap-ps-01.txt Title: Problem Statement for bootstrapping Mobile IPv6 Please note that the status intended for this I-D is Informational. Please review and post your comments by March 3rd, 2005. -Chairs, URL-ID is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 21:40:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19220 for ; Tue, 15 Feb 2005 21:40:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1FSN-0002kS-SL for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 22:02:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1F2Y-0004Ne-0l; Tue, 15 Feb 2005 21:35:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Epf-0000o9-SU for mip6@megatron.ietf.org; Tue, 15 Feb 2005 21:22:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16338 for ; Tue, 15 Feb 2005 21:22:26 -0500 (EST) 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.33) id 1D1FAp-0001rV-Vj for mip6@ietf.org; Tue, 15 Feb 2005 21:44:20 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2005 18:31:54 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1G2Lnq8003082 for ; Tue, 15 Feb 2005 18:21:50 -0800 (PST) Received: from gdommety-w2k05.cisco.com (dhcp-128-107-178-154.cisco.com [128.107.178.154]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AHT83579; Tue, 15 Feb 2005 18:21:54 -0800 (PST) Message-Id: <4.3.2.7.2.20050215182042.026dcb50@mira-sjc5-d.cisco.com> X-Sender: gdommety@mira-sjc5-d.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 15 Feb 2005 18:21:53 -0800 To: From: Gopal Dommety Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for bootstrapping Mobile IPv6 ) In-Reply-To: <4.3.2.7.2.20050215120213.026355d0@mira-sjc5-d.cisco.com> References: <697DAA22C5004B4596E033803A7CEF4403B1C2C4@daebe007.americas .nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Please note that the status intended for this I-D is Informational (and not Proposed Standard as specified in my email). Thanks to Vijay and Alpesh for pointing it out. -Gopal At 12:11 PM 2/15/2005 -0800, Gopal Dommety wrote: >Hello All, > > >This is a Working Group Last Call for the following I-D: >draft-ietf-mip6-bootstrap-ps-01.txt >Title: >Problem Statement for bootstrapping Mobile IPv6 > >Please note that the status intended for this I-D is Proposed Standard. > >Please review and post your comments by March 3rd, 2005. > >-Chairs, > >URL-ID is: >http://www.ietf.org/internet-drafts/draft-ietf-mip6-bootstrap-ps-01.txt > >_______________________________________________ >Mip6 mailing list >Mip6@ietf.org >https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 23:24:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14313 for ; Tue, 15 Feb 2005 23:24:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1H54-0005pC-Gy for mip6-web-archive@ietf.org; Tue, 15 Feb 2005 23:46:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Gdp-0003kr-A0; Tue, 15 Feb 2005 23:18:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GWd-0000sE-Ia for mip6@megatron.ietf.org; Tue, 15 Feb 2005 23:10:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12801 for ; Tue, 15 Feb 2005 23:10:52 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Grn-0005Oy-4N for mip6@ietf.org; Tue, 15 Feb 2005 23:32:48 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1G4Ac907496; Wed, 16 Feb 2005 06:10:42 +0200 (EET) X-Scanned: Wed, 16 Feb 2005 06:08:48 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1G48mCq025645; Wed, 16 Feb 2005 06:08:48 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00Edk0Qu; Wed, 16 Feb 2005 06:08:47 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1G48lJ06243; Wed, 16 Feb 2005 06:08:47 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 16 Feb 2005 06:08:44 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 16 Feb 2005 06:08:43 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Wed, 16 Feb 2005 06:08:43 +0200 Message-ID: Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcUTibdWFkfpv8tkQ+Ssx99fVtOs5AAU1goQ To: , X-OriginalArrivalTime: 16 Feb 2005 04:08:43.0812 (UTC) FILETIME=[346BFE40:01C513DD] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Hi James, > OK, then how about "inter-administrative domain roaming"? If two = operators > merge and originally used some kind of inter-operator solution because = they > are two different administrative domains, then they could continue to = use > that. Thanks for the clarification, I just wanted to check on whether this was = supported or not in your scenario. It seems it is; I'm otherwise not so hung-up = on terminalogy. thanks, John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 15 23:58:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17894 for ; Tue, 15 Feb 2005 23:58:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Hbp-0006y4-CF for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 00:20:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1HDs-0007OZ-RQ; Tue, 15 Feb 2005 23:55:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1HCB-0006fR-Q3 for mip6@megatron.ietf.org; Tue, 15 Feb 2005 23:53:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17463 for ; Tue, 15 Feb 2005 23:53:49 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1HXM-0006pt-0o for mip6@ietf.org; Wed, 16 Feb 2005 00:15:45 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1G4rmI12136; Wed, 16 Feb 2005 06:53:48 +0200 (EET) X-Scanned: Wed, 16 Feb 2005 06:52:37 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1G4qbI9032667; Wed, 16 Feb 2005 06:52:37 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00QEse80; Wed, 16 Feb 2005 06:52:34 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1G4qXM24403; Wed, 16 Feb 2005 06:52:33 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 16 Feb 2005 06:52:30 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 16 Feb 2005 06:52:30 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Wed, 16 Feb 2005 06:52:29 +0200 Message-ID: Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcUTiwMYb3lieev0Q16z/W6lJbyE8QAWAaFw To: , X-OriginalArrivalTime: 16 Feb 2005 04:52:30.0474 (UTC) FILETIME=[5208CEA0:01C513E3] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Hi James, > I think the issue is administrative boundaries from the network = operator > perspective. If an operator manages multiple kinds of networks = separated by > administrative boundaries, then these are, effectively, separate > administrative domains, and the boundaries should be respected. It is > basically a question of managability. Issues such as exposure of = detailed > topology information (not only for security purposes, but also for = purposes > of effective routing information and address management) need to be = kept > within an administrative boundary inside which the network operator = can > effectively manage. That's why there are two types of routing = information > distribution protocols, one for inside an administrative domain and = one for > outside. Exposing detailed address and topology information outside an > administrative domain through protocols that were originally designed = for > configuring hosts within an administrative domain is not such a good = idea in > my opinion, because it adds more complexity to the management task. > Naturally, others have different opinions. I basically agree; so let's drop the inter/intra-operator discussions = and speak about administrative boundries. I was slightly confuses after = reading your original mail, but I think if we just discuss from administrative boundries perspective, it would be clearer. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 00:20:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20023 for ; Wed, 16 Feb 2005 00:20:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1HxJ-0007Va-FX for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 00:42:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1HZp-0005xa-Lx; Wed, 16 Feb 2005 00:18:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1HYZ-0005JD-UA for mip6@megatron.ietf.org; Wed, 16 Feb 2005 00:17:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19703 for ; Wed, 16 Feb 2005 00:16:56 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Htk-0007QW-OS for mip6@ietf.org; Wed, 16 Feb 2005 00:38:53 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j1G5GhHr023491; Wed, 16 Feb 2005 14:16:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j1G5GhEJ016031; Wed, 16 Feb 2005 14:16:43 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id QAA16024 ; Wed, 16 Feb 2005 14:16:43 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j1G5Ggr6023779; Wed, 16 Feb 2005 14:16:42 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1G5Geke021782; Wed, 16 Feb 2005 14:16:40 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1G5Ge8a016230; Wed, 16 Feb 2005 14:16:40 +0900 (JST) Received: from steelhead (ncg-dhcp69.isl.rdc.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IBZ0046CNZPEA@tsbpo1.po.toshiba.co.jp>; Wed, 16 Feb 2005 14:16:37 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1D1Glf-0005l1-00; Tue, 15 Feb 2005 20:26:27 -0800 Date: Tue, 15 Feb 2005 23:26:27 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> To: James Kempf Message-id: <20050216042627.GC18190@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a On Mon, Feb 14, 2005 at 02:23:06PM -0800, James Kempf wrote: (snip) > Personally, I don't see the need to define a HA-AAA-NAS/DHCP interface, as > draft-ohba recommends, because I believe this is and should remain an > intra-operator interface that should not cross administrative boundaries. As > I mentioned in San Diego and Washington, DC, I don't believe inter-domain AA > A flows to the DHCP server or NAS should be used for inter-domain > bootstrapping due to the complexity involved in carrying the configuration > information between network operator domains and making sure it is > consistent. I think that the complexity of a HA-AAA-NAS/DHCP interface is not much different between inter-domain and intra-domain bootstrapping cases. I mean that the complexity is basically about state synchronization on configuration parameters between a AAA server, a DHCP server and a DHCP server and is common to both inter-domain and intra-domain cases. > I don't believe anything needs to be standardized for > intra-domain bootstrapping using DHCP except for the format of the record in > DHCP for the MIP6 information, which impacts the MN-DHCP server interface. > In a roaming situation, a home IMSP can indicate during the network access > authentication that the MN should bootstrap off the local DHCP server, if a > local HA, is available through the AAA-H to MN protocol (i.e. end to end), > without having to do anything through the local DHCP server itself. I agree that this is a simple model. On the other hand, this provides a less optimized solution in that the MN might need to execute two EAP runs, one EAP for network access authentication (and to get a local HA assigned to the MN) and the other EAP over IKEv2 between the MN and the HA. Some operators may desire a more optimized solution in which AAA for network access and AAA for mobility service are dependent and only one EAP needs to be executed. Thanks, Yoshihiro Ohba > For a > nonintegrated MSP, the mobility service is being provided by the MSP itself, > it becomes a bit more difficult to do local HA service, since there is no > way the DNS SRV RR can be specialized to the local domain, but there are > some other possibilities (like preprovisioning the MN with domain names > where local service is available, like iPASS does with telephone numbers of > NASes). > > jak > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 03:55:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13750 for ; Wed, 16 Feb 2005 03:55:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1LJh-0005Bu-Nb for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 04:17:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Kvi-0006Z2-C4; Wed, 16 Feb 2005 03:53:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1KoR-0004l3-4C for mip6@megatron.ietf.org; Wed, 16 Feb 2005 03:45:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12744 for ; Wed, 16 Feb 2005 03:45:32 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1L9e-0004qu-8q for mip6@ietf.org; Wed, 16 Feb 2005 04:07:30 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IBZ00A29X52E6@dns2.cselt.it> for mip6@ietf.org; Wed, 16 Feb 2005 09:34:14 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 09:44:38 +0100 Date: Wed, 16 Feb 2005 09:45:01 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] mip6-aaa frameworks To: Erik Nordmark Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] mip6-aaa frameworks Thread-Index: AcUTsVxcRlv58UcATbmWJnyQ1BaH0wAUCkNA Content-class: urn:content-classes:message X-OriginalArrivalTime: 16 Feb 2005 08:44:38.0265 (UTC) FILETIME=[BFA50E90:01C51403] X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Hi Erik, >=20 > Alper Yegin wrote: > > This is an attempt to enumerate possible MIP6-AAA=20 > frameworks, and start > > discussions on for which one(s) IETF shall pursue standardization.=20 >=20 > Good summary. >=20 > FWIW I think that framework 4 is the key one to standardize,=20 > because it=20 > allows the network access AAA being decoupled from the MIP6 AAA. >=20 > Not that it doesn't require that they be completely separate,=20 > since the=20 > same AAA backend and the same NAI (and perhaps even EAP=20 > method) could be=20 > used for the cases when the same identity is used for noth=20 > the network=20 > access and for MIP6. And AFAIK it is this backend=20 > infrastructure concern=20 > that is key for the operators. > I agree that framework 4 should be standardized. draft-chakrabati-mip6-bmip-00 describes a solution based on this framework that allows also dynamic HA discovery. I guess this draft could be a good starting point. Since in this draft the HA acts as a EAP pass-through authenticator, I think we should also investigate if Diameter EAP application is suitable for the HA-AAA communication or we need another draft specifying a new Diameter application or some new MIPv6-specific AVPs. However note that this approach is not optimized in case of Integrated ASP: in this scenario, the MN needs to execute two EAP runs, one EAP for network access authentication and the other EAP over IKEv2 and, as you mention, the same AAA backend, the same NAI and even the same EAP method could be used for these two cases. For this reason, I think that we should standardize also an optimized approach in which AAA for network access and AAA for mobility service are dependent and only one EAP exchange needs to be executed. Note that here I'm not not advocating any of the solutions proposed so far (e.g. EAP, PANA, Diameter, DHCP), I'm only suggesting to have also an optimized solution that might be useful to mobile operators that would like to deploy MIPv6 in an efficient way. Regards, --Gerardo =20 =20 > I think that degree of separation is the right thing for an=20 > IETF standard. >=20 > Erik >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 04:31:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17488 for ; Wed, 16 Feb 2005 04:31:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Lrk-00069y-4u for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 04:53:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1LTX-0007jA-OI; Wed, 16 Feb 2005 04:28:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1LSD-0007I2-KC for mip6@megatron.ietf.org; Wed, 16 Feb 2005 04:26:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17211 for ; Wed, 16 Feb 2005 04:26:39 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1LnR-000642-55 for mip6@ietf.org; Wed, 16 Feb 2005 04:48:37 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 18:26:54 +0900 Message-ID: <004401c51409$928b96d0$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: "Gerardo Giaretta" , "Erik Nordmark" References: Subject: Re: [Mip6] mip6-aaa frameworks Date: Wed, 16 Feb 2005 18:26:19 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Feb 2005 09:26:54.0613 (UTC) FILETIME=[A76D0C50:01C51409] X-Spam-Score: 2.2 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1344918921==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --===============1344918921== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8sIEdlcmFyZG8uDQoNCj5JIGFncmVlIHRoYXQgZnJhbWV3b3JrIDQgc2hvdWxkIGJlIHN0 YW5kYXJkaXplZC4NCj5kcmFmdC1jaGFrcmFiYXRpLW1pcDYtYm1pcC0wMCBkZXNjcmliZXMgYSBz b2x1dGlvbiBiYXNlZCBvbiB0aGlzDQo+ZnJhbWV3b3JrIHRoYXQgYWxsb3dzIGFsc28gZHluYW1p YyBIQSBkaXNjb3ZlcnkuIEkgZ3Vlc3MgdGhpcyBkcmFmdA0KPmNvdWxkIGJlIGEgZ29vZCBzdGFy dGluZyBwb2ludC4gDQoNClRoZSBkeW5hbWljIEhBIGRpc2NvdmVyeSBpcyBzdGlsbCBhbiBpc3N1 ZS4NCldpdGggbXkgbWluZCwgYWRkaW5nIHNlY3VyaXR5IG1lY2hhbmlzbSB0byB0aGUgcHJlLWV4 aXN0aW5nIEROUyBxdWVyeSBtYXkgYmUgYSBidXJkZW4uIA0KSSB3b3VsZCBsaWtlIHRvIHdhaXQg dG8gbG9vayBvdmVyIHRoZSBuZXh0IHZlcnNpb24gb2YgdGhhdCBkcmFmdC4NCldpdGggcmVnYXJk cyB0byB0aGUgZnJhbWV3b3JrIDQsDQpJIGFtIHN0aWxsIG5vdCBjbGVhciBhYm91dCB3aGF0IHRo ZSBtb2JpbGl0eSBzZXJ2aWNlIGlzLg0KSSB0aGluayB0aGUgbW9iaWxpdHkgc2VydmljZSBpcyBz dGFydGVkIHdoZW4gdGhlIE1OIGJvb3RzdHJhcHMuDQpXaGVuIGRvZXMgdGhlIG1vYmlsaXR5IHNl cnZpY2UgZW5kID8NCk1JUHY2IGFsc28gc3VwcG9ydHMgdGhlIFJSLiANClRoYXQgbWVhbnMgdGhh dCB0aGUgSEEgbWF5IG5vdCBrbm93IGhvdyBtYW55IHBhY2tldHMgd2VyZSB0cmFzdmVyc2VkIGZv ciB0aGUgTU4uDQpXaXRoIHJlbGF0ZWQgd2l0aCB0aGlzIHBvaW50LCBhY2NvdW50aW5nIHByb2Nl c3NpbmcgaW4gdGhlIEFBQSBzZXJ2ZXIgY2FuIGJlIGFuIGlzc3VlLg0KQXMgaSBrbm93LCBjdXJy ZW50bHkgQUFBIGFjY291bnRpbmcgaXMgcHJvY2Vzc2VkIGZvciB0aGUgbmV0d29yayBhY2Nlc3Mg c2VydmljZS4NCklmIHdlIHRyeSB0byBjaGFyZ2Ugb25seSBmb3IgdGhlIG1vYmlsaXR5IHNlcnZp Y2UsIHdlIG5lZWQgdG8gY2xlYXJseSBkZWZpbmUgd2hhdCB0aGUgbW9iaWxpdHkgc2VydmljZSBp cy4NCg0KPkhvd2V2ZXIgbm90ZSB0aGF0IHRoaXMgYXBwcm9hY2ggaXMgbm90IG9wdGltaXplZCBp biBjYXNlIG9mIEludGVncmF0ZWQNCj5BU1A6IGluIHRoaXMgc2NlbmFyaW8sIHRoZSBNTiBuZWVk cyB0byBleGVjdXRlIHR3byBFQVAgcnVucywgb25lIEVBUCBmb3INCj5uZXR3b3JrIGFjY2VzcyBh dXRoZW50aWNhdGlvbiBhbmQgdGhlIG90aGVyIEVBUCBvdmVyIElLRXYyIGFuZCwgYXMgeW91DQo+ bWVudGlvbiwgdGhlIHNhbWUgQUFBIGJhY2tlbmQsIHRoZSBzYW1lIE5BSSBhbmQgZXZlbiB0aGUg c2FtZSBFQVAgbWV0aG9kDQo+Y291bGQgYmUgdXNlZCBmb3IgdGhlc2UgdHdvIGNhc2VzLiBGb3Ig dGhpcyByZWFzb24sIEkgdGhpbmsgdGhhdCB3ZQ0KPnNob3VsZCBzdGFuZGFyZGl6ZSBhbHNvIGFu IG9wdGltaXplZCBhcHByb2FjaCBpbiB3aGljaCBBQUEgZm9yIG5ldHdvcmsNCj5hY2Nlc3MgYW5k IEFBQSBmb3IgbW9iaWxpdHkgc2VydmljZSBhcmUgZGVwZW5kZW50IGFuZCBvbmx5IG9uZSBFQVAN Cj5leGNoYW5nZSBuZWVkcyB0byBiZSBleGVjdXRlZC4gTm90ZSB0aGF0IGhlcmUgSSdtIG5vdCBu b3QgYWR2b2NhdGluZyBhbnkNCj5vZiB0aGUgc29sdXRpb25zIHByb3Bvc2VkIHNvIGZhciAoZS5n LiBFQVAsIFBBTkEsIERpYW1ldGVyLCBESENQKSwgSSdtDQo+b25seSBzdWdnZXN0aW5nIHRvIGhh dmUgYWxzbyBhbiBvcHRpbWl6ZWQgc29sdXRpb24gdGhhdCBtaWdodCBiZSB1c2VmdWwNCj50byBt b2JpbGUgb3BlcmF0b3JzIHRoYXQgd291bGQgbGlrZSB0byBkZXBsb3kgTUlQdjYgaW4gYW4gZWZm aWNpZW50IHdheQ0KDQpUaGlzIGlzIGEgcmVhc29uIHdoeSBJIHdvdWxkIGxpa2UgdG8gdGhpbmsg YWJvdXQgdGhlIGJvb3RzdHJhcHBpbmcgZnJhbWV3b3JrIGZpcnN0Lg0KDQpKdW5naG9vbg== --===============1344918921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1344918921==-- From mip6-bounces@ietf.org Wed Feb 16 04:56:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19494 for ; Wed, 16 Feb 2005 04:56:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1MGc-0006l4-Gt for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 05:18:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Lp6-0004PX-DI; Wed, 16 Feb 2005 04:50:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1LjO-0002w8-1N for mip6@megatron.ietf.org; Wed, 16 Feb 2005 04:44:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18503 for ; Wed, 16 Feb 2005 04:44:23 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1M4b-0006Tc-NL for mip6@ietf.org; Wed, 16 Feb 2005 05:06:22 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Feb 2005 18:44:40 +0900 Message-ID: <008401c5140c$0e1f9100$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: , "Gopal Dommety" References: <4.3.2.7.2.20050215120213.026355d0@mira-sjc5-d.cisco.com> Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for bootstrapping Mobile IPv6 ) Date: Wed, 16 Feb 2005 18:44:05 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 16 Feb 2005 09:44:40.0909 (UTC) FILETIME=[22FCE7D0:01C5140C] X-Spam-Score: 2.2 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0611280225==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc --===============0611280225== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8sIEdvcGFsDQoNCkkgd291bGQgbGlrZSB0byByZS1jb21tZW50IGFib3V0IHRoaXMgV0cg SS1ELg0KSSB0aGluayB0aGlzIEktRCBuZWVkcyB0byBiZSByZWZpbmVkIHRvIGNsZWFybHkgc3Rh dGUgYWJvdXQgDQp0aGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIG5ldHdvcmsgYWNjZXNzIHNl cnZpY2UgYW5kIG1vYmlsaXR5IHNlcnZpY2UsDQomIGxvY2FsIGhvbWUgYWdlbnQgYXNzaWdubWVu dCBpc3N1ZS4NCkkgcmFpc2VkIDMgcXVlc3Rpb25zIHJlbGF0ZWQgd2l0aCB0aGlzIGFzIGZvbGxv d3MuDQoNClExLiBTaG91bGQgdGhlIG5ldHdvcmsgYWNjZXNzIHNlcnZpY2UgYmUgYWx3YXlzIHBl cmZvcm1lZCB3aGVuIGEgTU4gYm9vdHN0cmFwcyA/IA0Kfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NClNlY3Rpb24gNi4gIE5ldHdvcmsg QWNjZXNzIGFuZCBNb2JpbGl0eSBzZXJ2aWNlcw0KW1BhZ2UgMTRdDQpPbmx5IGhhdmluZyBNb2Jp bGUgSVB2NiBzZXJ2aWNlIGlzIG5vdCBwb3NzaWJsZSwgc2luY2UgdGhlIE1vYmlsZSBJUHY2IHBy b3RvY29sIHJlcXVpcmVzDQphYmlsaXR5IHRvIHNlbmQgYW5kIHJlY2VpdmUgSVB2NiBwYWNrZXRz LiAgDQo9PiBJdCBzZWVtcyB0aGF0IG5ldHdvcmsgYWNjZXNzIHNlcnZpY2Ugc2hvdWxkIGJlIGFs d2F5cyBwZXJmb3JtZWQuDQoNClNlY3Rpb24gNy4xICBNb2JpbGl0eSBTZXJ2aWNlIFN1YnNjcmlw dGlvbiBTY2VuYXJpbw0KPT4gVGhlcmUgaXMgbm8gd29yZHMgYWJvdXQgbmV0d29yayBhY2Nlc3Mg c2VydmljZS4NCg0KUTIuIERvZXMgd2UgaGF2ZSB0byBjb25zaWRlciB0aGUgY2FzZSBvZiAgaW5m cmFzdHJ1Y3R1cmUtbGVzcyBzY2VuYXJpbyB3aGVuIHdlIGRldmVsb3AgYSBib290c3RyYXBwaW5n IHNvbHV0aW9uIG9yIG5vdCA/DQp+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn4NClNlY3Rpb24g Ny40IEluZnJhc3RydWN0dXJlLWxlc3Mgc2NlbmFyaW8NCltQYWdlIDE3XQ0KVGhpcyBzcGVjaWZp YyBzY2VuYXJpbyBpcyBub3Qgc3VwcG9ydGVkIGluIHRoaXMgZG9jdW1lbnQuICBUaGUgcmVhc29u DQpmb3IgdGhpcyBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA5Lg0KU2VjdGlvbiA5LiBTZWN1cml0 eSBDb25zaWRlcmF0aW9ucw0KVGh1cywgdGhlIGNhc2Ugb2YgaW5mcmFzdHJ1Y3R1cmUtbGVzcyBu ZXR3b3JrIHdoZXJlIHRoZXJlIGlzIGFic29sdXRlbHkgDQpubyBwcmUtbWVkaWF0ZWQgdHJ1c3Qg aXMga2VwdCBvdXRzaWRlIG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQo9PiBJdCBzZWVtcyB0 aGF0IHdlIGRvbid0IG5lZWQgdG8gY29uc2lkZXIgdGhlIGluZnJhc3RydWN0dXJlLWxlc3Mgc2Nl bmFyaW8gDQogICAgIHdoZW4gd2UgY3JlYXRlIGEgYm9vdHN0cmFwcGluZyBzb2x1dGlvbi4NCg0K UTMuIERvZXMgYSBib290c3RyYXBwaW5nIHNvbHV0aW9uIHNob3VsZCBzdXBwb3J0IGxvY2FsIGhv bWUgYWdlbnQgYXNzaWdubWVudCBvciBub3QgPw0Kfn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+DQpTZWN0aW9uIDUuMS4yICBEeW5h bWljIEhvbWUgQWdlbnQgQXNzaWdubWVudA0KW1BhZ2UgMTBdDQpMb2NhbCBob21lIGFnZW50cw0K ICAgICAgVGhlIG1vYmlsZSBub2RlJ3MgaG9tZSBBU1AgbWF5IHdhbnQgdG8gYWxsb3cgYSBsb2Nh bCByb2FtaW5nDQogICAgICBwYXJ0bmVyIEFTUCB0byBhc3NpZ24gYSBsb2NhbCBob21lIGFnZW50 IGZvciB0aGUgbW9iaWxlIG5vZGUuDQogICAgICBUaGlzIGlzIHVzZWZ1bCBib3RoIGZyb20gdGhl IHBvaW50IG9mIHZpZXcgb2YgY29tbXVuaWNhdGlvbnMNCiAgICAgIGVmZmljaWVuY3ksIGFuZCBo YXMgYWxzbyBiZWVuIG1lbnRpb25lZCBhcyBvbmUgYXBwcm9hY2ggdG8gc3VwcG9ydA0KICAgICAg bG9jYXRpb24gcHJpdmFjeS4NCj0+IFdoYXQgaXMgdGhlIGV4YWN0IG1lYW5pbmcgb2YgdGhlICd1 c2VmdWwnIGFuZCAnYWxzbyBiZWVuIG1lbnRpb25lZCcgPw0KICAgICBJcyB0aGUgbG9jYWwgaG9t ZSBhZ2VudCBmdW5jdGlvbiBvcHRpb25hbFtNQVldID8NCg0KZHJhZnQtbGUtYWFhLW1pcHY2LXJl cXVpcmVtZW50cy0wMy50eHQNClNlY3Rpb24gNS41LiAgSG9tZSBhZ2VudCBhbGxvY2F0aW9uDQog ICBTdWNoIGZ1bmN0aW9uYWxpdHkgU0hPVUxEIGFsc28gYmUgY29uc2lkZXJlZCB3aGVuIGRlc2ln bmluZyB0aGUgQUFBDQogICBzdXBwb3J0IGZvciBNSVB2NiBzb2x1dGlvbi4NCj0+IEl0IHNlZW1z IHRoYXQgd2UgU0hPVUxEIHN1cHBvcnQgdGhlIGxvY2FsIEhBIGFzc2lnbm1lbnQgZnVuY3Rpb24u DQpJIGFscmVhZHkga25vdyB0aGF0IGRyYWZ0LWlldGYtbWlwNi1ib290c3RyYXAtcHMgaXMgbm90 IGEgSS1EIHRoYXQgZGVzY3JpYmUgdGhlIHJlcXVpcmVtZW50ICYNCmRyYWZ0LWxlLWFhYS1taXB2 Ni1yZXF1aXJlbWVudHMgd2FzIGV4cGlyZWQuIA0KQnV0IGkgdGhpbmsgdGhhdCB3ZSBoYXZlIHRv IGRlY2lkZSBhYm91dCB0aGlzIGJlY2F1c2UgbWFueSBkaWZmZXJlbnQgYXBwcm9hY2hlcyBjYW4g YmUgY29tZSBvdXQgZGVwZW5kaW5nIG9uIG91ciBkZWNpc2lvbi4NCg0KLS1KdW5naG9vbg0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkdvcGFsIERvbW1ldHkiIDxnZG9t bWV0eUBjaXNjby5jb20+DQpUbzogPG1pcDZAaWV0Zi5vcmc+DQpTZW50OiBXZWRuZXNkYXksIEZl YnJ1YXJ5IDE2LCAyMDA1IDU6MTEgQU0NClN1YmplY3Q6IFtNaXA2XSBXRyBMQzogSS1EIGRyYWZ0 LWlldGYtbWlwNi1ib290c3RyYXAtcHMtMDEudHh0IChQcm9ibGVtIFN0YXRlbWVudCBmb3IgYm9v dHN0cmFwcGluZyBNb2JpbGUgSVB2NiApDQoNCg0KPiANCj4gSGVsbG8gQWxsLA0KPiANCj4gDQo+ IFRoaXMgaXMgYSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgdGhlIGZvbGxvd2luZyBJLUQ6 DQo+IGRyYWZ0LWlldGYtbWlwNi1ib290c3RyYXAtcHMtMDEudHh0DQo+IFRpdGxlOg0KPiBQcm9i bGVtIFN0YXRlbWVudCBmb3IgYm9vdHN0cmFwcGluZyBNb2JpbGUgSVB2Ng0KPiANCj4gUGxlYXNl IG5vdGUgdGhhdCB0aGUgc3RhdHVzIGludGVuZGVkIGZvciB0aGlzIEktRCBpcyBQcm9wb3NlZCBT dGFuZGFyZC4NCj4gDQo+IFBsZWFzZSByZXZpZXcgYW5kIHBvc3QgeW91ciBjb21tZW50cyBieSBN YXJjaCAzcmQsIDIwMDUuDQo+IA0KPiAtQ2hhaXJzLA0KPiANCj4gVVJMLUlEIGlzOg0KPiBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLW1pcDYtYm9vdHN0cmFw LXBzLTAxLnR4dA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gTWlwNiBtYWlsaW5nIGxpc3QNCj4gTWlwNkBpZXRmLm9yZw0KPiBodHRwczov L3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taXA2 --===============0611280225== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0611280225==-- From mip6-bounces@ietf.org Wed Feb 16 06:15:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25278 for ; Wed, 16 Feb 2005 06:15:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1NUp-0000DY-RE for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 06:37:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1N5l-0007bO-VK; Wed, 16 Feb 2005 06:11:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1N1A-0006v8-UG for mip6@megatron.ietf.org; Wed, 16 Feb 2005 06:06:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24688 for ; Wed, 16 Feb 2005 06:06:49 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1NMP-0008Si-8Z for mip6@ietf.org; Wed, 16 Feb 2005 06:28:49 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j1GB6hJH021069; Wed, 16 Feb 2005 12:06:43 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1GB6giQ031474; Wed, 16 Feb 2005 12:06:42 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRJN8C>; Wed, 16 Feb 2005 12:06:42 +0100 Message-ID: From: Tschofenig Hannes To: "'Rafa Marin Lopez'" , Alper Yegin Subject: AW: [Mip6] mip6-aaa frameworks Date: Wed, 16 Feb 2005 12:05:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: quoted-printable hi rafa,=20 please see a comment inline: > -----Urspr=FCngliche Nachricht----- > Von: Rafa Marin Lopez [mailto:rafa@dif.um.es]=20 > Gesendet: Dienstag, 15. Februar 2005 18:12 > An: Alper Yegin > Cc: mip6@ietf.org > Betreff: Re: [Mip6] mip6-aaa frameworks >=20 >=20 > Hi Alper,all >=20 > I think this classification could be summarized in two models (agent=20 > sequence and pull sequence) in this sense: >=20 > Taking into account that HA would be service equipment for=20 > Mobile IPv6=20 > service then: >=20 > if people want pull sequence then they need to know HA address and=20 > execute some kind of protocol between MT and NAS(HA) and HA=20 > contacts AAA=20 > server (framework 4) >=20 > MT------HA------AAA >=20 > if people want (framework 1, framework 2, framework 3) to=20 > deliver MIP6=20 > configuration parameters with network access, agent sequence=20 > could fit=20 > in the majority of these cases >=20 > MT-----AAA-----HA i think that this sequence is not quite right since the mt cannot = directly interact with the aaa protocol, in most cases.=20 you might need to rely on pana or specific eap methods to finally = contact the aaa server.=20 your two models sound like push and pull model. i think that this is = yet another design aspect that is mostly unrelated to the solutions. since = most mechanisms would support both.=20 >=20 >=20 > note1 : you may want to include=20 > draft-ohba-mip6-boot-arch-dhcp-00.txt in=20 > framework 2. > note2 : draft-bournelle-pana-mip6-00 can match with sequences=20 > shown by=20 > draft-ohba-aaaarch-authorization-delegation-00 ciao \hannes >=20 > Regards. >=20 > Alper Yegin wrote: >=20 > >This is an attempt to enumerate possible MIP6-AAA=20 > frameworks, and start > >discussions on for which one(s) IETF shall pursue standardization.=20 > > > >Framework 1: > >------------ > >Using network access AAA to deliver MIP6 configuration=20 > parameters from > >the AAA server to the MN.=20 > > > >MIP6 configuration is directly delivered from the AAA server=20 > to the MN > >during network access AAA, in-band with the authentication (e.g., > >transported by EAP or EAP methods). > > > >Related I-Ds: > > > >draft-giaretta-mip6-authorization-eap-01 > >draft-le-aaa-mipv6-requirements-03 > >draft-ohnishi-mip6-aaa-problem-statement-00 > > > >Discussion: > > > >The end2end transport between the AAA and the MN is the key.=20 > Use of EAP > >for this somewhat network access unrelated "configuration" is not > >recommended as far as I understand. One can design his own=20 > EAP method to > >do that, yet that would have limited applicability. > > > > > >Framework 2: > >------------ > >Using network access AAA to deliver MIP6 configuration=20 > parameters from > >the AAA server to the NAS. It is assumed that parameters will be > >delivered from the NAS to the MN via another protocol (e.g.,=20 > DHCP, PANA, > >etc.) > > > >Related I-Ds: > > > >draft-chowdhury-mip6-bootstrap-radius-00 > >draft-jang-dhc-haopt-00 > > > >Discussion: > > > >This is similar to NAS learning the IP address for the connected = host > >via RADIUS, and delivering it to the host via DHCP. > > > >James had a comment regarding not having to support intra-operator > >interoperability. I think regardless of the deployment,=20 > interoperability > >between vendors is the important. Also, I was not sure on=20 > the complexity > >argument. > > > >3GPP2 has already chosen this scheme. Some other SDO(s) may=20 > follow the > >suit. > > > >Framework 3: > >------------ > >Piggybacking MIP6 signaling (BU) with network access AAA.=20 > In-band with > >the network access authentication execution, the MN delivers > >(piggybacks) a BU to the AAA server. The AAA server may have to = relay > >the BU to the HA (unless collocated). =20 > > > >Related I-D: > > > >draft-le-aaa-mipv6-requirements-03 > > > >Discussion: > > > >While the performance benefits are clear, limited applicability (not > >always the network access and mobility services are bundled) and > >complexity are concerning. > > > > > >Framework 4: > >------------ > >A backend AAA protocol is executed between the HA and the=20 > AAA server in > >response to the MIP6 signaling between the MN and the HA.=20 > Similar to the > >use of AAA protocols with MIPv4 co-located care-of address case. > > > >Related I-Ds: > > > >draft-giaretta-mip6-aaa-ha-goals-00.txt > >draft-yegin-mip6-aaa-fwk-00.txt > > > >Discussion: > >This one appears to be the most needed framework. It is=20 > assumed that MN > >already knows the HA address.=20 > > > > > >Are there other frameworks to add? > > > >I am sure I have missed some references, please let us know=20 > which ones. > > > >Alper > > > > > > > > > >_______________________________________________ > >Mip6 mailing list > >Mip6@ietf.org > >https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > =20 > > >=20 >=20 > --=20 > ------------------------------------------------------ > Rafael Marin Lopez > Faculty of Computer Science-University of Murcia > 30071 Murcia - Spain > Telf: +34968367645 e-mail: rafa@dif.um.es > ------------------------------------------------------ >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 07:43:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03560 for ; Wed, 16 Feb 2005 07:43:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1OsI-0002hI-Ll for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 08:05:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1OUS-0002MA-65; Wed, 16 Feb 2005 07:41:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1OPY-0001Yu-6X for mip6@megatron.ietf.org; Wed, 16 Feb 2005 07:36:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02607 for ; Wed, 16 Feb 2005 07:36:06 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Okk-0002JQ-Gl for mip6@ietf.org; Wed, 16 Feb 2005 07:58:05 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id C6DEA8273; Wed, 16 Feb 2005 13:35:27 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.34) id 1D1OOO-0003At-MR; Wed, 16 Feb 2005 13:34:56 +0100 Date: Wed, 16 Feb 2005 13:34:56 +0100 From: Julien Bournelle To: Alper Yegin Subject: Re: [Mip6] mip6-aaa frameworks Message-ID: <20050216123456.GJ11112@ipv6-3.int-evry.fr> References: <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> User-Agent: Mutt/1.5.6+20040907i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Hi all, more comments concerning framework 1 and 2 inline: On Mon, Feb 14, 2005 at 10:44:19PM -0800, Alper Yegin wrote: > > Framework 1: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the MN. > > MIP6 configuration is directly delivered from the AAA server to the MN > during network access AAA, in-band with the authentication (e.g., > transported by EAP or EAP methods). > > Related I-Ds: > > draft-giaretta-mip6-authorization-eap-01 > draft-le-aaa-mipv6-requirements-03 > draft-ohnishi-mip6-aaa-problem-statement-00 > > Discussion: > > The end2end transport between the AAA and the MN is the key. Use of EAP > for this somewhat network access unrelated "configuration" is not > recommended as far as I understand. One can design his own EAP method to > do that, yet that would have limited applicability. Concerning this framework, it appears that we have 2 possibilities: - define a new EAP method, the EAP server will be in charge of selecting the right method based on NAI for example. The problem is that we could have a user having the mip6 stack but who didn't want to use it. With this approach, it appears that we always configure the mip6 service. - use EAP-TLVs (draft-giaretta-mip6-authorization), the problem here is that EAP hasn't been designed for configuration. > Framework 2: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the NAS. It is assumed that parameters will be > delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, > etc.) > > Related I-Ds: > > draft-chowdhury-mip6-bootstrap-radius-00 > draft-jang-dhc-haopt-00 > > Discussion: > > This is similar to NAS learning the IP address for the connected host > via RADIUS, and delivering it to the host via DHCP. > > James had a comment regarding not having to support intra-operator > interoperability. I think regardless of the deployment, interoperability > between vendors is the important. Also, I was not sure on the complexity > argument. > > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the > suit. Concerning this framework, I also see 2 possibilities: - add mip6 functionalities to exisiting applications: basically add some AVPs and mechanisms to RADIUS EAP/ Diameter EAP (if EAP is in use). This also imply some modifications to 802.1X/PANA/... - define a specific AAA application for mip6. In this case, we'll have at least two AAA applications used in the access network. The reason is that I guess we won't have only mip6 terminal. Thus the authentication agent will need a way to select the right application. The protocol used between the MN and the authentication agent will also need some modifications to handle this. -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 07:58:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05271 for ; Wed, 16 Feb 2005 07:58:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1P6j-00035r-DX for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 08:20:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Ok4-0005X5-Vh; Wed, 16 Feb 2005 07:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Oi6-00056J-Ut for mip6@megatron.ietf.org; Wed, 16 Feb 2005 07:55:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04987 for ; Wed, 16 Feb 2005 07:55:17 -0500 (EST) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1P3M-00030n-Ec for mip6@ietf.org; Wed, 16 Feb 2005 08:17:16 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j1GCtGFF011764; Wed, 16 Feb 2005 13:55:16 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1GCtFiQ010357; Wed, 16 Feb 2005 13:55:15 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRJQ7H>; Wed, 16 Feb 2005 13:55:15 +0100 Message-ID: From: Tschofenig Hannes To: "'Julien Bournelle'" , Alper Yegin Subject: AW: [Mip6] mip6-aaa frameworks Date: Wed, 16 Feb 2005 13:53:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable hi julien,=20 i think that framework 1 and 2 do not split the design space = particularly well. draft-chowdhury-mip6-bootstrap-radius-00 and draft-le-aaa-mipv6-requirements-03.txt have a few things in common.=20 i personally would like to see a solution that does not depend on = protocols that do not necessary have to deal with the bootstrapping procedure = itself.=20 for example, what protocols do you use to provide the bootstrapping parameters to the end host and how many administrative domains do they traverse. when you run a bootstrapping procedure for mip6 (or for other protocols as well) then why do you need to depend on some = infrastructure in the visited network (particularly when want something from the home network)?=20 ciao hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20 > Gesendet: Mittwoch, 16. Februar 2005 13:35 > An: Alper Yegin > Cc: mip6@ietf.org > Betreff: Re: [Mip6] mip6-aaa frameworks >=20 >=20 > Hi all, >=20 > more comments concerning framework 1 and 2 inline: >=20 > On Mon, Feb 14, 2005 at 10:44:19PM -0800, Alper Yegin wrote: > >=20 > > Framework 1: > > ------------ > > Using network access AAA to deliver MIP6 configuration=20 > parameters from > > the AAA server to the MN.=20 > >=20 > > MIP6 configuration is directly delivered from the AAA=20 > server to the MN > > during network access AAA, in-band with the authentication (e.g., > > transported by EAP or EAP methods). > >=20 > > Related I-Ds: > >=20 > > draft-giaretta-mip6-authorization-eap-01 > > draft-le-aaa-mipv6-requirements-03 > > draft-ohnishi-mip6-aaa-problem-statement-00 > >=20 > > Discussion: > >=20 > > The end2end transport between the AAA and the MN is the=20 > key. Use of EAP > > for this somewhat network access unrelated "configuration" is not > > recommended as far as I understand. One can design his own=20 > EAP method to > > do that, yet that would have limited applicability. >=20 > Concerning this framework, it appears that we have 2 possibilities: >=20 > - define a new EAP method, the EAP server will be in charge of > selecting the right method based on NAI for example. The problem = is > that we could have a user having the mip6 stack but who didn't = want > to use it. With this approach, it appears that we always configure > the mip6 service. >=20 > - use EAP-TLVs (draft-giaretta-mip6-authorization), the=20 > problem here is > that EAP hasn't been designed for configuration. >=20 > > Framework 2: > > ------------ > > Using network access AAA to deliver MIP6 configuration=20 > parameters from > > the AAA server to the NAS. It is assumed that parameters will be > > delivered from the NAS to the MN via another protocol=20 > (e.g., DHCP, PANA, > > etc.) > >=20 > > Related I-Ds: > >=20 > > draft-chowdhury-mip6-bootstrap-radius-00 > > draft-jang-dhc-haopt-00 > >=20 > > Discussion: > >=20 > > This is similar to NAS learning the IP address for the=20 > connected host > > via RADIUS, and delivering it to the host via DHCP. > >=20 > > James had a comment regarding not having to support intra-operator > > interoperability. I think regardless of the deployment,=20 > interoperability > > between vendors is the important. Also, I was not sure on=20 > the complexity > > argument. > >=20 > > 3GPP2 has already chosen this scheme. Some other SDO(s) may=20 > follow the > > suit. >=20 > Concerning this framework, I also see 2 possibilities: >=20 > - add mip6 functionalities to exisiting applications:=20 > basically add some > AVPs and mechanisms to RADIUS EAP/ Diameter EAP (if EAP is in = use). > This also imply some modifications to 802.1X/PANA/... >=20 > - define a specific AAA application for mip6. In this case,=20 > we'll have > at least two AAA applications used in the access network.=20 > The reason > is that I guess we won't have only mip6 terminal. Thus the > authentication agent will need a way to select the right=20 > application. > The protocol used between the MN and the authentication agent will > also need some modifications to handle this. >=20 >=20 > --=20 > julien.bournelle@int-evry.fr >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 08:25:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07661 for ; Wed, 16 Feb 2005 08:25:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1PWi-0003nb-4h for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 08:47:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1P1q-0000ry-IH; Wed, 16 Feb 2005 08:15:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1P04-0000VC-CT for mip6@megatron.ietf.org; Wed, 16 Feb 2005 08:13:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06731 for ; Wed, 16 Feb 2005 08:13:50 -0500 (EST) Received: from smtp.um.es ([155.54.212.103]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1PLK-0003VT-62 for mip6@ietf.org; Wed, 16 Feb 2005 08:35:50 -0500 Received: from smtp.um.es (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id BAD1C1D53; Wed, 16 Feb 2005 14:13:07 +0100 (CET) Received: from correo.um.es (zape.um.es [155.54.212.102]) by smtp.um.es (Postfix) with ESMTP id 4744E1812; Wed, 16 Feb 2005 14:12:54 +0100 (CET) Received: from [155.54.210.9] (dibulibu.um.es [155.54.1.250]) by correo.um.es (Postfix) with ESMTP id D95F15CD5; Wed, 16 Feb 2005 14:12:51 +0100 (MET) Message-ID: <421346D2.5020706@dif.um.es> Date: Wed, 16 Feb 2005 14:12:50 +0100 From: Rafa Marin Lopez User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tschofenig Hannes Subject: Re: AW: [Mip6] mip6-aaa frameworks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: quoted-printable Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable Hi Hannes ... thanks for your answer please see inline. Tschofenig Hannes wrote: >hi rafa,=20 > >please see a comment inline: > > =20 > >>-----Urspr=FCngliche Nachricht----- >>Von: Rafa Marin Lopez [mailto:rafa@dif.um.es]=20 >>Gesendet: Dienstag, 15. Februar 2005 18:12 >>An: Alper Yegin >>Cc: mip6@ietf.org >>Betreff: Re: [Mip6] mip6-aaa frameworks >> >> >>Hi Alper,all >> >>I think this classification could be summarized in two models (agent=20 >>sequence and pull sequence) in this sense: >> >>Taking into account that HA would be service equipment for=20 >>Mobile IPv6=20 >>service then: >> >>if people want pull sequence then they need to know HA address and=20 >>execute some kind of protocol between MT and NAS(HA) and HA=20 >>contacts AAA=20 >>server (framework 4) >> >>MT------HA------AAA >> >>if people want (framework 1, framework 2, framework 3) to=20 >>deliver MIP6=20 >>configuration parameters with network access, agent sequence=20 >>could fit=20 >>in the majority of these cases >> >>MT-----AAA-----HA >> =20 >> > >i think that this sequence is not quite right since the mt cannot direct= ly >interact with the aaa protocol, in most cases.=20 >you might need to rely on pana or specific eap methods to finally contac= t >the aaa server. > Well, when I said agent sequence I was not following strictly RFC 2904.=20 What I meant that MT contacts with AAA through some means (as you=20 correctly point out pana or eap methods for example) and AAA provides=20 MIP6 information to MT by using these means. But before to do that AAA=20 needs to contact with Service Equipment (HA) in order to set up the=20 service. After that further communication take place between MT and HA=20 for example to establish IPSec tunnel. >=20 > > >your two models sound like push and pull model. > Under my understanding , framework 4 is pull model. On the other hand in=20 push sequence there is no interaction with HA because of that I said=20 agent sequence. > i think that this is yet >another design aspect that is mostly unrelated to the solutions. since m= ost >mechanisms would support both.=20 > =20 > when you say "mechanisms" =3D mip6 boostrapping solutions?? On the other hand RFC 2904 defines AAA authorization framework and many=20 proposal is based on AAA so I think this is a good reference model. On=20 the one hand I agree with you that it could be too high level abstraction= . Regards --=20 ------------------------------------------------------ Rafael Marin Lopez Faculty of Computer Science-University of Murcia 30071 Murcia - Spain Telf: +34968367645 e-mail: rafa@dif.um.es ------------------------------------------------------ _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 11:12:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06857 for ; Wed, 16 Feb 2005 11:12:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1S88-0003VY-Ck for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 11:34:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1QwU-0002po-Dc; Wed, 16 Feb 2005 10:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1QjZ-0006Xv-MF for mip6@megatron.ietf.org; Wed, 16 Feb 2005 10:04:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18520 for ; Wed, 16 Feb 2005 10:04:54 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1R4o-0006dX-Ai for mip6@ietf.org; Wed, 16 Feb 2005 10:26:55 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC000G04F75M7@mailout3.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 00:04:17 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC0007W7F751F@mailout3.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 00:04:17 +0900 (KST) Received: from Alperyegin ([105.253.155.56]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IC0005XIF725P@mmp1.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 00:04:17 +0900 (KST) Date: Wed, 16 Feb 2005 07:04:12 -0800 From: Alper Yegin Subject: MIP6-AAA Fwk 2 (was RE: [Mip6] mip6-aaa frameworks) In-reply-to: <02e601c51389$21dd84a0$016115ac@dcml.docomolabsusa.com> To: "'James Kempf'" , mip6@ietf.org Message-id: <162f01c51438$c79cbff0$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7BIT (Catching up with e-mail... ) > > Framework 2: > > ------------ > > Using network access AAA to deliver MIP6 configuration parameters from > > the AAA server to the NAS. It is assumed that parameters will be > > delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, > > etc.) > > > > Related I-Ds: > > > > draft-chowdhury-mip6-bootstrap-radius-00 > > draft-jang-dhc-haopt-00 > > > > Discussion: > > > > This is similar to NAS learning the IP address for the connected host > > via RADIUS, and delivering it to the host via DHCP. > > > > James had a comment regarding not having to support intra-operator > > interoperability. I think regardless of the deployment, interoperability > > between vendors is the important. Also, I was not sure on the complexity > > argument. > > > > Consider the following. Suppose RADIUS is used to transfer operator A's HA > addresses from operator A's AAA server to operator B's NAS. First question > is whether the addresses are delivered every time a roamed host makes a > DHCP > request for the HA address? Since network access AAA happens before DHCP takes place, the HA address should be delivered via RADIUS even before MN asks for it. > If not and there is any caching going on, then > the addresses could get stale. It'd be as fresh as the network access session. > Second question is how the NAS > differentiates > which home operator to ask for the addresses? NAS gets what AAA home server (for network access) delivers. > Presumably an NAI but is > that > separate or combined with DHCP? This is a big change in the basic IETF > DHCP > architecture, IMHO. Managing DHCP configuration information within an > operator's domain is difficult enough. I don't see that. Please see newly issued RFC 4014. Or, Framed-IP-address attribute as defined in RFC 2865. > > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the > > suit. > > > > Can someone provide more details here? As far as I know, in the current > 3GPP2 MIP4 system, the PDSN is both home and foreign agent (please correct > if this is wrong), so I don't see how DHCP would come into the picture. > How > are they planning on changing that for MIP6? Are they really planning on > distributing the addresses of home agents between operators or just within > a > single operator? I'll let 3GPP2 folks comment on that. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 14:35:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07842 for ; Wed, 16 Feb 2005 14:35:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VIE-0006Es-Cq for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 14:57:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1SrO-0007A8-RY; Wed, 16 Feb 2005 12:21:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1RDG-0008Qj-VV for mip6@megatron.ietf.org; Wed, 16 Feb 2005 10:35:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25442 for ; Wed, 16 Feb 2005 10:35:36 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1RYW-0008Gp-L6 for mip6@ietf.org; Wed, 16 Feb 2005 10:57:37 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 8FA0D81CA; Wed, 16 Feb 2005 16:35:00 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.34) id 1D1RC9-0003ew-9h; Wed, 16 Feb 2005 16:34:29 +0100 Date: Wed, 16 Feb 2005 16:34:29 +0100 From: Julien Bournelle To: Tschofenig Hannes Subject: Re: [Mip6] mip6-aaa frameworks Message-ID: <20050216153429.GQ11112@ipv6-3.int-evry.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Alper Yegin , "'Julien Bournelle'" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 hi hannes, On Wed, Feb 16, 2005 at 01:53:52PM +0100, Tschofenig Hannes wrote: > > i think that framework 1 and 2 do not split the design space particularly > well. draft-chowdhury-mip6-bootstrap-radius-00 and > draft-le-aaa-mipv6-requirements-03.txt have a few things in common. they split the "AAA" approach. > i personally would like to see a solution that does not depend on protocols > that do not necessary have to deal with the bootstrapping procedure itself. > > for example, what protocols do you use to provide the bootstrapping > parameters to the end host and how many administrative domains do they > traverse. when you run a bootstrapping procedure for mip6 (or for other > protocols as well) then why do you need to depend on some infrastructure in > the visited network (particularly when want something from the home > network)? the idea is not to depend on some infrastructure. The "AAA" idea is that we could have this infrastructure available and that in this case it can be interesting to couple it with the bootstrapping procedure for authorization and accounting purpose. however, we can't assume that we always have a AAA system. In this case, we need framework 4 (or something else). Does this imply that we should reject framwork 1-2 ? -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 14:46:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10161 for ; Wed, 16 Feb 2005 14:46:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VTA-0006uH-Bj for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:08:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1TUe-0006nS-07; Wed, 16 Feb 2005 13:01:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1RfY-00072c-GN for mip6@megatron.ietf.org; Wed, 16 Feb 2005 11:04:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04880 for ; Wed, 16 Feb 2005 11:04:49 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1S0n-0002pq-RI for mip6@ietf.org; Wed, 16 Feb 2005 11:26:51 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC000101HZ5F2@mailout3.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 01:04:17 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC0005TBHZ4TP@mailout3.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 01:04:16 +0900 (KST) Received: from Alperyegin ([105.253.155.5]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IC0001VEHZ1BD@mmp2.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 01:04:16 +0900 (KST) Date: Wed, 16 Feb 2005 08:04:11 -0800 From: Alper Yegin Subject: MIP6-AAA Fwk 3 (was RE: [Mip6] mip6-aaa frameworks) In-reply-to: <011101c513c8$9a1d5e10$861167c0@adithya> To: "'Mohan Parthasarathy'" , mip6@ietf.org Message-id: <163001c51441$2955dd50$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7BIT > > Framework 3: > > ------------ > > Piggybacking MIP6 signaling (BU) with network access AAA. In-band with > > the network access authentication execution, the MN delivers > > (piggybacks) a BU to the AAA server. The AAA server may have to relay > > the BU to the HA (unless collocated). > > > > Related I-D: > > > > draft-le-aaa-mipv6-requirements-03 > > > > Discussion: > > > > While the performance benefits are clear, limited applicability (not > > always the network access and mobility services are bundled) and > > complexity are concerning. > > > Can you elaborate on the complexity issue ? - By the time network access AAA is executed: - MN must know its HA (may not be possible if the HA discovery is done after the access is authorized -- e.g., DHCP, DNS-based schemes) - MN must know its care-of address. (may not be possible if the CoA allocation depends on the network access authentication. - AAA_home server must decapsulate the BU and forward it to the HA. What is the source address in BU packets? (may be a ingress-filtering concern). - The BUack from the HA: is it sent back to MN directly, or forwarded to AAA_home and piggybacked in the AAA response to MN? - The results of mobility management and access authorization may need to be coordinated? What happens when one succeeds and other fails? - What is the transport for BU? EAP, or EAP lower layers, PPP+RADIUS, ? I don't claim these are impossible to answer, but clearly each answer would lead to additional complexity. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 15:04:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13826 for ; Wed, 16 Feb 2005 15:04:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Vko-0007zA-8u for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:26:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Uyo-0007Ou-9Z; Wed, 16 Feb 2005 14:36:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Szn-0003xs-Ct for mip6@megatron.ietf.org; Wed, 16 Feb 2005 12:29:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29708 for ; Wed, 16 Feb 2005 12:29:48 -0500 (EST) Received: from smtp808.mail.sc5.yahoo.com ([66.163.168.187]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1TL2-0002X1-Gt for mip6@ietf.org; Wed, 16 Feb 2005 12:51:52 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 16 Feb 2005 17:29:46 -0000 Message-ID: <004601c5144d$1c5866c0$861167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <163001c51441$2955dd50$291d9069@sisa.samsung.com> Subject: Re: MIP6-AAA Fwk 3 (was RE: [Mip6] mip6-aaa frameworks) Date: Wed, 16 Feb 2005 09:29:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit > > > Framework 3: > > > ------------ > > > Piggybacking MIP6 signaling (BU) with network access AAA. In-band > with > > > the network access authentication execution, the MN delivers > > > (piggybacks) a BU to the AAA server. The AAA server may have to > relay > > > the BU to the HA (unless collocated). > > > > > > Related I-D: > > > > > > draft-le-aaa-mipv6-requirements-03 > > > > > > Discussion: > > > > > > While the performance benefits are clear, limited applicability (not > > > always the network access and mobility services are bundled) and > > > complexity are concerning. > > > > > Can you elaborate on the complexity issue ? > > - By the time network access AAA is executed: > - MN must know its HA (may not be possible if the HA > discovery is done after the access is authorized -- e.g., > DHCP, DNS-based schemes) The access network most likely allows DNS requests to pass through. Perhaps i am biased by how WLAN hotspots work today.. > - MN must know its care-of address. (may not be possible if the > CoA allocation depends on the network access authentication. Good point. > - AAA_home server must decapsulate the BU and forward it to the HA. What > is the source address in BU packets? (may be a ingress-filtering > concern). > - The BUack from the HA: is it sent back to MN directly, or forwarded to > AAA_home and piggybacked in the AAA response to MN? These two steps are part of Diameter Mobile IPv4 application today and don't know how to asses their complexity. And you need this as part of option 4 also. > - The results of mobility management and access authorization may need > to be coordinated? What happens when one succeeds and other fails? > - What is the transport for BU? EAP, or EAP lower layers, PPP+RADIUS, ? > You mean the transport on the access link (between MN and access router). Yes, that needs to be decided. > I don't claim these are impossible to answer, but clearly each answer > would lead to additional complexity. > My concern is on how we assess that something is complex :-) -mohan > Alper > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 15:12:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15725 for ; Wed, 16 Feb 2005 15:12:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VsT-0008OU-4G for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:34:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VAc-0000L4-4B; Wed, 16 Feb 2005 14:49:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1TXz-0002Gg-Dk for mip6@megatron.ietf.org; Wed, 16 Feb 2005 13:05:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10011 for ; Wed, 16 Feb 2005 13:05:06 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1TtF-0005oe-6x for mip6@ietf.org; Wed, 16 Feb 2005 13:27:10 -0500 Message-ID: <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yoshihiro Ohba" References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Wed, 16 Feb 2005 10:06:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Yoshi, > I think that the complexity of a HA-AAA-NAS/DHCP interface is not much > different between inter-domain and intra-domain bootstrapping cases. > I mean that the complexity is basically about state synchronization on > configuration parameters between a AAA server, a DHCP server and a > DHCP server and is common to both inter-domain and intra-domain cases. > The complexity can be illustrated by the following scenario. Suppose something goes wrong on the interface and I am the manager in charge of network management. If it is an intra-administrative domain interface, I call up my network management people on their cell phone and they rush right out and fix it, since I pay them to be on duty 24 hours a day with cell phones hot to make sure our roaming customers get good service. Now, suppose it is an inter-domain interface. I call or send email to the equivalent person at the management level of the other domain. Maybe they answer the phone, maybe they don't and I end up playing telephone tag with them for 3 days until we finally manage to talk. Then it takes their people and my people a couple days to diagnose and fix the problem. Meanwhile, our roaming customers are not getting service. That, in a nutshell, is the problem. > > I don't believe anything needs to be standardized for > > intra-domain bootstrapping using DHCP except for the format of the record in > > DHCP for the MIP6 information, which impacts the MN-DHCP server interface. > > In a roaming situation, a home IMSP can indicate during the network access > > authentication that the MN should bootstrap off the local DHCP server, if a > > local HA, is available through the AAA-H to MN protocol (i.e. end to end), > > without having to do anything through the local DHCP server itself. > > I agree that this is a simple model. On the other hand, this provides > a less optimized solution in that the MN might need to execute two EAP > runs, one EAP for network access authentication (and to get a local HA > assigned to the MN) and the other EAP over IKEv2 between the MN and > the HA. Some operators may desire a more optimized solution in which > AAA for network access and AAA for mobility service are dependent and > only one EAP needs to be executed. > There need not be two EAP round trips if there is a flag in the EAP reply from the AAA-H which says that the MN should simply use DHCP to find a local HA address. The EAP reply configures the IPsec SA, avoiding the need for the IKEv2 transaction. The other alternative is that the AAA-H itself communicates with the AAA-F to obtain the local HA address, then sends it back in the EAP reply. In that case, there is an additional round trip on the back end, but, again there would be no need for the IKEv2 transaction if the EAP is used to configure the IPsec SA. Both of these have been discussed in the context of the draft-giaretta proposal for using EAP to do bootstrapping. I think you may be confusing draft-giaretta with draft-chakrabarti-bmip. The latter does propose using IKEv2, but there the initial EAP transaction for bootstrapping may or may not use AAA/EAP. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 15:17:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16594 for ; Wed, 16 Feb 2005 15:17:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VxW-00006z-TZ for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:39:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VFK-0004kF-3n; Wed, 16 Feb 2005 14:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Top-0004hn-K1 for mip6@megatron.ietf.org; Wed, 16 Feb 2005 13:22:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13975 for ; Wed, 16 Feb 2005 13:22:31 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1UA7-0007AR-2o for mip6@ietf.org; Wed, 16 Feb 2005 13:44:36 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id j1GIM3bj023353 for ; Wed, 16 Feb 2005 12:22:03 -0600 (CST) Received: by eamrcnt751.exu.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 16 Feb 2005 12:21:49 -0600 Received: from [142.133.116.23] (142.133.116.23 [142.133.116.23]) by EAMMLEX034.lmc.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 1913VQ62; Wed, 16 Feb 2005 13:21:59 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <285bb56f17a2ee6d147adc2d1742b043@ericsson.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: mip6 From: Wassim Haddad Date: Wed, 16 Feb 2005 13:24:21 -0500 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Subject: [Mip6] I-D ACTION:draft-haddad-momipriv-threat-model-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Hi all, > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Privacy for Mobile and Multi-homed Nodes (MoMiPriv): > Formalizing the Threat Model > Author(s) : W. Haddad, et al. > Filename : draft-haddad-momipriv-threat-model-00.txt > Pages : 18 > Date : 2005-2-15 > > This memo describes threats violating the privacy based on > identifiers used at the MAC and IP layers, in the context of > a mobile and multi-homed environment. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-haddad-momipriv-threat- > model-00.txt > A mailing list (momipriv) has been set up to discuss this topic. To subscribe, please visit: http://lacnic.net/mailman/listinfo/momipriv Comments are highly appreciated. Regards, Wassim H. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 15:19:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17004 for ; Wed, 16 Feb 2005 15:19:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VzK-0000BU-R0 for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:41:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VHY-0007lb-90; Wed, 16 Feb 2005 14:56:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Tz2-0003Aa-B6 for mip6@megatron.ietf.org; Wed, 16 Feb 2005 13:33:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17135 for ; Wed, 16 Feb 2005 13:33:04 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1UKH-0008Dn-C3 for mip6@ietf.org; Wed, 16 Feb 2005 13:55:09 -0500 Received: from jurassic.eng.sun.com ([129.146.85.105]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j1GIX2nK019574; Wed, 16 Feb 2005 11:33:02 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j1GIX1dA967945; Wed, 16 Feb 2005 10:33:02 -0800 (PST) Message-ID: <421391B8.3020706@sun.com> Date: Wed, 16 Feb 2005 10:32:24 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerardo Giaretta Subject: Re: [Mip6] mip6-aaa frameworks References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Gerardo Giaretta wrote: > Hi Erik, > I agree that framework 4 should be standardized. > draft-chakrabati-mip6-bmip-00 describes a solution based on this > framework that allows also dynamic HA discovery. I guess this draft > could be a good starting point. Since in this draft the HA acts as a EAP > pass-through authenticator, I think we should also investigate if > Diameter EAP application is suitable for the HA-AAA communication or we > need another draft specifying a new Diameter application or some new > MIPv6-specific AVPs. Yes, it makes sense to investigate this. > However note that this approach is not optimized in case of Integrated > ASP: in this scenario, the MN needs to execute two EAP runs, one EAP for > network access authentication and the other EAP over IKEv2 and, as you > mention, the same AAA backend, the same NAI and even the same EAP method > could be used for these two cases. For this reason, I think that we > should standardize also an optimized approach in which AAA for network > access and AAA for mobility service are dependent and only one EAP > exchange needs to be executed. Note that here I'm not not advocating any > of the solutions proposed so far (e.g. EAP, PANA, Diameter, DHCP), I'm > only suggesting to have also an optimized solution that might be useful > to mobile operators that would like to deploy MIPv6 in an efficient way. The thing that is a bit hard for me to understand is whether and how a MN can cope with both the separate and integrated ones. For instance, do we see there being a MN which will perform the integrated approach (if that is used by the access network) and fallback to use the separate approach? Or will there be completely separate MNs so that we don't need to worry about which to try first and the possible interaction between the two different schemes. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 15:20:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17175 for ; Wed, 16 Feb 2005 15:20:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1W08-0000DG-7O for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:42:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VIR-0001b7-8T; Wed, 16 Feb 2005 14:57:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1U7Y-0007ZC-4P for mip6@megatron.ietf.org; Wed, 16 Feb 2005 13:41:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19659 for ; Wed, 16 Feb 2005 13:41:51 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1USn-0000hv-Sm for mip6@ietf.org; Wed, 16 Feb 2005 14:03:56 -0500 Received: from jurassic.eng.sun.com ([129.146.81.36]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j1GIfmvB016216; Wed, 16 Feb 2005 10:41:48 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j1GIfmxV970540; Wed, 16 Feb 2005 10:41:48 -0800 (PST) Message-ID: <421393C7.8000704@sun.com> Date: Wed, 16 Feb 2005 10:41:11 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Junghoon Jee Subject: Re: [Mip6] mip6-aaa frameworks References: <004401c51409$928b96d0$6b70fe81@FlyToWorld> In-Reply-To: <004401c51409$928b96d0$6b70fe81@FlyToWorld> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Junghoon Jee wrote: > The dynamic HA discovery is still an issue. > With my mind, adding security mechanism to the pre-existing DNS query may be a burden. The need for confidentiality of the HAs IP address is hard for me to understand without understanding the threat model. Suppose there is perfect confidentiality. An attacker wants to attack the HA, and the attacker controls a large number of zombies for DDoS attack. It is sufficient for somebody, who has paid $10 for a month or an hour of service, to disclose the HA's IP address to the attacker, and then the DDoS attack can be launched towards that IP address. And for a large operator, the probability that one of their legitimate subscribers is infected with a zombie, is quite high when PCs might be the MN. Such a zombie could then share the IP address with the attacker. The upshot is that I don't think the subscribers can be trusted to not share the HA's IP address, either intentionally or unwittingly. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 15:20:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17292 for ; Wed, 16 Feb 2005 15:20:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1W0f-0000FC-IC for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:42:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VIu-0002rg-KK; Wed, 16 Feb 2005 14:57:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1UBa-0001Io-8B for mip6@megatron.ietf.org; Wed, 16 Feb 2005 13:46:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21131 for ; Wed, 16 Feb 2005 13:46:04 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1UWp-0001Ay-KB for mip6@ietf.org; Wed, 16 Feb 2005 14:08:07 -0500 Message-ID: <051701c51457$e83031b0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alper Yegin" , References: <162f01c51438$c79cbff0$291d9069@sisa.samsung.com> Subject: Re: MIP6-AAA Fwk 2 (was RE: [Mip6] mip6-aaa frameworks) Date: Wed, 16 Feb 2005 10:46:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit > > Presumably an NAI but is > > that > > separate or combined with DHCP? This is a big change in the basic IETF > > DHCP > > architecture, IMHO. Managing DHCP configuration information within an > > operator's domain is difficult enough. > > I don't see that. Please see newly issued RFC 4014. Or, > Framed-IP-address attribute as defined in RFC 2865. > Ok, but this is not for inter-domain transfer of configuration information AFIKT. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 15:31:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19559 for ; Wed, 16 Feb 2005 15:31:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WAv-0000rR-3m for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 15:53:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VRu-0006uI-ET; Wed, 16 Feb 2005 15:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1V2W-0002xL-GB for mip6@megatron.ietf.org; Wed, 16 Feb 2005 14:40:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09218 for ; Wed, 16 Feb 2005 14:40:46 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1VNo-0006dc-UR for mip6@ietf.org; Wed, 16 Feb 2005 15:02:49 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j1GJdGHr023289; Thu, 17 Feb 2005 04:39:17 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j1GJdGd7004595; Thu, 17 Feb 2005 04:39:16 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id EAA04592 ; Thu, 17 Feb 2005 04:39:16 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j1GJdGcb017065; Thu, 17 Feb 2005 04:39:16 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1GJdF6A025837; Thu, 17 Feb 2005 04:39:15 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1GJdF8a010646; Thu, 17 Feb 2005 04:39:15 +0900 (JST) Received: from steelhead (iVPN01-073.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IC000D1GRXC9R@tsbpo1.po.toshiba.co.jp>; Thu, 17 Feb 2005 04:39:12 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1D1UTb-00066G-00; Wed, 16 Feb 2005 11:04:43 -0800 Date: Wed, 16 Feb 2005 14:04:43 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> To: James Kempf Message-id: <20050216190443.GK18190@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Hi James, On Wed, Feb 16, 2005 at 10:06:02AM -0800, James Kempf wrote: > Yoshi, > > > I think that the complexity of a HA-AAA-NAS/DHCP interface is not much > > different between inter-domain and intra-domain bootstrapping cases. > > I mean that the complexity is basically about state synchronization on > > configuration parameters between a AAA server, a DHCP server and a > > DHCP server and is common to both inter-domain and intra-domain cases. > > > > The complexity can be illustrated by the following scenario. Suppose > something goes wrong on the interface and I am the manager in charge of > network management. If it is an intra-administrative domain interface, I > call up my network management people on their cell phone and they rush right > out and fix it, since I pay them to be on duty 24 hours a day with cell > phones hot to make sure our roaming customers get good service. Now, suppose > it is an inter-domain interface. I call or send email to the equivalent > person at the management level of the other domain. Maybe they answer the > phone, maybe they don't and I end up playing telephone tag with them for 3 > days until we finally manage to talk. Then it takes their people and my > people a couple days to diagnose and fix the problem. Meanwhile, our roaming > customers are not getting service. > > That, in a nutshell, is the problem. This seems to be a general problem that is common to any roaming scenario, not specific to MIP6 bootstrapping scenario. The IETF already defines a similar framework for Mobile IPv4 bootstrapping with having a MN-FA-AAA interface and I don't see a problem in general (in terms of complexity for roaming support) with replacing FA with NAS/DHCP in the case of Mobile IPv6 bootstrapping. > > > > > I don't believe anything needs to be standardized for > > > intra-domain bootstrapping using DHCP except for the format of the > record in > > > DHCP for the MIP6 information, which impacts the MN-DHCP server > interface. > > > In a roaming situation, a home IMSP can indicate during the network > access > > > authentication that the MN should bootstrap off the local DHCP server, > if a > > > local HA, is available through the AAA-H to MN protocol (i.e. end to > end), > > > without having to do anything through the local DHCP server itself. > > > > I agree that this is a simple model. On the other hand, this provides > > a less optimized solution in that the MN might need to execute two EAP > > runs, one EAP for network access authentication (and to get a local HA > > assigned to the MN) and the other EAP over IKEv2 between the MN and > > the HA. Some operators may desire a more optimized solution in which > > AAA for network access and AAA for mobility service are dependent and > > only one EAP needs to be executed. > > > > There need not be two EAP round trips if there is a flag in the EAP reply > from the AAA-H which says that the MN should simply use DHCP to find a local > HA address. The EAP reply configures the IPsec SA, avoiding the need for the > IKEv2 transaction. > > The other alternative is that the AAA-H itself communicates with the AAA-F > to obtain the local HA address, then sends it back in the EAP reply. In that > case, there is an additional round trip on the back end, but, again there > would be no need for the IKEv2 transaction if the EAP is used to configure > the IPsec SA. But both of these would need to push IKE credentials of the MN from the AAA server in the home domain to the local HA in the visited domain, to avoid the second EAP run. On the other hand, if we allow the delivery of IKE credentials to the local HA across administrative domains, I think we can certainly allow the framework of carrying a HA address to the local NAS/DHCP across administrative domains. Regards, Yoshihiro Ohba > > Both of these have been discussed in the context of the draft-giaretta > proposal for using EAP to do bootstrapping. I think you may be confusing > draft-giaretta with draft-chakrabarti-bmip. The latter does propose using > IKEv2, but there the initial EAP transaction for bootstrapping may or may > not use AAA/EAP. > > > jak > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 16:30:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28289 for ; Wed, 16 Feb 2005 16:30:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1X6B-0003Ol-An for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 16:52:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Wd0-0007Ti-OF; Wed, 16 Feb 2005 16:22:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1WZO-0005lt-BS for mip6@megatron.ietf.org; Wed, 16 Feb 2005 16:18:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26935 for ; Wed, 16 Feb 2005 16:18:47 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Wuf-00030y-90 for mip6@ietf.org; Wed, 16 Feb 2005 16:40:52 -0500 Message-ID: <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yoshihiro Ohba" References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Wed, 16 Feb 2005 13:19:42 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Yoshi, > This seems to be a general problem that is common to any roaming > scenario, not specific to MIP6 bootstrapping scenario. The IETF > already defines a similar framework for Mobile IPv4 bootstrapping with > having a MN-FA-AAA interface and I don't see a problem in general (in > terms of complexity for roaming support) with replacing FA with > NAS/DHCP in the case of Mobile IPv6 bootstrapping. > Yes, but configuration is a different problem from network access/mobility auth/authz.. The information distributed by any network access/mobility roaming consists of a yes/no indication about whether someone can enter the network, together with possibly a master key associated with that permission. What your draft is talking about is distributing detailed configuration about the topology and services in the home administrative domain. There is much more that can go wrong in that case. > > The other alternative is that the AAA-H itself communicates with the AAA-F > > to obtain the local HA address, then sends it back in the EAP reply. In that > > case, there is an additional round trip on the back end, but, again there > > would be no need for the IKEv2 transaction if the EAP is used to configure > > the IPsec SA. > > But both of these would need to push IKE credentials of the MN from > the AAA server in the home domain to the local HA in the visited > domain, to avoid the second EAP run. On the other hand, if we allow > the delivery of IKE credentials to the local HA across administrative > domains, I think we can certainly allow the framework of carrying a HA > address to the local NAS/DHCP across administrative domains. > The difference is that the delivery is end to end, between the MN and the AAA-H with EAP. So the security can be end to end, between the home network operator and the client. If the NAS is in the middle, as in your proposal, there is a weak point where compromise of security, or network management problems are more likely to occur. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 16:40:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29295 for ; Wed, 16 Feb 2005 16:40:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1XFS-0003er-VN for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 17:02:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1WmZ-0002yW-21; Wed, 16 Feb 2005 16:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1WkR-0001kM-9N for mip6@megatron.ietf.org; Wed, 16 Feb 2005 16:30:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28252 for ; Wed, 16 Feb 2005 16:30:12 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1X5j-0003NN-Ss for mip6@ietf.org; Wed, 16 Feb 2005 16:52:17 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC000C01X1H3Q@mailout2.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 06:29:41 +0900 (KST) Received: from ep_mmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC000M7LX1GKW@mailout2.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 06:29:40 +0900 (KST) Received: from Alperyegin ([105.253.155.45]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IC0002VXX1DOL@mmp2.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 06:29:40 +0900 (KST) Date: Wed, 16 Feb 2005 13:29:35 -0800 From: Alper Yegin Subject: RE: MIP6-AAA Fwk 2 (was RE: [Mip6] mip6-aaa frameworks) In-reply-to: <051701c51457$e83031b0$016115ac@dcml.docomolabsusa.com> To: "'James Kempf'" , mip6@ietf.org Message-id: <19eb01c5146e$9ea1f760$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT > > > Presumably an NAI but is > > > that > > > separate or combined with DHCP? This is a big change in the basic IETF > > > DHCP > > > architecture, IMHO. Managing DHCP configuration information within an > > > operator's domain is difficult enough. > > > > I don't see that. Please see newly issued RFC 4014. Or, > > Framed-IP-address attribute as defined in RFC 2865. > > > > Ok, but this is not for inter-domain transfer of configuration information > AFIKT. In this case, RADIUS runs inter-domain, DHCP intra-domain. Is there a specific protocol limitation or explicit recommendation against this usage? Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 16:56:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01244 for ; Wed, 16 Feb 2005 16:56:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1XUx-0004Aw-3A for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 17:18:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1WzW-0007ux-NH; Wed, 16 Feb 2005 16:45:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Wup-00063D-Sr for mip6@megatron.ietf.org; Wed, 16 Feb 2005 16:40:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29348 for ; Wed, 16 Feb 2005 16:40:57 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1XG9-0003g1-6o for mip6@ietf.org; Wed, 16 Feb 2005 17:03:02 -0500 Message-ID: <063401c51470$58f1a010$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alper Yegin" , References: <19eb01c5146e$9ea1f760$291d9069@sisa.samsung.com> Subject: Re: MIP6-AAA Fwk 2 (was RE: [Mip6] mip6-aaa frameworks) Date: Wed, 16 Feb 2005 13:41:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit > > Ok, but this is not for inter-domain transfer of configuration > information > > AFIKT. > > In this case, RADIUS runs inter-domain, DHCP intra-domain. Is there a > specific protocol limitation or explicit recommendation against this > usage? > No, but I don't see anything in this draft or any other about running RADIUS interdomain with configuration to then be distributed intradomain by DHCP. Are you aware of any such draft, other than those being discussed on this list in the context of MIP6 bootstrapping? jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 16:57:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01340 for ; Wed, 16 Feb 2005 16:57:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1XVi-0004Cf-SF for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 17:19:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1X5L-0001US-PM; Wed, 16 Feb 2005 16:51:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1WwB-0006ZH-4T for mip6@megatron.ietf.org; Wed, 16 Feb 2005 16:42:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29491 for ; Wed, 16 Feb 2005 16:42:20 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1XHU-0003i7-Eo for mip6@ietf.org; Wed, 16 Feb 2005 17:04:25 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC000M01XLQ1O@mailout3.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 06:41:50 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC0005MYXLPCI@mailout3.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 06:41:49 +0900 (KST) Received: from Alperyegin ([105.253.155.45]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IC000222XLMMD@mmp1.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 06:41:49 +0900 (KST) Date: Wed, 16 Feb 2005 13:41:44 -0800 From: Alper Yegin Subject: RE: MIP6-AAA Fwk 3 (was RE: [Mip6] mip6-aaa frameworks) In-reply-to: <004601c5144d$1c5866c0$861167c0@adithya> To: "'Mohan Parthasarathy'" , mip6@ietf.org Message-id: <19f101c51470$5113ec40$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7BIT > > - AAA_home server must decapsulate the BU and forward it to the HA. What > > is the source address in BU packets? (may be a ingress-filtering > > concern). > > - The BUack from the HA: is it sent back to MN directly, or forwarded to > > AAA_home and piggybacked in the AAA response to MN? > > These two steps are part of Diameter Mobile IPv4 application today and > don't > know how to asses their complexity. True. Though that does not mean we shall do the same with MIP6. And, not everyone is happy about the associated complexity. > And you need this as part of option 4 > also. You mean for "framework 4"? That's not the case. The flow is different: MN<---->HA<--->AAA, vs. MN<---->AAA<---->HA > > > - The results of mobility management and access authorization may need > > to be coordinated? What happens when one succeeds and other fails? > > - What is the transport for BU? EAP, or EAP lower layers, PPP+RADIUS, ? > > > You mean the transport on the access link (between MN and access router). > Yes, that needs to be decided. No, I mean from MN all the way to HA. > > > I don't claim these are impossible to answer, but clearly each answer > > would lead to additional complexity. > > > My concern is on how we assess that something is complex :-) I'm glad I didn't call this "complex", otherwise I'd had to answer your question :-) I identified these as additional complexity. The hard question is, how much additional complexity is justified before we give up on standardizing a mechanism. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 18:19:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10185 for ; Wed, 16 Feb 2005 18:19:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YnD-0006ad-9D for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 18:41:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1YFe-0007yC-MJ; Wed, 16 Feb 2005 18:06:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1YCG-0005gt-5M for mip6@megatron.ietf.org; Wed, 16 Feb 2005 18:03:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07663 for ; Wed, 16 Feb 2005 18:03:00 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YXZ-00067f-OV for mip6@ietf.org; Wed, 16 Feb 2005 18:25:07 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC100M011C6J9@mailout1.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 08:02:30 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC100EYU1C5RF@mailout1.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 08:02:30 +0900 (KST) Received: from Alperyegin ([105.253.155.5]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IC100EOR1C3EJ@mmp2.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 08:02:29 +0900 (KST) Date: Wed, 16 Feb 2005 15:02:24 -0800 From: Alper Yegin Subject: RE: MIP6-AAA Fwk 2 (was RE: [Mip6] mip6-aaa frameworks) In-reply-to: <063401c51470$58f1a010$016115ac@dcml.docomolabsusa.com> To: "'James Kempf'" , mip6@ietf.org Message-id: <1a0501c5147b$958cc210$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT > > > Ok, but this is not for inter-domain transfer of configuration > > information > > > AFIKT. > > > > In this case, RADIUS runs inter-domain, DHCP intra-domain. Is there a > > specific protocol limitation or explicit recommendation against this > > usage? > > > > No, but I don't see anything in this draft or any other about running > RADIUS > interdomain with configuration to then be distributed intradomain by DHCP. > Are you aware of any such draft, other than those being discussed on this > list in the context of MIP6 bootstrapping? Luckily, yes: http://ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt I said luckily, because this is not a protocol issue but an architecture/systems issue which may not be commonly captured in I-Ds. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 18:28:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11086 for ; Wed, 16 Feb 2005 18:28:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Yw4-0006pX-3E for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 18:50:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1YWq-0006Gc-0G; Wed, 16 Feb 2005 18:24:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1YRi-0003sZ-1o for mip6@megatron.ietf.org; Wed, 16 Feb 2005 18:19:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10166 for ; Wed, 16 Feb 2005 18:18:58 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Yn2-0006aQ-59 for mip6@ietf.org; Wed, 16 Feb 2005 18:41:05 -0500 Message-ID: <066b01c5147e$09f03860$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alper Yegin" , References: <1a0501c5147b$958cc210$291d9069@sisa.samsung.com> Subject: Re: MIP6-AAA Fwk 2 (was RE: [Mip6] mip6-aaa frameworks) Date: Wed, 16 Feb 2005 15:19:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit > Luckily, yes: > http://ietf.org/internet-drafts/draft-droms-dhc-v6-relayopt-00.txt > > I said luckily, because this is not a protocol issue but an > architecture/systems issue which may not be commonly captured in I-Ds. > Yes, it is an architecture issue. >From a quick glance at this draft, it looks like an attempt to support the 3GPP2 architecture. As I've argued elsewhere on this list, I am not convinced that this architecture is such a good idea for IP networks in general, and thus that it is suitable for an Internet standard. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 19:04:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15326 for ; Wed, 16 Feb 2005 19:04:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ZUu-0007zd-Jh for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 19:26:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Z1R-0002yO-LU; Wed, 16 Feb 2005 18:55:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Yye-0001Mo-IE for mip6@megatron.ietf.org; Wed, 16 Feb 2005 18:53:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13835 for ; Wed, 16 Feb 2005 18:53:00 -0500 (EST) Received: from smtp809.mail.sc5.yahoo.com ([66.163.168.188]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1ZJv-0007bi-GP for mip6@ietf.org; Wed, 16 Feb 2005 19:15:08 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp809.mail.sc5.yahoo.com with SMTP; 16 Feb 2005 23:52:53 -0000 Message-ID: <014d01c51482$a00b3440$861167c0@adithya> From: "Mohan Parthasarathy" To: "Alper Yegin" , References: <19f101c51470$5113ec40$291d9069@sisa.samsung.com> Subject: Re: MIP6-AAA Fwk 3 (was RE: [Mip6] mip6-aaa frameworks) Date: Wed, 16 Feb 2005 15:52:50 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit > > > - AAA_home server must decapsulate the BU and forward it to the HA. > What > > > is the source address in BU packets? (may be a ingress-filtering > > > concern). > > > - The BUack from the HA: is it sent back to MN directly, or > forwarded to > > > AAA_home and piggybacked in the AAA response to MN? > > > > These two steps are part of Diameter Mobile IPv4 application today and > > don't > > know how to asses their complexity. > > True. Though that does not mean we shall do the same with MIP6. And, not > everyone is happy about the associated complexity. > Sure, we don't have to repeat. But this is based on the assumption/reality that something is complex. > > And you need this as part of option 4 > > also. > > You mean for "framework 4"? That's not the case. The flow is different: > MN<---->HA<--->AAA, vs. MN<---->AAA<---->HA > > Ok, agreed that HA-AAA might be simpler than AAA-HA interaction. > > > - The results of mobility management and access authorization may > need > > > to be coordinated? What happens when one succeeds and other fails? > > > - What is the transport for BU? EAP, or EAP lower layers, > PPP+RADIUS, ? > > > > > You mean the transport on the access link (between MN and access > router). > > Yes, that needs to be decided. > > No, I mean from MN all the way to HA. > Hmm, you already have RADIUS or DIAMETER between the NAS and AAA. Hence, we just have to decide between EAP or EAP lower layer for the first hop i guess. > > > > > > I don't claim these are impossible to answer, but clearly each > answer > > > would lead to additional complexity. > > > > > My concern is on how we assess that something is complex :-) > > I'm glad I didn't call this "complex", otherwise I'd had to answer your > question :-) I identified these as additional complexity. The hard > question is, how much additional complexity is justified before we give > up on standardizing a mechanism. > Ok. -mohan > Alper > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 19:24:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17350 for ; Wed, 16 Feb 2005 19:24:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Zoq-0000Aq-Jd for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 19:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ZPM-00042K-Tm; Wed, 16 Feb 2005 19:20:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ZNp-0003LJ-SJ for mip6@megatron.ietf.org; Wed, 16 Feb 2005 19:19:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16927 for ; Wed, 16 Feb 2005 19:19:02 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ZjA-0008S1-IW for mip6@ietf.org; Wed, 16 Feb 2005 19:41:10 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 09:19:18 +0900 Message-ID: <000c01c51486$3e8a4770$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: "Julien Bournelle" , "Tschofenig Hannes" References: <20050216153429.GQ11112@ipv6-3.int-evry.fr> Subject: Re: [Mip6] mip6-aaa frameworks Date: Thu, 17 Feb 2005 09:18:45 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 17 Feb 2005 00:19:18.0495 (UTC) FILETIME=[52110EF0:01C51486] X-Spam-Score: 2.2 (++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Alper Yegin , "'Julien Bournelle'" , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1143862034==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe --===============1143862034== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGkgSnVsaWVuLg0KUGxlYXNlIHNlZSBteSBjb21tZW50cyBhdCB0aGUgZW5kLg0KDQotLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkp1bGllbiBCb3VybmVsbGUiIDxqdWxpZW4u Ym91cm5lbGxlQGludC1ldnJ5LmZyPg0KVG86ICJUc2Nob2ZlbmlnIEhhbm5lcyIgPGhhbm5lcy50 c2Nob2ZlbmlnQHNpZW1lbnMuY29tPg0KQ2M6ICJBbHBlciBZZWdpbiIgPGFscGVyLnllZ2luQHNh bXN1bmcuY29tPjsgIidKdWxpZW4gQm91cm5lbGxlJyIgPGp1bGllbi5ib3VybmVsbGVAaW50LWV2 cnkuZnI+OyA8bWlwNkBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNywgMjAw NSAxMjozNCBBTQ0KU3ViamVjdDogUmU6IFtNaXA2XSBtaXA2LWFhYSBmcmFtZXdvcmtzDQoNCg0K PiANCj4gaGkgaGFubmVzLA0KPiANCj4gT24gV2VkLCBGZWIgMTYsIDIwMDUgYXQgMDE6NTM6NTJQ TSArMDEwMCwgVHNjaG9mZW5pZyBIYW5uZXMgd3JvdGU6DQo+ID4gDQo+ID4gaSB0aGluayB0aGF0 IGZyYW1ld29yayAxIGFuZCAyIGRvIG5vdCBzcGxpdCB0aGUgZGVzaWduIHNwYWNlIHBhcnRpY3Vs YXJseQ0KPiA+IHdlbGwuIGRyYWZ0LWNob3dkaHVyeS1taXA2LWJvb3RzdHJhcC1yYWRpdXMtMDAg YW5kDQo+ID4gZHJhZnQtbGUtYWFhLW1pcHY2LXJlcXVpcmVtZW50cy0wMy50eHQgaGF2ZSBhIGZl dyB0aGluZ3MgaW4gY29tbW9uLiANCj4gDQo+IHRoZXkgc3BsaXQgdGhlICJBQUEiIGFwcHJvYWNo LiANCj4gDQo+ID4gaSBwZXJzb25hbGx5IHdvdWxkIGxpa2UgdG8gc2VlIGEgc29sdXRpb24gdGhh dCBkb2VzIG5vdCBkZXBlbmQgb24gcHJvdG9jb2xzDQo+ID4gdGhhdCBkbyBub3QgbmVjZXNzYXJ5 IGhhdmUgdG8gZGVhbCB3aXRoIHRoZSBib290c3RyYXBwaW5nIHByb2NlZHVyZSBpdHNlbGYuIA0K PiA+IA0KPiA+IGZvciBleGFtcGxlLCB3aGF0IHByb3RvY29scyBkbyB5b3UgdXNlIHRvIHByb3Zp ZGUgdGhlIGJvb3RzdHJhcHBpbmcNCj4gPiBwYXJhbWV0ZXJzIHRvIHRoZSBlbmQgaG9zdCBhbmQg aG93IG1hbnkgYWRtaW5pc3RyYXRpdmUgZG9tYWlucyBkbyB0aGV5DQo+ID4gdHJhdmVyc2UuIHdo ZW4geW91IHJ1biBhIGJvb3RzdHJhcHBpbmcgcHJvY2VkdXJlIGZvciBtaXA2IChvciBmb3Igb3Ro ZXINCj4gPiBwcm90b2NvbHMgYXMgd2VsbCkgdGhlbiB3aHkgZG8geW91IG5lZWQgdG8gZGVwZW5k IG9uIHNvbWUgaW5mcmFzdHJ1Y3R1cmUgaW4NCj4gPiB0aGUgdmlzaXRlZCBuZXR3b3JrIChwYXJ0 aWN1bGFybHkgd2hlbiB3YW50IHNvbWV0aGluZyBmcm9tIHRoZSBob21lDQo+ID4gbmV0d29yayk/ IA0KPiANCj4gdGhlIGlkZWEgaXMgbm90IHRvIGRlcGVuZCBvbiBzb21lIGluZnJhc3RydWN0dXJl LiBUaGUgIkFBQSIgaWRlYSBpcyB0aGF0DQo+IHdlIGNvdWxkIGhhdmUgdGhpcyBpbmZyYXN0cnVj dHVyZSBhdmFpbGFibGUgYW5kIHRoYXQgaW4gdGhpcyBjYXNlIGl0IGNhbg0KPiBiZSBpbnRlcmVz dGluZyB0byBjb3VwbGUgaXQgd2l0aCB0aGUgYm9vdHN0cmFwcGluZyBwcm9jZWR1cmUgZm9yDQo+ IGF1dGhvcml6YXRpb24gYW5kIGFjY291bnRpbmcgcHVycG9zZS4gDQo+IA0KPiBob3dldmVyLCB3 ZSBjYW4ndCBhc3N1bWUgdGhhdCB3ZSBhbHdheXMgaGF2ZSBhIEFBQSBzeXN0ZW0uIEluIHRoaXMg Y2FzZSwNCj4gd2UgbmVlZCBmcmFtZXdvcmsgNCAob3Igc29tZXRoaW5nIGVsc2UpLiBEb2VzIHRo aXMgaW1wbHkgdGhhdCB3ZSBzaG91bGQgcmVqZWN0DQo+IGZyYW13b3JrIDEtMiA/DQoNCkFzIGkg a25vdywgZXZlbiBmcmFtZXdvcmsgNCwgdGhlcmUgaXMgYSBBQUEgaG9tZSBzZXJ2ZXIgaW4gdGhl IE1OJ3MgaG9tZSBuZXR3b3JrLg0KSSB0aGluayBpbiB0aGlzIGNhc2UsIHRoZXJlIGlzIG5vIEFB QSBzZXJ2ZXIgaW4gdGhlIGxvY2FsLS12aXNpdGVkIGRvbWFpbiBvZiB0aGUgTU4uDQpTbywgbm8g QVNQIGFuZCBvbmx5IHdpdGggTVNQLg0KSSBwZXJzb25hbGx5IHdhbnQgYSBBQUEgaG9tZSBzZXJ2 ZXIgaW5mcmFzdHJ1Y3R1cmUgd2hpY2ggY2FuIHN1cHBvcnQgTUlQNiBib290ZHN0cmFwcGluZw0K dHJhbnBhcmVudGx5IHdoZXRoZXIgdGhlIEFTUCBvciBJQVNQIGlzIGRlcGxveWVkLg0KDQpJIGRv bid0IHRoaW5rIHRoYXQgbmVlZCBvZiBmcmFtZXdvcmsgNCBjYW4gbm90IHJlamVjdCBmcmFtZXdv cmsgMS0yLg0KDQpKdW5naG9vbi4NCg0KPiAtLSANCj4ganVsaWVuLmJvdXJuZWxsZUBpbnQtZXZy eS5mcg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gTWlwNiBtYWlsaW5nIGxpc3QNCj4gTWlwNkBpZXRmLm9yZw0KPiBodHRwczovL3d3dzEu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9taXA2 --===============1143862034== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1143862034==-- From mip6-bounces@ietf.org Wed Feb 16 19:59:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20531 for ; Wed, 16 Feb 2005 19:59:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1aMd-00014v-7i for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 20:21:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Zzi-0002Wl-PM; Wed, 16 Feb 2005 19:58:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Zun-0000c4-7U for mip6@megatron.ietf.org; Wed, 16 Feb 2005 19:53:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19829 for ; Wed, 16 Feb 2005 19:53:05 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1aG9-0000ra-3R for mip6@ietf.org; Wed, 16 Feb 2005 20:15:13 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 09:53:23 +0900 Message-ID: <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: "Erik Nordmark" References: <004401c51409$928b96d0$6b70fe81@FlyToWorld> <421393C7.8000704@sun.com> Subject: Re: [Mip6] mip6-aaa frameworks Date: Thu, 17 Feb 2005 09:52:50 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 17 Feb 2005 00:53:23.0666 (UTC) FILETIME=[15156320:01C5148B] X-Spam-Score: 2.2 (++) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Gerardo Giaretta , Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0101176229==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d --===============0101176229== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gRXJpaywNClBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLg0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkVyaWsgTm9yZG1hcmsiIDxlcmlrLm5vcmRtYXJr QHN1bi5jb20+DQpUbzogIkp1bmdob29uIEplZSIgPGpoamVlQGV0cmkucmUua3I+DQpDYzogIkdl cmFyZG8gR2lhcmV0dGEiIDxHZXJhcmRvLkdpYXJldHRhQFRJTEFCLkNPTT47ICJBbHBlciBZZWdp biIgPGFscGVyLnllZ2luQHNhbXN1bmcuY29tPjsgPG1pcDZAaWV0Zi5vcmc+DQpTZW50OiBUaHVy c2RheSwgRmVicnVhcnkgMTcsIDIwMDUgMzo0MSBBTQ0KU3ViamVjdDogUmU6IFtNaXA2XSBtaXA2 LWFhYSBmcmFtZXdvcmtzDQoNCg0KPiANCj4gSnVuZ2hvb24gSmVlIHdyb3RlOg0KPiANCj4gPiBU aGUgZHluYW1pYyBIQSBkaXNjb3ZlcnkgaXMgc3RpbGwgYW4gaXNzdWUuDQo+ID4gV2l0aCBteSBt aW5kLCBhZGRpbmcgc2VjdXJpdHkgbWVjaGFuaXNtIHRvIHRoZSBwcmUtZXhpc3RpbmcgRE5TIHF1 ZXJ5IG1heSBiZSBhIGJ1cmRlbi4gDQo+IA0KPiBUaGUgbmVlZCBmb3IgY29uZmlkZW50aWFsaXR5 IG9mIHRoZSBIQXMgSVAgYWRkcmVzcyBpcyBoYXJkIGZvciBtZSB0byANCj4gdW5kZXJzdGFuZCB3 aXRob3V0IHVuZGVyc3RhbmRpbmcgdGhlIHRocmVhdCBtb2RlbC4NCg0KQ3VycmVudGx5LCBteSBj b25jZXJuIGlzIGFib3V0IHRoZSBpbnRlZ3JpdHkgYW5kIHJlcGxheSBwcm90ZWN0aW9uIGZvciBI QSBJUCBhZGRyZXNzLg0KQ291bGQgd2Ugc3VwcG9ydCB0aGlzIHdpdGhvdXQgcmVxdWlyaW5nIHRo ZSBzZWN1cml0eSBmdW5jdGlvbiBpbiB0aGUgcHJlLWV4aXN0aW5nIEROUyBzZXJ2ZXJzID8NCk15 IGFuc3dlciBpcyBOTy4NCklmIG15IGFuc3dlciBpcyBjb3JyZWN0LCBwcmUtZXhpc3RpbmcgRE5T IHNlcnZlcnMgbmVlZHMgdG8gYmUgY2hhbmdlZCB0byBzdXBwb3J0IE1JUDYgYm9vdHN0cmFwcGlu Zy4NCkkgYW0gbm90IHN1cmUgd2hldGhlcmUgdGhpcyBhcHByb2FjaCBpcyByaWdodC4NCg0KQlRX LCBpIGRvbid0IGFncmVlIHRvIG9wZW4gdXAgdGhlIGNoYW5jZSBvZiAgcmV2ZWFsaW5nIHRoZSBI QSBJUCBhZGRyZXNzIGJ5IHB1dHRpbmcgdGhpcyBpbmZvcm1hdGlvbg0KaW50byB0aGUgcHVibGlj bHkgYXZhaWxhYmxlIEROUyBzZXJ2ZXIuIEFueW9uZSBjYW4gcXVlcnkgdGhlIEROUyBzZXJ2ZXIg dG8gZ2V0IGFueSBvdGhlcidzIEhBIGFkZHJlc3MuDQpUaGlzIGluY3JlYXNlIHRoZSBwb3NzaWJp bGl0eSBvZiBEb1MgYXR0YWNrLiBJIGtub3cgdGhhdCB0aGlzIHBvaW50IGlzIGFscmVhZHkgbWVu dGlvbmVkIGluIHRoZSBibWlwNiBkcmFmdC4NCkkgYW0gd2FpdGluZyB0aGVpciByaWdodCBzb2x1 dGlvbiBmb3IgdGhpcy4NCg0KSSBob3BlIHdlIGRvbid0IGRyYXcgYmFjayB0aGUgZHluYW1pYyBI QSBhc3NpZ25tZW50IGR1cmluZyBNSVA2IGJvb3RzdHJhc3BwaW5nIGJlY2F1c2Ugd2UgY2FuIG5v dCBmaW5kIHJpZ2h0IHdheSB0byB0byB0aGlzLg0KQW55IGdvb2QgaWRlYSA/DQoNCj4gU3VwcG9z ZSB0aGVyZSBpcyBwZXJmZWN0IGNvbmZpZGVudGlhbGl0eS4gQW4gYXR0YWNrZXIgd2FudHMgdG8g YXR0YWNrIA0KPiB0aGUgSEEsIGFuZCB0aGUgYXR0YWNrZXIgY29udHJvbHMgYSBsYXJnZSBudW1i ZXIgb2Ygem9tYmllcyBmb3IgRERvUyANCj4gYXR0YWNrLiBJdCBpcyBzdWZmaWNpZW50IGZvciBz b21lYm9keSwgd2hvIGhhcyBwYWlkICQxMCBmb3IgYSBtb250aCBvciANCj4gYW4gaG91ciBvZiBz ZXJ2aWNlLCB0byBkaXNjbG9zZSB0aGUgSEEncyBJUCBhZGRyZXNzIHRvIHRoZSBhdHRhY2tlciwg YW5kIA0KPiB0aGVuIHRoZSBERG9TIGF0dGFjayBjYW4gYmUgbGF1bmNoZWQgdG93YXJkcyB0aGF0 IElQIGFkZHJlc3MuDQo+IEFuZCBmb3IgYSBsYXJnZSBvcGVyYXRvciwgdGhlIHByb2JhYmlsaXR5 IHRoYXQgb25lIG9mIHRoZWlyIGxlZ2l0aW1hdGUgDQo+IHN1YnNjcmliZXJzIGlzIGluZmVjdGVk IHdpdGggYSB6b21iaWUsIGlzIHF1aXRlIGhpZ2ggd2hlbiBQQ3MgbWlnaHQgYmUgDQo+IHRoZSBN Ti4gU3VjaCBhIHpvbWJpZSBjb3VsZCB0aGVuIHNoYXJlIHRoZSBJUCBhZGRyZXNzIHdpdGggdGhl IGF0dGFja2VyLg0KDQpBYm91dCB0aGUgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gYWJvdXQg SEEgYWRkcmVzcywNCkkgdGFsa2VkIHdpdGggSmFtZSB0aHJvdWdoIHRoaXMgbWFpbGluZyBiZWZv cmUuDQpXaXRoIG15IG1pbmQsIHNlY3VyaXR5IGlzc3VlIHRoYXQgY2FuIGJlIHRvdWNoZWQgYnkg dGhlIG1vYmlsdHkgcHJvdG9jb2wgDQpzaG91bGQgYmUgY29uZmluZWQgdG8gdGhlIGlzc3VlcyB0 aGF0IGFyZSByYWlzZWQgYnkgdGhlIG1vYmlsaXR5IHByb3RvY29sIGl0c2VsZi4NClN5c3RlbSBz ZWN1cml0eSBpc3N1ZXMgbGlrZSBoYWNraW5nIG9mIGxvY2FsIHN5c3RlbSdzIGNyaXRpY2FsIGlu Zm9ybWF0aW9uIG9yDQppbGwtaW50ZW5kZWQgaW5zaWRlIGF0dGFja2VycyBhcmUgb3V0IG9mIHNj b3BlIHdoZW4gY29uc2lkcmluZyB0aGUgTUlQNiBzZWN1cml0eS4NCg0KTXkgcG9pbnQgaXMgdGhh dCwNCldoZW4gd2UgY3JlYXRlIGEgYm9vdHJhcHBpbmcgZnJhbWV3b3JrIGFuZCBzb2x1dGlvbiwN CndlIG5lZWQgdG8gY2FyZWZ1bGx5IGRlc2lnbiB0aGlzIG5vdCB0byByYWlzZSBuZXcgcG9zc2li bGUgYXR0YWNrcy4NCkkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGVyZSBpcyBubyBwZXJmZWN0IHNl Y3VydHkuDQpCdXQgdGhpcyBmZWF0dXJlIGNhbiBub3QgYmUgbWlzLXVuZGVyc3Rvb2QgdGhhdCB3 ZSBkb24ndCBuZWVkIHRvIHRoaW5rDQphYm91dCB0aGUgc2VjdXJpdHkgaXNzdWVzIHRoYXQgYXJl IHJhaXNlZCBieSBhZG9wdGluZyBhIG5ldyBwcm90b2NvbCBvciBzb2x1dGlvbi4NCg0KLS1KdW5n aG9vbg0KDQoNCj4gVGhlIHVwc2hvdCBpcyB0aGF0IEkgZG9uJ3QgdGhpbmsgdGhlIHN1YnNjcmli ZXJzIGNhbiBiZSB0cnVzdGVkIHRvIG5vdCANCj4gc2hhcmUgdGhlIEhBJ3MgSVAgYWRkcmVzcywg ZWl0aGVyIGludGVudGlvbmFsbHkgb3IgdW53aXR0aW5nbHkuDQo+IA0KPiAgICAgRXJpaw== --===============0101176229== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0101176229==-- From mip6-bounces@ietf.org Wed Feb 16 20:47:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24360 for ; Wed, 16 Feb 2005 20:47:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1b6h-00029p-0P for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 21:09:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ajY-0001Th-66; Wed, 16 Feb 2005 20:45:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1aXu-0006JE-6l for mip6@megatron.ietf.org; Wed, 16 Feb 2005 20:33:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23370 for ; Wed, 16 Feb 2005 20:33:32 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1atG-0001rw-Eg for mip6@ietf.org; Wed, 16 Feb 2005 20:55:39 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1H22wh10265; Wed, 16 Feb 2005 18:02:58 -0800 X-mProtect: <200502170202> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdPiIcdP; Wed, 16 Feb 2005 18:02:48 PST Message-ID: <4213F429.9060705@iprg.nokia.com> Date: Wed, 16 Feb 2005 17:32:25 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] mip6-aaa frameworks References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> <02e601c51389$21dd84a0$016115ac@dcml.docomolabsusa.com> In-Reply-To: <02e601c51389$21dd84a0$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit James Kempf wrote: >>Framework 2: >>------------ >>Using network access AAA to deliver MIP6 configuration parameters from >>the AAA server to the NAS. It is assumed that parameters will be >>delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, >>etc.) >> >>Related I-Ds: >> >>draft-chowdhury-mip6-bootstrap-radius-00 >>draft-jang-dhc-haopt-00 >> >>Discussion: >> >>This is similar to NAS learning the IP address for the connected host >>via RADIUS, and delivering it to the host via DHCP. >> >>James had a comment regarding not having to support intra-operator >>interoperability. I think regardless of the deployment, interoperability >>between vendors is the important. Also, I was not sure on the complexity >>argument. >> > > > Consider the following. Suppose RADIUS is used to transfer operator A's HA > addresses from operator A's AAA server to operator B's NAS. First question > is whether the addresses are delivered every time a roamed host makes a DHCP > request for the HA address? If not and there is any caching going on, then > the addresses could get stale. Second question is how the NAS differentiates > which home operator to ask for the addresses? Presumably an NAI but is that > separate or combined with DHCP? This is a big change in the basic IETF DHCP > architecture, IMHO. Managing DHCP configuration information within an > operator's domain is difficult enough. > > >>3GPP2 has already chosen this scheme. Some other SDO(s) may follow the >>suit. >> > > > Can someone provide more details here? As far as I know, in the current > 3GPP2 MIP4 system, the PDSN is both home and foreign agent (please correct > if this is wrong), 3GPP2 uses different mechanisms for MIPv4 and MIPv6. for MIPv6, there is no foreign agent. the PDSN is just a NAS. the Home Agent is in the Operator's home link. > so I don't see how DHCP would come into the picture. How > are they planning on changing that for MIP6? Are they really planning on > distributing the addresses of home agents between operators or just within a > single operator? both. at the end of access network authentication, the HA address is delivered to the PDSN (which is a NAS). the PDSN then sends the HA address to the MN via DHCP. works pretty well and I happen to think that this is a good bootstrap mechanism. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 20:55:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24870 for ; Wed, 16 Feb 2005 20:55:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1bEM-0002KK-KT for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 21:17:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1apx-0003xc-RJ; Wed, 16 Feb 2005 20:52:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1amU-0002eH-1Q for mip6@megatron.ietf.org; Wed, 16 Feb 2005 20:48:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24426 for ; Wed, 16 Feb 2005 20:48:35 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1b7q-0002BO-FK for mip6@ietf.org; Wed, 16 Feb 2005 21:10:42 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1H2IDS17206; Wed, 16 Feb 2005 18:18:13 -0800 X-mProtect: <200502170218> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdVQlLbN; Wed, 16 Feb 2005 18:18:10 PST Message-ID: <4213F7C4.8010704@iprg.nokia.com> Date: Wed, 16 Feb 2005 17:47:48 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alper Yegin Subject: Re: [Mip6] mip6-aaa frameworks References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> In-Reply-To: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Content-Transfer-Encoding: 7bit this classification is very confusing to me. we are dealing with three problems here. 1. Access network authentication 2. bootstrapping 3. MN authenticating to the Home Agent using its NAI/FQDN. for 3), it is simple. we need to standardize the interface between the HA and the AAAH ASAP. we need both RADIUS attributes and DIAMETER AVPs for this. this should be decoupled from the other two problems. draft-ietf-mip6-ikev2-ipsec-02.txt already defines how to run IKEv2 with EAP once the MN knows the HA's address. for 2), we need to standardize *a* solution. this could use/or not use AAA. but I dont believe we can develop a solution that will be valid in all deployments. for example, I think the mechanism used in 3GPP2 is quite okay for 3GPP2 networks. for 1), again, I think it is specific to the deployment. but doesnt hurt standardizing one solution in the IETF. ofcourse, you can develop a solution based on AAA that can solve all three problems. (I guess draft-le... does that). but the single solution might not work in all deployments. and we have to evaluate the complexity involved. my 2 cents. Vijay Alper Yegin wrote: > This is an attempt to enumerate possible MIP6-AAA frameworks, and start > discussions on for which one(s) IETF shall pursue standardization. > > Framework 1: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the MN. > > MIP6 configuration is directly delivered from the AAA server to the MN > during network access AAA, in-band with the authentication (e.g., > transported by EAP or EAP methods). > > Related I-Ds: > > draft-giaretta-mip6-authorization-eap-01 > draft-le-aaa-mipv6-requirements-03 > draft-ohnishi-mip6-aaa-problem-statement-00 > > Discussion: > > The end2end transport between the AAA and the MN is the key. Use of EAP > for this somewhat network access unrelated "configuration" is not > recommended as far as I understand. One can design his own EAP method to > do that, yet that would have limited applicability. > > > Framework 2: > ------------ > Using network access AAA to deliver MIP6 configuration parameters from > the AAA server to the NAS. It is assumed that parameters will be > delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, > etc.) > > Related I-Ds: > > draft-chowdhury-mip6-bootstrap-radius-00 > draft-jang-dhc-haopt-00 > > Discussion: > > This is similar to NAS learning the IP address for the connected host > via RADIUS, and delivering it to the host via DHCP. > > James had a comment regarding not having to support intra-operator > interoperability. I think regardless of the deployment, interoperability > between vendors is the important. Also, I was not sure on the complexity > argument. > > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the > suit. > > Framework 3: > ------------ > Piggybacking MIP6 signaling (BU) with network access AAA. In-band with > the network access authentication execution, the MN delivers > (piggybacks) a BU to the AAA server. The AAA server may have to relay > the BU to the HA (unless collocated). > > Related I-D: > > draft-le-aaa-mipv6-requirements-03 > > Discussion: > > While the performance benefits are clear, limited applicability (not > always the network access and mobility services are bundled) and > complexity are concerning. > > > Framework 4: > ------------ > A backend AAA protocol is executed between the HA and the AAA server in > response to the MIP6 signaling between the MN and the HA. Similar to the > use of AAA protocols with MIPv4 co-located care-of address case. > > Related I-Ds: > > draft-giaretta-mip6-aaa-ha-goals-00.txt > draft-yegin-mip6-aaa-fwk-00.txt > > Discussion: > This one appears to be the most needed framework. It is assumed that MN > already knows the HA address. > > > Are there other frameworks to add? > > I am sure I have missed some references, please let us know which ones. > > Alper > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 21:31:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27598 for ; Wed, 16 Feb 2005 21:31:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1bnL-00037i-9Q for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 21:53:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1bO5-0007hw-Bw; Wed, 16 Feb 2005 21:27:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1bBL-0003V8-Rc for mip6@megatron.ietf.org; Wed, 16 Feb 2005 21:14:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25857 for ; Wed, 16 Feb 2005 21:14:17 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1bWh-0002ex-Ly for mip6@ietf.org; Wed, 16 Feb 2005 21:36:24 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j1H2E5Hr014366; Thu, 17 Feb 2005 11:14:05 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j1H2E5xO023419; Thu, 17 Feb 2005 11:14:05 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id MAA23414 ; Thu, 17 Feb 2005 11:14:05 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j1H2E4vI000312; Thu, 17 Feb 2005 11:14:05 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1H2E18X018774; Thu, 17 Feb 2005 11:14:01 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1H2E08a008799; Thu, 17 Feb 2005 11:14:00 +0900 (JST) Received: from steelhead (iVPN11-166.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IC1006OMA790J@tsbpo1.po.toshiba.co.jp>; Thu, 17 Feb 2005 11:13:57 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1D1aue-0006ke-00; Wed, 16 Feb 2005 17:57:04 -0800 Date: Wed, 16 Feb 2005 20:57:04 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> To: James Kempf Message-id: <20050217015704.GE25571@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 On Wed, Feb 16, 2005 at 01:19:42PM -0800, James Kempf wrote: > Yoshi, > > > This seems to be a general problem that is common to any roaming > > scenario, not specific to MIP6 bootstrapping scenario. The IETF > > already defines a similar framework for Mobile IPv4 bootstrapping with > > having a MN-FA-AAA interface and I don't see a problem in general (in > > terms of complexity for roaming support) with replacing FA with > > NAS/DHCP in the case of Mobile IPv6 bootstrapping. > > > > Yes, but configuration is a different problem from network access/mobility > auth/authz.. The information distributed by any network access/mobility > roaming consists of a yes/no indication about whether someone can enter the > network, together with possibly a master key associated with that > permission. > > What your draft is talking about is distributing detailed configuration > about the topology and services in the home administrative domain. There is > much more that can go wrong in that case. So do you think that the existing solution for Mobile IPv4 bootstrapping is not a good solution to follow when defining a Mobile IPv6 bootstrapping solution? > > > > > The other alternative is that the AAA-H itself communicates with the > AAA-F > > > to obtain the local HA address, then sends it back in the EAP reply. In > that > > > case, there is an additional round trip on the back end, but, again > there > > > would be no need for the IKEv2 transaction if the EAP is used to > configure > > > the IPsec SA. > > > > But both of these would need to push IKE credentials of the MN from > > the AAA server in the home domain to the local HA in the visited > > domain, to avoid the second EAP run. On the other hand, if we allow > > the delivery of IKE credentials to the local HA across administrative > > domains, I think we can certainly allow the framework of carrying a HA > > address to the local NAS/DHCP across administrative domains. > > > > The difference is that the delivery is end to end, between the MN and the > AAA-H with EAP. So the security can be end to end, between the home network > operator and the client. If the NAS is in the middle, as in your proposal, > there is a weak point where compromise of security, or network management > problems are more likely to occur. I don't understand the security threat because the HA address is somehow exposed to the operator of the visited domain when the MN sends a BU to the HA (I mentioned this several months ago). Also I don't understand the network management problems, because even in the end-to-end delivery model you mentioned above, some information such as IKEv2 credentials would need to be passed to the local HA in the visited domain from the home domain (it's not a pure end-to-end delivery in that sense) in order for the MN to perform IKEv2 with the local HA without running EAP over IKEv2. I really don't see a major difference between managing IKEv2 credentials and managing HA address across administrative domains. Regards, Yoshihiro Ohba > > jak > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 21:58:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00941 for ; Wed, 16 Feb 2005 21:58:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1cDQ-0003sS-OQ for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 22:20:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1bdE-0005Nl-9o; Wed, 16 Feb 2005 21:43:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1bXz-0003H1-95 for mip6@megatron.ietf.org; Wed, 16 Feb 2005 21:37:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28130 for ; Wed, 16 Feb 2005 21:37:40 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1btL-0003En-UE for mip6@ietf.org; Wed, 16 Feb 2005 21:59:48 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1H36mx04517; Wed, 16 Feb 2005 19:06:48 -0800 X-mProtect: <200502170306> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdQ0pAfg; Wed, 16 Feb 2005 19:06:42 PST Message-ID: <42140322.20706@iprg.nokia.com> Date: Wed, 16 Feb 2005 18:36:18 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Junghoon Jee Subject: Re: [Mip6] mip6-aaa frameworks References: <004401c51409$928b96d0$6b70fe81@FlyToWorld> <421393C7.8000704@sun.com> <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> In-Reply-To: <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Alper Yegin , Erik Nordmark , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Junghoon Jee wrote: >>>The dynamic HA discovery is still an issue. >>>With my mind, adding security mechanism to the pre-existing DNS query may be a burden. >> >>The need for confidentiality of the HAs IP address is hard for me to >>understand without understanding the threat model. > > > Currently, my concern is about the integrity and replay protection for HA IP address. > Could we support this without requiring the security function in the pre-existing DNS servers ? > My answer is NO. > If my answer is correct, pre-existing DNS servers needs to be changed to support MIP6 bootstrapping. > I am not sure whethere this approach is right. I have to disagree here. it is like getting any other server's address through DNS. IMHO, the threat model is no different. > BTW, i don't agree to open up the chance of revealing the HA IP address by putting this information > into the publicly available DNS server. Anyone can query the DNS server to get any other's HA address. > This increase the possibility of DoS attack. I know that this point is already mentioned in the bmip6 draft. > I am waiting their right solution for this. this might sound cliched, but you cannot achieve security through obscurity. :) Vijay > > I hope we don't draw back the dynamic HA assignment during MIP6 bootstraspping because we can not find right way to to this. > Any good idea ? > > >>Suppose there is perfect confidentiality. An attacker wants to attack >>the HA, and the attacker controls a large number of zombies for DDoS >>attack. It is sufficient for somebody, who has paid $10 for a month or >>an hour of service, to disclose the HA's IP address to the attacker, and >>then the DDoS attack can be launched towards that IP address. >>And for a large operator, the probability that one of their legitimate >>subscribers is infected with a zombie, is quite high when PCs might be >>the MN. Such a zombie could then share the IP address with the attacker. > > > About the confidentiality protection about HA address, > I talked with Jame through this mailing before. > With my mind, security issue that can be touched by the mobilty protocol > should be confined to the issues that are raised by the mobility protocol itself. > System security issues like hacking of local system's critical information or > ill-intended inside attackers are out of scope when considring the MIP6 security. > > My point is that, > When we create a bootrapping framework and solution, > we need to carefully design this not to raise new possible attacks. > I agree with you that there is no perfect securty. > But this feature can not be mis-understood that we don't need to think > about the security issues that are raised by adopting a new protocol or solution. > > --Junghoon > > > >>The upshot is that I don't think the subscribers can be trusted to not >>share the HA's IP address, either intentionally or unwittingly. >> >> Erik >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Mip6 mailing list >>Mip6@ietf.org >>https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 16 23:18:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA08621 for ; Wed, 16 Feb 2005 23:18:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1dSz-0005ty-Hz for mip6-web-archive@ietf.org; Wed, 16 Feb 2005 23:40:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1d5g-0005HX-Gr; Wed, 16 Feb 2005 23:16:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1csH-0000mo-5f for mip6@megatron.ietf.org; Wed, 16 Feb 2005 23:02:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07509 for ; Wed, 16 Feb 2005 23:02:42 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1dDe-0005YD-CZ for mip6@ietf.org; Wed, 16 Feb 2005 23:24:51 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 13:02:58 +0900 Message-ID: <005101c514a5$7d9fef40$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: "Vijay Devarapalli" References: <004401c51409$928b96d0$6b70fe81@FlyToWorld> <421393C7.8000704@sun.com> <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> <42140322.20706@iprg.nokia.com> Subject: Re: [Mip6] mip6-aaa frameworks Date: Thu, 17 Feb 2005 13:02:25 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 17 Feb 2005 04:02:58.0782 (UTC) FILETIME=[912E57E0:01C514A5] X-Spam-Score: 2.2 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Gerardo Giaretta , Alper Yegin , Erik Nordmark , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1267307344==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --===============1267307344== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gVmlqYXkuDQpQbGVhc2Ugc2VlIG15IGNvbW1lbnRzIGlubGluZS4NCg0KPiBKdW5naG9v biBKZWUgd3JvdGU6DQo+IA0KPiA+Pj5UaGUgZHluYW1pYyBIQSBkaXNjb3ZlcnkgaXMgc3RpbGwg YW4gaXNzdWUuDQo+ID4+PldpdGggbXkgbWluZCwgYWRkaW5nIHNlY3VyaXR5IG1lY2hhbmlzbSB0 byB0aGUgcHJlLWV4aXN0aW5nIEROUyBxdWVyeSBtYXkgYmUgYSBidXJkZW4uIA0KPiA+Pg0KPiA+ PlRoZSBuZWVkIGZvciBjb25maWRlbnRpYWxpdHkgb2YgdGhlIEhBcyBJUCBhZGRyZXNzIGlzIGhh cmQgZm9yIG1lIHRvIA0KPiA+PnVuZGVyc3RhbmQgd2l0aG91dCB1bmRlcnN0YW5kaW5nIHRoZSB0 aHJlYXQgbW9kZWwuDQo+ID4gDQo+ID4gDQo+ID4gQ3VycmVudGx5LCBteSBjb25jZXJuIGlzIGFi b3V0IHRoZSBpbnRlZ3JpdHkgYW5kIHJlcGxheSBwcm90ZWN0aW9uIGZvciBIQSBJUCBhZGRyZXNz Lg0KPiA+IENvdWxkIHdlIHN1cHBvcnQgdGhpcyB3aXRob3V0IHJlcXVpcmluZyB0aGUgc2VjdXJp dHkgZnVuY3Rpb24gaW4gdGhlIHByZS1leGlzdGluZyBETlMgc2VydmVycyA/DQo+ID4gTXkgYW5z d2VyIGlzIE5PLg0KPiA+IElmIG15IGFuc3dlciBpcyBjb3JyZWN0LCBwcmUtZXhpc3RpbmcgRE5T IHNlcnZlcnMgbmVlZHMgdG8gYmUgY2hhbmdlZCB0byBzdXBwb3J0IE1JUDYgYm9vdHN0cmFwcGlu Zy4NCj4gPiBJIGFtIG5vdCBzdXJlIHdoZXRoZXJlIHRoaXMgYXBwcm9hY2ggaXMgcmlnaHQuDQo+ IA0KPiBJIGhhdmUgdG8gZGlzYWdyZWUgaGVyZS4gaXQgaXMgbGlrZSBnZXR0aW5nIGFueSBvdGhl ciBzZXJ2ZXIncyBhZGRyZXNzDQo+IHRocm91Z2ggRE5TLiBJTUhPLCB0aGUgdGhyZWF0IG1vZGVs IGlzIG5vIGRpZmZlcmVudC4NCg0KZHJhZnQtaWV0Zi1ib290c3RyYXAtcHMgcmVxdWlyZXMgdGhl IGludGVncml0eSBhbmQgcmVwbGF5IHByb3RlY3Rpb24gb2YgYm9vdHN0cmFwcGluZyBpbmZvcm1h dGlvbi4NCldoYXQgZG8geW91IHRoaW5rIGFib3V0IHRoaXMgPw0KDQo+ID4gQlRXLCBpIGRvbid0 IGFncmVlIHRvIG9wZW4gdXAgdGhlIGNoYW5jZSBvZiAgcmV2ZWFsaW5nIHRoZSBIQSBJUCBhZGRy ZXNzIGJ5IHB1dHRpbmcgdGhpcyBpbmZvcm1hdGlvbg0KPiA+IGludG8gdGhlIHB1YmxpY2x5IGF2 YWlsYWJsZSBETlMgc2VydmVyLiBBbnlvbmUgY2FuIHF1ZXJ5IHRoZSBETlMgc2VydmVyIHRvIGdl dCBhbnkgb3RoZXIncyBIQSBhZGRyZXNzLg0KPiA+IFRoaXMgaW5jcmVhc2UgdGhlIHBvc3NpYmls aXR5IG9mIERvUyBhdHRhY2suIEkga25vdyB0aGF0IHRoaXMgcG9pbnQgaXMgYWxyZWFkeSBtZW50 aW9uZWQgaW4gdGhlIGJtaXA2IGRyYWZ0Lg0KPiA+IEkgYW0gd2FpdGluZyB0aGVpciByaWdodCBz b2x1dGlvbiBmb3IgdGhpcy4NCj4gDQo+IHRoaXMgbWlnaHQgc291bmQgY2xpY2hlZCwgYnV0IHlv dSBjYW5ub3QgYWNoaWV2ZSBzZWN1cml0eSB0aHJvdWdoDQo+IG9ic2N1cml0eS4gOikNClBsZWFz ZSBsb29rIGF0IHRoZSBBcHBlbmRpeCBBLiBvZiBibWlwIGRyYWZ0Lg0KQ291bGQgeW91IGV4cGxh aW4gd2h5IHlvdSB1c2UgdGhlIHdvcmQgJ2NsaWNoZWQnIGFuZCAnb2JzY3VyaXR5JyB3aXRob3V0 IGFueSBkZXRhaWxlZCBleHBsYW5hdGlvbiA/DQpXb3VsZG4ndCB5b3Ugd2FudCB0byBrZWVwIHRo ZSBiYXNpYyBzdGVwIGJlY2F1c2UgeW91IHRoaW5rIGl0IGlzIGNsaWNoZWQgPw0KDQpKdW5naG9v bg0KDQo+IFZpamF5DQo+IA0KPiA+IA0KPiA+IEkgaG9wZSB3ZSBkb24ndCBkcmF3IGJhY2sgdGhl IGR5bmFtaWMgSEEgYXNzaWdubWVudCBkdXJpbmcgTUlQNiBib290c3RyYXNwcGluZyBiZWNhdXNl IHdlIGNhbiBub3QgZmluZCByaWdodCB3YXkgdG8gdG8gdGhpcy4NCj4gPiBBbnkgZ29vZCBpZGVh ID8NCj4gPiANCj4gPiANCj4gPj5TdXBwb3NlIHRoZXJlIGlzIHBlcmZlY3QgY29uZmlkZW50aWFs aXR5LiBBbiBhdHRhY2tlciB3YW50cyB0byBhdHRhY2sgDQo+ID4+dGhlIEhBLCBhbmQgdGhlIGF0 dGFja2VyIGNvbnRyb2xzIGEgbGFyZ2UgbnVtYmVyIG9mIHpvbWJpZXMgZm9yIEREb1MgDQo+ID4+ YXR0YWNrLiBJdCBpcyBzdWZmaWNpZW50IGZvciBzb21lYm9keSwgd2hvIGhhcyBwYWlkICQxMCBm b3IgYSBtb250aCBvciANCj4gPj5hbiBob3VyIG9mIHNlcnZpY2UsIHRvIGRpc2Nsb3NlIHRoZSBI QSdzIElQIGFkZHJlc3MgdG8gdGhlIGF0dGFja2VyLCBhbmQgDQo+ID4+dGhlbiB0aGUgRERvUyBh dHRhY2sgY2FuIGJlIGxhdW5jaGVkIHRvd2FyZHMgdGhhdCBJUCBhZGRyZXNzLg0KPiA+PkFuZCBm b3IgYSBsYXJnZSBvcGVyYXRvciwgdGhlIHByb2JhYmlsaXR5IHRoYXQgb25lIG9mIHRoZWlyIGxl Z2l0aW1hdGUgDQo+ID4+c3Vic2NyaWJlcnMgaXMgaW5mZWN0ZWQgd2l0aCBhIHpvbWJpZSwgaXMg cXVpdGUgaGlnaCB3aGVuIFBDcyBtaWdodCBiZSANCj4gPj50aGUgTU4uIFN1Y2ggYSB6b21iaWUg Y291bGQgdGhlbiBzaGFyZSB0aGUgSVAgYWRkcmVzcyB3aXRoIHRoZSBhdHRhY2tlci4NCj4gPiAN Cj4gPiANCj4gPiBBYm91dCB0aGUgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gYWJvdXQgSEEg YWRkcmVzcywNCj4gPiBJIHRhbGtlZCB3aXRoIEphbWUgdGhyb3VnaCB0aGlzIG1haWxpbmcgYmVm b3JlLg0KPiA+IFdpdGggbXkgbWluZCwgc2VjdXJpdHkgaXNzdWUgdGhhdCBjYW4gYmUgdG91Y2hl ZCBieSB0aGUgbW9iaWx0eSBwcm90b2NvbCANCj4gPiBzaG91bGQgYmUgY29uZmluZWQgdG8gdGhl IGlzc3VlcyB0aGF0IGFyZSByYWlzZWQgYnkgdGhlIG1vYmlsaXR5IHByb3RvY29sIGl0c2VsZi4N Cj4gPiBTeXN0ZW0gc2VjdXJpdHkgaXNzdWVzIGxpa2UgaGFja2luZyBvZiBsb2NhbCBzeXN0ZW0n cyBjcml0aWNhbCBpbmZvcm1hdGlvbiBvcg0KPiA+IGlsbC1pbnRlbmRlZCBpbnNpZGUgYXR0YWNr ZXJzIGFyZSBvdXQgb2Ygc2NvcGUgd2hlbiBjb25zaWRyaW5nIHRoZSBNSVA2IHNlY3VyaXR5Lg0K PiA+IA0KPiA+IE15IHBvaW50IGlzIHRoYXQsDQo+ID4gV2hlbiB3ZSBjcmVhdGUgYSBib290cmFw cGluZyBmcmFtZXdvcmsgYW5kIHNvbHV0aW9uLA0KPiA+IHdlIG5lZWQgdG8gY2FyZWZ1bGx5IGRl c2lnbiB0aGlzIG5vdCB0byByYWlzZSBuZXcgcG9zc2libGUgYXR0YWNrcy4NCj4gPiBJIGFncmVl IHdpdGggeW91IHRoYXQgdGhlcmUgaXMgbm8gcGVyZmVjdCBzZWN1cnR5Lg0KPiA+IEJ1dCB0aGlz IGZlYXR1cmUgY2FuIG5vdCBiZSBtaXMtdW5kZXJzdG9vZCB0aGF0IHdlIGRvbid0IG5lZWQgdG8g dGhpbmsNCj4gPiBhYm91dCB0aGUgc2VjdXJpdHkgaXNzdWVzIHRoYXQgYXJlIHJhaXNlZCBieSBh ZG9wdGluZyBhIG5ldyBwcm90b2NvbCBvciBzb2x1dGlvbi4NCj4gPiANCj4gPiAtLUp1bmdob29u DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4+VGhlIHVwc2hvdCBpcyB0aGF0IEkgZG9uJ3QgdGhpbmsg dGhlIHN1YnNjcmliZXJzIGNhbiBiZSB0cnVzdGVkIHRvIG5vdCANCj4gPj5zaGFyZSB0aGUgSEEn cyBJUCBhZGRyZXNzLCBlaXRoZXIgaW50ZW50aW9uYWxseSBvciB1bndpdHRpbmdseS4NCj4gPj4N Cj4gPj4gICAgRXJpaw0KPiA+Pg0KPiA+Pg0KPiA+Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+Pg0KPiA+ Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+TWlw NiBtYWlsaW5nIGxpc3QNCj4gPj5NaXA2QGlldGYub3JnDQo+ID4+aHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbWlwNg0KPiA= --===============1267307344== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1267307344==-- From mip6-bounces@ietf.org Thu Feb 17 00:39:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17317 for ; Thu, 17 Feb 2005 00:39:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1eip-0008Bt-KJ for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 01:01:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1eId-0007aP-Nf; Thu, 17 Feb 2005 00:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1eEh-0005xF-8d for mip6@megatron.ietf.org; Thu, 17 Feb 2005 00:29:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16340 for ; Thu, 17 Feb 2005 00:29:55 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ea4-0007u2-Mx for mip6@ietf.org; Thu, 17 Feb 2005 00:52:05 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC100B08J91QB@mailout2.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 14:29:25 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC100J2JJ9013@mailout2.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 14:29:25 +0900 (KST) Received: from Alperyegin ([105.253.155.46]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IC100510J8XXQ@mmp1.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 14:29:24 +0900 (KST) Date: Wed, 16 Feb 2005 21:29:20 -0800 From: Alper Yegin Subject: RE: [Mip6] mip6-aaa frameworks In-reply-to: <4213F7C4.8010704@iprg.nokia.com> To: "'Vijay Devarapalli'" Message-id: <1a4301c514b1$a2fbb920$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: ee80a2074afbfe28d15369f4e74e579d Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Content-Transfer-Encoding: 7BIT Vijay, > this classification is very confusing to me. This is one way to look at various MIP6-AAA interactions. If you have different ways to look at it, please share. > we are dealing with > three problems here. > > 1. Access network authentication > 2. bootstrapping > 3. MN authenticating to the Home Agent using its NAI/FQDN. > > for 3), it is simple. we need to standardize the interface between > the HA and the AAAH ASAP. we need both RADIUS attributes and > DIAMETER AVPs for this. this should be decoupled from the other > two problems. Well, isn't dynamically generating the MN-HA SA for [3] part of the bootstrapping problem [2]? > draft-ietf-mip6-ikev2-ipsec-02.txt already defines > how to run IKEv2 with EAP once the MN knows the HA's address. > > for 2), we need to standardize *a* solution. this could use/or not > use AAA. but I dont believe we can develop a solution that will > be valid in all deployments. for example, I think the mechanism > used in 3GPP2 is quite okay for 3GPP2 networks. I agree. > > for 1), again, I think it is specific to the deployment. but > doesnt hurt standardizing one solution in the IETF. Are you talking about plain network access auth/z? Or, something also related to MIP6? > ofcourse, you can develop a solution based on AAA that can > solve all three problems. (I guess draft-le... does that). but > the single solution might not work in all deployments. and we > have to evaluate the complexity involved. > > my 2 cents. Alper > > Vijay > > > Alper Yegin wrote: > > This is an attempt to enumerate possible MIP6-AAA frameworks, and start > > discussions on for which one(s) IETF shall pursue standardization. > > > > Framework 1: > > ------------ > > Using network access AAA to deliver MIP6 configuration parameters from > > the AAA server to the MN. > > > > MIP6 configuration is directly delivered from the AAA server to the MN > > during network access AAA, in-band with the authentication (e.g., > > transported by EAP or EAP methods). > > > > Related I-Ds: > > > > draft-giaretta-mip6-authorization-eap-01 > > draft-le-aaa-mipv6-requirements-03 > > draft-ohnishi-mip6-aaa-problem-statement-00 > > > > Discussion: > > > > The end2end transport between the AAA and the MN is the key. Use of EAP > > for this somewhat network access unrelated "configuration" is not > > recommended as far as I understand. One can design his own EAP method to > > do that, yet that would have limited applicability. > > > > > > Framework 2: > > ------------ > > Using network access AAA to deliver MIP6 configuration parameters from > > the AAA server to the NAS. It is assumed that parameters will be > > delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, > > etc.) > > > > Related I-Ds: > > > > draft-chowdhury-mip6-bootstrap-radius-00 > > draft-jang-dhc-haopt-00 > > > > Discussion: > > > > This is similar to NAS learning the IP address for the connected host > > via RADIUS, and delivering it to the host via DHCP. > > > > James had a comment regarding not having to support intra-operator > > interoperability. I think regardless of the deployment, interoperability > > between vendors is the important. Also, I was not sure on the complexity > > argument. > > > > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the > > suit. > > > > Framework 3: > > ------------ > > Piggybacking MIP6 signaling (BU) with network access AAA. In-band with > > the network access authentication execution, the MN delivers > > (piggybacks) a BU to the AAA server. The AAA server may have to relay > > the BU to the HA (unless collocated). > > > > Related I-D: > > > > draft-le-aaa-mipv6-requirements-03 > > > > Discussion: > > > > While the performance benefits are clear, limited applicability (not > > always the network access and mobility services are bundled) and > > complexity are concerning. > > > > > > Framework 4: > > ------------ > > A backend AAA protocol is executed between the HA and the AAA server in > > response to the MIP6 signaling between the MN and the HA. Similar to the > > use of AAA protocols with MIPv4 co-located care-of address case. > > > > Related I-Ds: > > > > draft-giaretta-mip6-aaa-ha-goals-00.txt > > draft-yegin-mip6-aaa-fwk-00.txt > > > > Discussion: > > This one appears to be the most needed framework. It is assumed that MN > > already knows the HA address. > > > > > > Are there other frameworks to add? > > > > I am sure I have missed some references, please let us know which ones. > > > > Alper > > > > > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 01:56:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24266 for ; Thu, 17 Feb 2005 01:56:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1fw3-0001ZF-Va for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 02:18:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1fYP-0002dE-QA; Thu, 17 Feb 2005 01:54:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1fXt-0002HV-9d for mip6@megatron.ietf.org; Thu, 17 Feb 2005 01:53:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24007 for ; Thu, 17 Feb 2005 01:53:52 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ftG-0001Vi-9s for mip6@ietf.org; Thu, 17 Feb 2005 02:16:00 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1H6qgP23003; Thu, 17 Feb 2005 08:52:42 +0200 (EET) X-Scanned: Thu, 17 Feb 2005 08:52:22 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1H6qMMs023966; Thu, 17 Feb 2005 08:52:22 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00dyaYXR; Thu, 17 Feb 2005 08:52:20 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1H6qKJ03277; Thu, 17 Feb 2005 08:52:20 +0200 (EET) Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 08:52:13 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 08:52:13 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for bootstrapping Mobile IPv6 ) Date: Thu, 17 Feb 2005 08:52:12 +0200 Message-ID: Thread-Topic: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (Problem Statement for bootstrapping Mobile IPv6 ) Thread-Index: AcUTnv1Kvbkpob/7S96Di+kl5yhWLgBHYT6g To: , X-OriginalArrivalTime: 17 Feb 2005 06:52:13.0348 (UTC) FILETIME=[35C62640:01C514BD] X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Hi Gopal, > This is a Working Group Last Call for the following I-D: > draft-ietf-mip6-bootstrap-ps-01.txt > Title: > Problem Statement for bootstrapping Mobile IPv6 >=20 > Please note that the status intended for this I-D is Proposed=20 > Standard. >=20 > Please review and post your comments by March 3rd, 2005. I generally support this work going forward, but I found the draft to be overly long and containing many assumptions that I believe are unwarrented. Idealy, the problem statement should be no longer than 10 pages, IMO. I'd like a short description of the problem and motivation for solving the problem. Some high-level discussion of the=20 MN needs, the source of the bootstrapping information, etc. is OK, but I think discussion of the deployment models is probably not very useful. I would be happy to work with the author on cleaning this up, if there is support for my view. My feeling is that most of what I would like to see is burried in the document and would just need some re-organization inside the document and removal of some stuff. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 02:01:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26000 for ; Thu, 17 Feb 2005 02:01:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1g0g-0001gu-H4 for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 02:23:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1fdp-0004Kr-Fs; Thu, 17 Feb 2005 02:00:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1fbL-0003eG-7f for mip6@megatron.ietf.org; Thu, 17 Feb 2005 01:57:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24331 for ; Thu, 17 Feb 2005 01:57:26 -0500 (EST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1fwk-0001a4-9T for mip6@ietf.org; Thu, 17 Feb 2005 02:19:34 -0500 Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j1H6vMvB000771; Wed, 16 Feb 2005 22:57:22 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j1H6vLvX311870; Wed, 16 Feb 2005 22:57:21 -0800 (PST) Message-ID: <4214402C.7080203@sun.com> Date: Wed, 16 Feb 2005 22:56:44 -0800 From: Erik Nordmark User-Agent: Mozilla Thunderbird 1.0 (X11/20041208) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Junghoon Jee Subject: Re: [Mip6] mip6-aaa frameworks References: <004401c51409$928b96d0$6b70fe81@FlyToWorld> <421393C7.8000704@sun.com> <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> In-Reply-To: <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Junghoon Jee wrote: > Currently, my concern is about the integrity and replay protection for HA IP address. > Could we support this without requiring the security function in the pre-existing DNS servers ? > My answer is NO. > If my answer is correct, pre-existing DNS servers needs to be changed to support MIP6 bootstrapping. > I am not sure whethere this approach is right. Integrity and replay of expired information can be provided by DNSsec. So the operator of the DNS which has the records for the HA's IP addresses just needs to deploy DNSsec. > BTW, i don't agree to open up the chance of revealing the HA IP address by putting this information > into the publicly available DNS server. Anyone can query the DNS server to get any other's HA address. I'm confused because above you said you were concerned about integrity and replay protection (in response to my comment about confidentiality), and now you are talking about confidentiality. > This increase the possibility of DoS attack. I know that this point > is already mentioned in the bmip6 draft. > I am waiting their right solution for this. > I hope we don't draw back the dynamic HA assignment during MIP6 bootstraspping because we can not find right way to to this. > Any good idea ? Depends on the details of what the threats are, and whether they are realistic. Is the only concern that non-subscribers shouldn't be able to find out the HAs IP address? Is it ok if non-subscribers can find out the /64 (or /48) prefix which contains one or more HAs? Is there a concern about malicious subscribers? Is there a concern about subscribers which might be infectived with malware which sends off the IP addresses of the HAs to some attackers? Without understanding the above questions and having some idea about the answers it isn't possible to define any useful confidentiality for the HAs IP address. > About the confidentiality protection about HA address, > I talked with Jame through this mailing before. > With my mind, security issue that can be touched by the mobilty protocol > should be confined to the issues that are raised by the mobility protocol itself. > System security issues like hacking of local system's critical information or > ill-intended inside attackers are out of scope when considring the MIP6 security. But security doesn't work that way. Having a very good door lock on your house, and making sure that it is locked when you leave home, is no good if you leave the windows wide open; security is a systems issue. That doesn't mean you need to solve all the security issues in the whole system, but I think it does mean that you need to understand how security works across the whole system. Erik _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 02:30:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18248 for ; Thu, 17 Feb 2005 02:30:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1gTA-0002JX-5s for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 02:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1g5D-0006Z7-Pm; Thu, 17 Feb 2005 02:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1g13-0004eu-N2 for mip6@megatron.ietf.org; Thu, 17 Feb 2005 02:24:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17347 for ; Thu, 17 Feb 2005 02:24:00 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1gMR-0002B1-Vt for mip6@ietf.org; Thu, 17 Feb 2005 02:46:09 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1H7Nsc11369; Thu, 17 Feb 2005 09:23:54 +0200 (EET) X-Scanned: Thu, 17 Feb 2005 09:35:56 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1H7Zulw008224; Thu, 17 Feb 2005 09:35:56 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00FZHqso; Thu, 17 Feb 2005 09:35:52 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1H70HJ09451; Thu, 17 Feb 2005 09:00:17 +0200 (EET) Received: from esebe017.NOE.Nokia.com ([172.21.138.56]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 08:59:46 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe017.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 08:59:47 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Feb 2005 08:59:45 +0200 Message-ID: Thread-Topic: [Mip6] mip6-aaa frameworks Thread-Index: AcUUtAhLszQC8zfhRW2uxSxKJgHDngACW56g To: , X-OriginalArrivalTime: 17 Feb 2005 06:59:47.0140 (UTC) FILETIME=[44415040:01C514BE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] question about mip6-aaa frameworks X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Hi all, Starting a new thread as working though this thead is getting tough. It seems that a high-level view on this is needed, not looking at specific solutions at the moment. I think that this is somewhat of a complex mix of protocols, architectures and solutions which is making forward progress very difficult. I think Alper's and Vijay's mails are showing that there is a need to look at the network elements (possibly) involved and the potential deployment models proposed. It is clear that a = one-size-fits-all approach is bound to fail; and I assumed that the WG was interested in enabling existing deployments a way to provide bootstrapping = information to a mobile node. Therefore, I'd like to propose that we look at a higher-level view as a way forward out of this. I haven't been involved in any of the proposals, but I'd be happy to try to gather some thoughts about this, even though the submissions of new drafts is now closed. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 03:02:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20796 for ; Thu, 17 Feb 2005 03:02:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1gyC-000316-Hd for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 03:25:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1gYb-0001oj-Qc; Thu, 17 Feb 2005 02:58:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1gU9-0008Kl-C2 for mip6@megatron.ietf.org; Thu, 17 Feb 2005 02:54:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20204 for ; Thu, 17 Feb 2005 02:54:04 -0500 (EST) Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1gpY-0002pd-RU for mip6@ietf.org; Thu, 17 Feb 2005 03:16:13 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1H7rxD20140; Thu, 17 Feb 2005 09:53:59 +0200 (EET) X-Scanned: Thu, 17 Feb 2005 10:05:42 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1H85g3H010222; Thu, 17 Feb 2005 10:05:42 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00UguihT; Thu, 17 Feb 2005 10:05:41 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1H7rEJ23537; Thu, 17 Feb 2005 09:53:14 +0200 (EET) Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 01:53:12 -0600 Received: mvebe001.noe.nokia.com 172.18.140.37 from 10.241.58.4 10.241.58.4 via HTTP with MS-WebStorage 6.0.6249 Received: from vijayd4 by mvebe001.noe.nokia.com; 16 Feb 2005 23:53:11 -0800 Subject: RE: [Mip6] mip6-aaa frameworks From: Vijay Devarapalli To: ext Alper Yegin In-Reply-To: <1a4301c514b1$a2fbb920$291d9069@sisa.samsung.com> References: <1a4301c514b1$a2fbb920$291d9069@sisa.samsung.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1108626791.17801.9.camel@vijayd4> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 (1.4.5-9) Date: Wed, 16 Feb 2005 23:53:11 -0800 X-OriginalArrivalTime: 17 Feb 2005 07:53:12.0460 (UTC) FILETIME=[BAC654C0:01C514C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, "'Vijay Devarapalli'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: 7bit On Wed, 2005-02-16 at 21:29, ext Alper Yegin wrote: > Vijay, > > > this classification is very confusing to me. > > This is one way to look at various MIP6-AAA interactions. If you have > different ways to look at it, please share. > > > we are dealing with > > three problems here. > > > > 1. Access network authentication > > 2. bootstrapping > > 3. MN authenticating to the Home Agent using its NAI/FQDN. > > > > for 3), it is simple. we need to standardize the interface between > > the HA and the AAAH ASAP. we need both RADIUS attributes and > > DIAMETER AVPs for this. this should be decoupled from the other > > two problems. > > Well, isn't dynamically generating the MN-HA SA for [3] part of the > bootstrapping problem [2]? not always. see draft-ietf-mip6-ikve2-ipsec. ( I think Gerardo also had a draft on using EAP). if EAP is used with IKEv2 with a AAAH backend, then the MN and the HA can setup the required SAs dynamically. in this case, the MN just needs the HA's address before running IKE. the MN can even acquire a Home Address when it runs IKEv2 with the HA (section 7 of draft-ietf-mip6-ikev2-ipsec-00). this falls into framework 4 in your classification. > > > draft-ietf-mip6-ikev2-ipsec-02.txt already defines > > how to run IKEv2 with EAP once the MN knows the HA's address. > > > > for 2), we need to standardize *a* solution. this could use/or not > > use AAA. but I dont believe we can develop a solution that will > > be valid in all deployments. for example, I think the mechanism > > used in 3GPP2 is quite okay for 3GPP2 networks. > > I agree. > > > > > for 1), again, I think it is specific to the deployment. but > > doesnt hurt standardizing one solution in the IETF. > > Are you talking about plain network access auth/z? Or, something also > related to MIP6? plain network access. Vijay > > > ofcourse, you can develop a solution based on AAA that can > > solve all three problems. (I guess draft-le... does that). but > > the single solution might not work in all deployments. and we > > have to evaluate the complexity involved. > > > > my 2 cents. > > Alper > > > > > > Vijay > > > > > > Alper Yegin wrote: > > > This is an attempt to enumerate possible MIP6-AAA frameworks, and > start > > > discussions on for which one(s) IETF shall pursue standardization. > > > > > > Framework 1: > > > ------------ > > > Using network access AAA to deliver MIP6 configuration parameters > from > > > the AAA server to the MN. > > > > > > MIP6 configuration is directly delivered from the AAA server to the > MN > > > during network access AAA, in-band with the authentication (e.g., > > > transported by EAP or EAP methods). > > > > > > Related I-Ds: > > > > > > draft-giaretta-mip6-authorization-eap-01 > > > draft-le-aaa-mipv6-requirements-03 > > > draft-ohnishi-mip6-aaa-problem-statement-00 > > > > > > Discussion: > > > > > > The end2end transport between the AAA and the MN is the key. Use of > EAP > > > for this somewhat network access unrelated "configuration" is not > > > recommended as far as I understand. One can design his own EAP > method to > > > do that, yet that would have limited applicability. > > > > > > > > > Framework 2: > > > ------------ > > > Using network access AAA to deliver MIP6 configuration parameters > from > > > the AAA server to the NAS. It is assumed that parameters will be > > > delivered from the NAS to the MN via another protocol (e.g., DHCP, > PANA, > > > etc.) > > > > > > Related I-Ds: > > > > > > draft-chowdhury-mip6-bootstrap-radius-00 > > > draft-jang-dhc-haopt-00 > > > > > > Discussion: > > > > > > This is similar to NAS learning the IP address for the connected > host > > > via RADIUS, and delivering it to the host via DHCP. > > > > > > James had a comment regarding not having to support intra-operator > > > interoperability. I think regardless of the deployment, > interoperability > > > between vendors is the important. Also, I was not sure on the > complexity > > > argument. > > > > > > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow > the > > > suit. > > > > > > Framework 3: > > > ------------ > > > Piggybacking MIP6 signaling (BU) with network access AAA. In-band > with > > > the network access authentication execution, the MN delivers > > > (piggybacks) a BU to the AAA server. The AAA server may have to > relay > > > the BU to the HA (unless collocated). > > > > > > Related I-D: > > > > > > draft-le-aaa-mipv6-requirements-03 > > > > > > Discussion: > > > > > > While the performance benefits are clear, limited applicability (not > > > always the network access and mobility services are bundled) and > > > complexity are concerning. > > > > > > > > > Framework 4: > > > ------------ > > > A backend AAA protocol is executed between the HA and the AAA server > in > > > response to the MIP6 signaling between the MN and the HA. Similar to > the > > > use of AAA protocols with MIPv4 co-located care-of address case. > > > > > > Related I-Ds: > > > > > > draft-giaretta-mip6-aaa-ha-goals-00.txt > > > draft-yegin-mip6-aaa-fwk-00.txt > > > > > > Discussion: > > > This one appears to be the most needed framework. It is assumed that > MN > > > already knows the HA address. > > > > > > > > > Are there other frameworks to add? > > > > > > I am sure I have missed some references, please let us know which > ones. > > > > > > Alper > > > > > > > > > > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 03:19:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22455 for ; Thu, 17 Feb 2005 03:19:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1hDh-0003Pj-68 for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 03:41:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1gpV-00088J-Cx; Thu, 17 Feb 2005 03:16:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1gmW-0006rF-JA for mip6@megatron.ietf.org; Thu, 17 Feb 2005 03:13:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21895 for ; Thu, 17 Feb 2005 03:13:03 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1h7w-0003GT-DI for mip6@ietf.org; Thu, 17 Feb 2005 03:35:12 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1H8gSU02084; Thu, 17 Feb 2005 00:42:28 -0800 X-mProtect: <200502170842> Nokia Silicon Valley Messaging Protection Received: from daec-linuxvpn0584.americas.nokia.com (10.241.58.4, claiming to be "[192.168.1.101]") by darkstar.iprg.nokia.com smtpdjubyaA; Thu, 17 Feb 2005 00:42:20 PST Message-ID: <421451CD.7060409@iprg.nokia.com> Date: Thu, 17 Feb 2005 00:11:57 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Junghoon Jee Subject: Re: [Mip6] mip6-aaa frameworks References: <004401c51409$928b96d0$6b70fe81@FlyToWorld> <421393C7.8000704@sun.com> <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> <42140322.20706@iprg.nokia.com> <005101c514a5$7d9fef40$6b70fe81@FlyToWo In-Reply-To: <005101c514a5$7d9fef40$6b70fe81@FlyToWorld> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Alper Yegin , Erik Nordmark , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Junghoon Jee wrote: > Hello Vijay. > Please see my comments inline. > > >>Junghoon Jee wrote: >> >> >>>>>The dynamic HA discovery is still an issue. >>>>>With my mind, adding security mechanism to the pre-existing DNS query may be a burden. >>>> >>>>The need for confidentiality of the HAs IP address is hard for me to >>>>understand without understanding the threat model. >>> >>> >>>Currently, my concern is about the integrity and replay protection for HA IP address. >>>Could we support this without requiring the security function in the pre-existing DNS servers ? >>>My answer is NO. >>>If my answer is correct, pre-existing DNS servers needs to be changed to support MIP6 bootstrapping. >>>I am not sure whethere this approach is right. >> >>I have to disagree here. it is like getting any other server's address >>through DNS. IMHO, the threat model is no different. > > > draft-ietf-bootstrap-ps requires the integrity and replay protection of bootstrapping information. > What do you think about this ? the problem statement doesnt actually require this. it lists it as a design goal. there is a slight difference. and I had actually excluded MN acquiring the HA's address through DNS as something outside the bootstrapping problem statement. something that can be used readily today. note, that only HA's address is obtained through DNS. not the HoA. and as Erik pointed out, one can always use DNSSEC. > >>>BTW, i don't agree to open up the chance of revealing the HA IP address by putting this information >>>into the publicly available DNS server. Anyone can query the DNS server to get any other's HA address. >>>This increase the possibility of DoS attack. I know that this point is already mentioned in the bmip6 draft. >>>I am waiting their right solution for this. >> >>this might sound cliched, but you cannot achieve security through >>obscurity. :) > > Please look at the Appendix A. of bmip draft. > Could you explain why you use the word 'cliched' and 'obscurity' without any detailed explanation ? because you can't really hope to hide your HA address. that is just not possible. most often, I find that an Operator's configuration settings can be just obtained from the web. I dont see Cingular trying to hide GPRS Access Points information. they publish it on the web. > Wouldn't you want to keep the basic step because you think it is cliched ? please read further in the same paragraph. > The threat from DDoS > in this case is no larger than for any other widely known public > Internet server, such as a popular Web site or, indeed, a DNS server > for a top level domain. Measures similar to those used by popular > Web site providers or DNS server operators can be deployed to > mitigate such attacks. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 03:41:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24418 for ; Thu, 17 Feb 2005 03:41:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1hZF-00046B-EV for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 04:03:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hAT-0008GY-0V; Thu, 17 Feb 2005 03:37:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1h4q-0005bL-TC for mip6@megatron.ietf.org; Thu, 17 Feb 2005 03:32:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23578 for ; Thu, 17 Feb 2005 03:31:59 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1hQF-0003hl-99 for mip6@ietf.org; Thu, 17 Feb 2005 03:54:08 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC100M0CRO9MV@mailout3.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 17:31:21 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC100E19RO626@mailout3.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 17:31:18 +0900 (KST) Received: from Alperyegin ([105.253.155.46]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IC100K31RO452@mmp2.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 17:31:18 +0900 (KST) Date: Thu, 17 Feb 2005 00:31:13 -0800 From: Alper Yegin Subject: MIP6-AAA fwk 2 (was RE: [Mip6] mip6-aaa frameworks) In-reply-to: <20050216123456.GJ11112@ipv6-3.int-evry.fr> To: "'Julien Bournelle'" Message-id: <1a4901c514cb$0bd7b610$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7BIT Hi Julien, > > Framework 2: > > ------------ > > Using network access AAA to deliver MIP6 configuration parameters from > > the AAA server to the NAS. It is assumed that parameters will be > > delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, > > etc.) > > > > Related I-Ds: > > > > draft-chowdhury-mip6-bootstrap-radius-00 > > draft-jang-dhc-haopt-00 > > > > Discussion: > > > > This is similar to NAS learning the IP address for the connected host > > via RADIUS, and delivering it to the host via DHCP. > > > > James had a comment regarding not having to support intra-operator > > interoperability. I think regardless of the deployment, interoperability > > between vendors is the important. Also, I was not sure on the complexity > > argument. > > > > 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the > > suit. > > Concerning this framework, I also see 2 possibilities: > > - add mip6 functionalities to exisiting applications: basically add some > AVPs and mechanisms to RADIUS EAP/ Diameter EAP (if EAP is in use). > This also imply some modifications to 802.1X/PANA/... > > - define a specific AAA application for mip6. In this case, we'll have > at least two AAA applications used in the access network. The reason > is that I guess we won't have only mip6 terminal. Thus the > authentication agent will need a way to select the right application. > The protocol used between the MN and the authentication agent will > also need some modifications to handle this. I don't think we'd need a new AAA application. It is the same NAS application carrying additional configuration parameters. One can design a solution where MN can indicate its desire to learn MIP6 parameters during network access AAA. (or, if AAA home server is sending a piece of information that does not generate or change state, e.g., HA address, it can do that anyways, and MN can toss it away if not needed) Alper > > > -- > julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 03:53:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA25237 for ; Thu, 17 Feb 2005 03:53:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1hky-0004NJ-SJ for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 04:15:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hKu-0003qn-Eg; Thu, 17 Feb 2005 03:48:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1hJC-00035H-Dm for mip6@megatron.ietf.org; Thu, 17 Feb 2005 03:46:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24791 for ; Thu, 17 Feb 2005 03:46:48 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1heZ-0004Dr-6q for mip6@ietf.org; Thu, 17 Feb 2005 04:08:58 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC100E04SD2ND@mailout1.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 17:46:14 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC100LF5SD2YF@mailout1.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 17:46:14 +0900 (KST) Received: from Alperyegin ([105.253.155.46]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IC100F6DSCYC4@mmp1.samsung.com> for mip6@ietf.org; Thu, 17 Feb 2005 17:46:14 +0900 (KST) Date: Thu, 17 Feb 2005 00:46:07 -0800 From: Alper Yegin Subject: accounting (was RE: [Mip6] mip6-aaa frameworks) In-reply-to: <004401c51409$928b96d0$6b70fe81@FlyToWorld> To: "'Junghoon Jee'" , "'Gerardo Giaretta'" , "'Erik Nordmark'" Message-id: <1a4a01c514cd$218f0740$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7BIT > With regards to the framework 4, > I am still not clear about what the mobility service is. > I think the mobility service is started when the MN bootstraps. > When does the mobility service end ? > MIPv6 also supports the RR. > That means that the HA may not know how many packets were trasversed for > the MN. > With related with this point, accounting processing in the AAA server can > be an issue. > As i know, currently AAA accounting is processed for the network access > service. > If we try to charge only for the mobility service, we need to clearly > define what the mobility service is. MIP6 service is being provided by the HA when there is an active MIP6 binding cache entry for the MN. HA can keep track of forward and reverse tunneled IP packets, received BU/HoTI/HoT messages. HA cannot do anything about end2end signaling and data traffic between the MN and CNs. That's not necessary either. Turning these accounting information to billing is not a protocol concern. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 05:22:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03012 for ; Thu, 17 Feb 2005 05:22:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1j9N-0006S0-MD for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 05:44:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ilh-0003uo-7u; Thu, 17 Feb 2005 05:20:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ij0-0002ez-Ag for mip6@megatron.ietf.org; Thu, 17 Feb 2005 05:17:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02530 for ; Thu, 17 Feb 2005 05:17:32 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1j4P-0006KW-W5 for mip6@ietf.org; Thu, 17 Feb 2005 05:39:43 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IC100L11W1T1R@dns2.cselt.it> for mip6@ietf.org; Thu, 17 Feb 2005 11:06:10 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 11:16:12 +0100 Date: Thu, 17 Feb 2005 11:16:36 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] mip6-aaa frameworks To: Erik Nordmark Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] mip6-aaa frameworks Thread-Index: AcUUVgKwXk2wxmfqQTuqmfKse8L+vAAgg3uA Content-class: urn:content-classes:message X-OriginalArrivalTime: 17 Feb 2005 10:16:12.0515 (UTC) FILETIME=[B4E2D330:01C514D9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable Hi Erik, please see below... >=20 > Gerardo Giaretta wrote: > > Hi Erik, >=20 > > I agree that framework 4 should be standardized. > > draft-chakrabati-mip6-bmip-00 describes a solution based on this > > framework that allows also dynamic HA discovery. I guess this draft > > could be a good starting point. Since in this draft the HA=20 > acts as a EAP > > pass-through authenticator, I think we should also investigate if > > Diameter EAP application is suitable for the HA-AAA=20 > communication or we > > need another draft specifying a new Diameter application or some new > > MIPv6-specific AVPs. >=20 > Yes, it makes sense to investigate this. >=20 > > However note that this approach is not optimized in case of=20 > Integrated > > ASP: in this scenario, the MN needs to execute two EAP=20 > runs, one EAP for > > network access authentication and the other EAP over IKEv2=20 > and, as you > > mention, the same AAA backend, the same NAI and even the=20 > same EAP method > > could be used for these two cases. For this reason, I think that we > > should standardize also an optimized approach in which AAA=20 > for network > > access and AAA for mobility service are dependent and only one EAP > > exchange needs to be executed. Note that here I'm not not=20 > advocating any > > of the solutions proposed so far (e.g. EAP, PANA, Diameter,=20 > DHCP), I'm > > only suggesting to have also an optimized solution that=20 > might be useful > > to mobile operators that would like to deploy MIPv6 in an=20 > efficient way. >=20 > The thing that is a bit hard for me to understand is whether=20 > and how a=20 > MN can cope with both the separate and integrated ones. >=20 > For instance, do we see there being a MN which will perform the=20 > integrated approach (if that is used by the access network)=20 > and fallback=20 > to use the separate approach? Or will there be completely=20 > separate MNs=20 > so that we don't need to worry about which to try first and=20 > the possible=20 > interaction between the two different schemes. >=20 I think it depends on the solution used for bootstrapping MIPv6 during network access authentication. However, generally I think that during network access authentication, the AAAH or the NAS (depending on the solution via EAP or a EAP lower layer) should communicate to the MN if MIPv6 is available (e.g. through an AVP/TLV). If so, the MN can start bootstrapping MIPv6 using the AAA infrastructure and the AAA exchange used for network access authentication. If the MN is not required to perform the network access authentication (i.e. in a free network) or it cannot bootstrap MIPv6 in an integrated way from its current access network location (e.g. the NAS does not support MIPv6 extensions), the MN will not receive any hint from the network for MIPv6 bootstrapping and will start bootstrapping MIPv6 in a non-optimized way through IKEv2. =20 --Gerardo > Erik >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 05:51:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06467 for ; Thu, 17 Feb 2005 05:51:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1jbY-0007CL-Jc for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 06:13:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jCj-0005yf-JB; Thu, 17 Feb 2005 05:48:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1j7Q-0003kG-VD for mip6@megatron.ietf.org; Thu, 17 Feb 2005 05:42:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05450 for ; Thu, 17 Feb 2005 05:42:46 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1jSr-0006w3-Gh for mip6@ietf.org; Thu, 17 Feb 2005 06:04:58 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IC100538XML4L@dns1.cselt.it> for mip6@ietf.org; Thu, 17 Feb 2005 11:39:57 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 11:44:52 +0100 Date: Thu, 17 Feb 2005 11:42:16 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt To: James Kempf , Yoshihiro Ohba Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt thread-index: AcUUbtQ2pTtSa3gXQMWW61LR89hIegAbTUAQ Content-Class: urn:content-classes:message X-OriginalArrivalTime: 17 Feb 2005 10:44:52.0875 (UTC) FILETIME=[B64CEDB0:01C514DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable Hi James, Yoshi, please see a comment at the end... >=20 > Yoshi, >=20 > > This seems to be a general problem that is common to any roaming > > scenario, not specific to MIP6 bootstrapping scenario. The IETF > > already defines a similar framework for Mobile IPv4=20 > bootstrapping with > > having a MN-FA-AAA interface and I don't see a problem in=20 > general (in > > terms of complexity for roaming support) with replacing FA with > > NAS/DHCP in the case of Mobile IPv6 bootstrapping. > > >=20 > Yes, but configuration is a different problem from network=20 > access/mobility > auth/authz.. The information distributed by any network=20 > access/mobility > roaming consists of a yes/no indication about whether someone=20 > can enter the > network, together with possibly a master key associated with that > permission. >=20 > What your draft is talking about is distributing detailed=20 > configuration > about the topology and services in the home administrative=20 > domain. There is > much more that can go wrong in that case. >=20 >=20 > > > The other alternative is that the AAA-H itself=20 > communicates with the > AAA-F > > > to obtain the local HA address, then sends it back in the=20 > EAP reply. In > that > > > case, there is an additional round trip on the back end,=20 > but, again > there > > > would be no need for the IKEv2 transaction if the EAP is used to > configure > > > the IPsec SA. > > > > But both of these would need to push IKE credentials of the MN from > > the AAA server in the home domain to the local HA in the visited > > domain, to avoid the second EAP run. On the other hand, if we allow > > the delivery of IKE credentials to the local HA across=20 > administrative > > domains, I think we can certainly allow the framework of=20 > carrying a HA > > address to the local NAS/DHCP across administrative domains. > > >=20 > The difference is that the delivery is end to end, between=20 > the MN and the > AAA-H with EAP. So the security can be end to end, between=20 > the home network > operator and the client. If the NAS is in the middle, as in=20 > your proposal, > there is a weak point where compromise of security, or=20 > network management > problems are more likely to occur. >=20 I completely agree on this.=20 In particular this is also the reason why I think the second alternative suggested by James is more attractive: the AAA-H communicates with the AAA-F to obtain the local HA address, then sends it back to the MN in the EAP reply. In this way, the MN-AAAH interface is the same both if the HA is assigned locally or in the home operator network and this seems to reduce the complexity of the system; the difference is in the AAAH-AAAF interface and might be handled with specific Diameter AVPs. --Gerardo > jak >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 06:22:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08802 for ; Thu, 17 Feb 2005 06:22:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1k5S-0007xv-HN for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 06:44:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jhn-0002Tt-0o; Thu, 17 Feb 2005 06:20:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jYN-00073q-Hm for mip6@megatron.ietf.org; Thu, 17 Feb 2005 06:10:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08124 for ; Thu, 17 Feb 2005 06:10:37 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1jto-0007iF-Od for mip6@ietf.org; Thu, 17 Feb 2005 06:32:49 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1HBAPP13513; Thu, 17 Feb 2005 13:10:25 +0200 (EET) X-Scanned: Thu, 17 Feb 2005 13:21:11 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1HBLBd8028044; Thu, 17 Feb 2005 13:21:11 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 009iDCTb; Thu, 17 Feb 2005 13:21:07 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1HB8YM15759; Thu, 17 Feb 2005 13:08:34 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 13:07:02 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 17 Feb 2005 13:07:02 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: accounting (was RE: [Mip6] mip6-aaa frameworks) Date: Thu, 17 Feb 2005 13:07:01 +0200 Message-ID: Thread-Topic: accounting (was RE: [Mip6] mip6-aaa frameworks) Thread-Index: AcUUz/mokl9E/mjAQ6OQI4g07iPh2gAEJ+uw To: , , , X-OriginalArrivalTime: 17 Feb 2005 11:07:02.0176 (UTC) FILETIME=[CEA02A00:01C514E0] X-Spam-Score: 0.3 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Hi Alper, > > With regards to the framework 4, > > I am still not clear about what the mobility service is. > > I think the mobility service is started when the MN bootstraps. > > When does the mobility service end ? > > MIPv6 also supports the RR. > > That means that the HA may not know how many packets were = trasversedfor > > the MN. > > With related with this point, accounting processing in the AAA = server can > > be an issue. > > As i know, currently AAA accounting is processed for the network = access > > service. > > If we try to charge only for the mobility service, we need to = clearly > > define what the mobility service is. >=20 > MIP6 service is being provided by the HA when there is an active MIP6 > binding cache entry for the MN. HA can keep track of forward and = reverse > tunneled IP packets, received BU/HoTI/HoT messages. HA cannot do > anything about end2end signaling and data traffic between the MN and > CNs. That's not necessary either. Turning these accounting information > to billing is not a protocol concern. I agree with you. I think that accounting for these packets are not a = protocol concern, but much more of deployment issue (i.e. - which packets you = charge for and where do you put the packet counting box). John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 06:45:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12339 for ; Thu, 17 Feb 2005 06:45:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1kRQ-0000GB-Qe for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 07:07:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1k3z-0003tc-9r; Thu, 17 Feb 2005 06:43:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1jzo-000222-Ld for mip6@megatron.ietf.org; Thu, 17 Feb 2005 06:39:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11741 for ; Thu, 17 Feb 2005 06:38:58 -0500 (EST) Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1kLF-0008VG-1s for mip6@ietf.org; Thu, 17 Feb 2005 07:01:10 -0500 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id 59B1381E0; Thu, 17 Feb 2005 12:38:20 +0100 (CET) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.34) id 1D1jye-00046u-0E; Thu, 17 Feb 2005 12:37:48 +0100 Date: Thu, 17 Feb 2005 12:37:47 +0100 From: Julien Bournelle To: Junghoon Jee Subject: Re: [Mip6] mip6-aaa frameworks Message-ID: <20050217113747.GX11112@ipv6-3.int-evry.fr> References: <20050216153429.GQ11112@ipv6-3.int-evry.fr> <000c01c51486$3e8a4770$6b70fe81@FlyToWorld> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000c01c51486$3e8a4770$6b70fe81@FlyToWorld> User-Agent: Mutt/1.5.6+20040907i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Alper Yegin , Julien Bournelle , mip6@ietf.org, Tschofenig Hannes X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi, comments inline, On Thu, Feb 17, 2005 at 09:18:45AM +0900, Junghoon Jee wrote: > > the idea is not to depend on some infrastructure. The "AAA" idea is that > > we could have this infrastructure available and that in this case it can > > be interesting to couple it with the bootstrapping procedure for > > authorization and accounting purpose. > > > > however, we can't assume that we always have a AAA system. In this case, > > we need framework 4 (or something else). Does this imply that we should reject > > framwork 1-2 ? > > As i know, even framework 4, there is a AAA home server in the MN's home network. > I think in this case, there is no AAA server in the local--visited domain of the MN. > So, no ASP and only with MSP. > I personally want a AAA home server infrastructure which can support MIP6 bootdstrapping > tranparently whether the ASP or IASP is deployed. I just said that we can't always assume that it exists a AAA network access system in the visited network thus, in my opinion, we really need a solution based on framework 4. I'm just wondering if, taking into account that solution 4 is needed, we can also standardize a solution based on framework 1 or 2. This does not mean that I'm in favor of solution 4. -- julien.bournelle@int-evry.fr _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 08:16:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19811 for ; Thu, 17 Feb 2005 08:16:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ls2-0002c2-NJ for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 08:39:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1lSl-0004Xz-I1; Thu, 17 Feb 2005 08:12:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1lOk-0002yG-3o for mip6@megatron.ietf.org; Thu, 17 Feb 2005 08:08:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19101 for ; Thu, 17 Feb 2005 08:08:49 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1lkA-0002Pr-K6 for mip6@ietf.org; Thu, 17 Feb 2005 08:30:59 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1HD7bWj001757; Thu, 17 Feb 2005 22:07:37 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1HD7akf027301; Thu, 17 Feb 2005 22:07:37 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1HD7aHa027298; Thu, 17 Feb 2005 22:07:36 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1HD7asn015714; Thu, 17 Feb 2005 22:07:36 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1HD7aNg015711; Thu, 17 Feb 2005 22:07:36 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1HD7ZWR019815; Thu, 17 Feb 2005 22:07:35 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1HD7ZVW012302; Thu, 17 Feb 2005 22:07:35 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1HD7ZcP012299; Thu, 17 Feb 2005 22:07:35 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id WAA10401; Thu, 17 Feb 2005 22:07:34 +0900 (JST) Message-ID: <4214978D.7080005@lab.ntt.co.jp> Date: Thu, 17 Feb 2005 22:09:33 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: Yoshihiro Ohba Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> In-Reply-To: <20050217015704.GE25571@steelhead> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit Hi James, Ohba-san and all, Let me add new point of view for classification of framework. (It does not mean that I disagree Alper's classification.) I think that framework can be divided into 2 main branches as follows. Type1: bootstrapping procedure is executed between MN and AAA server. Type2: bootstrapping procedure is executed between MN and network elements such as HA, NAS and DHCP server. Those network elements can use back end AAA server. In type 1, we assumed that MNs and AAA server communicate directly by using authentication protocol such as EAP and network elements are not required to understand MIP6 specific information. So, I don't think that we are required to specify detailed interface between AAA and MN because AAA in home network can assign configuration parameters in vendor specific attribute. Local domain | Home domain NE | AAA | | +--------------+ | | MN | In type2, we are required to specify interface. Because bootstrapping messages may be treated by network elements in local domain and AAA server in home network. I don't understand why problems are caused only in DHCP case. Local domain | Home domain NE-------------------->AAA (DHCP, HA, NAS) | | | | NE | | | MN- - - - - - - - - - - + | Could you give me comments? Best Redards --Mayumi > On Wed, Feb 16, 2005 at 01:19:42PM -0800, James Kempf wrote: > >>Yoshi, >> >> >>>This seems to be a general problem that is common to any roaming >>>scenario, not specific to MIP6 bootstrapping scenario. The IETF >>>already defines a similar framework for Mobile IPv4 bootstrapping with >>>having a MN-FA-AAA interface and I don't see a problem in general (in >>>terms of complexity for roaming support) with replacing FA with >>>NAS/DHCP in the case of Mobile IPv6 bootstrapping. >>> >> >>Yes, but configuration is a different problem from network access/mobility >>auth/authz.. The information distributed by any network access/mobility >>roaming consists of a yes/no indication about whether someone can enter the >>network, together with possibly a master key associated with that >>permission. >> >>What your draft is talking about is distributing detailed configuration >>about the topology and services in the home administrative domain. There is >>much more that can go wrong in that case. > > > So do you think that the existing solution for Mobile IPv4 > bootstrapping is not a good solution to follow when defining a Mobile > IPv6 bootstrapping solution? > > >> >>>>The other alternative is that the AAA-H itself communicates with the >> >>AAA-F >> >>>>to obtain the local HA address, then sends it back in the EAP reply. In >> >>that >> >>>>case, there is an additional round trip on the back end, but, again >> >>there >> >>>>would be no need for the IKEv2 transaction if the EAP is used to >> >>configure >> >>>>the IPsec SA. >>> >>>But both of these would need to push IKE credentials of the MN from >>>the AAA server in the home domain to the local HA in the visited >>>domain, to avoid the second EAP run. On the other hand, if we allow >>>the delivery of IKE credentials to the local HA across administrative >>>domains, I think we can certainly allow the framework of carrying a HA >>>address to the local NAS/DHCP across administrative domains. >>> >> >>The difference is that the delivery is end to end, between the MN and the >>AAA-H with EAP. So the security can be end to end, between the home network >>operator and the client. If the NAS is in the middle, as in your proposal, >>there is a weak point where compromise of security, or network management >>problems are more likely to occur. > > > I don't understand the security threat because the HA address is > somehow exposed to the operator of the visited domain when the MN > sends a BU to the HA (I mentioned this several months ago). Also I > don't understand the network management problems, because even in the > end-to-end delivery model you mentioned above, some information such > as IKEv2 credentials would need to be passed to the local HA in the > visited domain from the home domain (it's not a pure end-to-end > delivery in that sense) in order for the MN to perform IKEv2 with the > local HA without running EAP over IKEv2. I really don't see a major > difference between managing IKEv2 credentials and managing HA address > across administrative domains. > > Regards, > > Yoshihiro Ohba > > > > >> jak >> >> > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > -- *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 59 5631 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 08:55:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24629 for ; Thu, 17 Feb 2005 08:55:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mTm-0003iK-3b for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 09:18:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1lx0-0007CZ-I6; Thu, 17 Feb 2005 08:44:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1log-0004ga-SJ for mip6@megatron.ietf.org; Thu, 17 Feb 2005 08:35:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21747 for ; Thu, 17 Feb 2005 08:35:37 -0500 (EST) Received: from goliath.siemens.de ([192.35.17.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mA9-00038Y-A6 for mip6@ietf.org; Thu, 17 Feb 2005 08:57:49 -0500 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.12.6/8.12.6) with ESMTP id j1HDZRJH023248; Thu, 17 Feb 2005 14:35:27 +0100 Received: from mchp9daa.mch.sbs.de (mchp9daa.mch.sbs.de [139.25.137.99]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id j1HDZRiQ024056; Thu, 17 Feb 2005 14:35:27 +0100 Received: by mchp9daa.mch.sbs.de with Internet Mail Service (5.5.2657.72) id <1XNRK2RT>; Thu, 17 Feb 2005 14:35:27 +0100 Message-ID: From: Tschofenig Hannes To: "'Mayumi Yanagiya'" , Yoshihiro Ohba Subject: AW: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.tx t Date: Thu, 17 Feb 2005 14:34:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: mip6@ietf.org, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 hi all, let me try another attempt: the authentication and key exchange protocol will be run between two nodes (eap peer and eap server, if we assume eap usage -- i think most people do). now, since the eap peer and the eap server do not communicate directly with each other (in most cases at least) we have in many cases another party in the game. finally, there is yet another node that is target of the whole bootstrapping procedure (if i assume that the end host is always the second target since the established keying material is supposed to be known to two or more parties). please some note that some of these entities may not be physically separated. now, how does your classification consider these three aspects? btw, i disagree that the protocol between the aaa server and the home agent, .. etc. node does not need to be standardized. ciao hannes > Hi James, Ohba-san and all, > > Let me add new point of view for classification of framework. > (It does not mean that I disagree Alper's classification.) > > I think that framework can be divided into 2 main branches as follows. > Type1: bootstrapping procedure is executed between MN and AAA server. > Type2: bootstrapping procedure is executed between MN and network > elements such as HA, NAS and DHCP server. > Those network elements can use back end AAA server. > > In type 1, we assumed that MNs and AAA server communicate directly by > using authentication protocol such as EAP and network elements are not > required to understand MIP6 specific information. So, I don't > think that > we are required to specify detailed interface between AAA and > MN because > AAA in home network can assign configuration parameters in vendor > specific attribute. > > Local domain | Home domain > NE | AAA > | | > +--------------+ > | | > MN | > > In type2, we are required to specify interface. Because bootstrapping > messages may be treated by network elements in local domain and AAA > server in home network. > I don't understand why problems are caused only in DHCP case. > > Local domain | Home domain > NE-------------------->AAA > (DHCP, HA, NAS) | | > | | NE > | | | > MN- - - - - - - - - - - + > | > > Could you give me comments? > > Best Redards > --Mayumi > > > On Wed, Feb 16, 2005 at 01:19:42PM -0800, James Kempf wrote: > > > >>Yoshi, > >> > >> > >>>This seems to be a general problem that is common to any roaming > >>>scenario, not specific to MIP6 bootstrapping scenario. The IETF > >>>already defines a similar framework for Mobile IPv4 > bootstrapping with > >>>having a MN-FA-AAA interface and I don't see a problem in > general (in > >>>terms of complexity for roaming support) with replacing FA with > >>>NAS/DHCP in the case of Mobile IPv6 bootstrapping. > >>> > >> > >>Yes, but configuration is a different problem from network > access/mobility > >>auth/authz.. The information distributed by any network > access/mobility > >>roaming consists of a yes/no indication about whether > someone can enter the > >>network, together with possibly a master key associated with that > >>permission. > >> > >>What your draft is talking about is distributing detailed > configuration > >>about the topology and services in the home administrative > domain. There is > >>much more that can go wrong in that case. > > > > > > So do you think that the existing solution for Mobile IPv4 > > bootstrapping is not a good solution to follow when > defining a Mobile > > IPv6 bootstrapping solution? > > > > > >> > >>>>The other alternative is that the AAA-H itself > communicates with the > >> > >>AAA-F > >> > >>>>to obtain the local HA address, then sends it back in the > EAP reply. In > >> > >>that > >> > >>>>case, there is an additional round trip on the back end, > but, again > >> > >>there > >> > >>>>would be no need for the IKEv2 transaction if the EAP is used to > >> > >>configure > >> > >>>>the IPsec SA. > >>> > >>>But both of these would need to push IKE credentials of the MN from > >>>the AAA server in the home domain to the local HA in the visited > >>>domain, to avoid the second EAP run. On the other hand, > if we allow > >>>the delivery of IKE credentials to the local HA across > administrative > >>>domains, I think we can certainly allow the framework of > carrying a HA > >>>address to the local NAS/DHCP across administrative domains. > >>> > >> > >>The difference is that the delivery is end to end, between > the MN and the > >>AAA-H with EAP. So the security can be end to end, between > the home network > >>operator and the client. If the NAS is in the middle, as in > your proposal, > >>there is a weak point where compromise of security, or > network management > >>problems are more likely to occur. > > > > > > I don't understand the security threat because the HA address is > > somehow exposed to the operator of the visited domain when the MN > > sends a BU to the HA (I mentioned this several months ago). Also I > > don't understand the network management problems, because > even in the > > end-to-end delivery model you mentioned above, some information such > > as IKEv2 credentials would need to be passed to the local HA in the > > visited domain from the home domain (it's not a pure end-to-end > > delivery in that sense) in order for the MN to perform > IKEv2 with the > > local HA without running EAP over IKEv2. I really don't see a major > > difference between managing IKEv2 credentials and managing > HA address > > across administrative domains. > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > > >> jak > >> > >> > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > -- > > *++++++++++++++++++++++++++++++++++++++++++ > NTT Network Service Systems Laboratories > Mayumi Yanagiya > tel: +81 422 59 6783 fax: +81 422 59 5631 > E-mail: yanagiya.mayumi@lab.ntt.co.jp > +++++++++++++++++++++++++++++++++++++++++++* > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 09:05:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25701 for ; Thu, 17 Feb 2005 09:05:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1md4-00040v-NI for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 09:27:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1m8v-0003yV-HU; Thu, 17 Feb 2005 08:56:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1m2m-0001UB-9A for mip6@megatron.ietf.org; Thu, 17 Feb 2005 08:50:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24153 for ; Thu, 17 Feb 2005 08:50:10 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1mOD-0003Yj-Af for mip6@ietf.org; Thu, 17 Feb 2005 09:12:23 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IC2009325WNCU@dns2.cselt.it> for mip6@ietf.org; Thu, 17 Feb 2005 14:38:47 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Feb 2005 14:49:13 +0100 Date: Thu, 17 Feb 2005 14:49:37 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] mip6-aaa frameworks To: Vijay Devarapalli Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] mip6-aaa frameworks Thread-Index: AcUUlL4n6nbjAu/8QN6Nq1UheijGlwAYCMBQ Content-class: urn:content-classes:message X-OriginalArrivalTime: 17 Feb 2005 13:49:13.0031 (UTC) FILETIME=[76AACD70:01C514F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: quoted-printable Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable Hi Vijay, >=20 > this classification is very confusing to me. we are dealing with > three problems here. >=20 > 1. Access network authentication > 2. bootstrapping > 3. MN authenticating to the Home Agent using its NAI/FQDN. >=20 > for 3), it is simple. we need to standardize the interface between > the HA and the AAAH ASAP. we need both RADIUS attributes and > DIAMETER AVPs for this. this should be decoupled from the other > two problems. draft-ietf-mip6-ikev2-ipsec-02.txt already defines > how to run IKEv2 with EAP once the MN knows the HA's address. > I completely agree on that. This is the reason of draft-giaretta-mip6-aaa-ha-goals, where we tried to identify some design goals for such an interface. I think we should standardize this interface at least to enable the usage of a AAA backend authentication server in draft-ietf-mip6-ikev2-ipsec-02. Then, this interface might be useful also for other frameworks: as suggested by draft-giaretta-mip6-aaa-ha-goals, if you try to list the goals for each framework, they do not differ too much and lots of them are in common. =20 > for 2), we need to standardize *a* solution. this could use/or not > use AAA. but I dont believe we can develop a solution that will > be valid in all deployments. for example, I think the mechanism > used in 3GPP2 is quite okay for 3GPP2 networks. >=20 > for 1), again, I think it is specific to the deployment. but > doesnt hurt standardizing one solution in the IETF. >=20 > ofcourse, you can develop a solution based on AAA that can > solve all three problems. (I guess draft-le... does that). but > the single solution might not work in all deployments. and we > have to evaluate the complexity involved. >=20 Sure.=20 However I think that the WG should decide if an optmized solution for an Integrated ASP should be standardized other than the IKEv2(+EAP) framework. I remember that in the boostrapping PS DT we decided to highlight the Integrated ASP scenario because in such a scenario you can have some optimizations. In regard to this, I think we should decide whether a bootstrapping mechanism integrated with network access authentication should be standardized. Regards, --Gerardo=20 > my 2 cents. >=20 > Vijay >=20 >=20 > Alper Yegin wrote: > > This is an attempt to enumerate possible MIP6-AAA=20 > frameworks, and start > > discussions on for which one(s) IETF shall pursue standardization.=20 > >=20 > > Framework 1: > > ------------ > > Using network access AAA to deliver MIP6 configuration=20 > parameters from > > the AAA server to the MN.=20 > >=20 > > MIP6 configuration is directly delivered from the AAA=20 > server to the MN > > during network access AAA, in-band with the authentication (e.g., > > transported by EAP or EAP methods). > >=20 > > Related I-Ds: > >=20 > > draft-giaretta-mip6-authorization-eap-01 > > draft-le-aaa-mipv6-requirements-03 > > draft-ohnishi-mip6-aaa-problem-statement-00 > >=20 > > Discussion: > >=20 > > The end2end transport between the AAA and the MN is the=20 > key. Use of EAP > > for this somewhat network access unrelated "configuration" is not > > recommended as far as I understand. One can design his own=20 > EAP method to > > do that, yet that would have limited applicability. > >=20 > >=20 > > Framework 2: > > ------------ > > Using network access AAA to deliver MIP6 configuration=20 > parameters from > > the AAA server to the NAS. It is assumed that parameters will be > > delivered from the NAS to the MN via another protocol=20 > (e.g., DHCP, PANA, > > etc.) > >=20 > > Related I-Ds: > >=20 > > draft-chowdhury-mip6-bootstrap-radius-00 > > draft-jang-dhc-haopt-00 > >=20 > > Discussion: > >=20 > > This is similar to NAS learning the IP address for the=20 > connected host > > via RADIUS, and delivering it to the host via DHCP. > >=20 > > James had a comment regarding not having to support intra-operator > > interoperability. I think regardless of the deployment,=20 > interoperability > > between vendors is the important. Also, I was not sure on=20 > the complexity > > argument. > >=20 > > 3GPP2 has already chosen this scheme. Some other SDO(s) may=20 > follow the > > suit. > >=20 > > Framework 3: > > ------------ > > Piggybacking MIP6 signaling (BU) with network access AAA.=20 > In-band with > > the network access authentication execution, the MN delivers > > (piggybacks) a BU to the AAA server. The AAA server may=20 > have to relay > > the BU to the HA (unless collocated). =20 > >=20 > > Related I-D: > >=20 > > draft-le-aaa-mipv6-requirements-03 > >=20 > > Discussion: > >=20 > > While the performance benefits are clear, limited applicability (not > > always the network access and mobility services are bundled) and > > complexity are concerning. > >=20 > >=20 > > Framework 4: > > ------------ > > A backend AAA protocol is executed between the HA and the=20 > AAA server in > > response to the MIP6 signaling between the MN and the HA.=20 > Similar to the > > use of AAA protocols with MIPv4 co-located care-of address case. > >=20 > > Related I-Ds: > >=20 > > draft-giaretta-mip6-aaa-ha-goals-00.txt > > draft-yegin-mip6-aaa-fwk-00.txt > >=20 > > Discussion: > > This one appears to be the most needed framework. It is=20 > assumed that MN > > already knows the HA address.=20 > >=20 > >=20 > > Are there other frameworks to add? > >=20 > > I am sure I have missed some references, please let us know=20 > which ones. > >=20 > > Alper > >=20 > >=20 > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 15:33:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02129 for ; Thu, 17 Feb 2005 15:33:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sgP-0006mB-5h for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 15:55:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qb0-0007d0-SU; Thu, 17 Feb 2005 13:41:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nuM-0007di-0b for mip6@megatron.ietf.org; Thu, 17 Feb 2005 10:49:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08958 for ; Thu, 17 Feb 2005 10:49:36 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1oFp-0007S0-7P for mip6@ietf.org; Thu, 17 Feb 2005 11:11:49 -0500 Received: from kolumbus.fi (p130 [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1DB6189883; Thu, 17 Feb 2005 17:49:00 +0200 (EET) Message-ID: <4214BC94.8050206@kolumbus.fi> Date: Thu, 17 Feb 2005 17:47:32 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mobile IPv6 Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Content-Transfer-Encoding: 7bit Cc: Bernard Aboba Subject: [Mip6] Icos BoF -- IP Configuration Security X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Content-Transfer-Encoding: 7bit For your information: we intend to arrange a BoF in the next IETF about the secure configuration needs at IP layer. This is an issue that has come up in several WGs, including MIP6 and DHC. The purpose of this one-time BoF is provide an additional forum where these needs can be discussed along with their architectural implications. Hopefully we can also learn a bit from others, about their problems and solutions. All actual work would, however, be still performed in the respective working groups. Mailing list has been set up; we'd appreciate your discussion about the issues. See below for a link to subscribe yourself. IP Configuration Security BoF Chairs: Bernard Aboba Jari Arkko Area Directors: Thomas Narten Margaret Wasserman Mailing list: https://www.machshav.com/mailman/listinfo.cgi/icos This BoF will provide an overview of secure Internet layer configuration needs, discussing the architectural issues, areas of applicability and potential solutions under discussion in different areas of the IETF. The purpose of the BoF is to discuss a common topic that touches several existing Working Groups, and it is not expected that a new working group will be formed as a result. The BoF will also not replace ongoing process in existing WGs, though it is hoped that the discussion gives additional insights to the participants to deal with these issues. The need for this BoF has came up in the context of expanding EAP usage, including the use of EAP for configuration in different IETF WGs. However, the BoF will discuss this issue from a general point of view, as the issue is not related to just a single protocol. Examples of specific issues in IP layer protocols are brought forward, however, as are examples of solutions in order make it easier to understand the concrete implications of the issues. Internet layer configuration is defined as the configuration required to support the operation at the Internet layer. This includes IP address configuration, default gateway(s), name server configuration, boot configuration (TFTP, NFS), service location and directory configuration, mobility configuration, and time server configuration (NTP). Configuration is typically performed insecurely today. For example, DHCP is rarely secured for a variety of reasons, even though a security mechanism has been defined in RFC 3118. In other cases, such as in Mobile IPv6, the use of security tools is mandatory in the protocols, but there are deployment barriers. As a result, Internet Area working groups are exploring alternative solutions. These include use of EAP for use for key derivation, and configuration. For example, the DHC WG has considered employment of EAP-derived keys for use with DHCP security, as defined in RFC 3118 and 3315. The MIPv6 WG, in investigating the bootstrapping problem, has considered proposals involving use of IKEv2 with EAP, as well as utilization of link layer EAP exchanges for configuration. IPv6 uses Router Advertisements for address autoconfiguration; however, a mechanism is needed to secure them. The SEND working group defined a zero-configuration mechanism for secure IP address configuration, based on Cryptographically Generated Addresses (CGAs). It also defined a certificate-based authorization for routers, where hosts can use a router that has a certificate traceable to a trusted root configured for the host. All these configuration tasks have delay constraints, because they typically need to be performed before a node that just moved can resume communications. Reading list: [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] Droms, R., Ed., Bound, J., Volz,, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Lefkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [RFC3818] Schryver, V., "IANA Considerations for Point-to-Point Protocol", RFC 3818, June 2004. [ANYCAST] Hagino, J., and K. Ettikan, "An Analysis of IPv6 Anycast", draft-ietf-ipngwg-ipv6-anycast-analysis-02.txt, Internet draft (work in progress), June 2003. [DHCPv4Threat] Hibbs, R., Smith, C., Volz, B., Zohar, M., "Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis", draft-ietf-dhc-v4-threat-analysis-02.txt, Internet draft (work in progress), April 2004. [DHCPv6Threat] Prigent, N., Marchand, J., Dupont, F., Cousin, B., Laurent- Maknavicius, M. and J. Bournelle, "DHCPv6 Threats", draft- prigent-dhcpv6-threats-00.txt, March 2001. [DNSConfv6] Jeong, J. (ed.), "IPv6 Host Configuration of DNS Server Information Approaches", draft-ietf-dnsop-ipv6-dns- configuration-04.txt, Internet draft (work in progress), September 2004. [EAP3118] Yegin, A., Tschofenig, H. and D. Forsberg, "Bootstrapping RFC 3118 Delayed DHCP AUthentication Using EAP-based Network Access Authentication", draft-yegin-eap-boot-rfc3118-01.txt, Internet draft (work in progress), January 2005. [EAPIKE] Tschofenig, H., Kroeselberg, D., Ohba, Y. and F. Bersani, "EAP IKEv2 Method (EAP-IKEv2)", draft-tschofenig-eap-ikev2-05.txt, Internet draft (work in progress), October 2004. [IKEv2] Kaufman, C., (ed.), "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17.txt, Internet draft (work in progress), September 2004. [IPCPMIPv6] Song, J., Chong, C. and D. Leigh, "MIPv6 IPCP configuration option for PPP IPv6CP", draft-song-pppext-mipv6-ppp- support-01.txt, Internet draft (work in progress), October 2001. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send- ndopt-06.txt, Internet draft (work in progress), January 2005. [SEND-CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", draft-ietf-send-cga-06.txt, Internet draft (work in progress), October 2004. [MIPv6-BOOT] A. Patel, "Problem Statement for bootstrapping Mobile IPv6, draft-ietf-mip6-bootstrap-ps-01.txt, Internet draft (work in progress), October 2004. [MIPv6-IKEv2] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-00.txt, Internet draft (work in progress), October 2004. [MIPv6-EAP] Giaretta, G., Guardini, I., Demaria, E., Bournelle, J., and M. Laurent-Maknavicius, "MIPv6 Authorization and Configuration based on EAP", draft-giaretta-mip6-authorization-eap-02.txt, Internet draft (work in progress), October 2004. [MIPv6-AAA] Yegin, A., "AAA Mobile IPv6 Application Framework", draft-yegin-mip6-aaa-fwk-00.txt, Internet draft (work in progress), August 2004. [MIPv6-BOOT2] J. Kempf, E. Nordmark, S. Chakrabarti, "Bootstrapping Mobile IPv6", draft-chakrabarti-mip6-bmip-00.txt, Internet draft (work in progress), December 2004. ---- IP Configuration Security BOF Agenda Time and Date: Monday, March 7, 2005, 1530-1730 (Tentative - have asked to be moved to Wed-Thu!) Preliminaries: (5 minutes) - Minute Takers - Bluesheets IP Configuration Security Problem, Bernard Aboba (10 minutes) http://www.drizzle.com/~aboba/IETF62/icos.ppt Why do we care, TBD (10 minutes) Credential Reuse, TBD (10 minutes) EAP and its Applicability, Bernard Aboba (15 minutes) http://www.drizzle.com/~aboba/IETF62/icos.ppt (To Be Provided) http://www.ietf.org/rfc/rfc3748.txt http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-04.txt Overview of The MIPv6 Bootstrap Problem, James Kempf (20 minutes) http://www.ietf.org/internet-drafts/draft-ietf-mipv6-bootstrap-ps-01.txt http://www.ietf.org/internet-drafts/draft-giaretta-mipv6-authorization-eap-02.txt http://www.ietf.org/internet-drafts/draft-chakrabarti-mip6-bmip-00.txt http://www.ietf.org/internet-drafts/draft-ietf-mipv6-ikev2-ipsec-00.txt (more documents in the reading list) Overview of DHCP Security, Mark Stapp/Ralph Droms (20 minutes) http://www.ietf.org/rfc/rfc3118.txt http://www.ietf.org/rfc/rfc3315.txt http://www.ietf.org/internet-drafts/draft-ietf-dhc-v4-threat-analysis-03.txt http://www.ietf.org/internet-drafts/draft-yegin-eap-boot-rfc3118-01.txt http://bgp.potaroo.net/ietf/all-ids/draft-ietf-dhc-auth-sigzero-00.txt http://www.drizzle.com/~aboba/IETF62/draft-stapp-dhc-eap-00.txt (To Be Provided) Overview of Secure Configuration in SEND, Jari Arkko (10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-send-cga-06.txt http://www.ietf.org/internet-drafts/draft-ietf-send-ndopt-06.txt Overview of Other IP Layer Needs, TBD (5 min) - Mobile IPv4 - PANA - IKEv2 Discussion and Wrapup (20 minutes) _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 16:00:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04699 for ; Thu, 17 Feb 2005 16:00:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1t6Y-0007dA-52 for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 16:22:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qnx-0000I9-Mj; Thu, 17 Feb 2005 13:55:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1olT-0008IY-1z for mip6@megatron.ietf.org; Thu, 17 Feb 2005 11:44:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20029 for ; Thu, 17 Feb 2005 11:44:29 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1p6u-0002UH-5D for mip6@ietf.org; Thu, 17 Feb 2005 12:06:43 -0500 Message-ID: <06ca01c51510$15c88510$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Junghoon Jee" , "Erik Nordmark" References: <004401c51409$928b96d0$6b70fe81@FlyToWorld><421393C7.8000704@sun.com> <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> Subject: Re: [Mip6] mip6-aaa frameworks Date: Thu, 17 Feb 2005 08:45:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Gerardo Giaretta , Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Junghoon, > Currently, my concern is about the integrity and replay protection for HA IP address. > Could we support this without requiring the security function in the pre-existing DNS servers ? > My answer is NO. > If my answer is correct, pre-existing DNS servers needs to be changed to support MIP6 bootstrapping. > I am not sure whethere this approach is right. > Replay protection is provided by the DNS protocol itself, integrity protection is provided by DNSSEC. No need to change the protocol. Please see RFC 2535 and RFC 1035. > BTW, i don't agree to open up the chance of revealing the HA IP address by putting this information > into the publicly available DNS server. Anyone can query the DNS server to get any other's HA address. > This increase the possibility of DoS attack. I know that this point is already mentioned in the bmip6 draft. > I am waiting their right solution for this. > But anyone can sign up for a subscription at a mobility service provider, get the address by EAPoL2 or even have it manually provisioned, then use the address to attack the HA. The only difference is that someone must take the time and effort to sign up for the subscription, but how much of a barrier is that? There are other ways of preventing against DoS attack on the HA that need to be deployed by a serious mobility service provider, a mobility service provider can't depend on bootstrapping being able to hide the address. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 16:01:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04834 for ; Thu, 17 Feb 2005 16:01:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1t89-0007ep-PS for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 16:24:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qoF-0000fG-Bc; Thu, 17 Feb 2005 13:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1oo1-0000cj-Jd for mip6@megatron.ietf.org; Thu, 17 Feb 2005 11:47:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20647 for ; Thu, 17 Feb 2005 11:47:07 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1p9V-0002ep-MH for mip6@ietf.org; Thu, 17 Feb 2005 12:09:22 -0500 Message-ID: <06df01c51510$774fddb0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> <02e601c51389$21dd84a0$016115ac@dcml.docomolabsusa.com> <4213F429.9060705@iprg.nokia.com> Subject: Re: [Mip6] mip6-aaa frameworks Date: Thu, 17 Feb 2005 08:48:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit > > so I don't see how DHCP would come into the picture. How > > are they planning on changing that for MIP6? Are they really planning on > > distributing the addresses of home agents between operators or just within a > > single operator? > > both. > > at the end of access network authentication, the HA address is delivered > to the PDSN (which is a NAS). the PDSN then sends the HA address to the > MN via DHCP. > > works pretty well and I happen to think that this is a good bootstrap > mechanism. > Sure, for 3GPP2 networks. The problem is that these are essentially telephone networks with a high degree of trust and co-ordination between operators. Not all networks in the Internet are like that. That's why I don't think this mechanism is such a good idea for the Internet in general. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 16:20:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06571 for ; Thu, 17 Feb 2005 16:20:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1tQB-0008Dj-7Q for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 16:42:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1r6G-0001j9-Mk; Thu, 17 Feb 2005 14:14:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1pSr-0005z1-Lw for mip6@megatron.ietf.org; Thu, 17 Feb 2005 12:29:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29763 for ; Thu, 17 Feb 2005 12:29:13 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1poF-0005c4-LE for mip6@ietf.org; Thu, 17 Feb 2005 12:51:28 -0500 Message-ID: <077c01c51516$58590520$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mayumi Yanagiya" , "Yoshihiro Ohba" References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> <4214978D.7080005@lab.ntt.co.jp> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Thu, 17 Feb 2005 09:30:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Content-Transfer-Encoding: 7bit Yanagiya-san, In addition to your classification, there is also Type 3 bootstrapping, in which AAA is not involved, such as is described in draft-chakrabarti-bmip. Alper's classification mixes backend AAA and bootstrapping AAA and so is different, this one is only for boostrapping AAA. Regarding the problem with DHCP, the issue is that not all IP networks will have the proper inter-domain network management integration and inter-network operator trust that 3GPP2 networks do (which use a NAS/DHCP interface). Without these, deployment of such an interface can lead to problems. For example, in the future, a mobile operator may decide to conclude a roaming agreement with a small wireless ISP that is not a traditional mobile telephony service provider for cost or coverage reasons, in order to provide roaming coverage for its users. Such an ISP may not have the resources necessary to support such an interface. jak ----- Original Message ----- From: "Mayumi Yanagiya" To: "Yoshihiro Ohba" Cc: "James Kempf" ; Sent: Thursday, February 17, 2005 5:09 AM Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt > Hi James, Ohba-san and all, > > Let me add new point of view for classification of framework. > (It does not mean that I disagree Alper's classification.) > > I think that framework can be divided into 2 main branches as follows. > Type1: bootstrapping procedure is executed between MN and AAA server. > Type2: bootstrapping procedure is executed between MN and network > elements such as HA, NAS and DHCP server. > Those network elements can use back end AAA server. > > In type 1, we assumed that MNs and AAA server communicate directly by > using authentication protocol such as EAP and network elements are not > required to understand MIP6 specific information. So, I don't think that > we are required to specify detailed interface between AAA and MN because > AAA in home network can assign configuration parameters in vendor > specific attribute. > > Local domain | Home domain > NE | AAA > | | > +--------------+ > | | > MN | > > In type2, we are required to specify interface. Because bootstrapping > messages may be treated by network elements in local domain and AAA > server in home network. > I don't understand why problems are caused only in DHCP case. > > Local domain | Home domain > NE-------------------->AAA > (DHCP, HA, NAS) | | > | | NE > | | | > MN- - - - - - - - - - - + > | > > Could you give me comments? > > Best Redards > --Mayumi > > > On Wed, Feb 16, 2005 at 01:19:42PM -0800, James Kempf wrote: > > > >>Yoshi, > >> > >> > >>>This seems to be a general problem that is common to any roaming > >>>scenario, not specific to MIP6 bootstrapping scenario. The IETF > >>>already defines a similar framework for Mobile IPv4 bootstrapping with > >>>having a MN-FA-AAA interface and I don't see a problem in general (in > >>>terms of complexity for roaming support) with replacing FA with > >>>NAS/DHCP in the case of Mobile IPv6 bootstrapping. > >>> > >> > >>Yes, but configuration is a different problem from network access/mobility > >>auth/authz.. The information distributed by any network access/mobility > >>roaming consists of a yes/no indication about whether someone can enter the > >>network, together with possibly a master key associated with that > >>permission. > >> > >>What your draft is talking about is distributing detailed configuration > >>about the topology and services in the home administrative domain. There is > >>much more that can go wrong in that case. > > > > > > So do you think that the existing solution for Mobile IPv4 > > bootstrapping is not a good solution to follow when defining a Mobile > > IPv6 bootstrapping solution? > > > > > >> > >>>>The other alternative is that the AAA-H itself communicates with the > >> > >>AAA-F > >> > >>>>to obtain the local HA address, then sends it back in the EAP reply. In > >> > >>that > >> > >>>>case, there is an additional round trip on the back end, but, again > >> > >>there > >> > >>>>would be no need for the IKEv2 transaction if the EAP is used to > >> > >>configure > >> > >>>>the IPsec SA. > >>> > >>>But both of these would need to push IKE credentials of the MN from > >>>the AAA server in the home domain to the local HA in the visited > >>>domain, to avoid the second EAP run. On the other hand, if we allow > >>>the delivery of IKE credentials to the local HA across administrative > >>>domains, I think we can certainly allow the framework of carrying a HA > >>>address to the local NAS/DHCP across administrative domains. > >>> > >> > >>The difference is that the delivery is end to end, between the MN and the > >>AAA-H with EAP. So the security can be end to end, between the home network > >>operator and the client. If the NAS is in the middle, as in your proposal, > >>there is a weak point where compromise of security, or network management > >>problems are more likely to occur. > > > > > > I don't understand the security threat because the HA address is > > somehow exposed to the operator of the visited domain when the MN > > sends a BU to the HA (I mentioned this several months ago). Also I > > don't understand the network management problems, because even in the > > end-to-end delivery model you mentioned above, some information such > > as IKEv2 credentials would need to be passed to the local HA in the > > visited domain from the home domain (it's not a pure end-to-end > > delivery in that sense) in order for the MN to perform IKEv2 with the > > local HA without running EAP over IKEv2. I really don't see a major > > difference between managing IKEv2 credentials and managing HA address > > across administrative domains. > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > > >> jak > >> > >> > > > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > -- > > *++++++++++++++++++++++++++++++++++++++++++ > NTT Network Service Systems Laboratories > Mayumi Yanagiya > tel: +81 422 59 6783 fax: +81 422 59 5631 > E-mail: yanagiya.mayumi@lab.ntt.co.jp > +++++++++++++++++++++++++++++++++++++++++++* > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 16:49:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09647 for ; Thu, 17 Feb 2005 16:49:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1trt-0000dm-IZ for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 17:11:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1rPL-0000es-Qb; Thu, 17 Feb 2005 14:33:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1q1N-0002Bc-0z for mip6@megatron.ietf.org; Thu, 17 Feb 2005 13:05:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09109 for ; Thu, 17 Feb 2005 13:04:58 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qMp-00006l-PY for mip6@ietf.org; Thu, 17 Feb 2005 13:27:14 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1HIYI617615; Thu, 17 Feb 2005 10:34:18 -0800 X-mProtect: <200502171834> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdqoSzzv; Thu, 17 Feb 2005 10:32:12 PST Message-ID: <4214DC0D.6030100@iprg.nokia.com> Date: Thu, 17 Feb 2005 10:01:49 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] mip6-aaa frameworks References: <11d201c51329$c83d61e0$291d9069@sisa.samsung.com> <02e601c51389$21dd84a0$016115ac@dcml.docomolabsusa.com> <4213F429.9060705@iprg.nokia.com> <06df01c51510$774fddb0$016115ac@dcml.docomolabsusa.com> In-Reply-To: <06df01c51510$774fddb0$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: Alper Yegin , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit James Kempf wrote: >>>so I don't see how DHCP would come into the picture. How >>>are they planning on changing that for MIP6? Are they really planning on >>>distributing the addresses of home agents between operators or just > > within a > >>>single operator? >> >>both. >> >>at the end of access network authentication, the HA address is delivered >>to the PDSN (which is a NAS). the PDSN then sends the HA address to the >>MN via DHCP. >> >>works pretty well and I happen to think that this is a good bootstrap >>mechanism. >> > > > Sure, for 3GPP2 networks. okay. it appeared to me that you were saying the mechanism used by 3GPP2 is a bad idea. > The problem is that these are essentially telephone networks with a high > degree of trust and co-ordination between operators. Not all networks in the > Internet are like that. That's why I don't think this mechanism is such a > good idea for the Internet in general. sure. it just needs to be evaluated along with other mechanisms. I have always maintained that it is not possible to come with one bootstrap mechanism that will work in all deployments and scenarios. Vijay _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 16:57:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11536 for ; Thu, 17 Feb 2005 16:57:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1u09-0001C9-S7 for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 17:20:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1rsF-0000FG-MP; Thu, 17 Feb 2005 15:03:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qG7-0007ar-5y for mip6@megatron.ietf.org; Thu, 17 Feb 2005 13:20:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13060 for ; Thu, 17 Feb 2005 13:20:12 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qbb-0001G9-2O for mip6@ietf.org; Thu, 17 Feb 2005 13:42:28 -0500 Message-ID: <07c701c5151d$779649a0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yoshihiro Ohba" References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Thu, 17 Feb 2005 10:21:07 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Yoshi, > So do you think that the existing solution for Mobile IPv4 > bootstrapping is not a good solution to follow when defining a Mobile > IPv6 bootstrapping solution? > Removing the foreign agent from MIP6 makes the protocol architecturally cleaner. It strengthens the end-to-end relationship between the home agent and mobile node. This is an advantage from a network management and security standpoint, because it reduces the possibility of failure in the middle. Re-introducing the foreign agent as a NAS that does DHCP will decrease the reliability in general (though for specific cases like telephony-style networks such as 3GPP2, it may work). It's the standard end-to-end argument, see Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End Arguments in System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288. > > The difference is that the delivery is end to end, between the MN and the > > AAA-H with EAP. So the security can be end to end, between the home network > > operator and the client. If the NAS is in the middle, as in your proposal, > > there is a weak point where compromise of security, or network management > > problems are more likely to occur. > > I don't understand the security threat because the HA address is > somehow exposed to the operator of the visited domain when the MN > sends a BU to the HA (I mentioned this several months ago). Also I > don't understand the network management problems, because even in the > end-to-end delivery model you mentioned above, some information such > as IKEv2 credentials would need to be passed to the local HA in the > visited domain from the home domain (it's not a pure end-to-end > delivery in that sense) in order for the MN to perform IKEv2 with the > local HA without running EAP over IKEv2. I really don't see a major > difference between managing IKEv2 credentials and managing HA address > across administrative domains. > Regarding dynamic/local HA to AAA-H v.s. NAS/DHCP to AAA-H, the security problems of securing the AAA flows between the AAA-H and the network entity in the local network (local HA or NAS/DHCP server) are similar. Local HA should not be enabled unless the roaming network operator and home network operator trust each other. The difference between security credentials and addresses is that the verification of the security credentials during an IKEv2 exchange (provided EAPoIKEv2 is used with the local HA) lies squarely in the home network. Thus, once again, there is an end-to-end transaction between the MN and AAA-H in which the local HA merely acts as a routing intermediary. There is no transfer of sensitive credentials between the home network and the foreign network. With addresses, the home network is depending on the foreign network NAS to properly handle the addresses. It's just another point where compromise or failure is possible, even if, in general, the two operators trust each other. The fewer network entities involved, the less possibility for failure. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 16:58:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12024 for ; Thu, 17 Feb 2005 16:58:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1u1L-0001Kf-4f for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 17:21:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1s0S-0002Av-VJ; Thu, 17 Feb 2005 15:12:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qOv-0002Fm-G4 for mip6@megatron.ietf.org; Thu, 17 Feb 2005 13:29:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15272 for ; Thu, 17 Feb 2005 13:29:18 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1qkO-0001tP-7H for mip6@ietf.org; Thu, 17 Feb 2005 13:51:34 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id AA6238000B0 for ; Thu, 17 Feb 2005 20:28:45 +0200 (EET) Date: Thu, 17 Feb 2005 20:28:45 +0200 (EET) From: Wassim Haddad To: mip6@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/Mixed; BOUNDARY=NextPart Content-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Mip6] I-D ACTION:draft-haddad-momipriv-problem-statement-01.txt (fwd) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --NextPart Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Hi, A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Privacy for Mobile and Multi-homed Nodes: MoMiPriv Problem Statement Author(s) : W. Haddad, et al. Filename : draft-haddad-momipriv-problem-statement-01.txt Pages : 15 Date : 2005-2-16 This memo describes the privacy in mobility and multi-homing problem statement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haddad-momipriv-problem-statement-01.txt Comments are appreciated. Regards, Wassim H. --NextPart Content-Type: MULTIPART/ALTERNATIVE; BOUNDARY=OtherAccess Content-ID: Content-Description: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; ACCESS-TYPE=mail-server; SERVER="mailserv@ietf.org" Content-ID: --OtherAccess Content-Type: MESSAGE/EXTERNAL-BODY; NAME="draft-haddad-momipriv-problem-statement-01.txt"; SITE="ftp.ietf.org"; ACCESS-TYPE=anon-ftp; DIRECTORY=internet-drafts Content-ID: --OtherAccess-- --NextPart Content-Type: TEXT/PLAIN; CHARSET=us-ascii Content-ID: Content-Description: Content-Disposition: INLINE _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Thu Feb 17 17:14:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14833 for ; Thu, 17 Feb 2005 17:14:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uGJ-0002AR-96 for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 17:36:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tf6-00032Z-21; Thu, 17 Feb 2005 16:58:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ryJ-0001Ck-Hp for mip6@megatron.ietf.org; Thu, 17 Feb 2005 15:10:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28660 for ; Thu, 17 Feb 2005 15:09:54 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sJj-0005zH-Pa for mip6@ietf.org; Thu, 17 Feb 2005 15:32:10 -0500 Message-ID: <081c01c5152c$c123a450$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , "Gopal Dommety" References: <4.3.2.7.2.20050215120213.026355d0@mira-sjc5-d.cisco.com> <008401c5140c$0e1f9100$6b70fe81@FlyToWorld> Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt (ProblemStatement for bootstrapping Mobile IPv6 ) Date: Thu, 17 Feb 2005 12:10:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Here's my nonsecurity related comments on this draft. Overall: I think the draft is sound in general, and I like the separation between mobility and access service provider. I believe this distinction is clearly made. Less clear is the distinction between the access network service provider and home network service provider, in the traditional wireless sense. I think this needs to be clarified in order for this document to clearly lay out the problem of roaming, in the traditional wireless sense, and I think that might be what is leading to some of the confusion on the list. I'll provide some suggestions for improvement below. 1) Section 1.3 There are some terms that are used throughout the draft that are not well defined. For example, trust relationship. I'd suggest adding the following definitions to this section: trust relationship - In the context of this draft, trust relationship means that two parties in question, typically the user of the mobile host and the mobility or access service provider, have some sort of prior contact in which the mobile host was provisioned with credentials. These credentials allow the mobile host to authenticate itself to the mobility or access service provider and to prove its authorization to obtain service. infrastructureless relationship - In the context of this draft, an infrastructureless relationship is one in which the user of the mobile host and the mobility or access service provider have no previous contact and the mobile host is not required to supply credentials to authenticate and prove authorization for service. Mobility and/or network access service is provided without any authentication or authorization. Infrastructureless in this context does not mean that there is no network infrastructure, such as would be the case for an ad hoc network. credentials - Data or mechanism used by a mobile host to authenticate itself to a mobility or access network service provider and prove authorization to receive service. User name/passwords, one time password cards, public/private key pairs with certificates, biometric information, etc. are some examples. I also think some of the terms need modification. Here are those I would suggest modifying: ASA Access Service Authorizer. A network operator that authenticates a mobile host and establishes the mobile host's authorization to receive Internet service. ASP Access Service Provider. A network operator that provides direct IP packet forwarding to and from the end host. Serving Network Access Provider. A network operator that is the mobile host's ASP but not its ASA. The roaming network accesss provider may or may not additionally provide mobility service. Home Network Access Provider. A network operator that is both the mobile host's ASP and ASA. The home network access provider may or may not additionally provide mobility service (note that this is a slighlty different definition from RFC 3775). IASP Integrated Access Service Provider. A service provider that provides both authorization for network access and also provides mobility service. MSA Mobility Service Authorizer. A service provider that authorizes Mobile IPv6 service. MSP Mobility Service Provider. A service provider that provides Mobile IPv6 service. In order to obtain such service, the mobile host must be authenticated and prove authorization to obtain the service. Home Mobility Service Provider. A MSP that both provides mobility service and authorizes it. Serving Mobility Service Provider. A MSP that provides mobility service but depends on another service provider to authorize it. Roaming When the mobile host is receiving network access service from a network other than its home network, it is said to be roaming. 2) Section 6 needs to be modified to more clearly define roaming, using the terminology defined above. I would suggest rewriting paragraph 3 as follows: If the mobile host is within the geographical area in which network access service is not provided by its home network access service provider, the mobile host is roaming. The home network access service provider in this case acts as the access service authorizer, but the actual network access is provided by the serving network access provider. During the authentication and authorization prior to the mobile host having Internet access, the serving network access provider may simply act as a routing agent for authentication and authorization back to the access service authorizer, or it may require an additional authentication and authorization step itself. An example of a roaming situation is when a business person is using a hotspot service in an airport, and the hotspot service provider has a roaming agreement with the business person's cellular provider. In that case, the hotspot network is acting as the serving network access provider, while the cellular network is acting as the access service authorizer. When the business person moves from the hotspot network to the cellular network, the cellular network is both the home access service provider and the access service authorizer. Also, I think paragraph 5 would benefit from the following change: Mobility service using Mobile IPv6 is conceptually and possibly also in practice separate from network access service, though of course network access is required prior to providing mobility. Mobile IPv6 service enables an IPv6 host to maintain its reachability despite changing its network attachment point (subnets). A network operator providing Mobile IPv6 service is called a mobility service provider (MSP). Granting Mobile IPv6 service requires a host to authenticate and prove authorization for the service. A network operator that authenticates a mobile host and authorizes mobility service is called a mobility service authorizer. If both types of operation are performed by the same operator, that operator is called a home mobility service provider. If authentication and authorization is provided by one operator and the actual service is provider by another, the operator providing the service is called the serving mobility service provider. The serving MSP must contact the mobile host's mobility service authorizer to check the mobile host's authorization prior to granting mobility service. Finally, I think that paragraph 8 needs modification. Here's a suggested change: The service model defined here clearly separates the entity providing the service from the entity that authentications and authorizes the service. In the case of basic network access, this supports the traditional and well-known roaming model, in which inter-operator roaming agreements allow a host to obtain network access in areas where their home network access provider does not have coverage. In the case of mobility service, this allows a roaming mobile host to obtain mobility service in the local operator's network while having that service authorized by the home operator. The service model also allows mobility service and network access service to be provided by different entities. This allows a network operator with no wireless access, like, for example, an enterprise network operator, to deploy a Mobile IPv6 home agent for mobility service while the actual wireless network access is provided by the serving network access providers with which the enterprise operator has a contract. Here are some other possible combinations of ASPs and MSPs: I would drop paragraphs 4, 6, and 7, since they talk about mechanisms rather than the service model, and this section is really about the service model. The bullet list after paragraph 8 and paragraph 9 both look OK. I'll send comments on Section 9 in a separate message. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 19:09:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28587 for ; Thu, 17 Feb 2005 19:09:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1w3h-0005Ys-Oj for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 19:31:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1vOP-0006vQ-MQ; Thu, 17 Feb 2005 18:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1v0e-0004vL-5p for mip6@megatron.ietf.org; Thu, 17 Feb 2005 18:24:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23374 for ; Thu, 17 Feb 2005 18:24:30 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1vM8-0004Eu-TU for mip6@ietf.org; Thu, 17 Feb 2005 18:46:49 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j1HNOLHr007565; Fri, 18 Feb 2005 08:24:21 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j1HNOLEb009453; Fri, 18 Feb 2005 08:24:21 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id JAA09451 ; Fri, 18 Feb 2005 08:24:21 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j1HNOLLG012016; Fri, 18 Feb 2005 08:24:21 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1HNOKmn018692; Fri, 18 Feb 2005 08:24:20 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1HNOK8a008104; Fri, 18 Feb 2005 08:24:20 +0900 (JST) Received: from steelhead (iVPN01-038.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IC200BHJX0HA8@tsbpo1.po.toshiba.co.jp>; Fri, 18 Feb 2005 08:24:17 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1D1uNT-0007gz-00; Thu, 17 Feb 2005 14:44:07 -0800 Date: Thu, 17 Feb 2005 17:44:07 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <07c701c5151d$779649a0$016115ac@dcml.docomolabsusa.com> To: James Kempf Message-id: <20050217224407.GA29145@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> <07c701c5151d$779649a0$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f James, On Thu, Feb 17, 2005 at 10:21:07AM -0800, James Kempf wrote: > Yoshi, > > > So do you think that the existing solution for Mobile IPv4 > > bootstrapping is not a good solution to follow when defining a Mobile > > IPv6 bootstrapping solution? > > > > Removing the foreign agent from MIP6 makes the protocol architecturally > cleaner. It strengthens the end-to-end relationship between the home agent > and mobile node. This is an advantage from a network management and security > standpoint, because it reduces the possibility of failure in the middle. > Re-introducing the foreign agent as a NAS that does DHCP will decrease the > reliability in general (though for specific cases like telephony-style > networks such as 3GPP2, it may work). It's the standard end-to-end argument, > see Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End Arguments in > System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288. I agree that the bootstrapping model defined in 3GPP2 is good for well-managed networks. An advantage of the 3GPP2 model is that the model uses the existing building block protocols (i.e., EAP, EAP methods, DHCP, PANA, IEEE 802.1X) without modification as much as possible. A downside is that it introduces an addtitional middle box (NAS/DHCP server), which is transparent in other bootstrapping framework, to carry the bootstrapping parameters. > > > > > The difference is that the delivery is end to end, between the MN and > the > > > AAA-H with EAP. So the security can be end to end, between the home > network > > > operator and the client. If the NAS is in the middle, as in your > proposal, > > > there is a weak point where compromise of security, or network > management > > > problems are more likely to occur. > > > > I don't understand the security threat because the HA address is > > somehow exposed to the operator of the visited domain when the MN > > sends a BU to the HA (I mentioned this several months ago). Also I > > don't understand the network management problems, because even in the > > end-to-end delivery model you mentioned above, some information such > > as IKEv2 credentials would need to be passed to the local HA in the > > visited domain from the home domain (it's not a pure end-to-end > > delivery in that sense) in order for the MN to perform IKEv2 with the > > local HA without running EAP over IKEv2. I really don't see a major > > difference between managing IKEv2 credentials and managing HA address > > across administrative domains. > > > > Regarding dynamic/local HA to AAA-H v.s. NAS/DHCP to AAA-H, the security > problems of securing the AAA flows between the AAA-H and the network entity > in the local network (local HA or NAS/DHCP server) are similar. Local HA > should not be enabled unless the roaming network operator and home network > operator trust each other. I agree with you on this. > The difference between security credentials and > addresses is that the verification of the security credentials during an > IKEv2 exchange (provided EAPoIKEv2 is used with the local HA) lies squarely > in the home network. Thus, once again, there is an end-to-end transaction > between the MN and AAA-H in which the local HA merely acts as a routing > intermediary. There is no transfer of sensitive credentials between the home > network and the foreign network. That is true provided EAPoIKEv2 is used with the local HA, as you mentioned above. But if IKEv2 is used with the local HA but without EAP (I mean the case in which there is no 2nd EAP), still there is transfer of sensitive credentials across administrative domains and I don't see a major difference as I mentioned in the previous mail. > With addresses, the home network is > depending on the foreign network NAS to properly handle the addresses. It's > just another point where compromise or failure is possible, even if, in > general, the two operators trust each other. The fewer network entities > involved, the less possibility for failure. Again, if IKEv2 is used with the local HA but without EAP, the local HA still involves in the bootstrapping transaction and the number of involved network entities for maintain the IKE credentials across domains (three -- MN, local HA and AAA server) are the same as that is needed for maintain HA address across domains (three - MN, NAS(*) and AAA server). So I'd say that even if we use EAP for carrying bootstrapping parameters, local HA support without 2nd EAP does not follow the end-to-end model, and thus is recommended only for well-managed networks. I hope I am doing the right analysis here. (*) The number of the entities for the latter case can be four when NAS and local DHCP server are physically separate devices. Regerds, Yoshihiro Ohba > > jak > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 20:13:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05526 for ; Thu, 17 Feb 2005 20:13:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1x3N-0007eQ-4l for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 20:35:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1wUB-0005PV-OF; Thu, 17 Feb 2005 19:59:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1wGi-0007yi-FJ for mip6@megatron.ietf.org; Thu, 17 Feb 2005 19:45:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02094 for ; Thu, 17 Feb 2005 19:45:13 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1wcE-0006bj-Ht for mip6@ietf.org; Thu, 17 Feb 2005 20:07:33 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC300E010QHE6@mailout3.samsung.com> for mip6@ietf.org; Fri, 18 Feb 2005 09:44:41 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC300KWP0QG72@mailout3.samsung.com> for mip6@ietf.org; Fri, 18 Feb 2005 09:44:41 +0900 (KST) Received: from Alperyegin ([105.253.155.40]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IC300LEK0QE9O@mmp2.samsung.com> for mip6@ietf.org; Fri, 18 Feb 2005 09:44:40 +0900 (KST) Date: Thu, 17 Feb 2005 16:44:35 -0800 From: Alper Yegin To: mip6@ietf.org Message-id: <1c5601c51553$063cbd80$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7BIT Subject: [Mip6] mip6-aaa frameworks (updated) X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7BIT I have added new references. If I missed any, let me know. Framework 1: ------------ Using network access AAA to deliver MIP6 configuration parameters from the AAA server to the MN. MIP6 configuration is directly delivered from the AAA server to the MN during network access AAA, in-band with the authentication (e.g., transported by EAP or EAP methods). Related I-Ds: draft-giaretta-mip6-authorization-eap-01 draft-le-aaa-mipv6-requirements-03 draft-ohnishi-mip6-aaa-problem-statement-00 Discussion: The end2end transport between the AAA and the MN is the key. Use of EAP for this somewhat network access unrelated "configuration" is not recommended as far as I understand. One can design his own EAP method to do that, yet that would have limited applicability. Framework 2: ------------ Using network access AAA to deliver MIP6 configuration parameters from the AAA server to the NAS. It is assumed that parameters will be delivered from the NAS to the MN via another protocol (e.g., DHCP, PANA, etc.) Related I-Ds: draft-chowdhury-mip6-bootstrap-radius-00 (home to visited domain protocol) draft-jang-dhc-haopt-00 (visited domain to MN protocol) draft-ohba-mip6-boot-arch-dhcp-00.txt (visited domain to MN protocol) draft-jee-mip6-bootstrap-pana-00.txt (visited domain to MN protocol) Discussion: This is similar to NAS learning the IP address for the connected host via RADIUS, and delivering it to the host via DHCP. James had a comment regarding not having to support intra-operator interoperability. I think regardless of the deployment, interoperability between vendors is the important. Also, I was not sure on the complexity argument. 3GPP2 has already chosen this scheme. Some other SDO(s) may follow the suit. Framework 3: ------------ Piggybacking MIP6 signaling (BU) with network access AAA. In-band with the network access authentication execution, the MN delivers (piggybacks) a BU to the AAA server. The AAA server may have to relay the BU to the HA (unless collocated). Related I-D: draft-le-aaa-mipv6-requirements-03 Discussion: While the performance benefits are clear, limited applicability (not always the network access and mobility services are bundled) and complexity are concerning. Framework 4: ------------ A backend AAA protocol is executed between the HA and the AAA server in response to the MIP6 signaling between the MN and the HA. Similar to the use of AAA protocols with MIPv4 co-located care-of address case. Related I-Ds: draft-giaretta-mip6-aaa-ha-goals-00.txt draft-yegin-mip6-aaa-fwk-00.txt draft-chakrabati-mip6-bmip-00.txt (delivers HA via DNS; relies on fwk4) draft-bournelle-pana-mip6-00 (delivers local HA, HoA from NAS; relies on fwk4) draft-tschofenig-mip6-bootstrapping-pana-00.txt (runs PANA to HA; relies on fwk4) draft-jee-mip6-bootstrap-pana-00.txt (relies on fwk4) Discussion: This one appears to be the most needed framework. It is assumed that MN already knows the HA address. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 20:28:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07107 for ; Thu, 17 Feb 2005 20:28:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1xII-00084s-5t for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 20:50:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1wmy-00076O-Vq; Thu, 17 Feb 2005 20:18:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1wfc-0003Dk-HQ for mip6@megatron.ietf.org; Thu, 17 Feb 2005 20:11:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05185 for ; Thu, 17 Feb 2005 20:10:57 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1x1A-0007Xd-MU for mip6@ietf.org; Thu, 17 Feb 2005 20:33:17 -0500 Message-ID: <087b01c51550$b3fd8330$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yoshihiro Ohba" References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> <07c701c5151d$779649a0$016115ac@dcml.docomolabsusa.com> <20050217224407.GA29145@steelhead> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Thu, 17 Feb 2005 16:27:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Yoshi, I would not expect a home operator to transfer the mobility service credentials for a user to a dynamically assigned home agent in the foreign operator's network. Standard IP network access roaming doesn't do this and I would not expect it to be done for mobility service roaming either. For one thing, if Radius is used, the credentials won't be encrypted end to end unless the two operators take special precautions, so there is the possibility of compromise if the Radius traffic is routed through an intermediary. If the two operators want to avoid having the mobile host require an EAP round trip back to the home network during the IKEv2 exchange through the dynamically assigned home agent, the home operator can provision the host with a certificate and the dynamically assigned home agent can check the certificate to see if the host is authorized for mobility service instead of using EAP (better anyway, but the PKI overhead may not be for everyone). I know that base 3GPP authentication architecture transfers the authentication vector from the HLR to the VLR (without any authentication or encryption on the SS7 transport believe), I don't know if 3GPP2 does this, but I would expect so since the HLR/VLR architecture is the same. The security of this is questionable at best, and I think we need to do much better in the IETF mobility service architecture. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: "James Kempf" Cc: "Yoshihiro Ohba" ; Sent: Thursday, February 17, 2005 2:44 PM Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt > James, > > On Thu, Feb 17, 2005 at 10:21:07AM -0800, James Kempf wrote: > > Yoshi, > > > > > So do you think that the existing solution for Mobile IPv4 > > > bootstrapping is not a good solution to follow when defining a Mobile > > > IPv6 bootstrapping solution? > > > > > > > Removing the foreign agent from MIP6 makes the protocol architecturally > > cleaner. It strengthens the end-to-end relationship between the home agent > > and mobile node. This is an advantage from a network management and security > > standpoint, because it reduces the possibility of failure in the middle. > > Re-introducing the foreign agent as a NAS that does DHCP will decrease the > > reliability in general (though for specific cases like telephony-style > > networks such as 3GPP2, it may work). It's the standard end-to-end argument, > > see Saltzer, J.H., Reed, D.P., and Clark, D.D., "End-to-End Arguments in > > System Design," ACM TOCS, Vol 2, Number 4, November 1984, pp 277-288. > > I agree that the bootstrapping model defined in 3GPP2 is good for > well-managed networks. An advantage of the 3GPP2 model is that the > model uses the existing building block protocols (i.e., EAP, EAP > methods, DHCP, PANA, IEEE 802.1X) without modification as much as > possible. A downside is that it introduces an addtitional middle box > (NAS/DHCP server), which is transparent in other bootstrapping > framework, to carry the bootstrapping parameters. > > > > > > > > > The difference is that the delivery is end to end, between the MN and > > the > > > > AAA-H with EAP. So the security can be end to end, between the home > > network > > > > operator and the client. If the NAS is in the middle, as in your > > proposal, > > > > there is a weak point where compromise of security, or network > > management > > > > problems are more likely to occur. > > > > > > I don't understand the security threat because the HA address is > > > somehow exposed to the operator of the visited domain when the MN > > > sends a BU to the HA (I mentioned this several months ago). Also I > > > don't understand the network management problems, because even in the > > > end-to-end delivery model you mentioned above, some information such > > > as IKEv2 credentials would need to be passed to the local HA in the > > > visited domain from the home domain (it's not a pure end-to-end > > > delivery in that sense) in order for the MN to perform IKEv2 with the > > > local HA without running EAP over IKEv2. I really don't see a major > > > difference between managing IKEv2 credentials and managing HA address > > > across administrative domains. > > > > > > > Regarding dynamic/local HA to AAA-H v.s. NAS/DHCP to AAA-H, the security > > problems of securing the AAA flows between the AAA-H and the network entity > > in the local network (local HA or NAS/DHCP server) are similar. Local HA > > should not be enabled unless the roaming network operator and home network > > operator trust each other. > > I agree with you on this. > > > The difference between security credentials and > > addresses is that the verification of the security credentials during an > > IKEv2 exchange (provided EAPoIKEv2 is used with the local HA) lies squarely > > in the home network. Thus, once again, there is an end-to-end transaction > > between the MN and AAA-H in which the local HA merely acts as a routing > > intermediary. There is no transfer of sensitive credentials between the home > > network and the foreign network. > > That is true provided EAPoIKEv2 is used with the local HA, as you > mentioned above. But if IKEv2 is used with the local HA but without > EAP (I mean the case in which there is no 2nd EAP), still there is > transfer of sensitive credentials across administrative domains and I > don't see a major difference as I mentioned in the previous mail. > > > With addresses, the home network is > > depending on the foreign network NAS to properly handle the addresses. It's > > just another point where compromise or failure is possible, even if, in > > general, the two operators trust each other. The fewer network entities > > involved, the less possibility for failure. > > Again, if IKEv2 is used with the local HA but without EAP, the local > HA still involves in the bootstrapping transaction and the number of > involved network entities for maintain the IKE credentials across > domains (three -- MN, local HA and AAA server) are the same as that is > needed for maintain HA address across domains (three - MN, NAS(*) and > AAA server). So I'd say that even if we use EAP for carrying > bootstrapping parameters, local HA support without 2nd EAP does not > follow the end-to-end model, and thus is recommended only for > well-managed networks. I hope I am doing the right analysis here. > > (*) The number of the entities for the latter case can be four when > NAS and local DHCP server are physically separate devices. > > Regerds, > > Yoshihiro Ohba > > > > > > jak > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 21:03:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10516 for ; Thu, 17 Feb 2005 21:03:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1xq4-0000WP-Nt for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 21:25:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xQo-0007zM-V9; Thu, 17 Feb 2005 20:59:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xGJ-0003Tv-OR for mip6@megatron.ietf.org; Thu, 17 Feb 2005 20:48:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09099 for ; Thu, 17 Feb 2005 20:48:54 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1xbq-00009e-Il for mip6@ietf.org; Thu, 17 Feb 2005 21:11:13 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC3000013OKFT@mailout3.samsung.com> for mip6@ietf.org; Fri, 18 Feb 2005 10:48:20 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC300EVH3OK4J@mailout3.samsung.com> for mip6@ietf.org; Fri, 18 Feb 2005 10:48:20 +0900 (KST) Received: from Alperyegin ([105.253.155.40]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0IC3002IF3OH99@mmp2.samsung.com> for mip6@ietf.org; Fri, 18 Feb 2005 10:48:20 +0900 (KST) Date: Thu, 17 Feb 2005 17:48:14 -0800 From: Alper Yegin To: mip6@ietf.org Message-id: <1c5701c5155b$ea9e0940$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7BIT Subject: [Mip6] MIP6 bootstrapping solution sets X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7BIT As I have said before, MIP6-AAA framework discussion is highly related to MIP6 bootstrapping problem space, but they are not the same things. Not all MIP6-AAA frameworks can solve the bootstrapping problem single handedly (e.g., fwk4 relies on MN knowing its HA); and things like accounting has nothing to do with bootstrapping. MN learning its HA or home addresses, generating a dynamic SA with its HA using a AAA process are the overlaps between the two subjects. Let's also note that it is not likely we'd come up with a single solution that solves the problem in any deployment scenarios. We are likely to come up with multiple solutions, each possibly consisting of more than one component. Having said these, here is an attempt to capture solution sets. A set has to generate all of the HA, HoA, and MN-HA SA parameters. Please provide additions and modifications. I'm likely to have missed some. HA discovery HoA discovery MN-HA SA generation ------------ ------------- ------------------- (a) - via DNS - IKEv2 - MIP6-AAA Fwk 4 - RFC3775 (anycast) - mip6-mn-ident-option (b) - PANA/DHCP with NAS, - PANA/DHCP - MIP6-AAA Fwk 4 coupled with - IKEv2 - PANA/DHCP + MIP6-AAA MIP6-AAA Fwk 2 - mip6-mn-ident-option Fwk 2 (for MN); MIP6-AAA Fwk 4 (for HA) (c) - MIP6-AAA Fwk 1 - MIP6-AAA Fwk 1 - MIP6-AAA Fwk 1(for MN); - IKEv2 MIP6-AAA Fwk 4(for HA) - mip6-mn-ident-option In a set (e.g., a, b, or c), any one of the alternatives listed under one column can be used with others under the other columns. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 21:53:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15072 for ; Thu, 17 Feb 2005 21:53:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ycV-0001k2-Vy for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 22:15:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1y29-0001q4-Ry; Thu, 17 Feb 2005 21:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1xvm-0006s2-Ge for mip6@megatron.ietf.org; Thu, 17 Feb 2005 21:31:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13171 for ; Thu, 17 Feb 2005 21:31:45 -0500 (EST) Received: from mail.flarion.com ([63.103.94.23] helo=ftmailgfi1.flariontech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1yHM-0001Ca-5A for mip6@ietf.org; Thu, 17 Feb 2005 21:54:04 -0500 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi1.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 17 Feb 2005 21:31:11 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] mip6-aaa frameworks Date: Thu, 17 Feb 2005 21:31:11 -0500 Message-ID: Thread-Topic: [Mip6] mip6-aaa frameworks Thread-Index: AcUTKlYUyy6//4G3T4+YXGZg07J/AQCNyL5Q From: "Soliman, Hesham" To: "Alper Yegin" , X-OriginalArrivalTime: 18 Feb 2005 02:31:11.0613 (UTC) FILETIME=[E910CAD0:01C51561] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: quoted-printable I'm trying to catch up with this thread. I think fwk 4 is the best alternative for us to pursue and makes most sense since AAA is basically used to authenticate BUs. There is also a precedence for this in 3GPP IMS. On some level though, this will depend on the EAP method used. Hesham > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org]On=20 > Behalf Of > Alper Yegin > Sent: Tuesday, February 15, 2005 1:44 AM > To: mip6@ietf.org > Subject: [Mip6] mip6-aaa frameworks >=20 >=20 >=20 > This is an attempt to enumerate possible MIP6-AAA=20 > frameworks, and start > discussions on for which one(s) IETF shall pursue standardization.=20 >=20 > Framework 1: > ------------ > Using network access AAA to deliver MIP6 configuration=20 > parameters from > the AAA server to the MN.=20 >=20 > MIP6 configuration is directly delivered from the AAA server=20 > to the MN > during network access AAA, in-band with the authentication (e.g., > transported by EAP or EAP methods). >=20 > Related I-Ds: >=20 > draft-giaretta-mip6-authorization-eap-01 > draft-le-aaa-mipv6-requirements-03 > draft-ohnishi-mip6-aaa-problem-statement-00 >=20 > Discussion: >=20 > The end2end transport between the AAA and the MN is the key.=20 > Use of EAP > for this somewhat network access unrelated "configuration" is not > recommended as far as I understand. One can design his own=20 > EAP method to > do that, yet that would have limited applicability. >=20 >=20 > Framework 2: > ------------ > Using network access AAA to deliver MIP6 configuration=20 > parameters from > the AAA server to the NAS. It is assumed that parameters will be > delivered from the NAS to the MN via another protocol (e.g.,=20 > DHCP, PANA, > etc.) >=20 > Related I-Ds: >=20 > draft-chowdhury-mip6-bootstrap-radius-00 > draft-jang-dhc-haopt-00 >=20 > Discussion: >=20 > This is similar to NAS learning the IP address for the connected host > via RADIUS, and delivering it to the host via DHCP. >=20 > James had a comment regarding not having to support intra-operator > interoperability. I think regardless of the deployment,=20 > interoperability > between vendors is the important. Also, I was not sure on=20 > the complexity > argument. >=20 > 3GPP2 has already chosen this scheme. Some other SDO(s) may=20 > follow the > suit. >=20 > Framework 3: > ------------ > Piggybacking MIP6 signaling (BU) with network access AAA.=20 > In-band with > the network access authentication execution, the MN delivers > (piggybacks) a BU to the AAA server. The AAA server may have to relay > the BU to the HA (unless collocated). =20 >=20 > Related I-D: >=20 > draft-le-aaa-mipv6-requirements-03 >=20 > Discussion: >=20 > While the performance benefits are clear, limited applicability (not > always the network access and mobility services are bundled) and > complexity are concerning. >=20 >=20 > Framework 4: > ------------ > A backend AAA protocol is executed between the HA and the=20 > AAA server in > response to the MIP6 signaling between the MN and the HA.=20 > Similar to the > use of AAA protocols with MIPv4 co-located care-of address case. >=20 > Related I-Ds: >=20 > draft-giaretta-mip6-aaa-ha-goals-00.txt > draft-yegin-mip6-aaa-fwk-00.txt >=20 > Discussion: > This one appears to be the most needed framework. It is=20 > assumed that MN > already knows the HA address.=20 >=20 >=20 > Are there other frameworks to add? >=20 > I am sure I have missed some references, please let us know=20 > which ones. >=20 > Alper >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=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 This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 23:20:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22350 for ; Thu, 17 Feb 2005 23:20:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1zyq-0003jV-Q3 for mip6-web-archive@ietf.org; Thu, 17 Feb 2005 23:43:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1zZi-0002Xq-0P; Thu, 17 Feb 2005 23:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1zTY-00084c-PW for mip6@megatron.ietf.org; Thu, 17 Feb 2005 23:10:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21505 for ; Thu, 17 Feb 2005 23:10:42 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1zp8-0003VN-1x for mip6@ietf.org; Thu, 17 Feb 2005 23:33:03 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1I4A2On006258; Fri, 18 Feb 2005 13:10:02 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1I4A1Ld020379; Fri, 18 Feb 2005 13:10:01 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1I4A1ER020375; Fri, 18 Feb 2005 13:10:01 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1I4A1DH002647; Fri, 18 Feb 2005 13:10:01 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1I4A06r002641; Fri, 18 Feb 2005 13:10:00 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1I4A0bL004130; Fri, 18 Feb 2005 13:10:00 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1I49xub000480; Fri, 18 Feb 2005 13:10:00 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1I49x1U000475; Fri, 18 Feb 2005 13:09:59 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id NAA09276; Fri, 18 Feb 2005 13:09:59 +0900 (JST) Message-ID: <42156B0E.20703@lab.ntt.co.jp> Date: Fri, 18 Feb 2005 13:11:58 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> <4214978D.7080005@lab.ntt.co.jp> <077c01c51516$58590520$016115ac@dcml.docomolabsusa.com> In-Reply-To: <077c01c51516$58590520$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id j1I4A2On006258 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32029c790f79bd4a84a26bd2915c54b9 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Content-Transfer-Encoding: quoted-printable Hi James, Thank you for your reply. > In addition to your classification, there is also Type 3=20 bootstrapping, in > which AAA is not involved, such as is described in=20 draft-chakrabarti-bmip. > Alper's classification mixes backend AAA and bootstrapping AAA and so = is > different, this one is only for boostrapping AAA. I agree that there are solutions that don=92t rely on AAA. But, can I focus on the solutions which are relied on AAA in order to=20 simplify discussion? > Regarding the problem with DHCP, the issue is that not all IP=20 networks will > have the proper inter-domain network management integration and > inter-network operator trust that 3GPP2 networks do (which use a NAS/D= HCP > interface). Without these, deployment of such an interface can lead to > problems. For example, in the future, a mobile operator may decide to > conclude a roaming agreement with a small wireless ISP that is not a > traditional mobile telephony service provider for cost or coverage=20 reasons, > in order to provide roaming coverage for its users. Such an ISP may=20 not have > the resources necessary to support such an interface. I agree that problems will be occurred when network providers don=92t=20 have agreement. But I can=92t understand why the problems will be occurre= d=20 only in DHCP case. For example, in IKEv2 based solution, - if MN is assigned home agent in home network, HA aren=92t required inter-domain interface. - if MN assign home agent in local network, home agent will be required inter-domain interface to get some information such as IKE credential. I think that same problems will be occurred if there is no agreement=20 between home network and local network. Is my opinion wrong? --Mayumi > jak > > > ----- Original Message ----- > From: "Mayumi Yanagiya" > To: "Yoshihiro Ohba" > Cc: "James Kempf" ; > Sent: Thursday, February 17, 2005 5:09 AM > Subject: Re: [Mip6] Consensus call:=20 draft-giaretta-mip6-aaa-ha-goals-00.txt > > > >>Hi James, Ohba-san and all, >> >>Let me add new point of view for classification of framework. >>(It does not mean that I disagree Alper's classification.) >> >>I think that framework can be divided into 2 main branches as follows. >> Type1: bootstrapping procedure is executed between MN and AAA server. >> Type2: bootstrapping procedure is executed between MN and network >> elements such as HA, NAS and DHCP server. >> Those network elements can use back end AAA server. >> >>In type 1, we assumed that MNs and AAA server communicate directly by >>using authentication protocol such as EAP and network elements are not >>required to understand MIP6 specific information. So, I don't think th= at >>we are required to specify detailed interface between AAA and MN becau= se >>AAA in home network can assign configuration parameters in vendor >>specific attribute. >> >> Local domain | Home domain >> NE | AAA >> | | >> +--------------+ >> | | >> MN | >> >>In type2, we are required to specify interface. Because bootstrapping >>messages may be treated by network elements in local domain and AAA >>server in home network. >>I don't understand why problems are caused only in DHCP case. >> >> Local domain | Home domain >> NE-------------------->AAA >> (DHCP, HA, NAS) | | >> | | NE >> | | | >> MN- - - - - - - - - - - + >> | >> >>Could you give me comments? >> >>Best Redards >>--Mayumi >> >> >>>On Wed, Feb 16, 2005 at 01:19:42PM -0800, James Kempf wrote: >>> >>> >>>>Yoshi, >>>> >>>> >>>> >>>>>This seems to be a general problem that is common to any roaming >>>>>scenario, not specific to MIP6 bootstrapping scenario. The IETF >>>>>already defines a similar framework for Mobile IPv4 bootstrapping w= ith >>>>>having a MN-FA-AAA interface and I don't see a problem in general (= in >>>>>terms of complexity for roaming support) with replacing FA with >>>>>NAS/DHCP in the case of Mobile IPv6 bootstrapping. >>>>> >>>> >>>>Yes, but configuration is a different problem from network > > access/mobility > >>>>auth/authz.. The information distributed by any network access/mobil= ity >>>>roaming consists of a yes/no indication about whether someone can en= ter > > the > >>>>network, together with possibly a master key associated with that >>>>permission. >>>> >>>>What your draft is talking about is distributing detailed configurat= ion >>>>about the topology and services in the home administrative domain.=20 There > > is > >>>>much more that can go wrong in that case. >>> >>> >>>So do you think that the existing solution for Mobile IPv4 >>>bootstrapping is not a good solution to follow when defining a Mobile >>>IPv6 bootstrapping solution? >>> >>> >>> >>>>>>The other alternative is that the AAA-H itself communicates with t= he >>>> >>>>AAA-F >>>> >>>> >>>>>>to obtain the local HA address, then sends it back in the EAP repl= y. > > In > >>>>that >>>> >>>> >>>>>>case, there is an additional round trip on the back end, but, agai= n >>>> >>>>there >>>> >>>> >>>>>>would be no need for the IKEv2 transaction if the EAP is used to >>>> >>>>configure >>>> >>>> >>>>>>the IPsec SA. >>>>> >>>>>But both of these would need to push IKE credentials of the MN from >>>>>the AAA server in the home domain to the local HA in the visited >>>>>domain, to avoid the second EAP run. On the other hand, if we allo= w >>>>>the delivery of IKE credentials to the local HA across administrati= ve >>>>>domains, I think we can certainly allow the framework of carrying a= HA >>>>>address to the local NAS/DHCP across administrative domains. >>>>> >>>> >>>>The difference is that the delivery is end to end, between the MN an= d > > the > >>>>AAA-H with EAP. So the security can be end to end, between the home > > network > >>>>operator and the client. If the NAS is in the middle, as in your > > proposal, > >>>>there is a weak point where compromise of security, or network > > management > >>>>problems are more likely to occur. >>> >>> >>>I don't understand the security threat because the HA address is >>>somehow exposed to the operator of the visited domain when the MN >>>sends a BU to the HA (I mentioned this several months ago). Also I >>>don't understand the network management problems, because even in the >>>end-to-end delivery model you mentioned above, some information such >>>as IKEv2 credentials would need to be passed to the local HA in the >>>visited domain from the home domain (it's not a pure end-to-end >>>delivery in that sense) in order for the MN to perform IKEv2 with the >>>local HA without running EAP over IKEv2. I really don't see a major >>>difference between managing IKEv2 credentials and managing HA address >>>across administrative domains. >>> >>>Regards, >>> >>>Yoshihiro Ohba >>> >>> >>> >>> >>> >>>> jak >>>> >>>> >>> >>> >>>_______________________________________________ >>>Mip6 mailing list >>>Mip6@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mip6 >>> >> >>-- >> _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 17 23:47:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24882 for ; Thu, 17 Feb 2005 23:47:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D20Ot-0004WA-6r for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 00:09:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1zyX-0006H5-Qt; Thu, 17 Feb 2005 23:42:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1zvr-0004pJ-La for mip6@megatron.ietf.org; Thu, 17 Feb 2005 23:39:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24170 for ; Thu, 17 Feb 2005 23:39:57 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D20HR-0004Lp-NG for mip6@ietf.org; Fri, 18 Feb 2005 00:02:18 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Feb 2005 13:40:13 +0900 Message-ID: <005601c51573$dd4de860$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: "James Kempf" , , "Gopal Dommety" References: <4.3.2.7.2.20050215120213.026355d0@mira-sjc5-d.cisco.com><008401c5140c$0e1f9100$6b70fe81@FlyToWorld> <081c01c5152c$c123a450$016115ac@dcml.docomolabsusa.com> Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt(ProblemStatement for bootstrapping Mobile IPv6 ) Date: Fri, 18 Feb 2005 13:39:42 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 18 Feb 2005 04:40:13.0892 (UTC) FILETIME=[EFD2D040:01C51573] X-Spam-Score: 2.2 (++) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0195883860==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 --===============0195883860== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gSmFtZXMgYW5kIEFMTC4NCkl0J3MgdmVyeSBjb29sLg0KUGxlYXNlIHNlZSBteSBjb21t ZW50cyBpbmxpbmUuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiSmFt ZXMgS2VtcGYiIDxrZW1wZkBkb2NvbW9sYWJzLXVzYS5jb20+DQpUbzogPG1pcDZAaWV0Zi5vcmc+ OyAiR29wYWwgRG9tbWV0eSIgPGdkb21tZXR5QGNpc2NvLmNvbT4NClNlbnQ6IEZyaWRheSwgRmVi cnVhcnkgMTgsIDIwMDUgNToxMCBBTQ0KU3ViamVjdDogUmU6IFtNaXA2XSBXRyBMQzogSS1EIGRy YWZ0LWlldGYtbWlwNi1ib290c3RyYXAtcHMtMDEudHh0KFByb2JsZW1TdGF0ZW1lbnQgZm9yIGJv b3RzdHJhcHBpbmcgTW9iaWxlIElQdjYgKQ0KDQoNCj4gDQo+IEhlcmUncyBteSBub25zZWN1cml0 eSByZWxhdGVkIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQuDQo+IA0KPiBPdmVyYWxsOiBJIHRoaW5r IHRoZSBkcmFmdCBpcyBzb3VuZCBpbiBnZW5lcmFsLCBhbmQgSSBsaWtlIHRoZSBzZXBhcmF0aW9u DQo+IGJldHdlZW4gbW9iaWxpdHkgYW5kIGFjY2VzcyBzZXJ2aWNlIHByb3ZpZGVyLiBJIGJlbGll dmUgdGhpcyBkaXN0aW5jdGlvbiBpcw0KPiBjbGVhcmx5IG1hZGUuIExlc3MgY2xlYXIgaXMgdGhl IGRpc3RpbmN0aW9uIGJldHdlZW4gdGhlIGFjY2VzcyBuZXR3b3JrDQo+IHNlcnZpY2UgcHJvdmlk ZXIgYW5kIGhvbWUgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVyLCBpbiB0aGUgdHJhZGl0aW9uYWwN Cj4gd2lyZWxlc3Mgc2Vuc2UuIEkgdGhpbmsgdGhpcyBuZWVkcyB0byBiZSBjbGFyaWZpZWQgaW4g b3JkZXIgZm9yIHRoaXMNCj4gZG9jdW1lbnQgdG8gY2xlYXJseSBsYXkgb3V0IHRoZSBwcm9ibGVt IG9mIHJvYW1pbmcsIGluIHRoZSB0cmFkaXRpb25hbA0KPiB3aXJlbGVzcyBzZW5zZSwgYW5kIEkg dGhpbmsgdGhhdCBtaWdodCBiZSB3aGF0IGlzIGxlYWRpbmcgdG8gc29tZSBvZiB0aGUNCj4gY29u ZnVzaW9uIG9uIHRoZSBsaXN0LiBJJ2xsIHByb3ZpZGUgc29tZSBzdWdnZXN0aW9ucyBmb3IgaW1w cm92ZW1lbnQgYmVsb3cuDQo+IA0KPiAxKSBTZWN0aW9uIDEuMw0KPiANCj4gVGhlcmUgYXJlIHNv bWUgdGVybXMgdGhhdCBhcmUgdXNlZCB0aHJvdWdob3V0IHRoZSBkcmFmdCB0aGF0IGFyZSBub3Qg d2VsbA0KPiBkZWZpbmVkLiBGb3IgZXhhbXBsZSwgdHJ1c3QgcmVsYXRpb25zaGlwLiBJJ2Qgc3Vn Z2VzdCBhZGRpbmcgdGhlIGZvbGxvd2luZw0KPiBkZWZpbml0aW9ucyB0byB0aGlzIHNlY3Rpb246 DQo+IA0KPiB0cnVzdCByZWxhdGlvbnNoaXAgLSBJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRyYWZ0 LCB0cnVzdCByZWxhdGlvbnNoaXAgbWVhbnMNCj4gdGhhdCB0d28gcGFydGllcyBpbiBxdWVzdGlv biwgdHlwaWNhbGx5IHRoZSB1c2VyIG9mIHRoZSBtb2JpbGUgaG9zdCBhbmQgdGhlDQo+IG1vYmls aXR5IG9yIGFjY2VzcyBzZXJ2aWNlIHByb3ZpZGVyLCBoYXZlIHNvbWUgc29ydCBvZiBwcmlvciBj b250YWN0IGluDQo+IHdoaWNoIHRoZSBtb2JpbGUgaG9zdCB3YXMgcHJvdmlzaW9uZWQgd2l0aCBj cmVkZW50aWFscy4gDQoNCj4gVGhlc2UgY3JlZGVudGlhbHMgYWxsb3cgdGhlIG1vYmlsZSBob3N0 IHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYgdG8gdGhlIG1vYmlsaXR5IG9yIGFjY2Vzcw0KPiBzZXJ2 aWNlIHByb3ZpZGVyIGFuZCB0byBwcm92ZSBpdHMgYXV0aG9yaXphdGlvbiB0byBvYnRhaW4gc2Vy dmljZS4NCg0KSSB3b3VsZCBsaWtlIHRvIGNoYW5nZSBsaWtlIGJlbG93IGlmIG15IHVuZGVyc3Rh bmRpbmcgb2YgeW91ciB0ZXJtaW5vbG9neSBpcyBjb3JyZWN0Lg0KIlRoZXNlIGNyZWRlbnRpYWxz IGFsbG93IHRoZSBtb2JpbGUgaG9zdCB0byBhdXRoZW50aWNhdGUgaXRzZWxmIHRvIHRoZSBtb2Jp bGl0eSBvciBhY2Nlc3MNCnNlcnZpY2UgLS1hdXRob3JpemVyLS0gYW5kIHRvIHByb3ZlIGl0cyBh dXRob3JpemF0aW9uIHRvIG9idGFpbiBzZXJ2aWNlIg0KDQo+IGluZnJhc3RydWN0dXJlbGVzcyBy ZWxhdGlvbnNoaXAgLSBJbiB0aGUgY29udGV4dCBvZiB0aGlzIGRyYWZ0LCBhbg0KPiBpbmZyYXN0 cnVjdHVyZWxlc3MgcmVsYXRpb25zaGlwIGlzIG9uZSBpbiB3aGljaCB0aGUgdXNlciBvZiB0aGUg bW9iaWxlIGhvc3QNCj4gYW5kIHRoZSBtb2JpbGl0eSBvciBhY2Nlc3Mgc2VydmljZSBwcm92aWRl ciBoYXZlIG5vIHByZXZpb3VzIGNvbnRhY3QgYW5kIHRoZQ0KPiBtb2JpbGUgaG9zdCBpcyBub3Qg cmVxdWlyZWQgdG8gc3VwcGx5IGNyZWRlbnRpYWxzIHRvIGF1dGhlbnRpY2F0ZSBhbmQgcHJvdmUN Cj4gYXV0aG9yaXphdGlvbiBmb3Igc2VydmljZS4gDQoNCj4gTW9iaWxpdHkgYW5kL29yIG5ldHdv cmsgYWNjZXNzIHNlcnZpY2UgaXMgcHJvdmlkZWQgd2l0aG91dCBhbnkgYXV0aGVudGljYXRpb24g b3IgYXV0aG9yaXphdGlvbi4gDQo+IEluZnJhc3RydWN0dXJlbGVzcyBpbiB0aGlzIGNvbnRleHQg ZG9lcyBub3QgbWVhbiB0aGF0IHRoZXJlIGlzIG5vIG5ldHdvcmsgaW5mcmFzdHJ1Y3R1cmUsIHN1 Y2ggYXMNCj4gd291bGQgYmUgdGhlIGNhc2UgZm9yIGFuIGFkIGhvYyBuZXR3b3JrLg0KDQpUaGUg bm90YWJsZSBwb2ludCBvZiB0aGUgYWJvdmUgcGhyYXNlIGlzIHRoZSB1c2Ugb2YgIk1vYmlsaXR5 IGFuZC9vciBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlIiBub3QNCiJNb2JpbGl0eSBhbmQvb3IgbmV0 d29yayBhY2Nlc3MgYXV0aG9yaXplciIuDQpJIGxpa2UgdGhpcyBzbyBtdWNoLiBJdCdzIHZlcnkg Y2xlYXIuDQpJIGhvcGUgdG8gc2VlIHRoaXMgZGVmaW5pdGlvbiBpbiB0aGUgbmV4dCB2ZXJzaW9u IG9mIHRoaXMgSS1ELg0KDQo+IGNyZWRlbnRpYWxzIC0gRGF0YSBvciBtZWNoYW5pc20gdXNlZCBi eSBhIG1vYmlsZSBob3N0IHRvIGF1dGhlbnRpY2F0ZSBpdHNlbGYNCj4gdG8gYSBtb2JpbGl0eSBv ciBhY2Nlc3MgbmV0d29yayBzZXJ2aWNlIHByb3ZpZGVyIGFuZCBwcm92ZSBhdXRob3JpemF0aW9u IHRvDQo+IHJlY2VpdmUgc2VydmljZS4gVXNlciBuYW1lL3Bhc3N3b3Jkcywgb25lIHRpbWUgcGFz c3dvcmQgY2FyZHMsDQo+IHB1YmxpYy9wcml2YXRlIGtleSBwYWlycyB3aXRoIGNlcnRpZmljYXRl cywgYmlvbWV0cmljIGluZm9ybWF0aW9uLCBldGMuIGFyZQ0KPiBzb21lIGV4YW1wbGVzLg0KPiAN Cj4gSSBhbHNvIHRoaW5rIHNvbWUgb2YgdGhlIHRlcm1zIG5lZWQgbW9kaWZpY2F0aW9uLiAgSGVy ZSBhcmUgdGhvc2UgSSB3b3VsZA0KPiBzdWdnZXN0IG1vZGlmeWluZzoNCj4gDQo+IEFTQQ0KPiAg ICAgQWNjZXNzIFNlcnZpY2UgQXV0aG9yaXplci4gQSBuZXR3b3JrIG9wZXJhdG9yIHRoYXQgYXV0 aGVudGljYXRlcyBhDQo+IG1vYmlsZSBob3N0IGFuZCBlc3RhYmxpc2hlcyB0aGUgbW9iaWxlIGhv c3QncyBhdXRob3JpemF0aW9uIHRvIHJlY2VpdmUNCj4gSW50ZXJuZXQgc2VydmljZS4NCj4gDQo+ IEFTUA0KPiAgICAgQWNjZXNzIFNlcnZpY2UgUHJvdmlkZXIuIEEgbmV0d29yayBvcGVyYXRvciB0 aGF0IHByb3ZpZGVzIGRpcmVjdCBJUA0KPiBwYWNrZXQgZm9yd2FyZGluZyB0byBhbmQgZnJvbSB0 aGUgZW5kIGhvc3QuDQo+IA0KPiBTZXJ2aW5nIE5ldHdvcmsgQWNjZXNzIFByb3ZpZGVyLg0KPiAg ICAgQSBuZXR3b3JrIG9wZXJhdG9yIHRoYXQgaXMgdGhlIG1vYmlsZSBob3N0J3MgQVNQIGJ1dCBu b3QgaXRzIEFTQS4gVGhlDQo+IHJvYW1pbmcgbmV0d29yayBhY2Nlc3NzIHByb3ZpZGVyIG1heSBv ciBtYXkgbm90IGFkZGl0aW9uYWxseSBwcm92aWRlDQo+IG1vYmlsaXR5IHNlcnZpY2UuDQoNCldo YXQgYWJvdXQgY2hhbmdpbmcgdGhlICJTZXJ2aW5nIE5ldHdvcmsgQWNjZXNzIFByb3ZpZGVyIiB0 byAiUm9hbWluZyBOZXR3b3JrIEFjY2VzcyBQcm92aWRlciIgPw0KVGhpcyBpcyBub3Qgc2lnbmlm aWNhbnQsIGl0J3MganVzdCBhIGNob2ljZS4NCg0KPiBIb21lIE5ldHdvcmsgQWNjZXNzIFByb3Zp ZGVyLg0KPiAgICAgQSBuZXR3b3JrIG9wZXJhdG9yIHRoYXQgaXMgYm90aCB0aGUgbW9iaWxlIGhv c3QncyBBU1AgYW5kIEFTQS4gVGhlIGhvbWUNCj4gbmV0d29yayBhY2Nlc3MgcHJvdmlkZXIgbWF5 IG9yIG1heSBub3QgYWRkaXRpb25hbGx5IHByb3ZpZGUgbW9iaWxpdHkgc2VydmljZQ0KPiAobm90 ZSB0aGF0IHRoaXMgaXMgYSBzbGlnaGx0eSBkaWZmZXJlbnQgZGVmaW5pdGlvbiBmcm9tIFJGQyAz Nzc1KS4NCj4gDQo+IElBU1ANCj4gICAgIEludGVncmF0ZWQgQWNjZXNzIFNlcnZpY2UgUHJvdmlk ZXIuIEEgc2VydmljZSBwcm92aWRlciB0aGF0IHByb3ZpZGVzDQo+IGJvdGggYXV0aG9yaXphdGlv biBmb3IgbmV0d29yayBhY2Nlc3MgYW5kIGFsc28gcHJvdmlkZXMgbW9iaWxpdHkgc2VydmljZS4N Cj4gDQo+IE1TQQ0KPiAgICAgTW9iaWxpdHkgU2VydmljZSBBdXRob3JpemVyLiBBIHNlcnZpY2Ug cHJvdmlkZXIgdGhhdCBhdXRob3JpemVzIE1vYmlsZQ0KPiBJUHY2IHNlcnZpY2UuDQo+IA0KPiBN U1ANCj4gICAgIE1vYmlsaXR5IFNlcnZpY2UgUHJvdmlkZXIuIEEgc2VydmljZSBwcm92aWRlciB0 aGF0IHByb3ZpZGVzIE1vYmlsZSBJUHY2DQo+IHNlcnZpY2UuIEluIG9yZGVyIHRvIG9idGFpbiBz dWNoIHNlcnZpY2UsIHRoZSBtb2JpbGUgaG9zdCBtdXN0IGJlDQo+IGF1dGhlbnRpY2F0ZWQgYW5k IHByb3ZlIGF1dGhvcml6YXRpb24gdG8gb2J0YWluIHRoZSBzZXJ2aWNlLg0KPiANCj4gSG9tZSBN b2JpbGl0eSBTZXJ2aWNlIFByb3ZpZGVyLg0KPiAgICAgQSBNU1AgdGhhdCBib3RoIHByb3ZpZGVz IG1vYmlsaXR5IHNlcnZpY2UgYW5kIGF1dGhvcml6ZXMgaXQuDQo+IA0KPiBTZXJ2aW5nIE1vYmls aXR5IFNlcnZpY2UgUHJvdmlkZXIuDQo+ICAgICBBIE1TUCB0aGF0IHByb3ZpZGVzIG1vYmlsaXR5 IHNlcnZpY2UgYnV0IGRlcGVuZHMgb24gYW5vdGhlciBzZXJ2aWNlDQo+IHByb3ZpZGVyIHRvIGF1 dGhvcml6ZSBpdC4NCg0KV2hhdCBhYm91dCBjaGFuZ2luZyB0aGUgIlNlcnZpbmcgTW9iaWxpdHkg U2VydmljZSBQcm92aWRlciIgdG8gIlJvYW1pbmcgTW9iaWxpdHkgU2VydmljZSBQcm92aWRlciIg Pw0KDQo+IFJvYW1pbmcNCj4gICAgIFdoZW4gdGhlIG1vYmlsZSBob3N0IGlzIHJlY2VpdmluZyBu ZXR3b3JrIGFjY2VzcyBzZXJ2aWNlIGZyb20gYSBuZXR3b3JrDQo+IG90aGVyIHRoYW4gaXRzIGhv bWUgbmV0d29yaywgaXQgaXMgc2FpZCB0byBiZSByb2FtaW5nLg0KPiANCj4gMikgIFNlY3Rpb24g NiBuZWVkcyB0byBiZSBtb2RpZmllZCB0byBtb3JlIGNsZWFybHkgZGVmaW5lIHJvYW1pbmcsIHVz aW5nIHRoZQ0KPiB0ZXJtaW5vbG9neSBkZWZpbmVkIGFib3ZlLiBJIHdvdWxkIHN1Z2dlc3QgcmV3 cml0aW5nIHBhcmFncmFwaCAzIGFzIGZvbGxvd3M6DQo+IA0KPiBJZiB0aGUgbW9iaWxlIGhvc3Qg aXMgd2l0aGluIHRoZSBnZW9ncmFwaGljYWwgYXJlYSBpbiB3aGljaCBuZXR3b3JrIGFjY2Vzcw0K PiBzZXJ2aWNlIGlzIG5vdCBwcm92aWRlZCBieSBpdHMgaG9tZSBuZXR3b3JrIGFjY2VzcyBzZXJ2 aWNlIHByb3ZpZGVyLCB0aGUNCj4gbW9iaWxlIGhvc3QgaXMgcm9hbWluZy4gVGhlIGhvbWUgbmV0 d29yayBhY2Nlc3Mgc2VydmljZSBwcm92aWRlciBpbiB0aGlzDQo+IGNhc2UgYWN0cyBhcyB0aGUg YWNjZXNzIHNlcnZpY2UgYXV0aG9yaXplciwgYnV0IHRoZSBhY3R1YWwgbmV0d29yayBhY2Nlc3Mg aXMNCj4gcHJvdmlkZWQgYnkgdGhlIHNlcnZpbmcgbmV0d29yayBhY2Nlc3MgcHJvdmlkZXIuIER1 cmluZyB0aGUgYXV0aGVudGljYXRpb24NCj4gYW5kIGF1dGhvcml6YXRpb24gcHJpb3IgdG8gdGhl IG1vYmlsZSBob3N0IGhhdmluZyBJbnRlcm5ldCBhY2Nlc3MsIHRoZQ0KPiBzZXJ2aW5nIG5ldHdv cmsgYWNjZXNzIHByb3ZpZGVyIG1heSBzaW1wbHkgYWN0IGFzIGEgcm91dGluZyBhZ2VudCBmb3IN Cj4gYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6YXRpb24gYmFjayB0byB0aGUgYWNjZXNzIHNl cnZpY2UgYXV0aG9yaXplciwgb3INCj4gaXQgbWF5IHJlcXVpcmUgYW4gYWRkaXRpb25hbCBhdXRo ZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBzdGVwIGl0c2VsZi4NCj4gQW4gZXhhbXBsZSBv ZiBhIHJvYW1pbmcgc2l0dWF0aW9uIGlzIHdoZW4gYSBidXNpbmVzcyBwZXJzb24gaXMgdXNpbmcg YQ0KPiBob3RzcG90IHNlcnZpY2UgaW4gYW4gYWlycG9ydCwgYW5kIHRoZSBob3RzcG90IHNlcnZp Y2UgcHJvdmlkZXIgaGFzIGENCj4gcm9hbWluZyBhZ3JlZW1lbnQgd2l0aCB0aGUgYnVzaW5lc3Mg cGVyc29uJ3MgY2VsbHVsYXIgcHJvdmlkZXIuIEluIHRoYXQNCj4gY2FzZSwgdGhlIGhvdHNwb3Qg bmV0d29yayBpcyBhY3RpbmcgYXMgdGhlIHNlcnZpbmcgbmV0d29yayBhY2Nlc3MgcHJvdmlkZXIs DQo+IHdoaWxlIHRoZSBjZWxsdWxhciBuZXR3b3JrIGlzIGFjdGluZyBhcyB0aGUgYWNjZXNzIHNl cnZpY2UgYXV0aG9yaXplci4gV2hlbg0KPiB0aGUgYnVzaW5lc3MgcGVyc29uIG1vdmVzIGZyb20g dGhlIGhvdHNwb3QgbmV0d29yayB0byB0aGUgY2VsbHVsYXIgbmV0d29yaywNCj4gdGhlIGNlbGx1 bGFyIG5ldHdvcmsgaXMgYm90aCB0aGUgaG9tZSBhY2Nlc3Mgc2VydmljZSBwcm92aWRlciBhbmQg dGhlIGFjY2Vzcw0KPiBzZXJ2aWNlIGF1dGhvcml6ZXIuDQoNClllcyBpdCdzIGNsZWFyLg0KDQo+ IEFsc28sIEkgdGhpbmsgcGFyYWdyYXBoIDUgd291bGQgYmVuZWZpdCBmcm9tIHRoZSBmb2xsb3dp bmcgY2hhbmdlOg0KPiANCj4gTW9iaWxpdHkgc2VydmljZSB1c2luZyBNb2JpbGUgSVB2NiBpcyBj b25jZXB0dWFsbHkgYW5kIHBvc3NpYmx5IGFsc28gaW4NCj4gcHJhY3RpY2Ugc2VwYXJhdGUgZnJv bSBuZXR3b3JrIGFjY2VzcyBzZXJ2aWNlLCB0aG91Z2ggb2YgY291cnNlIG5ldHdvcmsNCj4gYWNj ZXNzIGlzIHJlcXVpcmVkIHByaW9yIHRvIHByb3ZpZGluZyBtb2JpbGl0eS4gTW9iaWxlIElQdjYg c2VydmljZSBlbmFibGVzDQo+IGFuIElQdjYgaG9zdCB0byBtYWludGFpbiBpdHMgcmVhY2hhYmls aXR5IGRlc3BpdGUgY2hhbmdpbmcgaXRzIG5ldHdvcmsNCj4gYXR0YWNobWVudCBwb2ludCAoc3Vi bmV0cykuIEEgbmV0d29yayBvcGVyYXRvciBwcm92aWRpbmcgTW9iaWxlIElQdjYgc2VydmljZQ0K PiBpcyBjYWxsZWQgYSBtb2JpbGl0eSBzZXJ2aWNlIHByb3ZpZGVyIChNU1ApLiBHcmFudGluZyBN b2JpbGUgSVB2NiBzZXJ2aWNlDQo+IHJlcXVpcmVzIGEgaG9zdCB0byBhdXRoZW50aWNhdGUgYW5k IHByb3ZlIGF1dGhvcml6YXRpb24gZm9yIHRoZSBzZXJ2aWNlLiBBDQo+IG5ldHdvcmsgb3BlcmF0 b3IgdGhhdCBhdXRoZW50aWNhdGVzIGEgbW9iaWxlIGhvc3QgYW5kIGF1dGhvcml6ZXMgbW9iaWxp dHkNCj4gc2VydmljZSBpcyBjYWxsZWQgYSBtb2JpbGl0eSBzZXJ2aWNlIGF1dGhvcml6ZXIuIElm IGJvdGggdHlwZXMgb2Ygb3BlcmF0aW9uDQo+IGFyZSBwZXJmb3JtZWQgYnkgdGhlIHNhbWUgb3Bl cmF0b3IsIHRoYXQgb3BlcmF0b3IgaXMgY2FsbGVkIGEgaG9tZSBtb2JpbGl0eQ0KPiBzZXJ2aWNl IHByb3ZpZGVyLiBJZiBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBpcyBwcm92aWRl ZCBieSBvbmUNCj4gb3BlcmF0b3IgYW5kIHRoZSBhY3R1YWwgc2VydmljZSBpcyBwcm92aWRlciBi eSBhbm90aGVyLCB0aGUgb3BlcmF0b3INCj4gcHJvdmlkaW5nIHRoZSBzZXJ2aWNlIGlzIGNhbGxl ZCB0aGUgc2VydmluZyBtb2JpbGl0eSBzZXJ2aWNlIHByb3ZpZGVyLiBUaGUNCj4gc2VydmluZyBN U1AgbXVzdCBjb250YWN0IHRoZSBtb2JpbGUgaG9zdCdzIG1vYmlsaXR5IHNlcnZpY2UgYXV0aG9y aXplciB0bw0KPiBjaGVjayB0aGUgbW9iaWxlIGhvc3QncyBhdXRob3JpemF0aW9uIHByaW9yIHRv IGdyYW50aW5nIG1vYmlsaXR5IHNlcnZpY2UuDQoNCkkgbGlrZSB0aGlzIHdheSwgaWYgeW91IGFn cmVlIHdpdGggdGhlIGNoYW5nZSBvZiB0aGUgdGVybWlub2xvZ3kuDQoiSWYgYXV0aGVudGljYXRp b24gYW5kIGF1dGhvcml6YXRpb24gaXMgcHJvdmlkZWQgYnkgb25lIG9wZXJhdG9yIGFuZCB0aGUg YWN0dWFsIHNlcnZpY2UgaXMgcHJvdmlkZXIgYnkgYW5vdGhlciwgdGhlIG9wZXJhdG9yIHByb3Zp ZGluZyB0aGUgc2VydmljZSBpcyBjYWxsZWQgdGhlICJyb2FtaW5nIiBtb2JpbGl0eSBzZXJ2aWNl IHByb3ZpZGVyLiINClRoaXMgaXMgYWxzbyBhIGNob2ljZS4NCg0KPiBGaW5hbGx5LCBJIHRoaW5r IHRoYXQgcGFyYWdyYXBoIDggbmVlZHMgbW9kaWZpY2F0aW9uLiBIZXJlJ3MgYSBzdWdnZXN0ZWQN Cj4gY2hhbmdlOg0KPiANCj4gVGhlIHNlcnZpY2UgbW9kZWwgZGVmaW5lZCBoZXJlIGNsZWFybHkg c2VwYXJhdGVzIHRoZSBlbnRpdHkgcHJvdmlkaW5nIHRoZQ0KPiBzZXJ2aWNlIGZyb20gdGhlIGVu dGl0eSB0aGF0IGF1dGhlbnRpY2F0aW9ucyBhbmQgYXV0aG9yaXplcyB0aGUgc2VydmljZS4gDQoN ClRoaXMgaXMgdGhlIHBvaW50IHdoYXQgaSBsaWtlIHlvdXIgZXhwcmVzc2lvbi4NCkkgdGhpbmss IHdlJ3JlIHVzaW5nIG9mIHRlcm1pbm9sb2d5LCAic2VydmljZSBwcm92aWRlciIgdG8gZXhwcmVz cyB0aGUgZGlmZmVyZW50IGVudGl0aWVzLg0KVGhpcyBwb2ludCBzaG91bGQgYmUgYXBwbGllZCB0 byB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoaXMgSS1ELg0KDQpJIHRoaW5rIHdlIGNhbiB1dGlsaXpl IHRoaXMgSmFtZXMnIHdvcmsgdG8gYnVpbGQtdXAgb3VyIE1JUDYgYm9vdHN0cmFwcGluZyBmcmFt ZXdvcmsuDQoNCi0tSnVuZ2hvb24gDQoNCj4gSW4gdGhlIGNhc2Ugb2YgYmFzaWMgbmV0d29yayBh Y2Nlc3MsIHRoaXMgc3VwcG9ydHMgdGhlIHRyYWRpdGlvbmFsIGFuZA0KPiB3ZWxsLWtub3duIHJv YW1pbmcgbW9kZWwsIGluIHdoaWNoIGludGVyLW9wZXJhdG9yIHJvYW1pbmcgYWdyZWVtZW50cyBh bGxvdyBhDQo+IGhvc3QgdG8gb2J0YWluIG5ldHdvcmsgYWNjZXNzIGluIGFyZWFzIHdoZXJlIHRo ZWlyIGhvbWUgbmV0d29yayBhY2Nlc3MNCj4gcHJvdmlkZXIgZG9lcyBub3QgaGF2ZSBjb3ZlcmFn ZS4gSW4gdGhlIGNhc2Ugb2YgbW9iaWxpdHkgc2VydmljZSwgdGhpcw0KPiBhbGxvd3MgYSByb2Ft aW5nIG1vYmlsZSBob3N0IHRvIG9idGFpbiBtb2JpbGl0eSBzZXJ2aWNlIGluIHRoZSBsb2NhbA0K PiBvcGVyYXRvcidzIG5ldHdvcmsgd2hpbGUgaGF2aW5nIHRoYXQgc2VydmljZSBhdXRob3JpemVk IGJ5IHRoZSBob21lDQo+IG9wZXJhdG9yLiBUaGUgc2VydmljZSBtb2RlbCBhbHNvIGFsbG93cyBt b2JpbGl0eSBzZXJ2aWNlIGFuZCBuZXR3b3JrIGFjY2Vzcw0KPiBzZXJ2aWNlIHRvIGJlIHByb3Zp ZGVkIGJ5IGRpZmZlcmVudCBlbnRpdGllcy4gVGhpcyBhbGxvd3MgYSBuZXR3b3JrIG9wZXJhdG9y DQo+IHdpdGggbm8gd2lyZWxlc3MgYWNjZXNzLCBsaWtlLCBmb3IgZXhhbXBsZSwgYW4gZW50ZXJw cmlzZSBuZXR3b3JrIG9wZXJhdG9yLA0KPiB0byBkZXBsb3kgYSBNb2JpbGUgSVB2NiBob21lIGFn ZW50IGZvciBtb2JpbGl0eSBzZXJ2aWNlIHdoaWxlIHRoZSBhY3R1YWwNCj4gd2lyZWxlc3MgbmV0 d29yayBhY2Nlc3MgaXMgcHJvdmlkZWQgYnkgdGhlIHNlcnZpbmcgbmV0d29yayBhY2Nlc3MgcHJv dmlkZXJzDQo+IHdpdGggd2hpY2ggdGhlIGVudGVycHJpc2Ugb3BlcmF0b3IgaGFzIGEgY29udHJh Y3QuIEhlcmUgYXJlIHNvbWUgb3RoZXINCj4gcG9zc2libGUgY29tYmluYXRpb25zIG9mIEFTUHMg YW5kIE1TUHM6DQo+IA0KPiBJIHdvdWxkIGRyb3AgcGFyYWdyYXBocyA0LCA2LCBhbmQgNywgc2lu Y2UgdGhleSB0YWxrIGFib3V0IG1lY2hhbmlzbXMgcmF0aGVyDQo+IHRoYW4gdGhlIHNlcnZpY2Ug bW9kZWwsIGFuZCB0aGlzIHNlY3Rpb24gaXMgcmVhbGx5IGFib3V0IHRoZSBzZXJ2aWNlIG1vZGVs Lg0KPiANCj4gVGhlIGJ1bGxldCBsaXN0IGFmdGVyIHBhcmFncmFwaCA4IGFuZCBwYXJhZ3JhcGgg OSBib3RoIGxvb2sgT0suDQo+IA0KPiBJJ2xsIHNlbmQgY29tbWVudHMgb24gU2VjdGlvbiA5IGlu IGEgc2VwYXJhdGUgbWVzc2FnZS4NCj4gDQo+ICAgICAgICAgICAgIGphaw0KPiANCj4gDQo+IA0K PiANCj4gDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IE1pcDYgbWFpbGluZyBsaXN0DQo+IE1pcDZAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbWlwNg== --===============0195883860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0195883860==-- From mip6-bounces@ietf.org Fri Feb 18 08:38:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01731 for ; Fri, 18 Feb 2005 08:38:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28gK-00005R-LM for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 09:00:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D28F9-0007E0-Tx; Fri, 18 Feb 2005 08:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D283u-0002or-8b for mip6@megatron.ietf.org; Fri, 18 Feb 2005 08:20:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29735 for ; Fri, 18 Feb 2005 08:20:49 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D28PY-000824-Et for mip6@ietf.org; Fri, 18 Feb 2005 08:43:13 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IC30021ZZLV0L@dns1.cselt.it> for mip6@ietf.org; Fri, 18 Feb 2005 14:17:55 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Feb 2005 14:22:51 +0100 Date: Fri, 18 Feb 2005 14:20:14 +0100 From: Gerardo Giaretta Subject: MIP6-AAA high-level view (was RE: [Mip6] question about mip6-aaa frameworks) To: john.loughney@nokia.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: MIP6-AAA high-level view (was RE: [Mip6] question about mip6-aaa frameworks) thread-index: AcUUtAhLszQC8zfhRW2uxSxKJgHDngACW56gAD+YaaA= Content-Class: urn:content-classes:message X-OriginalArrivalTime: 18 Feb 2005 13:22:51.0656 (UTC) FILETIME=[F281E080:01C515BC] X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Cc: alper.yegin@samsung.com, mip6@ietf.org, vijayd@iprg.nokia.com, James Kempf X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: quoted-printable John, I follow this thread since I agree that we need a high-level view on bootstrapping and AAA stuff, trying not to look at solution space, but considering network elements involved and potential deployment models. I think that the natural starting point for this analysis is the Problem Statement draft, since several related concepts have been discussed by the DT last year. Yesterday James sent a very interesting terminology classification that should be included in the draft and that we should consider as the reference terminology. I am posting it here for the sake of clarity: ASA - Access Service Authorizer. A network operator that authenticates a mobile host and establishes the mobile host's authorization to receive Internet service. ASP - Access Service Provider. A network operator that provides direct IP packet forwarding to and from the end host.=20 MSA - Mobility Service Authorizer. A service provider that authorizes Mobile IPv6 service. MSP - Mobility Service Provider. A service provider that provides Mobile IPv6 service. In order to obtain such service, the mobile host must be authenticated and prove authorization to obtain the service. IASP - Integrated Access Service Provider. A service provider that provides both authorization for network access and also provides mobility service. >From this terminology it is clear that one of the fundamental design assumption of the DT has been the decoupling between the access network service and the mobility service. For this reason, I think the first main classification we should consider is between frameworks that do not involve the access network service and frameworks that do involve it. 1. frameworks (or scenarios) that do not involve the access network service. The WG SHOULD standardize a solution for this.=20 Deployment scenarios:=20 a) MSA =3D MSP: the provider that authorizes the MN for mobility service is the same entity that manages the HA=20 b) MSA !=3D MSP: the HA is managed by a third entity (this is the "Third Party Scenario" in PS draft and it's analogous to roaming scenario for network access)=20 Network Elements involved: MN, HA, AAA-H, optionally AAA-F (AAA-H is the AAA server of the MSA; AAA-F is the AAA server of the MSP) MN <-------------> HA <---------> (AAA-F) <-------> AAA-H IKEv2(+EAP) ? ? The missing piece here is an investigation about the interface between HA and AAA. We should investigate if current Diameter Applications (e.g. EAP Diameter Application) are enough or if some new AVPs or applications are needed. 2. frameworks (or scenarios) that involves the access network service. The WG MAY standardize a solution for this. Deployment scenarios (note that the following diagrams are not suggesting any solutions but only showing the network elements involved and the relationships among them): a) MSA=3DASA (I-ASP), MSP=3DMSA, ASP=3DASA MN <-----> NAS <-----------> AAA ^ | V HA b) MSA=3DASA (I-ASP), MSP=3DMSA, ASP!=3DASA MN <-----> NAS <---------> AAA-ASP <------> AAA-MSP ^ | V HA c) MSA=3DASA (I-ASP), MSP!=3DMSA, ASP!=3DASA (allocation of the HA in = the local domain) MN <-----> NAS <---------> AAA-ASP <------> AAA-MSP ^ | V HA First of all, we should understand if we, as MIP6 WG, want to standardize an optimized solution for these scenarios. Note that a solution for 1 is also applicable in this scenario, but it may require a disoptimization (double EAP authentication). If an optimized solution for these scenarios is within the WG interest, we should focus on proposals, trying to identify some design principles that the solution should fulfill.=20 Comments? --Gerardo > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 > Behalf Of john.loughney@nokia.com > Sent: Thursday, February 17, 2005 8:00 AM > To: alper.yegin@samsung.com; vijayd@iprg.nokia.com > Cc: mip6@ietf.org > Subject: [Mip6] question about mip6-aaa frameworks >=20 >=20 > Hi all, >=20 > Starting a new thread as working though this thead is getting tough. >=20 > It seems that a high-level view on this is needed, not looking at > specific solutions at the moment. I think that this is somewhat > of a complex mix of protocols, architectures and solutions which > is making forward progress very difficult. >=20 > I think Alper's and Vijay's mails are showing that there is a need > to look at the network elements (possibly) involved and the > potential deployment models proposed. It is clear that a=20 > one-size-fits-all > approach is bound to fail; and I assumed that the WG was interested > in enabling existing deployments a way to provide=20 > bootstrapping information > to a mobile node. >=20 > Therefore, I'd like to propose that we look at a higher-level view > as a way forward out of this. I haven't been involved in any of the > proposals, but I'd be happy to try to gather some thoughts about this, > even though the submissions of new drafts is now closed. >=20 > John >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 18 13:32:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19090 for ; Fri, 18 Feb 2005 13:32:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2DHa-0004gs-BZ for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 13:55:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Cf8-0006bd-V6; Fri, 18 Feb 2005 13:15:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2CSP-0001rp-0w for mip6@megatron.ietf.org; Fri, 18 Feb 2005 13:02:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14445 for ; Fri, 18 Feb 2005 13:02:22 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Co5-0003pa-CN for mip6@ietf.org; Fri, 18 Feb 2005 13:24:50 -0500 Message-ID: <093801c515e4$1edf61d0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yoshihiro Ohba" References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com><01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com><20050216042627.GC18190@steelhead><049501c51452$31823da0$016115ac@dcml.docomolabsusa.com><20050216190443.GK18190@steelhead><060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com><20050217015704.GE25571@steelhead><07c701c5151d$779649a0$016115ac@dcml.docomolabsusa.com> <20050217224407.GA29145@steelhead> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Fri, 18 Feb 2005 10:03:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit > > The difference between security credentials and > > addresses is that the verification of the security credentials during an > > IKEv2 exchange (provided EAPoIKEv2 is used with the local HA) lies squarely > > in the home network. Thus, once again, there is an end-to-end transaction > > between the MN and AAA-H in which the local HA merely acts as a routing > > intermediary. There is no transfer of sensitive credentials between the home > > network and the foreign network. > > That is true provided EAPoIKEv2 is used with the local HA, as you > mentioned above. But if IKEv2 is used with the local HA but without > EAP (I mean the case in which there is no 2nd EAP), still there is > transfer of sensitive credentials across administrative domains and I > don't see a major difference as I mentioned in the previous mail. > I am not in favor of designs that require transfer of credentials shared exclusively between the mobility service authorizer and the user to a local HA in the foreign network, and don't believe such designs are a good idea for standardization for exactly the reason you cite above. > > With addresses, the home network is > > depending on the foreign network NAS to properly handle the addresses. It's > > just another point where compromise or failure is possible, even if, in > > general, the two operators trust each other. The fewer network entities > > involved, the less possibility for failure. > > Again, if IKEv2 is used with the local HA but without EAP, the local > HA still involves in the bootstrapping transaction and the number of > involved network entities for maintain the IKE credentials across > domains (three -- MN, local HA and AAA server) are the same as that is > needed for maintain HA address across domains (three - MN, NAS(*) and > AAA server). So I'd say that even if we use EAP for carrying > bootstrapping parameters, local HA support without 2nd EAP does not > follow the end-to-end model, and thus is recommended only for > well-managed networks. I hope I am doing the right analysis here. > With IKEv2 EAP through the local HA to the AAA-H, the local HA is acting as a router for an end to end encrypted bag of bits containing the credentials that are real-time transferred from the MN to the AAA-H. The AAA-H sends back a yes/no reply to the local HA. This is a well defined AAA-style transaction, and could even be optimized further with something like attribute certificates on the MN that the AAA-H provides during the initial network access authentication so that the MN can establish the IKEv2 SA on the local HA without needing a second EAP transaction. It's a completely different situation from NAS/DHCP case. In the NAS/DHCP case, the following are required: 1) Some way to propagate the home agent addresses into the AAA-H when those addresses change (as they will, please see parallel thread on preventing DoS attacks on home agents). 2) AAA flows from the AAA-H to the back end of the NAS, which unencapsulates them and relays them to the DHCP server. 3) Some way to transfer the addresses to the DHCP server if the NAS and DHCP server are not co-located. 4) Monitoring of the addresses and provisioning process to be sure that the addresses are current and there has been no compromise. This is a lot more than a simple AAA transaction, and requires a lot more network management and trust between networks than simple AAA, and there are a lot more ways for things to go wrong. This kind of network architecture is, in my opinion, not appropriate as a general solution for the Internet, though it may be useful for telephony-style networks, such as 3GPP2, in which there is a high degree of trust and co-operation between network operators. > (*) The number of the entities for the latter case can be four when > NAS and local DHCP server are physically separate devices. > Exactly. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 18 13:43:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20772 for ; Fri, 18 Feb 2005 13:43:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2DRR-00053L-Ln for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 14:05:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2D3J-0005aL-2P; Fri, 18 Feb 2005 13:40:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Cfr-0006nS-NE for mip6@megatron.ietf.org; Fri, 18 Feb 2005 13:16:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16346 for ; Fri, 18 Feb 2005 13:16:16 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2D1Z-0004DQ-3W for mip6@ietf.org; Fri, 18 Feb 2005 13:38:45 -0500 Message-ID: <095101c515e6$16bb4440$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mayumi Yanagiya" References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> <4214978D.7080005@lab.ntt.co.jp> <077c01c51516$58590520$016115ac@dcml.docomolabsusa.com> <42156B0E.20703@lab.ntt.co.jp> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Fri, 18 Feb 2005 10:17:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Yanagiya-san, > I agree that problems will be occurred when network providers don=92t >have agreement. But I can=92t understand why the problems will be occurr= ed >only in DHCP case. For example, in IKEv2 based solution, > - if MN is assigned home agent in home network, HA aren=92t required > inter-domain interface. > - if MN assign home agent in local network, home agent will be require= d > inter-domain interface to get some information such as IKE > credential. > > I think that same problems will be occurred if there is no agreement >between home network and local network. Is my opinion wrong? There are more places for things to go wrong in the DHCP case. As I mentioned in email to Yoshi, there needs to be some way to get the HA addresses into the AAA-H when they change, then from the AAA-H to the NAS= in the foreign domain, then from the NAS to the DHCP server, then from the D= HCP server to the MN. That's a lot more places for things to go wrong. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 18 13:57:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23311 for ; Fri, 18 Feb 2005 13:57:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Df4-0005YU-Hk for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 14:19:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2D3e-000626-P0; Fri, 18 Feb 2005 13:40:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Clp-00006K-3x for mip6@megatron.ietf.org; Fri, 18 Feb 2005 13:22:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17432 for ; Fri, 18 Feb 2005 13:22:26 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2D7W-0004Ou-Qf for mip6@ietf.org; Fri, 18 Feb 2005 13:44:55 -0500 Message-ID: <095701c515e6$f2d71350$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Junghoon Jee" , , "Gopal Dommety" References: <4.3.2.7.2.20050215120213.026355d0@mira-sjc5-d.cisco.com><008401c5140c$0e1f9100$6b70fe81@FlyToWorld> <081c01c5152c$c123a450$016115ac@dcml.docomolabsusa.com> <005601c51573$dd4de860$6b70fe81@FlyToWorld> Subject: Re: [Mip6] WG LC: I-D draft-ietf-mip6-bootstrap-ps-01.txt(ProblemStatement for bootstrapping Mobile IPv6 ) Date: Fri, 18 Feb 2005 10:23:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit > > These credentials allow the mobile host to authenticate itself to the mobility or access > > service provider and to prove its authorization to obtain service. > > I would like to change like below if my understanding of your terminology is correct. > "These credentials allow the mobile host to authenticate itself to the mobility or access > service --authorizer-- and to prove its authorization to obtain service" > Yes, that's right, thanx for catching it. I forgot to change this before I sent the email. > > Serving Network Access Provider. > > A network operator that is the mobile host's ASP but not its ASA. The > > roaming network accesss provider may or may not additionally provide > > mobility service. > > What about changing the "Serving Network Access Provider" to "Roaming Network Access Provider" ? > This is not significant, it's just a choice. > Actually, that's how I orginally had it, but I changed it to "serving" to be consistent with the terminology in Section 6. One problem here is the terminology used by other SDOs. I think 3GPP and 3GPP2 use "serving" to describe the roaming operator. Worse, however, is the terminology used by 802.11. They define "roaming" as what IETF or the 3Gs would call "handover", that is when a terminal moves from one access point to another. We don't have to be bound by the terminology used by other SDOs, but they will certainly read this document so we need to make sure terms are well defined. Personally, I don't mind which term is used, so long as it is well defined an consistently applied. > > Serving Mobility Service Provider. > > A MSP that provides mobility service but depends on another service > > provider to authorize it. > > What about changing the "Serving Mobility Service Provider" to "Roaming Mobility Service Provider" ? > Again, fine. > I like this way, if you agree with the change of the terminology. > "If authentication and authorization is provided by one operator and the actual service is provider by another, the operator providing the service is called the "roaming" mobility service provider." > This is also a choice. > OK. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 18 15:11:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05959 for ; Fri, 18 Feb 2005 15:11:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2EpI-0000PB-8N for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 15:34:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2E7w-0005rk-4J; Fri, 18 Feb 2005 14:49:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Dvl-0001Ef-KV for mip6@megatron.ietf.org; Fri, 18 Feb 2005 14:36:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00589 for ; Fri, 18 Feb 2005 14:36:47 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2EHS-00079y-Il for mip6@ietf.org; Fri, 18 Feb 2005 14:59:16 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0IC400701H486P@mailout2.samsung.com> for mip6@ietf.org; Sat, 19 Feb 2005 04:36:08 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IC400LN4H47W9@mailout2.samsung.com> for mip6@ietf.org; Sat, 19 Feb 2005 04:36:07 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IC40054VH45W8@mmp1.samsung.com> for mip6@ietf.org; Sat, 19 Feb 2005 04:36:07 +0900 (KST) Date: Fri, 18 Feb 2005 11:36:05 -0800 From: Alper Yegin Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt In-reply-to: <093801c515e4$1edf61d0$016115ac@dcml.docomolabsusa.com> To: "'James Kempf'" , "'Yoshihiro Ohba'" Message-id: <1d6f01c515f1$17924250$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7BIT Cc: mip6@ietf.org, "'Yoshihiro Ohba'" X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7BIT James, > It's a completely different situation from NAS/DHCP case. In the NAS/DHCP > case, the following are required: > > 1) Some way to propagate the home agent addresses into the AAA-H when > those > addresses change (as they will, please see parallel thread on preventing > DoS > attacks on home agents). When a configuration parameter changes, appropriate actions need to be taken regardless of the used scheme (e.g., update DNS servers, or update DHCP servers, or AAA servers, etc.). I don't see an order of magnitude difference between different "centralized bootstrapping systems" when it comes to handling changes. > 2) AAA flows from the AAA-H to the back end of the NAS, which > unencapsulates > them and relays them to the DHCP server. > 3) Some way to transfer the addresses to the DHCP server if the NAS and > DHCP > server are not co-located. These two are the same. Info flows from AAA home server to AAA client on the NAS (collocated with DHCP relay); later from DHCP relay to DHCP server. > 4) Monitoring of the addresses and provisioning process to be sure that > the > addresses are current and there has been no compromise. Sure. > This is a lot more than a simple AAA transaction, and requires a lot more > network management and trust between networks than simple AAA, and there > are > a lot more ways for things to go wrong. This kind of network architecture > is, in my opinion, not appropriate as a general solution for the Internet, > though it may be useful for telephony-style networks, such as 3GPP2, in > which there is a high degree of trust and co-operation between network > operators. I admit there are more end-points involved in the information flow. Unless there is some characteristic difference (e.g., insertion of untrusted 3rd parties in the flow), I don't see a major issue. Sure this may not be an appropriate scheme for all deployments. But if it is good enough for 3G* and other wireless operator networks, that should be enough to consider it -- of course, we shall capture its characteristics too. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 18 18:59:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27439 for ; Fri, 18 Feb 2005 18:59:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2INq-0008Hp-Uq for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 19:22:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2HLy-000252-Ec; Fri, 18 Feb 2005 18:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2GYC-0006gs-2v for mip6@megatron.ietf.org; Fri, 18 Feb 2005 17:24:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11007 for ; Fri, 18 Feb 2005 17:24:37 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Gtu-0003DC-0E for mip6@ietf.org; Fri, 18 Feb 2005 17:47:07 -0500 Message-ID: <09cf01c51608$c661e120$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Gerardo Giaretta" , References: Subject: Re: MIP6-AAA high-level view (was RE: [Mip6] question about mip6-aaa frameworks) Date: Fri, 18 Feb 2005 14:25:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: alper.yegin@samsung.com, mip6@ietf.org, vijayd@iprg.nokia.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Gerardo, >First of all, we should understand if we, as MIP6 WG, want to >standardize an optimized solution for these scenarios. Note that a >solution for 1 is also applicable in this scenario, but it may require a >disoptimization (double EAP authentication). If an optimized solution >for these scenarios is within the WG interest, we should focus on >proposals, trying to identify some design principles that the solution >should fulfill. As I suggested in my response to Yoshi, there are ways that optimization can be done. For now, I think we need to get the architecture sorted out, and worry about optimization later. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 18 19:04:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28318 for ; Fri, 18 Feb 2005 19:04:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2ISJ-00004w-Gn for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 19:26:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2HRy-0007gw-6k; Fri, 18 Feb 2005 18:22:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2H6F-00010c-5o for mip6@megatron.ietf.org; Fri, 18 Feb 2005 17:59:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15885 for ; Fri, 18 Feb 2005 17:59:48 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2HRz-0004fj-9N for mip6@ietf.org; Fri, 18 Feb 2005 18:22:19 -0500 Message-ID: <09f601c5160d$b227dcf0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Fri, 18 Feb 2005 15:00:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: 7bit Subject: [Mip6] Security Section Comments on draft-ietf-mip6-bootstrap-ps-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit This note contains comments on Section 9, Security Considerations. As a high level comment, this section seems to mix security considerations regarding the results of the bootstrapping process with security considerations for the bootstrapping process itself. This is somewhat confusing. Even though the two are related, I think the two need to be separated for clearer understanding. Furthermore, the bullet list at the end of the section contains a mix of design considerations and solutions. The solutions seem to me to be inappropriate in a problem statement. Finally there isn't any threat analysis and it seems to me that a problem statement security considerations should contain a threat analysis. Below is some suggested text that addresses these issues. -------------------- 9.0 Security Considerations There are two aspects of security for the Mobile IPv6 bootstrapping problem: 1) The security requirements imposed on the outcome of the bootstrapping process by RFC 3775 and other RFCs used by Mobile IPv6 for security. 2) The security of the bootstrapping process itself, in the sense of threats to the bootstrapping process imposed by active or passive attackers. Note that the two are related, in that if the bootstrapping process is compromised, the level of security required by RFC 3775 may not be obtained. The following two sections discuss these issues. 9.1 Security Requirements of Mobile IPv6 The Mobile IPv6 specification in RFC 3775 requires the establishment of a collection of IPsec SAs between the home agent and mobile host to secure the signaling traffic for Mobile IP, and, optionally, also to secure data traffic. The security of an IPsec SA required by the relevent IPsec RFCs must be quite strong. Provisioning of keys and other cryptographic material during the establishment of the SA through bootstrapping must be done in a manner such that authenticity is proved and confidentiality is ensured. In addition, the generation of any keying material or other cryptographic material for the SA must be done in a way such that the probability of compromise after the SA is in place is minimized. The best way to minimize the probability of such a compromise is to have the cryptographic material only known or calculable by the two end nodes that share the SA, in this case, the home agent and mobile host. If other parties are involved in the establishing the SA, through key distribution for example, the process should follow the constraints [cite Russ Housley's AAA keys draft here, can't find reference at the moment] designed to provide equivalent security. RFC 3775 also requires a trust relationship as defined in Section 1.3 between the mobile host and mobility service provider. This is necessary, for instance, to ensure that fradulent mobile hosts which attempt to flood other mobile hosts with traffic can not only be shut off but tracked down [draft-ietf- mipv6-ro-sec]. An infrastructureless relationship as defined in Section 1.3 does not satisfy this requirement. Any bootstrapping solution must include a trust relationship between mobile host and mobility service provider. Solutions that depend on an infrastructureless relationship are out of scope for bootstrapping. Another requirement is that a home address is authorized to one specific host at a time. RFC 3775 requires this in order to that misbehaving mobile hosts can be shut down. This implies that, in addition to the IPsec SA, the home agent must somehow authorize the mobile host for a home address. The authorization can be either implicit (for example, as a side effect of the authentication for mobility service) or explicit. The authorization can either be done at the time the SA is created or dynamically managed through a first come, first served allocation policy. 9.2 Threats to the Bootstrapping Process Various attacks are possible on the bootstrapping process itself. These attacks can compromise the process such that the RFC 3775 requirements for Mobile IP security are not met, or they can serve to simply disrupt the process such that bootstrapping cannot complete. Here are some possible attacks: o An attacking network entity purporting to offer the mobile host a legitimate home agent address or boostrapping for the IPsec SAs may, instead, offer a bogus home agent address or configure bogus SAs that allow the home agent to steal the mobile host's traffic or otherwise disrupts the mobile host's mobility service. o An attacking mobile host may attempt to steal mobility service by offering up fake credentials to a bootstrapping network entity or otherwise disrupt the home agent's ability to offer mobility service. o A man in the middle on the link between the mobile host and the bootstrapping network entity could steal credentials or other sensitive information and use that to steal mobility service or deny it to the legitimate owner of the credentials. o An attacker could arrange for a distributed denial of service attack on the bootstrapping entity, to disrupt legitimate users from obtaining bootstrapping. In addition to these attacks, there are other considerations that are important in achieving a good security design. Because mobility and network access authentication are separate services, any keys for these services need to be cryptographically separate, separately named, and have separate lifetimes that are not exceeded. This is necessary because a mobile host must be able to move from one serving (or roaming) network access provider to another without needing to change its mobility access provider. Finally, basic cryptographic processes must provide for multiple algorithms in order to accommodate the widely varying deployment needs. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 18 19:49:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02386 for ; Fri, 18 Feb 2005 19:49:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2J9i-0001Uv-4a for mip6-web-archive@ietf.org; Fri, 18 Feb 2005 20:11:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2ITQ-0004Sz-EJ; Fri, 18 Feb 2005 19:27:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2IHL-0004oF-9R for mip6@megatron.ietf.org; Fri, 18 Feb 2005 19:15:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29775 for ; Fri, 18 Feb 2005 19:15:20 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Id6-0000Yz-Gd for mip6@ietf.org; Fri, 18 Feb 2005 19:37:52 -0500 Message-ID: <09f901c51618$3e1029c0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Fri, 18 Feb 2005 16:16:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Subject: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit As John Loughney brought up, the draft is a bit long for a problem statement. Actually, I think the draft is more a mix of problem statement, functional architecture, and requirements. It might be worthwhile to at least separate out the draft into these three parts, to simplify and condense the problem statement and group the other parts more coherently together. draft-giaretta-mip6-aaa-ha-goals, which, despite its title, deals with similar issues on the back end, actually does a pretty good job of separating out these three parts stylistically, though of course the content is different. The other possibility would be to separate the draft into two, one for the problem statement and one for the requirements and functional architecture. If that is done, I think it is very important that all the content in the current functional architecture and requirements parts of the draft not get lost (in the past, I've seem parts of drafts get lost when they are so separated). jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Feb 19 01:11:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02984 for ; Sat, 19 Feb 2005 01:11:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2OBO-0002n2-A3 for mip6-web-archive@ietf.org; Sat, 19 Feb 2005 01:33:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2NkI-0004Pp-20; Sat, 19 Feb 2005 01:05:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2NbZ-0007rh-LF for mip6@megatron.ietf.org; Sat, 19 Feb 2005 00:56:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00574 for ; Sat, 19 Feb 2005 00:56:34 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2NxN-0002Gq-J1 for mip6@ietf.org; Sat, 19 Feb 2005 01:19:10 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1J5uYc27506; Sat, 19 Feb 2005 07:56:34 +0200 (EET) X-Scanned: Sat, 19 Feb 2005 07:55:48 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1J5tma5005120; Sat, 19 Feb 2005 07:55:48 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00NuXQ8s; Sat, 19 Feb 2005 07:55:47 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1J5tkJ23557; Sat, 19 Feb 2005 07:55:46 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 19 Feb 2005 07:55:42 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 19 Feb 2005 07:55:35 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 19 Feb 2005 07:55:41 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt Date: Sat, 19 Feb 2005 07:55:40 +0200 Message-ID: Thread-Topic: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt Thread-Index: AcUWHg0efoGTC6YJQgWLwpWAhtEuiAAKVdhw To: , X-OriginalArrivalTime: 19 Feb 2005 05:55:41.0553 (UTC) FILETIME=[A4EECE10:01C51647] X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Hi James, > As John Loughney brought up, the draft is a bit long for a problem > statement. Actually, I think the draft is more a mix of problem = statement, > functional architecture, and requirements. It might be worthwhile to = at > least separate out the draft into these three parts, to simplify and > condense the problem statement and group the other parts more = coherently > together. draft-giaretta-mip6-aaa-ha-goals, which, despite its title, = deals > with similar issues on the back end, actually does a pretty good job = of > separating out these three parts stylistically, though of course the = content > is different. >=20 > The other possibility would be to separate the draft into two, one = for the > problem statement and one for the requirements and functional = architecture. > If that is done, I think it is very important that all the content in = the > current functional architecture and requirements parts of the draft = not get > lost (in the past, I've seem parts of drafts get lost when they are so > separated). I'm comfortable with either solutions, I do think that the document has = a lot of useful information that shouldn't get lost. I think if we took your later suggest, we could probably progress it rather quickly, I don't = think we need additional information. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sat Feb 19 12:34:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24004 for ; Sat, 19 Feb 2005 12:34:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Yqz-0005Ha-6j for mip6-web-archive@ietf.org; Sat, 19 Feb 2005 12:57:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2XJM-00043g-6n; Sat, 19 Feb 2005 11:18:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2VxN-0003Xw-SH for mip6@megatron.ietf.org; Sat, 19 Feb 2005 09:51:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08481 for ; Sat, 19 Feb 2005 09:51:34 -0500 (EST) 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.33) id 1D2WJB-0000lZ-QM for mip6@ietf.org; Sat, 19 Feb 2005 10:14:14 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Feb 2005 08:04:47 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,100,1107734400"; d="scan'208"; a="226854709:sNHT19865356" Received: from alpeshw2k03 (sjc-vpn7-169.cisco.com [10.21.144.169]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1JEp2uC026369; Sat, 19 Feb 2005 06:51:03 -0800 (PST) Message-Id: <200502191451.j1JEp2uC026369@sj-core-1.cisco.com> From: "Alpesh" To: , , Subject: RE: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt Date: Sat, 19 Feb 2005 06:51:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Thread-Index: AcUWHg0efoGTC6YJQgWLwpWAhtEuiAAKVdhwABKVh3A= In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit James: I tend to agree, but let me recall - wasn't the goal of the design team to develop a problem statement - state what is the goal of bootstrap, what are the operating parameters and what should be the constraints? I am definitely open to reorganize the document as John originally suggested. I don't oppose to break up the document either - my concern is losing information/context in moving from one to many. Problem statements dispersed over multiple docs are typically hard to capture, IMHO. Still open to suggestions. -a > -----Original Message----- > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > Behalf Of john.loughney@nokia.com > Sent: Friday, February 18, 2005 9:56 PM > To: kempf@docomolabs-usa.com; mip6@ietf.org > Subject: RE: [Mip6] Overall LC comment on > draft-ietf-mip6-bootstrap-ps-01.txt > > Hi James, > > > As John Loughney brought up, the draft is a bit long for a problem > > statement. Actually, I think the draft is more a mix of problem > > statement, functional architecture, and requirements. It might be > > worthwhile to at least separate out the draft into these > three parts, > > to simplify and condense the problem statement and group the other > > parts more coherently together. draft-giaretta-mip6-aaa-ha-goals, > > which, despite its title, deals with similar issues on the > back end, > > actually does a pretty good job of separating out these three parts > > stylistically, though of course the content is different. > > > > The other possibility would be to separate the draft into two, one > > for the problem statement and one for the requirements and > functional architecture. > > If that is done, I think it is very important that all the > content in > > the current functional architecture and requirements parts of the > > draft not get lost (in the past, I've seem parts of drafts get lost > > when they are so separated). > > I'm comfortable with either solutions, I do think that the > document has a lot of useful information that shouldn't get > lost. I think if we took your later suggest, we could > probably progress it rather quickly, I don't think we need > additional information. > > John > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Feb 20 22:21:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11467 for ; Sun, 20 Feb 2005 22:21:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D34UO-0002Bf-2I for mip6-web-archive@ietf.org; Sun, 20 Feb 2005 22:44:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D33aB-00047e-J8; Sun, 20 Feb 2005 21:45:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D33KR-0007LG-LU for mip6@megatron.ietf.org; Sun, 20 Feb 2005 21:29:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07716 for ; Sun, 20 Feb 2005 21:29:36 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D33gY-0000uk-BE for mip6@ietf.org; Sun, 20 Feb 2005 21:52:35 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Feb 2005 11:29:54 +0900 Message-ID: <003001c517bd$1d226ba0$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: "Vijay Devarapalli" References: <004401c51409$928b96d0$6b70fe81@FlyToWorld> <421393C7.8000704@sun.com> <002b01c5148b$018ffb30$6b70fe81@FlyToWorld> <42140322.20706@iprg.nokia.com> <005101c514a5$7d9fef40$6b70fe81@FlyToWo <421451CD.7060409@iprg.nokia.com> Subject: Re: [Mip6] mip6-aaa frameworks Date: Mon, 21 Feb 2005 11:29:05 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 21 Feb 2005 02:29:54.0157 (UTC) FILETIME=[3A2331D0:01C517BD] X-Spam-Score: 2.2 (++) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: Gerardo Giaretta , Alper Yegin , Erik Nordmark , mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1596192989==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 --===============1596192989== Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gVmlqYXksIA0KUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQoNCi0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAiVmlqYXkgRGV2YXJhcGFsbGkiIDx2aWpheWRA aXByZy5ub2tpYS5jb20+DQpUbzogIkp1bmdob29uIEplZSIgPGpoamVlQGV0cmkucmUua3I+DQpD YzogIkVyaWsgTm9yZG1hcmsiIDxlcmlrLm5vcmRtYXJrQHN1bi5jb20+OyAiR2VyYXJkbyBHaWFy ZXR0YSIgPEdlcmFyZG8uR2lhcmV0dGFAVElMQUIuQ09NPjsgIkFscGVyIFllZ2luIiA8YWxwZXIu eWVnaW5Ac2Ftc3VuZy5jb20+OyA8bWlwNkBpZXRmLm9yZz4NClNlbnQ6IFRodXJzZGF5LCBGZWJy dWFyeSAxNywgMjAwNSA1OjExIFBNDQpTdWJqZWN0OiBSZTogW01pcDZdIG1pcDYtYWFhIGZyYW1l d29ya3MNCg0KDQo+IA0KPiBKdW5naG9vbiBKZWUgd3JvdGU6DQo+ID4gSGVsbG8gVmlqYXkuDQo+ ID4gUGxlYXNlIHNlZSBteSBjb21tZW50cyBpbmxpbmUuDQo+ID4gDQo+ID4gDQo+ID4+SnVuZ2hv b24gSmVlIHdyb3RlOg0KPiA+Pg0KPiA+Pg0KPiA+Pj4+PlRoZSBkeW5hbWljIEhBIGRpc2NvdmVy eSBpcyBzdGlsbCBhbiBpc3N1ZS4NCj4gPj4+Pj5XaXRoIG15IG1pbmQsIGFkZGluZyBzZWN1cml0 eSBtZWNoYW5pc20gdG8gdGhlIHByZS1leGlzdGluZyBETlMgcXVlcnkgbWF5IGJlIGEgYnVyZGVu LiANCj4gPj4+Pg0KPiA+Pj4+VGhlIG5lZWQgZm9yIGNvbmZpZGVudGlhbGl0eSBvZiB0aGUgSEFz IElQIGFkZHJlc3MgaXMgaGFyZCBmb3IgbWUgdG8gDQo+ID4+Pj51bmRlcnN0YW5kIHdpdGhvdXQg dW5kZXJzdGFuZGluZyB0aGUgdGhyZWF0IG1vZGVsLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PkN1cnJl bnRseSwgbXkgY29uY2VybiBpcyBhYm91dCB0aGUgaW50ZWdyaXR5IGFuZCByZXBsYXkgcHJvdGVj dGlvbiBmb3IgSEEgSVAgYWRkcmVzcy4NCj4gPj4+Q291bGQgd2Ugc3VwcG9ydCB0aGlzIHdpdGhv dXQgcmVxdWlyaW5nIHRoZSBzZWN1cml0eSBmdW5jdGlvbiBpbiB0aGUgcHJlLWV4aXN0aW5nIERO UyBzZXJ2ZXJzID8NCj4gPj4+TXkgYW5zd2VyIGlzIE5PLg0KPiA+Pj5JZiBteSBhbnN3ZXIgaXMg Y29ycmVjdCwgcHJlLWV4aXN0aW5nIEROUyBzZXJ2ZXJzIG5lZWRzIHRvIGJlIGNoYW5nZWQgdG8g c3VwcG9ydCBNSVA2IGJvb3RzdHJhcHBpbmcuDQo+ID4+PkkgYW0gbm90IHN1cmUgd2hldGhlcmUg dGhpcyBhcHByb2FjaCBpcyByaWdodC4NCj4gPj4NCj4gPj5JIGhhdmUgdG8gZGlzYWdyZWUgaGVy ZS4gaXQgaXMgbGlrZSBnZXR0aW5nIGFueSBvdGhlciBzZXJ2ZXIncyBhZGRyZXNzDQo+ID4+dGhy b3VnaCBETlMuIElNSE8sIHRoZSB0aHJlYXQgbW9kZWwgaXMgbm8gZGlmZmVyZW50Lg0KPiA+IA0K PiA+IA0KPiA+IGRyYWZ0LWlldGYtYm9vdHN0cmFwLXBzIHJlcXVpcmVzIHRoZSBpbnRlZ3JpdHkg YW5kIHJlcGxheSBwcm90ZWN0aW9uIG9mIGJvb3RzdHJhcHBpbmcgaW5mb3JtYXRpb24uDQo+ID4g V2hhdCBkbyB5b3UgdGhpbmsgYWJvdXQgdGhpcyA/DQo+IA0KPiB0aGUgcHJvYmxlbSBzdGF0ZW1l bnQgZG9lc250IGFjdHVhbGx5IHJlcXVpcmUgdGhpcy4gaXQgbGlzdHMgaXQNCj4gYXMgYSBkZXNp Z24gZ29hbC4gdGhlcmUgaXMgYSBzbGlnaHQgZGlmZmVyZW5jZS4gYW5kIEkgaGFkDQo+IGFjdHVh bGx5IGV4Y2x1ZGVkIE1OIGFjcXVpcmluZyB0aGUgSEEncyBhZGRyZXNzIHRocm91Z2ggRE5TIGFz DQo+IHNvbWV0aGluZyBvdXRzaWRlIHRoZSBib290c3RyYXBwaW5nIHByb2JsZW0gc3RhdGVtZW50 LiBzb21ldGhpbmcNCj4gdGhhdCBjYW4gYmUgdXNlZCByZWFkaWx5IHRvZGF5LiBub3RlLCB0aGF0 IG9ubHkgSEEncyBhZGRyZXNzIGlzDQo+IG9idGFpbmVkIHRocm91Z2ggRE5TLiBub3QgdGhlIEhv QS4NCg0KSWYgdGhlIHByb2JsZW0gc3RhdGVtZW50IGRvZW4ndCBuZWVkIHRvIGxpc3QgdXAgdGhl IHJlcXVpcmVtZW50cyBhYm91dCBNSVA2IGJvb3RzdHJhcHBpbmcuDQpJIHdvdWxkIGxpa2UgdG8g ZXhjbHVkZSB0aGUgc2VudGVuY2VzIHRoYXQgbWlnaHQgY29uZnVzZSB0aGUgcmVhZGVycyBvZiB0 aGF0IGRvY3VtZW50Lg0KQlRXLCBJIGFncmVlIHdpdGggSmFtZXMnIHNlY29uZCBpZGVhIDsNCiJU aGUgb3RoZXIgcG9zc2liaWxpdHkgd291bGQgYmUgdG8gc2VwYXJhdGUgdGhlIGRyYWZ0IGludG8g dHdvLCBvbmUgZm9yIHRoZQ0KcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIG9uZSBmb3IgdGhlIHJlcXVp cmVtZW50cyBhbmQgZnVuY3Rpb25hbCBhcmNoaXRlY3R1cmUuIg0KDQpZZXMsIEkga25vdyB0aGF0 IG9ubHkgSEEncyBhZGRyZXNzIGlzIG9idGFpbmVkIHRocm91Z2ggRE5TIG5vdCB0aGUgSG9BLg0K DQo+IGFuZCBhcyBFcmlrIHBvaW50ZWQgb3V0LCBvbmUgY2FuIGFsd2F5cyB1c2UgRE5TU0VDLg0K DQo+ICAgPg0KPiA+Pj5CVFcsIGkgZG9uJ3QgYWdyZWUgdG8gb3BlbiB1cCB0aGUgY2hhbmNlIG9m ICByZXZlYWxpbmcgdGhlIEhBIElQIGFkZHJlc3MgYnkgcHV0dGluZyB0aGlzIGluZm9ybWF0aW9u DQo+ID4+PmludG8gdGhlIHB1YmxpY2x5IGF2YWlsYWJsZSBETlMgc2VydmVyLiBBbnlvbmUgY2Fu IHF1ZXJ5IHRoZSBETlMgc2VydmVyIHRvIGdldCBhbnkgb3RoZXIncyBIQSBhZGRyZXNzLg0KPiA+ Pj5UaGlzIGluY3JlYXNlIHRoZSBwb3NzaWJpbGl0eSBvZiBEb1MgYXR0YWNrLiBJIGtub3cgdGhh dCB0aGlzIHBvaW50IGlzIGFscmVhZHkgbWVudGlvbmVkIGluIHRoZSBibWlwNiBkcmFmdC4NCj4g Pj4+SSBhbSB3YWl0aW5nIHRoZWlyIHJpZ2h0IHNvbHV0aW9uIGZvciB0aGlzLg0KPiA+Pg0KPiA+ PnRoaXMgbWlnaHQgc291bmQgY2xpY2hlZCwgYnV0IHlvdSBjYW5ub3QgYWNoaWV2ZSBzZWN1cml0 eSB0aHJvdWdoDQo+ID4+b2JzY3VyaXR5LiA6KQ0KPiA+IA0KPiA+IFBsZWFzZSBsb29rIGF0IHRo ZSBBcHBlbmRpeCBBLiBvZiBibWlwIGRyYWZ0Lg0KPiA+IENvdWxkIHlvdSBleHBsYWluIHdoeSB5 b3UgdXNlIHRoZSB3b3JkICdjbGljaGVkJyBhbmQgJ29ic2N1cml0eScgd2l0aG91dCBhbnkgZGV0 YWlsZWQgZXhwbGFuYXRpb24gPw0KPiANCj4gYmVjYXVzZSB5b3UgY2FuJ3QgcmVhbGx5IGhvcGUg dG8gaGlkZSB5b3VyIEhBIGFkZHJlc3MuIHRoYXQgaXMganVzdA0KPiBub3QgcG9zc2libGUuIG1v c3Qgb2Z0ZW4sIEkgZmluZCB0aGF0IGFuIE9wZXJhdG9yJ3MgY29uZmlndXJhdGlvbg0KPiBzZXR0 aW5ncyBjYW4gYmUganVzdCBvYnRhaW5lZCBmcm9tIHRoZSB3ZWIuIEkgZG9udCBzZWUgQ2luZ3Vs YXINCj4gdHJ5aW5nIHRvIGhpZGUgR1BSUyBBY2Nlc3MgUG9pbnRzIGluZm9ybWF0aW9uLiB0aGV5 IHB1Ymxpc2ggaXQgb24NCj4gdGhlIHdlYi4NCg0KWWVzLCBhcyB5b3Ugc2FpZCBJIGFtIG5vdCBz dXJlIHdoZXRoZXIgd2UgY2FuIGhpZGUgSEEgYWRkcmVzcyB1bmRlciBjb25zaWRlcmluZyANCnRo ZSBjdXJyZW50IHN0YW5kYXJkaXplZCBSRkMgMzc3NS4NCk15IHBvaW50IGlzIHRoYXQsDQpDdXJy ZW50IGV4YW1wbGUgb2Ygb3BlbmluZyBjcml0aWNhbCBpbmZvcm1hdGlvbiB0byB0aGUgcHVibGlj IGluZnJhLA0KY2FuIG5vdCBqdXN0aWZ5IHRoYXQgd2UgY2FuIGZvbGxvdyB0aGUgc2FtZSBhcHBy b2FjaC4NCg0KPiA+IFdvdWxkbid0IHlvdSB3YW50IHRvIGtlZXAgdGhlIGJhc2ljIHN0ZXAgYmVj YXVzZSB5b3UgdGhpbmsgaXQgaXMgY2xpY2hlZCA/DQo+IA0KPiBwbGVhc2UgcmVhZCBmdXJ0aGVy IGluIHRoZSBzYW1lIHBhcmFncmFwaC4NCj4gDQo+ID4gICAgVGhlIHRocmVhdCBmcm9tIEREb1MN Cj4gPiAgICBpbiB0aGlzIGNhc2UgaXMgbm8gbGFyZ2VyIHRoYW4gZm9yIGFueSBvdGhlciB3aWRl bHkga25vd24gcHVibGljDQo+ID4gICAgSW50ZXJuZXQgc2VydmVyLCBzdWNoIGFzIGEgcG9wdWxh ciBXZWIgc2l0ZSBvciwgaW5kZWVkLCBhIEROUyBzZXJ2ZXINCj4gPiAgICBmb3IgYSB0b3AgbGV2 ZWwgZG9tYWluLiAgTWVhc3VyZXMgc2ltaWxhciB0byB0aG9zZSB1c2VkIGJ5IHBvcHVsYXINCj4g PiAgICBXZWIgc2l0ZSBwcm92aWRlcnMgb3IgRE5TIHNlcnZlciBvcGVyYXRvcnMgY2FuIGJlIGRl cGxveWVkIHRvDQo+ID4gICAgbWl0aWdhdGUgc3VjaCBhdHRhY2tzLiANCg0KSSBhbHJlYWR5IGtu b3cgd2hhdCB0aGV5IGFyZSBzYXlpbmcgYWJvdXQuDQpJIHRoaW5rLCB5b3UgbmVlZCB0byBjaGVj ayB0aGUgcHJldmlvdXMgZGlzY3Vzc2lvbiBiZXR3ZWVuIEphbWVzIGFuZCBtZS4NCg0KLS1KdW5n aG9vbg0KDQo+IFZpamF5 --===============1596192989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1596192989==-- From mip6-bounces@ietf.org Mon Feb 21 01:36:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28905 for ; Mon, 21 Feb 2005 01:36:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D37Xg-0007JQ-8l for mip6-web-archive@ietf.org; Mon, 21 Feb 2005 01:59:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36jr-0000Zz-Dq; Mon, 21 Feb 2005 01:08:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36ab-0005TJ-VL for mip6@megatron.ietf.org; Mon, 21 Feb 2005 00:58:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26347 for ; Mon, 21 Feb 2005 00:58:29 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D36wk-0006UD-Np for mip6@ietf.org; Mon, 21 Feb 2005 01:21:31 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1L5wUc16618; Mon, 21 Feb 2005 07:58:30 +0200 (EET) X-Scanned: Mon, 21 Feb 2005 08:09:30 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1L69UJG006883; Mon, 21 Feb 2005 08:09:30 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00m0nUVj; Mon, 21 Feb 2005 08:09:17 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1L5u1M24914; Mon, 21 Feb 2005 07:56:01 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Feb 2005 07:55:56 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Feb 2005 07:55:56 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Date: Mon, 21 Feb 2005 07:55:56 +0200 Message-ID: Thread-Topic: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Thread-Index: AcUWF2wsNfHjRCwWTWOCbXBr222M9QBwSvng To: , X-OriginalArrivalTime: 21 Feb 2005 05:55:56.0985 (UTC) FILETIME=[02F50A90:01C517DA] X-Spam-Score: 0.3 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Hi James, > This note contains comments on Section 9, Security Considerations. >=20 > As a high level comment, this section seems to mix security = considerations > regarding the results of the bootstrapping process with security > considerations for the bootstrapping process itself. This is somewhat > confusing. Even though the two are related, I think the two need to be > separated for clearer understanding. Furthermore, the bullet > list at the end of the section contains a mix of design considerations > and solutions. The solutions seem to me to be inappropriate in a = problem statement. > > Finally there isn't any threat analysis and it seems to me that > a problem statement security considerations should contain a threat > analysis. Below is some suggested text that addresses these issues. =20 Generally I agree with your proposal, and I think the text improves upon the current text. One bit confused me: > In addition to these attacks, there are other considerations that are > important in achieving a good security design. Because mobility and = network > access authentication are separate services, any keys for these = services > need to be cryptographically separate, separately named, and have = separate > lifetimes that are not exceeded. This is necessary because a mobile = host > must be able to move from one serving (or roaming) network access = provider > to another without needing to change its mobility access provider. = Finally, > basic cryptographic processes must provide for multiple algorithms in = order > to accommodate the widely varying deployment needs. Could you more fully explain this statement. Because mobility and network access authentication are separate = services ... One one level, in some deployments, these are indeed seperate. However, = in some, you want fate-sharing between the two - if either fails, the other = should fail. Since mobility is needed (in some deployments) network access = authentication is not sufficient. =20 However, I think you might be suggesting that the network access = provider may be seperate from the mobility access provider, therefore they keying = material needs to be seperate. Is this more along the lines of what you mean? John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 21 02:23:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23461 for ; Mon, 21 Feb 2005 02:23:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D38H5-0008Qy-Ab for mip6-web-archive@ietf.org; Mon, 21 Feb 2005 02:46:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D37LB-0008Cy-Qb; Mon, 21 Feb 2005 01:46:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36q1-00021m-4F for mip6@megatron.ietf.org; Mon, 21 Feb 2005 01:14:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27554 for ; Mon, 21 Feb 2005 01:14:32 -0500 (EST) Received: from alpha9.its.monash.edu.au ([130.194.1.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D37CD-0006rp-Ug for mip6@ietf.org; Mon, 21 Feb 2005 01:37:31 -0500 Received: from localhost ([130.194.13.88]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LL2OB2G3268WW9M2@vaxh.its.monash.edu.au> for mip6@ietf.org; Mon, 21 Feb 2005 17:14:21 +1100 Received: from moe.its.monash.edu.au (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id C56B5AB545; Mon, 21 Feb 2005 17:14:20 +1100 (EST) Received: from [130.194.252.110] (knuth.eng.monash.edu.au [130.194.252.110]) by moe.its.monash.edu.au (Postfix) with ESMTP id 9F0D04FB03; Mon, 21 Feb 2005 17:14:20 +1100 (EST) Date: Mon, 21 Feb 2005 17:14:19 +1100 From: Greg Daley To: Wassim Haddad , mip6@ietf.org Message-id: <42197C3B.50500@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922 X-Accept-Language: en, en-us X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Content-Transfer-Encoding: 7BIT Subject: [Mip6] first impressions of omipv6-03 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: greg.daley@eng.monash.edu.au List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Content-Transfer-Encoding: 7BIT Hi I've just (finally) read OMIPv6, sorry about the delay. Here are my first impressions. I've not done an in depth analysis of the protocols yet (not that I'm capable of doing one), but the basic premise seems sound. The document, though, doesn't look quite like a specification. It's OK to get the idea of the protocol, but doesn't state up front what the motivation for OMIPv6 is. The abstract is promising, but the introduction doesn't really explain the difference between RR and OMIPv6, and spell out the benefits. I find the "this technique was specified originally in [XX]", to be distracting, when they could be summarized and referenced from the Acknowledgements Section. The Design Rationale may be something which migrates to an appendix, since it's actually talking about individual components of the mechanism. The big picture hasn't really been spelled out by then. At this stage, there really should be a summary of operations (maybe even without signalling), which defines what roughly can be done with OMPIv6, and the underlying principle (proof of identity using CGA and CoA proofs). Overall, I think I get it, I think it will work, and may be worth investigating further. I'd like to see more interest from the WG and another version before it became a WG or RG document. Concerns --------- It looks like the CN may be forced to send two messages for one of the MN's with the Pre-binding-Test and the pre-binding-acknowledgement. Is this the case? Is it possible to make the MN send two messages since this is the initial contact? Terminology ----------- When it talks about through HA, does it mean the MN is using its own Home Address (reverse tunnelled through its own HA)? When it mentions 'directly', does it mean that the message has a source address of the MN's CoA? simultaneously moving may indicate cell transition at the same time. It sounds better to delineate whether the devices are: 1) both MNs or 2) simultaneously changing subnets. Shared Key Option ------------------ The shared key option is 16 octets, and MUST be encrypted using the private key. I'm not sure, but I guess that the size of something encrypted with an RSA key is the length of the RSA modulus. Did you really want to specify that the key is encrypted with (only a fixed) 1024 bit RSA key? Care-of-Address Tests --------------------- it seems that the primary proof of ownership is over the Home Address. Isn't it possible to prove the Care-of-Address is valid, if the same CGA public/private key pair, and an additional CGA parameters set are transmitted in the BU? If the MN was able to prove its identity and location in the BU, the only issues would be computation on the MN and on the CN. If the porrf for the Home Address came first, then this may be applicable. Couldn't this be used with credit-based authorization to delay the timing requirements for a care-of-test (or something)? IPR ---- Yeah I know, but it's supposed to be an optimization on top of MIPv6. It's worth working out if both Ericsson and Microsoft want this one under similar to SEND terms. Future work ----------- I know that you've worked on this for a while. I think that in terms of specification, though this is at about the same level of knowledge as EBU (with CBA slightly behind). EBU I think has enough promise to look at standardization now or later. Is it worth getting these (EBU/OMIPv6) out as experimental in the IRTF ASAP? These or components of them could come out later as IETF standards track work. Transport area did this recently with the Eifel response algorithm, which has just gone Proposed Standard. (3522 and 4015) Greg _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 21 05:45:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09520 for ; Mon, 21 Feb 2005 05:45:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3BQ7-0004uU-OA for mip6-web-archive@ietf.org; Mon, 21 Feb 2005 06:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3AXx-0000fg-G3; Mon, 21 Feb 2005 05:12:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D39oR-0000tl-0n for mip6@megatron.ietf.org; Mon, 21 Feb 2005 04:25:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02935 for ; Mon, 21 Feb 2005 04:25:00 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3AAa-0002tA-HC for mip6@ietf.org; Mon, 21 Feb 2005 04:48:01 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Feb 2005 18:25:16 +0900 Message-ID: <005e01c517f7$24385640$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: Date: Mon, 21 Feb 2005 18:24:28 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 21 Feb 2005 09:25:16.0720 (UTC) FILETIME=[41248300:01C517F7] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Mip6] Question about MIPv6 deployment issues X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0811336605==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca --===============0811336605== Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sIEFMTC4NCg0KRHVyaW5nIGN1cnJlbnQgZGlzY3Vzc2lvbnMgYWJvdXQgTUlQdjYgYm9v dHN0cmFwcGluZywgDQpJJ3ZlIGNvbWUgdXAgd2l0aCBzZXZlcmFsIHF1ZXN0aW9ucyByZWxhdGVk IHdpdGggdGhpcy4NCg0KMS4gSXMgdGhlIE1JUHY2IGJvb3RzdHJhcHBpbmcgaXMgYSBkZXBsb3lt ZW50IGlzc3VlIG9yIG5vdCA/DQoNCkFGQUlLLCBNSVB2NiBib290c3RyYXBwaW5nIGlzIGZvciBh IHdpZGUgc3ByZWFkIGRlcGxveW1lbnQgb2YgTUlQdjYuDQpDdXJyZW50bHkgTUlQNiBXRyBjaGFy dGVycyhodHRwOi8vd3d3LmlldGYub3JnL2h0bWwuY2hhcnRlcnMvbWlwNi1jaGFydGVyLmh0bWwp ICBzYXlzIGFib3V0IHRoaXMgbGlrZSBiZWxvdywNCiJib290c3RyYXAgbWVjaGFuaXNtIGZvciBz ZXR0aW5nIHVwIHNlY3VyaXR5IGFzc29jaWF0aW9ucyBiZXR3ZWVuIHRoZSBNb2JpbGUgTm9kZSAo TU4pIGFuZCBIb21lIEFnZW50IChIQSkgdGhhdCB3b3VsZCBlbmFibGUgZWFzaWVyIGRlcGxveW1l bnQgb2YgTW9iaWxlIElQdjYuIg0KDQoyLiBJZiB0aGUgTUlQdjYgYm9vdHN0cmFwcGluZyBtZWNo YW5pc20gaXMgYSBkZXBsb3ltZW50IGlzc3VlLA0KRG8geW91IGFncmVlIHRoYXQgYSBib290c3Ry YXBwaW5nIHNvbHV0aW9uIHNob3VsZCBiZSBkZXNpZ25lZCBtaW5pbWl6aW5nIHRoZSBjaGFuZ2UN Cm9mIHRoZSBjdXJyZW50IGluZnJhc3RydWN0dXJlID8NCg0KSWYgeW91ciBhbnN3ZXIgaXMgWUVT LA0KSSB3b3VsZCBsaWtlIHRvIGFzayB5b3Ugd2hldGhlciB0aGUgdXNlIG9mIEROU3NlYyBpcyBh IHJpZ2h0IGNob2ljZSBmb3IgYm9vdHN0cmFwcGluZyBzb2x1dGlvbiBvciBub3QuDQpJbiBteSBv cGluaW9uLCBJIHRoaW5rIHRoZSB1c2Ugb2YgRE5Tc2VjIGlzIE5PVCBhIHJpZ2h0IGNob2ljZSBi ZWNhdXNlIHRoZSBETlNzZWMgaXMgcmFyZWx5IGRlcGxveWVkLg0KDQpJIGRvbid0IGFncmVlIHRo ZSBhcHByb2FjaCBvZiByZXF1aXJpbmcgdGhlIHJhcmVseSBkZXBsb3llZCBwcm90b2NvbA0KdG8g c3VwcG9ydCB0aGUgTUlQdjYgYm9vdHN0cmFwcGluZyBiZWNhdXNlIHRoZSBNSVB2NiBib290c3Ry YXBwaW5nIG1lY2hhbmlzbSBpcyANCm9yaWdpbmFsbHkgZm9yIGEgZWFzeSBkZXBsb3ltZW50IG9m IHRoZSBNb2JpbGUgSVB2NiBwcm90b2NvbC4NCg0KSU1ITywgdGhlIGRlcGxveW1lbnQgb2YgdGhl IG5ldHdvcmsgYWNjZXNzIEFBQSBpbmZyYXN0cnVjdHVyZSBpcyBtb3JlIGxpa2VseSBlYXNpZXIg DQp0aGFuIHRoZSB3aWRlIHNwcmVhZCBkZXBsb3ltZW50IG9mIEROU3NlYy4NCg0KMy4gV2hlbiB3 ZSBkZXNpZ24gYSBib290c3RyYXBwaW5nIHNvbHV0aW9uLCBkbyB5b3UgYWdyZWUgdG8gb3Blbmlu ZyB0aGUgDQpNTidzIEhBIGFkZHJlc3MgaW5mb3JtYXRpb24gdG8gYW55b25lIHdpdGhvdXQgYW55 IHJlc3RyaWN0aW9uID8NCg0KSSB0aGluayB0aGF0IHRoZSBIQSBhZGRyZXNzIGluZm9ybWF0aW9u IGlzIG5vdCBhbiBwdWJsaWMgaW5mb3JtYXRpb24gdGhhdA0KY2FuIGJlIGVhc2lseSBhY2Nlc3Np YmxlIHRvIGFueW9uZSAsbGlrZSB1c2luZyB0aGUgcHVibGljIEROUy4NCg0KSWYgeW91IGFncmVl IHRvIG9wZW4gdGhpcywgd2hhdCBhYm91dCBvcGVuaW5nIHRoZSBIQSBhZGRyZXNzIHRvIHRoZSBw dWJsaWMgd2ViIHNlcnZlciANCmFzIFZpamF5IG1hZGUgYW4gZXhhbXBsZS4gDQoNCi0tSnVuZ2hv b24NCg0KDQo= --===============0811336605== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0811336605==-- From mip6-bounces@ietf.org Mon Feb 21 05:46:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09642 for ; Mon, 21 Feb 2005 05:46:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3BRC-0004wK-OO for mip6-web-archive@ietf.org; Mon, 21 Feb 2005 06:09:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3AYn-0000mq-4a; Mon, 21 Feb 2005 05:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D39tB-0001oy-99 for mip6@megatron.ietf.org; Mon, 21 Feb 2005 04:30:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03305 for ; Mon, 21 Feb 2005 04:29:54 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3AFL-00031B-J3 for mip6@ietf.org; Mon, 21 Feb 2005 04:52:56 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0IC900G408X396@dns1.cselt.it> for mip6@ietf.org; Mon, 21 Feb 2005 10:27:03 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Feb 2005 10:32:01 +0100 Date: Mon, 21 Feb 2005 10:29:23 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt To: Alpesh , john.loughney@nokia.com, kempf@docomolabs-usa.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt thread-index: AcUWHg0efoGTC6YJQgWLwpWAhtEuiAAKVdhwABKVh3AAWKoyQA== Content-Class: urn:content-classes:message X-OriginalArrivalTime: 21 Feb 2005 09:32:01.0468 (UTC) FILETIME=[326427C0:01C517F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: quoted-printable Hi all, >=20 > James: >=20 > I tend to agree, but let me recall - wasn't the goal of the=20 > design team to > develop a problem statement - state what is the goal of=20 > bootstrap, what are > the operating parameters and what should be the constraints? >=20 > I am definitely open to reorganize the document as John originally > suggested. I don't oppose to break up the document either -=20 > my concern is > losing information/context in moving from one to many.=20 > Problem statements > dispersed over multiple docs are typically hard to capture, IMHO. =20 >=20 > Still open to suggestions. > I'm also comfortable with either solutions, since both would improve the document. Maybe it could be easier to split the draft in a "problem statement" and a "functional architecture and requirements" one (even if I agree that we should be very careful not to loose contents during this splitting). This could be also a way to easily include in the document some current considerations about integration between AAA and MIP6, for example in a way similar to my last mailing list post (thread: MIP6-AAA high-level view). From current mailing list discussion, it seems to me that the WG is lacking of some architectural "guidelines" (or goals/requirements) to develop a bootstrapping solution. Otherwise some of these AAA-MIP6 architectural considerations could be integrated in the scenarios description of draft-giaretta-mip6-aaa-ha-goals, but this draft only deals with the back end and it might not be the most convenient way to move forward. Regards, --Gerardo =20 > -a >=20 > > -----Original Message----- > > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On=20 > > Behalf Of john.loughney@nokia.com > > Sent: Friday, February 18, 2005 9:56 PM > > To: kempf@docomolabs-usa.com; mip6@ietf.org > > Subject: RE: [Mip6] Overall LC comment on=20 > > draft-ietf-mip6-bootstrap-ps-01.txt > >=20 > > Hi James, > >=20 > > > As John Loughney brought up, the draft is a bit long for=20 > a problem=20 > > > statement. Actually, I think the draft is more a mix of problem=20 > > > statement, functional architecture, and requirements. It might be=20 > > > worthwhile to at least separate out the draft into these=20 > > three parts,=20 > > > to simplify and condense the problem statement and group=20 > the other=20 > > > parts more coherently together. draft-giaretta-mip6-aaa-ha-goals,=20 > > > which, despite its title, deals with similar issues on the=20 > > back end,=20 > > > actually does a pretty good job of separating out these=20 > three parts=20 > > > stylistically, though of course the content is different. > > >=20 > > > The other possibility would be to separate the draft into=20 > two, one=20 > > > for the problem statement and one for the requirements and=20 > > functional architecture. > > > If that is done, I think it is very important that all the=20 > > content in=20 > > > the current functional architecture and requirements parts of the=20 > > > draft not get lost (in the past, I've seem parts of=20 > drafts get lost=20 > > > when they are so separated). > >=20 > > I'm comfortable with either solutions, I do think that the=20 > > document has a lot of useful information that shouldn't get=20 > > lost. I think if we took your later suggest, we could=20 > > probably progress it rather quickly, I don't think we need=20 > > additional information. > >=20 > > John > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 21 06:32:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09519 for ; Mon, 21 Feb 2005 05:45:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3BQ6-0004uL-Mw for mip6-web-archive@ietf.org; Mon, 21 Feb 2005 06:08:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3ARv-0008AL-Bv; Mon, 21 Feb 2005 05:05:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D39mi-0000Rq-Dh for mip6@megatron.ietf.org; Mon, 21 Feb 2005 04:23:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02830 for ; Mon, 21 Feb 2005 04:23:13 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3A8r-0002rK-UR for mip6@ietf.org; Mon, 21 Feb 2005 04:46:15 -0500 Received: from FlyToWorld ([129.254.112.107]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Feb 2005 18:23:29 +0900 Message-ID: <005a01c517f6$e41fcc50$6b70fe81@FlyToWorld> From: "Junghoon Jee" To: Date: Mon, 21 Feb 2005 18:22:40 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 21 Feb 2005 09:23:29.0185 (UTC) FILETIME=[010BF910:01C517F7] X-Spam-Score: 1.1 (+) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Mip6] Question about mip6-aaa framework 4 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1769364356==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 --===============1769364356== Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGVsbG8sIEFMTC4NCkkndmUgY29tZSB1cCB3aXRoIGEgcXVlc3Rpb24gYWJvdXQgRnJhbWV3b3Jr IDQuDQoNCkFscGVyIHNheXMsDQp+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fn5+fg0KRnJhbWV3b3Jr IDQ6DQotLS0tLS0tLS0tLS0NCkEgYmFja2VuZCBBQUEgcHJvdG9jb2wgaXMgZXhlY3V0ZWQgYmV0 d2VlbiB0aGUgSEEgYW5kIHRoZSBBQUEgc2VydmVyIGluDQpyZXNwb25zZSB0byB0aGUgTUlQNiBz aWduYWxpbmcgYmV0d2VlbiB0aGUgTU4gYW5kIHRoZSBIQS4gU2ltaWxhciB0byB0aGUNCnVzZSBv ZiBBQUEgcHJvdG9jb2xzIHdpdGggTUlQdjQgY28tbG9jYXRlZCBjYXJlLW9mIGFkZHJlc3MgY2Fz ZS4NCg0KUmVsYXRlZCBJLURzOg0KDQpkcmFmdC1naWFyZXR0YS1taXA2LWFhYS1oYS1nb2Fscy0w MC50eHQNCmRyYWZ0LXllZ2luLW1pcDYtYWFhLWZ3ay0wMC50eHQNCg0KRGlzY3Vzc2lvbjoNClRo aXMgb25lIGFwcGVhcnMgdG8gYmUgdGhlIG1vc3QgbmVlZGVkIGZyYW1ld29yay4gSXQgaXMgYXNz dW1lZCB0aGF0IE1ODQphbHJlYWR5IGtub3dzIHRoZSBIQSBhZGRyZXNzLiANCn5+fn5+fn5+fn5+ fn5+fn5+fn5+fn5+fn5+fn4NCg0KPT4gV2hhdCdzIHRoZSBleGFjdCBtZWFuaW5nIG9mIGFzc3Vt cHRpb24gb2Yga25vd2luZyB0aGUgSEEgPw0KSXMgdGhpcyBtZWFuIHRoYXQgdGhlIHByZS1jb25m aWd1cmF0aW9uIG9mIHRoZSBIQSBhZGRyZXNzIHRvIHRoZSBNTiA/DQpJIHdvdWxkIGxpa2UgdG8g cmVwZWF0IG15IHByZXZpb3VzIGNvbW1lbnRzIGFib3V0IHRoaXMgZm9yIGNsYXJpdHkgYmVjYXVz ZSB0aGVyZSBpcyBubyBhbnN3ZXINCmFib3V0IHRoaXMuDQoiQXMgSSBrbm93LCBkeW5hbWljIEhB IGFzc2lnbm1lbnQgaXMgb3dpbmcgdG8gdGhlIGlzc3VlcyBvZiB0aGUgaG9tZSBhZ2VudCBkaXNj b3ZlcnksDQppbmRlcGVuZGVudCBuZXR3b3JrIG1hbmFnZW1lbnQsIGxvY2FsIGhvbWUgYWdlbnRz IGFuZCBlYXNlIG9mIGRlcGxveW1lbnQNCmFzIHNwZWNpZmllZCBpbiB0aGUgZHJhZnQtaWV0Zi1t aXA2LWJvb3RzdHJhcC1wcy0wMS50eHQuIEFsc28gaXQgaXMgdmVyeSByZWxhdGVkIHdpdGggdGhl IGhvbWUgYWRkcmVzcyBhc3NpZ25tZW50LiINCg0KSWYgdGhlIGFzc3VtcHRpb24gbWVhbnMgcHJl LWNvbmZpZ3VyYXRpb24gb2YgSEEgYWRkcmVzcywNCkkgaGF2ZSBhIHF1ZXN0aW9uIHdoZXRoZXIg dGhlIGZyYW1ld29yayA0IGlzIGZvciBhIE1JUHY2IGJvb3RzdHJhcHBpbmcgb3Igbm90Lg0KSWYg dGhlIEhBIGFkZHJlc3MgaXMgcHJlLWNvbmZpZ3VyZWQsIHRoZSBIb0EgYWRkcmVzcyBjYW4gYmUg Z2VuZXJhdGVkIGVhc2lseSB1c2luZw0KdGhlIHByZWZpeCBpbmZvcm1hdGlvbiBvZiB0aGUgSEEg YWRkcmVzcyB3aXRob3V0IHVzaW5nIHRoZSBJS0V2MiBwcm9jZXNzaW5nIGJldHdlZW4NCnRoZSBN TiBhbmQgSEEuIEFuZCBtb3JlIG9uIHRoaXMsIHRoZSBJS0V2MiBwcm9jZXNzaW5nIGlzIHBlcmZv cm1lZCB1c2luZyBjZXJ0aWZpY2F0ZXMgd2l0aG91dA0KdXNpbmcgdGhlIGR5bmFtaWNhbGx5IGFz c2lnbmVkIHNlY3VyaXR5IGtleWluZyBtYXRlcmlhbC4NCkkgdGhpbmsgdGhhdCB0aGUgZnJhbWV3 b3JrIGNhbiBiZSB1c2VkIGZvciBhIGdlbmVyYWwgYXV0aGVudGljYXRpb24gYW5kIGF1dGhvcml6 YXRpb24gcHJvY2Vzc2luZw0KZm9yIGEgTU4gYnV0LCBJTUhPIGl0IGlzIG5vdCBzbyByZWxldmFu dCB0byB0aGUgTUlQdjYgYm9vdHN0cmFwcGluZy4NCg0KQUZBSUssIHRoZSBib290c3RyYXBwaW5n IGlzIGZvciBhIGR5bmFtaWMgY29uZmlndXJhdGlvbiBvZiBIQSwgaG9tZSBhZGRyZXNzIGFuZCBz ZWN1cml0eQ0Ka2V5aW5nIG1hdGVyaWFsIHRvIHN1cHBvcnQgdGhlIE1OJ3MgaW5pdGlhbCBjb25m aWd1cmF0aW9uIHNldC11cC4NCg0KLS1KdW5naG9vbg0KDQoNCg0KDQoNCg== --===============1769364356== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============1769364356==-- From mip6-bounces@ietf.org Mon Feb 21 08:05:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22284 for ; Mon, 21 Feb 2005 08:05:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3DcA-0000JT-3j for mip6-web-archive@ietf.org; Mon, 21 Feb 2005 08:28:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3CVT-0006EM-8a; Mon, 21 Feb 2005 07:17:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Bg2-0006Rw-CO for mip6@megatron.ietf.org; Mon, 21 Feb 2005 06:24:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13091 for ; Mon, 21 Feb 2005 06:24:27 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3C2D-0005w2-OY for mip6@ietf.org; Mon, 21 Feb 2005 06:47:30 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1LBO6Oc029099; Mon, 21 Feb 2005 20:24:06 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1LBO5sd027093; Mon, 21 Feb 2005 20:24:05 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1LBO4s5027078; Mon, 21 Feb 2005 20:24:04 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1LBO4hr010136; Mon, 21 Feb 2005 20:24:04 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1LBO43c010130; Mon, 21 Feb 2005 20:24:04 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1LBO4XW025887; Mon, 21 Feb 2005 20:24:04 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1LBO36W009606; Mon, 21 Feb 2005 20:24:03 +0900 (JST) Received: from ime.m.ecl.ntt.co.jp (ime0.m.ecl.ntt.co.jp [129.60.5.143]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j1LBO36W009600; Mon, 21 Feb 2005 20:24:03 +0900 (JST) Received: from lab.ntt.co.jp by ime.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id UAA20186; Mon, 21 Feb 2005 20:24:02 +0900 (JST) Message-ID: <4219C54C.6040202@lab.ntt.co.jp> Date: Mon, 21 Feb 2005 20:26:04 +0900 From: Mayumi Yanagiya User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: ja MIME-Version: 1.0 To: James Kempf Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> <4214978D.7080005@lab.ntt.co.jp> <077c01c51516$58590520$016115ac@dcml.docomolabsusa.com> <42156B0E.20703@lab.ntt.co.jp> <095101c515e6$16bb4440$016115ac@dcml.docomolabsusa.com> In-Reply-To: <095101c515e6$16bb4440$016115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by tama5.ecl.ntt.co.jp id j1LBO6Oc029099 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Hello, Thank you for your reply. I agree that it will be complex to synchronize states. But, I'm not sure that configuration parameters will be exposed only=20 when AAA-H distributes to elements in visited network. As you mentioned,=20 IP address of home agent, home address of mobile node and IKE credential=20 are exposed to element in visited domain in DHCP case. But, if other=20 solution is applied, element in visited domain t, such as access router,=20 will be able to get those parameters except IKE credential. Did you point out that DHCP solution is easier for visited domain to get=20 parameters than other solution? I have one more question. If we apply DHCP solution to the well managed network, it doesn=92t cause= =20 problem? Best Regards, --Mayumi > Yanagiya-san, >=20 >=20 >> I agree that problems will be occurred when network providers don=92t >>have agreement. But I can=92t understand why the problems will be occur= red >>only in DHCP case. For example, in IKEv2 based solution, >> - if MN is assigned home agent in home network, HA aren=92t required >> inter-domain interface. >> - if MN assign home agent in local network, home agent will be require= d >> inter-domain interface to get some information such as IKE >> credential. >> >> I think that same problems will be occurred if there is no agreement >>between home network and local network. Is my opinion wrong? >=20 >=20 > There are more places for things to go wrong in the DHCP case. As I > mentioned in email to Yoshi, there needs to be some way to get the HA > addresses into the AAA-H when they change, then from the AAA-H to the N= AS in > the foreign domain, then from the NAS to the DHCP server, then from the= DHCP > server to the MN. That's a lot more places for things to go wrong. >=20 > jak >=20 >=20 >=20 --=20 *++++++++++++++++++++++++++++++++++++++++++ NTT Network Service Systems Laboratories Mayumi Yanagiya tel: +81 422 59 6783 fax: +81 422 59 5631 E-mail: yanagiya.mayumi@lab.ntt.co.jp +++++++++++++++++++++++++++++++++++++++++++* _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 21 16:11:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15578 for ; Mon, 21 Feb 2005 16:11:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3LCD-000533-67 for mip6-web-archive@ietf.org; Mon, 21 Feb 2005 16:34:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3JB7-0000t0-1L; Mon, 21 Feb 2005 14:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3HaS-0005DX-R7 for mip6@megatron.ietf.org; Mon, 21 Feb 2005 12:43:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24525 for ; Mon, 21 Feb 2005 12:43:05 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Hwg-0008BO-Qn for mip6@ietf.org; Mon, 21 Feb 2005 13:06:12 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1LHh3413806 for ; Mon, 21 Feb 2005 19:43:03 +0200 (EET) X-Scanned: Mon, 21 Feb 2005 19:43:00 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1LHh0aD028478 for ; Mon, 21 Feb 2005 19:43:00 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 002kfSoD; Mon, 21 Feb 2005 19:42:59 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1LHgWM01807 for ; Mon, 21 Feb 2005 19:42:32 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 21 Feb 2005 11:42:27 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Feb 2005 11:42:25 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C844@daebe101.NOE.Nokia.com> Thread-Topic: Draft agenda of meeting at IETF62 thread-index: AcUYPLQV+46QqH0tTrGbdIYhS2f6yw== To: X-OriginalArrivalTime: 21 Feb 2005 17:42:27.0092 (UTC) FILETIME=[B56E0D40:01C5183C] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Draft agenda of meeting at IETF62 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable If you had sent a request for a slot and do not see it on the agenda below, please send me an email. -Basavaraj Draft Agenda of MIP6 WG meeting at IETF62 Monday March 7th, 1930-2200 ------------------------------------------ 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins 2. WG status update Chairs 20 Mins MIB I-D IKEv2 I-D Auth I-D Bootstrap PS 3. MIP6 Advance API issues Samita C. 10 Mins 4. MIP6-AAA Frameworks Alper Yegin 10 Mins Email thread on ML and I-D: draft-yegin-mip6-aaa-fwk-00 =20 5. Discussion of how to proceed with=20 I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt 20 Mins Giaretta Gerardo 6. MIP6 Bootstrapping 20 Mins I-D: draft-chakrabarti-mip6-bmip-00 James Kempf 6. PF_KEY Extension as an Interface between MIP6 and IPsec/IKE I-D: draft-sugimoto-mip6-pfkey-migrate-00 15 Mins Shinta Sugimoto 7. Location privacy in MIP6 Rajeev Koodli 15 Mins I-D: draft-koodli-mip6-location-privacy-00.txt =20 draft-koodli-mip6-location-privacy-solutions-00.txt =20 8. A Scheme of Mobile Firewall in MIP6 Qiu Ying 10 Mins I-D: draft-qiu-mip6-mobile-firewall-00.txt Time permitting: 9. Discussion of other I-Ds of possible interest to WG: MOMIPRIV Wassim Haddad draft-haddad-momipriv-problem-statement-01.txt =20 draft-haddad-momipriv-threat-model-00.txt=20 10. 6th TAHI and Connectathon 2005 Yukiyo Akisada _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 21 18:50:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00374 for ; Mon, 21 Feb 2005 18:50:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Ng1-0000Tk-BB for mip6-web-archive@ietf.org; Mon, 21 Feb 2005 19:13:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Kuy-0000iM-Bc; Mon, 21 Feb 2005 16:16:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Jlg-0005ic-Lz for mip6@megatron.ietf.org; Mon, 21 Feb 2005 15:02:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07499 for ; Mon, 21 Feb 2005 15:02:49 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3K7v-0003D6-7k for mip6@ietf.org; Mon, 21 Feb 2005 15:25:56 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0ICA00I012BSVL@mailout3.samsung.com> for mip6@ietf.org; Tue, 22 Feb 2005 05:02:16 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ICA005NG2BSH0@mailout3.samsung.com> for mip6@ietf.org; Tue, 22 Feb 2005 05:02:16 +0900 (KST) Received: from Alperyegin ([105.253.155.27]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0ICA007U72BPSH@mmp2.samsung.com> for mip6@ietf.org; Tue, 22 Feb 2005 05:02:16 +0900 (KST) Date: Mon, 21 Feb 2005 12:02:07 -0800 From: Alper Yegin To: mip6@ietf.org Message-id: <200201c51850$3a6f2520$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7BIT Subject: [Mip6] FW: MIP6 bootstrapping solution sets X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7BIT Not sure if this appeared on the list... resending. -----Original Message----- From: Alper Yegin [mailto:alper.yegin@samsung.com] Sent: Thursday, February 17, 2005 5:48 PM To: 'mip6@ietf.org' Subject: MIP6 bootstrapping solution sets As I have said before, MIP6-AAA framework discussion is highly related to MIP6 bootstrapping problem space, but they are not the same things. Not all MIP6-AAA frameworks can solve the bootstrapping problem single handedly (e.g., fwk4 relies on MN knowing its HA); and things like accounting has nothing to do with bootstrapping. MN learning its HA or home addresses, generating a dynamic SA with its HA using a AAA process are the overlaps between the two subjects. Let's also note that it is not likely we'd come up with a single solution that solves the problem in any deployment scenarios. We are likely to come up with multiple solutions, each possibly consisting of more than one component. Having said these, here is an attempt to capture solution sets. A set has to generate all of the HA, HoA, and MN-HA SA parameters. Please provide additions and modifications. I'm likely to have missed some. HA discovery HoA discovery MN-HA SA generation ------------ ------------- ------------------- (a) - via DNS - IKEv2 - MIP6-AAA Fwk 4 - RFC3775 (anycast) - mip6-mn-ident-option (b) - PANA/DHCP with NAS, - PANA/DHCP - MIP6-AAA Fwk 4 coupled with - IKEv2 - PANA/DHCP + MIP6-AAA MIP6-AAA Fwk 2 - mip6-mn-ident-option Fwk 2 (for MN); MIP6-AAA Fwk 4 (for HA) (c) - MIP6-AAA Fwk 1 - MIP6-AAA Fwk 1 - MIP6-AAA Fwk 1(for MN); - IKEv2 MIP6-AAA Fwk 4(for HA) - mip6-mn-ident-option In a set (e.g., a, b, or c), any one of the alternatives listed under one column can be used with others under the other columns. Alper _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Tue Feb 22 09:51:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07352 for ; Tue, 22 Feb 2005 09:51:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3bkJ-0007Ny-Oq for mip6-web-archive@ietf.org; Tue, 22 Feb 2005 10:14:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3MND-00042J-Ds; Mon, 21 Feb 2005 17:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3KV5-0004w5-Ti; Mon, 21 Feb 2005 15:49:51 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13732; Mon, 21 Feb 2005 15:49:50 -0500 (EST) Message-Id: <200502212049.PAA13732@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Feb 2005 15:49:50 -0500 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-firewalls-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 and Firewalls Problem statement Author(s) : F. Le, et al. Filename : draft-ietf-mip6-firewalls-01.txt Pages : 22 Date : 2005-2-21 Firewalls are an integral aspect of a majority of IP networks today given the state of security in the Internet, threats and vulnerabilities to data networks. IP networks today are predominantly based on IPv4 technology and hence firewalls have been designed for these networks. Deployment of IPv6 networks is currently progressing, albeit at a slower pace. Firewalls for IPv6 networks are still maturing and in development. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-firewalls-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-mip6-firewalls-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-mip6-firewalls-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: <2005-2-21151853.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-firewalls-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-firewalls-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-21151853.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Feb 23 01:00:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15406 for ; Wed, 23 Feb 2005 01:00:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3pw3-0003Rn-5Z for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 01:23:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kfk-0004VE-8k; Tue, 22 Feb 2005 19:46:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3dQU-000314-DL for mip6@megatron.ietf.org; Tue, 22 Feb 2005 12:02:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22685 for ; Tue, 22 Feb 2005 12:01:53 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3dma-0002y6-Up for mip6@ietf.org; Tue, 22 Feb 2005 12:25:13 -0500 Message-ID: <005c01c51900$5b7a4000$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alpesh" , , References: <200502191451.j1JEp2uC026369@sj-core-1.cisco.com> Subject: Re: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt Date: Tue, 22 Feb 2005 09:02:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Alpesh, I'm comfortable keeping the document in one piece, as long as the problem statement, architecture, and requirements themes are clearly separated. I think the problem statement itself could probably be done in one section. Actually, the archtecture and requirements parts are in some sense more interesting than the problem statement, since they're defining a model for Mobile IP roaming that I believe will be quite valuable to wireless service providers. jak ----- Original Message ----- From: "Alpesh" To: ; ; Sent: Saturday, February 19, 2005 6:51 AM Subject: RE: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt > James: > > I tend to agree, but let me recall - wasn't the goal of the design team to > develop a problem statement - state what is the goal of bootstrap, what are > the operating parameters and what should be the constraints? > > I am definitely open to reorganize the document as John originally > suggested. I don't oppose to break up the document either - my concern is > losing information/context in moving from one to many. Problem statements > dispersed over multiple docs are typically hard to capture, IMHO. > > Still open to suggestions. > > -a > > > -----Original Message----- > > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > > Behalf Of john.loughney@nokia.com > > Sent: Friday, February 18, 2005 9:56 PM > > To: kempf@docomolabs-usa.com; mip6@ietf.org > > Subject: RE: [Mip6] Overall LC comment on > > draft-ietf-mip6-bootstrap-ps-01.txt > > > > Hi James, > > > > > As John Loughney brought up, the draft is a bit long for a problem > > > statement. Actually, I think the draft is more a mix of problem > > > statement, functional architecture, and requirements. It might be > > > worthwhile to at least separate out the draft into these > > three parts, > > > to simplify and condense the problem statement and group the other > > > parts more coherently together. draft-giaretta-mip6-aaa-ha-goals, > > > which, despite its title, deals with similar issues on the > > back end, > > > actually does a pretty good job of separating out these three parts > > > stylistically, though of course the content is different. > > > > > > The other possibility would be to separate the draft into two, one > > > for the problem statement and one for the requirements and > > functional architecture. > > > If that is done, I think it is very important that all the > > content in > > > the current functional architecture and requirements parts of the > > > draft not get lost (in the past, I've seem parts of drafts get lost > > > when they are so separated). > > > > I'm comfortable with either solutions, I do think that the > > document has a lot of useful information that shouldn't get > > lost. I think if we took your later suggest, we could > > probably progress it rather quickly, I don't think we need > > additional information. > > > > John > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 01:00:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15455 for ; Wed, 23 Feb 2005 01:00:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3pwD-0003SP-EY for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 01:23:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kfn-0004Wo-Hh; Tue, 22 Feb 2005 19:46:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3dYb-00042f-Mw for mip6@megatron.ietf.org; Tue, 22 Feb 2005 12:10:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24138 for ; Tue, 22 Feb 2005 12:10:37 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3dv3-0003Hn-9y for mip6@ietf.org; Tue, 22 Feb 2005 12:33:57 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 22 Feb 2005 09:10:37 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,107,1107763200"; d="scan'208"; a="162664819:sNHT25244092" Received: from alpeshw2k03 (sjc-vpn1-466.cisco.com [10.21.97.210]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j1MH9pwN015136; Tue, 22 Feb 2005 09:09:52 -0800 (PST) Message-Id: <200502221709.j1MH9pwN015136@sj-core-3.cisco.com> From: "Alpesh" To: "'James Kempf'" , , Subject: RE: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt Date: Tue, 22 Feb 2005 09:09:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 thread-index: AcUZADnHLRi4AluQSLe93qXuGCCTywAAOzQQ In-Reply-To: <005c01c51900$5b7a4000$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: 7bit James: Agree. Do you think we should have a conference call before IETF or just wait to meet in person to close all issues? Either case, I would like to meet in person with concerned parties to reach a consensus sooner. -a > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Tuesday, February 22, 2005 9:03 AM > To: Alpesh; john.loughney@nokia.com; mip6@ietf.org > Subject: Re: [Mip6] Overall LC comment on > draft-ietf-mip6-bootstrap-ps-01.txt > > Alpesh, > > I'm comfortable keeping the document in one piece, as long as > the problem statement, architecture, and requirements themes > are clearly separated. I think the problem statement itself > could probably be done in one section. > Actually, the archtecture and requirements parts are in some > sense more interesting than the problem statement, since > they're defining a model for Mobile IP roaming that I believe > will be quite valuable to wireless service providers. > > jak > > > ----- Original Message ----- > From: "Alpesh" > To: ; ; > > Sent: Saturday, February 19, 2005 6:51 AM > Subject: RE: [Mip6] Overall LC comment on > draft-ietf-mip6-bootstrap-ps-01.txt > > > > James: > > > > I tend to agree, but let me recall - wasn't the goal of the > design team to > > develop a problem statement - state what is the goal of > bootstrap, what > are > > the operating parameters and what should be the constraints? > > > > I am definitely open to reorganize the document as John originally > > suggested. I don't oppose to break up the document either - > my concern is > > losing information/context in moving from one to many. > Problem statements > > dispersed over multiple docs are typically hard to capture, IMHO. > > > > Still open to suggestions. > > > > -a > > > > > -----Original Message----- > > > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > > > Behalf Of john.loughney@nokia.com > > > Sent: Friday, February 18, 2005 9:56 PM > > > To: kempf@docomolabs-usa.com; mip6@ietf.org > > > Subject: RE: [Mip6] Overall LC comment on > > > draft-ietf-mip6-bootstrap-ps-01.txt > > > > > > Hi James, > > > > > > > As John Loughney brought up, the draft is a bit long > for a problem > > > > statement. Actually, I think the draft is more a mix of problem > > > > statement, functional architecture, and requirements. > It might be > > > > worthwhile to at least separate out the draft into these > > > three parts, > > > > to simplify and condense the problem statement and > group the other > > > > parts more coherently together. > draft-giaretta-mip6-aaa-ha-goals, > > > > which, despite its title, deals with similar issues on the > > > back end, > > > > actually does a pretty good job of separating out these > three parts > > > > stylistically, though of course the content is different. > > > > > > > > The other possibility would be to separate the draft > into two, one > > > > for the problem statement and one for the requirements and > > > functional architecture. > > > > If that is done, I think it is very important that all the > > > content in > > > > the current functional architecture and requirements > parts of the > > > > draft not get lost (in the past, I've seem parts of > drafts get lost > > > > when they are so separated). > > > > > > I'm comfortable with either solutions, I do think that the > > > document has a lot of useful information that shouldn't get > > > lost. I think if we took your later suggest, we could > > > probably progress it rather quickly, I don't think we need > > > additional information. > > > > > > John > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 01:15:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16851 for ; Wed, 23 Feb 2005 01:15:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qAX-0003sM-Ge for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 01:38:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kfx-0004ZZ-04; Tue, 22 Feb 2005 19:46:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3eiS-0003n1-UM for mip6@megatron.ietf.org; Tue, 22 Feb 2005 13:25:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01049 for ; Tue, 22 Feb 2005 13:24:39 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3f4h-0005Pl-Me for mip6@ietf.org; Tue, 22 Feb 2005 13:48:00 -0500 Message-ID: <022e01c5190b$e6f02680$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Junghoon Jee" , References: <005e01c517f7$24385640$6b70fe81@FlyToWorld> Subject: Re: [Mip6] Question about MIPv6 deployment issues Date: Tue, 22 Feb 2005 10:25:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Junghoon, Currently, there is only one ISP in the US that is offering IPv6 service (NTT Verio) and nobody is offering Mobile IPv6. With so little deployment of IPv6, restricting discussion to current IPv4 deployed technology is way too pessimistic, IMHO. DNSSEC is an important, next generation security technology for DNS, just as IPv6 itself is next generation technology for the Internet, and Mobile IPv6 is for next generation mobility. So it makes sense to include DNSSEC into bootstrapping, if one of the proposed bootstrapping solution requires it, as we've suggested for bmip. Note that I say "one of" here, because I don't believe there will be just a single bootstrapping solution for all the scenerios covered by the problem statement. Some of them don't require DNSSEC, but they are limited to particular deployment situations. jak ----- Original Message ----- From: "Junghoon Jee" To: Sent: Monday, February 21, 2005 1:24 AM Subject: [Mip6] Question about MIPv6 deployment issues > Hello, ALL. > > During current discussions about MIPv6 bootstrapping, > I've come up with several questions related with this. > > 1. Is the MIPv6 bootstrapping is a deployment issue or not ? > > AFAIK, MIPv6 bootstrapping is for a wide spread deployment of MIPv6. > Currently MIP6 WG charters(http://www.ietf.org/html.charters/mip6-charter.html) says about this like below, > "bootstrap mechanism for setting up security associations between the Mobile Node (MN) and Home Agent (HA) that would enable easier deployment of Mobile IPv6." > > 2. If the MIPv6 bootstrapping mechanism is a deployment issue, > Do you agree that a bootstrapping solution should be designed minimizing the change > of the current infrastructure ? > > If your answer is YES, > I would like to ask you whether the use of DNSsec is a right choice for bootstrapping solution or not. > In my opinion, I think the use of DNSsec is NOT a right choice because the DNSsec is rarely deployed. > > I don't agree the approach of requiring the rarely deployed protocol > to support the MIPv6 bootstrapping because the MIPv6 bootstrapping mechanism is > originally for a easy deployment of the Mobile IPv6 protocol. > > IMHO, the deployment of the network access AAA infrastructure is more likely easier > than the wide spread deployment of DNSsec. > > 3. When we design a bootstrapping solution, do you agree to opening the > MN's HA address information to anyone without any restriction ? > > I think that the HA address information is not an public information that > can be easily accessible to anyone ,like using the public DNS. > > If you agree to open this, what about opening the HA address to the public web server > as Vijay made an example. > > --Junghoon > > > ---------------------------------------------------------------------------- ---- > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 01:22:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17638 for ; Wed, 23 Feb 2005 01:22:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qHZ-000456-9f for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 01:46:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kg6-0004bW-DV; Tue, 22 Feb 2005 19:46:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3fFK-0007TC-S6 for mip6@megatron.ietf.org; Tue, 22 Feb 2005 13:58:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04005 for ; Tue, 22 Feb 2005 13:58:39 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3fba-0006Pq-MI for mip6@ietf.org; Tue, 22 Feb 2005 14:21:59 -0500 Message-ID: <029001c51910$abb42c10$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Date: Tue, 22 Feb 2005 10:59:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Hi John, >> In addition to these attacks, there are other considerations that are >> important in achieving a good security design. Because mobility and network >> access authentication are separate services, any keys for these services >> need to be cryptographically separate, separately named, and have separate >> lifetimes that are not exceeded. This is necessary because a mobile host >> must be able to move from one serving (or roaming) network access provider >> to another without needing to change its mobility access provider. Finally, >> basic cryptographic processes must provide for multiple algorithms in order >> to accommodate the widely varying deployment needs. > >Could you more fully explain this statement. > >Because mobility and network access authentication are separate services ... > >One one level, in some deployments, these are indeed seperate. However, in some, >you want fate-sharing between the two - if either fails, the other should fail. >Since mobility is needed (in some deployments) network access authentication >is not sufficient. > >However, I think you might be suggesting that the network access provider may be >seperate from the mobility access provider, therefore they keying material needs >to be seperate. Is this more along the lines of what you mean? Actually, I think we want to keep the keys separate even if the network access provider and mobility service provider are the same. From a security standpoint, it makes sense to maintain separate keys, so that if one is compromised the other won't be. I suppose one could argue that "well, if the network access service is compromised, the user is so hosed, so it really doesn't matter if mobility service is compromised" but the othe way around is something different. If the mobility service key is compromised, the mobile host could stay put at the same place and re-establish secure mobility access service, as long as network access service is not compromised. If the two keys are the same, then the mobile host must go through re-establishing secure network access service before mobility service security can be repaired. Does this make sense? If so, perhaps the draft should make this point explicitly. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 01:45:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20411 for ; Wed, 23 Feb 2005 01:45:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3qdm-0004lA-90 for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 02:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgI-0004fS-7j; Tue, 22 Feb 2005 19:47:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3fuE-00040y-Ap for mip6@megatron.ietf.org; Tue, 22 Feb 2005 14:41:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08991 for ; Tue, 22 Feb 2005 14:40:56 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3gGV-0007kK-1L for mip6@ietf.org; Tue, 22 Feb 2005 15:04:16 -0500 Message-ID: <02d501c51916$90b0d4d0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Mayumi Yanagiya" References: <079501c50b08$a86878b0$291d9069@sisa.samsung.com> <01cd01c512e3$c4f4a250$016115ac@dcml.docomolabsusa.com> <20050216042627.GC18190@steelhead> <049501c51452$31823da0$016115ac@dcml.docomolabsusa.com> <20050216190443.GK18190@steelhead> <060501c5146d$3f27f060$016115ac@dcml.docomolabsusa.com> <20050217015704.GE25571@steelhead> <4214978D.7080005@lab.ntt.co.jp> <077c01c51516$58590520$016115ac@dcml.docomolabsusa.com> <42156B0E.20703@lab.ntt.co.jp> <095101c515e6$16bb4440$016115ac@dcml.docomolabsusa.com> <4219C54C.6040202@lab.ntt.co.jp> Subject: Re: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Tue, 22 Feb 2005 11:41:49 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable >I agree that it will be complex to synchronize states. >But, I'm not sure that configuration parameters will be exposed only >when AAA-H distributes to elements in visited network. As you mentioned, >IP address of home agent, home address of mobile node and IKE credential >are exposed to element in visited domain in DHCP case. But, if other >solution is applied, element in visited domain t, such as access router, >will be able to get those parameters except IKE credential. >Did you point out that DHCP solution is easier for visited domain to get >parameters than other solution? Routers won't have access to the contents if they are encrypted. For the DHCP solution, the NAS in the visited domain has to manage the informatio= n. >I have one more question. >If we apply DHCP solution to the well managed network, it doesn=92t caus= e >problem? Like I said, for telephony-style networks, where both the home and visite= d networks believe they can trust each other, might be OK with such a solution. But it is not a solution for the Internet as a whole. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 02:53:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04837 for ; Wed, 23 Feb 2005 02:53:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3rhF-0007SP-9e for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 03:16:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgg-0004mz-Sl; Tue, 22 Feb 2005 19:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3gmY-0007Lz-Fd for mip6@megatron.ietf.org; Tue, 22 Feb 2005 15:37:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16856 for ; Tue, 22 Feb 2005 15:37:07 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3h8t-000138-Ai for mip6@ietf.org; Tue, 22 Feb 2005 16:00:28 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0ICB00401YKVFZ@mailout3.samsung.com> for mip6@ietf.org; Wed, 23 Feb 2005 05:36:31 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ICB0095XYKVCX@mailout3.samsung.com> for mip6@ietf.org; Wed, 23 Feb 2005 05:36:31 +0900 (KST) Received: from Alperyegin ([105.144.29.41]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ICB00IFSYKTM5@mmp1.samsung.com> for mip6@ietf.org; Wed, 23 Feb 2005 05:36:31 +0900 (KST) Date: Tue, 22 Feb 2005 12:36:29 -0800 From: Alper Yegin Subject: RE: [Mip6] Question about mip6-aaa framework 4 In-reply-to: <005a01c517f6$e41fcc50$6b70fe81@FlyToWorld> To: "'Junghoon Jee'" , mip6@ietf.org Message-id: <234101c5191e$313a6130$291d9069@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7BIT X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7BIT Hi Junghoon, > => What's the exact meaning of assumption of knowing the HA ? > Is this mean that the pre-configuration of the HA address to the MN ? It might be preconfigured, or learned via some other mechanism (e.g., DNS, DHCP, PANA, etc.) > I would like to repeat my previous comments about this for clarity because > there is no answer > about this. > "As I know, dynamic HA assignment is owing to the issues of the home agent > discovery, > independent network management, local home agents and ease of deployment > as specified in the draft-ietf-mip6-bootstrap-ps-01.txt. Also it is very > related with the home address assignment." > > If the assumption means pre-configuration of HA address, > I have a question whether the framework 4 is for a MIPv6 bootstrapping or > not. Fwk 4 provides MN-HA SA generation. Therefore it solves a subset of the "bootstrapping" problem. > If the HA address is pre-configured, the HoA address can be generated > easily using > the prefix information of the HA address without using the IKEv2 > processing between > the MN and HA. And more on this, the IKEv2 processing is performed using > certificates without > using the dynamically assigned security keying material. > I think that the framework can be used for a general authentication and > authorization processing > for a MN but, IMHO it is not so relevant to the MIPv6 bootstrapping. > > AFAIK, the bootstrapping is for a dynamic configuration of HA, home > address and security > keying material to support the MN's initial configuration set-up. True. But the point is, not all bootstrapping issues have to be solved by the same protocol/mechanism. It's OK to solve different parts of the bootstrapping problem by using separate protocols/mechanisms. I tried to capture that in my message (subject: "MIP6 bootstrapping solution sets"). I hope this makes sense. Alper > > --Junghoon > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 03:37:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11832 for ; Wed, 23 Feb 2005 03:37:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3sOA-00013R-HJ for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 04:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kgv-0004qC-FO; Tue, 22 Feb 2005 19:47:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3go5-0007PR-IA for mip6@megatron.ietf.org; Tue, 22 Feb 2005 15:38:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17078 for ; Tue, 22 Feb 2005 15:38:32 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3hAF-0001GG-Rt for mip6@ietf.org; Tue, 22 Feb 2005 16:01:53 -0500 Message-ID: <033001c5191e$9ceb5970$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Tue, 22 Feb 2005 12:39:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Subject: [Mip6] Another Draft on HoA Privacy X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Hi folks, Here's another draft on HoA privacy: http://www.i2r.a-star.edu.sg/icsd/publications/draft-qiu-mip6-hiding-movement-00.txt Unfortunately, Qui didn't manage to get the draft in on time and the WG chairs tell us they don't want to make a habit of scheduling drafts that haven't been officially posted since there is often not enough time at MIP6 meetings for those that were. A request has been made for time at the Mobopts meeting to discuss this draft, but we've not heard yet on it. If you have comments, you can send them here or to Mobopts. jak _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 18:37:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14415 for ; Wed, 23 Feb 2005 18:37:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D46Qw-0000nx-Qx for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 19:00:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kjf-0005Rt-FR; Tue, 22 Feb 2005 19:50:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hDK-0001CA-7w; Tue, 22 Feb 2005 16:05:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21419; Tue, 22 Feb 2005 16:04:59 -0500 (EST) Message-Id: <200502222104.QAA21419@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:04:59 -0500 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture Author(s) : V. Devarapalli Filename : draft-ietf-mip6-ikev2-ipsec-01.txt Pages : 26 Date : 2005-2-22 This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-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-mip6-ikev2-ipsec-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-mip6-ikev2-ipsec-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: <2005-2-22160506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ikev2-ipsec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ikev2-ipsec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160506.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- From mip6-bounces@ietf.org Wed Feb 23 19:21:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23336 for ; Wed, 23 Feb 2005 19:21:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D477d-0003V3-NL for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 19:44:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3klr-00064C-R0; Tue, 22 Feb 2005 19:52:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Nkm-000851-Bm for mip6@megatron.ietf.org; Mon, 21 Feb 2005 19:18:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02960 for ; Mon, 21 Feb 2005 19:18:03 -0500 (EST) Received: from newyork.ucdavis.edu ([169.237.104.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3O6y-00019y-Gz for mip6@ietf.org; Mon, 21 Feb 2005 19:41:13 -0500 Received: from phaenicia.ucdavis.edu (phaenicia.ucdavis.edu [169.237.104.170]) by newyork.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j1M0I0De006020; Mon, 21 Feb 2005 16:18:01 -0800 (PST) Received: from phaenicia.ucdavis.edu (localhost [127.0.0.1]) by phaenicia.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j1M0I0ne007014; Mon, 21 Feb 2005 16:18:00 -0800 (PST) Received: (from www@localhost) by phaenicia.ucdavis.edu (8.12.10/8.12.9/Submit) id j1M0I0No007001; Mon, 21 Feb 2005 16:18:00 -0800 (PST) Date: Mon, 21 Feb 2005 16:18:00 -0800 (PST) Message-Id: <200502220018.j1M0I0No007001@phaenicia.ucdavis.edu> To: Basavaraj.Patil@nokia.com, mip6@ietf.org Subject: RE: [Mip6] Draft agenda of meeting at IETF62 From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Dear MIP6 WG Chair, I would like to request a time slot to discuss about draft-zhao-mip6-rr-ext-01 at the MIP6 WG meeting in Minneapolis. Thank you very much. Sincerely, fan > > If you had sent a request for a slot and do not see > it on the agenda below, please send me an email. > > -Basavaraj > > > > Draft Agenda of MIP6 WG meeting at IETF62 > Monday March 7th, 1930-2200 > ------------------------------------------ > > 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins > > 2. WG status update Chairs 20 Mins > MIB I-D > IKEv2 I-D > Auth I-D > Bootstrap PS > > 3. MIP6 Advance API issues Samita C. 10 Mins > > 4. MIP6-AAA Frameworks Alper Yegin 10 Mins > Email thread on ML and I-D: draft-yegin-mip6-aaa-fwk-00 > > 5. Discussion of how to proceed with > I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt 20 Mins > Giaretta Gerardo > > 6. MIP6 Bootstrapping 20 Mins > I-D: draft-chakrabarti-mip6-bmip-00 > James Kempf > > 6. PF_KEY Extension as an Interface between MIP6 and IPsec/IKE > I-D: draft-sugimoto-mip6-pfkey-migrate-00 15 Mins > Shinta Sugimoto > > 7. Location privacy in MIP6 Rajeev Koodli 15 Mins > I-D: draft-koodli-mip6-location-privacy-00.txt > draft-koodli-mip6-location-privacy-solutions-00.txt > > 8. A Scheme of Mobile Firewall in MIP6 Qiu Ying 10 Mins > I-D: draft-qiu-mip6-mobile-firewall-00.txt > > Time permitting: > 9. Discussion of other I-Ds of possible interest to WG: > MOMIPRIV Wassim Haddad > draft-haddad-momipriv-problem-statement-01.txt > draft-haddad-momipriv-threat-model-00.txt > > 10. 6th TAHI and Connectathon 2005 Yukiyo Akisada > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 19:21:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23376 for ; Wed, 23 Feb 2005 19:21:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D477h-0003VQ-Q7 for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 19:44:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3klr-000647-CX; Tue, 22 Feb 2005 19:52:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3NhY-0007V9-Fh for mip6@megatron.ietf.org; Mon, 21 Feb 2005 19:14:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02757 for ; Mon, 21 Feb 2005 19:14:43 -0500 (EST) Received: from havana.ucdavis.edu ([169.237.104.156]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3O3k-00014k-Hk for mip6@ietf.org; Mon, 21 Feb 2005 19:37:53 -0500 Received: from celerio.ucdavis.edu (celerio.ucdavis.edu [169.237.104.178]) by havana.ucdavis.edu (8.12.10/8.12.9/it-defang-5.2.0) with ESMTP id j1M0EeFr021044; Mon, 21 Feb 2005 16:14:41 -0800 (PST) Received: from celerio.ucdavis.edu (localhost [127.0.0.1]) by celerio.ucdavis.edu (8.12.10/8.12.9/UCD5.2.0) with ESMTP id j1M0EeDh011581; Mon, 21 Feb 2005 16:14:40 -0800 (PST) Received: (from www@localhost) by celerio.ucdavis.edu (8.12.10/8.12.9/Submit) id j1M0EemB011580; Mon, 21 Feb 2005 16:14:40 -0800 (PST) Date: Mon, 21 Feb 2005 16:14:40 -0800 (PST) Message-Id: <200502220014.j1M0EemB011580@celerio.ucdavis.edu> To: mip6@ietf.org From: "Fan Zhao" X-Errors-To: fanzhao@blue.ucdavis.edu X-Mailer: Geckomail-b16 X-Originating-IP: [128.120.178.196] X-User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) X-Scanned-By: MIMEDefang 2.49 on 169.237.104.195 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Mip6] draft-zhao-mip6-rr-ext-01 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Dear all, We submit draft-zhao-mip6-rr-ext-00.txt last week and just update it with a 01 version. Both versions can be found in the following URL: http://wwwcsif.cs.ucdavis.edu/~zhaofa/MIP6/ if they have not shown up in the Internet-Drafts directories. Abstract This draft proposes some extensions to the Return Routability Test in MIP6 to address the location privacy issue and enable CN as well as MN to promptly detect the attack that could compromise the security of MIP6 RO mechanism. Your comments are welcome. Regards, fan zhao _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 19:21:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23626 for ; Wed, 23 Feb 2005 19:21:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D478I-0003aA-SZ for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 19:45:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3yir-0001WQ-NW; Wed, 23 Feb 2005 10:46:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3yiq-0001VF-Ev for mip6@megatron.ietf.org; Wed, 23 Feb 2005 10:46:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00563 for ; Wed, 23 Feb 2005 10:46:24 -0500 (EST) Received: from palrel13.hp.com ([156.153.255.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3z5H-0005mE-7x for mip6@ietf.org; Wed, 23 Feb 2005 11:09:55 -0500 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by palrel13.hp.com (Postfix) with ESMTP id 194791C07596 for ; Wed, 23 Feb 2005 07:46:25 -0800 (PST) Received: from kitche.zk3.dec.com (kitche1.zk3.dec.com [16.140.160.161]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id B20282359 for ; Wed, 23 Feb 2005 07:46:24 -0800 (PST) Received: from [127.0.0.1] by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j1NFkLS0001042339; Wed, 23 Feb 2005 10:46:22 -0500 (EST) Message-ID: <421CA509.2010400@hp.com> Date: Wed, 23 Feb 2005 10:45:13 -0500 From: Brian Haley Organization: HP Linux and Open Source Lab User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Content-Type: multipart/mixed; boundary="------------010206020907010805010509" X-Spam-Score: 0.1 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Subject: [Mip6] [Fwd: I-D ACTION:draft-haley-mip6-mh-signaling-00.txt] X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a This is a multi-part message in MIME format. --------------010206020907010805010509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, This is a draft I submitted last week to try and create a generic HA/MN signaling message. The exact contents of the message would be defined in other drafts (for example draft-deng-mip6-ha-loadbalance-02.txt and draft-kempf-mip6-ha-alert-00.txt). The only comment so far is that there be both secure and insecure message types. Any other comments are appreciated. Thanks, -Brian --------------010206020907010805010509 Content-Type: message/rfc822; name="I-D ACTION:draft-haley-mip6-mh-signaling-00.txt" Content-Disposition: inline; filename="I-D ACTION:draft-haley-mip6-mh-signaling-00.txt" Received: from yquarry.zk3.dec.com by kitche.zk3.dec.com (8.11.1/1.1.27.5/27Oct00-1235PM) id j1FHCbs0001835301; Tue, 15 Feb 2005 12:12:37 -0500 (EST) Received: from taynzmail03.nz-tay.cpqcorp.net by yquarry.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id MAA21096; Tue, 15 Feb 2005 12:12:37 -0500 (EST) Received: from zmamail01.zma.compaq.com (zmamail01.nz-tay.cpqcorp.net [161.114.72.101]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 12A482DC3 for ; Tue, 15 Feb 2005 12:12:37 -0500 (EST) Received: from atarelrim03.atl.hp.com (atarelrim03.atl.hp.com [192.151.27.11]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id D315E16D1B for ; Tue, 15 Feb 2005 12:12:36 -0500 (EST) Received: from atarelrim03.atl.hp.com (localhost [127.0.0.1]) by receive-from-antispam-filter (Postfix) with SMTP id B369432E49; Tue, 15 Feb 2005 12:12:36 -0500 (EST) Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by atarelrim03.atl.hp.com (Postfix) with ESMTP id 0CED132E5F; Tue, 15 Feb 2005 12:12:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15Hm-0003w6-L3; Tue, 15 Feb 2005 11:10:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D14Wt-0007zC-Rc for i-d-announce@megatron.ietf.org; Tue, 15 Feb 2005 10:22:23 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11023 for ; Tue, 15 Feb 2005 10:22:21 -0500 (EST) Message-Id: <200502151522.KAA11023@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 15 Feb 2005 10:22:21 -0500 Subject: I-D ACTION:draft-haley-mip6-mh-signaling-00.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-Post: List-Help: List-Subscribe: , Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.0.3.0, Antispam-Data: 2005.2.15.7 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Header Signaling Message Author(s) : B. Haley Filename : draft-haley-mip6-mh-signaling-00.txt Pages : 6 Date : 2005-2-14 This document specifies a new Mobility Header message type that can be used between a mobile node and home agent to signal an event that requires attention. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-haley-mip6-mh-signaling-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-haley-mip6-mh-signaling-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-haley-mip6-mh-signaling-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: <2005-2-15103401.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-haley-mip6-mh-signaling-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-haley-mip6-mh-signaling-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-15103401.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart-- --------------010206020907010805010509 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------010206020907010805010509-- From mip6-bounces@ietf.org Wed Feb 23 20:52:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21713 for ; Wed, 23 Feb 2005 20:52:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48XT-0003hU-QR for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 21:15:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3p0R-0006gm-QS; Wed, 23 Feb 2005 00:24:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3p0N-0006g2-4B for mip6@megatron.ietf.org; Wed, 23 Feb 2005 00:24:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11617 for ; Wed, 23 Feb 2005 00:24:02 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3pMt-0002Gx-0h for mip6@ietf.org; Wed, 23 Feb 2005 00:47:29 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N5O1G10018; Wed, 23 Feb 2005 07:24:01 +0200 (EET) X-Scanned: Wed, 23 Feb 2005 07:36:28 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1N5aSSg010300; Wed, 23 Feb 2005 07:36:28 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00zoniOz; Wed, 23 Feb 2005 07:36:26 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N5NHM13970; Wed, 23 Feb 2005 07:23:17 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 07:23:17 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 07:23:16 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 07:23:16 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Date: Wed, 23 Feb 2005 07:23:16 +0200 Message-ID: Thread-Topic: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Thread-Index: AcUZEL1xyoEnlcliSzOreXDMiYm2igAVc1HA To: , X-OriginalArrivalTime: 23 Feb 2005 05:23:16.0927 (UTC) FILETIME=[C77F6CF0:01C51967] X-Spam-Score: 0.3 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Hi James, > Actually, I think we want to keep the keys separate even if the = network > access provider and mobility service provider are the same. From a = security > standpoint, it makes sense to maintain separate keys, so that if one = is > compromised the other won't be. I suppose one could argue that "well, = if > the network access service is compromised, the user is so hosed, so it > really doesn't matter if mobility service is compromised" but the othe = way > around is something different. If the mobility service key is = compromised, > the mobile host could stay put at the same place and re-establish = secure > mobility access service, as long as network access service is not > compromised. If the two keys are the same, then the mobile host must = go > through re-establishing secure network access service before mobility > service security can be repaired. >=20 > Does this make sense? If so, perhaps the draft should make this point > explicitly. I think we should make this point explicitly. To modify your proposed = text: >> In addition to these attacks, there are other considerations that are >> important in achieving a good security design. Because mobility and = network >> access authentication are separate services, any keys for these = services >> need to be cryptographically separate, separately named, and have = separate >> lifetimes that are not exceeded. This is necessary because a mobile = host >> must be able to move from one serving (or roaming) network access = provider >> to another without needing to change its mobility access provider. = Finally, >> basic cryptographic processes must provide for multiple algorithms in = order >> to accommodate the widely varying deployment needs. In addition to these attackes, there are other considerstions that are = important in achieving a good security design. As mobility and network access = authentication are seperate services, keys for these services need to be = cryptographically=20 seperate, seperately named and have seperate lifetimes. This is needed = because if one service is compromised, the other service is not. This is = necessary=20 so that a mobile host can move from one serving (or roaming) network = access=20 provider to another without needing to change its mobility access = provider.=20 Finally, basic cryptographic processes must provide for multiple = algorithms in order to accommodate the widely varying deployment needs. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 21:19:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01465 for ; Wed, 23 Feb 2005 21:19:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48y9-0006iK-Hr for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 21:43:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3zgH-0006rj-4r; Wed, 23 Feb 2005 11:48:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3zgF-0006r1-9U for mip6@megatron.ietf.org; Wed, 23 Feb 2005 11:48:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09336 for ; Wed, 23 Feb 2005 11:48:03 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D402u-0008CR-2y for mip6@ietf.org; Wed, 23 Feb 2005 12:11:35 -0500 Message-ID: <04a501c519c7$95e5d160$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Alpesh" , , References: <200502221709.j1MH9pwN015136@sj-core-3.cisco.com> Subject: Re: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt Date: Wed, 23 Feb 2005 08:48:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Alpesh, Let's arrange a meeting prior to the MIP6 meeting at IETF. F2F is higher bandwidth. jak ----- Original Message ----- From: "Alpesh" To: "'James Kempf'" ; ; Sent: Tuesday, February 22, 2005 9:09 AM Subject: RE: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt > James: > > Agree. Do you think we should have a conference call before IETF or just > wait to meet > in person to close all issues? Either case, I would like to meet in person > with concerned parties to reach a consensus sooner. > > -a > > > -----Original Message----- > > From: James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: Tuesday, February 22, 2005 9:03 AM > > To: Alpesh; john.loughney@nokia.com; mip6@ietf.org > > Subject: Re: [Mip6] Overall LC comment on > > draft-ietf-mip6-bootstrap-ps-01.txt > > > > Alpesh, > > > > I'm comfortable keeping the document in one piece, as long as > > the problem statement, architecture, and requirements themes > > are clearly separated. I think the problem statement itself > > could probably be done in one section. > > Actually, the archtecture and requirements parts are in some > > sense more interesting than the problem statement, since > > they're defining a model for Mobile IP roaming that I believe > > will be quite valuable to wireless service providers. > > > > jak > > > > > > ----- Original Message ----- > > From: "Alpesh" > > To: ; ; > > > > Sent: Saturday, February 19, 2005 6:51 AM > > Subject: RE: [Mip6] Overall LC comment on > > draft-ietf-mip6-bootstrap-ps-01.txt > > > > > > > James: > > > > > > I tend to agree, but let me recall - wasn't the goal of the > > design team to > > > develop a problem statement - state what is the goal of > > bootstrap, what > > are > > > the operating parameters and what should be the constraints? > > > > > > I am definitely open to reorganize the document as John originally > > > suggested. I don't oppose to break up the document either - > > my concern is > > > losing information/context in moving from one to many. > > Problem statements > > > dispersed over multiple docs are typically hard to capture, IMHO. > > > > > > Still open to suggestions. > > > > > > -a > > > > > > > -----Original Message----- > > > > From: mip6-bounces@ietf.org [mailto:mip6-bounces@ietf.org] On > > > > Behalf Of john.loughney@nokia.com > > > > Sent: Friday, February 18, 2005 9:56 PM > > > > To: kempf@docomolabs-usa.com; mip6@ietf.org > > > > Subject: RE: [Mip6] Overall LC comment on > > > > draft-ietf-mip6-bootstrap-ps-01.txt > > > > > > > > Hi James, > > > > > > > > > As John Loughney brought up, the draft is a bit long > > for a problem > > > > > statement. Actually, I think the draft is more a mix of problem > > > > > statement, functional architecture, and requirements. > > It might be > > > > > worthwhile to at least separate out the draft into these > > > > three parts, > > > > > to simplify and condense the problem statement and > > group the other > > > > > parts more coherently together. > > draft-giaretta-mip6-aaa-ha-goals, > > > > > which, despite its title, deals with similar issues on the > > > > back end, > > > > > actually does a pretty good job of separating out these > > three parts > > > > > stylistically, though of course the content is different. > > > > > > > > > > The other possibility would be to separate the draft > > into two, one > > > > > for the problem statement and one for the requirements and > > > > functional architecture. > > > > > If that is done, I think it is very important that all the > > > > content in > > > > > the current functional architecture and requirements > > parts of the > > > > > draft not get lost (in the past, I've seem parts of > > drafts get lost > > > > > when they are so separated). > > > > > > > > I'm comfortable with either solutions, I do think that the > > > > document has a lot of useful information that shouldn't get > > > > lost. I think if we took your later suggest, we could > > > > probably progress it rather quickly, I don't think we need > > > > additional information. > > > > > > > > John > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Wed Feb 23 22:21:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24930 for ; Wed, 23 Feb 2005 22:21:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D49vv-00054T-IZ for mip6-web-archive@ietf.org; Wed, 23 Feb 2005 22:45:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3zXU-0004sw-Qy; Wed, 23 Feb 2005 11:39:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3zXU-0004rg-0y for mip6@megatron.ietf.org; Wed, 23 Feb 2005 11:39:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07722 for ; Wed, 23 Feb 2005 11:38:37 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3ztl-0007kW-Lc for mip6@ietf.org; Wed, 23 Feb 2005 12:02:09 -0500 Message-ID: <044401c519c6$4184d310$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Date: Wed, 23 Feb 2005 08:39:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Sounds fine. jak ----- Original Message ----- From: To: ; Sent: Tuesday, February 22, 2005 9:23 PM Subject: RE: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Hi James, > Actually, I think we want to keep the keys separate even if the network > access provider and mobility service provider are the same. From a security > standpoint, it makes sense to maintain separate keys, so that if one is > compromised the other won't be. I suppose one could argue that "well, if > the network access service is compromised, the user is so hosed, so it > really doesn't matter if mobility service is compromised" but the othe way > around is something different. If the mobility service key is compromised, > the mobile host could stay put at the same place and re-establish secure > mobility access service, as long as network access service is not > compromised. If the two keys are the same, then the mobile host must go > through re-establishing secure network access service before mobility > service security can be repaired. > > Does this make sense? If so, perhaps the draft should make this point > explicitly. I think we should make this point explicitly. To modify your proposed text: >> In addition to these attacks, there are other considerations that are >> important in achieving a good security design. Because mobility and network >> access authentication are separate services, any keys for these services >> need to be cryptographically separate, separately named, and have separate >> lifetimes that are not exceeded. This is necessary because a mobile host >> must be able to move from one serving (or roaming) network access provider >> to another without needing to change its mobility access provider. Finally, >> basic cryptographic processes must provide for multiple algorithms in order >> to accommodate the widely varying deployment needs. In addition to these attackes, there are other considerstions that are important in achieving a good security design. As mobility and network access authentication are seperate services, keys for these services need to be cryptographically seperate, seperately named and have seperate lifetimes. This is needed because if one service is compromised, the other service is not. This is necessary so that a mobile host can move from one serving (or roaming) network access provider to another without needing to change its mobility access provider. Finally, basic cryptographic processes must provide for multiple algorithms in order to accommodate the widely varying deployment needs. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 00:13:57 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05616 for ; Thu, 24 Feb 2005 00:13:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Bgo-0000Ai-P1 for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 00:37:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3l2C-000069-J1; Tue, 22 Feb 2005 20:09:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3T5W-0004o5-Ah for mip6@megatron.ietf.org; Tue, 22 Feb 2005 01:00:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15527 for ; Tue, 22 Feb 2005 00:59:54 -0500 (EST) Received: from msg-mx3.usc.edu ([128.125.137.8] ident=sjes) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3TRq-0005kt-Lh for mip6@ietf.org; Tue, 22 Feb 2005 01:23:08 -0500 Received: from ceng.usc.edu ([128.125.72.78]) by msg-mx3.usc.edu (Sun Java System Messaging Server 6.1 HotFix 0.08 (built Dec 8 2004)) with ESMTP id <0ICA00I77TZSJZ90@msg-mx3.usc.edu> for mip6@ietf.org; Mon, 21 Feb 2005 21:59:52 -0800 (PST) Received: from localhost (anrg@localhost) by ceng.usc.edu (8.10.1/8.10.1/usc) with ESMTP id j1M5xpm25134 for ; Mon, 21 Feb 2005 21:59:51 -0800 (PST) Date: Mon, 21 Feb 2005 21:59:51 -0800 (PST) From: anrg To: mip6@ietf.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7BIT X-Mailman-Approved-At: Tue, 22 Feb 2005 20:09:47 -0500 Subject: [Mip6] ACM SenSys 2005 CFP X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7BIT ACM SenSys 2005: CALL FOR PAPERS November 2-4, 2005 http://sensys.csail.mit.edu/ The 3rd ACM Conference on Embedded Networked Sensor Systems (SenSys) is a highly selective single-track forum for the presentation of research results on systems issues in the emerging area of embedded, networked sensors. These distributed systems of smart sensors and actuators connecting computational capabilities to the physical world have the potential to revolutionize the way in which the real world is instrumented, monitored, and controlled. Such systems present a wide range of challenges to the system designer because of resource constraints, uncertainty, irregularity, and scale. SenSys provides a cross-disciplinary venue for researchers addressing the rich space of networked sensor system design issues to interact, present and exchange research results, and demonstrate their work in a hands-on research exhibition. We seek technical papers describing original, previously unpublished research results. Topics of interest include, but are not limited to, novel results in the following areas of research in sensor networks: - Sensor network architecture and protocols - Distributed coordination algorithms (e.g., for localization, time synchronization, clustering, topology control, etc.) - Failure resilience and fault isolation - Energy management - Operating systems - Data, information, and signal processing - Data storage - Distributed actuation and control - Programming methodology - Security and privacy - Network planning, provisioning, and deployment - Operational experience and testbeds - Experimental methodology (e.g., repeatable experimentation, measurement infrastructure, simulation, emulation, etc.) - Analysis of real-world systems and fundamental limits - Applications - Integration with other systems (e.g., Web-based information systems, process control, enterprise software, etc.) The conference time-line is as follows. All deadlines are firm. - Paper Registration & Abstract: April 1, 2005, Midnight Eastern Time - Paper Submission Deadline: April 8, 2005, Midnight Eastern - Time Notification of Paper Acceptance: July 1, 2005 - Camera Ready Paper Copy: August 25, 2005 CONFERENCE COMMITTEE ==================== General Chair: Jason Redi (BBN Technologies) Program Co-Chairs: Hari Balakrishnan (MIT), and Feng Zhao (Microsoft Research) Local Arrangements Chair: Curt Schurgers (UCSD) Publicity Co-Chairs: Bhaskar Krishnamachari (USC), and Wendi Heinzelman (University of Rochester) Publication Chair: Xenofon Koutsoukos (Vanderbilt University) Posters Co-Chairs: Matt Welsh (Harvard University) and John Byers (Boston University) Demos Co-Chairs: Chenyang Lu (Washington University in St. Louis) and Phil Gibbons (Intel Research) Web Site Chair: Michel Goraczko (MIT), Steering Committee: Deborah Estrin UCLA, Co Chair Victor Bahl Microsoft, SIGMOBILE Representative Taieb Znati University of Pittsburgh Craig Partridge BBN Technologies, SIGCOMM Representative _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 00:19:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07899 for ; Thu, 24 Feb 2005 00:19:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4BmO-0000rf-01 for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 00:43:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D46Ku-00026p-UJ; Wed, 23 Feb 2005 18:54:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D46Kt-000262-IG for mip6@megatron.ietf.org; Wed, 23 Feb 2005 18:54:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17258 for ; Wed, 23 Feb 2005 18:54:27 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D46hg-0001cg-4y for mip6@ietf.org; Wed, 23 Feb 2005 19:18:04 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1O0PSc06087 for ; Wed, 23 Feb 2005 16:25:28 -0800 X-mProtect: <200502240025> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141209.americas.nokia.com (172.18.141.209, claiming to be "[172.18.141.209]") by darkstar.iprg.nokia.com smtpdHTsGIv; Wed, 23 Feb 2005 16:25:26 PST Message-ID: <421D17A2.4020202@iprg.nokia.com> Date: Wed, 23 Feb 2005 15:54:10 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Subject: Re: [Fwd: [Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-01.txt] References: <421D174E.3050303@iprg.nokia.com> In-Reply-To: <421D174E.3050303@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit I meant version 01.. :) Vijay Devarapalli wrote: > hello all, > > heres version 02 of the MIP6 and IKEv2 spec. fixed many things > that werent correct in the first version. there are also more > details now available in the sections which describe the use > of IKEv2. > > reviews would be much appreciated. > > Vijay > > ------------------------------------------------------------------------ > > Subject: > [Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-01.txt > From: > Internet-Drafts@ietf.org > Date: > Tue, 22 Feb 2005 16:04:59 -0500 > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > CC: > mip6@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 IPv6 Working Group of the IETF. > > Title : Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture > Author(s) : V. Devarapalli > Filename : draft-ietf-mip6-ikev2-ipsec-01.txt > Pages : 26 > Date : 2005-2-22 > > This document describes Mobile IPv6 operation with the revised IPsec > architecture and IKEv2. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-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-mip6-ikev2-ipsec-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-mip6-ikev2-ipsec-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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 00:29:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11874 for ; Thu, 24 Feb 2005 00:29:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4BwI-00022w-JO for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 00:53:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3oRe-0001TD-5p; Tue, 22 Feb 2005 23:48:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3oRV-0001S8-VY for mip6@megatron.ietf.org; Tue, 22 Feb 2005 23:48:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04882 for ; Tue, 22 Feb 2005 23:48:01 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3oo3-0000fv-Aj for mip6@ietf.org; Wed, 23 Feb 2005 00:11:27 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N4m0n15603; Wed, 23 Feb 2005 06:48:00 +0200 (EET) X-Scanned: Wed, 23 Feb 2005 06:59:44 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1N4xivo028203; Wed, 23 Feb 2005 06:59:44 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00LVh6hy; Wed, 23 Feb 2005 06:59:42 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N4kaU26806; Wed, 23 Feb 2005 06:46:36 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 06:46:24 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 06:46:24 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt Date: Wed, 23 Feb 2005 06:46:23 +0200 Message-ID: Thread-Topic: [Mip6] Overall LC comment on draft-ietf-mip6-bootstrap-ps-01.txt Thread-Index: AcUZAGJoIW1LgRuPTiKhB+BxRPA1OAAYhoaA To: , , X-OriginalArrivalTime: 23 Feb 2005 04:46:24.0244 (UTC) FILETIME=[A0A2CB40:01C51962] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Alpesh & James, > I'm comfortable keeping the document in one piece, as long as the = problem > statement, architecture, and requirements themes are clearly = separated. I > think the problem statement itself could probably be done in one = section. > Actually, the archtecture and requirements parts are in some sense = more > interesting than the problem statement, since they're defining a model = for > Mobile IP roaming that I believe will be quite valuable to wireless = service > providers. I think that is a reasonable way forward; if clearly separated, I think = this would be OK with me. =20 John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 00:38:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15533 for ; Thu, 24 Feb 2005 00:38:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4C4z-0003EE-3Y for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 01:02:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3r6J-0003Ii-Kl; Wed, 23 Feb 2005 02:38:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3r6D-0003HW-SA for mip6@megatron.ietf.org; Wed, 23 Feb 2005 02:38:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02072 for ; Wed, 23 Feb 2005 02:38:14 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3rSm-0006jW-RM for mip6@ietf.org; Wed, 23 Feb 2005 03:01:41 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N7c4G00724; Wed, 23 Feb 2005 09:38:04 +0200 (EET) X-Scanned: Wed, 23 Feb 2005 09:35:51 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1N7ZpPC031022; Wed, 23 Feb 2005 09:35:51 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00zbVmUh; Wed, 23 Feb 2005 09:35:51 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1N7DUM18134; Wed, 23 Feb 2005 09:13:30 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 09:13:21 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Feb 2005 09:13:19 +0200 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="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Date: Wed, 23 Feb 2005 09:13:20 +0200 Message-ID: Thread-Topic: [Mip6] Consensus call: draft-giaretta-mip6-aaa-ha-goals-00.txt Thread-Index: AcUZdb1z3Xbpjh4TSi+HwQCo/mpZBwAAEXeA To: , X-OriginalArrivalTime: 23 Feb 2005 07:13:19.0853 (UTC) FILETIME=[2725F9D0:01C51977] X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, yohba@tari.toshiba.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable James, > >I have one more question. > >If we apply DHCP solution to the well managed network, it doesn=92t = cause > >problem? >=20 > Like I said, for telephony-style networks, where both the home and = visited > networks believe they can trust each other, might be OK with such a > solution. But it is not a solution for the Internet as a whole. Well, I think that this sollution isn't completely restricted to = telephony-style networks, unless you consider wireless ISP-style roaming as part of = telephony-style networks. There is considerable interest in providing managed roaming, = even with non-telecom providers. In RADext, we are seeing a number of = organizations and ISPs wanting better roaming infrastructure. I think this represents = a fairly significant potential deployment model for (M)IPv6, even if it isn't = exactly the traditional IETF model. So, I partly agree with you that this is a complex case, but I still = think it is a realistic case that should be addressed, just how to ensure the = level of complexity isn't too large. On the other hand, I would like to see a solution for the case where = this trust is not present. John _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 00:42:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16754 for ; Thu, 24 Feb 2005 00:42:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4C8h-0003e9-Hl for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 01:06:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3uJc-0001Pm-F8; Wed, 23 Feb 2005 06:04:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3uJY-0001PZ-UH for mip6@megatron.ietf.org; Wed, 23 Feb 2005 06:04:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02819 for ; Wed, 23 Feb 2005 06:04:11 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3ug7-0007LI-QQ for mip6@ietf.org; Wed, 23 Feb 2005 06:27:41 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0ICD00K492M951@dns1.cselt.it> for mip6@ietf.org; Wed, 23 Feb 2005 12:01:21 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 12:06:20 +0100 Date: Wed, 23 Feb 2005 12:03:41 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt To: James Kempf Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt thread-index: AcUZcbWCljHwATErST6s7H96/0rOQgAJKPig Content-Class: urn:content-classes:message X-OriginalArrivalTime: 23 Feb 2005 11:06:20.0156 (UTC) FILETIME=[B40EEBC0:01C51997] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable Hi James, please see below.. >=20 > Hi John, >=20 > >> In addition to these attacks, there are other=20 > considerations that are > >> important in achieving a good security design. Because mobility and > network > >> access authentication are separate services, any keys for=20 > these services > >> need to be cryptographically separate, separately named, and have > separate > >> lifetimes that are not exceeded. This is necessary because=20 > a mobile host > >> must be able to move from one serving (or roaming) network access > provider > >> to another without needing to change its mobility access provider. > Finally, > >> basic cryptographic processes must provide for multiple=20 > algorithms in > order > >> to accommodate the widely varying deployment needs. > > > >Could you more fully explain this statement. > > > >Because mobility and network access authentication are=20 > separate services > ... > > > >One one level, in some deployments, these are indeed=20 > seperate. However, in > some, > >you want fate-sharing between the two - if either fails, the=20 > other should > fail. > >Since mobility is needed (in some deployments) network access > authentication > >is not sufficient. > > > >However, I think you might be suggesting that the network=20 > access provider > may be > >seperate from the mobility access provider, therefore they=20 > keying material > needs > >to be seperate. Is this more along the lines of what you mean? >=20 > Actually, I think we want to keep the keys separate even if=20 > the network > access provider and mobility service provider are the same.=20 > From a security > standpoint, it makes sense to maintain separate keys, so that=20 > if one is > compromised the other won't be. I suppose one could argue=20 > that "well, if > the network access service is compromised, the user is so hosed, so it > really doesn't matter if mobility service is compromised" but=20 > the othe way > around is something different. If the mobility service key is=20 > compromised, > the mobile host could stay put at the same place and=20 > re-establish secure > mobility access service, as long as network access service is not > compromised. If the two keys are the same, then the mobile=20 > host must go > through re-establishing secure network access service before mobility > service security can be repaired. >=20 > Does this make sense? If so, perhaps the draft should make this point > explicitly. >=20 I think this makes sense. Even if the network access provider and the mobility service provider are the same, network access and mobility are different services. For this reason the keys must be kept separate and I agree we should mention this explicitly in the draft. Note that obviously you can exploit the network access keying material (i.e. EAP keying hierarchy) to derive cryptographically separated keys for mobility service. But this could be solution specific and I'm not sure we should mention it in the problem statement draft. --Gerardo > jak >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 01:12:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26808 for ; Thu, 24 Feb 2005 01:12:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CbL-0006ck-Ja for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 01:36:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D49eq-0005pf-TC; Wed, 23 Feb 2005 22:27:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D49eo-0005oF-Rh for mip6@megatron.ietf.org; Wed, 23 Feb 2005 22:27:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26766 for ; Wed, 23 Feb 2005 22:27:15 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4A1d-0005as-1j for mip6@ietf.org; Wed, 23 Feb 2005 22:50:53 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j1O3R0Hr026223; Thu, 24 Feb 2005 12:27:00 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j1O3R0DL007706; Thu, 24 Feb 2005 12:27:00 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id NAA07698 ; Thu, 24 Feb 2005 12:26:59 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j1O3Qxv8006840; Thu, 24 Feb 2005 12:26:59 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1O3Quld014973; Thu, 24 Feb 2005 12:26:56 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1O3Qt8a011701; Thu, 24 Feb 2005 12:26:56 +0900 (JST) Received: from steelhead (iVPN01-204.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0ICE006UTC8R6W@tsbpo1.po.toshiba.co.jp>; Thu, 24 Feb 2005 12:26:52 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1D474o-0001L4-00; Wed, 23 Feb 2005 16:41:58 -0800 Date: Wed, 23 Feb 2005 19:41:58 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt In-reply-to: To: john.loughney@nokia.com Message-id: <20050224004158.GE2906@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: mip6@ietf.org, kempf@docomolabs-usa.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Hi John and James, I think that we might define which level of the keys for the two services in the EAP key hierarchy needs to be cryptographically separated (for simplicity let me assume that the keys are part of EAP key hierarchy). It is always good to cryptographically separate keys derived from the EAP MK (Master Key) for network access service and keys derived from the EAP MK for mobility service. On the other hand, depending on optimization level and deployment scneario, two EAP MKs may be the same, meaning that cryptographic separation may not always be possible at the highest level of the EAP key hierarchy. Yoshihiro Ohba On Wed, Feb 23, 2005 at 07:23:16AM +0200, john.loughney@nokia.com wrote: > Hi James, > > > Actually, I think we want to keep the keys separate even if the network > > access provider and mobility service provider are the same. From a security > > standpoint, it makes sense to maintain separate keys, so that if one is > > compromised the other won't be. I suppose one could argue that "well, if > > the network access service is compromised, the user is so hosed, so it > > really doesn't matter if mobility service is compromised" but the othe way > > around is something different. If the mobility service key is compromised, > > the mobile host could stay put at the same place and re-establish secure > > mobility access service, as long as network access service is not > > compromised. If the two keys are the same, then the mobile host must go > > through re-establishing secure network access service before mobility > > service security can be repaired. > > > > Does this make sense? If so, perhaps the draft should make this point > > explicitly. > > I think we should make this point explicitly. To modify your proposed text: > > >> In addition to these attacks, there are other considerations that are > >> important in achieving a good security design. Because mobility and network > >> access authentication are separate services, any keys for these services > >> need to be cryptographically separate, separately named, and have separate > >> lifetimes that are not exceeded. This is necessary because a mobile host > >> must be able to move from one serving (or roaming) network access provider > >> to another without needing to change its mobility access provider. Finally, > >> basic cryptographic processes must provide for multiple algorithms in order > >> to accommodate the widely varying deployment needs. > > In addition to these attackes, there are other considerstions that are important > in achieving a good security design. As mobility and network access authentication > are seperate services, keys for these services need to be cryptographically > seperate, seperately named and have seperate lifetimes. This is needed because > if one service is compromised, the other service is not. This is necessary > so that a mobile host can move from one serving (or roaming) network access > provider to another without needing to change its mobility access provider. > Finally, basic cryptographic processes must provide for multiple algorithms in order > to accommodate the widely varying deployment needs. > > John > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 01:35:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05496 for ; Thu, 24 Feb 2005 01:35:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cy4-0000uI-O8 for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 01:59:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D46Jb-0000pV-Rj; Wed, 23 Feb 2005 18:53:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D46Ja-0000pD-My for mip6@megatron.ietf.org; Wed, 23 Feb 2005 18:53:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17026 for ; Wed, 23 Feb 2005 18:53:07 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D46gN-0001Xz-Ix for mip6@ietf.org; Wed, 23 Feb 2005 19:16:44 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1O0O7F04196 for ; Wed, 23 Feb 2005 16:24:07 -0800 X-mProtect: <200502240024> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141209.americas.nokia.com (172.18.141.209, claiming to be "[172.18.141.209]") by darkstar.iprg.nokia.com smtpd1wSNJd; Wed, 23 Feb 2005 16:24:03 PST Message-ID: <421D174E.3050303@iprg.nokia.com> Date: Wed, 23 Feb 2005 15:52:46 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mip6@ietf.org Subject: [Fwd: [Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-01.txt] Content-Type: multipart/mixed; boundary="------------050708020301040104040106" X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 This is a multi-part message in MIME format. --------------050708020301040104040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hello all, heres version 02 of the MIP6 and IKEv2 spec. fixed many things that werent correct in the first version. there are also more details now available in the sections which describe the use of IKEv2. reviews would be much appreciated. Vijay --------------050708020301040104040106 Content-Type: message/rfc822; name="[Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-01.txt" Content-Disposition: inline; filename="[Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-01.txt" Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA14214; Wed, 23 Feb 2005 15:42:15 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1O0DMO25776; Wed, 23 Feb 2005 16:13:22 -0800 X-mProtect: <200502240013> Nokia Silicon Valley Messaging Protection Received: from mailrelay.iprg.nokia.com (205.226.0.201) by darkstar.iprg.nokia.com smtpdyTbxbg; Wed, 23 Feb 2005 16:13:18 PST X-Scanned: Wed, 23 Feb 2005 15:41:50 -0800 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by mailrelay.iprg.nokia.com (8.12.9/8.12.9) id j1NNfoAO010817; Wed, 23 Feb 2005 15:41:50 -0800 Received: from megatron.ietf.org (132.151.6.71) by mailrelay.iprg.nokia.com 00oiZI8J; Wed, 23 Feb 2005 15:41:50 PST Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kjf-0005Rt-JY; Tue, 22 Feb 2005 19:50:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3hDK-0001CA-7w; Tue, 22 Feb 2005 16:05:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21419; Tue, 22 Feb 2005 16:04:59 -0500 (EST) Message-Id: <200502222104.QAA21419@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 22 Feb 2005 16:04:59 -0500 Cc: mip6@ietf.org Subject: [Mip6] I-D ACTION:draft-ietf-mip6-ikev2-ipsec-01.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobility for IPv6 Working Group of the IETF. Title : Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture Author(s) : V. Devarapalli Filename : draft-ietf-mip6-ikev2-ipsec-01.txt Pages : 26 Date : 2005-2-22 This document describes Mobile IPv6 operation with the revised IPsec architecture and IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-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-mip6-ikev2-ipsec-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-mip6-ikev2-ipsec-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: <2005-2-22160506.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mip6-ikev2-ipsec-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mip6-ikev2-ipsec-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-22160506.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --NextPart-- --------------050708020301040104040106 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --------------050708020301040104040106-- From mip6-bounces@ietf.org Thu Feb 24 08:22:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16407 for ; Thu, 24 Feb 2005 08:22:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JJj-0005ML-GE for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 08:46:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Isi-0002ml-TH; Thu, 24 Feb 2005 08:18:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Isg-0002mG-Vd for mip6@megatron.ietf.org; Thu, 24 Feb 2005 08:18:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15618 for ; Thu, 24 Feb 2005 08:18:13 -0500 (EST) Received: from dns1.tilab.com ([163.162.42.4]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4JFZ-0005Bw-OL for mip6@ietf.org; Thu, 24 Feb 2005 08:41:55 -0500 Received: from iowa2k01a.cselt.it ([163.162.242.201]) by dns1.cselt.it (PMDF V6.0-025 #38895) with ESMTP id <0ICF0096E3I5TD@dns1.cselt.it> for mip6@ietf.org; Thu, 24 Feb 2005 14:15:41 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01a.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 14:20:42 +0100 Date: Thu, 24 Feb 2005 14:18:02 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt To: john.loughney@nokia.com, kempf@docomolabs-usa.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt thread-index: AcUZEL1xyoEnlcliSzOreXDMiYm2igAVc1HAAEMpZoA= Content-Class: urn:content-classes:message X-OriginalArrivalTime: 24 Feb 2005 13:20:42.0171 (UTC) FILETIME=[A3CE88B0:01C51A73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Hi John and James, please see a comment below. >=20 > In addition to these attackes, there are other=20 > considerstions that are important > in achieving a good security design. As mobility and network=20 > access authentication > are seperate services, keys for these services need to be=20 > cryptographically=20 > seperate, seperately named and have seperate lifetimes. This=20 > is needed because > if one service is compromised, the other service is not.=20 > This is necessary=20 > so that a mobile host can move from one serving (or roaming)=20 > network access=20 > provider to another without needing to change its mobility=20 > access provider.=20 > Finally, basic cryptographic processes must provide for=20 > multiple algorithms in order > to accommodate the widely varying deployment needs. >=20 Since it's not clear to me which scenario you are referring to, could you please clarify on this sentence of your proposed text: " This is necessary so that a mobile host can move from one serving (or roaming) network access provider to another without needing to change its mobility access provider.=20 " Thanks, --Gerardo > John >=20 > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to=20 MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 13:13:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25317 for ; Thu, 24 Feb 2005 13:13:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Nrf-00061V-Vo for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 13:37:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NTB-0004sn-7G; Thu, 24 Feb 2005 13:12:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NT9-0004ne-7v for mip6@megatron.ietf.org; Thu, 24 Feb 2005 13:12:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25153 for ; Thu, 24 Feb 2005 13:12:08 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Nq5-0005zK-PM for mip6@ietf.org; Thu, 24 Feb 2005 13:35:54 -0500 Message-ID: <085001c51a9c$7e19fd60$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Gerardo Giaretta" , References: Subject: Re: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt Date: Thu, 24 Feb 2005 10:13:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: 7bit Gerardo, How about if we change the sentence to: "In addition, for scenerios where the access service authorizer and mobility service provider are different, maintaining separate keys allows the host to move from one access network to another without undergoing a new round of mobility service authorization." jak ----- Original Message ----- From: "Gerardo Giaretta" To: ; Cc: Sent: Thursday, February 24, 2005 5:18 AM Subject: RE: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt Hi John and James, please see a comment below. > > In addition to these attackes, there are other > considerstions that are important > in achieving a good security design. As mobility and network > access authentication > are seperate services, keys for these services need to be > cryptographically > seperate, seperately named and have seperate lifetimes. This > is needed because > if one service is compromised, the other service is not. > This is necessary > so that a mobile host can move from one serving (or roaming) > network access > provider to another without needing to change its mobility > access provider. > Finally, basic cryptographic processes must provide for > multiple algorithms in order > to accommodate the widely varying deployment needs. > Since it's not clear to me which scenario you are referring to, could you please clarify on this sentence of your proposed text: " This is necessary so that a mobile host can move from one serving (or roaming) network access provider to another without needing to change its mobility access provider. " Thanks, --Gerardo > John > > _______________________________________________ > Mip6 mailing list > Mip6@ietf.org > https://www1.ietf.org/mailman/listinfo/mip6 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A. ==================================================================== CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you ==================================================================== _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 13:45:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28661 for ; Thu, 24 Feb 2005 13:45:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OMC-0006q9-E4 for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 14:09:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Nva-0002IL-1Y; Thu, 24 Feb 2005 13:41:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4NvW-0002CQ-DQ for mip6@megatron.ietf.org; Thu, 24 Feb 2005 13:41:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28224 for ; Thu, 24 Feb 2005 13:41:27 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4OIS-0006i9-VI for mip6@ietf.org; Thu, 24 Feb 2005 14:05:13 -0500 Message-ID: <08d301c51aa0$99e0c020$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yoshihiro Ohba" , References: <20050224004158.GE2906@steelhead> Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Date: Thu, 24 Feb 2005 10:42:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Content-Transfer-Encoding: 7bit Yoshi, This works if EAP is used, but it might not be. From the perspective of the problem statement, I think it is sufficient to state that the keys need to be cryptographically separated. In the solutions document, this then can be addressed in a way appropriate to the solution. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: Cc: ; Sent: Wednesday, February 23, 2005 4:41 PM Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt > Hi John and James, > > I think that we might define which level of the keys for the two > services in the EAP key hierarchy needs to be cryptographically > separated (for simplicity let me assume that the keys are part > of EAP key hierarchy). > > It is always good to cryptographically separate keys derived from the > EAP MK (Master Key) for network access service and keys derived from > the EAP MK for mobility service. On the other hand, depending on > optimization level and deployment scneario, two EAP MKs may be the > same, meaning that cryptographic separation may not always be possible > at the highest level of the EAP key hierarchy. > > Yoshihiro Ohba > > > > On Wed, Feb 23, 2005 at 07:23:16AM +0200, john.loughney@nokia.com wrote: > > Hi James, > > > > > Actually, I think we want to keep the keys separate even if the network > > > access provider and mobility service provider are the same. From a security > > > standpoint, it makes sense to maintain separate keys, so that if one is > > > compromised the other won't be. I suppose one could argue that "well, if > > > the network access service is compromised, the user is so hosed, so it > > > really doesn't matter if mobility service is compromised" but the othe way > > > around is something different. If the mobility service key is compromised, > > > the mobile host could stay put at the same place and re-establish secure > > > mobility access service, as long as network access service is not > > > compromised. If the two keys are the same, then the mobile host must go > > > through re-establishing secure network access service before mobility > > > service security can be repaired. > > > > > > Does this make sense? If so, perhaps the draft should make this point > > > explicitly. > > > > I think we should make this point explicitly. To modify your proposed text: > > > > >> In addition to these attacks, there are other considerations that are > > >> important in achieving a good security design. Because mobility and network > > >> access authentication are separate services, any keys for these services > > >> need to be cryptographically separate, separately named, and have separate > > >> lifetimes that are not exceeded. This is necessary because a mobile host > > >> must be able to move from one serving (or roaming) network access provider > > >> to another without needing to change its mobility access provider. Finally, > > >> basic cryptographic processes must provide for multiple algorithms in order > > >> to accommodate the widely varying deployment needs. > > > > In addition to these attackes, there are other considerstions that are important > > in achieving a good security design. As mobility and network access authentication > > are seperate services, keys for these services need to be cryptographically > > seperate, seperately named and have seperate lifetimes. This is needed because > > if one service is compromised, the other service is not. This is necessary > > so that a mobile host can move from one serving (or roaming) network access > > provider to another without needing to change its mobility access provider. > > Finally, basic cryptographic processes must provide for multiple algorithms in order > > to accommodate the widely varying deployment needs. > > > > John > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Thu Feb 24 20:57:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19760 for ; Thu, 24 Feb 2005 20:57:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Ujj-0002g6-6d for mip6-web-archive@ietf.org; Thu, 24 Feb 2005 20:57:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4UiX-0004nj-Sx; Thu, 24 Feb 2005 20:56:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4UiV-0004kY-Te for mip6@megatron.ietf.org; Thu, 24 Feb 2005 20:56:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19638 for ; Thu, 24 Feb 2005 20:56:29 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4UiW-0002dV-CT for mip6@ietf.org; Thu, 24 Feb 2005 20:56:33 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0ICG005042PUQ3@mailout3.samsung.com> for mip6@ietf.org; Fri, 25 Feb 2005 10:56:18 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ICG000NK2PUYU@mailout3.samsung.com> for mip6@ietf.org; Fri, 25 Feb 2005 10:56:18 +0900 (KST) Received: from LocalHost ([75.2.43.236]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0ICG0062E2PUTC@mmp1.samsung.com> for mip6@ietf.org; Fri, 25 Feb 2005 10:56:18 +0900 (KST) Date: Fri, 25 Feb 2005 10:56:18 +0900 From: Heejin Jang Subject: [MIP6] DHCP Option for Home Agent Discovery in MIPv6 To: mip6@ietf.org Message-id: <014c01c51add$32621330$ec2b024b@LocalHost> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7BIT Cc: Alper Yegin , jinchoe X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7BIT Hello all, We posted an I-D that describes HA discovery with the help of DHCP6. We would appreciate to hear your comments. -------------------------------------------------------------------- Document title : DHCP Option for Home Agent Discovery in MIPv6 Authors : HeeJin Jang, Alper Yegin, JinHyeock Choi Filename : draft-jang-dhc-haopt-01.txt Date : 2005-2-20 Pages : 12 Abstract : This draft defines a DHCP-based scheme to enable dynamic discovery of Mobile IPv6 home agent address and home subnet. New DHCP options are defined to carry the information from a DHCP server to the DHCP client running on the mobile node. A URL for this Internet-Draft is: http://yegin.org/IETF/draft-jang-dhc-haopt-01.txt ------------------------------------------------------------------- Best regards - Heejin Jang _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 01:05:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12332 for ; Fri, 25 Feb 2005 01:05:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Ybs-00086i-QN for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 01:05:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4YZq-0004GS-MP; Fri, 25 Feb 2005 01:03:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4YZd-0004FY-9o for mip6@megatron.ietf.org; Fri, 25 Feb 2005 01:03:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12077 for ; Fri, 25 Feb 2005 01:03:36 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4YZh-00082l-Kl for mip6@ietf.org; Fri, 25 Feb 2005 01:03:42 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P63Wp05007; Fri, 25 Feb 2005 08:03:32 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 08:15:32 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1P6FWd1023211; Fri, 25 Feb 2005 08:15:32 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00bRFfDP; Fri, 25 Feb 2005 08:15:31 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P625M27919; Fri, 25 Feb 2005 08:02:05 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 08:02:02 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 08:02:01 +0200 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="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Date: Fri, 25 Feb 2005 08:02:02 +0200 Message-ID: Thread-Topic: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt thread-index: AcUaoI8GN15u2tSpQoSdtvxTSGMGzQAXmYWw To: , X-OriginalArrivalTime: 25 Feb 2005 06:02:01.0106 (UTC) FILETIME=[85A47F20:01C51AFF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 Content-Transfer-Encoding: 7bit I agree with James on this. Yoshi - do you think the current text prevents both the network access & mobility service from sharing the same EAP master key? John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 24 February, 2005 20:42 > To: Yoshihiro Ohba; Loughney John (Nokia-NRC/Helsinki) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Security Section Comments > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > Yoshi, > > This works if EAP is used, but it might not be. From the > perspective of the > problem statement, I think it is sufficient to state that the > keys need to > be cryptographically separated. In the solutions document, > this then can be > addressed in a way appropriate to the solution. > > jak > > > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: > Cc: ; > Sent: Wednesday, February 23, 2005 4:41 PM > Subject: Re: [Mip6] Security Section Comments > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > > Hi John and James, > > > > I think that we might define which level of the keys for the two > > services in the EAP key hierarchy needs to be cryptographically > > separated (for simplicity let me assume that the keys are part > > of EAP key hierarchy). > > > > It is always good to cryptographically separate keys > derived from the > > EAP MK (Master Key) for network access service and keys derived from > > the EAP MK for mobility service. On the other hand, depending on > > optimization level and deployment scneario, two EAP MKs may be the > > same, meaning that cryptographic separation may not always > be possible > > at the highest level of the EAP key hierarchy. > > > > Yoshihiro Ohba > > > > > > > > On Wed, Feb 23, 2005 at 07:23:16AM +0200, > john.loughney@nokia.com wrote: > > > Hi James, > > > > > > > Actually, I think we want to keep the keys separate even if the > network > > > > access provider and mobility service provider are the > same. From a > security > > > > standpoint, it makes sense to maintain separate keys, > so that if one > is > > > > compromised the other won't be. I suppose one could > argue that "well, > if > > > > the network access service is compromised, the user is > so hosed, so it > > > > really doesn't matter if mobility service is > compromised" but the othe > way > > > > around is something different. If the mobility service key is > compromised, > > > > the mobile host could stay put at the same place and > re-establish > secure > > > > mobility access service, as long as network access > service is not > > > > compromised. If the two keys are the same, then the > mobile host must > go > > > > through re-establishing secure network access service > before mobility > > > > service security can be repaired. > > > > > > > > Does this make sense? If so, perhaps the draft should > make this point > > > > explicitly. > > > > > > I think we should make this point explicitly. To modify > your proposed > text: > > > > > > >> In addition to these attacks, there are other > considerations that are > > > >> important in achieving a good security design. Because > mobility and > network > > > >> access authentication are separate services, any keys for these > services > > > >> need to be cryptographically separate, separately > named, and have > separate > > > >> lifetimes that are not exceeded. This is necessary > because a mobile > host > > > >> must be able to move from one serving (or roaming) > network access > provider > > > >> to another without needing to change its mobility > access provider. > Finally, > > > >> basic cryptographic processes must provide for > multiple algorithms in > order > > > >> to accommodate the widely varying deployment needs. > > > > > > In addition to these attackes, there are other > considerstions that are > important > > > in achieving a good security design. As mobility and > network access > authentication > > > are seperate services, keys for these services need to be > cryptographically > > > seperate, seperately named and have seperate lifetimes. > This is needed > because > > > if one service is compromised, the other service is not. This is > necessary > > > so that a mobile host can move from one serving (or > roaming) network > access > > > provider to another without needing to change its mobility access > provider. > > > Finally, basic cryptographic processes must provide for multiple > algorithms in order > > > to accommodate the widely varying deployment needs. > > > > > > John > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 01:15:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13488 for ; Fri, 25 Feb 2005 01:15:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4YlD-0008Jh-SI for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 01:15:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4YhJ-0002Dk-HJ; Fri, 25 Feb 2005 01:11:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4YhF-00027W-NC for mip6@megatron.ietf.org; Fri, 25 Feb 2005 01:11:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12994 for ; Fri, 25 Feb 2005 01:11:29 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4YhK-0008Dx-79 for mip6@ietf.org; Fri, 25 Feb 2005 01:11:34 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P6BOZ12622; Fri, 25 Feb 2005 08:11:25 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 08:22:12 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1P6MCmY006428; Fri, 25 Feb 2005 08:22:12 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00xNpvUv; Fri, 25 Feb 2005 08:22:11 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1P68oM03305; Fri, 25 Feb 2005 08:08:50 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 08:08:50 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 08:08:50 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt Date: Fri, 25 Feb 2005 08:08:49 +0200 Message-ID: Thread-Topic: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt thread-index: AcUanGJhMCQBRbwMQDmO/QgbfuhLUwAY4Oag To: , X-OriginalArrivalTime: 25 Feb 2005 06:08:50.0102 (UTC) FILETIME=[796C5560:01C51B00] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable James & Gerardo, I get Gerardo's point, but the text starts to get unwieldy. Howabout something simple like: It allows the mobile node to change access networks without performing a new mobility service authorization. I would like not to get bogged down in deployment models, etc. but just discuss what the benefit is for seperating the keys. Maybe its best to stick to higher level issues; service providers will deploy as they see fit, but the draft should talk about the more egeneral properties and what it allows for. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 24 February, 2005 20:13 > To: Gerardo Giaretta; Loughney John (Nokia-NRC/Helsinki) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Security Section > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt >=20 >=20 > Gerardo, >=20 > How about if we change the sentence to: >=20 > "In addition, for scenerios where the access service=20 > authorizer and mobility > service provider are different, maintaining separate keys=20 > allows the host to > move from one access network to another without undergoing a=20 > new round of > mobility service authorization." >=20 > jak >=20 >=20 > ----- Original Message -----=20 > From: "Gerardo Giaretta" > To: ; > Cc: > Sent: Thursday, February 24, 2005 5:18 AM > Subject: RE: [Mip6] Security Section > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt >=20 >=20 > Hi John and James, >=20 > please see a comment below. >=20 > > > > In addition to these attackes, there are other > > considerstions that are important > > in achieving a good security design. As mobility and network > > access authentication > > are seperate services, keys for these services need to be > > cryptographically > > seperate, seperately named and have seperate lifetimes. This > > is needed because > > if one service is compromised, the other service is not. > > This is necessary > > so that a mobile host can move from one serving (or roaming) > > network access > > provider to another without needing to change its mobility > > access provider. > > Finally, basic cryptographic processes must provide for > > multiple algorithms in order > > to accommodate the widely varying deployment needs. > > >=20 > Since it's not clear to me which scenario you are referring to, could > you please clarify on this sentence of your proposed text: >=20 > " > This is necessary so that a mobile host can move from one serving (or > roaming) network access provider to another without needing to change > its mobility access provider. > " >=20 > Thanks, > --Gerardo >=20 >=20 > > John > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > Italia S.p.A. >=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 > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 07:53:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09824 for ; Fri, 25 Feb 2005 07:53:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ey5-00083z-43 for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 07:53:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ew2-0006rc-BD; Fri, 25 Feb 2005 07:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ew0-0006rS-6W for mip6@megatron.ietf.org; Fri, 25 Feb 2005 07:51:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09723 for ; Fri, 25 Feb 2005 07:51:06 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ew6-00082O-OR for mip6@ietf.org; Fri, 25 Feb 2005 07:51:16 -0500 Received: from esealmw129.eemea.ericsson.se ([153.88.254.120]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1PCojQ0020624; Fri, 25 Feb 2005 13:51:00 +0100 Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 13:47:52 +0100 Received: from emyklnt163.ao.ericsson.se ([150.236.92.63]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 13:47:52 +0100 Received: by emyklnt163.ao.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Fri, 25 Feb 2005 20:47:56 +0800 Message-ID: <2D255349D9B1A04683757BFAD6D367960A556185@ejptont100.nrj.ericsson.se> From: "Shinta Sugimoto (TO/NRJ)" To: "'mip6@ietf.org'" Date: Fri, 25 Feb 2005 20:48:04 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-2022-jp" X-OriginalArrivalTime: 25 Feb 2005 12:47:52.0504 (UTC) FILETIME=[3834F380:01C51B38] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: "'Francis Dupont'" Subject: [Mip6] MIPv6-IPsec interaction X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Hello, Below is an I-D (informational) about interface between MIPv6 and IPsec/IKE. We appreciate your comments. Regards, Shinta Sugimoto --- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : PF_KEY Extension as an Interface between Mobile IPv6 and IPsec/IKE Author(s) : S. Sugimoto, F. Dupont Filename : draft-sugimoto-mip6-pfkey-migrate-00.txt Pages : 21 Date : 2005-2-15 This document describes need for interface between Mobile IPv6 and IPsec/IKE and show how two protocols can interwork each other. We propose a mechanism to realize this interaction by extending PF_KEY framework. Proposed mechanism makes it possible for Mobile IPv6 to inform IPsec/IKE about the movement. Receiving the message, IPsec components can take necessary actions to update corresponding entry in SPD and SADB. In addition, IKE can use the notification for keeping its IKE connection alive. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sugimoto-mip6-pfkey-migrate-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-sugimoto-mip6-pfkey-migrate-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-sugimoto-mip6-pfkey-migrate-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. _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 09:44:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21663 for ; Fri, 25 Feb 2005 09:44:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ghr-0002R0-9u for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 09:44:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gdW-0003Hh-JY; Fri, 25 Feb 2005 09:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gdV-0003HU-7Z for mip6@megatron.ietf.org; Fri, 25 Feb 2005 09:40:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21149 for ; Fri, 25 Feb 2005 09:40:06 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gdb-0002IR-2Q for mip6@ietf.org; Fri, 25 Feb 2005 09:40:17 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0ICH00D4M1K87S@dns2.cselt.it> for mip6@ietf.org; Fri, 25 Feb 2005 15:28:56 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 15:39:27 +0100 Date: Fri, 25 Feb 2005 15:39:54 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt To: James Kempf Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt Thread-Index: AcUanZyPL3sq6A9sT0m0YckV7TDaJAApnuJg Content-class: urn:content-classes:message X-OriginalArrivalTime: 25 Feb 2005 14:39:27.0187 (UTC) FILETIME=[CE8C8230:01C51B47] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable James, the text sounds good.=20 Do you think we need to mention explicitly that in this case we are referring to scenarios where access service authorizer and mobility service authorizer are the same?=20 I'm not sure about that, since it is obvious that, if access service authorizer and mobility service authorizer are different, the keys are separate and the way you handle mobility service is orthogonal to the way you handle access service. --Gerardo > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com]=20 > Sent: Thursday, February 24, 2005 7:13 PM > To: Gerardo Giaretta; john.loughney@nokia.com > Cc: mip6@ietf.org > Subject: Re: [Mip6] Security Section=20 > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt >=20 >=20 > Gerardo, >=20 > How about if we change the sentence to: >=20 > "In addition, for scenerios where the access service=20 > authorizer and mobility > service provider are different, maintaining separate keys=20 > allows the host to > move from one access network to another without undergoing a=20 > new round of > mobility service authorization." >=20 > jak >=20 >=20 > ----- Original Message -----=20 > From: "Gerardo Giaretta" > To: ; > Cc: > Sent: Thursday, February 24, 2005 5:18 AM > Subject: RE: [Mip6] Security Section > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt >=20 >=20 > Hi John and James, >=20 > please see a comment below. >=20 > > > > In addition to these attackes, there are other > > considerstions that are important > > in achieving a good security design. As mobility and network > > access authentication > > are seperate services, keys for these services need to be > > cryptographically > > seperate, seperately named and have seperate lifetimes. This > > is needed because > > if one service is compromised, the other service is not. > > This is necessary > > so that a mobile host can move from one serving (or roaming) > > network access > > provider to another without needing to change its mobility > > access provider. > > Finally, basic cryptographic processes must provide for > > multiple algorithms in order > > to accommodate the widely varying deployment needs. > > >=20 > Since it's not clear to me which scenario you are referring to, could > you please clarify on this sentence of your proposed text: >=20 > " > This is necessary so that a mobile host can move from one serving (or > roaming) network access provider to another without needing to change > its mobility access provider. > " >=20 > Thanks, > --Gerardo >=20 >=20 > > John > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > Italia S.p.A. >=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 > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 09:51:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22288 for ; Fri, 25 Feb 2005 09:51:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4goJ-0002ba-OJ for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 09:51:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gmf-0003wa-O5; Fri, 25 Feb 2005 09:49:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gmd-0003uQ-SN for mip6@megatron.ietf.org; Fri, 25 Feb 2005 09:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22190 for ; Fri, 25 Feb 2005 09:49:33 -0500 (EST) Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4gml-0002ZN-3p for mip6@ietf.org; Fri, 25 Feb 2005 09:49:45 -0500 Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0ICH00D8D200IN@dns2.cselt.it> for mip6@ietf.org; Fri, 25 Feb 2005 15:38:24 +0100 (MET) Received: from EXC01B.cselt.it ([163.162.4.199]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 15:48:55 +0100 Date: Fri, 25 Feb 2005 15:49:23 +0100 From: Gerardo Giaretta Subject: RE: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt To: john.loughney@nokia.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Importance: normal Priority: normal Thread-Topic: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt Thread-Index: AcUanGJhMCQBRbwMQDmO/QgbfuhLUwAY4OagABIqIQA= Content-class: urn:content-classes:message X-OriginalArrivalTime: 25 Feb 2005 14:48:55.0718 (UTC) FILETIME=[216B7460:01C51B49] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, kempf@docomolabs-usa.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable John, just to understand correctly what text you'd like to replace, are you suggesting to change the text to: " In addition to these attacks, there are other considerations that are important in achieving a good security design. As mobility and network access authentication are seperate services, keys for these services need to be cryptographically seperate, seperately named and have seperate lifetimes. This allows the mobile node to change access networks without performing a new mobility service authorization. Finally, basic cryptographic processes must provide for multiple algorithms in order to accommodate the widely varying deployment needs. " --Gerardo > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > Sent: Friday, February 25, 2005 7:09 AM > To: kempf@docomolabs-usa.com; Gerardo.Giaretta@TILAB.COM > Cc: mip6@ietf.org > Subject: RE: [Mip6] Security Section=20 > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt >=20 >=20 > James & Gerardo, >=20 > I get Gerardo's point, but the text starts to get unwieldy. > Howabout something simple like: >=20 > It allows the mobile node to change access networks without > performing a new mobility service authorization. >=20 > I would like not to get bogged down in deployment models, etc. > but just discuss what the benefit is for seperating the keys. > Maybe its best to stick to higher level issues; service providers > will deploy as they see fit, but the draft should talk about > the more egeneral properties and what it allows for. >=20 > John >=20 >=20 >=20 > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 24 February, 2005 20:13 > > To: Gerardo Giaretta; Loughney John (Nokia-NRC/Helsinki) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Security Section > > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt > >=20 > >=20 > > Gerardo, > >=20 > > How about if we change the sentence to: > >=20 > > "In addition, for scenerios where the access service=20 > > authorizer and mobility > > service provider are different, maintaining separate keys=20 > > allows the host to > > move from one access network to another without undergoing a=20 > > new round of > > mobility service authorization." > >=20 > > jak > >=20 > >=20 > > ----- Original Message -----=20 > > From: "Gerardo Giaretta" > > To: ; > > Cc: > > Sent: Thursday, February 24, 2005 5:18 AM > > Subject: RE: [Mip6] Security Section > > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt > >=20 > >=20 > > Hi John and James, > >=20 > > please see a comment below. > >=20 > > > > > > In addition to these attackes, there are other > > > considerstions that are important > > > in achieving a good security design. As mobility and network > > > access authentication > > > are seperate services, keys for these services need to be > > > cryptographically > > > seperate, seperately named and have seperate lifetimes. This > > > is needed because > > > if one service is compromised, the other service is not. > > > This is necessary > > > so that a mobile host can move from one serving (or roaming) > > > network access > > > provider to another without needing to change its mobility > > > access provider. > > > Finally, basic cryptographic processes must provide for > > > multiple algorithms in order > > > to accommodate the widely varying deployment needs. > > > > >=20 > > Since it's not clear to me which scenario you are referring=20 > to, could > > you please clarify on this sentence of your proposed text: > >=20 > > " > > This is necessary so that a mobile host can move from one=20 > serving (or > > roaming) network access provider to another without needing=20 > to change > > its mobility access provider. > > " > >=20 > > Thanks, > > --Gerardo > >=20 > >=20 > > > John > > > > > > _______________________________________________ > > > Mip6 mailing list > > > Mip6@ietf.org > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > >=20 > >=20 > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > > Italia S.p.A. > >=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 > > CONFIDENTIALITY NOTICE > > This message and its attachments are addressed solely to the persons > > above and may contain confidential information. If you have received > > the message in error, be informed that any use of the content hereof > > is prohibited. Please return it immediately to the sender and delete > > the message. Should you have any questions, please send an e_mail to > > MailAdmin@tilab.com. Thank you > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 > >=20 > >=20 >=20 Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia = S.p.A. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please send an e_mail to MailAdmin@tilab.com. Thank you =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 10:29:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28996 for ; Fri, 25 Feb 2005 10:29:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hPr-00044B-GR for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 10:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hKW-0004v7-D1; Fri, 25 Feb 2005 10:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4hKU-0004t5-Th for mip6@megatron.ietf.org; Fri, 25 Feb 2005 10:24:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27795 for ; Fri, 25 Feb 2005 10:24:31 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4hKa-0003hv-Nv for mip6@ietf.org; Fri, 25 Feb 2005 10:24:42 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j1PFOIaX014435; Sat, 26 Feb 2005 00:24:18 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j1PFOI7A000349; Sat, 26 Feb 2005 00:24:18 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id AAA00348 ; Sat, 26 Feb 2005 00:24:18 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j1PFOHwm013857; Sat, 26 Feb 2005 00:24:17 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1PFOHiq016797; Sat, 26 Feb 2005 00:24:17 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1PFOG8a021386; Sat, 26 Feb 2005 00:24:16 +0900 (JST) Received: from steelhead ([172.30.24.40]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0ICH00MJY42W9Z@tsbpo1.po.toshiba.co.jp>; Sat, 26 Feb 2005 00:24:13 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1D4fy8-0002N1-00; Fri, 25 Feb 2005 05:57:24 -0800 Date: Fri, 25 Feb 2005 08:57:24 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt In-reply-to: To: john.loughney@nokia.com Message-id: <20050225135724.GA8919@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Cc: mip6@ietf.org, yohba@tari.toshiba.com, kempf@docomolabs-usa.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a On Fri, Feb 25, 2005 at 08:02:02AM +0200, john.loughney@nokia.com wrote: > I agree with James on this. Yoshi - do you think the current text prevents > both the network access & mobility service from sharing the same EAP master key? I am not sure whether the current text prevents it or not, but it would be clearer if we can mention that the keys that need to be cryptographically separated are generated from authentication credentials (i.e., are not the keys in the authentication credentials), something like: " In addition to these attackes, there are other considerstions that are important in achieving a good security design. As mobility and network access authentication are seperate services, keys generated from authentication credentials for these services need to be cryptographically seperate, seperately named and have seperate lifetimes. This is needed because if one service is compromised, the other service is not. This is necessary so that a mobile host can move from one serving (or roaming) network access provider to another without needing to change its mobility access provider. Finally, basic cryptographic processes must provide for multiple algorithms in order to accommodate the widely varying deployment needs. " Regards, Yoshihiro Ohba > > John > > > -----Original Message----- > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > Sent: 24 February, 2005 20:42 > > To: Yoshihiro Ohba; Loughney John (Nokia-NRC/Helsinki) > > Cc: mip6@ietf.org > > Subject: Re: [Mip6] Security Section Comments > > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > > > > Yoshi, > > > > This works if EAP is used, but it might not be. From the > > perspective of the > > problem statement, I think it is sufficient to state that the > > keys need to > > be cryptographically separated. In the solutions document, > > this then can be > > addressed in a way appropriate to the solution. > > > > jak > > > > > > > > ----- Original Message ----- > > From: "Yoshihiro Ohba" > > To: > > Cc: ; > > Sent: Wednesday, February 23, 2005 4:41 PM > > Subject: Re: [Mip6] Security Section Comments > > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > > > > > Hi John and James, > > > > > > I think that we might define which level of the keys for the two > > > services in the EAP key hierarchy needs to be cryptographically > > > separated (for simplicity let me assume that the keys are part > > > of EAP key hierarchy). > > > > > > It is always good to cryptographically separate keys > > derived from the > > > EAP MK (Master Key) for network access service and keys derived from > > > the EAP MK for mobility service. On the other hand, depending on > > > optimization level and deployment scneario, two EAP MKs may be the > > > same, meaning that cryptographic separation may not always > > be possible > > > at the highest level of the EAP key hierarchy. > > > > > > Yoshihiro Ohba > > > > > > > > > > > > On Wed, Feb 23, 2005 at 07:23:16AM +0200, > > john.loughney@nokia.com wrote: > > > > Hi James, > > > > > > > > > Actually, I think we want to keep the keys separate even if the > > network > > > > > access provider and mobility service provider are the > > same. From a > > security > > > > > standpoint, it makes sense to maintain separate keys, > > so that if one > > is > > > > > compromised the other won't be. I suppose one could > > argue that "well, > > if > > > > > the network access service is compromised, the user is > > so hosed, so it > > > > > really doesn't matter if mobility service is > > compromised" but the othe > > way > > > > > around is something different. If the mobility service key is > > compromised, > > > > > the mobile host could stay put at the same place and > > re-establish > > secure > > > > > mobility access service, as long as network access > > service is not > > > > > compromised. If the two keys are the same, then the > > mobile host must > > go > > > > > through re-establishing secure network access service > > before mobility > > > > > service security can be repaired. > > > > > > > > > > Does this make sense? If so, perhaps the draft should > > make this point > > > > > explicitly. > > > > > > > > I think we should make this point explicitly. To modify > > your proposed > > text: > > > > > > > > >> In addition to these attacks, there are other > > considerations that are > > > > >> important in achieving a good security design. Because > > mobility and > > network > > > > >> access authentication are separate services, any keys for these > > services > > > > >> need to be cryptographically separate, separately > > named, and have > > separate > > > > >> lifetimes that are not exceeded. This is necessary > > because a mobile > > host > > > > >> must be able to move from one serving (or roaming) > > network access > > provider > > > > >> to another without needing to change its mobility > > access provider. > > Finally, > > > > >> basic cryptographic processes must provide for > > multiple algorithms in > > order > > > > >> to accommodate the widely varying deployment needs. > > > > > > > > In addition to these attackes, there are other > > considerstions that are > > important > > > > in achieving a good security design. As mobility and > > network access > > authentication > > > > are seperate services, keys for these services need to be > > cryptographically > > > > seperate, seperately named and have seperate lifetimes. > > This is needed > > because > > > > if one service is compromised, the other service is not. This is > > necessary > > > > so that a mobile host can move from one serving (or > > roaming) network > > access > > > > provider to another without needing to change its mobility access > > provider. > > > > Finally, basic cryptographic processes must provide for multiple > > algorithms in order > > > > to accommodate the widely varying deployment needs. > > > > > > > > John > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 11:49:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06875 for ; Fri, 25 Feb 2005 11:49:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ifF-0005wG-UM for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 11:50:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4iZC-0000tX-7m; Fri, 25 Feb 2005 11:43:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4iZB-0000tM-9o for mip6@megatron.ietf.org; Fri, 25 Feb 2005 11:43:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06401 for ; Fri, 25 Feb 2005 11:43:45 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4iZJ-0005or-DH for mip6@ietf.org; Fri, 25 Feb 2005 11:43:58 -0500 Message-ID: <09ce01c51b59$51b828b0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: Subject: Re: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt Date: Fri, 25 Feb 2005 08:44:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit OK by me. jak ----- Original Message ----- From: To: ; Cc: Sent: Thursday, February 24, 2005 10:08 PM Subject: RE: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt James & Gerardo, I get Gerardo's point, but the text starts to get unwieldy. Howabout something simple like: It allows the mobile node to change access networks without performing a new mobility service authorization. I would like not to get bogged down in deployment models, etc. but just discuss what the benefit is for seperating the keys. Maybe its best to stick to higher level issues; service providers will deploy as they see fit, but the draft should talk about the more egeneral properties and what it allows for. John > -----Original Message----- > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: 24 February, 2005 20:13 > To: Gerardo Giaretta; Loughney John (Nokia-NRC/Helsinki) > Cc: mip6@ietf.org > Subject: Re: [Mip6] Security Section > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt > > > Gerardo, > > How about if we change the sentence to: > > "In addition, for scenerios where the access service > authorizer and mobility > service provider are different, maintaining separate keys > allows the host to > move from one access network to another without undergoing a > new round of > mobility service authorization." > > jak > > > ----- Original Message ----- > From: "Gerardo Giaretta" > To: ; > Cc: > Sent: Thursday, February 24, 2005 5:18 AM > Subject: RE: [Mip6] Security Section > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt > > > Hi John and James, > > please see a comment below. > > > > > In addition to these attackes, there are other > > considerstions that are important > > in achieving a good security design. As mobility and network > > access authentication > > are seperate services, keys for these services need to be > > cryptographically > > seperate, seperately named and have seperate lifetimes. This > > is needed because > > if one service is compromised, the other service is not. > > This is necessary > > so that a mobile host can move from one serving (or roaming) > > network access > > provider to another without needing to change its mobility > > access provider. > > Finally, basic cryptographic processes must provide for > > multiple algorithms in order > > to accommodate the widely varying deployment needs. > > > > Since it's not clear to me which scenario you are referring to, could > you please clarify on this sentence of your proposed text: > > " > This is necessary so that a mobile host can move from one serving (or > roaming) network access provider to another without needing to change > its mobility access provider. > " > > Thanks, > --Gerardo > > > > John > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom > Italia S.p.A. > > ==================================================================== > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > ==================================================================== > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 12:17:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09498 for ; Fri, 25 Feb 2005 12:17:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4j5o-0006YE-Ae for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 12:17:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4iwZ-0007Ii-Dy; Fri, 25 Feb 2005 12:07:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4iwW-0007IU-UB for mip6@megatron.ietf.org; Fri, 25 Feb 2005 12:07:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08486 for ; Fri, 25 Feb 2005 12:07:54 -0500 (EST) Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4iwf-0006Ip-4I for mip6@ietf.org; Fri, 25 Feb 2005 12:08:07 -0500 Message-ID: <0a2d01c51b5c$ae2552f0$016115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Yoshihiro Ohba" , References: <20050225135724.GA8919@steelhead> Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt Date: Fri, 25 Feb 2005 09:08:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: 7bit Cc: mip6@ietf.org, yohba@tari.toshiba.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bb031f3a6fb29f760794ac9bf1997ae Content-Transfer-Encoding: 7bit Yoshi, If the two sides use Diffie-Hellman, then the keys won't be generated directly from authentication credentials. The Diffie-Hellman exponents don't need to be related to authentication credentials at all. Instead of: "As mobility and network access authentication are seperate services, keys generated from authentication credentials for these services need to be cryptographically seperate, seperately named and have seperate lifetimes." How about: "As mobility and network access authentication are separate services, keys generated for these services need to be cryptographically separate, separately named, and have separate lifetimes, including if the keys are generated from authentication credentials" This doesn't imply somehow that the keys will always be generated from authentication credentials. jak ----- Original Message ----- From: "Yoshihiro Ohba" To: Cc: ; ; Sent: Friday, February 25, 2005 5:57 AM Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt > On Fri, Feb 25, 2005 at 08:02:02AM +0200, john.loughney@nokia.com wrote: > > I agree with James on this. Yoshi - do you think the current text prevents > > both the network access & mobility service from sharing the same EAP master key? > > I am not sure whether the current text prevents it or not, but it > would be clearer if we can mention that the keys that need to be > cryptographically separated are generated from authentication > credentials (i.e., are not the keys in the authentication > credentials), something like: > > " > In addition to these attackes, there are other considerstions that > are important in achieving a good security design. As mobility and > network access authentication are seperate services, keys generated > from authentication credentials for these services need to be > cryptographically seperate, seperately named and have seperate > lifetimes. This is needed because if one service is compromised, the > other service is not. This is necessary so that a mobile host can > move from one serving (or roaming) network access provider to another > without needing to change its mobility access provider. Finally, > basic cryptographic processes must provide for multiple algorithms in > order to accommodate the widely varying deployment needs. > " > > Regards, > > Yoshihiro Ohba > > > > > > John > > > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: 24 February, 2005 20:42 > > > To: Yoshihiro Ohba; Loughney John (Nokia-NRC/Helsinki) > > > Cc: mip6@ietf.org > > > Subject: Re: [Mip6] Security Section Comments > > > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > > > > > > > Yoshi, > > > > > > This works if EAP is used, but it might not be. From the > > > perspective of the > > > problem statement, I think it is sufficient to state that the > > > keys need to > > > be cryptographically separated. In the solutions document, > > > this then can be > > > addressed in a way appropriate to the solution. > > > > > > jak > > > > > > > > > > > > ----- Original Message ----- > > > From: "Yoshihiro Ohba" > > > To: > > > Cc: ; > > > Sent: Wednesday, February 23, 2005 4:41 PM > > > Subject: Re: [Mip6] Security Section Comments > > > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > > > > > > > > Hi John and James, > > > > > > > > I think that we might define which level of the keys for the two > > > > services in the EAP key hierarchy needs to be cryptographically > > > > separated (for simplicity let me assume that the keys are part > > > > of EAP key hierarchy). > > > > > > > > It is always good to cryptographically separate keys > > > derived from the > > > > EAP MK (Master Key) for network access service and keys derived from > > > > the EAP MK for mobility service. On the other hand, depending on > > > > optimization level and deployment scneario, two EAP MKs may be the > > > > same, meaning that cryptographic separation may not always > > > be possible > > > > at the highest level of the EAP key hierarchy. > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > On Wed, Feb 23, 2005 at 07:23:16AM +0200, > > > john.loughney@nokia.com wrote: > > > > > Hi James, > > > > > > > > > > > Actually, I think we want to keep the keys separate even if the > > > network > > > > > > access provider and mobility service provider are the > > > same. From a > > > security > > > > > > standpoint, it makes sense to maintain separate keys, > > > so that if one > > > is > > > > > > compromised the other won't be. I suppose one could > > > argue that "well, > > > if > > > > > > the network access service is compromised, the user is > > > so hosed, so it > > > > > > really doesn't matter if mobility service is > > > compromised" but the othe > > > way > > > > > > around is something different. If the mobility service key is > > > compromised, > > > > > > the mobile host could stay put at the same place and > > > re-establish > > > secure > > > > > > mobility access service, as long as network access > > > service is not > > > > > > compromised. If the two keys are the same, then the > > > mobile host must > > > go > > > > > > through re-establishing secure network access service > > > before mobility > > > > > > service security can be repaired. > > > > > > > > > > > > Does this make sense? If so, perhaps the draft should > > > make this point > > > > > > explicitly. > > > > > > > > > > I think we should make this point explicitly. To modify > > > your proposed > > > text: > > > > > > > > > > >> In addition to these attacks, there are other > > > considerations that are > > > > > >> important in achieving a good security design. Because > > > mobility and > > > network > > > > > >> access authentication are separate services, any keys for these > > > services > > > > > >> need to be cryptographically separate, separately > > > named, and have > > > separate > > > > > >> lifetimes that are not exceeded. This is necessary > > > because a mobile > > > host > > > > > >> must be able to move from one serving (or roaming) > > > network access > > > provider > > > > > >> to another without needing to change its mobility > > > access provider. > > > Finally, > > > > > >> basic cryptographic processes must provide for > > > multiple algorithms in > > > order > > > > > >> to accommodate the widely varying deployment needs. > > > > > > > > > > In addition to these attackes, there are other > > > considerstions that are > > > important > > > > > in achieving a good security design. As mobility and > > > network access > > > authentication > > > > > are seperate services, keys for these services need to be > > > cryptographically > > > > > seperate, seperately named and have seperate lifetimes. > > > This is needed > > > because > > > > > if one service is compromised, the other service is not. This is > > > necessary > > > > > so that a mobile host can move from one serving (or > > > roaming) network > > > access > > > > > provider to another without needing to change its mobility access > > > provider. > > > > > Finally, basic cryptographic processes must provide for multiple > > > algorithms in order > > > > > to accommodate the widely varying deployment needs. > > > > > > > > > > John > > > > > > > > > > _______________________________________________ > > > > > Mip6 mailing list > > > > > Mip6@ietf.org > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 12:22:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10057 for ; Fri, 25 Feb 2005 12:22:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jAZ-0006hB-9k for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 12:22:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4j9E-0003NF-Gx; Fri, 25 Feb 2005 12:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4j9C-0003HJ-Mo for mip6@megatron.ietf.org; Fri, 25 Feb 2005 12:21:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09953 for ; Fri, 25 Feb 2005 12:20:59 -0500 (EST) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4j9L-0006fB-EC for mip6@ietf.org; Fri, 25 Feb 2005 12:21:13 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j1PHKraX006413; Sat, 26 Feb 2005 02:20:53 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j1PHKr0s010543; Sat, 26 Feb 2005 02:20:53 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id CAA10542 ; Sat, 26 Feb 2005 02:20:53 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j1PHKqDq022441; Sat, 26 Feb 2005 02:20:52 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j1PHKqna026758; Sat, 26 Feb 2005 02:20:52 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j1PHKp8a012411; Sat, 26 Feb 2005 02:20:52 +0900 (JST) Received: from steelhead ([172.30.24.114]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0ICH000DR9IMX9@tsbpo1.po.toshiba.co.jp>; Sat, 26 Feb 2005 02:20:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1D4h2B-0002Xl-00; Fri, 25 Feb 2005 07:05:39 -0800 Date: Fri, 25 Feb 2005 10:05:39 -0500 From: Yoshihiro Ohba Subject: Re: [Mip6] Security Section Comments ondraft-ietf-mip6-bootstrap-ps-01.txt In-reply-to: <0a2d01c51b5c$ae2552f0$016115ac@dcml.docomolabsusa.com> To: James Kempf Message-id: <20050225150539.GC8919@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.6+20040907i References: <20050225135724.GA8919@steelhead> <0a2d01c51b5c$ae2552f0$016115ac@dcml.docomolabsusa.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: mip6@ietf.org, Yoshihiro Ohba X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 James, I am fine with your suggested change. Thank you. Yoshihiro Ohba On Fri, Feb 25, 2005 at 09:08:44AM -0800, James Kempf wrote: > Yoshi, > > If the two sides use Diffie-Hellman, then the keys won't be generated > directly from authentication credentials. The Diffie-Hellman exponents don't > need to be related to authentication credentials at all. > > Instead of: > > "As mobility and network access authentication are seperate services, keys > generated from authentication credentials for these services need to be > cryptographically seperate, seperately named and have seperate lifetimes." > > How about: > > "As mobility and network access authentication are separate services, keys > generated for these services need to be cryptographically separate, > separately named, and have separate lifetimes, including if the keys are > generated from authentication credentials" > > This doesn't imply somehow that the keys will always be generated from > authentication credentials. > > jak > > > ----- Original Message ----- > From: "Yoshihiro Ohba" > To: > Cc: ; ; > Sent: Friday, February 25, 2005 5:57 AM > Subject: Re: [Mip6] Security Section Comments > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > > On Fri, Feb 25, 2005 at 08:02:02AM +0200, john.loughney@nokia.com wrote: > > > I agree with James on this. Yoshi - do you think the current text > prevents > > > both the network access & mobility service from sharing the same EAP > master key? > > > > I am not sure whether the current text prevents it or not, but it > > would be clearer if we can mention that the keys that need to be > > cryptographically separated are generated from authentication > > credentials (i.e., are not the keys in the authentication > > credentials), something like: > > > > " > > In addition to these attackes, there are other considerstions that > > are important in achieving a good security design. As mobility and > > network access authentication are seperate services, keys generated > > from authentication credentials for these services need to be > > cryptographically seperate, seperately named and have seperate > > lifetimes. This is needed because if one service is compromised, the > > other service is not. This is necessary so that a mobile host can > > move from one serving (or roaming) network access provider to another > > without needing to change its mobility access provider. Finally, > > basic cryptographic processes must provide for multiple algorithms in > > order to accommodate the widely varying deployment needs. > > " > > > > Regards, > > > > Yoshihiro Ohba > > > > > > > > > > John > > > > > > > -----Original Message----- > > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > > Sent: 24 February, 2005 20:42 > > > > To: Yoshihiro Ohba; Loughney John (Nokia-NRC/Helsinki) > > > > Cc: mip6@ietf.org > > > > Subject: Re: [Mip6] Security Section Comments > > > > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > > > > > > > > > > Yoshi, > > > > > > > > This works if EAP is used, but it might not be. From the > > > > perspective of the > > > > problem statement, I think it is sufficient to state that the > > > > keys need to > > > > be cryptographically separated. In the solutions document, > > > > this then can be > > > > addressed in a way appropriate to the solution. > > > > > > > > jak > > > > > > > > > > > > > > > > ----- Original Message ----- > > > > From: "Yoshihiro Ohba" > > > > To: > > > > Cc: ; > > > > Sent: Wednesday, February 23, 2005 4:41 PM > > > > Subject: Re: [Mip6] Security Section Comments > > > > ondraft-ietf-mip6-bootstrap-ps-01.txt > > > > > > > > > > > > > Hi John and James, > > > > > > > > > > I think that we might define which level of the keys for the two > > > > > services in the EAP key hierarchy needs to be cryptographically > > > > > separated (for simplicity let me assume that the keys are part > > > > > of EAP key hierarchy). > > > > > > > > > > It is always good to cryptographically separate keys > > > > derived from the > > > > > EAP MK (Master Key) for network access service and keys derived from > > > > > the EAP MK for mobility service. On the other hand, depending on > > > > > optimization level and deployment scneario, two EAP MKs may be the > > > > > same, meaning that cryptographic separation may not always > > > > be possible > > > > > at the highest level of the EAP key hierarchy. > > > > > > > > > > Yoshihiro Ohba > > > > > > > > > > > > > > > > > > > > On Wed, Feb 23, 2005 at 07:23:16AM +0200, > > > > john.loughney@nokia.com wrote: > > > > > > Hi James, > > > > > > > > > > > > > Actually, I think we want to keep the keys separate even if the > > > > network > > > > > > > access provider and mobility service provider are the > > > > same. From a > > > > security > > > > > > > standpoint, it makes sense to maintain separate keys, > > > > so that if one > > > > is > > > > > > > compromised the other won't be. I suppose one could > > > > argue that "well, > > > > if > > > > > > > the network access service is compromised, the user is > > > > so hosed, so it > > > > > > > really doesn't matter if mobility service is > > > > compromised" but the othe > > > > way > > > > > > > around is something different. If the mobility service key is > > > > compromised, > > > > > > > the mobile host could stay put at the same place and > > > > re-establish > > > > secure > > > > > > > mobility access service, as long as network access > > > > service is not > > > > > > > compromised. If the two keys are the same, then the > > > > mobile host must > > > > go > > > > > > > through re-establishing secure network access service > > > > before mobility > > > > > > > service security can be repaired. > > > > > > > > > > > > > > Does this make sense? If so, perhaps the draft should > > > > make this point > > > > > > > explicitly. > > > > > > > > > > > > I think we should make this point explicitly. To modify > > > > your proposed > > > > text: > > > > > > > > > > > > >> In addition to these attacks, there are other > > > > considerations that are > > > > > > >> important in achieving a good security design. Because > > > > mobility and > > > > network > > > > > > >> access authentication are separate services, any keys for these > > > > services > > > > > > >> need to be cryptographically separate, separately > > > > named, and have > > > > separate > > > > > > >> lifetimes that are not exceeded. This is necessary > > > > because a mobile > > > > host > > > > > > >> must be able to move from one serving (or roaming) > > > > network access > > > > provider > > > > > > >> to another without needing to change its mobility > > > > access provider. > > > > Finally, > > > > > > >> basic cryptographic processes must provide for > > > > multiple algorithms in > > > > order > > > > > > >> to accommodate the widely varying deployment needs. > > > > > > > > > > > > In addition to these attackes, there are other > > > > considerstions that are > > > > important > > > > > > in achieving a good security design. As mobility and > > > > network access > > > > authentication > > > > > > are seperate services, keys for these services need to be > > > > cryptographically > > > > > > seperate, seperately named and have seperate lifetimes. > > > > This is needed > > > > because > > > > > > if one service is compromised, the other service is not. This is > > > > necessary > > > > > > so that a mobile host can move from one serving (or > > > > roaming) network > > > > access > > > > > > provider to another without needing to change its mobility access > > > > provider. > > > > > > Finally, basic cryptographic processes must provide for multiple > > > > algorithms in order > > > > > > to accommodate the widely varying deployment needs. > > > > > > > > > > > > John > > > > > > > > > > > > _______________________________________________ > > > > > > Mip6 mailing list > > > > > > Mip6@ietf.org > > > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > > > > > > > > > > > > > > > > _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 12:41:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11822 for ; Fri, 25 Feb 2005 12:41:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jTF-00075Y-SE for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 12:41:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jLM-0000ZA-FR; Fri, 25 Feb 2005 12:33:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jLJ-0000P6-16 for mip6@megatron.ietf.org; Fri, 25 Feb 2005 12:33:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10991 for ; Fri, 25 Feb 2005 12:33:29 -0500 (EST) Received: from carrierpigeon.cs.umd.edu ([128.8.129.58]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jLR-0006uf-Md for mip6@ietf.org; Fri, 25 Feb 2005 12:33:42 -0500 Received: from MINDLAP2 (mindlap2.cs.umd.edu [172.16.0.37]) (authenticated bits=0) by carrierpigeon.cs.umd.edu (8.12.10/8.12.5) with ESMTP id j1PHXEnC021828 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Fri, 25 Feb 2005 12:33:19 -0500 (EST) Message-Id: <200502251733.j1PHXEnC021828@carrierpigeon.cs.umd.edu> From: "Moustafa Youssef" To: Date: Fri, 25 Feb 2005 12:28:13 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0016_01C51B36.2E8C7CB0" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-MS-TNEF-Correlator: 0000000006F61F65A15E334E985099AB7E0DC8D344492200 X-Spam-Score: 0.0 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Subject: [Mip6] 3rd CFP: IEEE WirelessCom Symposium on Mobile Computing, 2005 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C51B36.2E8C7CB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (Our apologies if you receive multiple copies of this CFP) ------------------------------------------------------------- Third Call for Papers Symposium on Mobile Computing http://www.csee.umbc.edu/~younis/WC_MobCom05.htm as part of=20 IEEE WirelessCom 2005 Sheraton Maui Resort, Kaanapali Beach, Maui, Hawaii, USA http://www.ece.queensu.ca/hpages/faculty/safwat/wirelesscom/05/ June 13-16, 2005 Technical Sponsorship: IEEE TCCC, TCPC, and SSCTC Recent years have witnessed an enormous growth in the development and applications of mobile computing environments and devices. Many practitioners envision a future empowered with context and location = aware computation and communication infrastructure that allow users to access = data and receive service at any place and any time. Compared to conventional platforms, the mobility of computing nodes introduces many challenges to = the design of almost all systems components.=20 This symposium will foster a forum for discussing and presenting recent research results on mobile computer systems. Original papers are invited = in the broader area of mobile computing. Papers must report high-quality = and previously unpublished work. Topics of interest include, but are not = limited to, the following: =95 Architecture and infrastructure support=09 =95 Middleware and operating systems services =95 Development platforms and environments =95 Adaptive resource management schemes =95 Pervasive and Context-aware Computing =95 Performance metrics and studies =95 Power aware computation and communication =95 Data consistency and synchronization protocols =95 Fault-tolerant architectural and operation models =95 Wearable computing devices and systems =95 Time constrained mobile systems =95 Robust ad-hoc networking techniques =95 Efficient localization techniques =95 Wireless sensor networks =95 Mobile peer to peer systems =95 Quality of service provisioning =95 Context-conscious computing =95 Web caching and services =95 Emerging applications and systems =95 Mobile agents =95 Mobile commerce =95 Security and privacy issues Submission Guidelines --------------------- Original papers are solicited and must represent high-quality and = previously unpublished work, not currently under review by another conference or journal. Prospective authors should submit their paper electronically through https://msrcmt.research.microsoft.com/WirelessCom2005. All = papers are limited to 6 pages in standard IEEE double-column format.=20 Important Dates --------------- Paper Submission Deadline: March 15, 2005 Notification of Acceptance: April 15, 2005 Camera-Ready Papers: May 1, 2005 Symposium Co-Chairs ------------------- Mohamed Younis Department of Computer Science and Electrical Engineering University of Maryland Baltimore County, 1000 Hilltop Circle, Baltimore, MD 21250 Voice: (410) 455-3968, FAX: (410) 455-3968 E-mail: younis@csee.umbc.edu=20 Hesham El-Rewini Department of Computer Science and Engineering Southern Methodist University 3145 Dyer Street, Dallas, TX 75205 Voice: (214) 768-3278, FAX: (214) 768-3085 E-mail: rewini@engr.smu.edu Publicity Chair ---------------- Moustafa Youssef Department of Computer Science University of Maryland at College Park, College Park, MD 20742 Voice: (301) 405-0341, FAX: (301) 405-6707 E-mail: moustafa@cs.umd.edu ------=_NextPart_000_0016_01C51B36.2E8C7CB0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Disposition: attachment; filename="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhERAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBoCgAAEQAAAAsAAQ4BAAAAAgEKDgEAAAAYAAAAAAAAAAb2 H2WhXjNOmFCZq34NyNPCgAAAAwAUDgEAAAALAB8OAQAAAAIB+A8BAAAAEAAAAAb2H2WhXjNOmFCZ q34NyNMCAfoPAQAAABAAAAAG9h9loV4zTphQmat+DcjTAwD+DwUAAAACAQkQAQAAANkIAADVCAAA XhAAAExaRnXjznrwAwAKAHJjcGcxMjXiMgNDdGV4BUEBAwH3TwqAAqQD4wIAY2gKwHPwZXQwIAcT AoAP8wBQfwRWCFUHshHFDlEDARDHMvcGAAbDEcUzBEYQyRLbEdPbCO8J9zsYvw4wNRHCDGDOYwBQ CwkBZDM2EVALpoggKE8IcCBhcBhBTmcIkAQgBpAgeQhgIAEYwGNlaXZlIG1odWx0BSBsH1AFoHBl HkJvHpB0aAQAEsBG3FApCqIKhAqALSH/Iw+3JB8ktyE0ICYvJlBUILC/CyASwAdAAyACEAXAUB3g fwSQELAl3yZQBrEd8ACQdcZtIGADoE1vYgMQH1BLCFAqEHUfoG5nKLZoQQJAcDovL3cssC4SYxEg ZS4qYGJjLjEJgHUvfh6xAwBzLxhXQ18qwSsxMDUu7SxAbSi/ME9hBCAKsQVAJyBxL08wU0lFM4Ag V90ngGUf0AQQKzEgAdAu4EkhNFNoBJBhdCqSYRx1aQfwB5AYYSwgS55hAHAd4AdANeBCZQDQjmg2 YDWyNmBIYXcLcHE3wVVTQSE0LEkfAS4mcQpQCfBzdSzgYS/KaAqwZweQL2YA0B+BoHkvc2FmOBB0 LKDTM9UFoG0vLuAvMh89dgZKLgAfUDEzLTE27zZgNIgnQQWQaAMAOnADIO5THfAAgAWwcyCwLHAz ZNxUQ0HQNmBBwFBB8QBw8SegU1NDQcAhOiE0NgC/HxACMB6gNzARECwwYR9BvQPwdD6gBBAJgEJx IAnwmwWwBGB1BCAJwG93IKB/HnADoCCgH1ABAB9AGFBw/weARHFCgh3gC1BAUR+gQMG/IGIEYCrj PIErZEYRdieAfwIgSAIEIEKCR5EN4AeQLtk1oW55MYA1UGMfoEkC7yiBSpMAkCqRYSgAK3AIcPUf UGUqEXcEkEXBRVFHAP8FoAIwDsJCghhQSOQd0DgQ/05hSgRQdUKRPIEfcEBCUIPnC4ADUDFgdHIb cE5DIKDvNWAd0CfgRtAgRoBNMjVw7R3QY0vxBCBkNWBOAEKC/x72VMFL0h3QSDJMcQtgVxL/SGJM YR+gB4BMICsyUPEnoP9VEU+BH0ACMEkRQHELUQAw/UZBczZgR1JJk0VgTHAgcf9KCEYwAQAeYQIw A2AtoEvx/x9gTFIQ4SfgCfA60VUCR1T9AJBnA6AgcQdABGBTYFRC/VaweVNgTpAEIEoCTRFLMf9M ICE6J2EEIGCgKhYD8Cfj32DBHcEoAiphKBJkBAA7MP8EEEpiQoJMkAeQWfJKcR7y/0RxZhIKwBDg ZxIfgSBRA6DvSZsTIWClTCBPBRAeMFpD/yhjHdBOYQuASsAOsCegRyX6YgNgYQSBauJOAElvK6D/ TCAoVB9hYDEYwB3wMbEgsPhnaC058DbhW9FlxUrA/UZxbExwLgArYAJgBAA1MOtPEQWwa0wgVCAR LPAgYu9dMU7hYDELgGMKQAEANmC+YitwauNGMAVANvBta2NfNXBbFAIQVGIrkTpDGyf+OTSwAZER YRDga2FTpEKCP1MdOkBIoBhhd3N23U1p/GRkH9BQ40KCIBA1Qkpi72CmVsUopXc3REepWodCc/9K qnbeVbAFMB8yZhEIYVcRfwOBOsFIAwTwNTAHgXbdUL9W0TFgHzJCgghQT6MtUNT/Kz2E6lrCAHCD MhEwBRBykf9CglNgc8AeQYfOTsJQz1Hf/wIgfg5Vwk+BAJBgwXOQcCTLYKBzkGhK4Wl6UHRMkG90 oFBQBvB9/kY1wB+QLf81cB/QNVBIInfYQHF8KWgz+wEAkd9XRLEBoEnbS7WQFf9gw3bdB2KPU1Nw C3FFwUmVH5jfd3MIAHQQYDJkLWj/UFBcwBEwcfJKYngRQDE58f19/kUBIA3gCJBEcVBCNvD/kPWe r5ZnM9VWsUDSneZ9/n8qxShwEyFVEaYTm793c1H/b9UgcVbGkWFNlIefhkePYv+gcEZySgeV/3eg OnB34WWV932Pn9UHgHJqIWWhSKqYn/+lHjrBgS8qtlIyBJAfEHbd/wZgOzAFEHAXHzAA0ExwBAF7 ohghSVNxYHTwZWEqkUf/NdCVsZrxKKUkvyWIaf95kv8G8KBha3JCgm62ZhRvb3B//3GJNmB0krbx GMACMMGjbGJ7wTIH0WLAwnSgNTFPcmb3TuGJMgWxaghhWkFuIQNg/nMocEzBheIrcJ2wRNFBEP0I YGyKEbmyBUBHUSeAanT/RhAf0EzAkLJAYcGhIKADYPZ1wDAsM3MsgVrwZ3AOoPouZyYudPAFACow IHDL4O88gjPJNIJMIEEn4WqJdNj8IDYxgV6iRyFTYEKBCxG9M2RkCGCXMauRCkBtA6D3iOPL4GHb SSoRACCTko8R/7rfJWooUwYAubh+8GxQuqKnQVB7JGdjMTU/Kk50oPcGkFKWIHFBVVEFMIki2AU+ QbehAyDY3CfAsEFhLb82AGxQTHAoVNgHTHAxPyrnNMUqBwhQLUMQ8CeA1L/fJT0qwBDwB4AnoFkt 8yE0/37wMZJIAyBxKzTWoqByV+X2RcmzQFNFK6Ca8QZxSnG+VQMAH0AREFvF2HF5C2D9QpFCB0BY kQWwhxIuADtgbTZgMTSQEVBIY6E1cHC/EsAngHOgc+HphzdxRDRwZw4hAUAhQ1ZvS+FBUCgiNOqg KSA0GwAtMxg5Njg2YD1xRkFY8+3eITRFLQDAAxBBUC3k9kAs+2HbSAeQ41Hmkd1h/3YhAKDkL+U/ 5kXnaDTFCGD/xQIqoREwnbBlEQVA6BghNPwzMe5QfuBEoNaxU3AJ4B82UY8QJ+AxYEIBWCA3rw5A NKbthuzQNO4wN+6wee6AMjfuwJKU7zP9GDBeODS18LYYwPQCQF6Bcvwucx9wLYK4j9ZgcWK+gf9M cODj4U/ii27BO6BOAOOx/UWhZvRP9V+1xugf6SRUIf8S0F5hOtAoQcKx3KUKquyTuDA3NA5Q7Tv/ MDHuMXEu4C0wM+4A7tkOBzZ+Nwzg8FxGYgWS8ZEtMWQFAUh9EtAAAAADAA00/T8DAAMADzT9PwMA AgEUNAEAAAAQAAAATklUQfm/uAEAqgA32W4AAAIBfwABAAAAMQAAADAwMDAwMDAwMDZGNjFGNjVB MTVFMzM0RTk4NTA5OUFCN0UwREM4RDM0NDQ5MjIwMAAAAAADAAYQ8PwnxwMABxD0CgAAAwAQEAAA AAADABEQAAAAAB4ACBABAAAAZQAAAChPVVJBUE9MT0dJRVNJRllPVVJFQ0VJVkVNVUxUSVBMRUNP UElFU09GVEhJU0NGUCktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0AAAAAFao= ------=_NextPart_000_0016_01C51B36.2E8C7CB0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 ------=_NextPart_000_0016_01C51B36.2E8C7CB0-- From mip6-bounces@ietf.org Fri Feb 25 13:56:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18065 for ; Fri, 25 Feb 2005 13:56:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4kdi-0000DZ-Rl for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 13:56:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4kaH-00045s-4R; Fri, 25 Feb 2005 13:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4kaF-00045l-CQ for mip6@megatron.ietf.org; Fri, 25 Feb 2005 13:53:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17687 for ; Fri, 25 Feb 2005 13:53:01 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4kaP-00007c-51 for mip6@ietf.org; Fri, 25 Feb 2005 13:53:14 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PIqwZ21697 for ; Fri, 25 Feb 2005 20:52:58 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 20:52:44 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1PIqiw0004278 for ; Fri, 25 Feb 2005 20:52:44 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00Zq9VpR; Fri, 25 Feb 2005 20:52:43 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PIqgU28251 for ; Fri, 25 Feb 2005 20:52:43 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 12:52:38 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2005 12:52:38 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C8A7@daebe101.NOE.Nokia.com> Thread-Topic: Bootstrapping Solution Design Team thread-index: AcUbay2hvAO56y+6RFWId2dGXc01zA== To: X-OriginalArrivalTime: 25 Feb 2005 18:52:38.0477 (UTC) FILETIME=[2D4367D0:01C51B6B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Bootstrapping Solution Design Team X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: quoted-printable Hello, A design team to work on a solution to the bootstrap problem (draft-ietf-mip6-bootstrap-ps-01) has been formed. The design team consists of: Gerardo Giaretta[Editor], Alpesh Patel, Yoshihiro Ohba, James Kempf, Vijay Devarapalli and Alper Yegin. There have been several solution I-Ds to address the bootstrapping problem to this date. The DT will consider these I-Ds in the course of the overall solution proposal. The DT solution I-D will eventually require WG consensus in order for it to be accepted as a WG document.=20 A mailing list for the DT discussions has been setup (thanks to Gerardo).=20 http://vesuvio.ipv6.cselt.it/mailman/listinfo/mip6-boot-sol If you absolutelty want to be on this ML, please contact Gerardo Giaretta (Gerardo dot Giaretta at tilab dot com). The archives of the DT discussions will be made available when it terminates.=20 -Chairs _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 14:35:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22394 for ; Fri, 25 Feb 2005 14:35:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4lFt-00014i-2t for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 14:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4lEA-0002Mh-BA; Fri, 25 Feb 2005 14:34:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4lE8-0002ML-NG; Fri, 25 Feb 2005 14:34:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22160; Fri, 25 Feb 2005 14:34:14 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4lEJ-00011r-Pf; Fri, 25 Feb 2005 14:34:28 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PJYCU04603; Fri, 25 Feb 2005 21:34:12 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 21:47:26 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1PJlQE5030142; Fri, 25 Feb 2005 21:47:26 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00nrEviW; Fri, 25 Feb 2005 21:46:58 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PJXYU29265; Fri, 25 Feb 2005 21:33:34 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 13:33:33 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] IETF62: Timeslot requests on mip6 agenda Date: Fri, 25 Feb 2005 13:33:32 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C8A9@daebe101.NOE.Nokia.com> Thread-Topic: [Mip6] IETF62: Timeslot requests on mip6 agenda thread-index: AcUTlRChNKalx2JvSle5Q8vszwookgH2shog To: X-OriginalArrivalTime: 25 Feb 2005 19:33:33.0024 (UTC) FILETIME=[E4498E00:01C51B70] X-Spam-Score: 2.7 (++) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable Hi Wassim, As you are well aware, the Mobopts RG is primarily focused on dealing with optimization pertaining to IP mobility; And that encompasses the MIP6 protocol.=20 I do not think that we will make any progress as a result of presenting this I-D at the MIP6 WG meeting in IETF62. My recommendation is that this optimization technique be discussed in the Mobopts RG first; the outcome of the discussion therein can then propel the MIP6 WG to take up the standardization of this I-D if it is so deemed. As the MIP6 charter says: " It should be noted that there are potential optimizations that might make mobile IP more attractive for use by certain applications (e.g., making handovers "faster"). The latter category of optimizations is explicitly out-of-scope at this time;=20 " If you still think it makes sense to present this I-D to the MIP6 WG at IETF62, please indicate what you would hope to accomplish as a result of the 10 mins. -BPa > -----Original Message----- > From: ext Wassim Haddad > Sent: Tuesday, February 15, 2005 1:32 PM > To: Patil Basavaraj > Cc: mip6 > Subject: Re: [Mip6] IETF62: Timeslot requests on mip6 agenda >=20 >=20 > Hi Raj, >=20 > I would like to ask please for a slot to present=20 > draft-haddad-mip6-cga-omipv6-03 > (Optimizing Mobile IPv6 with CGAs, OMIPv6-CGA). >=20 > IMHO, this draft is relevant to the mip6 WG because it presents an=20 > efficient > optimization to the RO mode. >=20 > Slot Duration: 10 minutes. >=20 >=20 > Regards, > Wassim H. >=20 >=20 > On 15-Feb-05, at 5:08 AM, Basavaraj.Patil@nokia.com wrote: >=20 > > > > > > Hello, > > > > If you need a timeslot for presenting at the MIP6 WG meeting > > in Minneapolis (IETF62), please send the same to the chairs. > > Note that WG items have priority. > > It is essential that you have an I-D that has been submitted > > in order to get a slot on the agenda. > > Please state why this I-D is relevant to the MIP6 WG in the > > request along with the duration of time needed. > > > > -Basavaraj > > > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > > >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 15:33:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28550 for ; Fri, 25 Feb 2005 15:33:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4m9U-0002LH-S3 for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 15:33:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4m3u-0000np-2u; Fri, 25 Feb 2005 15:27:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4m3r-0000nV-Si; Fri, 25 Feb 2005 15:27:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27406; Fri, 25 Feb 2005 15:27:41 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4m42-000227-KV; Fri, 25 Feb 2005 15:27:56 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PKRdU01584; Fri, 25 Feb 2005 22:27:39 +0200 (EET) X-Scanned: Fri, 25 Feb 2005 22:36:14 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1PKaEFm030527; Fri, 25 Feb 2005 22:36:14 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00Gr5mAO; Fri, 25 Feb 2005 22:36:00 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PKMZU16687; Fri, 25 Feb 2005 22:22:36 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 14:22:17 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Draft agenda of meeting at IETF62 Date: Fri, 25 Feb 2005 14:22:16 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C8AE@daebe101.NOE.Nokia.com> Thread-Topic: [Mip6] Draft agenda of meeting at IETF62 thread-index: AcUYdDrDuSmd9BEESHW2/90BOl6PegDAqtQA To: , X-OriginalArrivalTime: 25 Feb 2005 20:22:17.0821 (UTC) FILETIME=[B39A28D0:01C51B77] X-Spam-Score: 2.7 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: mobopts@irtf.org X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.7 (++) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable Hi Fan, Enhancements to RR for the reasons that you mention are probably worth being discussed first in the Mobopts RG. I see that you have requested a slot in the Mobopts meeting at IETF62. Both location privacy issues/optimizations and enhancements to RR mechanism and RO should be discussed in therein. Recommendations coming from the Mobopts RG can then be taken up in the MIP6 WG. At this time, I do not see a reason to allocate a timeslot for this discussion in the MIP6 WG meeting at IETF62.=20 -BPa > -----Original Message----- > From: ext Fan Zhao [mailto:fanzhao@ucdavis.edu] > Sent: Monday, February 21, 2005 6:18 PM > To: Patil Basavaraj (Nokia-NET/Dallas); mip6@ietf.org > Subject: RE: [Mip6] Draft agenda of meeting at IETF62 >=20 >=20 >=20 > Dear MIP6 WG Chair, >=20 > I would like to request a time slot to discuss about > draft-zhao-mip6-rr-ext-01 at the MIP6 WG meeting in=20 > Minneapolis. Thank you very much. >=20 > Sincerely, > fan > =20 > >=20 > > If you had sent a request for a slot and do not see > > it on the agenda below, please send me an email. > >=20 > > -Basavaraj > >=20 > >=20 > >=20 > > Draft Agenda of MIP6 WG meeting at IETF62 > > Monday March 7th, 1930-2200 > > ------------------------------------------ > >=20 > > 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins > >=20 > > 2. WG status update Chairs 20 Mins > > MIB I-D > > IKEv2 I-D > > Auth I-D > > Bootstrap PS > >=20 > > 3. MIP6 Advance API issues Samita C. 10 Mins > >=20 > > 4. MIP6-AAA Frameworks Alper Yegin 10 Mins > > Email thread on ML and I-D: draft-yegin-mip6-aaa-fwk-00 > > =20 > > 5. Discussion of how to proceed with=20 > > I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt 20 Mins > > Giaretta Gerardo > >=20 > > 6. MIP6 Bootstrapping 20 Mins > > I-D: draft-chakrabarti-mip6-bmip-00 > > James Kempf > >=20 > > 6. PF_KEY Extension as an Interface between MIP6 and IPsec/IKE > > I-D: draft-sugimoto-mip6-pfkey-migrate-00 15 Mins > > Shinta Sugimoto > >=20 > > 7. Location privacy in MIP6 Rajeev Koodli 15 Mins > > I-D: draft-koodli-mip6-location-privacy-00.txt =20 > > draft-koodli-mip6-location-privacy-solutions-00.txt =20 > >=20 > > 8. A Scheme of Mobile Firewall in MIP6 Qiu Ying 10 Mins > > I-D: draft-qiu-mip6-mobile-firewall-00.txt > >=20 > > Time permitting: > > 9. Discussion of other I-Ds of possible interest to WG: > > MOMIPRIV Wassim Haddad > > draft-haddad-momipriv-problem-statement-01.txt =20 > > draft-haddad-momipriv-threat-model-00.txt=20 > >=20 > > 10. 6th TAHI and Connectathon 2005 Yukiyo Akisada > >=20 > >=20 > > _______________________________________________ > > Mip6 mailing list > > Mip6@ietf.org > > https://www1.ietf.org/mailman/listinfo/mip6 > >=20 >=20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Fri Feb 25 17:33:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09625 for ; Fri, 25 Feb 2005 17:33:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4o1j-0005G6-HB for mip6-web-archive@ietf.org; Fri, 25 Feb 2005 17:33:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ny7-0007Yw-3E; Fri, 25 Feb 2005 17:29:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ny5-0007Yo-Rk for mip6@megatron.ietf.org; Fri, 25 Feb 2005 17:29:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09371; Fri, 25 Feb 2005 17:29:51 -0500 (EST) From: Basavaraj.Patil@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4nyI-0005CH-NR; Fri, 25 Feb 2005 17:30:07 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PMTnc17388; Sat, 26 Feb 2005 00:29:50 +0200 (EET) X-Scanned: Sat, 26 Feb 2005 00:29:36 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1PMTaQL000743; Sat, 26 Feb 2005 00:29:36 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00zXT5S7; Sat, 26 Feb 2005 00:29:35 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1PMTYU02465; Sat, 26 Feb 2005 00:29:34 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 25 Feb 2005 16:29:30 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2005 16:29:28 -0600 Message-ID: <456943D540CFC14A8D7138E64843F85308C8B5@daebe101.NOE.Nokia.com> Thread-Topic: Revised agenda for Mobility for IPv6 (mip6) WG meeting at IETF62 thread-index: AcUbiXdyRbq+0DbOR86O8dSL1aDsvg== To: X-OriginalArrivalTime: 25 Feb 2005 22:29:30.0190 (UTC) FILETIME=[78D93EE0:01C51B89] X-Spam-Score: 0.3 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org Subject: [Mip6] Revised agenda for Mobility for IPv6 (mip6) WG meeting at IETF62 X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: quoted-printable Agenda of Mobility for IPv6 (mip6) WG meeting at IETF62 Monday March 7th, 1930-2200 Chair(s): Basavaraj Patil Gopal Dommety ------------------------------------------ 1. Agenda, Bluesheets, Note-takers and Jabber scribes 5 Mins 2. WG documents status update Chairs 20 Mins - draft-ietf-mip6-mipv6-mib-06 - draft-ietf-mip6-auth-protocol-04 - draft-ietf-mip6-mn-ident-option-02 - draft-ietf-mip6-bootstrap-ps-01 - draft-ietf-mip6-firewalls-01 - draft-ietf-mip6-precfgkbm-01 - draft-ietf-mip6-cn-ipsec-00 3. Discussion of WG I-Ds: - draft-ietf-mip6-mipext-advapi-03 Samita Chakrabarti 10 Mins - draft-ietf-mip6-ikev2-ipsec-01 Vijay Devarapalli 10 Mins 4. PF_KEY Extension as an Interface between MIP6 and IPsec/IKE I-D: draft-sugimoto-mip6-pfkey-migrate-00 15 Mins Shinta Sugimoto 5. MIP6-AAA Frameworks Alper Yegin 10 Mins Email thread on ML and I-D: draft-yegin-mip6-aaa-fwk-00 =20 6. Discussion of how to proceed with=20 I-D: draft-giaretta-mip6-aaa-ha-goals-00.txt 15 Mins Giaretta Gerardo 7. MIP6 Bootstrapping 20 Mins I-D: draft-chakrabarti-mip6-bmip-00 James Kempf 8. Location privacy in MIP6 Rajeev Koodli 15 Mins I-D: draft-koodli-mip6-location-privacy-00.txt =20 draft-koodli-mip6-location-privacy-solutions-00.txt =20 9. A Scheme of Mobile Firewall in MIP6 Qiu Ying 10 Mins I-D: draft-qiu-mip6-mobile-firewall-00.txt 10. IPv4 traversal for IPv6 Mobility Protocols 10 Mins I-D: draft-wakikawa-nemo-v4tunnel-01.txt Ryuji Wakikawa/Vijay Devarapalli 11. MN-HA signaling for HA Unavailability James Kempf/Vijay Devarapalli I-D: Based on draft-haley-mip6-mh-signaling-00.txt Time permitting: 12. Discussion of other I-Ds of possible interest to WG: MOMIPRIV Wassim Haddad draft-haddad-momipriv-problem-statement-01.txt =20 draft-haddad-momipriv-threat-model-00.txt=20 13. 6th TAHI and Connectathon 2005 Yukiyo Akisada =20 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Sun Feb 27 10:14:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04623 for ; Sun, 27 Feb 2005 10:14:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Q8H-0007oR-Nd for mip6-web-archive@ietf.org; Sun, 27 Feb 2005 10:14:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Q5r-0004QC-WD; Sun, 27 Feb 2005 10:12:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Q5q-0004Mp-HK for mip6@megatron.ietf.org; Sun, 27 Feb 2005 10:12:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04422 for ; Sun, 27 Feb 2005 10:12:24 -0500 (EST) Received: from email1.etri.re.kr ([129.254.16.131] helo=email1.etri.info) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Q6N-0007mu-WF for mip6@ietf.org; Sun, 27 Feb 2005 10:13:01 -0500 Received: from FlyToWorld ([192.168.250.7]) by email1.etri.info with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 00:13:03 +0900 Message-ID: <001101c51cde$c2cf7360$07faa8c0@FlyToWorld> From: "Junghoon Jee" To: , References: <456943D540CFC14A8D7138E64843F85308C8A7@daebe101.NOE.Nokia.com> Subject: Re: [Mip6] Bootstrapping Solution Design Team Date: Mon, 28 Feb 2005 00:12:32 +0900 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 27 Feb 2005 15:13:03.0570 (UTC) FILETIME=[D53BA320:01C51CDE] X-Spam-Score: 2.2 (++) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0851579189==" Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 2.2 (++) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 --===============0851579189== Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 SGVsbG8gQmFzYXZhcmFqLA0KSSB3b3VsZCBsaWtlIHRvIGpvaW4gdG8gdGhlIGJvb3RzdHJhcHBp bmcgZGVzaWduIHRlYW0gaWYgcG9zc2libGUuDQpGcm9tIHRoZSBsYXN0IElFVEYsIGkgaGF2ZSBi ZWVuIGV4cHJlc3NpbmcgbXkgd2lsbGluZ25lc3MgdG8gDQpqb2luIHRvIHRoZSBib290c3RyYXBw aW5nIERULg0KDQpUaGFuayB5b3UgaW4gYWR2YW5jZS4NCg0KSnVuZ2hvb24gSmVlDQogDQoNCi0t LS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiA8QmFzYXZhcmFqLlBhdGlsQG5va2lh LmNvbT4NClRvOiA8bWlwNkBpZXRmLm9yZz4NClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAyNiwg MjAwNSAzOjUyIEFNDQpTdWJqZWN0OiBbTWlwNl0gQm9vdHN0cmFwcGluZyBTb2x1dGlvbiBEZXNp Z24gVGVhbQ0KDQoNCg0KDQpIZWxsbywNCg0KQSBkZXNpZ24gdGVhbSB0byB3b3JrIG9uIGEgc29s dXRpb24gdG8gdGhlIGJvb3RzdHJhcCBwcm9ibGVtDQooZHJhZnQtaWV0Zi1taXA2LWJvb3RzdHJh cC1wcy0wMSkgaGFzIGJlZW4gZm9ybWVkLiBUaGUgZGVzaWduIHRlYW0NCmNvbnNpc3RzIG9mOiBH ZXJhcmRvIEdpYXJldHRhW0VkaXRvcl0sIEFscGVzaCBQYXRlbCwgWW9zaGloaXJvIE9oYmEsDQpK YW1lcyBLZW1wZiwgVmlqYXkgRGV2YXJhcGFsbGkgYW5kIEFscGVyIFllZ2luLg0KDQpUaGVyZSBo YXZlIGJlZW4gc2V2ZXJhbCBzb2x1dGlvbiBJLURzIHRvIGFkZHJlc3MgdGhlIGJvb3RzdHJhcHBp bmcNCnByb2JsZW0gdG8gdGhpcyBkYXRlLiBUaGUgRFQgd2lsbCBjb25zaWRlciB0aGVzZSBJLURz IGluIHRoZSBjb3Vyc2Ugb2YNCnRoZSBvdmVyYWxsIHNvbHV0aW9uIHByb3Bvc2FsLiBUaGUgRFQg c29sdXRpb24gSS1EIHdpbGwgZXZlbnR1YWxseQ0KcmVxdWlyZSBXRyBjb25zZW5zdXMgaW4gb3Jk ZXIgZm9yIGl0IHRvIGJlIGFjY2VwdGVkIGFzIGEgV0cgZG9jdW1lbnQuIA0KDQpBIG1haWxpbmcg bGlzdCBmb3IgdGhlIERUIGRpc2N1c3Npb25zIGhhcyBiZWVuIHNldHVwICh0aGFua3MgdG8NCkdl cmFyZG8pLiANCmh0dHA6Ly92ZXN1dmlvLmlwdjYuY3NlbHQuaXQvbWFpbG1hbi9saXN0aW5mby9t aXA2LWJvb3Qtc29sDQoNCklmIHlvdSBhYnNvbHV0ZWx0eSB3YW50IHRvIGJlIG9uIHRoaXMgTUws IHBsZWFzZSBjb250YWN0IEdlcmFyZG8NCkdpYXJldHRhIChHZXJhcmRvIGRvdCBHaWFyZXR0YSBh dCB0aWxhYiBkb3QgY29tKS4NClRoZSBhcmNoaXZlcyBvZiB0aGUgRFQgZGlzY3Vzc2lvbnMgd2ls bCBiZSBtYWRlIGF2YWlsYWJsZSB3aGVuIGl0DQp0ZXJtaW5hdGVzLiANCg0KLUNoYWlycw0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpNaXA2IG1h aWxpbmcgbGlzdA0KTWlwNkBpZXRmLm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbWlwNg== --===============0851579189== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 --===============0851579189==-- From bhovtm@go2.pl Sun Feb 27 12:07:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13280; Sun, 27 Feb 2005 12:07:50 -0500 (EST) Received: from [12.170.10.72] (helo=VCON-73V38UZR1K) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D5Ru7-0001NF-VZ; Sun, 27 Feb 2005 12:08:28 -0500 Received: from symphony-59.go2.pl ([4.240.11.33]:1906 "HELO mail.go2.pl") by go2.pl with SMTP id ; Sun, 27 Feb 2005 19:05:15 +0200 Date: Sun, 27 Feb 2005 15:08:15 -0200 Message-Id: <4.0.07.2081924.0083fc70@go2.pl> From: "Scott Boyle" To: Subject: You have qualified. X-message-flag: Authentic Sender, Hash: LKQLMTEA List-ID: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----------A48356845382213" X-Spam-Score: 7.1 (+++++++) X-Spam-Flag: YES X-Scan-Signature: 2ce306e4307a2c0b518ae453b13efdd0 This is a multi-part message in MIME format. ------------A48356845382213 Content-Type: multipart/alternative; boundary="----------A85031401794097" ------------A85031401794097 Content-Type: text/plain; Charset = "us-ascii" Content-Transfer-Encoding: 7bit http://www.g3tit.com/mortgage.asp. ------------A85031401794097 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit electrocardiograph insincere

 
 
 
 
 
 
.
.
.
http://www.g3tit.com/mortgage.asp It's time to fix up your situation for once and for all
.  
   
No More ------------A85031401794097-- ------------A48356845382213 Content-Type: image/gif; name="chuck.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Transfer-Encoding: base64 R0lGODlhbAHAAZEAAP///8zMzDMzMwAAACH5BAAAAAAALAAAAABsAcABAAL/hI+py+0Po5y02ouz 3rz7D4biSJbmiabqyrbuC8fyTNf2jef6zvf+DwwKh8Si8YhMKpfMpvMJjUqn1Kr1is1mAtqu94vh gsfkq9hwLqvX7Lb7DY/L54kBwk7P6y94RZ/B9fe3R1i4MHiAeHgHkGb4SKgI0CfGlSZ44NgIyfkm KTgQmjnJeBcq2Zn69ZlYaoDZGqs66xV4eitKWier28tLC3zF6vvK24eIGqzsNIx7avxLvDzNzICX DCudTM1d1OyQjdw9vjRMfOzqm03O3iNmPnmb/hcgn96OH6UpsZ3vj7MvzK5/BIsE5IOmoMKFDBs6 fAgxosSJFCtavIgxo8aN/xw7evwIMqTIkSRLmjyJMqXKlSxbunwJM6bMmTRrBjs4AeeWnEB0JvBZ iYLPnhKGKnBklEzSDfQgGF3aT8lSgdIcTO1wFYWdS36o/qxgNOrREKhQPfXqFMYgSTrFCh2rQwCC QD/dyrB7YeigM3gjZLUag17fYmTWnlvwdxRcQHMHLgaclas1wA+AUlacFilZx5swL6rcILENTOvi 5QJnj9SzV6snpyacqHVs2bjqyGYt6tPr19ZS29ld77bp0rp+C98t3NRq46dnn6792RjtrjtIz7vH ubjhaLHv8L3+65rjdaAaiOMenrWr5uSjXWsfi/g99vPRp4fd67wOdLD5Y/83j582k43nHoBVCYhg Qvf9t494A50HIXURUvdfgPpR2I9/E3qnQz2yaOjHQc5YGGJ0H8ryjnLLebYhd1wIIFmFuK34oIQ2 1ohjHY6UpeB5ttyS4gMg5mgfDb/tAsqIA8Znm5IUnjijb+P55oyDjDQ414XZWcnkKFwShsd3CCpS JY/p0EVigNH516WMRh4m35JtqglgjGxmd+CXV8q4HYdPgnljKRDuqOaXaPIzkJj6RXUkL2hqiUOj rcRpIqBucnbonX6ipyeKdKZZYYuWChronKNeumWpmUYg6Zh/5kDmnzy+o2eftl0XJJTqHQZqeXLi h40phQ4L7Dy1QsNrpYv/CvtpVzFOIuauPMTqB2/V5kYndIvwtha3zxzj7W3yYMNeck02Kqo6x31L 7IwqbkOjsdjOJuQh685Ly2A2IaQPDFnp69cTkXXhoROixVAwQQEd/CY3DIvwMMFsRLyvChQrhXCz J2x1A8A3RGyPZkVWR5ZsF0/gsQYpi7ByxyrXiyqsILT8Ac0W2OwBzjN4DC+eP+CsM1NqyVxNBj3H HGlnOx04tLXa2motI07fS5q5KhYzdXPDdUtf1Oeeqd1qDdL2miXQMYfMdFOKK2XWkmrbW7li+xsP eF3mSil90OSaH6Xq1N0K33eyCa6b4WAIAXwGdodsf6Xm96Ag0QJuK2d+/7sAqa6awnNq56QknAiW rx4rzaGm5kkdjASGtiw4eJKuOqmISiMX6J7/CrnLlj+tK6ePF/c758SmO/yrxa/uWYKKTO4qkbc7 l0u6nVaae/IttB5LwuA6mV3BZUYZr++jt/t0le2+Tr71ysNcYPPrhcyr9NAvruvJ/Mp+3eWlKEo/ +tS7Lz4zhSp4I8Per+SXIOcBT4HCS5/u8AcN/bVPgOP7HwKVtkDqCY90THNg/xCYuQyejoM+W98D e6c1LenGbo6DYLOsg7zqtXCE9COPpp50ucrJ0Ia9YpYBo1dCdTCPbgkcl8/ghiSqce05CiLGJWg0 uXClUEpBHM61WjW3K/+OonaoIaHb+sa2eV3IiFESkrh2YL/GpPEyQ1jjW/KyATeC5Y1GwIkb5WgB PNLRHWy0wcKCoMfHoMUE+5hKIPsIsRzg8ZAeEBlimliCszRmj4PMWAiGssZMUiEpdiRBIeEIyUem oJOMyeMIDsJIQSLSB6lE2s+6iBevofFmWllGWybJqqQ1rgI6ayUbm4I7lH1FDaS8nyhNhMphhuYx oiuWMXFJSU8+00BXwcsnQaNIUNISg7mEJjZn1j9lvkonQUnLMUEgolAaLy0A8+Vmvvi1SZ3xauZB jtbsJcYSlbFxtakcrVoDJHnKJW737BHZurYcgFpxPgeVGzDlec/dLDT/oM6BleL+9iFMpEhwrrMc N6XjwRliFFSyeh/7itFMERaOcWDSKEqdeb6yXHSl0oIWTGsAQgKK9IX+q2AIqxeAgb50px5VYOKC KSqOeW5I6+mp/5KaI77tTKcX3Jw6dbjBmPJulzLE4e/waTLuQNWF1TNgArEzANN1bjs/xZyEzAfA GX7vgOusagxLc6dnES9VFnwcWxEHPia+y1w5rc/WrOZWox6vqRoraQkLy9ibYu2ke22f8ZS6Vgb2 zrHdJOuX/goQtPI0Sx60C1Zxdw1CmVCyqqHsV0XbV+eBNiFMVZYwNZus541GqXjlhVD1JlkKstZY IAUW4f6TIb2OTF01/4Rp5d7Dwj6JY4ghHZxjYtdYFhhHAGkLY9VSeK4wxY2esFQXvqx4XLEeNZ7Z RW95K7ogQHErvE161yPHqLb4InGq4HyldpsQlqXNghIdMIs2semToIlTwRq4mCYMLIMzuDOS7S1l FdVZyWUut78fRSdPStCPv2hCjxPm4zFHzIISezPDM/jjgStGRD/2scQqBjAiJJnIBo9gG2cQ6geS sg5HQlKWpwzYio18zm/iVMkcIPAcsQLJWxaJUUxO8nA7G81LPvkxDH6BggOiL3JaeGl+o7KW/4Bd CnQZw6ocs/r+h4R2btPNdH6zKdcJZ5+hWM3U3fOGt4zkHN+5xh1Fg//b0BG1fzr0nPb87hKXWNSK Juk5jU6cRAvYUGoFzl0TNM22pgPQ/LZQ0bDd2l2iG7lNVVBjsAjH4SKLUdP5KlljLLRIg8XVHt11 gjdmad8iLV27OfmzgbGsTm372CFTFbX8xLN1Lwxr4XYVsHEVoQbTFK30Vnt6Xja2kn562th69lM/ 9PZWjX1FwY4W1mvqtGLdbVltQ7Zhq13qB+t6beXJQ607jHcMD1vQHh4gzZnwMVGRN+98P1qhzj32 fv+7WBrSNdk+xbdNow3vzbplWVItdYZGerfTPfXCjcIbAR9c7Ijbe+IDrDjFy63yrm6c2kwz67Zg W1mV9yzYuMVzLXf/6Stwe7W5Ix0ryNtDq+KedS9KLzMLlVnr4sKLtwViXtRvCkRXssygEWVXLzqu HPJCvaEel6KX5sNdLHodN/bFMBlBDlZo6+KJXc+n6y5dh7RDKq1id9f2An6Cclp5lHEcvId1bAQn 71jQdr5zLRoCMhWs+QuEXkHlhzD5P3Pi8nXufJbpLGIYC7goLRjYi6V5ZD9HOMX5kLAVXO/Kj8uB 8z/AJE9CXGXHB9qcHVTa8lS9C9rbJPNs5uQq5Z5dXIv+9C8jPTQPpseZq4/vAxI+RdDGafhiLTeV njSkJ01fWCKaah18+0K371Dik6RcGK9pEZ/N3IbzKdVAp6C6f53r/+WfNH7HPh9ucw4zw+Z/hrZs /6Z/+zdbQaJCOHQ2BcgPDdhzI9dz6jcSUjVbTBIUgkFz1hY25ZNFfHVBTwVXmDVtB3hv47Z0DkiA vddyKBhClYU91icRzzU8qpVxKyde+1d1LcJvjdAU3NY6MjiDfPU5RIVf0iE4z6ZDSVhd9qeEF1Vh +0KD2lcVZAd+V9h2+1RPdicvraJF3gdR3aV5JpgCg0GBZBgJSCNBaEgQRKZFbBgRQgiHtrR7c2iH d0iHeKiHe8iHfeiHfwiIgSiIg0iIhWiIh4iIiaiIi8iIjeiIjwiJZkADcpgFlBiJl4iJMHGGWvcP m7gKeTZNkncR0v82GkSgQ0LTbZ9HDaTIYhjgiaCEWTpjTTlDGaLhYkdmeLwHZW0mZDboc5CwOaKG H99xaKHThXfXGqTGXqqBWNgHUVS4hbkQVOfHjAj1d4aVfZJGULxlNR5yCsoodvOFbdTYNHXRVM8i LBzlQtpWLajGUbbAJ64WadXXUiaVUcC2a0q3ahfXjqgWOIrDc1FIAl6YgxyYVUtSW+SmgivncpaV YDFHbAh3gzXnGGCXW7cjgPL3dQK5eBLYGQcJPppjcS7Yfzj3VHo3WBA5VKtlVWeFjeIzkfWWkCy4 MQ0JkxqnOXDlUyM4giNpKnM1cQmHPX9nD0JXalvSk+nGcHKlk0P/45E3yZCtpXkwGE4HeYpVqZIX +Td542xO5Qo9mC22JpUcWYbmGIEm6VFrWG3oYTsbeYPJkAbT+H9+5VVcGUTUN4AklSiGgyScWJbU IWvMsmrl8R3ouEJcxR8KWFevZnWs85HQdY+bBXcpaFxYaZGUiVFp1pIIoJn89YZXA5LuhVyy5IxZ yBpph25hOJqI5Xfo52irqWmmKZrjBY1HZHbzk5qmJjFW4Ims2GGTdE2s1wnJpHujh3qo+JuNp2bh hHjKCWjOF2NjwHli9mQMlk7BpEaQYIl2uJ3FSQ6HRJybtxGXyUvNmXuqiIvHFxiqV3gRYSuJoXjM h0vUpWXQuV5v/4QTfRGXNMkQFkiLKXdgrTSLyUmWoDiErpSf8jlndWifH/ZRv4eczvmLENGA8JON yiJqLkWOHngasHcKcsElsvahz7hP07hvWkiOKWp+UkNpoTY3FuoPvgg4WHedxRKYKLQgEGpc/PaE IAiFRxddDwVe7DaZChFuRmlC6BKTjRWC7yZxWkk6L3if4dYQR9qVDqSkMVdA/fdtYJV15ziRJASb 9+eSBXGkTWmA/JGlAEeUFdJxW5GR/AeCGzhXdeqTAgc9rIkP78mBhbYsiDaVWzqXsnUj2XaXWIls 7PaKemClt7U+gBqFN4SWJDmpOImdZQql8SWh42A7HGcfUEiD/P9DpAzYdD5EqvWGp7eWVUnnf5K6 p18qHc24jITxpiiJm/QSZbOpq2SkeLzKgGDIF2WzomBnfplGWxXjSwmaTcLJoJmIZYvqrGBQNtFK rdVqrTXRnddqENqqMNzqMN4KruEqruNKruVqrueKrumqruvKru3qrofYSvtpMOKarR0BffX5Bsna EvX6ri2mT7loNAkFeHHWiqaklhURrEnJAFz0n2PoDcagWml0sP5VBm0li8h3BOxYoI7Kn0EAraWI sQUWsg9roFvnsLPUsVQgDuKIonE3PxxKjB3aafCUjaWpjf1BRVRos1oIOv4Blq35fgrlokzUaODn Jd71sQtaU6//9qng4Z+RyWwzCqRFN1MaO7VS21sauW6UQ6fux1YXdaNam7Ke6W8VZlbEwW0GQHBR qmyD2n5EKqaG2mxRa5Syd7YLaYqD+Wd3C28phYMK53AepxhepHfs6Koh2KUYlLiKireYp7e32kR8 G1hpu21h6bY4mqYOZHJzC7j/JqYctHDRo5MP1wN7Z4xwJrkUKZYZpJg2yZBoG6YeNI3EuLpsS6gP YoME5psTekIhRXGM27S1q6UJ12+ZW7nBVX54G5EoqJWBKgSm6zj0ebV6SbnxB3NMi0JWC5A0d39t VZnfa72nanMBmVnPG7mACYbvpam6SZO+ujuLZm74wjXhkV9J/yi/RxmN5qV2XAiaWpW+kEu6ZWB6 LsCvuwh89+kSxaSez9lm5zlm29mWX4GXg2F8h0cHBfwxDhycRvOAA7sEGBydnkGJILx6DZplJOyd GlZkgYeeltfAC0ygHGB7Jsxm4rSp2zozekq2hHScn5mKIJuvCDy2IotlS3ayR6y0JcvBCOigWgBm ISuvSYydliBIsPecE+uXuVeQvOuKQpy0GctNDMOeUlwDPyvEM/ZNsqcgUVyeXDay27kdPwILfDE2 A8BdjlOMrvmZj2Y4t0lPGckcOAtF5EYl1hiNbXpASvSYQ0uC+7SzKVq6d/WmJ4i1hgVcGDXHB5eq 7QEhUEOEnP+Ff3BBvnIiOfcxyhjqj3BcP6fys6ccnwapkIvDisSDuIM7ZR/5Wn46pYD5VWDZmGcZ yUaYl6lqXEUZKFyRsEt5pxzYll60gfPoOQ92brL8q+EDbY2axT/ckkgqzGmyV1lbfoUMgU/JWq46 mdVLvs0ElNKFd5QcH2jqA1hUkthIvNOzmdJHirXcFUejpYLLPtJmDmrcz+YLu5hKa8oby6jaUWaC jrC8gn1pawBoc8+cmyXIV6KaBNPlTPDIcj8EuhDEjU0rt5gb0kV0qfq1XLMm0OT7patiw1R6ldMy ZOQnXJspmvgljd83ZVIEaTdbkLE4pLUrjARlXqIcfjfLvmz/t4X+68H70axEobLLykqel7ftOUiE xsa69NQWJng8nC83zAMk1rslXMGtCHvUqcKQ9wL2M8YTs8IANokU1sLumhjx2q+AxJzRkczfeNeh 1Uj8GZul19cMTMZht06apIvv6o3kZ8puGNj3pox7TaIBjK7B6o+3NjtHnaigurQ6Mth2dWUTqnw2 fbuDTc5biXxm1m5MDatDjK6dzD0GLXcCRJTKbJBuqK6VRRcxPdt3N39O6trhmnNWG0wyCtFbq1sb C66Se1wP+cm4pNGqSr3kOa6TfKtQA3jaIseqfQe26tPpls2DLdZ5DbCmzZvmnQfUjd7rzd7tLWPu Dd/xLd/z/03f9W3f943f+a3f+83f/e3f/w3g5IrC5tnDKBvghjjgTMDWjwfWf117qpDgLBHhO7y6 5a2DpwsFE65NZUKBX1wzfHnGy3nSK4CX29RjjLTFWg1xTeB0gsQz5L3i08R0IEaxMV4Ot6WsXTzi orjEACrTLlteRluiXmpG8KvHssmy57B2prbdfaerSFl3RMuaHPq/gXxuj7yiR03ZpzZ0pNzcPujF RCePljq9PETMf8OEpPx0kIncpM3mxBIcQUrJHi68vzsnLs17y/PYtvu43bzasYuQVyqlOy6m01bo V4XEJL6PlbpTDVK4SCUhqgWS2FvMDLdRzPvM3nfoqhteDv8SLZuL6UrpKU7tlbzmJK+cPQnN6GBE psWLqoOjsMH76sOc1Avoktt8pZJJNPi7pEy6zMcbuJL50b9N7MhgOo/CxfD3pKvs0OX0g4nO47w+ 0L036Kcdn3DKvYDevLSO68Ac6McKzN3egrqu4vlXqqO6O2IOt5t82TOq0pw1a11+dJvuyqbaUx5d Q+ZsxD5M1P+r1HXshXQn5EWYUcm4oQx1XsWafl9T0zTN7eHSv1Wobs+O1HGXJFpgnVRdR52o8ULw F6XBrzNMw89pxQLT8a5VwxbOBLidPBru8c43wCUMyXnYxDJP2C4Mwz/2wjtPeJWIrwWrPuCZnkRw i1ad2DH/HMMySOeueBzhzWEpHO0RWsQbYy7dqRtRbmlYP6ugjMUh/tztmYFcDOMizrHNV+FHvzPw M1MR3e5skVsSBBVhvhhZbcPtI2Rn/2EQJnd3z4JLz8FqOs9Zyc3yPnoP9ZISO07AueOZbWUzXtiJ XnmFzkENbbuTI9nTC+T8iFJwc/lYrqdUjqJIZMypAY4Vr+UqCmrcR1jizKJHUpQ6/J+xiQ4NvZLA IxmD/6OZQOkWzVCpvNmLflyXnA09yzlvDpB8qriWw6pL2/VdfPUF7boOnahFSqtPmuJ7kpWd5b2f s+ew0br0aZWBT1qjbiVqxdssM09+bu3cPo8A7bvTH5Wi/56Xi7vq9E634v901jaFim7oBADM8lSR 3TUTE323SpaxXXPbLA8azNPjVFLsQvZATxB7UZWD4TALaG1U+/GIRWME0vpolEDlrjmkpIa0HZVZ /WCjP+gyp/CBrcSvWZt0CXnTJztolM+ZaicbV15n4VmsromrCpDuqosQz66LjGFs620v74XvkS8O wJFOU88Nx8GnkwPUT2KM6xLs1GDUE0lsktKVsrUntkEWZEcgUxaUKs5wZfEQ06tPI0Bgc3ni5mHm 2SQR+lY6wVdAEDW0jbpiZsp6NZrGMRw6sxphKrtaPRUaSiZ63cyZLADBFH3J3Dqd0T0yqJYIYlYM z0Etr//mAFT4EGJEiRMpVrQYwuFFjXMMFrqY8drGkHRAfrRYEqFJkStZbuzYCBbMljM3oByZEqMm kDtP0pRjcwxQn0OJFjVa0abGpEdr8ljKFGpUqVOpVrV6FWtWrVu5dvX6FWxYsWPJljV7Fm1atWvZ tnX7Fm5cuXPp1rV7F29evXv59vX7F3BgwYMJFzZ8GHFixYsZN3b8GHJkyZMpV7Z8GXNmzXCfbt5a srNnnV5DH3yasbTRpat9pmbmmgjsmQNkM3Mm8GdklLe9Nc358NdgfzKseTB3kSBDTRFQ1t4k1KPv g8mXvVQe/OZv6ePWnpkFkXoRkNbRkndqaVk68xcyscr/vdc7yfd51r8Wrzy7Uu4Pm7cRUjoFnkRJ aKP2tsPpKBZwO0ecbhqcZ55mHowBuwVwu+CefRqMohNfqAkPnt5EuAdCEkXkzZsLbzDOwhRr4EUI gQARkSgSuMFlISnQI6WZI775LgYec0yljkgYEQbISwi68Q4h4emmyO+UjBKI+jQ64xMciwjGE0i2 lKTCMB7IKAlFApGEStvos+XIgbzE4TgM8kETyYDSGLIoLOv0sYZt3vTvzpjEVEAZQOv5QMMP6TRm uQjdBDPH5MxsUx8qP4lJy0qalAoK9y51dBEtGbxNDhzd+09TOue0UEdLv/yGH2IGUYdUhkYgzg5T AHUV/w1GN9VjKj2HDNPXVgXd9dJI91PkVAwzyNQNbRBUts8Ye5X1WEo5bFMCboAdlNNQFyW2IGt3 vTY+RMYtF9pu+cx2CE/NhfdRA9Pd1qBDA1U3KmHLRWZZJx8FF9lh7DT23IFjgPHd5HT9cdYd+5l0 SohHZLPUbWnhNk9xpbiQnmNoXXRPav2gUWRY9cXzY5RV/hfMBVN8UGZpggP5pRRUBIdl0dSykrAA DRaOKee0AnqwnGXy2bBKK0v2Wqbtk5rqqq2+OiqGWzIaLK4b8zouHJHeQBlewMYabYvEVnvotN1m ilzw3p67IlI/PJFnL0BuEQkTZ5B3Z5vpRjvabeLsEf/h/YKUmIR9nNxwcKZ1TqScPaVt+EwjOY48 s8nZ5BJRQHmJcFWE2j2Yc88OtwTXQCd+d03X+d08dcuYiz3btV+FVPY/aa+dMs/XrZZkhYs9PtWe gQ/eXZHD6XL3jVEHXZyxly+sVnpuX5G+Bld/+ZySQ9TX6eupPruopKw3P7CkWJuJa2/Zn187hNBv FHL6LevvKAHT0/9qjnDfaBrCEv8BkH33Q+ACGdhABz4QghGU4AQpWEELXhCDGdTgBjnYQQ9+EIQh FOEISVhCE54QhSlU4QpZ2EIXvvAw64OhYIgTEefIcIaAuYQCYZfDp7WNP+cBkg8f84UMSWhljlpH 9fLSRqH8ERExUGMOkywGjG2YCYdQlIuf2BOf5M1Oi4yp4ec4FCFJKS+M7UscrigWuzMiMYtpfAsX c7cvygEkjnJkC+god7A3AlGPfRFexRD3pID4I2KBxB6yapbEvKUgG4KDoyITYzTyhIaHlNSL/DQJ QIFkspOhFOUoSUkRUJZyMqdE5WZUuUrItNKVsZTlLGlZS1veEpe51OUuedlLX/4SmMEU5jCJWUxj HhOZyVTmMpnZTGc+E5rRlOY0qVlNa14Tm9nU5ja52U1vfhOc4RQnLQsAADs= ------------A48356845382213-- From mip6-bounces@ietf.org Mon Feb 28 02:00:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA20045 for ; Mon, 28 Feb 2005 02:00:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5euG-0007TK-K8 for mip6-web-archive@ietf.org; Mon, 28 Feb 2005 02:01:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5epq-0004X1-EW; Mon, 28 Feb 2005 01:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5epZ-0004Ss-Dw for mip6@megatron.ietf.org; Mon, 28 Feb 2005 01:56:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19093 for ; Mon, 28 Feb 2005 01:56:36 -0500 (EST) From: john.loughney@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5eqF-0007OH-CD for mip6@ietf.org; Mon, 28 Feb 2005 01:57:20 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1S6uYA10350; Mon, 28 Feb 2005 08:56:34 +0200 (EET) X-Scanned: Mon, 28 Feb 2005 09:09:09 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1S79980000704; Mon, 28 Feb 2005 09:09:09 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00dM9eWG; Mon, 28 Feb 2005 09:09:08 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1S6tKM26943; Mon, 28 Feb 2005 08:55:21 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Feb 2005 08:54:43 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Feb 2005 08:54:43 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt Date: Mon, 28 Feb 2005 08:54:46 +0200 Message-ID: Thread-Topic: [Mip6] Security Section Commentsondraft-ietf-mip6-bootstrap-ps-01.txt thread-index: AcUanGJhMCQBRbwMQDmO/QgbfuhLUwAY4OagABIqIQAAhlynEA== To: X-OriginalArrivalTime: 28 Feb 2005 06:54:43.0424 (UTC) FILETIME=[61C52E00:01C51D62] X-Spam-Score: 0.3 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Content-Transfer-Encoding: quoted-printable Cc: mip6@ietf.org, kempf@docomolabs-usa.com X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Content-Transfer-Encoding: quoted-printable Hi Gerardo, It seems that I forgot about my original text, and I didn't really rewrite much! Anyhow, what I meant to say was that this text should not be based (or refer to) any specific scenario - by supporting cryptographically seperate keys, deployments can get a benefit, which is that MNs don't need to re-authenticate the mobility service if the MN changes access network. Its another story if deployments want this feature or not, but that, as said, is another story. John > -----Original Message----- > From: ext Gerardo Giaretta [mailto:Gerardo.Giaretta@TILAB.COM] > Sent: 25 February, 2005 16:49 > To: Loughney John (Nokia-NRC/Helsinki) > Cc: mip6@ietf.org; kempf@docomolabs-usa.com > Subject: RE: [Mip6] Security Section > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt >=20 >=20 > John, >=20 > just to understand correctly what text you'd like to replace, are you > suggesting to change the text to: >=20 > " > In addition to these attacks, there are other considerations that are > important in achieving a good security design. As mobility and network > access authentication are seperate services, keys for these services > need to be cryptographically seperate, seperately named and have > seperate lifetimes. This allows the mobile node to change access > networks without performing a new mobility service authorization. > Finally, basic cryptographic processes must provide for multiple > algorithms in order to accommodate the widely varying=20 > deployment needs. > " >=20 > --Gerardo >=20 >=20 > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20 > > Sent: Friday, February 25, 2005 7:09 AM > > To: kempf@docomolabs-usa.com; Gerardo.Giaretta@TILAB.COM > > Cc: mip6@ietf.org > > Subject: RE: [Mip6] Security Section=20 > > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt > >=20 > >=20 > > James & Gerardo, > >=20 > > I get Gerardo's point, but the text starts to get unwieldy. > > Howabout something simple like: > >=20 > > It allows the mobile node to change access networks without > > performing a new mobility service authorization. > >=20 > > I would like not to get bogged down in deployment models, etc. > > but just discuss what the benefit is for seperating the keys. > > Maybe its best to stick to higher level issues; service providers > > will deploy as they see fit, but the draft should talk about > > the more egeneral properties and what it allows for. > >=20 > > John > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: ext James Kempf [mailto:kempf@docomolabs-usa.com] > > > Sent: 24 February, 2005 20:13 > > > To: Gerardo Giaretta; Loughney John (Nokia-NRC/Helsinki) > > > Cc: mip6@ietf.org > > > Subject: Re: [Mip6] Security Section > > > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt > > >=20 > > >=20 > > > Gerardo, > > >=20 > > > How about if we change the sentence to: > > >=20 > > > "In addition, for scenerios where the access service=20 > > > authorizer and mobility > > > service provider are different, maintaining separate keys=20 > > > allows the host to > > > move from one access network to another without undergoing a=20 > > > new round of > > > mobility service authorization." > > >=20 > > > jak > > >=20 > > >=20 > > > ----- Original Message -----=20 > > > From: "Gerardo Giaretta" > > > To: ; > > > Cc: > > > Sent: Thursday, February 24, 2005 5:18 AM > > > Subject: RE: [Mip6] Security Section > > > Commentsondraft-ietf-mip6-bootstrap-ps-01.txt > > >=20 > > >=20 > > > Hi John and James, > > >=20 > > > please see a comment below. > > >=20 > > > > > > > > In addition to these attackes, there are other > > > > considerstions that are important > > > > in achieving a good security design. As mobility and network > > > > access authentication > > > > are seperate services, keys for these services need to be > > > > cryptographically > > > > seperate, seperately named and have seperate lifetimes. This > > > > is needed because > > > > if one service is compromised, the other service is not. > > > > This is necessary > > > > so that a mobile host can move from one serving (or roaming) > > > > network access > > > > provider to another without needing to change its mobility > > > > access provider. > > > > Finally, basic cryptographic processes must provide for > > > > multiple algorithms in order > > > > to accommodate the widely varying deployment needs. > > > > > > >=20 > > > Since it's not clear to me which scenario you are referring=20 > > to, could > > > you please clarify on this sentence of your proposed text: > > >=20 > > > " > > > This is necessary so that a mobile host can move from one=20 > > serving (or > > > roaming) network access provider to another without needing=20 > > to change > > > its mobility access provider. > > > " > > >=20 > > > Thanks, > > > --Gerardo > > >=20 > > >=20 > > > > John > > > > > > > > _______________________________________________ > > > > Mip6 mailing list > > > > Mip6@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/mip6 > > > > > > >=20 > > >=20 > > > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > > > Italia S.p.A. > > >=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=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > CONFIDENTIALITY NOTICE > > > This message and its attachments are addressed solely to=20 > the persons > > > above and may contain confidential information. If you=20 > have received > > > the message in error, be informed that any use of the=20 > content hereof > > > is prohibited. Please return it immediately to the sender=20 > and delete > > > the message. Should you have any questions, please send=20 > an e_mail to > > > MailAdmin@tilab.com. Thank you > > >=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 > > >=20 > > >=20 > > >=20 > >=20 >=20 >=20 > Gruppo Telecom Italia - Direzione e coordinamento di Telecom=20 > Italia S.p.A. >=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 > CONFIDENTIALITY NOTICE > This message and its attachments are addressed solely to the persons > above and may contain confidential information. If you have received > the message in error, be informed that any use of the content hereof > is prohibited. Please return it immediately to the sender and delete > the message. Should you have any questions, please send an e_mail to > MailAdmin@tilab.com. Thank you > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 28 08:55:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20961 for ; Mon, 28 Feb 2005 08:55:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5lO5-0007YJ-Ei for mip6-web-archive@ietf.org; Mon, 28 Feb 2005 08:56:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5lIw-0006rA-S7; Mon, 28 Feb 2005 08:51:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5Btf-0000nm-MQ for mip6@megatron.ietf.org; Sat, 26 Feb 2005 19:02:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10356 for ; Sat, 26 Feb 2005 19:02:52 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5Bu5-000566-H1 for mip6@ietf.org; Sat, 26 Feb 2005 19:03:22 -0500 Received: by wproxy.gmail.com with SMTP id 71so700830wri for ; Sat, 26 Feb 2005 16:02:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ToRwyshuDhOLmgqjz9rego1OzxcJioaTHCUlEpZ4rKaVYQqZ4nKvHRWph0KugM+Vuv0sTAyxec99S8QYFtTPn3UYUq4MSWyOqn39XMxivLdzxTlCG/CMysfNRDLRovI0USwCWavXRE5MWHUweZERPQib7t9sg0+vjfRfpPD4rqE= Received: by 10.54.37.44 with SMTP id k44mr172113wrk; Sat, 26 Feb 2005 16:02:45 -0800 (PST) Received: by 10.54.10.47 with HTTP; Sat, 26 Feb 2005 16:02:45 -0800 (PST) Message-ID: <88b9e992050226160222fd03ff@mail.gmail.com> Date: Sat, 26 Feb 2005 16:02:45 -0800 From: B Krishnamachari To: mip6@ietf.org In-Reply-To: <88b9e992050226160033ca2fff@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <88b9e992041122212238fbd303@mail.gmail.com> <88b9e9920411222122255f3cd@mail.gmail.com> <88b9e992050113123277082f92@mail.gmail.com> <88b9e99205020309433e72fb86@mail.gmail.com> <88b9e992050226160033ca2fff@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 28 Feb 2005 08:51:18 -0500 Subject: [Mip6] IEEE COMMUNICATIONS SOCIETY Sponsors BROADNETS-2005, Deadline Extended Further X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: B Krishnamachari List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit We are very proud to announce that IEEE COMMUNICATIONS SOCIETY have decided to cosponsor BROADNETS-2005. All papers in three symposia, Wireless Networking Symposium, Optical Networking Symposium, and Services/Applications Symposium will be made available on IEEE explorer. To allow authors to more use this new opportunity, we are extending the deadline for submission to APRIL 1, 2005. However you must register your paper by MARCH 24, 2005 and upload your paper by APRIL 1, 2005 midnight PST. For more details see http://www.broadnets.org _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 28 15:56:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06813 for ; Mon, 28 Feb 2005 15:56:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rxJ-0000Uv-9j for mip6-web-archive@ietf.org; Mon, 28 Feb 2005 15:57:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ru6-0000WY-UI; Mon, 28 Feb 2005 15:54:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ru5-0000WL-MV for mip6@megatron.ietf.org; Mon, 28 Feb 2005 15:54:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06538 for ; Mon, 28 Feb 2005 15:54:07 -0500 (EST) From: Franck.Le@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rus-0000RH-K5 for mip6@ietf.org; Mon, 28 Feb 2005 15:55:00 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1SKs4c17284; Mon, 28 Feb 2005 22:54:04 +0200 (EET) X-Scanned: Mon, 28 Feb 2005 22:53:50 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1SKrocj017390; Mon, 28 Feb 2005 22:53:50 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00dlG80A; Mon, 28 Feb 2005 22:53:48 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1SKrkU14221; Mon, 28 Feb 2005 22:53:46 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Feb 2005 14:53:10 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2005 14:53:11 -0600 Message-ID: <654E856A5136DF4382BE4B57B5E93A413B3101@daebe101.NOE.Nokia.com> Thread-Topic: [Mip6] IEEE COMMUNICATIONS SOCIETY Sponsors BROADNETS-2005, Deadline Extended Further thread-index: AcUdpJb9Wjz6xXlcSX28xQsKHUGZywAMpI7w To: , , , , X-OriginalArrivalTime: 28 Feb 2005 20:53:10.0793 (UTC) FILETIME=[834C7F90:01C51DD7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Questions on draft-qiu-mip6-mobile-firewall-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Hello, I read the draft-qiu-mip6-mobile-firewall-00.txt, and would have few = questions. I hope that the authors can clarify me on the following. The proposed approach is interesting and even though not always = applicable, it could be a solution when the visited network deploy MAPs. = Section 5 analyzes how the proposed solution solves many of the common = issues that firewall can present to the MIPv6 protocol. However it does = not seem to describe the procedures when the CN is also a MN. Let's call = MN1 the MN in the network where MAPs are deployed, and MN2, its CN. - Does the MAP allow RRT messages (e.g. HoTI, CoTI) from MN2 to reach = MN1? If yes, malicious may use that to flood MN1. MN1 may be in a = network where the access link is a scarce and expensive resource (e.g. = cellular network) and has to pay for its utilization. Fowarding these = RRT messages may cause the MN1 to pay for undesired packets sent by = malicious nodes generating RRT packets. - How does the MAP update the entries when the MN2 uses Route = Optimization? Thank you. Franck _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6 From mip6-bounces@ietf.org Mon Feb 28 15:56:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06833 for ; Mon, 28 Feb 2005 15:56:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rxN-0000V9-MM for mip6-web-archive@ietf.org; Mon, 28 Feb 2005 15:57:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ru6-0000WT-Gi; Mon, 28 Feb 2005 15:54:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5ru4-0000Vq-Bm for mip6@megatron.ietf.org; Mon, 28 Feb 2005 15:54:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06523 for ; Mon, 28 Feb 2005 15:54:06 -0500 (EST) From: Franck.Le@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rus-0000RI-Oh for mip6@ietf.org; Mon, 28 Feb 2005 15:54:59 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1SKs4Z17367; Mon, 28 Feb 2005 22:54:04 +0200 (EET) X-Scanned: Mon, 28 Feb 2005 23:07:34 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1SL7Y8P011091; Mon, 28 Feb 2005 23:07:34 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00SLCNwf; Mon, 28 Feb 2005 23:07:33 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1SKrkM16663; Mon, 28 Feb 2005 22:53:46 +0200 (EET) Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Feb 2005 14:53:34 -0600 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2005 14:53:11 -0600 Message-ID: <654E856A5136DF4382BE4B57B5E93A413B3101@daebe101.NOE.Nokia.com> Thread-Topic: [Mip6] IEEE COMMUNICATIONS SOCIETY Sponsors BROADNETS-2005, Deadline Extended Further thread-index: AcUdpJb9Wjz6xXlcSX28xQsKHUGZywAMpI7w To: , , , , X-OriginalArrivalTime: 28 Feb 2005 20:53:34.0525 (UTC) FILETIME=[9171B6D0:01C51DD7] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Subject: [Mip6] Questions on draft-qiu-mip6-mobile-firewall-00.txt X-BeenThere: mip6@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: mip6.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: mip6-bounces@ietf.org Errors-To: mip6-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Hello, I read the draft-qiu-mip6-mobile-firewall-00.txt, and would have few = questions. I hope that the authors can clarify me on the following. The proposed approach is interesting and even though not always = applicable, it could be a solution when the visited network deploy MAPs. = Section 5 analyzes how the proposed solution solves many of the common = issues that firewall can present to the MIPv6 protocol. However it does = not seem to describe the procedures when the CN is also a MN. Let's call = MN1 the MN in the network where MAPs are deployed, and MN2, its CN. - Does the MAP allow RRT messages (e.g. HoTI, CoTI) from MN2 to reach = MN1? If yes, malicious may use that to flood MN1. MN1 may be in a = network where the access link is a scarce and expensive resource (e.g. = cellular network) and has to pay for its utilization. Fowarding these = RRT messages may cause the MN1 to pay for undesired packets sent by = malicious nodes generating RRT packets. - How does the MAP update the entries when the MN2 uses Route = Optimization? Thank you. Franck _______________________________________________ Mip6 mailing list Mip6@ietf.org https://www1.ietf.org/mailman/listinfo/mip6