From mobike-bounces@machshav.com Wed Feb 01 03:32:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4DPF-0007Os-Q0 for mobike-archive@megatron.ietf.org; Wed, 01 Feb 2006 03:32:11 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21766 for ; Wed, 1 Feb 2006 03:30:16 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 74149FB290; Wed, 1 Feb 2006 03:31:49 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 7C3A2FB289 for ; Wed, 1 Feb 2006 03:31:47 -0500 (EST) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k118VjjQ023607; Wed, 1 Feb 2006 10:31:46 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 10:31:45 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Feb 2006 10:31:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 1 Feb 2006 10:31:44 +0200 Message-ID: In-Reply-To: <20060201005948.86785.qmail@web80611.mail.yahoo.com> Thread-Topic: [Mobike] does mobike support end-to-end use of tunnel mode? Thread-Index: AcYmytY5QD+SVFWCTqqZ8JWR+WrY0AAPDkCw From: To: , , X-OriginalArrivalTime: 01 Feb 2006 08:31:45.0254 (UTC) FILETIME=[EF797060:01C62709] Cc: mobike@machshav.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > This still does not describe the limitation. If i can > assume that the PAD can be configured appropriately, > then you can ensure what address a peer gets. So, > there seems to be a use case where this is limiting. > Can someone describe that ? In host-to-host IPsec use, either your addresses are static (so you don't have that big need for MOBIKE), or your PAD is not configured appropriately -- or you're doing something like BTNS. To take a concrete example: suppose my laptop wants to establish an IPsec SA with my local mail server. Assuming some kind of corporate PKI, the laptop could create an IKE_SA, authenticate the mail server, and authenticate itself as "pasi-dot-eronen-at- nokia-dot-com" (or "laptop-123456-at-nokia-dot-com"). But there's practically no way the mail server's PAD would contain child SA authorization data saying that "pasi-dot-.. is allowed to create IPsec SAs with traffic selectors matching address 192.0.2.123", since the address came from DHCP... So either creating the IPsec SA fails, or the PAD contains data saying "pasi-dot-... (and all other employees) are allowed to create SAs for practically any address" (or at least addresses they can spoof). The latter is not exactly very secure... but that's what some people are using anyway (sort of like BTNS). The "Experiences with Host-to-Host IPsec" paper by Tuomas Aura, Michael Roe, and Anish Mohammed (try Google for PDF) describes this and many other issues with host-to-host IPsec in detail. With typical "VPN gateway" use, the problem doesn't really exist. When the gateway allocates the client a new IP address using configuration payloads, it can at the same time update the PAD. None of this is really specific to MOBIKE as such, so I think we should not add text about this to the MOBIKE draft... Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Feb 01 09:59:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4JRv-0001zO-96 for mobike-archive@megatron.ietf.org; Wed, 01 Feb 2006 09:59:17 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05623 for ; Wed, 1 Feb 2006 09:57:24 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D802AFB297; Wed, 1 Feb 2006 09:58:54 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id D7FB6FB294 for ; Wed, 1 Feb 2006 09:58:52 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C47758990D; Wed, 1 Feb 2006 16:58:50 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 86D918990B; Wed, 1 Feb 2006 16:58:50 +0200 (EET) Message-ID: <43E0CCC3.6090106@piuha.net> Date: Wed, 01 Feb 2006 16:59:15 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: Erik.Nordmark@Sun.COM, mohanp@sbcglobal.net, mobike@machshav.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >In host-to-host IPsec use, either your addresses are static >(so you don't have that big need for MOBIKE), or your PAD is not >configured appropriately -- or you're doing something like BTNS. > >To take a concrete example: suppose my laptop wants to establish >an IPsec SA with my local mail server. Assuming some kind of >corporate PKI, the laptop could create an IKE_SA, authenticate the >mail server, and authenticate itself as "pasi-dot-eronen-at- >nokia-dot-com" (or "laptop-123456-at-nokia-dot-com"). > >But there's practically no way the mail server's PAD would contain >child SA authorization data saying that "pasi-dot-.. is allowed to >create IPsec SAs with traffic selectors matching address >192.0.2.123", since the address came from DHCP... > >So either creating the IPsec SA fails, or the PAD contains data >saying "pasi-dot-... (and all other employees) are allowed to create >SAs for practically any address" (or at least addresses they can >spoof). The latter is not exactly very secure... but that's what >some people are using anyway (sort of like BTNS). > >The "Experiences with Host-to-Host IPsec" paper by Tuomas Aura, >Michael Roe, and Anish Mohammed (try Google for PDF) describes >this and many other issues with host-to-host IPsec in detail. > > Right. Thanks for the reference, I hadn't seen that before. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Feb 01 10:02:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4JUd-0003eT-Pv for mobike-archive@megatron.ietf.org; Wed, 01 Feb 2006 10:02:00 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05857 for ; Wed, 1 Feb 2006 10:00:12 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EA9E8FB297; Wed, 1 Feb 2006 10:01:46 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2BDBEFB294 for ; Wed, 1 Feb 2006 10:01:45 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 26FDB8990D; Wed, 1 Feb 2006 17:01:44 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DFCE48990B; Wed, 1 Feb 2006 17:01:43 +0200 (EET) Message-ID: <43E0CD71.9060403@piuha.net> Date: Wed, 01 Feb 2006 17:02:09 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: X-Virus-Scanned: ClamAV using ClamSMTP Cc: Erik.Nordmark@Sun.COM, mobike@machshav.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit I do not have a strong opinion on where text should go. But personally I would like to see some note about the inner address allocation authorization issues (even if that note pushes the blame to IKEv2 where it belongs). --Jari Pasi.Eronen@nokia.com wrote: >Hmm.. I think this is more a limitation of MOBIKE (and IKEv2 >in general) rather than a security consideration of MOBIKE. > >How about adding this to Section 1.2 (Scope and Limitations)? > > IKEv2 relies on information in the Peer Authorization Database > (PAD) when determining if the peer is authorized to create an IPsec > SA with particular traffic selectors. MOBIKE does not change this > part of IKEv2. This may limit the applicability of MOBIKE in > host-to-host IPsec scenarios: although MOBIKE allows the peers to > update the tunnel header addresses, it does not modify the child SA > authorization data in the PAD. In other words, using some particular > tunnel header address does not imply that the peer is authorized > to create IPsec SAs with that address in the traffic selector. > >Best regards, >Pasi > > > >>-----Original Message----- >>From: mobike-bounces@machshav.com >>[mailto:mobike-bounces@machshav.com] On Behalf Of ext Jari Arkko >>Sent: 31 January, 2006 14:42 >>To: Erik Nordmark >>Cc: MOBIKE Mailing List >>Subject: Re: [Mobike] does mobike support end-to-end use of >>tunnel mode? >> >>Erik, >> >>Here are some text changes that may help clarify applicability >>and the issues relating to the allocation of inner addresses. First >>a new subsection to be added to the security considerations >>section: >> >> 5.x. Inner Address Ownership >> >> MOBIKE ensures that the IKEv2 peer is always the same >> entity regardless of its changing addresses. These addresses >> are in the IKEv2 messages as well as outer addresses in >> IPsec tunnel packets. >> >> However, MOBIKE relies entirely on IKEv2 in the use of inner >> addresses. Typically, the same inner addresses are employed >> throughout the lifetime of the IKEv2 security association, i.e., >> MOBIKE does not modify the inner addresses. Changing the >> inner address would in often result in a need to re-establish >> existing transport layer connections, as these are often >> bound to specific addresses. >> >> As with IKEv2, it is necessary to ensure that peers are authorized >> to use the inner addresses that they negotiate when creating >> child SAs. The Peer Authorization Database (PAD) specified in >> RFC 4301 [RFC4301] allows administrators to specify what >> inner addresses specific IKEv2 peers have. In addition, it >> is necessary to ensure that the dynamic allocation of addresses >> through configuration payloads does not allow peers to >> "hijack" addresses from other nodes. >> >>And in Section 1.2 (Limitations) change: >> >> This document focuses on the main scenario outlined above, and >> supports only tunnel mode IPsec SAs. >> >>=> >> >> This document focuses on the main scenario outlined above, and >> supports only tunnel mode IPsec SAs when at least one of the >> parties is a VPN gateway. >> >>--Jari >> >> >_______________________________________________ >Mobike mailing list >Mobike@machshav.com >https://www.machshav.com/mailman/listinfo.cgi/mobike > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Feb 01 13:16:05 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4MWF-0000WR-Ia for mobike-archive@megatron.ietf.org; Wed, 01 Feb 2006 13:16:05 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19910 for ; Wed, 1 Feb 2006 13:14:06 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1803DFB294; Wed, 1 Feb 2006 13:15:39 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from web80604.mail.yahoo.com (web80604.mail.yahoo.com [66.218.79.93]) by machshav.com (Postfix) with SMTP id 7263FFB293 for ; Wed, 1 Feb 2006 13:15:37 -0500 (EST) Received: (qmail 92870 invoked by uid 60001); 1 Feb 2006 18:15:36 -0000 Message-ID: <20060201181536.92868.qmail@web80604.mail.yahoo.com> Received: from [206.132.194.2] by web80604.mail.yahoo.com via HTTP; Wed, 01 Feb 2006 10:15:36 PST Date: Wed, 1 Feb 2006 10:15:36 -0800 (PST) From: Mohan Parthasarathy To: Pasi.Eronen@nokia.com, jari.arkko@piuha.net, Erik.Nordmark@Sun.COM In-Reply-To: MIME-Version: 1.0 Cc: mobike@machshav.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit --- Pasi.Eronen@nokia.com wrote: > Mohan Parthasarathy wrote: > > > This still does not describe the limitation. If i > can > > assume that the PAD can be configured > appropriately, > > then you can ensure what address a peer gets. So, > > there seems to be a use case where this is > limiting. > > Can someone describe that ? > > In host-to-host IPsec use, either your addresses are > static > (so you don't have that big need for MOBIKE), or > your PAD is not > configured appropriately -- or you're doing > something like BTNS. > > To take a concrete example: suppose my laptop wants > to establish > an IPsec SA with my local mail server. Assuming > some kind of > corporate PKI, the laptop could create an IKE_SA, > authenticate the > mail server, and authenticate itself as > "pasi-dot-eronen-at- > nokia-dot-com" (or > "laptop-123456-at-nokia-dot-com"). > > But there's practically no way the mail server's PAD > would contain > child SA authorization data saying that "pasi-dot-.. > is allowed to > create IPsec SAs with traffic selectors matching > address > 192.0.2.123", since the address came from DHCP... > Hmm..won't you be using a transport mode SA for this and MOBIKE is clearly out of scope here ? > So either creating the IPsec SA fails, or the PAD > contains data > saying "pasi-dot-... (and all other employees) are > allowed to create > SAs for practically any address" (or at least > addresses they can > spoof). The latter is not exactly very secure... > but that's what > some people are using anyway (sort of like BTNS). > > The "Experiences with Host-to-Host IPsec" paper by > Tuomas Aura, > Michael Roe, and Anish Mohammed (try Google for PDF) > describes > this and many other issues with host-to-host IPsec > in detail. > > With typical "VPN gateway" use, the problem doesn't > really exist. > When the gateway allocates the client a new IP > address using > configuration payloads, it can at the same time > update the PAD. > > None of this is really specific to MOBIKE as such, > so I think > we should not add text about this to the MOBIKE > draft... > Agreed. Now, we can even put the reference and say that host-to-host case is out of scope. -mohan > Best regards, > Pasi > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 02 08:02:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4e60-0003X6-1Z for mobike-archive@megatron.ietf.org; Thu, 02 Feb 2006 08:02:00 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00107 for ; Thu, 2 Feb 2006 08:00:13 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EE021FB294; Thu, 2 Feb 2006 08:01:44 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id AE425FB293 for ; Thu, 2 Feb 2006 08:01:42 -0500 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k12D1cG7022198; Thu, 2 Feb 2006 15:01:39 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 15:01:37 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Feb 2006 15:01:37 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 2 Feb 2006 15:01:37 +0200 Message-ID: In-Reply-To: <20060201181536.92868.qmail@web80604.mail.yahoo.com> Thread-Topic: [Mobike] does mobike support end-to-end use of tunnel mode? Thread-Index: AcYnW7J941Hi2WfgSD6d7h26Wx6qbwAmPo7g From: To: , , X-OriginalArrivalTime: 02 Feb 2006 13:01:37.0336 (UTC) FILETIME=[CD1ED380:01C627F8] Cc: mobike@machshav.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Mohan Parthasarathy wrote: > > But there's practically no way the mail server's PAD would contain > > child SA authorization data saying that "pasi-dot-.. is allowed > > to create IPsec SAs with traffic selectors matching address > > 192.0.2.123", since the address came from DHCP... > > Hmm..won't you be using a transport mode SA for this and MOBIKE > is clearly out of scope here ? You can use tunnel mode between two hosts if you want. > > None of this is really specific to MOBIKE as such, so I think > > we should not add text about this to the MOBIKE draft... > > Agreed. Now, we can even put the reference and say that > host-to-host case is out of scope. Well... if you have host-to-host tunnel mode IPsec working in a secure manner, MOBIKE could work as well. But this situation is pretty rare. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 02 14:38:33 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kHh-00074j-69 for mobike-archive@megatron.ietf.org; Thu, 02 Feb 2006 14:38:33 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02797 for ; Thu, 2 Feb 2006 14:36:39 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BE937FB298; Thu, 2 Feb 2006 14:38:11 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by machshav.com (Postfix) with ESMTP id 0500BFB297 for ; Thu, 2 Feb 2006 14:38:09 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.56.36]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k12Jc8Qj006882; Thu, 2 Feb 2006 12:38:08 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k12Jc7qF604481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Feb 2006 11:38:07 -0800 (PST) Message-ID: <43E25F87.7060704@sun.com> Date: Thu, 02 Feb 2006 11:37:43 -0800 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: Cc: mobike@machshav.com, mohanp@sbcglobal.net, jari.arkko@piuha.net Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > Well... if you have host-to-host tunnel mode IPsec working in a > secure manner, MOBIKE could work as well. But this situation > is pretty rare. Clarifying question: for this case are you assuming that the inner and outer IP addresses for the tunnel must be different? I think tunnel mode can be used (per the RFCs even if implementations might not handle it) where the inner and outer IP addresses are the same. If you apply MOBIKE to such a case, then you end up with an unsolved address ownership issues, because the existence of the IPsec SAs, which now use a different outer remote address, will prevent a different host which has "inherited" that outer address from establishing a SA with the same peer. This end-to-end tunnel case was in fact the one that made me concerned. A host is using some public-access network infrastructure. It gets allocated IP address B by a DHCP server. B contacts server A (www.example.com), and uses Mobike. As a result of this, A ends up with a (IKE and IPsec) SAs that make packets destined to IP address B be subject to the IPsec SA that was setup. Thus packets destined from A to B are placed on an ESP tunnel, with a destination of B. The host (B) later moves to a different network, where it is assigned IP address C. It uses Mobike to move the IKE and IPsec SAs from using B to using C. This (and here is were the document is silent) means that packets sent from A to B and placed in an ESP tunnel with a destination of C. (In any case, there isn't any text I could find that says that there is no residual IKE or IPsec SA or policy that refer to B.) What happens when another host appears on the initial public-access infrastructure and is assigned IP address B by the DHCP server? (This could be hours or days after the first host left.) When that host tries to contact www.example.com, things would fail due to the SADB and SPD entries that were created by the original host. --- The above isn't an issue for a IPsec SG that has static allocation/authorization of the inner IP addresses (having a fixed binding between the clients CERT and the inner IP address is clearly secure). Don't know if there are issues with IPsec SGs that do dynamic allocation of the inner IP address. Erik _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 02 14:51:43 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4kUZ-0004Ma-0r for mobike-archive@megatron.ietf.org; Thu, 02 Feb 2006 14:51:43 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03882 for ; Thu, 2 Feb 2006 14:49:57 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 33C6BFB298; Thu, 2 Feb 2006 14:51:33 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by machshav.com (Postfix) with ESMTP id B5A17FB297 for ; Thu, 2 Feb 2006 14:51:31 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.226.130]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id k12JpVQj018572; Thu, 2 Feb 2006 12:51:31 -0700 (MST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k12JpTwn610049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Feb 2006 11:51:30 -0800 (PST) Message-ID: <43E262A9.9010204@sun.com> Date: Thu, 02 Feb 2006 11:51:05 -0800 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Jari Arkko References: <20060127012043.10783.qmail@web80606.mail.yahoo.com> <43DF5B0F.8060905@piuha.net> In-Reply-To: <43DF5B0F.8060905@piuha.net> Cc: MOBIKE Mailing List Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Jari Arkko wrote: > Erik, > > Here are some text changes that may help clarify applicability > and the issues relating to the allocation of inner addresses. First > a new subsection to be added to the security considerations > section: Thanks for suggesting text. And sorry for not following up earlier (I thought I had done that last week, but I see I didn't finish my email to the MOBIKE list.) > 5.x. Inner Address Ownership > > MOBIKE ensures that the IKEv2 peer is always the same > entity regardless of its changing addresses. These addresses > are in the IKEv2 messages as well as outer addresses in > IPsec tunnel packets. > > However, MOBIKE relies entirely on IKEv2 in the use of inner > addresses. Typically, the same inner addresses are employed > throughout the lifetime of the IKEv2 security association, i.e., > MOBIKE does not modify the inner addresses. Changing the > inner address would in often result in a need to re-establish > existing transport layer connections, as these are often > bound to specific addresses. > > As with IKEv2, it is necessary to ensure that peers are authorized > to use the inner addresses that they negotiate when creating > child SAs. The Peer Authorization Database (PAD) specified in > RFC 4301 [RFC4301] allows administrators to specify what > inner addresses specific IKEv2 peers have. In addition, it > is necessary to ensure that the dynamic allocation of addresses > through configuration payloads does not allow peers to > "hijack" addresses from other nodes. That's definitely a start. But it doesn't cover the time shifting aspect which MOBIKE introduces. With just IKEv2 the SG can derive some security from the fact that the host is still reachable at the same address it used when it initially established the IKE and IPsec SAs. But MOBIKE allows the host to change that. As a result, some SG practices which might be safe today or with some IKE extensions (e.g., BTNS), might not be as safe when combined with MOBIKE. And MOBIKE, as applied to VPN cases where the SG has good enough(tm) authorization can be safe, but other IKE extensions might make it unsafe. I think covering this "might not be safely extended" aspect is the warning I'd like to see in the security considerations section. > And in Section 1.2 (Limitations) change: > > This document focuses on the main scenario outlined above, and > supports only tunnel mode IPsec SAs. > > => > > This document focuses on the main scenario outlined above, and > supports only tunnel mode IPsec SAs when at least one of the > parties is a VPN gateway. > That's good. But I think the paragraph below which says The base version of the MOBIKE protocol does not cover all potential future use scenarios, such as transport mode, application to securing SCTP, or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. Please consult the MOBIKE design document [Design] for further information and rationale behind these limitations. is misleading, since it might make folks think it is trivial to extend it to transport mode, when in fact any such extensions need to carefully look at address ownership issues. (And I can't see a tractable solution other than HBA or CGA for this.) So I'd suggest replacing it with The MOBIKE protocol as specified handles the case where at least one end is a VPN gateway that employs proper authorization of the inner tunnel address. As such it can avoid the address ownership issues. Extending MOBIKE or applying it other cases (end-to-end tunnel mode, transport mode, BTNS) would need to carefully look at the address ownership issue and any resulting time-shifting attacks. Please consult the MOBIKE design document [Design] for further information and rationale behind these limitations. Erik _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 02 15:16:48 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4ksq-0007OJ-R8 for mobike-archive@megatron.ietf.org; Thu, 02 Feb 2006 15:16:48 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05474 for ; Thu, 2 Feb 2006 15:15:05 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8020FFB298; Thu, 2 Feb 2006 15:16:41 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id 77905FB297 for ; Thu, 2 Feb 2006 15:16:39 -0500 (EST) Received: from [128.9.168.55] (upn.isi.edu [128.9.168.55]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id k12Jk0626591; Thu, 2 Feb 2006 11:46:00 -0800 (PST) Message-ID: <43E2617B.3040903@isi.edu> Date: Thu, 02 Feb 2006 11:46:03 -0800 From: Joe Touch User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark References: <43E25F87.7060704@sun.com> In-Reply-To: <43E25F87.7060704@sun.com> X-Enigmail-Version: 0.91.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: mobike@machshav.com, jari.arkko@piuha.net, mohanp@sbcglobal.net, Pasi.Eronen@nokia.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Erik Nordmark wrote: > Pasi.Eronen@nokia.com wrote: > > >>Well... if you have host-to-host tunnel mode IPsec working in a >>secure manner, MOBIKE could work as well. But this situation >>is pretty rare. > > > Clarifying question: for this case are you assuming that the inner and > outer IP addresses for the tunnel must be different? > > I think tunnel mode can be used (per the RFCs even if implementations > might not handle it) where the inner and outer IP addresses are the same. In that case, it doesn't seem like the inner packet shouldn't be accepted. The outer packet would be accepted because it is matches an IPsec rule and is properly signed. The inner packet, after decapsulation, should match the same rule, at which point it should look like an unsigned packet, which should be discarded. Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD4mF7E5f5cImnZrsRAjgDAJkBcovuSxDjxHHop2MXF9N7q5v5kACgzgdV nJZ7Z42+RsdV4ThwOYvhKTU= =GIft -----END PGP SIGNATURE----- _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Feb 02 16:55:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4mPu-0003iO-WC for mobike-archive@megatron.ietf.org; Thu, 02 Feb 2006 16:55:15 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17826 for ; Thu, 2 Feb 2006 16:53:16 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C3677FB298; Thu, 2 Feb 2006 16:54:49 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by machshav.com (Postfix) with ESMTP id 05D9DFB297 for ; Thu, 2 Feb 2006 16:54:47 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.58.166]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id k12LsidK008620; Thu, 2 Feb 2006 13:54:44 -0800 (PST) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k12LshgI648405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Feb 2006 13:54:44 -0800 (PST) Message-ID: <43E27F8B.7060205@sun.com> Date: Thu, 02 Feb 2006 13:54:19 -0800 From: Erik Nordmark User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: Cc: mobike@machshav.com, mohanp@sbcglobal.net, jari.arkko@piuha.net Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > In host-to-host IPsec use, either your addresses are static > (so you don't have that big need for MOBIKE), or your PAD is not > configured appropriately -- or you're doing something like BTNS. > > To take a concrete example: suppose my laptop wants to establish > an IPsec SA with my local mail server. Assuming some kind of > corporate PKI, the laptop could create an IKE_SA, authenticate the > mail server, and authenticate itself as "pasi-dot-eronen-at- > nokia-dot-com" (or "laptop-123456-at-nokia-dot-com"). > > But there's practically no way the mail server's PAD would contain > child SA authorization data saying that "pasi-dot-.. is allowed to > create IPsec SAs with traffic selectors matching address > 192.0.2.123", since the address came from DHCP... > > So either creating the IPsec SA fails, or the PAD contains data > saying "pasi-dot-... (and all other employees) are allowed to create > SAs for practically any address" (or at least addresses they can > spoof). The latter is not exactly very secure... but that's what > some people are using anyway (sort of like BTNS). Yes, and that is clearly a problem for IKEv2 in general. > The "Experiences with Host-to-Host IPsec" paper by Tuomas Aura, > Michael Roe, and Anish Mohammed (try Google for PDF) describes > this and many other issues with host-to-host IPsec in detail. > > With typical "VPN gateway" use, the problem doesn't really exist. > When the gateway allocates the client a new IP address using > configuration payloads, it can at the same time update the PAD. The configuration payload allows the client to suggest an IP address as well as just getting one assigned by the SG. I don't know if that introduces any new issues. But in any case, that isn't a problem introduced by the MOBIKE WG. But is there or is there not an issue introduced by the combination of dynamic SG assignment of inner addresses, and MOBIKE changing the outer addresses? Here is an example: Alice visits the IETF, get X as the IP address, connects to sg.example.net. The SG allocates A as the inner IP address for Alice. Alice moves to another network. Gets Y as the IP address and uses MOBIKE to move the SAs from X to Y. An hour later Bob, who also works at example.net, walks into the IETF and is allocated X as its IP address. Bob connects to sg.example.net and is allocated B as the inner address. I assume there is no conflict between Alice's and Bob's SAs on sg.example.net, even though they started with the same outer IP address. Is that assumption correct? --- What happens if it takes a while for Alice to walk to the other network so that things happen in this order: 1. Alice DHCP lease for the outer address (X) expires 2. Bob shows up at IETF and is allocated IP address X. 3. Bob contacts sg.example.net, and the SG still has the SAs for Alice at outer address X. Can Bob setup its SAs? What happens to Alice's SAs at the SG? 4. Alice finally arrives at the second network, is allocated IP address Y, and contacts the SG and uses MOBIKE to move its SAs from X to Y. Does this work as well as if Bob hadn't been around? There are variants on the above when Alice is walking even slower so that one or more of these happen before Bob arrives: - The IPsec SAs for Alice on the SG expires - The IKE SAs for Alice on the SG expires - The "lease" for the dynamically allocated inner address A expires on the SG, thus Bob might accidentally end up reusing both the inner and the outer IP addresses that Alice had. All these cases are introduced by MOBIKE, since it enables the reuse of the outer IP address by somebody else. Has anybody done the complete case analysis to check if we need some additional recommendations for the protocol behavior of the SG in order to ensure interoperability for these cases? > None of this is really specific to MOBIKE as such, so I think > we should not add text about this to the MOBIKE draft... I hope the above examples show that there are potential issues for how MOBIKE interacts with IKE on the SG. Erik _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Feb 03 03:57:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4wkr-0000wV-HE for mobike-archive@megatron.ietf.org; Fri, 03 Feb 2006 03:57:25 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06661 for ; Fri, 3 Feb 2006 03:55:35 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B48B3FB299; Fri, 3 Feb 2006 03:57:04 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id C1B91FB294 for ; Fri, 3 Feb 2006 03:57:02 -0500 (EST) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k138uwu8008010; Fri, 3 Feb 2006 10:57:01 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 10:56:59 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Feb 2006 10:56:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 3 Feb 2006 10:56:57 +0200 Message-ID: In-Reply-To: <43E25F87.7060704@sun.com> Thread-Topic: [Mobike] does mobike support end-to-end use of tunnel mode? Thread-Index: AcYoMG83Tc1TYYZCQXScOi/r8RMtygAa92LQ From: To: X-OriginalArrivalTime: 03 Feb 2006 08:56:59.0578 (UTC) FILETIME=[CAE871A0:01C6289F] Cc: mobike@machshav.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > > Pasi.Eronen@nokia.com wrote: > > > Well... if you have host-to-host tunnel mode IPsec working in a > > secure manner, MOBIKE could work as well. But this situation > > is pretty rare. > > Clarifying question: for this case are you assuming that the > inner and outer IP addresses for the tunnel must be different? > > I think tunnel mode can be used (per the RFCs even if > implementations might not handle it) where the inner and outer > IP addresses are the same. Yes, both addresses can be the same, but that does not really change the situation much. > If you apply MOBIKE to such a case, then you end up with an unsolved > address ownership issues, because the existence of the IPsec SAs, > which now use a different outer remote address, will prevent a > different host which has "inherited" that outer address from > establishing a SA with the same peer. The address ownership issue is not new to MOBIKE; exactly the same thing exists in RFC 4301 and 4306. > This end-to-end tunnel case was in fact the one that made me > concerned. > > A host is using some public-access network infrastructure. It > gets allocated IP address B by a DHCP server. > > B contacts server A (www.example.com), and uses Mobike. > As a result of this, A ends up with a (IKE and IPsec) SAs that make > packets destined to IP address B be subject to the IPsec SA that was > setup. Thus packets destined from A to B are placed on an ESP tunnel, > with a destination of B. No; it's much more likely that creating the IPsec SA will fail. As explained in Section 4.4.3 of RFC4301, server A will allow creating this IPsec SA _only_if the Child SA Authorization Data in its PAD has an entry "Authenticated-identity-X is allowed to create IPsec SAs with traffic selectors matching address B". In reality, this will not be the case, since server A has never heard about address B before. In other words, just sending IKEv2 packets using some particular address does not imply a permission to create IPsec SAs with that address in the traffic selectors! Of course, you can configure your PAD in a way that allows any authenticated peer to create IPsec SAs with any traffic selectors, but that would not be very secure in most environments. MOBIKE does not change this part of IPsec. In particular, moving to some particular address using UPDATE_SA_ADDRESSES, completing a return routability check, or including an address in the list of additional addresses do not imply any updates to the Child SA Authorization Data in the PAD. Let's not forget that the "UPDATE_SA_ADDRESSES" part of MOBIKE is basically an optimization to avoid creating new IKE_SAs when addresses change (and we want this optimization because creating an IKE_SA is likely to require user interaction, not because of extra roundtrips). If the PAD says "everything goes", an attacker can get the same effect by creating a new IKE_SA and new CHILD_SAs, without using MOBIKE at all. Presumably, the attacker wouldn't be worried about the inconvenience of typing the password twice. > The host (B) later moves to a different network, where it is > assigned IP address C. It uses Mobike to move the IKE and IPsec SAs > from using B to using C. This (and here is were the document is > silent) means that packets sent from A to B and placed in an ESP > tunnel with a destination of C. (In any case, there isn't any text > I could find that says that there is no residual IKE or IPsec SA or > policy that refer to B.) Yes, this is what happens (but only if the PAD allowed creating the SA in the first place). And this is correct, since according to server A's PAD, the peer is authorized to "represent" address B (there's no distinction between a host and extremely small security gateway in this case; although for SG, it's likely that instead of a B1.B2.B3.B4/32 this would be at least /29 or /28). > What happens when another host appears on the initial public-access > infrastructure and is assigned IP address B by the DHCP server? > (This could be hours or days after the first host left.) When that > host tries to contact www.example.com, things would fail due to the > SADB and SPD entries that were created by the original host. Creating the IPsec SAs could be succesful only if the PAD also has an entry "second-authenticated-identity is allowed to create IPsec SAs with traffic selectors matching address B". In other words, server A is configured in a way that both the first and second authenticated peers are allowed to represent address B. > The above isn't an issue for a IPsec SG that has static > allocation/authorization of the inner IP addresses (having a fixed > binding between the clients CERT and the inner IP address is clearly > secure). Don't know if there are issues with IPsec SGs that do > dynamic allocation of the inner IP address. Dynamic allocation of the inner IP address (using configuration payloads) basically implies that the SG adds a temporary PAD entry binding the authenticated peer identity and the newly allocated inner address. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Feb 03 08:25:15 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F50vw-0007XG-3s for mobike-archive@megatron.ietf.org; Fri, 03 Feb 2006 08:25:15 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26422 for ; Fri, 3 Feb 2006 08:23:18 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ECD6CFB29D; Fri, 3 Feb 2006 08:24:48 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 5CC9FFB299 for ; Fri, 3 Feb 2006 08:24:47 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 0B6098990E; Fri, 3 Feb 2006 15:24:43 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B6FE88990D; Fri, 3 Feb 2006 15:24:42 +0200 (EET) Message-ID: <43E359B3.4000606@piuha.net> Date: Fri, 03 Feb 2006 15:25:07 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark References: <43E27F8B.7060205@sun.com> In-Reply-To: <43E27F8B.7060205@sun.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mobike@machshav.com, mohanp@sbcglobal.net, Pasi.Eronen@nokia.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Erik Nordmark wrote: >The configuration payload allows the client to suggest an IP address as >well as just getting one assigned by the SG. I don't know if that >introduces any new issues. But in any case, that isn't a problem >introduced by the MOBIKE WG. > > Right. >But is there or is there not an issue introduced by the combination of >dynamic SG assignment of inner addresses, and MOBIKE changing the outer >addresses? > >Here is an example: > >Alice visits the IETF, get X as the IP address, connects to >sg.example.net. The SG allocates A as the inner IP address for Alice. > >Alice moves to another network. Gets Y as the IP address and uses MOBIKE >to move the SAs from X to Y. > >An hour later Bob, who also works at example.net, walks into the IETF >and is allocated X as its IP address. Bob connects to sg.example.net and >is allocated B as the inner address. >I assume there is no conflict between Alice's and Bob's SAs on >sg.example.net, even though they started with the same outer IP address. >Is that assumption correct? > > I think so. SA identification needs to happen via SPIs, not addresses. And for the internal addresses, the policies for accepting inner address proposals have to be so that A != B, even without MOBIKE. >--- > >What happens if it takes a while for Alice to walk to the other network >so that things happen in this order: >1. Alice DHCP lease for the outer address (X) expires >2. Bob shows up at IETF and is allocated IP address X. >3. Bob contacts sg.example.net, and the SG still has the SAs for Alice >at outer address X. Can Bob setup its SAs? What happens to Alice's SAs >at the SG? > > All of this is fine. Remember that already today we have to allow a situation where a number of VPN connections come from the same IP addresses, due to NATs. The SPIs will be different and the UDP port numbers will be different. (And when they aren't -- see the appendix in mobike protocol spec for a warning on how to do your implementation.) >4. Alice finally arrives at the second network, is allocated IP address >Y, and contacts the SG and uses MOBIKE to move its SAs from X to Y. Does >this work as well as if Bob hadn't been around? > > Yes. >There are variants on the above when Alice is walking even slower so >that one or more of these happen before Bob arrives: > - The IPsec SAs for Alice on the SG expires > > This is fine. > - The IKE SAs for Alice on the SG expires > > There's nothing special about this. Alice just has to re-establish her IKE SA, and then this is already from the new address. Nothing in this entire process affects the inner addresses. > - The "lease" for the dynamically allocated inner address A expires on >the SG, thus Bob might accidentally end up reusing both the inner and >the outer IP addresses that Alice had. > > This might be possible, but again, this is an IKEv2 problem. The lease might expire even if Alice didn't move, and didn't implement MOBIKE. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Feb 03 09:21:52 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F51oo-0003CJ-08 for mobike-archive@megatron.ietf.org; Fri, 03 Feb 2006 09:21:52 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02030 for ; Fri, 3 Feb 2006 09:19:59 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A58D3FB29D; Fri, 3 Feb 2006 09:21:35 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id C2CD2FB299 for ; Fri, 3 Feb 2006 09:21:33 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EEDB28990E; Fri, 3 Feb 2006 16:21:32 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B435F8990D; Fri, 3 Feb 2006 16:21:32 +0200 (EET) Message-ID: <43E36705.9010001@piuha.net> Date: Fri, 03 Feb 2006 16:21:57 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark References: <43E25F87.7060704@sun.com> In-Reply-To: <43E25F87.7060704@sun.com> X-Virus-Scanned: ClamAV using ClamSMTP Cc: mobike@machshav.com, mohanp@sbcglobal.net, Pasi.Eronen@nokia.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit Erik Nordmark wrote: > If you apply MOBIKE to such a case, then you end up with an unsolved > address ownership issues, because the existence of the IPsec SAs, > which now use a different outer remote address, will prevent a > different host which has "inherited" that outer address from > establishing a SA with the same peer. Lets talk about this case first without the inner=outer case. Generally, you can have multiple IKEv2 SAs from the same address, and the fact that they are from the same address says nothing about their "sameness"; the SAs have their own authorization, keying material, etc. Even if they come from the same address, they migh be have different inner address authorizations, for instance. Secondly, the inner and outer addresses are also unrelated. What's in the outer address does not necessarily pay any role in the authorization of specific inner addresses in the child SAs. Thirdly, MOBIKE is not a fully fledged mobility protocol in the same way as SHIM6 or MIPv6 are. Specifically, it does not provide its own stable identifier, but relies instead on the inner addresses for being stable. This implies that its incompatible with the model where inner=outer or where transport mode is used. (That does not mean, however, that it would be impossible to extend it to do these things.) > Clarifying question: for this case are you assuming that the inner and > outer IP addresses for the tunnel must be different? > > I think tunnel mode can be used (per the RFCs even if implementations > might not handle it) where the inner and outer IP addresses are the same. It can, but I don't think there's any magic associated with it. Its still the same old child SA authorization that applies. If your PAD is correctly set up, you can start with inner=outer and then move to another location while keeping your inner address the same. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Feb 05 16:40:58 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5rcr-0007P5-OY for mobike-archive@megatron.ietf.org; Sun, 05 Feb 2006 16:40:58 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17092 for ; Sun, 5 Feb 2006 16:39:05 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7F500FB293; Sun, 5 Feb 2006 16:40:38 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 170D9FB290 for ; Sun, 5 Feb 2006 16:40:35 -0500 (EST) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [192.44.77.29]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id k15LeHg11755; Sun, 5 Feb 2006 22:40:17 +0100 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id k15LeDOk084072; Sun, 5 Feb 2006 22:40:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200602052140.k15LeDOk084072@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark In-reply-to: Your message of Thu, 02 Feb 2006 11:37:43 PST. <43E25F87.7060704@sun.com> Date: Sun, 05 Feb 2006 22:40:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, jari.arkko@piuha.net, mohanp@sbcglobal.net, Pasi.Eronen@nokia.com Subject: Re: [Mobike] does mobike support end-to-end use of tunnel mode? X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: 7bit In your previous mail you wrote: > Well... if you have host-to-host tunnel mode IPsec working in a > secure manner, MOBIKE could work as well. But this situation > is pretty rare. Clarifying question: for this case are you assuming that the inner and outer IP addresses for the tunnel must be different? => they may be different only. To use the two-space system terms, the inner address is an identifier and the outer is a locator. MOBIKE can only change the outer address because the inner one is a traffic selector. BTW MOBIKE can be extended to transport mode when handoffs don't imply a traffic selector change (I know at least two common cases of this). To come back to authorization: IPsec assumes an authorization about the content of traffic selectors, so about inner addresses. It is used in the MIPv6/NEMO context. Regards Francis.Dupont@point6.net PS: I'll see further messages of this thread. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Feb 20 03:17:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FB6F4-00009R-5Q for mobike-archive@lists.ietf.org; Mon, 20 Feb 2006 03:17:58 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FB6F2-0006Hf-R4 for mobike-archive@lists.ietf.org; Mon, 20 Feb 2006 03:17:58 -0500 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 144FBFB292; Mon, 20 Feb 2006 03:17:54 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id D2C88FB28D for ; Mon, 20 Feb 2006 03:17:51 -0500 (EST) Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 62CFE8993D for ; Mon, 20 Feb 2006 10:17:43 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F28368993C for ; Mon, 20 Feb 2006 10:17:42 +0200 (EET) Message-ID: <43F97B3A.8090105@piuha.net> Date: Mon, 20 Feb 2006 10:18:02 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List X-Virus-Scanned: ClamAV using ClamSMTP Subject: [Mobike] FW: MOBIKE WG at IETF-65 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 This is the current reservation for our WG meeting in the IETF-65 agenda: >TUESDAY, March 21, 2006 > > ... >1720-1740 Afternoon Snack and Refreshment Break - >1740-1840 Afternoon Session III >INT l3vpn Layer 3 Virtual Private Networks WG >RAI simple SIP for Instant Messaging and Presence Leveraging Extensions WG >TSV dccp Datagram Congestion Control Protocol WG >SEC dkim Domain Keys Identified Mail WG >SEC mobike IKEv2 Mobility and Multihoming WG > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Feb 22 10:03:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FBvWV-0000Oe-Ld for mobike-archive@lists.ietf.org; Wed, 22 Feb 2006 10:03:23 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FBvWU-0007MY-3x for mobike-archive@lists.ietf.org; Wed, 22 Feb 2006 10:03:23 -0500 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8B51EFB2A6; Wed, 22 Feb 2006 10:03:20 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from ns1.cpanel.btnaccess.com (ns1.cpanel.btnaccess.com [205.177.121.2]) by machshav.com (Postfix) with ESMTP id 0BA3FFB2A5 for ; Wed, 22 Feb 2006 10:03:18 -0500 (EST) Received: from [65.213.193.135] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FBvWN-0007tq-Tp for mobike@machshav.com; Wed, 22 Feb 2006 10:03:16 -0500 From: "Robert Holliday" To: Date: Wed, 22 Feb 2006 10:03:16 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcY3wRwkp7Xipfj4T86HNQ2yJOBe6w== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - machshav.com X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20060222150318.0BA3FFB2A5@machshav.com> Subject: [Mobike] International Conference on Network Security 2006 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0496448992==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 This is a multi-part message in MIME format. --===============0496448992== Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C63797.33932AF0" This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C63797.33932AF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Registration Open!!! Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at rholliday@isocore.com. www.networksecurity2006.com ------=_NextPart_000_000C_01C63797.33932AF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

=

Registration = Open!!!

 

Reston Virginia, April = 17-19

Early Registration Benefits = Now Available

 

The conference offers cutting edge discussion and presentations on the contemporary issues in network security and = critical information infrastructure. 

 

Technical = Program: http://www.isocore.com/netwo= rksecurity2006/program.htm

 

Discounts still available for early = registration.

 

Registration: http://www.isocore.com/netwo= rksecurity2006/onlineregis.htm

 

Hotel space is limited but currently available and reservation can be made on-line.

 

Hotel = Reservations: http://www.isocore.com/netwo= rksecurity2006/hotel.htm

 

To obtain special rates for student or group please = contact Robert Holliday at rholliday@isocore.com.

 

www.networksecurity2006.com<= /span>

 

 

 

------=_NextPart_000_000C_01C63797.33932AF0-- --===============0496448992== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --===============0496448992==-- From mobike-bounces@machshav.com Fri Feb 24 15:50:09 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCjtB-0002HI-VN for mobike-archive@lists.ietf.org; Fri, 24 Feb 2006 15:50:09 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCjtA-0000C0-IQ for mobike-archive@lists.ietf.org; Fri, 24 Feb 2006 15:50:09 -0500 Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3AFFCFB2A1; Fri, 24 Feb 2006 15:50:05 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by machshav.com (Postfix) with ESMTP id C6638FB293 for ; Fri, 24 Feb 2006 15:50:02 -0500 (EST) Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k1OKo1vP003104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 24 Feb 2006 20:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FCjt3-0002Ux-DW; Fri, 24 Feb 2006 15:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Feb 2006 15:50:01 -0500 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-protocol-08.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.7 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IKEv2 Mobility and Multihoming Working Group of the IETF. Title : IKEv2 Mobility and Multihoming Protocol (MOBIKE) Author(s) : P. Eronen Filename : draft-ietf-mobike-protocol-08.txt Pages : 38 Date : 2006-2-24 This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile VPN client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-08.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-mobike-protocol-08.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-mobike-protocol-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-2-24134928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-protocol-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-protocol-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-2-24134928.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart--