From mobike-bounces@machshav.com Tue Nov 01 00:14:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWoTT-0004Yl-Eq for mobike-archive@megatron.ietf.org; Tue, 01 Nov 2005 00:14:19 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12033 for ; Tue, 1 Nov 2005 00:13:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 47AD5FB28D; Tue, 1 Nov 2005 05:14:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A45BEFB284; Tue, 1 Nov 2005 05:14:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 21D3CFB285; Tue, 1 Nov 2005 05:14:15 +0000 (UTC) Received: from smtp101.sbc.mail.mud.yahoo.com (smtp101.sbc.mail.mud.yahoo.com [68.142.198.200]) by machshav.com (Postfix) with SMTP id 433CBFB281 for ; Tue, 1 Nov 2005 05:14:14 +0000 (UTC) Received: (qmail 99211 invoked from network); 1 Nov 2005 05:14:13 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.9 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 1 Nov 2005 05:14:13 -0000 Message-ID: <000b01c5dea3$1ac04190$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <17249.60186.904922.201619@fireball.kivinen.iki.fi><20051028173833.41403.qmail@web80604.mail.yahoo.com> <17253.59958.496661.679698@fireball.kivinen.iki.fi> Date: Mon, 31 Oct 2005 21:14:14 -0800 MIME-Version: 1.0 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 Cc: Jari Arkko , MOBIKE Mailing List Subject: Re: [Mobike] Issue 46 (was: protocol draft status and movingforward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > > Why does one have to indicate that they have > > NO_ADDITIONAL_ADDRESSES ? If i don't send > > ADDITIONAL_IP* notification then you just have one > > address to operate with. What is the use of explicitly > > indicating this ? Also, ADDITIONAL_IP with zero > > address can do the same i guess i.e ADDITIONAL_IP* > > replaces the previous list with zero or more > > addresses. > > Ok, lets add explination about that too: > > The NO_ADDITIONAL_ADDRESSES notify is needed, as otherwise it > would not be possible to distinguish empty DPD message from > address update message that does not have any additional > addresses. Now we can distinguish them, as DPD is empty > INFORMATIONAL exchange and address update with no extra addresses > is INFORMATIONAL exchange having only N(NO_ADDITIONAL_ADDRESSES). > Both of them can have other additional payloads like N(COOKIE2) > etc. Hmm...part of the problem is that NO_ADDITIONAL_ADDRESS is really DELETE_ADDITIONAL_ADDRESS. But we don't want to use the word DELETE because we provide only replace semantics. It may sound trivial, but what exact action (delete the addresses contained in the previous ADD_ADDITIONAL_IP*) needs to be performed is not explained anywhere (not in 05). The defintion in 4.3 contains : The NO_ADDITIONAL_ADDRESSES notification can be included in an INFORMATIONAL exchange request message to indicate that the exchange initiator does not have addresses beyond the one used in the exchange (see Section 3.6 for more detailed description). Section 3.6 only contains "update the peer addresses ...". Perhaps the definition should be appended with.. "The exchange initiator sends this notification to delete the addresses sent in the earlier ADD_ADDITIONAL_ADDRESS notification". -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ > 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 Nov 02 04:40:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXF6A-0003vB-J9 for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 04:40:03 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23379 for ; Wed, 2 Nov 2005 04:39:41 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A377AFB28A; Wed, 2 Nov 2005 09:39:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A41A5FB284; Wed, 2 Nov 2005 09:39:57 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B8933FB285; Wed, 2 Nov 2005 09:39:55 +0000 (UTC) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by machshav.com (Postfix) with ESMTP id 69918FB282 for ; Wed, 2 Nov 2005 09:39:54 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id jA29dhhR005140; Wed, 2 Nov 2005 10:39:44 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id jA29dels005123; Wed, 2 Nov 2005 10:39:40 +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 jA29dda2054558; Wed, 2 Nov 2005 10:39:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511020939.jA29dda2054558@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Fri, 28 Oct 2005 11:44:51 +0300. <17249.58627.276353.689034@fireball.kivinen.iki.fi> Date: Wed, 02 Nov 2005 10:39:39 +0100 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: MOBIKE Mailing List , Jari Arkko Subject: Re: [Mobike] MOBIKE WG Agenda for IETF-64, take 1 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: We have rfc3554 implemented, but I do not think any of our customers actually uses it. Or at least none of the customers have ever complained or questioned anything about it from our support people, and that usually means that they are not using it at all. => perhaps they are waiting for IKEv2/2401bis? (:-) Note also that RFC3554 had this wierd text that indicated that you could actually use ID_LIST in the Phase 1 IDs too, and that is not possible in the IKEv2. The ID payload of the IKEv2 is always single identity, not a list. => it seems the ID_LIST in the Phase 1 can be replaced by the additional address stuff ("Specify multiple Phase 1 IDs, which are used to validate Phase 2 parameters (in particular, the Phase 2 selectors)"). The traffic selectors used in the IPsec SAs are lists so there should not be problem to use those in the SCTP. => I agree. The IKEv2 traffic selectors sent by the initiator must of course be such that the responder can narrow the TSr to be his own set of IP-addresses, i.e. the initiator sends TSi list with his own addresses, and sends 0.0.0.0.-255.255.255.255 and ::-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ip-adderess as TSr, so responder can then narrow it down to his own set of IP-addresses. => you assume the initiator doesn't know the responder addresses. I have not followed SCTP documents, but RFC3554 says that there currently is no way to modify the addresses when they are in use. Does anybody know if that has already changed, i.e. does the SCTP now support changing the addresses while it is in use? At least there are no RFCs yet about that. => there are some drafts which can add and/or delete addresses from the peer address sets. Also the current SCTP model seems to be that it uses only the one IP-address pair at time, and only uses the others when the primary address pair is not working. This actually means that supporting that in IKEv2/MOBIKE is quite simple, and only requires basic MOBIKE abilities (i.e. the things we have in the draft now). => yes, the current SCTP model is the "failover" one. Thanks Francis.Dupont@enst-bretagne.fr PS: the support of multiple *simultaneous* addresses in SAs seems to be both not necessary and perhaps problematic in the 2401bis framework. IMHO the update mechanism is enough so we should be able to adapt easily (i.e., nothing to change, only an application note) current MOBIKE to current SCTP, including SCTP mobility support. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 02 06:24:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXGjd-0005bu-HA for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 06:24:53 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28224 for ; Wed, 2 Nov 2005 06:24:31 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8F891FB289; Wed, 2 Nov 2005 11:24:51 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 45212FB282; Wed, 2 Nov 2005 11:24:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 27CE6FB284; Wed, 2 Nov 2005 11:24:49 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 26FA0FB280 for ; Wed, 2 Nov 2005 11:24:48 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA2BMCNC015906; Wed, 2 Nov 2005 13:22:17 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 13:24:46 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 13:24:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Nov 2005 13:24:48 +0200 Message-ID: Thread-Topic: [Mobike] 51 - spi collisions Thread-Index: AcXZJaLqbxKiP19/SS+k/xbgDtk/uAGeR0Tg From: To: , X-OriginalArrivalTime: 02 Nov 2005 11:24:46.0112 (UTC) FILETIME=[075B6A00:01C5DFA0] Subject: Re: [Mobike] 51 - spi collisions X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > The text is too simple to help the readers understand the > issue. At least providing an example (like the one given in Thomas > mail) as a background before the suggested text might help read it > better. Here's a proposal for text: Appendix A. Implementation Considerations A.1. Links from SPD Cache to Outbound SAD Entries [IPsecArch] Section 4.4.2 says that "For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache". The document does not specify how exactly this "pointing" is done, since this is an implementation detail that does not have to be standardized. However, it is clear that the links between the SPD cache and the SAD have to be done correctly to ensure that outbound packets are sent over the right SA. Some implementations are known to have problems in this area. In particular, simply storing the (remote tunnel header IP address, remote SPI) pair in the SPD cache is not sufficient, since the pair does not always uniquely identify a single SAD entry. For instance, two hosts behind the same NAT can accidentally happen to choose the same SPI value. The situation can also occur when a host is assigned an IP address previously used by some other host, and the SAs associated with the old host have not yet been deleted by dead peer detection. This may lead to packets being sent over the wrong SA or, if the key management daemon ensures the pair is unique, denying the creation of otherwise valid SAs. Storing the remote tunnel header IP address in the SPD cache may also complicate the implementation of MOBIKE, since the address can change during the lifetime of the SA. Thus, we recommend implementing the links between the SPD cache and the SAD in a way that does not require modification when the tunnel header IP address is updated by MOBIKE. For instance, in the C programming language, an ordinary pointer could be used. Any comments? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 02 07:58:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXICV-0000gY-NR for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 07:58:47 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03650 for ; Wed, 2 Nov 2005 07:58:24 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0D3DAFB285; Wed, 2 Nov 2005 12:58:44 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C21A3FB280; Wed, 2 Nov 2005 12:58:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B5109FB282; Wed, 2 Nov 2005 12:58:39 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 728D9FB249 for ; Wed, 2 Nov 2005 12:58:38 +0000 (UTC) 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 jA2CwSw22432; Wed, 2 Nov 2005 13:58:28 +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 jA2CwRuX055523; Wed, 2 Nov 2005 13:58:28 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511021258.jA2CwRuX055523@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com In-reply-to: Your message of Wed, 02 Nov 2005 13:24:48 +0200. Date: Wed, 02 Nov 2005 13:58:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mohanp@sbcglobal.net, mobike@machshav.com Subject: Re: [Mobike] 51 - spi collisions X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: Storing the remote tunnel header IP address in the SPD cache may also complicate the implementation of MOBIKE, since the address can change during the lifetime of the SA. Thus, we recommend implementing the links between the SPD cache and the SAD in a way that does not require modification when the tunnel header IP address is updated by MOBIKE. For instance, in the C programming language, an ordinary pointer could be used. Any comments? => I am afraid it is not enough: the link issue is not the only issue: if the SPD has no indication of what are the new endpoint addresses to use after an update, one cannot guarantee a new SA pair will be create using the right addresses. So an update should impact something somewhere in the SPD. Regards Francis.Dupont@enst-bretagne.fr PS: NAT-T and MIPv6 have the same issue. In NAT-T it is solved by making the initiator always behind the NAT (so the address can "float" as it is never used :-). In MIPv6 a solution is described in draft-sugimoto-mip6-pfkey-migrate-01.txt and in the real world an "unique" tag is used. BTW a C pointer is not a good solution because there is no one-to-one mapping between SPD and SAD. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 02 08:19:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIWc-0004Ah-Ey for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 08:19:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05489 for ; Wed, 2 Nov 2005 08:19:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5056DFB284; Wed, 2 Nov 2005 13:19:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1044BFB277; Wed, 2 Nov 2005 13:19:31 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B61FCFB280; Wed, 2 Nov 2005 13:19:29 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 9C7D8FB262 for ; Wed, 2 Nov 2005 13:19:28 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jA2DJIg3012452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Nov 2005 15:19:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jA2DJI91009675; Wed, 2 Nov 2005 15:19:18 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17256.48342.106506.242828@fireball.kivinen.iki.fi> Date: Wed, 2 Nov 2005 15:19:18 +0200 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200511020939.jA29dda2054558@givry.rennes.enst-bretagne.fr> References: <17249.58627.276353.689034@fireball.kivinen.iki.fi> <200511020939.jA29dda2054558@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: MOBIKE Mailing List , Jari Arkko Subject: Re: [Mobike] MOBIKE WG Agenda for IETF-64, take 1 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Francis Dupont writes: > The IKEv2 traffic selectors sent by the initiator must of course be > such that the responder can narrow the TSr to be his own set of > IP-addresses, i.e. the initiator sends TSi list with his own > addresses, and sends 0.0.0.0.-255.255.255.255 and > ::-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF ip-adderess as TSr, so > responder can then narrow it down to his own set of IP-addresses. > > => you assume the initiator doesn't know the responder addresses. I assume he does not know all of the address the responder is using. He might know one or few, but not necessarely all. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 02 08:23:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIa7-0006XV-Fp for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 08:23:14 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05636 for ; Wed, 2 Nov 2005 08:22:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 028F9FB28D; Wed, 2 Nov 2005 13:23:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6E997FB285; Wed, 2 Nov 2005 13:23:07 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8467AFB289; Wed, 2 Nov 2005 13:23:05 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 1510BFB284 for ; Wed, 2 Nov 2005 13:23:04 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jA2DN3Zb006178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Nov 2005 15:23:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jA2DN27P006431; Wed, 2 Nov 2005 15:23:02 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17256.48566.784871.473280@fireball.kivinen.iki.fi> Date: Wed, 2 Nov 2005 15:23:02 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: mohanp@sbcglobal.net, mobike@machshav.com Subject: Re: [Mobike] 51 - spi collisions X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > Appendix A. Implementation Considerations > > A.1. Links from SPD Cache to Outbound SAD Entries > > [IPsecArch] Section 4.4.2 says that "For outbound processing, > each SAD entry is pointed to by entries in the SPD-S part of the > SPD cache". The document does not specify how exactly this > "pointing" is done, since this is an implementation detail that > does not have to be standardized. > > However, it is clear that the links between the SPD cache and the > SAD have to be done correctly to ensure that outbound packets are > sent over the right SA. Some implementations are known to have > problems in this area. > > In particular, simply storing the (remote tunnel header IP > address, remote SPI) pair in the SPD cache is not sufficient, > since the pair does not always uniquely identify a single SAD > entry. For instance, two hosts behind the same NAT can > accidentally happen to choose the same SPI value. The situation > can also occur when a host is assigned an IP address previously > used by some other host, and the SAs associated with the old host > have not yet been deleted by dead peer detection. This may lead > to packets being sent over the wrong SA or, if the key management > daemon ensures the pair is unique, denying the creation of > otherwise valid SAs. > > Storing the remote tunnel header IP address in the SPD cache may > also complicate the implementation of MOBIKE, since the address > can change during the lifetime of the SA. Thus, we recommend > implementing the links between the SPD cache and the SAD in a way > that does not require modification when the tunnel header IP > address is updated by MOBIKE. For instance, in the C programming > language, an ordinary pointer could be used. > > Any comments? Fine by me. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 02 08:30:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXIhG-0001Me-40 for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 08:30:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05944 for ; Wed, 2 Nov 2005 08:30:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A1FC7FB280; Wed, 2 Nov 2005 13:30:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 69D3DFB282; Wed, 2 Nov 2005 13:30:31 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BFF57FB284; Wed, 2 Nov 2005 13:30:29 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id C7E55FB280 for ; Wed, 2 Nov 2005 13:30:28 +0000 (UTC) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA2DUMCq011227; Wed, 2 Nov 2005 15:30:26 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 15:30:21 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 15:30:20 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 2 Nov 2005 15:30:23 +0200 Message-ID: Thread-Topic: [Mobike] 51 - spi collisions Thread-Index: AcXfrUJshqQPGeKpScePui4ctgcdDgAAfxfA From: To: X-OriginalArrivalTime: 02 Nov 2005 13:30:20.0585 (UTC) FILETIME=[9240C190:01C5DFB1] Cc: mobike@machshav.com Subject: Re: [Mobike] 51 - spi collisions X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Francis Dupont wrote: > In your previous mail you wrote: > > Storing the remote tunnel header IP address in the SPD > cache may also complicate the implementation of MOBIKE, > since the address can change during the lifetime of the > SA. Thus, we recommend implementing the links between the > SPD cache and the SAD in a way that does not require > modification when the tunnel header IP address is updated > by MOBIKE. For instance, in the C programming language, an > ordinary pointer could be used. > > Any comments? > > => I am afraid it is not enough: the link issue is not the only > issue: if the SPD has no indication of what are the new endpoint > addresses to use after an update, one cannot guarantee a new SA > pair will be create using the right addresses. So an update > should impact something somewhere in the SPD. Currently, it's beyond the scope of MOBIKE how the initial contact is handled. Section 1.2 says: The mobility support in MOBIKE allows both parties to move, but does not provide a "rendezvous" mechanism that would allow [...] discovering the addresses when the IKE_SA is first established. In fact, if your manually configured SPD entry says that a certain IP address must be used when the SA is established, then that's the policy that must be followed, MOBIKE or not. If the IP address of the remote tunnel endpoint is not static, you need some kind of "rendezvous" mechanism for discovering it, like DNS (but then the SPD entry that triggers the creation of the IKE_SA would contain the FQDN of the remote tunnel endpoint, not the IP address -- and this is what "remote access" VPN clients usually do, I guess). > PS: NAT-T and MIPv6 have the same issue. In NAT-T it is solved by > making the initiator always behind the NAT (so the address can > "float" as it is never used :-). In MIPv6 a solution is described > in draft-sugimoto-mip6-pfkey-migrate-01.txt and in the real world > an "unique" tag is used. Yes, some kind of unique tag could be used instead of a pointer... > BTW a C pointer is not a good solution because there is no > one-to-one mapping between SPD and SAD. Well, it's many-to-one, so a pointer could work in the SPD cache-to-SAD direction..? But perhaps it's better not to say anything about C pointers in this document at all. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 02 08:51:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXJ1o-0006fJ-Ip for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 08:51:48 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07065 for ; Wed, 2 Nov 2005 08:51:25 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1F4A7FB289; Wed, 2 Nov 2005 13:51:47 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 351D0FB282; Wed, 2 Nov 2005 13:51:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3D28DFB284; Wed, 2 Nov 2005 13:51:45 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id B68F3FB280 for ; Wed, 2 Nov 2005 13:51:43 +0000 (UTC) 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 jA2DpIb27780; Wed, 2 Nov 2005 14:51:18 +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 jA2DpIHQ055949; Wed, 2 Nov 2005 14:51:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511021351.jA2DpIHQ055949@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com In-reply-to: Your message of Wed, 02 Nov 2005 15:30:23 +0200. Date: Wed, 02 Nov 2005 14:51:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com Subject: Re: [Mobike] 51 - spi collisions X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > => I am afraid it is not enough: the link issue is not the only > issue: if the SPD has no indication of what are the new endpoint > addresses to use after an update, one cannot guarantee a new SA > pair will be create using the right addresses. So an update > should impact something somewhere in the SPD. Currently, it's beyond the scope of MOBIKE how the initial contact is handled. Section 1.2 says: => I don't speak about the initial contact but the case where there are many SPD entries requiring IPsec protection between the two peers and only some of them have active IPsec SA pairs. The peer addresses are somewhere in the SPD (this is highly implementation dependent) and this information must be updated. In fact, if your manually configured SPD entry says that a certain IP address must be used when the SA is established, then that's the policy that must be followed, MOBIKE or not. => this is not the issue, next paragraph seems better. If the IP address of the remote tunnel endpoint is not static, => they are not in MOBIKE. you need some kind of "rendezvous" mechanism for discovering it, => no, we need this only if they are dynamic at *both* sides. like DNS (but then the SPD entry that triggers the creation of the IKE_SA would contain the FQDN of the remote tunnel endpoint, not the IP address -- and this is what "remote access" VPN clients usually do, I guess). => the VPN client I use has the addresses of the VPN server. It doesn't try DNS resolution because it tries to send no packets before IKE/IPsec setup. To come back to the main point, the peer addresses are dynamic and included somewhere in the SPD or the PAD. The way this is supported is very implementation dependent but the fact the information must be updatable by MOBIKE is not at choice. > BTW a C pointer is not a good solution because there is no > one-to-one mapping between SPD and SAD. Well, it's many-to-one, so a pointer could work in the SPD cache-to-SAD direction..? => but without a back pointer to patch it when the SAD changes is painful. But perhaps it's better not to say anything about C pointers in this document at all. => I agree. Regards Francis.Dupont@enst-bretagne.fr PS: BTW this is not the first time we have this discussion on the list. The problem is a detailed solution should be too implementation dependent and too vague wording doesn't help. But IMHO this is a critical issue: in fact the update the IPsec SAs is less important than the update the peer addresses in the policy! _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 02 12:33:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXMUp-0008RY-A0 for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 12:33:59 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23839 for ; Wed, 2 Nov 2005 12:33:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A531CFB289; Wed, 2 Nov 2005 17:33:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9361BFB284; Wed, 2 Nov 2005 17:33:56 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5029BFB285; Wed, 2 Nov 2005 17:33:55 +0000 (UTC) Received: from web80609.mail.yahoo.com (web80609.mail.yahoo.com [66.94.235.71]) by machshav.com (Postfix) with SMTP id 7FD43FB280 for ; Wed, 2 Nov 2005 17:33:54 +0000 (UTC) Received: (qmail 51777 invoked by uid 60001); 2 Nov 2005 17:33:51 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=mwXWNb2i1mc/6dCqSgZYtQF7vPlclPUZDJDXFGnj3mKFc0fdrlI0TkB5tGucjcOjkGuzNiHcQrNj6nPzp+PHzmD6Gg7QgUqbfHYA+ALUD7nAFh1bnL0XTJMQDPxh+/XrAryO/G0Zt2nmpaobNIiTggF3i9SGAw7AvPu/bFxOOYc= ; Message-ID: <20051102173351.51775.qmail@web80609.mail.yahoo.com> Received: from [206.132.194.2] by web80609.mail.yahoo.com via HTTP; Wed, 02 Nov 2005 09:33:51 PST Date: Wed, 2 Nov 2005 09:33:51 -0800 (PST) From: Mohan Parthasarathy To: Pasi.Eronen@nokia.com, mobike@machshav.com In-Reply-To: MIME-Version: 1.0 Subject: Re: [Mobike] 51 - spi collisions X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > > > The text is too simple to help the readers > understand the > > issue. At least providing an example (like the one > given in Thomas > > mail) as a background before the suggested text > might help read it > > better. > > Here's a proposal for text: > > Appendix A. Implementation Considerations > > A.1. Links from SPD Cache to Outbound SAD Entries > > [IPsecArch] Section 4.4.2 says that "For outbound > processing, > each SAD entry is pointed to by entries in the > SPD-S part of the > SPD cache". The document does not specify how > exactly this > "pointing" is done, since this is an > implementation detail that > does not have to be standardized. > > However, it is clear that the links between the > SPD cache and the > SAD have to be done correctly to ensure that > outbound packets are > sent over the right SA. Some implementations are > known to have > problems in this area. > > In particular, simply storing the (remote tunnel > header IP > address, remote SPI) pair in the SPD cache is not > sufficient, > since the pair does not always uniquely identify > a single SAD > entry. For instance, two hosts behind the same > NAT can > accidentally happen to choose the same SPI value. > The situation > can also occur when a host is assigned an IP > address previously > used by some other host, and the SAs associated > with the old host > have not yet been deleted by dead peer detection. > This may lead > to packets being sent over the wrong SA or, if > the key management > daemon ensures the pair is unique, denying the > creation of > otherwise valid SAs. > > Storing the remote tunnel header IP address in > the SPD cache may > also complicate the implementation of MOBIKE, > since the address > can change during the lifetime of the SA. >Thus, > we recommend > implementing the links between the SPD cache and > the SAD in a way > that does not require modification when the > tunnel header IP > address is updated by MOBIKE. For instance, in > the C programming > language, an ordinary pointer could be used. > I would remove the last sentence. Otherwise looks good... -mohan > Any comments? > > Best regards, > Pasi > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 02 22:01:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXVMT-0004v9-7p for mobike-archive@megatron.ietf.org; Wed, 02 Nov 2005 22:01:57 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26566 for ; Wed, 2 Nov 2005 22:01:33 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 5A069FB289; Thu, 3 Nov 2005 03:01:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E515EFB284; Thu, 3 Nov 2005 03:01:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 69863FB285; Thu, 3 Nov 2005 03:01:51 +0000 (UTC) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by machshav.com (Postfix) with SMTP id 7146FFB280 for ; Thu, 3 Nov 2005 03:01:50 +0000 (UTC) Received: (qmail 40584 invoked from network); 3 Nov 2005 03:01:49 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@67.123.81.122 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 3 Nov 2005 03:01:49 -0000 Message-ID: <006e01c5e022$f1f1c230$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "MOBIKE Mailing List" References: <17249.58627.276353.689034@fireball.kivinen.iki.fi><200511020939.jA29dda2054558@givry.rennes.enst-bretagne.fr> <17256.48342.106506.242828@fireball.kivinen.iki.fi> Date: Wed, 2 Nov 2005 19:01:53 -0800 MIME-Version: 1.0 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 Cc: Jari Arkko , Tero Kivinen Subject: [Mobike] Summary of Transport mode discussion (Was Re: MOBIKE WG Agenda for IETF-64, take 1) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Folks, This is the summary of the use cases for transport mode SA as far as i understand it. 1) SCTP : IKEv2 already supports proposing multiple addresses using TSi/TSr. SCTP seems to support a draft where one can add address dynamically. MOBIKE needs to be used for supporting that draft. 2) MIP6 : Related to the transport mode SA used in sending Binding updates. a) Adding Home address to the peer address set (don't know how RR would work for this). Mentioned in Francis draft. b) Another potential use case is using it for CoA authorization check where MOBIKE provides the RR check for the CoA in the BU (this is different from the one mentioned in Francis draft) 3) Issue 7: IP-IP tunnel with transport mode SA protection. MOBIKE support for upating the tunnel endpoints. 4) TCP connection : Similar to how IKEv2 NAT-T is supported, MOBIKE can also be supported. >From the discussion in the list, - it looks like (1) is not that heavily used and so may not justify adding support - 2.a and 2.b should at least be discussed in the MIP6 mailing list also - (3) may be a more common case that needs to be supported - 4 may never be implemented today and hence not attractive at all. Comments ? Does (3) make sense ? -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 03 01:41:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXYmh-0001F8-3x for mobike-archive@megatron.ietf.org; Thu, 03 Nov 2005 01:41:15 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10320 for ; Thu, 3 Nov 2005 01:40:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 02EB4FB28D; Thu, 3 Nov 2005 06:41:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 17AD2FB284; Thu, 3 Nov 2005 06:41:10 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7F74EFB289; Thu, 3 Nov 2005 06:41:08 +0000 (UTC) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by machshav.com (Postfix) with ESMTP id B6A14FB280 for ; Thu, 3 Nov 2005 06:41:07 +0000 (UTC) Received: from [192.168.1.47] (pool-71-106-130-244.lsanca.dsl-w.verizon.net [71.106.130.244]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id jA36eeM14961; Wed, 2 Nov 2005 22:40:40 -0800 (PST) Message-ID: <4369B0DB.7040106@isi.edu> Date: Wed, 02 Nov 2005 22:40:27 -0800 From: Joe Touch User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: Mohan Parthasarathy References: <17249.58627.276353.689034@fireball.kivinen.iki.fi><200511020939.jA29dda2054558@givry.rennes.enst-bretagne.fr> <17256.48342.106506.242828@fireball.kivinen.iki.fi> <006e01c5e022$f1f1c230$6501a8c0@adithya> In-Reply-To: <006e01c5e022$f1f1c230$6501a8c0@adithya> X-Enigmail-Version: 0.93.0.0 X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: Jari Arkko , MOBIKE Mailing List , Tero Kivinen Subject: Re: [Mobike] Summary of Transport mode discussion (Was Re: MOBIKE WG Agenda for IETF-64, take 1) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1274517958==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============1274517958== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB476ABCE91772238238DBD14" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB476ABCE91772238238DBD14 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Mohan Parthasarathy wrote: > Folks, >=20 > This is the summary of the use cases for transport mode SA as far as i = understand it. >=20 > 1) SCTP : IKEv2 already supports proposing multiple addresses using TS= i/TSr. > SCTP seems to support a draft where one can add addre= ss dynamically. > MOBIKE needs to be used for supporting that draft. >=20 > 2) MIP6 : Related to the transport mode SA used in sending Binding upda= tes. >=20 > a) Adding Home address to the peer address set (don't know how = RR would work > for this). Mentioned in Francis draft.=20 >=20 > b) Another potential use case is using it for CoA authorizatio= n check=20 > where MOBIKE provides the RR check for the CoA in the BU > (this is different from the one mentioned in Francis draft)= >=20 > 3) Issue 7: IP-IP tunnel with transport mode SA protection. MOBIKE supp= ort for upating > the tunnel endpoints. >=20 > 4) TCP connection : Similar to how IKEv2 NAT-T is supported, MOBIKE can= also be > supported. >=20 >>From the discussion in the list,=20 >=20 > - it looks like (1) is not that heavily used and so may not justify= adding support > - 2.a and 2.b should at least be discussed in the MIP6 mailing list= also > - (3) may be a more common case that needs to be supported > - 4 may never be implemented today and hence not attractive at all.= >=20 > Comments ? Does (3) make sense ? IMO, yes - see RFC 3884 ;-) Joe --------------enigB476ABCE91772238238DBD14 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.4.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDabDgE5f5cImnZrsRAg7nAJ9lubzhcQ7mKNuBA+icGN5Qk+7dnQCgy+Uu lHKUzZNGWmDFl7Nfl3Bjv1A= =+kVB -----END PGP SIGNATURE----- --------------enigB476ABCE91772238238DBD14-- --===============1274517958== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --===============1274517958==-- From mobike-bounces@machshav.com Thu Nov 03 04:54:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbo4-0006F3-I8 for mobike-archive@megatron.ietf.org; Thu, 03 Nov 2005 04:54:53 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18320 for ; Thu, 3 Nov 2005 04:54:30 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 24F47FB28A; Thu, 3 Nov 2005 09:54:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AC2DFFB282; Thu, 3 Nov 2005 09:54:47 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4B2C1FB284; Thu, 3 Nov 2005 09:54:45 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id DBF47FB27C for ; Thu, 3 Nov 2005 09:54:43 +0000 (UTC) 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 jA39sFe17652; Thu, 3 Nov 2005 10:54:15 +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 jA39sEd0061159; Thu, 3 Nov 2005 10:54:14 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511030954.jA39sEd0061159@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" In-reply-to: Your message of Wed, 02 Nov 2005 19:01:53 PST. <006e01c5e022$f1f1c230$6501a8c0@adithya> Date: Thu, 03 Nov 2005 10:54:14 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Jari Arkko , MOBIKE Mailing List , Tero Kivinen Subject: Re: [Mobike] Summary of Transport mode discussion (Was Re: MOBIKE WG Agenda for IETF-64, take 1) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: This is the summary of the use cases for transport mode SA as far as i understand it. 1) SCTP : IKEv2 already supports proposing multiple addresses using TSi/TSr. SCTP seems to support a draft where one can add address dynamically. MOBIKE needs to be used for supporting that draft. 2) MIP6 : Related to the transport mode SA used in sending Binding updates. a) Adding Home address to the peer address set (don't know how RR would work for this). Mentioned in Francis' draft. b) Another potential use case is using it for CoA authorization check where MOBIKE provides the RR check for the CoA in the BU (this is different from the one mentioned in Francis' draft) 3) Issue 7: IP-IP tunnel with transport mode SA protection. MOBIKE support for updating the tunnel endpoints. 4) TCP connection : Similar to how IKEv2 NAT-T is supported, MOBIKE can also be supported. >From the discussion in the list, - it looks like (1) is not that heavily used and so may not justify adding support => IMHO there is no support to add: we need only an "application note" explaining how to use IKEv2/2401bis/MOBIKE for SCTP. - 2.a and 2.b should at least be discussed in the MIP6 mailing list also - (3) may be a more common case that needs to be supported => in this case we need a text and a place to put it. - 4 may never be implemented today and hence not attractive at all. => I agree! Comments ? Does (3) make sense ? => it seems easy so as soon as someone has an interest in it... Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 03 04:58:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXbs2-0000A6-G2 for mobike-archive@megatron.ietf.org; Thu, 03 Nov 2005 04:58:58 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18570 for ; Thu, 3 Nov 2005 04:58:35 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 95B12FB28A; Thu, 3 Nov 2005 09:58:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 56353FB284; Thu, 3 Nov 2005 09:58:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EED0DFB289; Thu, 3 Nov 2005 09:58:51 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id C7B3CFB280 for ; Thu, 3 Nov 2005 09:58:50 +0000 (UTC) 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 jA39wbe17994; Thu, 3 Nov 2005 10:58:37 +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 jA39wbj2061308; Thu, 3 Nov 2005 10:58:38 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511030958.jA39wbj2061308@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Joe Touch In-reply-to: Your message of Wed, 02 Nov 2005 22:40:27 PST. <4369B0DB.7040106@isi.edu> Date: Thu, 03 Nov 2005 10:58:37 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Mohan Parthasarathy , Jari Arkko , Tero Kivinen Subject: Re: [Mobike] Summary of Transport mode discussion (Was Re: MOBIKE WG Agenda for IETF-64, take 1) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 his mail Joe Touch wrote: > Comments ? Does (3) make sense ? IMO, yes - see RFC 3884 ;-) => thanks, I was waiting for your opinion. Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 04 14:55:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EY7f7-0008Am-Tr for mobike-archive@megatron.ietf.org; Fri, 04 Nov 2005 14:55:45 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09620 for ; Fri, 4 Nov 2005 14:55:21 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 80D2EFB280; Fri, 4 Nov 2005 19:55:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 49F3CFB24F; Fri, 4 Nov 2005 19:55:37 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CE90CFB277; Fri, 4 Nov 2005 19:55:34 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8C164FB24F for ; Fri, 4 Nov 2005 19:55:33 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 826A089873 for ; Fri, 4 Nov 2005 21:55:27 +0200 (EET) Message-ID: <436BBC2D.4060108@piuha.net> Date: Fri, 04 Nov 2005 21:53:17 +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 Subject: [Mobike] Updated MOBIKE agenda X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 IETF-64 MOBIKE WG Agenda Time: WEDNESDAY, November 9, 2005 1300-1500 Afternoon Session I 1510-1610 Afternoon Session II Chairs: Jari Arkko Paul Hoffman PRELIMINARIES (10 minutes) Bluesheets Agenda Bash Document Status Open Issue Summary: http://www.vpnc.org/ietf-mobike/issues.html Presentations and agenda online at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64 Base Protocol (60 min -- Pasi Eronen) http://www.vpnc.org/ietf-org/draft-ietf-mobike-protocol-06.txt (to appear) - Discussion of remaining last call issue resolutions - We intend to close everything after Vancouver, edit, submit and send the draft to the ADs Design Draft (15 min -- Tero Kivinen) http://www.vpnc.org/ietf-org/draft-ietf-mobike-design-04.txt (to appear) - Discussion of remaining issues - Note: this is NOT for rehashing the decisions to change the protocol. This is about documenting the decisions and their rationale. Extensions and New Work Goal of this part of the meeting is to gain an understanding of what additional functionality is proposed, who does this benefit, and discuss whether the group feels the work is warranted. A brief technical summary of the approach should be included, but most of the time should be spent on the issue of whether this work is needed, and why/why not. MOBIKE Extensions for PF_KEY (10 min -- Hannes Tschofenig) http://www.tschofenig.com/drafts/draft-schilcher-mobike-pfkey-extension-01.txt Application Programming Interface to a Trigger Database for MOBIKE (10 min -- Hannes Tschofenig) http://www.tschofenig.com/drafts/draft-schilcher-mobike-trigger-api-02.txt Transport mode potential usage and issues (20 min -- Mohan or Francis TBC) http://www.machshav.com/pipermail/mobike/2005-November/001256.html (Please submit additional agenda requests, if any) Discussion of next steps (chairs) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Nov 05 11:14:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYQgG-0002QR-Iz for mobike-archive@megatron.ietf.org; Sat, 05 Nov 2005 11:14:12 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07838 for ; Sat, 5 Nov 2005 11:13:47 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 27F4FFB27D; Sat, 5 Nov 2005 16:14:08 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4A663FB24A; Sat, 5 Nov 2005 16:14:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D14B2FB24F; Sat, 5 Nov 2005 16:14:04 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3EC94FB249 for ; Sat, 5 Nov 2005 16:14:04 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3D9EC89871 for ; Sat, 5 Nov 2005 18:14:02 +0200 (EET) Message-ID: <436CD9CA.90608@piuha.net> Date: Sat, 05 Nov 2005 18:11:54 +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 Subject: [Mobike] protocol draft issues & process X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Folks, We still have open issues (marked "pending" on the issue list in the web). Please note that we need to decide what to do and get consensus before being able to move forward. So, please take a look at the open issues and post your suggestions and/or opinions. This is particularly important for the technical issues; for the editorial ones we can let Pasi handle them. We will also discuss the remaining issues in the meeting on Wednesday. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Nov 05 11:40:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYR5Z-0006pA-89 for mobike-archive@megatron.ietf.org; Sat, 05 Nov 2005 11:40:21 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08790 for ; Sat, 5 Nov 2005 11:39:55 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D2CF6FB27C; Sat, 5 Nov 2005 16:40:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4C4C6FB24F; Sat, 5 Nov 2005 16:40:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 35E35FB277; Sat, 5 Nov 2005 16:40:13 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 92439FB24A for ; Sat, 5 Nov 2005 16:40:12 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6069389871; Sat, 5 Nov 2005 18:40:11 +0200 (EET) Message-ID: <436CDFEB.8010703@piuha.net> Date: Sat, 05 Nov 2005 18:38:03 +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 References: <436BBC2D.4060108@piuha.net> In-Reply-To: <436BBC2D.4060108@piuha.net> Cc: Paul Hoffman Subject: [Mobike] Extensions discussions X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 We have discussed extensions on the list and will also discuss them in the meeting. The chairs would like to remind everyone that we are indeed discussing extensions - not redesigning the protocol to MOBIKE'. That is, there should be a specific new functionality that is offered by the extension, or something completely orthogonal to the protocol such as an API. In some cases MOBIKE protocol extensions may need to "reopen" some old issues, e.g., add new payloads or options to work around some limitation. But this is not an open season to reopen any issue; the basic design of MOBIKE stays as it is. The extension mechanism only apply for the new functionality case. Ability to fit well within the existing MOBIKE protocol framework is also a criteria when looking at potential extensions. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Nov 06 08:12:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYkK8-0002zp-5H for mobike-archive@megatron.ietf.org; Sun, 06 Nov 2005 08:12:42 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25830 for ; Sun, 6 Nov 2005 08:12:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 45307FB283; Sun, 6 Nov 2005 13:12:33 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 12305FB27C; Sun, 6 Nov 2005 13:12:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8C134FB27D; Sun, 6 Nov 2005 13:12:27 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 12AE8FB262 for ; Sun, 6 Nov 2005 13:12:26 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B896389871; Sun, 6 Nov 2005 15:12:12 +0200 (EET) Message-ID: <436E00AC.9020400@piuha.net> Date: Sun, 06 Nov 2005 15:10:04 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: marcelo bagnulo braun , Tero Kivinen Cc: MOBIKE Mailing List Subject: [Mobike] 54 - marcelo's editorial comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Hi all, I'm looking at the editorial issues and trying to see what exactly needs to be changed. First the ones that I think need a text change: >9. In section 4.4 i think that the Dead Path Detection indication should >be mentioned as one of the events that should lead to an address change >(perhaps a reference to section 4.9 would be useful too) along with > > Suggested change: o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working. => o An IKEv2 request has been re-transmitted several times, but no valid reply has been received. This suggests the current path is no longer working. See also Section 3.9. >10. In section 4.4, it is stated that: > > o It updates the IPsec SAs associated with this IKE_SA with the new > addresses (unless this was already done before sending the > request). > >As i understand it, the reason for updating the addresses here is >because the reply plays the role of a return routability check, right? >It would make sense to state so, for instance adding something like > > o It updates the IPsec SAs associated with this IKE_SA with the new > addresses (unless this was already done before sending the > request i.e. no return routability check was required, see 4.6). > > Ok. The current Section that this text is in is by the way 3.5. > 12. In section 4.6 it is stated that: > > By default, the return routability check SHOULD be done before > updating the IPsec SAs. In environments where the peer is expected > to be well-behaved (many corporate VPNs, for instance), or the > address can be verified by some other means (e.g., the address is > included in the peer's certificate), the return routability check MAY > be omitted or postponed until after the IPsec SAs have been updated. > >I am not sure that the example of the certificate is a good example... >what if the certificate is self signed? (i don't know if those are >supported) but in any case, i don't know how simple is that certificates >can prove address ownership (this depends of the checks performed by the >CA about address ownership) > Right. Suggested text change: s/the address is included in the peer's certificate/the address is included in a certificate given to the peer by a trusted authority/ Then the ones that do not appear to need a text change: >1. I think that in the Introduction, a comment about what is the >difference between mobike and what can be achieved with MIP is. I mean, >after reading the spec, the difference is clear, but stating it in the >introduction would make things easier to understand, especially since >the mobility scenario is described there. In particular, stating the it >is not a goal of mobike to make changes in the IP address transparent to >the upper layers (as stated in the charter for instance) would be useful. > The new introduction makes it quite clear that we are talking about tunnel mode, so the payload traffic & address effects appear to be obvious. We could of course describe what the differences to various other mobility and multihoming protocols are, but I'm not sure that text is easy to write and get consensus on. >6. In section 3.2. it would make clearer to me if the messages and >extensions introduced by mobike (i.e. the actual mobike protocol) where >highlighted somehow in the examples (so that it can be distinguished >from general IKE exchange) > > But I believe hiding this is actually useful for the overview, as people don't have to understand in detail the work split between IKEv2 and MOBIKE. And the information is very explicit in subsequent sections. >13. Later on, in this section 6.3 it is stated that: > > It should also be noted, as shown in [Bombing], that without ingress > filtering in the attacker's network, such attacks are already > possible simply by sending spoofed packets from the attacker to the > victim directly. > >But the whole point of this attack is to achieve amplification, right? I >mean, the story that an attacker using a 56kbps starts a download from a >heavy server and the redirects it towards a victim flooding it. The >point is that the attacker could only send 56kbps, while in this attack, >it could redirect the whole server flow through the victim. So, i don't >agree with this comment i would suggest to remove it. > > The current text already talks about amplification in the same paragraph. The point is that mere flooding without amplification would not be a problem. >14. In section 6.4 it is stated that: > > Attackers may spoof various indications from lower layers and the > network in an effort to confuse the peers about which addresses are > or are not working. For example, attackers may spoof link-layer > error messages in an effort to cause the parties to move their > traffic elsewhere or even to disconnect. Attackers may also spoof > information related to network attachments, router discovery, and > address assignments in an effort to make the parties believe they > have Internet connectivity when, in reality, they do not. > > This may cause use of non-preferred addresses or even denial-of- > service. > >As i understand this, all non verifiable indications should be used >merely as hints. When such a hint is received, the node should perform a >Dead Peer Detection, verifying securely, that the path is no longer >working. > > Well, this isn't strictly speaking true. There are non-verifiable indications that we HAVE to take into account. Or at the very least we know that for such an indication, DPD will surely fail too. For instance, if L2 decides that the link is down, IP and upper layers have way of reversing that decision even if decision was originally based on unverifiable indications. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Nov 06 10:54:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYmqX-0008DZ-SR for mobike-archive@megatron.ietf.org; Sun, 06 Nov 2005 10:54:20 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03730 for ; Sun, 6 Nov 2005 10:53:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DED76FB284; Sun, 6 Nov 2005 15:54:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A6419FB27D; Sun, 6 Nov 2005 15:54:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 37E99FB280; Sun, 6 Nov 2005 15:54:08 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 12BA5FB262 for ; Sun, 6 Nov 2005 15:54:07 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7C90689871; Sun, 6 Nov 2005 17:53:59 +0200 (EET) Message-ID: <436E2697.1090605@piuha.net> Date: Sun, 06 Nov 2005 17:51:51 +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 , Pasi Eronen , Tero Kivinen , Mohan Parthasarathy , marcelo bagnulo braun Subject: [Mobike] open issue status... X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Technical: ======= 68 - conformance requirements We have converged on text. But Mohan and Pasi are still discussing the rationale of why the requirements can be what they are. Waiting for Pasi and Mohan to post a note on whether additional clarification is needed. Action: Pasi & Mohan 60 - addresses from IKE_SA_INIT or IKE_SA_AUTH? Ongoing debate between Pasi and Tero. We need to discuss this in the meeting, but I will also try to get Pasi and Tero talk about it prior to the meeting. Action: Pasi and Tero and then to agree about this in the meeting. 58 - deleting addresses No changes to the behaviour, but current text was perhaps insufficiently clear. Someone to send text. Action: Unless someone else sends text, Pasi will write this. 56 - ingress filtering compatibility No changes to the design decision, i.e., we only support bidirectional paths. But again there's some debate about the limitation text's clarity in Section 1.2, the issue is simply the use of "address pair" vs. "path". There's a text proposal from Tero, but Pasi also said he knows how to formulate the text. Action: Pasi, others to agree or discuss on list 52 - security of address updates Leaning on to change nothing. We know address updates are less secure if NO_NAT_ALLOWED is used. As for the suggested heuristics - there's a worry that they are not bulletproof, and its simply better to test as IKEv2 does. Action: to agree about this in the meeting. 51 - SPI collisions This already happens in IKEv1, v2, and 2401bis. Uncertain if we should add anything about this in MOBIKE. Action: to agree about this in the meeting. Editorial: ====== 64 - editorial comments/questions from Stephane These questions have been mostly answered by Tero and Stephane seemed OK with the answer. The only remaining issue is whether the port 4500 behaviour needs to be explained in the draft. Waiting for Tero to post a suggestion about this or to say nothing is needed. Action: Tero 59 - editorial comments from Tero Mostly in -05 already, but some missing ones being discussed. Most solved, but Pasi to post final text suggestion to the list. Action: Tero 54 - editorial comments from marcelo Jari posted a proposal on what needs to be changed and how. Action: Marcelo to agree or discuss, Pasi to edit in. 46 - questions about ADDITIONAL_*_ADDRESSES Editorial since we're not revisiting an earlier decision to have full updates instead of diffs. Tero has a text clarification. OK? Action: Everyone to agree on Tero's suggestion or send better text. 45 - clarifications to security considerations After a discussion with Pasi, we are leaning towards not changing anything. Action: Mohan to agree or discuss. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Nov 06 12:14:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYo64-00084U-Bz for mobike-archive@megatron.ietf.org; Sun, 06 Nov 2005 12:14:24 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09033 for ; Sun, 6 Nov 2005 12:13:58 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 58E8BFB28D; Sun, 6 Nov 2005 17:14:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F2F4BFB262; Sun, 6 Nov 2005 17:14:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 62E28FB27D; Sun, 6 Nov 2005 17:14:14 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 6C8B9FB249 for ; Sun, 6 Nov 2005 17:14:13 +0000 (UTC) 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 jA6HE9na031831; Sun, 6 Nov 2005 19:14:12 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Nov 2005 19:13:56 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Nov 2005 19:13:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Nov 2005 19:13:53 +0200 Message-ID: Thread-Topic: [Mobike] Issue 59 (was: protocol draft status and moving forward) Thread-Index: AcXbwoiSimZWQiTcRYm4fK5qJF6J4gHMa+Tg From: To: X-OriginalArrivalTime: 06 Nov 2005 17:13:56.0807 (UTC) FILETIME=[7898C570:01C5E2F5] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59 (was: protocol draft status and moving forward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Tero Kivinen wrote: > Yes. People WILL misunderstand any text you put there. > > If you do not want to add the text twice, then add the picture, not > the text. Text is hard to parse when you are trying to implement > things, and then you end up interpreting every hidden meaning before > each word used. Ok, how about this? The Notify Message Type for this message is TBD-BY-IANA8. The notification data contains the IP addresses and ports from/to which the packet was sent. For IPv4, the notification data is 12 octets long and is defined as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Source IPv4 address ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Destination IPv4 address ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Source port ! Destination port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For IPv6, the notification data is 36 octets long and is defined as follows: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! Source IPv6 address ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ! Destination IPv6 address ! ! ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Source port ! Destination port ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Protocol ID and SPI Size fields are set to zero. (Note that I also re-arranged the fields: previously the order was src ip, src port, dst ip, dst port -- this is the same order they appear in the packet, and made the picture look nicer :-) > > Is mentioning IPv6 some more helpful for the reader..? > > Yes. I think it should be repeated also in the security considerations > section, just to tell where this protection can be used. Ok, I copied the "This feature is mainly intended for IPv6 and site-to-site VPN cases, where the administrators may know beforehand that NATs are not present." from 3.9 here. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Nov 06 13:24:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYpCG-0001jh-W5 for mobike-archive@megatron.ietf.org; Sun, 06 Nov 2005 13:24:53 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13094 for ; Sun, 6 Nov 2005 13:24:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2AA54FB28B; Sun, 6 Nov 2005 18:24:49 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6560CFB280; Sun, 6 Nov 2005 18:24:47 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 83F24FB282; Sun, 6 Nov 2005 18:24:45 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 596FCFB27D for ; Sun, 6 Nov 2005 18:24:44 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA6IM3YD005921; Sun, 6 Nov 2005 20:22:04 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Nov 2005 20:24:31 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 6 Nov 2005 20:24:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 6 Nov 2005 20:24:30 +0200 Message-ID: Thread-Topic: Issue 70: Non-SAD updates (was: 51 - spi collisions) Thread-Index: AcXftLQnFaB+/hwfSM+AFNR16DPoBQDSmAtg From: To: X-OriginalArrivalTime: 06 Nov 2005 18:24:31.0688 (UTC) FILETIME=[54C85480:01C5E2FF] Cc: mobike@machshav.com Subject: [Mobike] Issue 70: Non-SAD updates (was: 51 - spi collisions) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Francis Dupont wrote: > In your previous mail you wrote: > > > => I am afraid it is not enough: the link issue is not the only > > issue: if the SPD has no indication of what are the new endpoint > > addresses to use after an update, one cannot guarantee a new SA > > pair will be create using the right addresses. So an update > > should impact something somewhere in the SPD. > > Currently, it's beyond the scope of MOBIKE how the initial > contact is handled. Section 1.2 says: > > => I don't speak about the initial contact but the case where > there are many SPD entries requiring IPsec protection between > the two peers and only some of them have active IPsec SA pairs. > The peer addresses are somewhere in the SPD (this is highly > implementation dependent) and this information must be updated. (I created a new issue for this -- this is clearly different from issue 51 where the IPsec SAs already exist) In fact, 2401bis does not specify how the peer is determined when an outgoing packet triggers the creation of an SA. Section 4.4.3.4 writes: For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 and 2401bis do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. In particular, there can be several peers that are allowed to represent X (several different security gateways we could contact to establish an SA for the triggering packet). Presumably, the process is something like this: 1. Determine the right peer for the IPsec SA 2. Determine whether we have an active IKE_SA with this peer 3. If not, create an IKE_SA 4. Create the IPsec SA using CREATE_CHILD_SA exchange (possibly piggybacked in IKE_AUTH if we needed a new IKE_SA) The text I quoted above basically says steps 1 and 2 are beyond the scope of 2401bis (and IMHO also MOBIKE). Step 3 is discussed in Section 3.1 of MOBIKE draft (basically, finding out the peer addresses is beyond the scope), and step 4 should be very simple. > To come back to the main point, the peer addresses are dynamic and > included somewhere in the SPD or the PAD. The way this is supported > is very implementation dependent but the fact the information must be > updatable by MOBIKE is not at choice. Hmm.. as long as we agree that the inital contact (how to determine addresses when establishing the IKE_SA) is beyond the scope of MOBIKE (as Section 3.1 currently says), the question seems to be just about steps 1 and 2 above, right? But since 2401bis is not very light reading in this area, perhaps it would be a good idea to mention that depending on exactly how those unspecified steps are implemented, the implementation may be affected by MOBIKE. How about adding something like this to the "implementation considerations" appendix? A.2 Creating Outbound SAs When an outbound packet requires IPsec processing but no suitable SA exists, a new SA will be created. In this case, the host has to determine (1) who is the right peer for this SA, (2) whether the host already has an IKE_SA with this peer, and (3) if no IKE_SA exists, the IP address(es) of the peer for contacting it. Neither [IPsecArch] nor MOBIKE specifies how exactly these three steps are carried out. [IPsecArch] Section 4.4.3.4 says: For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 and 2401bis do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. In step 1, there may be more than one possible peer (e.g., several security gateways that are allowed to represent X). In step 3, the host may need to consult a directory such as DNS to determine the peer IP address(es). Some implementations are known to use a single IP address as an identifier for the right peer in steps 1 and 2 (in which case step 3 becomes trivial). This approach may complicate the implementation of MOBIKE; however, these implementation details are beyond the scope of this specification. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Nov 06 14:19:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYq3I-0005Wa-Cb for mobike-archive@megatron.ietf.org; Sun, 06 Nov 2005 14:19:40 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15758 for ; Sun, 6 Nov 2005 14:19:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E8758FB28E; Sun, 6 Nov 2005 19:19:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 82C41FB282; Sun, 6 Nov 2005 19:19:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9E985FB28A; Sun, 6 Nov 2005 19:19:35 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 47E94FB280 for ; Sun, 6 Nov 2005 19:19:34 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jA6JJSOY025910 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Nov 2005 21:19:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jA6JJRwM016934; Sun, 6 Nov 2005 21:19:27 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17262.22335.172013.305540@fireball.kivinen.iki.fi> Date: Sun, 6 Nov 2005 21:19:27 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <436E00AC.9020400@piuha.net> References: <436E00AC.9020400@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 13 min Cc: MOBIKE Mailing List Subject: [Mobike] 54 - marcelo's editorial comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > >I am not sure that the example of the certificate is a good example... > >what if the certificate is self signed? (i don't know if those are > >supported) but in any case, i don't know how simple is that certificates > >can prove address ownership (this depends of the checks performed by the > >CA about address ownership) > > > Right. Suggested text change: s/the address is > included in the peer's certificate/the address is > included in a certificate given to the peer by a trusted > authority/ The certificate is not normally given by trusted authority in the exchange, it is signed by the trusted authority and the other peer normally presents it. On the other hand, I do not see any problem with the original text. If certificate is not trusted by the peer, this will lead the peer to reject the authentication because there is no valid certificate, thus it does not matter what the certificate had. Of course you DO NOT use any information from the any other certificates than from the one that was used in the authentication. Also in some scenarios self-signed certificates with opportunistic approach could be used. If you want to change that text then "the address is inlcuded in the certificate used to authenticate the other peer". -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Nov 06 14:31:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqEI-0007zF-H0 for mobike-archive@megatron.ietf.org; Sun, 06 Nov 2005 14:31:02 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16277 for ; Sun, 6 Nov 2005 14:30:35 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 622FDFB28F; Sun, 6 Nov 2005 19:30:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 49E5FFB282; Sun, 6 Nov 2005 19:30:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A23F0FB28A; Sun, 6 Nov 2005 19:30:51 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 89482FB27D for ; Sun, 6 Nov 2005 19:30:50 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jA6JUnuq006646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Nov 2005 21:30:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jA6JUmsD001788; Sun, 6 Nov 2005 21:30:48 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17262.23016.795079.711821@fireball.kivinen.iki.fi> Date: Sun, 6 Nov 2005 21:30:48 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59 (was: protocol draft status and moving forward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > Tero Kivinen wrote: > > > Yes. People WILL misunderstand any text you put there. > > > > If you do not want to add the text twice, then add the picture, not > > the text. Text is hard to parse when you are trying to implement > > things, and then you end up interpreting every hidden meaning before > > each word used. > > Ok, how about this? That is fine. Even the picture (formula) I used would have been sufficient, but this is even better... > > > Is mentioning IPv6 some more helpful for the reader..? > > > > Yes. I think it should be repeated also in the security considerations > > section, just to tell where this protection can be used. > > Ok, I copied the "This feature is mainly intended for IPv6 and > site-to-site VPN cases, where the administrators may know > beforehand that NATs are not present." from 3.9 here. Good. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Nov 06 14:33:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EYqH7-0000G7-VC for mobike-archive@megatron.ietf.org; Sun, 06 Nov 2005 14:33:58 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16391 for ; Sun, 6 Nov 2005 14:33:31 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 220F1FB293; Sun, 6 Nov 2005 19:33:56 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CF717FB28E; Sun, 6 Nov 2005 19:33:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0FD5AFB28E; Sun, 6 Nov 2005 19:33:52 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 4E711FB282 for ; Sun, 6 Nov 2005 19:33:50 +0000 (UTC) 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 jA6JXg720882; Sun, 6 Nov 2005 20:33:42 +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 jA6JXgkr084016; Sun, 6 Nov 2005 20:33:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511061933.jA6JXgkr084016@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com In-reply-to: Your message of Sun, 06 Nov 2005 20:24:30 +0200. Date: Sun, 06 Nov 2005 20:33:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 70: Non-SAD updates (was: 51 - spi collisions) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > there are many SPD entries requiring IPsec protection between > the two peers and only some of them have active IPsec SA pairs. > The peer addresses are somewhere in the SPD (this is highly > implementation dependent) and this information must be updated. (I created a new issue for this -- this is clearly different from issue 51 where the IPsec SAs already exist) => I agree but the intersection between 41 and 70 is not void. In fact, 2401bis does not specify how the peer is determined when an outgoing packet triggers the creation of an SA. => yes, this is very implementation dependent so the specs should provide no details, but should say something as it is in fact needed... Presumably, the process is something like this: 1. Determine the right peer for the IPsec SA 2. Determine whether we have an active IKE_SA with this peer 3. If not, create an IKE_SA 4. Create the IPsec SA using CREATE_CHILD_SA exchange (possibly piggybacked in IKE_AUTH if we needed a new IKE_SA) => I agree. 1 is only for outgoing traffic in all implementations I know but it doesn't matter (if the policies are symmetrical the other peer will establish the SAs, if they are not this is an error). The text I quoted above basically says steps 1 and 2 are beyond the scope of 2401bis (and IMHO also MOBIKE). => I disagree about step 1 which is in the scope of 2401bis (only). Step 3 is discussed in Section 3.1 of MOBIKE draft (basically, finding out the peer addresses is beyond the scope), and step 4 should be very simple. => to find the peer addresses is IMHO a part of step 1. > To come back to the main point, the peer addresses are dynamic and > included somewhere in the SPD or the PAD. The way this is supported > is very implementation dependent but the fact the information must be > updatable by MOBIKE is not at choice. Hmm.. as long as we agree that the inital contact (how to determine addresses when establishing the IKE_SA) is beyond the scope of => oops. The term "initial contact" meant something else for me. MOBIKE (as Section 3.1 currently says), the question seems to be just about steps 1 and 2 above, right? But since 2401bis is not very light reading in this area, perhaps it would be a good idea to mention that depending on exactly how those unspecified steps are implemented, the implementation may be affected by MOBIKE. => yes, my concern is the step 1 has to be done so there are some infos somewhere which must be updated by MOBIKE. How about adding something like this to the "implementation considerations" appendix? => this is a way to solve the issue A.2 Creating Outbound SAs When an outbound packet requires IPsec processing but no suitable SA exists, a new SA will be created. In this case, the host has => s/will/shall/ ? BTW it is more a SA pair but I agree the text is more readable as it is. to determine (1) who is the right peer for this SA, (2) whether the host already has an IKE_SA with this peer, and (3) if no IKE_SA exists, the IP address(es) of the peer for contacting it. Neither [IPsecArch] nor MOBIKE specifies how exactly these three steps are carried out. [IPsecArch] Section 4.4.3.4 says: For example, assume that IKE A receives an outbound packet destined for IP address X, a host served by a security gateway. RFC 2401 and 2401bis do not specify how A determines the address of the IKE peer serving X. However, any peer contacted by A as the presumed representative for X must be registered in the PAD in order to allow the IKE exchange to be authenticated. Moreover, when the authenticated peer asserts that it represents X in its traffic selector exchange, the PAD will be consulted to determine if the peer in question is authorized to represent X. In step 1, there may be more than one possible peer (e.g., several security gateways that are allowed to represent X). In step 3, the host may need to consult a directory such as DNS to determine the peer IP address(es). => the last sentence is loose enough to make MIPv6 to work (:-)! Some implementations are known to use a single IP address as an identifier for the right peer in steps 1 and 2 (in which case step 3 becomes trivial). This approach may complicate the implementation of MOBIKE; however, these implementation details => IMHO here we have to explain why, i.e., this IP address has to be updated when it changes. are beyond the scope of this specification. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 16:17:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEMU-000269-Sn for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 16:17:07 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08365 for ; Mon, 7 Nov 2005 16:16:39 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id B4DCCFB27F; Mon, 7 Nov 2005 21:17:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 84EC9FB24F; Mon, 7 Nov 2005 21:17:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9669DFB262; Mon, 7 Nov 2005 21:17:00 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 92278FB249 for ; Mon, 7 Nov 2005 21:16:59 +0000 (UTC) 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 jA7LECP7025468; Mon, 7 Nov 2005 23:14:18 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:16:10 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:16:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Nov 2005 23:16:06 +0200 Message-ID: Thread-Topic: [Mobike] 54 - marcelo's editorial comments Thread-Index: AcXi0+CWjF4GGOXmS9yIUwYiPqqxOwBDHVjA From: To: X-OriginalArrivalTime: 07 Nov 2005 21:16:09.0741 (UTC) FILETIME=[795043D0:01C5E3E0] Subject: Re: [Mobike] 54 - marcelo's editorial comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > > 9. In section 4.4 i think that the Dead Path Detection > > indication should be mentioned as one of the events that should > > lead to an address change (perhaps a reference to section 4.9 > > would be useful too) along with > > Suggested change: > > o An IKEv2 request has been re-transmitted several times, but no > valid reply has been received. This suggests the > current path is no longer working. > > => > > o An IKEv2 request has been re-transmitted several times, but no > valid reply has been received. This suggests the > current path is no longer working. See also Section 3.9. Section 3.9 is about NAT prohibition, and doesn't need to be referenced here?? In -04, Section 4.9 was about path testing, but that's not really very closely related either. IMHO Marcelo's original comment is already handled here: failing DPD == "IKEv2 request has been re-transmitted several times, but no valid reply has been received". My proposal: no text change. > > 10. In section 4.4, it is stated that: > > > > o It updates the IPsec SAs associated with this IKE_SA > > with the new addresses (unless this was already done > > before sending the request). > > > > As i understand it, the reason for updating the addresses here > > is because the reply plays the role of a return routability > > check, right? It would make sense to state so, for instance > > adding something like > > > > o It updates the IPsec SAs associated with this IKE_SA > > with the new addresses (unless this was already done > > before sending the request i.e. no return routability > > check was required, see 4.6). > > Ok. The current Section that this text is in is by the way 3.5. The pointer to 4.6/3.5 is IMHO confusing; the real pointer is to the step "Updates the IPsec SAs..." step earlier in this section. How about this? o It updates the IPsec SAs associated with this IKE_SA with the new addresses (unless this was already done earlier before sending the request; this is the case when no return routability check was required). > > I am not sure that the example of the certificate is a good > > example... what if the certificate is self signed? (i don't know > > if those are supported) but in any case, i don't know how simple > > is that certificates can prove address ownership (this depends > > of the checks performed by the CA about address ownership) > > Right. Suggested text change: s/the address is included in the > peer's certificate/the address is included in a certificate given > to the peer by a trusted authority/ My proposal: [..], or the address can be verified by some other means (e.g., a certificate issued by an authority trusted for this purpose), [...] Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 16:54:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZEwF-0001cz-Ap for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 16:54:05 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10393 for ; Mon, 7 Nov 2005 16:53:36 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 15F2BFB24F; Mon, 7 Nov 2005 21:54:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CA5C7FB27C; Mon, 7 Nov 2005 21:53:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B00A5FB27C; Mon, 7 Nov 2005 21:53:56 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id E0F54FB249 for ; Mon, 7 Nov 2005 21:53:55 +0000 (UTC) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA7LE6IB031676; Mon, 7 Nov 2005 23:14:07 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:18:01 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:18:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Nov 2005 23:17:58 +0200 Message-ID: Thread-Topic: [Mobike] Issue 56 (was: protocol draft status and moving forward) Thread-Index: AcXbnzIzjhcVKyxXSaOjhg1oXJohjgIQX0QQ From: To: , X-OriginalArrivalTime: 07 Nov 2005 21:18:00.0682 (UTC) FILETIME=[BB7084A0:01C5E3E0] Subject: Re: [Mobike] Issue 56 (was: protocol draft status and moving forward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Tero Kivinen wrote: > but I would change that to: > > ---------------------------------------------------------------------- > MOBIKE follows the IKEv2 practice where a response message > is sent to the same address and port from which the request > was received. This implies that MOBIKE does not work over > unidirectional address pairs. > ---------------------------------------------------------------------- > > i.e change "unidirectional paths" to "unidirectional address > pairs", as we do not really care about paths but address pairs. > > MOBIKE will work perfectly if even if there is 2 unidirectional > paths (if we use the definition of path that includes the route of > the packet), which form one bidirectional address pair for MOBIKE > to use... Hmm, you're right... but it's not really the address pair that has the direction. How about this? This implies that MOBIKE does not work over address pairs that provide only unidirectional connectivity. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 16:57:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZF01-0002Od-Ka for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 16:57:57 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10571 for ; Mon, 7 Nov 2005 16:57:32 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C4EF9FB27F; Mon, 7 Nov 2005 21:57:56 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E0658FB24F; Mon, 7 Nov 2005 21:57:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 059EBFB27C; Mon, 7 Nov 2005 21:57:51 +0000 (UTC) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by machshav.com (Postfix) with ESMTP id 456E7FB249 for ; Mon, 7 Nov 2005 21:57:50 +0000 (UTC) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 07 Nov 2005 13:57:49 -0800 X-IronPort-AV: i="3.97,301,1125903600"; d="scan'208"; a="361950140:sNHT786839722" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jA7LvBnt002852; Mon, 7 Nov 2005 13:57:47 -0800 (PST) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Nov 2005 16:57:32 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Nov 2005 16:56:34 -0500 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD6CA0BFF@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] Issue 64 - Stephane Beaulieu's commentsondraft-mobike-protocol-04.txt Thread-Index: AcXTvLXwciLk+hgBQ2aCm1S4TQs5jQALgkpQA/2DVNAAAVEmwA== From: "Stephane Beaulieu (stephane)" To: X-OriginalArrivalTime: 07 Nov 2005 21:57:32.0315 (UTC) FILETIME=[410AFEB0:01C5E3E6] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 64 - Stephane Beaulieu's commentsondraft-mobike-protocol-04.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Sounds good. Stephane. > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Monday, November 07, 2005 4:19 PM > To: Stephane Beaulieu (stephane) > Cc: mobike@machshav.com > Subject: RE: [Mobike] Issue 64 - Stephane Beaulieu's > commentsondraft-mobike-protocol-04.txt > > Stephane Beaulieu wrote: > > > > Section 4.2 > > > > > > > > I don't understand why we need to switch to port 4500 even if > > > > there is no NAT in the path. Can someone explain this > to me? Or > > > > better yet, explain it in the draft? > > > > > I raised this question also earlier, and the answer was: > In case we > > > later move to the path that has a NAT box between, and we need to > > > enable NAT-T, then we must be on the port 4500 before we enable > > > NAT-T. To avoid hassle to do the changing of the port at > that time, > > > we do it in the beginning. It does not hurt at all to > move to port > > > 4500 immediately, if both ends support NAT-T, and it will make > > > enabling NAT-T very simple when we later in the > UPDATE_SA_ADDRESSES > > > notice there is NAT between us. > > > > [SB] Ah. That makes sense. Perhaps the reasoning here should be > > documented as well. > > The text currently says: > > To simplify things, implementations that support both this > specification and NAT Traversal MUST change to port 4500 if the > correspondent also supports both, even if no NAT was detected > between them (this way, there is no need to change the ports > later). > > But perhaps the last part could be slightly rephrased. > How about this? > > "(this way, there is no need to change the ports later if a > a NAT is detected on some other path)" > > Best regards, > Pasi > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 17:17:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFIc-0006FZ-7T for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 17:17:10 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11579 for ; Mon, 7 Nov 2005 17:16:44 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6B490FB281; Mon, 7 Nov 2005 22:17:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 16E50FB24F; Mon, 7 Nov 2005 22:17:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EE589FB27C; Mon, 7 Nov 2005 22:17:01 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 0C427FB249 for ; Mon, 7 Nov 2005 22:17:01 +0000 (UTC) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA7LGuGJ027437; Mon, 7 Nov 2005 23:16:59 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:19:00 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:19:00 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Nov 2005 23:18:58 +0200 Message-ID: Thread-Topic: [Mobike] Issue 64 - Stephane Beaulieu's commentsondraft-mobike-protocol-04.txt Thread-Index: AcXTvLXwciLk+hgBQ2aCm1S4TQs5jQALgkpQA/2DVNA= From: To: X-OriginalArrivalTime: 07 Nov 2005 21:19:00.0223 (UTC) FILETIME=[DEEDC0F0:01C5E3E0] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 64 - Stephane Beaulieu's commentsondraft-mobike-protocol-04.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Stephane Beaulieu wrote: > > > Section 4.2 > > > > > > I don't understand why we need to switch to port 4500 even > > > if there is no NAT in the path. Can someone explain this > > > to me? Or better yet, explain it in the draft? > > > I raised this question also earlier, and the answer was: In case > > we later move to the path that has a NAT box between, and we > > need to enable NAT-T, then we must be on the port 4500 before we > > enable NAT-T. To avoid hassle to do the changing of the port at > > that time, we do it in the beginning. It does not hurt at all to > > move to port 4500 immediately, if both ends support NAT-T, and > > it will make enabling NAT-T very simple when we later in the > > UPDATE_SA_ADDRESSES notice there is NAT between us. > > [SB] Ah. That makes sense. Perhaps the reasoning here should be > documented as well. The text currently says: To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them (this way, there is no need to change the ports later). But perhaps the last part could be slightly rephrased. How about this? "(this way, there is no need to change the ports later if a a NAT is detected on some other path)" Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 17:19:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFKj-0006zZ-0h for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 17:19:21 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11684 for ; Mon, 7 Nov 2005 17:18:55 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 582A1FB281; Mon, 7 Nov 2005 22:19:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 34F60FB27D; Mon, 7 Nov 2005 22:19:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 239A8FB27F; Mon, 7 Nov 2005 22:19:14 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id E383AFB27C for ; Mon, 7 Nov 2005 22:19:12 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA7LEVHM025712; Mon, 7 Nov 2005 23:14:32 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:16:55 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 7 Nov 2005 23:16:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 7 Nov 2005 23:16:52 +0200 Message-ID: Thread-Topic: Issue 70: Non-SAD updates (was: 51 - spi collisions) Thread-Index: AcXjCQz7TMCDqFkSTe2zBjRFB5SG7wA13oTw From: To: X-OriginalArrivalTime: 07 Nov 2005 21:16:54.0982 (UTC) FILETIME=[94477E60:01C5E3E0] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 70: Non-SAD updates (was: 51 - spi collisions) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Francis Dupont wrote: > Presumably, the process is something like this: > > 1. Determine the right peer for the IPsec SA > 2. Determine whether we have an active IKE_SA with this peer > 3. If not, create an IKE_SA > 4. Create the IPsec SA using CREATE_CHILD_SA exchange > (possibly piggybacked in IKE_AUTH if we needed a new IKE_SA) > > => I agree. 1 is only for outgoing traffic in all implementations > I know but it doesn't matter (if the policies are symmetrical the > other peer will establish the SAs, if they are not this is an error). > > The text I quoted above basically says steps 1 and 2 are beyond > the scope of 2401bis (and IMHO also MOBIKE). > > => I disagree about step 1 which is in the scope of 2401bis (only). > > Step 3 is discussed in Section 3.1 of MOBIKE draft (basically, > finding out the peer addresses is beyond the scope), and step 4 > should be very simple. > > => to find the peer addresses is IMHO a part of step 1. IMHO at least some parts of step 1 are beyond the scope of 2401bis (e.g. Section 4.4.3.4 says "RFC 2401 and 2401bis do not specify how A determines the address of the IKE peer serving X.") On the other hand, 2401bis does not specify that exactly these four steps must be done in this order, so it's a matter of taste how you want to describe it... > Some implementations are known to use a single IP address as an > identifier for the right peer in steps 1 and 2 (in which case > step 3 becomes trivial). This approach may complicate the > implementation of MOBIKE; however, these implementation details > > => IMHO here we have to explain why, i.e., this IP address has to > be updated when it changes. Hmm... actually the text I proposed was not quite right. Using a single IP address as the sole identifier for the right peer simply doesn't work correctly, since an IP address does not uniquely identify a peer (for similar reasons as in issue 51). More likely, it has to also take into account information in the PAD etc.. How about rephrasing the last paragraph to something like this? When performing these steps, implementations may use information contained in the SPD, the PAD, and possibly some other implementation-specific databases. Regardless of how exactly the steps are implemented, it is important to remember that IP addresses can change, and that an IP address alone does not always uniquely identify a single IKE peer (for the same reasons as why the combination of the remote IP address and SPI does not uniquely identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 and 2 it may be easier to identify the "right peer" using its authenticated identity instead of its current IP address. However, these implementation details are beyond the scope of this specification. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 17:42:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZFgi-0004ue-1h for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 17:42:04 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13920 for ; Mon, 7 Nov 2005 17:41:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EBC5EFB283; Mon, 7 Nov 2005 22:42:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 37CC6FB280; Mon, 7 Nov 2005 22:41:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EF0D6FB281; Mon, 7 Nov 2005 22:41:56 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 997FBFB27D for ; Mon, 7 Nov 2005 22:41:55 +0000 (UTC) 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 jA7MfkM15473; Mon, 7 Nov 2005 23:41:46 +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 jA7Mfki6090442; Mon, 7 Nov 2005 23:41:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511072241.jA7Mfki6090442@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com In-reply-to: Your message of Mon, 07 Nov 2005 23:16:52 +0200. Date: Mon, 07 Nov 2005 23:41:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 70: Non-SAD updates (was: 51 - spi collisions) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: Hmm... actually the text I proposed was not quite right. Using a single IP address as the sole identifier for the right peer simply doesn't work correctly, since an IP address does not uniquely identify a peer (for similar reasons as in issue 51). More likely, it has to also take into account information in the PAD etc.. => yes, this is a known issue for ipsec-tools... How about rephrasing the last paragraph to something like this? When performing these steps, implementations may use information contained in the SPD, the PAD, and possibly some other implementation-specific databases. Regardless of how exactly the steps are implemented, it is important to remember that IP addresses can change, and that an IP address alone does not always uniquely identify a single IKE peer (for the same reasons as why the combination of the remote IP address and SPI does not uniquely identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 and 2 it may be easier to identify the "right peer" using its authenticated identity instead of its current IP address. However, these implementation details are beyond the scope of this specification. => the sentence about the authenticated identity is IMHO only for positive step 2 but I think the text is enough detailed. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 18:06:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZG3s-0003Hj-Le for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 18:06:00 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15818 for ; Mon, 7 Nov 2005 18:05:33 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6AEA8FB28F; Mon, 7 Nov 2005 23:05:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B2254FB283; Mon, 7 Nov 2005 23:05:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E68B9FB28A; Mon, 7 Nov 2005 23:05:54 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 944E5FB282 for ; Mon, 7 Nov 2005 23:05:53 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jA7N5p8B003546 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Nov 2005 01:05:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jA7N5pJn025845; Tue, 8 Nov 2005 01:05:51 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17263.56782.984566.212920@fireball.kivinen.iki.fi> Date: Tue, 8 Nov 2005 01:05:50 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 56 (was: protocol draft status and moving forward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > Hmm, you're right... but it's not really the address pair that has > the direction. How about this? > > This implies that MOBIKE does not work over address pairs > that provide only unidirectional connectivity. That is fine by me. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 19:32:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHPu-0007Aw-Ev for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 19:32:52 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26569 for ; Mon, 7 Nov 2005 19:32:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 8F5E0FB27F; Tue, 8 Nov 2005 00:32:48 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1ED3CFB24F; Tue, 8 Nov 2005 00:32:45 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 67AE2FB262; Tue, 8 Nov 2005 00:32:43 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 7AA83FB249 for ; Tue, 8 Nov 2005 00:32:42 +0000 (UTC) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA80SJfD006542; Tue, 8 Nov 2005 02:28:25 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 02:32:40 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 02:32:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Nov 2005 02:32:34 +0200 Message-ID: Thread-Topic: [Mobike] Issue 46 (was: protocol draft status and movingforward) Thread-Index: AcXeozMDOZNqGvsCQQiVG3rxRO1XyQFWJ62g From: To: , X-OriginalArrivalTime: 08 Nov 2005 00:32:39.0354 (UTC) FILETIME=[EC7871A0:01C5E3FB] Subject: Re: [Mobike] Issue 46 (was: protocol draft status and movingforward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > Hmm...part of the problem is that NO_ADDITIONAL_ADDRESS is really > DELETE_ADDITIONAL_ADDRESS. But we don't want to use the word > DELETE because we provide only replace semantics. It may sound > trivial, but what exact action (delete the addresses contained in > the previous ADD_ADDITIONAL_IP*) needs to be performed is not > explained anywhere (not in 05). The defintion in 4.3 contains : > > The NO_ADDITIONAL_ADDRESSES notification can be included in an > INFORMATIONAL exchange request message to indicate that the > exchange initiator does not have addresses beyond the one used > in the exchange (see Section 3.6 for more detailed description). > > Section 3.6 only contains "update the peer addresses ...". Perhaps > the definition should be appended with.. "The exchange initiator > sends this notification to delete the addresses sent in the > earlier ADD_ADDITIONAL_ADDRESS notification". The draft does not have an ADD_ADDITIONAL_ADDRESS notification; the new list always replaces the old information. But here's a yet another attempt to rewrite the beginning of Section 3.6: As described in Section 3.4, both the initiator and responder can send a list of additional addresses in the IKE_AUTH exchange. This information can be updated by sending an INFORMATIONAL exchange request message that contains either one or more ADDITIONAL_IP4/ 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has only a single IP address, it is placed in the IP header, and the message contains the NO_ADDITIONAL_ADDRESSES notification. If the exchange initiator has several addresses, one of them is placed in the IP header, and the rest in ADDITIONAL_IP4/6_ADDRESS notifications. The new list of addresses replaces the old information (in other words, there are no separate add/delete operations; instead, the complete list is sent every time these notifications are used). Does this look better? (BTW, it seems issue 58 is essentially a duplicate of this one) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 19:33:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHQJ-0007FY-HV for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 19:33:17 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26597 for ; Mon, 7 Nov 2005 19:32:48 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4FFBDFB282; Tue, 8 Nov 2005 00:33:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 20AFEFB262; Tue, 8 Nov 2005 00:33:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 96FA2FB27D; Tue, 8 Nov 2005 00:33:09 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id ABD35FB249 for ; Tue, 8 Nov 2005 00:33:08 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA80UR9e030083; Tue, 8 Nov 2005 02:30:29 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 02:33:07 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 02:33:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Nov 2005 02:33:03 +0200 Message-ID: Thread-Topic: issue 45 - clarifications to security considerations Thread-Index: AcXYjRzGu9n7MYNISsObJgcWc2NpygLbtT1A From: To: X-OriginalArrivalTime: 08 Nov 2005 00:33:05.0806 (UTC) FILETIME=[FC3CB2E0:01C5E3FB] Cc: mobike@machshav.com Subject: Re: [Mobike] issue 45 - clarifications to security considerations X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > Here's another attempt: > > Such an attack could also be defeated by use of negative > acknowledgements, such as TCP RST and ICMP errors. However, in > our case the victim lacks a valid SA and, as a result, is > incapable providing any other negative acknowledgements than > ICMP errors. Such errors may be filtered in many networks, and > has some denial-of-service issues itself. Hmm.. here's my take (add this to the end of the section): The duration of the attack can also be limited if the victim reports the unwanted traffic to the originating IPsec tunnel endpoint using ICMP error messages or INVALID_SPI notifications. As described in [IKEv2] Section 2.21, this SHOULD trigger a liveness test, which also doubles as a return routability check if the COOKIE2 notification is included. And while we're at it, we could also make the 3rd paragraph (the one referring to [Aura02] and transport layer acks) more accurate: If the attack is launched by an outsider, the traffic flow would normally stop soon due to the lack of responses (such as transport layer acknowledgements). However, if the original recipient of the flow is malicious, it could maintain the traffic flow for an extended period of time, since it often would be able to send the required acknowledgements (see [Aura02] for more discussion). Does this look ok? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 19:36:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHTW-00088J-Gl for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 19:36:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26749 for ; Mon, 7 Nov 2005 19:36:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 6B9FCFB282; Tue, 8 Nov 2005 00:36:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8EA09FB27D; Tue, 8 Nov 2005 00:36:29 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F2610FB27F; Tue, 8 Nov 2005 00:36:27 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 52DDCFB27C for ; Tue, 8 Nov 2005 00:36:27 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0858D89863; Tue, 8 Nov 2005 02:36:22 +0200 (EET) Message-ID: <436FE476.3060403@piuha.net> Date: Tue, 08 Nov 2005 01:34:14 +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: Cc: mobike@machshav.com Subject: Re: [Mobike] issue 45 - clarifications to security considerations X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 >Hmm.. here's my take (add this to the end of the section): > > The duration of the attack can also be limited if the victim > reports the unwanted traffic to the originating IPsec tunnel > endpoint using ICMP error messages or INVALID_SPI > notifications. As described in [IKEv2] Section 2.21, this SHOULD > trigger a liveness test, which also doubles as a return > routability check if the COOKIE2 notification is included. > >And while we're at it, we could also make the 3rd paragraph >(the one referring to [Aura02] and transport layer acks) >more accurate: > > If the attack is launched by an outsider, the traffic flow would > normally stop soon due to the lack of responses (such as > transport layer acknowledgements). However, if the original > recipient of the flow is malicious, it could maintain the traffic > flow for an extended period of time, since it often would be able > to send the required acknowledgements (see [Aura02] for more > discussion). > >Does this look ok? > > Yes. Thanks. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 20:09:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZHzf-00081X-0T for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 20:09:49 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28235 for ; Mon, 7 Nov 2005 20:09:19 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 73302FB280; Tue, 8 Nov 2005 01:09:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4A574FB27C; Tue, 8 Nov 2005 01:09:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 10733FB27D; Tue, 8 Nov 2005 01:09:38 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id C506AFB24F for ; Tue, 8 Nov 2005 01:09:35 +0000 (UTC) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA815JxY032231 for ; Tue, 8 Nov 2005 03:05:19 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 03:09:34 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 03:09:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Nov 2005 03:08:49 +0200 Message-ID: Thread-Topic: Intermediate snapshot of protocol document Thread-Index: AcXkAPn0F7ZSPonmRJipV7QHl/iCjQ== From: To: X-OriginalArrivalTime: 08 Nov 2005 01:09:33.0722 (UTC) FILETIME=[14562FA0:01C5E401] Subject: [Mobike] Intermediate snapshot of protocol document X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Hi everyone, I've created an intermediate snapshot "06.a" of the protocol document. This snapshot is totally unofficial, but I hope it helps in keeping track of which issues we still need to discuss. This contains new text about the following issues (in some cases, we perhaps haven't fully agreed on the text yet but at least there's a proposal): 45 Clarifications to security considerations 46 Questions about additional addresses 51 SPI collisions 54 Editorial comments from Marcelo 56 Ingress filtering compatibility 58 Deleting addresses 59 Editorial comments from Tero 64 Editorial comments and questions from Stephane 70 Non-SAD updates 72 More editorial comments from Tero The snapshot and diff from -05: http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-06.a.txt http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-06.a-from-05.ht ml Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 20:51:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIdo-0001Yt-TK for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 20:51:17 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00278 for ; Mon, 7 Nov 2005 20:50:49 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3FD3AFB280; Tue, 8 Nov 2005 01:51:15 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7D489FB27C; Tue, 8 Nov 2005 01:51:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2CF29FB27D; Tue, 8 Nov 2005 01:51:10 +0000 (UTC) Received: from web80602.mail.yahoo.com (web80602.mail.yahoo.com [66.218.79.91]) by machshav.com (Postfix) with SMTP id 4FEFFFB24F for ; Tue, 8 Nov 2005 01:51:09 +0000 (UTC) Received: (qmail 41529 invoked by uid 60001); 8 Nov 2005 01:51:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vjsAckCSYSr2QwlCWnz6hRFi1yTgQbpujplz1c3EZnaGDbJGFGADUVyQN+fzeT4XZf4StVj6ANsOAPKkhlOFlStg+DOkHVyyy44CEO2oN2Gmq6sope1+Tr090TLM98qnXxzTad+pnYDB+jrPK3b/nRe7g4K/0w6sXIxn7p0/d8k= ; Message-ID: <20051108015108.41527.qmail@web80602.mail.yahoo.com> Received: from [192.100.104.18] by web80602.mail.yahoo.com via HTTP; Mon, 07 Nov 2005 17:51:08 PST Date: Mon, 7 Nov 2005 17:51:08 -0800 (PST) From: Mohan Parthasarathy To: Pasi.Eronen@nokia.com, mobike@machshav.com In-Reply-To: MIME-Version: 1.0 Subject: Re: [Mobike] Issue 46 (was: protocol draft status and movingforward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > > > Hmm...part of the problem is that > NO_ADDITIONAL_ADDRESS is really > > DELETE_ADDITIONAL_ADDRESS. But we don't want to > use the word > > DELETE because we provide only replace semantics. > It may sound > > trivial, but what exact action (delete the > addresses contained in > > the previous ADD_ADDITIONAL_IP*) needs to be > performed is not > > explained anywhere (not in 05). The defintion in > 4.3 contains : > > > > The NO_ADDITIONAL_ADDRESSES notification can be > included in an > > INFORMATIONAL exchange request message to > indicate that the > > exchange initiator does not have addresses > beyond the one used > > in the exchange (see Section 3.6 for more > detailed description). > > > > Section 3.6 only contains "update the peer > addresses ...". Perhaps > > the definition should be appended with.. "The > exchange initiator > > sends this notification to delete the addresses > sent in the > > earlier ADD_ADDITIONAL_ADDRESS notification". > > The draft does not have an ADD_ADDITIONAL_ADDRESS > notification; > the new list always replaces the old information. > > But here's a yet another attempt to rewrite the > beginning of > Section 3.6: > > As described in Section 3.4, both the initiator > and responder can > send a list of additional addresses in the > IKE_AUTH exchange. This > information can be updated by sending an > INFORMATIONAL exchange > request message that contains either one or more > ADDITIONAL_IP4/ > 6_ADDRESS notifications or the > NO_ADDITIONAL_ADDRESSES notification. > > If the exchange initiator has only a single IP > address, it is placed > in the IP header, and the message contains the > NO_ADDITIONAL_ADDRESSES notification. If the > If there is only one address, why do you need to explicitly tell your peer that you have NO_ADDITIONAL_ADDRESS ? Isn't NO_ADDITIONAL_ADDRESS needed only when oyu have sent ADDITIONAL_ADDRESS previously ? > exchange initiator has > several addresses, one of them is placed in the > IP header, and the > rest in ADDITIONAL_IP4/6_ADDRESS notifications. > The new list of > addresses replaces the old information (in other > words, there are no > separate add/delete operations; instead, the > complete list is sent > every time these notifications are used). > > Does this look better? > Please see my comments above. I think the only time we send NO_ADDITIONAL_ADDRESS is when you have sent ADDITIONAL_IP before. Otherwise, i don't know why we need one. thanks mohan > (BTW, it seems issue 58 is essentially a duplicate > of this one) > > Best regards, > Pasi > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 20:52:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIf1-0002Va-64 for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 20:52:31 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00390 for ; Mon, 7 Nov 2005 20:52:01 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3CD14FB27F; Tue, 8 Nov 2005 01:52:27 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 16DC2FB27D; Tue, 8 Nov 2005 01:52:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DC8C8FB27F; Tue, 8 Nov 2005 01:52:20 +0000 (UTC) Received: from web80607.mail.yahoo.com (web80607.mail.yahoo.com [66.94.235.69]) by machshav.com (Postfix) with SMTP id F000CFB24F for ; Tue, 8 Nov 2005 01:52:18 +0000 (UTC) Received: (qmail 23325 invoked by uid 60001); 8 Nov 2005 01:52:18 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=FXQvS5qgTo4uWCAGcYKIUJF2g2lcvr06zS5rPJ8GoSob3RZmdmqZrFSnuymulOHRdRi+Z27OF2+nN7wSQchyjKwWO2xtNfEyX7tb/vt/AyCpSINcrkOAS7+7ApwAOWsXzJYCZBgz7N8GfNbda6lYSptqV2OEJc7T6842WAT/AtY= ; Message-ID: <20051108015218.23323.qmail@web80607.mail.yahoo.com> Received: from [192.100.104.18] by web80607.mail.yahoo.com via HTTP; Mon, 07 Nov 2005 17:52:18 PST Date: Mon, 7 Nov 2005 17:52:18 -0800 (PST) From: Mohan Parthasarathy To: Pasi.Eronen@nokia.com, jari.arkko@piuha.net In-Reply-To: MIME-Version: 1.0 Cc: mobike@machshav.com Subject: Re: [Mobike] issue 45 - clarifications to security considerations X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 sounds good to me. -mohan --- Pasi.Eronen@nokia.com wrote: > Jari Arkko wrote: > > > Here's another attempt: > > > > Such an attack could also be defeated by use of > negative > > acknowledgements, such as TCP RST and ICMP > errors. However, in > > our case the victim lacks a valid SA and, as a > result, is > > incapable providing any other negative > acknowledgements than > > ICMP errors. Such errors may be filtered in many > networks, and > > has some denial-of-service issues itself. > > Hmm.. here's my take (add this to the end of the > section): > > The duration of the attack can also be limited if > the victim > reports the unwanted traffic to the originating > IPsec tunnel > endpoint using ICMP error messages or INVALID_SPI > notifications. As described in [IKEv2] Section > 2.21, this SHOULD > trigger a liveness test, which also doubles as a > return > routability check if the COOKIE2 notification is > included. > > And while we're at it, we could also make the 3rd > paragraph > (the one referring to [Aura02] and transport layer > acks) > more accurate: > > If the attack is launched by an outsider, the > traffic flow would > normally stop soon due to the lack of responses > (such as > transport layer acknowledgements). However, if > the original > recipient of the flow is malicious, it could > maintain the traffic > flow for an extended period of time, since it > often would be able > to send the required acknowledgements (see > [Aura02] for more > discussion). > > Does this look ok? > > Best regards, > Pasi > _______________________________________________ > 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 Mon Nov 07 21:12:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZIyY-0008BZ-Qu for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 21:12:43 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01388 for ; Mon, 7 Nov 2005 21:12:14 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 0F1B0FB280; Tue, 8 Nov 2005 02:12:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5D1A3FB27C; Tue, 8 Nov 2005 02:12:35 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 15F0BFB27D; Tue, 8 Nov 2005 02:12:34 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id CC3B7FB24F for ; Tue, 8 Nov 2005 02:12:32 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jA82CUj3029462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Nov 2005 04:12:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jA82CUaR006492; Tue, 8 Nov 2005 04:12:30 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17264.2446.336137.623907@fireball.kivinen.iki.fi> Date: Tue, 8 Nov 2005 04:12:30 +0200 From: Tero Kivinen To: Mohan Parthasarathy In-Reply-To: <20051108015108.41527.qmail@web80602.mail.yahoo.com> References: <20051108015108.41527.qmail@web80602.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 46 (was: protocol draft status and movingforward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > If there is only one address, why do you need to > explicitly tell your peer that you have > NO_ADDITIONAL_ADDRESS ? Isn't NO_ADDITIONAL_ADDRESS > needed only when oyu have sent ADDITIONAL_ADDRESS > previously ? If you do not include it then then you are not updating address list of the other end. See my previous email to the list, i.e. would adding follogin text help: ---------------------------------------------------------------------- The NO_ADDITIONAL_ADDRESSES notify is needed, as otherwise it would not be possible to distinguish empty DPD message from address update message that does not have any additional addresses. Now we can distinguish them, as DPD is empty INFORMATIONAL exchange and address update with no extra addresses is INFORMATIONAL exchange having only N(NO_ADDITIONAL_ADDRESSES). Both of them can have other additional payloads like N(COOKIE2) etc. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 07 22:07:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZJpi-0000lX-1z for mobike-archive@megatron.ietf.org; Mon, 07 Nov 2005 22:07:38 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA05019 for ; Mon, 7 Nov 2005 22:07:09 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DCA1AFB280; Tue, 8 Nov 2005 03:07:34 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AB67CFB27C; Tue, 8 Nov 2005 03:07:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D47E6FB27D; Tue, 8 Nov 2005 03:07:31 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 142B3FB24F for ; Tue, 8 Nov 2005 03:07:31 +0000 (UTC) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA837R3Z025255; Tue, 8 Nov 2005 05:07:29 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 05:07:29 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 Nov 2005 05:07:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Nov 2005 05:07:24 +0200 Message-ID: Thread-Topic: [Mobike] Issue 46 (was: protocol draft status and movingforward) Thread-Index: AcXkBuwMl1dnYUoCS0mWOeJ50e96nAACgRdw From: To: , X-OriginalArrivalTime: 08 Nov 2005 03:07:28.0640 (UTC) FILETIME=[8D510000:01C5E411] Subject: Re: [Mobike] Issue 46 (was: protocol draft status and movingforward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > > If there is only one address, why do you need to > explicitly tell your peer that you have > NO_ADDITIONAL_ADDRESS ? Tero already answered this, but here's another take: we update the address list only if the request contains either NO_ADDITIONAL_ADDRESS or ADDITIONAL_*_ADDRESS. Otherwise, we would have to include the whole address list in every single IKEv2 request, even when the list has not changed. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 08 12:35:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EZXNo-0007Mk-O7 for mobike-archive@megatron.ietf.org; Tue, 08 Nov 2005 12:35:45 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19459 for ; Tue, 8 Nov 2005 12:35:17 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7D461FB283; Tue, 8 Nov 2005 17:35:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A010FFB24F; Tue, 8 Nov 2005 17:35:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 626E2FB27F; Tue, 8 Nov 2005 17:35:32 +0000 (UTC) Received: from web80602.mail.yahoo.com (web80602.mail.yahoo.com [66.218.79.91]) by machshav.com (Postfix) with SMTP id A4083FB246 for ; Tue, 8 Nov 2005 17:35:31 +0000 (UTC) Received: (qmail 77231 invoked by uid 60001); 8 Nov 2005 17:35:31 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Nwn6kVy/LYikp4+aHJX4ti999MueMrfkjVxghcN/VvtJBT7oQRgwJ6ke3/Y9YRQeP0yO/FXu0r1IcjtAB76t5wxW6HvaqK2mYa2StqQu+i7Hp6gti7+Cg1Nfi8Gd5jFI6h41Ky4U8GJbqPKAAAdhqFsNVrafmHwe/+OMaKE0kJA= ; Message-ID: <20051108173531.77229.qmail@web80602.mail.yahoo.com> Received: from [209.52.106.168] by web80602.mail.yahoo.com via HTTP; Tue, 08 Nov 2005 09:35:31 PST Date: Tue, 8 Nov 2005 09:35:31 -0800 (PST) From: Mohan Parthasarathy To: Pasi.Eronen@nokia.com, mobike@machshav.com In-Reply-To: MIME-Version: 1.0 Subject: Re: [Mobike] Issue 46 (was: protocol draft status and movingforward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Ok, face to face exchange clarified this. You send NO_ADDITIONAL_ADDRESS whenever you are left with just one address and that address appears in the IP header. ADDITIONAL_ADDRESS is sent only when you have more than one address. Perhaps, i am the only one so confused :-) -mohan --- Pasi.Eronen@nokia.com wrote: > Mohan Parthasarathy wrote: > > > > If there is only one address, why do you need to > > explicitly tell your peer that you have > > NO_ADDITIONAL_ADDRESS ? > > Tero already answered this, but here's another take: > we update the address list only if the request > contains > either NO_ADDITIONAL_ADDRESS or > ADDITIONAL_*_ADDRESS. > Otherwise, we would have to include the whole > address > list in every single IKEv2 request, even when the > list > has not changed. > > Best regards, > Pasi > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 10 17:18:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaKk9-0006ua-Rw for mobike-archive@megatron.ietf.org; Thu, 10 Nov 2005 17:18:06 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20315 for ; Thu, 10 Nov 2005 17:17:35 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 40E52FB291; Thu, 10 Nov 2005 22:18:00 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CCF79FB28B; Thu, 10 Nov 2005 22:17:56 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 59245FB28D; Thu, 10 Nov 2005 22:17:55 +0000 (UTC) Received: from web80611.mail.yahoo.com (web80611.mail.yahoo.com [66.94.235.73]) by machshav.com (Postfix) with SMTP id 96A21FB285 for ; Thu, 10 Nov 2005 22:17:54 +0000 (UTC) Received: (qmail 53000 invoked by uid 60001); 10 Nov 2005 22:17:54 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XYEML7LbZ7I9txriqwT3m5t9JpYhAqCevYUpW8wvAMYddgmxqTFK9CkfkR6PZuvxGutY8LCwHh4ffGMYcd1MmrSImJf2uY3km72IMFiyOmnNOAZ9zXBxcFrf7Y8EB0850ECEvKvVqO/sBf5hi5nRZCz6HsVvBEZnmilM9RqdYXU= ; Message-ID: <20051110221754.52998.qmail@web80611.mail.yahoo.com> Received: from [192.100.104.17] by web80611.mail.yahoo.com via HTTP; Thu, 10 Nov 2005 14:17:54 PST Date: Thu, 10 Nov 2005 14:17:54 -0800 (PST) From: Mohan Parthasarathy To: mobike@machshav.com MIME-Version: 1.0 Subject: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Section 5.3 of the design document discusses about the scope of SA change i.e whether it should change all the SAs or some of the SAs and how packet formats would be different for these cases. I think there is a bigger issue here. You can't have one SA and have multiple flows/packets going over different paths because if their path charecterestics are different, the replay check would drop the packets. Unless ESP can maintain per-address sequence numbers, how this would be possible. Perhaps this could be mentioned as a design point. I don't remember whether this was discussed before or not. -mohan P.S: This issue came up in monami6 discussion _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Nov 10 17:46:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaLBp-0008Gc-EV for mobike-archive@megatron.ietf.org; Thu, 10 Nov 2005 17:46:41 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22214 for ; Thu, 10 Nov 2005 17:46:09 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 792ABFB28F; Thu, 10 Nov 2005 22:46:36 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B1379FB28A; Thu, 10 Nov 2005 22:46:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 13D79FB28B; Thu, 10 Nov 2005 22:46:33 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id ED270FB249 for ; Thu, 10 Nov 2005 22:46:31 +0000 (UTC) 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 jAAMjZR19498; Thu, 10 Nov 2005 23:45:35 +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 jAAMjZuh015822; Thu, 10 Nov 2005 23:45:35 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511102245.jAAMjZuh015822@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy In-reply-to: Your message of Thu, 10 Nov 2005 14:17:54 PST. <20051110221754.52998.qmail@web80611.mail.yahoo.com> Date: Thu, 10 Nov 2005 23:45:35 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: P.S: This issue came up in monami6 discussion => to be more specific: the Monami6 WG explictely asked the issue 8 to be reopened. The minutes are not yet available but the Jabber logs should show me at the micro just asking this and Vijay's answer (sure). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 11 13:16:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EadS7-0008GT-Fs for mobike-archive@megatron.ietf.org; Fri, 11 Nov 2005 13:16:43 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24948 for ; Fri, 11 Nov 2005 13:16:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 65561FB290; Fri, 11 Nov 2005 18:16:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86447FB282; Fri, 11 Nov 2005 18:16:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CC9FDFB284; Fri, 11 Nov 2005 18:16:34 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 664CDFB280 for ; Fri, 11 Nov 2005 18:16:33 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jABIGU7v011502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Nov 2005 20:16:30 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jABIGTVa029214; Fri, 11 Nov 2005 20:16:29 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17268.57341.194810.274974@fireball.kivinen.iki.fi> Date: Fri, 11 Nov 2005 20:16:29 +0200 From: Tero Kivinen To: Mohan Parthasarathy In-Reply-To: <20051110221754.52998.qmail@web80611.mail.yahoo.com> References: <20051110221754.52998.qmail@web80611.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 81 min Cc: mobike@machshav.com Subject: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > I think there is a bigger issue here. You can't have > one SA and have multiple flows/packets going over > different paths because if their path charecterestics > are different, the replay check would drop the > packets. Unless ESP can maintain per-address > sequence numbers, how this would be possible. > Perhaps this could be mentioned as a design point. > I don't remember whether this was discussed before > or not. Actually that is not problem with issue 8. The issue 8 is about moving only part of SAs created between two hosts. One SA always will use exactly one address pair regardless of issue 8. Our charter do rule out load balancing, i.e. using multiple addresses at the same time for single IPsec SA is explicitly ruled out for the group. We do already offer a way for the host to create separate group of SAs which are moved separately from each other, i.e. applications can create multiple IKE SAs, and create the IPsec SAs to the IKE SA having similar IPsec SAs. I.e. if you have 3 different groups of IPsec SAs wanting to have different charasteristics from the interfaces uses, you can create 3 IKE SAs and create those IPsec SAs inside each of those IKE SAs. Then you have 3 groups (IKE SAs) which you can separately move from one address pair to another. You can even move the IPsec SAs from one group to another, by recreating the IPsec SA in diffenet IKE SA and then deleting the old IPsec SA from old IKE SA. The problem with ESP sequence numbers comes only if we try to do load-balancing, i.e. use multiple different ip-addresses for the SAME IPec SA at the same time. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 11 13:25:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eadaw-0005Jx-EL for mobike-archive@megatron.ietf.org; Fri, 11 Nov 2005 13:25:50 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25592 for ; Fri, 11 Nov 2005 13:25:19 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id E6F1BFB291; Fri, 11 Nov 2005 18:25:46 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C56F8FB284; Fri, 11 Nov 2005 18:25:43 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B6E7AFB28A; Fri, 11 Nov 2005 18:25:41 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id A52EAFB23E for ; Fri, 11 Nov 2005 18:25:40 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jABIPcvi003315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 11 Nov 2005 20:25:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jABIPbHG010719; Fri, 11 Nov 2005 20:25:37 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17268.57889.918348.51440@fireball.kivinen.iki.fi> Date: Fri, 11 Nov 2005 20:25:37 +0200 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200511102245.jAAMjZuh015822@givry.rennes.enst-bretagne.fr> References: <20051110221754.52998.qmail@web80611.mail.yahoo.com> <200511102245.jAAMjZuh015822@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: Mohan Parthasarathy , mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Francis Dupont writes: > In your previous mail you wrote: > > P.S: This issue came up in monami6 discussion > > => to be more specific: the Monami6 WG explictely asked the issue 8 > to be reopened. The minutes are not yet available but the Jabber logs > should show me at the micro just asking this and Vijay's answer (sure). I checked the Jabber logs, but couldn't really find out if they are asking for using multiple address pairs for single SA simultaneously (load balancing ==> out of charter of mobike), or if it is issue 8, which is having multiple IPsec SAs inside one IKE SA, and wanting to move them separately from each other without creating multiple IKE SAs. Need to wait for the minutes then.... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 11 16:30:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EagTb-0006bg-C9 for mobike-archive@megatron.ietf.org; Fri, 11 Nov 2005 16:30:27 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19220 for ; Fri, 11 Nov 2005 16:29:57 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3F6ABFB291; Fri, 11 Nov 2005 21:30:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E1FB2FB28B; Fri, 11 Nov 2005 21:30:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 44941FB28E; Fri, 11 Nov 2005 21:30:20 +0000 (UTC) Received: from web80603.mail.yahoo.com (web80603.mail.yahoo.com [66.218.79.92]) by machshav.com (Postfix) with SMTP id 7C909FB284 for ; Fri, 11 Nov 2005 21:30:19 +0000 (UTC) Received: (qmail 58612 invoked by uid 60001); 11 Nov 2005 21:30:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kWMlYblBgExxAKDYKb7hLEw7icpRejjPrlwIJVkvwa7OAvQukWhHbzdD8rLEg9RBaOr24fz66h2eQIN2y5uYFT1v2DjgxnvP38suUahBiu9/PQqRsrDGX+ukZJiwH5QlOWaBd/yJlWxUsGLbaTuf3pu1xBt7Jwy1CA5KBVoTJNg= ; Message-ID: <20051111213019.58610.qmail@web80603.mail.yahoo.com> Received: from [192.100.104.18] by web80603.mail.yahoo.com via HTTP; Fri, 11 Nov 2005 13:30:19 PST Date: Fri, 11 Nov 2005 13:30:19 -0800 (PST) From: Mohan Parthasarathy To: Tero Kivinen In-Reply-To: <17268.57341.194810.274974@fireball.kivinen.iki.fi> MIME-Version: 1.0 Cc: mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 --- Tero Kivinen wrote: > Mohan Parthasarathy writes: > > I think there is a bigger issue here. You can't > have > > one SA and have multiple flows/packets going over > > different paths because if their path > charecterestics > > are different, the replay check would drop the > > packets. Unless ESP can maintain per-address > > sequence numbers, how this would be possible. > > Perhaps this could be mentioned as a design point. > > I don't remember whether this was discussed before > > or not. > > Actually that is not problem with issue 8. The issue > 8 is about moving > only part of SAs created between two hosts. One SA > always will use > exactly one address pair regardless of issue 8. Our > charter do rule > out load balancing, i.e. using multiple addresses at > the same time for > single IPsec SA is explicitly ruled out for the > group. > I never mentioned issue 8 and monami6 does not know anything about MOBIKE issues :-) > We do already offer a way for the host to create > separate group of SAs > which are moved separately from each other, i.e. > applications can > create multiple IKE SAs, and create the IPsec SAs to > the IKE SA having > similar IPsec SAs. I.e. if you have 3 different > groups of IPsec SAs > wanting to have different charasteristics from the > interfaces uses, > you can create 3 IKE SAs and create those IPsec SAs > inside each of > those IKE SAs. Then you have 3 groups (IKE SAs) > which you can > separately move from one address pair to another. > > You can even move the IPsec SAs from one group to > another, by > recreating the IPsec SA in diffenet IKE SA and then > deleting the old > IPsec SA from old IKE SA. > > The problem with ESP sequence numbers comes only if > we try to do > load-balancing, i.e. use multiple different > ip-addresses for the SAME > IPec SA at the same time. My only poiny is about the design document where one can explain this motivation. I never asked to reopen any issues. I agree that one can use multiple SAs for different flows. I don't think the discussion in monami6 went that far. So, my intention was just to explain this in the design document. -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 05:00:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebb8B-0006EA-Kk for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 05:00:07 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09347 for ; Mon, 14 Nov 2005 04:59:33 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 96A26FB282; Mon, 14 Nov 2005 10:00:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7D38AFB27C; Mon, 14 Nov 2005 09:59:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 11AB8FB280; Mon, 14 Nov 2005 09:59:56 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 0072BFB277 for ; Mon, 14 Nov 2005 09:59:54 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAE9xqLB027256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2005 11:59:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAE9xppP017541; Mon, 14 Nov 2005 11:59:51 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17272.24599.451385.989422@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 11:59:51 +0200 From: Tero Kivinen To: Mohan Parthasarathy In-Reply-To: <20051111213019.58610.qmail@web80603.mail.yahoo.com> References: <17268.57341.194810.274974@fireball.kivinen.iki.fi> <20051111213019.58610.qmail@web80603.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > My only poiny is about the design document where > one can explain this motivation. I never asked > to reopen any issues. I agree that one can use > multiple SAs for different flows. I don't think > the discussion in monami6 went that far. So, > my intention was just to explain this in the > design document. So you want the design document to explain why load balancing was left out from the charter? I am not really sure why it should be there, as it is already clear from the charter that we are not going to do that. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 05:49:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebbty-00050c-0t for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 05:49:30 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11483 for ; Mon, 14 Nov 2005 05:48:56 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 2DAF3FB28A; Mon, 14 Nov 2005 10:49:27 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B63DEFB27C; Mon, 14 Nov 2005 10:49:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1517DFB280; Mon, 14 Nov 2005 10:49:21 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id C1C4CFB277 for ; Mon, 14 Nov 2005 10:49:19 +0000 (UTC) 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 jAEAmoH30002; Mon, 14 Nov 2005 11:48:50 +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 jAEAmo3N032974; Mon, 14 Nov 2005 11:48:50 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511141048.jAEAmo3N032974@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Fri, 11 Nov 2005 20:16:29 +0200. <17268.57341.194810.274974@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 11:48:50 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Mohan Parthasarathy , mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: Actually that is not problem with issue 8. The issue 8 is about moving only part of SAs created between two hosts. One SA always will use exactly one address pair regardless of issue 8. Our charter do rule out load balancing, i.e. using multiple addresses at the same time for single IPsec SA is explicitly ruled out for the group. => so we agree the issue 8 is not out of the charter. We do already offer a way for the host to create separate group of SAs which are moved separately from each other, i.e. applications can create multiple IKE SAs, and create the IPsec SAs to the IKE SA having => this, to have to create multiple IKE SAs between the same peers, is exactly we'd like to change (including in Monami6 WG concern). similar IPsec SAs. I.e. if you have 3 different groups of IPsec SAs wanting to have different charasteristics from the interfaces uses, you can create 3 IKE SAs and create those IPsec SAs inside each of those IKE SAs. Then you have 3 groups (IKE SAs) which you can separately move from one address pair to another. Regards Francis.Dupont@enst-bretagne.fr PS: note there are at most two issues to solve to support this: - choose between either sending the message using the "new" address or adding a new field for the "new" address. (the first is a simplest extension of the current style). - a place to put the list of SAs to update. For the second IMHO an update payload is better. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 05:52:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebbwl-0005Qw-4K for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 05:52:23 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11601 for ; Mon, 14 Nov 2005 05:51:51 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DAD56FB28A; Mon, 14 Nov 2005 10:52:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 80939FB280; Mon, 14 Nov 2005 10:52:17 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EE95EFB281; Mon, 14 Nov 2005 10:52:15 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id C4C8AFB27C for ; Mon, 14 Nov 2005 10:52:14 +0000 (UTC) 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 jAEApnH30374; Mon, 14 Nov 2005 11:51:49 +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 jAEApnc1032996; Mon, 14 Nov 2005 11:51:49 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511141051.jAEApnc1032996@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Fri, 11 Nov 2005 20:25:37 +0200. <17268.57889.918348.51440@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 11:51:49 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Mohan Parthasarathy , mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: I checked the Jabber logs, but couldn't really find out if they are asking for using multiple address pairs for single SA simultaneously (load balancing ==> out of charter of mobike), or if it is issue 8, => it is issue 8, each flow uses one tunnel. which is having multiple IPsec SAs inside one IKE SA, and wanting to move them separately from each other without creating multiple IKE SAs. => the Monami6 stuff is in the Mobike charter (as people understood the question they knew also the charter :-). Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 08:01:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebdy1-0003Xf-6i for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 08:01:49 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18678 for ; Mon, 14 Nov 2005 08:01:15 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7F337FB285; Mon, 14 Nov 2005 13:01:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F40DDFB27C; Mon, 14 Nov 2005 13:01:38 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D35B0FB280; Mon, 14 Nov 2005 13:01:37 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 85F22FB277 for ; Mon, 14 Nov 2005 13:01:36 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAED1VgT014211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2005 15:01:31 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAED1T6a007164; Mon, 14 Nov 2005 15:01:29 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17272.35497.409227.188195@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 15:01:29 +0200 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200511141048.jAEAmo3N032974@givry.rennes.enst-bretagne.fr> References: <17268.57341.194810.274974@fireball.kivinen.iki.fi> <200511141048.jAEAmo3N032974@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: Mohan Parthasarathy , mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Francis Dupont writes: > In your previous mail you wrote: > > Actually that is not problem with issue 8. The issue 8 is about moving > only part of SAs created between two hosts. One SA always will use > exactly one address pair regardless of issue 8. Our charter do rule > out load balancing, i.e. using multiple addresses at the same time for > single IPsec SA is explicitly ruled out for the group. > > => so we agree the issue 8 is not out of the charter. If it would be out of charter, then it wouldn't be in the issue list at all, as it would be non-issue... :-) But it is closed and will not be opened as far as I have understood. > => this, to have to create multiple IKE SAs between the same peers, > is exactly we'd like to change (including in Monami6 WG concern). The working group decided that it is not a concern to create mutliple IKE SAs and did close issue 8. Thus there is no reason to restart the discussion about this same issue again here. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 08:19:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbeFZ-0007Qk-1V for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 08:19:57 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20042 for ; Mon, 14 Nov 2005 08:19:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7C35BFB285; Mon, 14 Nov 2005 13:19:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A2C2FFB27C; Mon, 14 Nov 2005 13:19:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 88217FB280; Mon, 14 Nov 2005 13:19:44 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 2F98CFB277 for ; Mon, 14 Nov 2005 13:19:43 +0000 (UTC) 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 jAEDJPH11290; Mon, 14 Nov 2005 14:19:25 +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 jAEDJPEL034342; Mon, 14 Nov 2005 14:19:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511141319.jAEDJPEL034342@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Mon, 14 Nov 2005 15:01:29 +0200. <17272.35497.409227.188195@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 14:19:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Mohan Parthasarathy , mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > => this, to have to create multiple IKE SAs between the same peers, > is exactly we'd like to change (including in Monami6 WG concern). The working group decided that it is not a concern to create mutliple IKE SAs and did close issue 8. Thus there is no reason to restart the discussion about this same issue again here. => there is a reason: an explicit request from the Monami6 WG. As it is in the charter of Mobike IMHO the only thing the Monami6 WG can do is this request. Now Monami6 people can raise a concern at the last call for the design document and/or ask for a transfer of this point between WGs' charters. BTW the Monami6 WG is supposed to address real world concerns so I don't believe the Mobike WG should ignore the message... Regards Francis.Dupont@enst-bretagne.fr PS: the document to read is Vijay's presentation. I have a private copy of it if it is no more available at the IETF site. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 08:44:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebecx-00025W-SL for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 08:44:08 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21151 for ; Mon, 14 Nov 2005 08:43:35 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 25350FB283; Mon, 14 Nov 2005 13:44:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 06305FB27C; Mon, 14 Nov 2005 13:44:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 20097FB277; Mon, 14 Nov 2005 13:44:02 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id E2D49FB23C for ; Mon, 14 Nov 2005 13:44:00 +0000 (UTC) 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 jAEDf8CP025730; Mon, 14 Nov 2005 15:41:09 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 15:43:58 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 15:43:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 15:43:58 +0200 Message-ID: Thread-Topic: [Mobike] Scope of SA change in design document.. Thread-Index: AcXpHoS4hLcK2fvzTRmmA4Nm9TQN2AAAKbEQ From: To: X-OriginalArrivalTime: 14 Nov 2005 13:43:58.0153 (UTC) FILETIME=[7684BB90:01C5E921] Cc: mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Francis Dupont wrote: > > The working group decided that it is not a concern to create > mutliple IKE SAs and did close issue 8. Thus there is no reason > to restart the discussion about this same issue again here. > > => there is a reason: an explicit request from the Monami6 WG. As > it is in the charter of Mobike IMHO the only thing the Monami6 WG > can do is this request. Now Monami6 people can raise a concern at > the last call for the design document and/or ask for a transfer of > this point between WGs' charters. BTW the Monami6 WG is supposed > to address real world concerns so I don't believe the Mobike WG > should ignore the message... I agree, we should not ignore the message. However, as we're basically finished with the MOBIKE base protocol, I don't think we should talk about "reopening issue 8", since that would be slightly misleading. What we can talk about is specifying an extension to the MOBIKE base protocol that would provide the functionality Monami6 would want. Determining what exactly the extension should do to satisfy Monami6 needs will take time (especially since Monami6 itself will take some time to stabilize -- after all, the WG was started less than two months ago), so it will be a separate document. Thus, this is not an "issue" for the MOBIKE base protocol document or the design document (which explains why the base protocol was done that way): it's a new work item for MOBIKE WG. Currently, the issue tracker at www.vpnc.org is only used to track issues for the base protocol document. New work items should be tracked by changing the milestones in the charter instead. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 08:51:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbekH-00046Y-BA for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 08:51:41 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21703 for ; Mon, 14 Nov 2005 08:51:08 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 162BFFB285; Mon, 14 Nov 2005 13:51:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2A882FB27C; Mon, 14 Nov 2005 13:51:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 00437FB280; Mon, 14 Nov 2005 13:51:19 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id E337BFB277 for ; Mon, 14 Nov 2005 13:51:18 +0000 (UTC) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAEDmSho001203 for ; Mon, 14 Nov 2005 15:48:29 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 15:51:18 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 15:51:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 15:51:18 +0200 Message-ID: Thread-Topic: Issue 73: Port numbers in examples Thread-Index: AcXpIn0UKIs0BX17SpOg6uFI6Dw5Ug== From: To: X-OriginalArrivalTime: 14 Nov 2005 13:51:17.0633 (UTC) FILETIME=[7C780F10:01C5E922] Subject: [Mobike] Issue 73: Port numbers in examples X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Stephane pointed out in the WG meeting that the examples in Section 2.2 don't change to port 4500 as they should. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 08:58:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eber8-0006Vc-Dm for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 08:58:46 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22124 for ; Mon, 14 Nov 2005 08:58:13 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 7B6C3FB281; Mon, 14 Nov 2005 13:58:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 97F2AFB262; Mon, 14 Nov 2005 13:58:40 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DC7FEFB277; Mon, 14 Nov 2005 13:58:38 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 0F6C8FB24F for ; Mon, 14 Nov 2005 13:58:38 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAEDthw0009658; Mon, 14 Nov 2005 15:55:47 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 15:58:32 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 15:58:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 15:58:32 +0200 Message-ID: Thread-Topic: [Mobike] Issue 60: Addresses in IKE_SA_INIT/AUTH (was: Comments of draft-ietf-mobike-protocol-04.txt) Thread-Index: AcXVYHJYvMA1C6nKT3aAl80aoYj6bATwlVmA From: To: X-OriginalArrivalTime: 14 Nov 2005 13:58:31.0629 (UTC) FILETIME=[7F2697D0:01C5E923] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 60: Addresses in IKE_SA_INIT/AUTH (was: Comments of draft-ietf-mobike-protocol-04.txt) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Tero Kivinen wrote: > > Actually sending UNEXPECTED_NAT_DETECTION during IKE SA creation > is quite useless, as it cannot be authenticated, and also if the > initiator wants to ignore those error notifications and continue > retrying regardless of them. So why do we send those notifies in > the first place? Hmm, this is true:if there's an attack, we cannot really detect it at the IKE_SA_INIT stage anyway.... So as I already said in the meeting last week, I've changed my opinion and support your proposal (take addresses from 1st IKE_AUTH exchange, NAT-T or no NAT-T). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 09:01:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebeu1-00076D-6z for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 09:01:45 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22311 for ; Mon, 14 Nov 2005 09:01:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id EF6E1FB280; Mon, 14 Nov 2005 14:01:42 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DC7C8FB249; Mon, 14 Nov 2005 14:01:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ED9ADFB27C; Mon, 14 Nov 2005 14:01:39 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 2FB0EFB249 for ; Mon, 14 Nov 2005 14:01:39 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAEDuvwU027821; Mon, 14 Nov 2005 15:57:03 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:01:38 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 14 Nov 2005 16:01:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 16:01:29 +0200 Message-ID: Thread-Topic: Issue 71: Failing RR (was: Do we need text about failing RR) Thread-Index: AcXbxoz8SRhLi3CQQBOOm5ZSMFS2UwNXRDSA From: To: , X-OriginalArrivalTime: 14 Nov 2005 14:01:28.0838 (UTC) FILETIME=[E8C68A60:01C5E923] Subject: [Mobike] Issue 71: Failing RR (was: Do we need text about failing RR) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Discussing this face-to-face clarified the situation: I guess all we need is a way for the initiator to discover the situation. Your proposal about considering the IP address when deciding whether to start DPD sounds like the way to go. Could you figure out what needs to be added and/or changed in the draft to make this work? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 09:12:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebf4M-00018A-OJ for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 09:12:26 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23076 for ; Mon, 14 Nov 2005 09:11:53 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 4BB23FB285; Mon, 14 Nov 2005 14:12:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B46C2FB27C; Mon, 14 Nov 2005 14:12:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 365E6FB280; Mon, 14 Nov 2005 14:12:14 +0000 (UTC) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id CF8D6FB24A for ; Mon, 14 Nov 2005 14:12:12 +0000 (UTC) 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 jAEEBxH16335; Mon, 14 Nov 2005 15:11:59 +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 jAEEBxSs034776; Mon, 14 Nov 2005 15:11:59 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200511141411.jAEEBxSs034776@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com In-reply-to: Your message of Mon, 14 Nov 2005 15:43:58 +0200. Date: Mon, 14 Nov 2005 15:11:59 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: I agree, we should not ignore the message. However, as we're basically finished with the MOBIKE base protocol, I don't think we should talk about "reopening issue 8", since that would be slightly misleading. => if it was not clear enough, I spoke about "reopening issue 8" for *extensions* to the base protocol. What we can talk about is specifying an extension to the MOBIKE base protocol that would provide the functionality Monami6 would want. Determining what exactly the extension should do to satisfy Monami6 needs will take time (especially since Monami6 itself will take some time to stabilize -- after all, the WG was started less than two months ago), so it will be a separate document. => I fully agree. Thus, this is not an "issue" for the MOBIKE base protocol document or the design document (which explains why the base protocol was done that way): it's a new work item for MOBIKE WG. => as far as I know "extensions" is one of the next work items. Currently, the issue tracker at www.vpnc.org is only used to track issues for the base protocol document. New work items should be tracked by changing the milestones in the charter instead. => it seems we agree. The issue 8 and the "initiator" decides everything are the first two points to solve in extensions IMHO as they have bad impacts in real world extra requirements. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 10:26:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbgDc-00064u-N9 for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 10:26:04 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29077 for ; Mon, 14 Nov 2005 10:25:31 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DBD76FB283; Mon, 14 Nov 2005 15:26:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B805AFB27C; Mon, 14 Nov 2005 15:25:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A1465FB280; Mon, 14 Nov 2005 15:25:58 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 35D29FB277 for ; Mon, 14 Nov 2005 15:25:57 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAEFPslm027832 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2005 17:25:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAEFPrY6029015; Mon, 14 Nov 2005 17:25:53 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17272.44161.579549.977879@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 17:25:53 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: mobike@machshav.com Subject: [Mobike] Issue 71: Failing RR (was: Do we need text about failing RR) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > Discussing this face-to-face clarified the situation: I guess > all we need is a way for the initiator to discover the situation. > > Your proposal about considering the IP address when deciding > whether to start DPD sounds like the way to go. Could you > figure out what needs to be added and/or changed in the draft > to make this work? Hmm... I think we need new section probably after "Failure Recover and Timeouts" explaining DPD behavior: X.X Dead Peer Detection MOBIKE protocol uses same DPD method than normal IKEv2, but as the IP addresses might change in the MOBIKE also they should be taken account when determing whether the other peer is alive and in sync with address updates. This means that, if there is incoming traffic, but that does not use current address pair, that should not be considered to proof that the other end is alive. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 10:59:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ebgjp-0005Sw-Jc for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 10:59:21 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01341 for ; Mon, 14 Nov 2005 10:58:48 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id DE1CDFB277; Mon, 14 Nov 2005 15:59:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 37DA7FB27C; Mon, 14 Nov 2005 15:59:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E6F8CFB280; Mon, 14 Nov 2005 15:59:14 +0000 (UTC) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by machshav.com (Postfix) with ESMTP id F3B2EFB277 for ; Mon, 14 Nov 2005 15:59:13 +0000 (UTC) Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 14 Nov 2005 07:58:58 -0800 X-IronPort-AV: i="3.97,328,1125903600"; d="scan'208"; a="674696675:sNHT2812643778" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAEFw6KT028331; Mon, 14 Nov 2005 07:58:55 -0800 (PST) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Nov 2005 10:58:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 14 Nov 2005 10:58:53 -0500 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD6D099A5@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] Issue 73: Port numbers in examples Thread-Index: AcXpIn0UKIs0BX17SpOg6uFI6Dw5UgAEX90A From: "Stephane Beaulieu (stephane)" To: , X-OriginalArrivalTime: 14 Nov 2005 15:58:54.0389 (UTC) FILETIME=[50404E50:01C5E934] Subject: Re: [Mobike] Issue 73: Port numbers in examples X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Hi Pasi, Thanks. I meant to follow up with an email, but it slipped my mind. There's also another piece of text in section 3.5 which is misleading. o If the IPsec SAs were updated in the previous step: If NAT Traversal is not enabled, and the responder supports NAT Traversal (as indicated by NAT detection payloads in the IKE_SA_INIT exchange), and the initiator either suspects or knows that a NAT is likely to be present, enables NAT Traversal (that is, enables UDP encapsulation of outgoing ESP packets and sending of NAT- Keepalive packets). This implies that we didn't already switch to port 4500 as was mentioned earlier in the doc. My impression is that we were always doing UDP encaps on port 4500. (or are we just switching IKE to port 4500, but not doing UDP encaps?) Stephane. > -----Original Message----- > From: mobike-bounces@machshav.com > [mailto:mobike-bounces@machshav.com] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Monday, November 14, 2005 8:51 AM > To: mobike@machshav.com > Subject: [Mobike] Issue 73: Port numbers in examples > > > Stephane pointed out in the WG meeting that the examples in > Section 2.2 don't change to port 4500 as they should. > > Best regards, > Pasi > _______________________________________________ > 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 Mon Nov 14 12:53:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbiVv-0008Kt-Vc for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 12:53:08 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08761 for ; Mon, 14 Nov 2005 12:52:36 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3B0E3FB28B; Mon, 14 Nov 2005 17:53:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5A530FB24F; Mon, 14 Nov 2005 17:52:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4C96FFB27C; Mon, 14 Nov 2005 17:52:57 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 04C72FB24A for ; Mon, 14 Nov 2005 17:52:56 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAEHqna0005085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Nov 2005 19:52:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAEHqmOZ019159; Mon, 14 Nov 2005 19:52:48 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17272.52976.354312.130526@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 19:52:48 +0200 From: Tero Kivinen To: "Stephane Beaulieu (stephane)" In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD6D099A5@xmb-rtp-208.amer.cisco.com> References: <13E3DA8B48E17D4C96D261A36A23FCD6D099A5@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 73: Port numbers in examples X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Stephane Beaulieu (stephane) writes: > Hi Pasi, > > Thanks. I meant to follow up with an email, but it slipped my mind. > > There's also another piece of text in section 3.5 which is misleading. > > > o If the IPsec SAs were updated in the previous step: If NAT > Traversal is not enabled, and the responder supports NAT Traversal > (as indicated by NAT detection payloads in the IKE_SA_INIT > exchange), and the initiator either suspects or knows that a NAT > is likely to be present, enables NAT Traversal (that is, enables > UDP encapsulation of outgoing ESP packets and sending of NAT- > Keepalive packets). > > > This implies that we didn't already switch to port 4500 as was mentioned > earlier in the doc. My impression is that we were always doing UDP > encaps on port 4500. (or are we just switching IKE to port 4500, but > not doing UDP encaps?) Yes. We simply move all IKE traffic to port 4500 immediately when we notice that other end supports NAT regardless whether there is NAT or not. The IPsec SAs are still created using normal ESP packets in case there is no NAT, and if we move behind NAT then we change those IPsec SAs to use UDP encapsulation too. If we move away from NAT then we again disable the UDP encapsulation of IPsec packets, but keep the IKE traffic on port 4500. The reason for this is that if we would do the port switch when we later detect NAT, it would cause the additional complexity, as responder do not know the addresses that are going to be used in the encapsulated packets, as initiator wouldn't had sent any packets with those addresses and NAT wouldn't have created mapping for the packets yet. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Nov 14 21:42:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbqmT-0005gg-J4 for mobike-archive@megatron.ietf.org; Mon, 14 Nov 2005 21:42:45 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22642 for ; Mon, 14 Nov 2005 21:42:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 39A17FB282; Tue, 15 Nov 2005 02:42:41 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EC2FEFB277; Tue, 15 Nov 2005 02:42:37 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 33E8EFB27C; Tue, 15 Nov 2005 02:42:36 +0000 (UTC) Received: from smtp108.sbc.mail.mud.yahoo.com (smtp108.sbc.mail.mud.yahoo.com [68.142.198.207]) by machshav.com (Postfix) with SMTP id 216E5FB262 for ; Tue, 15 Nov 2005 02:42:35 +0000 (UTC) Received: (qmail 91273 invoked from network); 15 Nov 2005 02:42:34 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@70.137.155.90 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 15 Nov 2005 02:42:33 -0000 Message-ID: <004801c5e98e$3b2d0080$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <17268.57341.194810.274974@fireball.kivinen.iki.fi><20051111213019.58610.qmail@web80603.mail.yahoo.com> <17272.24599.451385.989422@fireball.kivinen.iki.fi> Date: Mon, 14 Nov 2005 18:42:32 -0800 MIME-Version: 1.0 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 Cc: mobike@machshav.com Subject: Re: [Mobike] Scope of SA change in design document.. X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > > My only poiny is about the design document where > > one can explain this motivation. I never asked > > to reopen any issues. I agree that one can use > > multiple SAs for different flows. I don't think > > the discussion in monami6 went that far. So, > > my intention was just to explain this in the > > design document. > > So you want the design document to explain why load balancing was left > out from the charter? I am not really sure why it should be there, as > it is already clear from the charter that we are not going to do that. I re-read issue 8 and section 5.3. I realized that they are not related :-) I don't think any changes are needed in the design document. -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ > 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 Tue Nov 15 04:45:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EbxN6-0000CO-RV for mobike-archive@megatron.ietf.org; Tue, 15 Nov 2005 04:45:00 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13968 for ; Tue, 15 Nov 2005 04:44:26 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3E9D6FB282; Tue, 15 Nov 2005 09:44:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F1374FB277; Tue, 15 Nov 2005 09:44:52 +0000 (UTC) X-Original-To: Mobike@machshav.com Delivered-To: Mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8D0FBFB27C; Tue, 15 Nov 2005 09:44:51 +0000 (UTC) Received: from web30915.mail.mud.yahoo.com (web30915.mail.mud.yahoo.com [68.142.201.68]) by machshav.com (Postfix) with SMTP id D9303FB262 for ; Tue, 15 Nov 2005 09:44:50 +0000 (UTC) Received: (qmail 18875 invoked by uid 60001); 15 Nov 2005 09:44:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=iUadEqxsfwEUEhEFCBUpOgQrPskzEZfa2kF+jfz2zH4DUP/hC2M6t8sgPSSLzn+8t9QqPWpIiWEh4nIuoOxp3yt3JAZYeG3wMh++FEdPDt2GfvOScydVdTIbZv/G0B6c/sZbJIS66oveGAKAhG+lg1H6GKv9SjqkfmBKvZkTMSY= ; Message-ID: <20051115094450.18873.qmail@web30915.mail.mud.yahoo.com> Received: from [203.130.213.233] by web30915.mail.mud.yahoo.com via HTTP; Tue, 15 Nov 2005 09:44:50 GMT Date: Tue, 15 Nov 2005 09:44:50 +0000 (GMT) From: Noval Aspani To: Mobike@machshav.com MIME-Version: 1.0 Subject: [Mobike] (no subject) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1388373247==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --===============1388373247== Content-Type: multipart/alternative; boundary="0-132336574-1132047890=:18355" --0-132336574-1132047890=:18355 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit how to out from this mailist Send instant messages to your online friends http://uk.messenger.yahoo.com --0-132336574-1132047890=:18355 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
how to out from this mailist

Send instant messages to your online friends http://uk.messenger.yahoo.com --0-132336574-1132047890=:18355-- --===============1388373247== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --===============1388373247==-- From mobike-bounces@machshav.com Tue Nov 15 13:56:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec5yK-0003QL-Tl for mobike-archive@megatron.ietf.org; Tue, 15 Nov 2005 13:56:01 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17994 for ; Tue, 15 Nov 2005 13:55:27 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id BDF6EFB281; Tue, 15 Nov 2005 18:55:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 98AF3FB277; Tue, 15 Nov 2005 18:55:54 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DA516FB27C; Tue, 15 Nov 2005 18:55:52 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 30E9FFB262 for ; Tue, 15 Nov 2005 18:55:52 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 271F189863; Tue, 15 Nov 2005 20:55:48 +0200 (EET) Message-ID: <437A20A4.7060704@piuha.net> Date: Tue, 15 Nov 2005 19:53:40 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <17262.23016.795079.711821@fireball.kivinen.iki.fi> In-Reply-To: <17262.23016.795079.711821@fireball.kivinen.iki.fi> Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 59 (was: protocol draft status and moving forward) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Looks good to me. --Jari Tero Kivinen wrote: >Pasi.Eronen@nokia.com writes: > > >>Tero Kivinen wrote: >> >> >> >>>Yes. People WILL misunderstand any text you put there. >>> >>>If you do not want to add the text twice, then add the picture, not >>>the text. Text is hard to parse when you are trying to implement >>>things, and then you end up interpreting every hidden meaning before >>>each word used. >>> >>> >>Ok, how about this? >> >> > >That is fine. Even the picture (formula) I used would have been >sufficient, but this is even better... > > > >>>>Is mentioning IPv6 some more helpful for the reader..? >>>> >>>> >>>Yes. I think it should be repeated also in the security considerations >>>section, just to tell where this protection can be used. >>> >>> >>Ok, I copied the "This feature is mainly intended for IPv6 and >>site-to-site VPN cases, where the administrators may know >>beforehand that NATs are not present." from 3.9 here. >> >> > >Good. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 15 14:05:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec67u-0006XU-Ko for mobike-archive@megatron.ietf.org; Tue, 15 Nov 2005 14:05:54 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18503 for ; Tue, 15 Nov 2005 14:05:22 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1A416FB282; Tue, 15 Nov 2005 19:05:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F2CD5FB277; Tue, 15 Nov 2005 19:05:48 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 18456FB27D; Tue, 15 Nov 2005 19:05:48 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 02AB6FB262 for ; Tue, 15 Nov 2005 19:05:47 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 685A989863; Tue, 15 Nov 2005 21:05:45 +0200 (EET) Message-ID: <437A22F9.2080504@piuha.net> Date: Tue, 15 Nov 2005 20:03:37 +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: Cc: mobike@machshav.com Subject: Re: [Mobike] 54 - marcelo's editorial comments X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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, >>>9. In section 4.4 i think that the Dead Path Detection >>>indication should be mentioned as one of the events that should >>>lead to an address change (perhaps a reference to section 4.9 >>>would be useful too) along with >>> >>> >>Suggested change: >> >> o An IKEv2 request has been re-transmitted several times, but no >> valid reply has been received. This suggests the >> current path is no longer working. >> >>=> >> >> o An IKEv2 request has been re-transmitted several times, but no >> valid reply has been received. This suggests the >> current path is no longer working. See also Section 3.9. >> >> > >Section 3.9 is about NAT prohibition, and doesn't need to be >referenced here?? In -04, Section 4.9 was about path testing, but >that's not really very closely related either. IMHO Marcelo's >original comment is already handled here: failing DPD == "IKEv2 >request has been re-transmitted several times, but no valid reply >has been received". > >My proposal: no text change. > > Ok. >>>10. In section 4.4, it is stated that: >>> >>> o It updates the IPsec SAs associated with this IKE_SA >>> with the new addresses (unless this was already done >>> before sending the request). >>> >>>As i understand it, the reason for updating the addresses here >>>is because the reply plays the role of a return routability >>>check, right? It would make sense to state so, for instance >>>adding something like >>> >>> o It updates the IPsec SAs associated with this IKE_SA >>> with the new addresses (unless this was already done >>> before sending the request i.e. no return routability >>> check was required, see 4.6). >>> >>> >>Ok. The current Section that this text is in is by the way 3.5. >> >> > >The pointer to 4.6/3.5 is IMHO confusing; the real pointer is to >the step "Updates the IPsec SAs..." step earlier in this section. > > Yes. >How about this? > > o It updates the IPsec SAs associated with this IKE_SA with > the new addresses (unless this was already done earlier > before sending the request; this is the case when no > return routability check was required). > > Ok. > > >>>I am not sure that the example of the certificate is a good >>>example... what if the certificate is self signed? (i don't know >>>if those are supported) but in any case, i don't know how simple >>>is that certificates can prove address ownership (this depends >>>of the checks performed by the CA about address ownership) >>> >>> >>Right. Suggested text change: s/the address is included in the >>peer's certificate/the address is included in a certificate given >>to the peer by a trusted authority/ >> >> > >My proposal: > > [..], or the address can be verified by some other means > (e.g., a certificate issued by an authority trusted for > this purpose), [...] > > Ok. I think that also addressed Tero's concern with my original text proposal. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 15 14:17:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6JC-000240-2w for mobike-archive@megatron.ietf.org; Tue, 15 Nov 2005 14:17:34 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18993 for ; Tue, 15 Nov 2005 14:17:00 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 926B1FB283; Tue, 15 Nov 2005 19:17:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 66D30FB27C; Tue, 15 Nov 2005 19:17:28 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7256DFB280; Tue, 15 Nov 2005 19:17:26 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id C12A6FB277 for ; Tue, 15 Nov 2005 19:17:25 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8C45089863; Tue, 15 Nov 2005 21:17:23 +0200 (EET) Message-ID: <437A25B3.9050104@piuha.net> Date: Tue, 15 Nov 2005 20:15: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: Cc: mobike@machshav.com, Francis.Dupont@enst-bretagne.fr Subject: Re: [Mobike] Issue 70: Non-SAD updates (was: 51 - spi collisions) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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'm OK with Pasi's initial suggestion as updated below in his e-mail. --Jari >How about rephrasing the last paragraph to something like this? > > When performing these steps, implementations may use information > contained in the SPD, the PAD, and possibly some other > implementation-specific databases. Regardless of how exactly the > steps are implemented, it is important to remember that IP > addresses can change, and that an IP address alone does not always > uniquely identify a single IKE peer (for the same reasons as why > the combination of the remote IP address and SPI does not uniquely > identify an outbound IPsec SA; see Appendix A.1). Thus, in steps 1 > and 2 it may be easier to identify the "right peer" using its > authenticated identity instead of its current IP address. However, > these implementation details are beyond the scope of this > specification. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 15 14:27:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6Sc-0004S5-He for mobike-archive@megatron.ietf.org; Tue, 15 Nov 2005 14:27:18 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19733 for ; Tue, 15 Nov 2005 14:26:45 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 51D06FB283; Tue, 15 Nov 2005 19:27:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EDCC0FB27C; Tue, 15 Nov 2005 19:27:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C84EAFB280; Tue, 15 Nov 2005 19:27:11 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 237C8FB277 for ; Tue, 15 Nov 2005 19:27:11 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 45C9E89863; Tue, 15 Nov 2005 21:27:00 +0200 (EET) Message-ID: <437A27F3.8080707@piuha.net> Date: Tue, 15 Nov 2005 20:24:51 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <13E3DA8B48E17D4C96D261A36A23FCD6D099A5@xmb-rtp-208.amer.cisco.com> <17272.52976.354312.130526@fireball.kivinen.iki.fi> In-Reply-To: <17272.52976.354312.130526@fireball.kivinen.iki.fi> Cc: Pasi.Eronen@nokia.com, mobike@machshav.com Subject: Re: [Mobike] Issue 73: Port numbers in examples X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 agree with what Tero is writing below. But from what I understood we are just describing the port numbers in the example, not adding any other new text. Correct? Tero Kivinen wrote: >Yes. We simply move all IKE traffic to port 4500 immediately when we >notice that other end supports NAT regardless whether there is NAT or >not. The IPsec SAs are still created using normal ESP packets in case >there is no NAT, and if we move behind NAT then we change those IPsec >SAs to use UDP encapsulation too. If we move away from NAT then we >again disable the UDP encapsulation of IPsec packets, but keep the IKE >traffic on port 4500. > >The reason for this is that if we would do the port switch when we >later detect NAT, it would cause the additional complexity, as >responder do not know the addresses that are going to be used in the >encapsulated packets, as initiator wouldn't had sent any packets with >those addresses and NAT wouldn't have created mapping for the packets >yet. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 15 14:51:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6qT-0008K1-1G for mobike-archive@megatron.ietf.org; Tue, 15 Nov 2005 14:51:57 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22203 for ; Tue, 15 Nov 2005 14:51:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id C8113FB283; Tue, 15 Nov 2005 19:51:53 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BE2CCFB27C; Tue, 15 Nov 2005 19:51:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DF3B8FB280; Tue, 15 Nov 2005 19:51:48 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id CAD49FB277 for ; Tue, 15 Nov 2005 19:51:47 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8CB8989863; Tue, 15 Nov 2005 21:51:39 +0200 (EET) Message-ID: <437A2DB9.8090307@piuha.net> Date: Tue, 15 Nov 2005 20:49:29 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <17272.44161.579549.977879@fireball.kivinen.iki.fi> In-Reply-To: <17272.44161.579549.977879@fireball.kivinen.iki.fi> Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 71: Failing RR (was: Do we need text about failing RR) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Tero Kivinen wrote: >I think we need new section probably after "Failure Recover and >Timeouts" explaining DPD behavior: > >X.X Dead Peer Detection > > MOBIKE protocol uses same DPD method than normal IKEv2, but as the > IP addresses might change in the MOBIKE also they should be taken > account when determing whether the other peer is alive and in sync > with address updates. This means that, if there is incoming traffic, > but that does not use current address pair, that should not be > considered to proof that the other end is alive. > > OK. Somewhat edited version below: "MOBIKE uses the same Dead Peer Detection method as normal IKEv2, but as addresses may change, it is not sufficient to just verify that the peer is alive, but also that it is synchronized with the address updates and has not, for instance, ignored an address update due to failure to complete return routability test. This means that when there are incoming IPsec packets, MOBIKE nodes SHOULD inspect the addresses used in those packets and determine that they correspond to those that should be employed. If they do not, such packets SHOULD NOT be used as evidence that the peer is able to communicate with this node and or that the peer has received all address updates." --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Nov 15 14:59:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ec6y1-00027g-WB for mobike-archive@megatron.ietf.org; Tue, 15 Nov 2005 14:59:46 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22575 for ; Tue, 15 Nov 2005 14:59:12 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 09920FB283; Tue, 15 Nov 2005 19:59:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4D886FB27C; Tue, 15 Nov 2005 19:59:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 97979FB280; Tue, 15 Nov 2005 19:59:37 +0000 (UTC) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by machshav.com (Postfix) with ESMTP id B8311FB277 for ; Tue, 15 Nov 2005 19:59:36 +0000 (UTC) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Nov 2005 14:59:36 -0500 X-IronPort-AV: i="3.97,334,1125892800"; d="scan'208"; a="75789007:sNHT24964700" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jAFJwtJv013806; Tue, 15 Nov 2005 14:59:33 -0500 (EST) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 14:59:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 15 Nov 2005 14:59:28 -0500 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD6D09D9F@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] Issue 73: Port numbers in examples Thread-Index: AcXqGpcu+0gKWdEzRr+16Z4kSvcd6wABG13A From: "Stephane Beaulieu (stephane)" To: "Jari Arkko" , "Tero Kivinen" X-OriginalArrivalTime: 15 Nov 2005 19:59:29.0376 (UTC) FILETIME=[16964600:01C5EA1F] Cc: Pasi.Eronen@nokia.com, mobike@machshav.com Subject: Re: [Mobike] Issue 73: Port numbers in examples X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Just changing the port values in the example is fine with me. The rest appears to have been confusion on my part. Stephane. > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Tuesday, November 15, 2005 1:25 PM > To: Tero Kivinen > Cc: Stephane Beaulieu (stephane); mobike@machshav.com; > Pasi.Eronen@nokia.com > Subject: Re: [Mobike] Issue 73: Port numbers in examples > > I agree with what Tero is writing below. But from what I > understood we are just describing the port numbers in the > example, not adding any other new text. Correct? > > Tero Kivinen wrote: > > >Yes. We simply move all IKE traffic to port 4500 immediately when we > >notice that other end supports NAT regardless whether there > is NAT or > >not. The IPsec SAs are still created using normal ESP > packets in case > >there is no NAT, and if we move behind NAT then we change > those IPsec > >SAs to use UDP encapsulation too. If we move away from NAT then we > >again disable the UDP encapsulation of IPsec packets, but > keep the IKE > >traffic on port 4500. > > > >The reason for this is that if we would do the port switch when we > >later detect NAT, it would cause the additional complexity, as > >responder do not know the addresses that are going to be used in the > >encapsulated packets, as initiator wouldn't had sent any > packets with > >those addresses and NAT wouldn't have created mapping for > the packets > >yet. > > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 03:27:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcIe5-0006JC-OC for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 03:27:58 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08795 for ; Wed, 16 Nov 2005 03:27:23 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D8B40FB281; Wed, 16 Nov 2005 08:27:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 776A0FB27C; Wed, 16 Nov 2005 08:27:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 05ED2FB280; Wed, 16 Nov 2005 08:27:44 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 2AC73FB262 for ; Wed, 16 Nov 2005 08:27:43 +0000 (UTC) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAG8RZZn024460; Wed, 16 Nov 2005 10:27:41 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:27:40 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:27:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Nov 2005 10:27:45 +0200 Message-ID: Thread-Topic: [Mobike] Issue 71: Failing RR (was: Do we need text about failing RR) Thread-Index: AcXqHhQNRTCj+gYLRY+l7mdiGqEHgQAaWYTQ From: To: X-OriginalArrivalTime: 16 Nov 2005 08:27:40.0305 (UTC) FILETIME=[9BAA7010:01C5EA87] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 71: Failing RR (was: Do we need text about failing RR) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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: > OK. Somewhat edited version below: > > "MOBIKE uses the same Dead Peer Detection method as normal > IKEv2, but as addresses may change, it is not sufficient to > just verify that the peer is alive, but also that it is > synchronized with the address updates and has not, for > instance, ignored an address update due to failure to complete > return routability test. This means that when there are > incoming IPsec packets, MOBIKE nodes SHOULD inspect the > addresses used in those packets and determine that they > correspond to those that should be employed. If they do not, > such packets SHOULD NOT be used as evidence that the peer is > able to communicate with this node and or that the peer has > received all address updates." Looks OK to me. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 03:33:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcIjh-00087O-Ao for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 03:33:45 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09082 for ; Wed, 16 Nov 2005 03:33:11 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 23186FB284; Wed, 16 Nov 2005 08:33:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5E42BFB280; Wed, 16 Nov 2005 08:33:40 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D2C69FB281; Wed, 16 Nov 2005 08:33:37 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id E4825FB27C for ; Wed, 16 Nov 2005 08:33:36 +0000 (UTC) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAG8StVh010514 for ; Wed, 16 Nov 2005 10:28:57 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:33:35 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 10:33:35 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Nov 2005 10:33:41 +0200 Message-ID: Thread-Topic: [Mobike] Issue 60: Addresses in IKE_SA_INIT/AUTH Thread-Index: AcXYhAO7MCLRgXhgR7Cm7N6ZbAvSPwSA6X1Q From: To: X-OriginalArrivalTime: 16 Nov 2005 08:33:35.0501 (UTC) FILETIME=[6F610BD0:01C5EA88] Subject: Re: [Mobike] Issue 60: Addresses in IKE_SA_INIT/AUTH X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Here's proposed text for issue 60. Rephrase Section 3.3 (Initial Tunnel Header Addresses [...] The addresses in the IKE_SA are initialized from the IP header of the first IKE_AUTH request. The addresses are taken from the IKE_AUTH request because IKEv2 requires changing from port 500 to 4500 if a NAT is discovered. [...] And in Section 3.9 (NAT Prohibition): [...] all messages that can update the addresses associated with the IKE_SA and/or IPsec SAs (the first IKE_AUTH request and all INFORMATIONAL requests that contain any of the following notifications: UPDATE_SA_ADDRESSES, ADDITIONAL_IP4/6_ADDRESS, NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED notification. [...] If they do not match, a response containing an UNEXPECTED_NAT_DETECTED notification is sent. [...] If the exchange initiator receives an UNEXPECTED_NAT_DETECTED notification in response to its INFORMATIONAL request, it SHOULD retry the operation several times using new INFORMATIONAL requests. Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in the IKE_AUTH exchange, it SHOULD retry IKE_SA establishment several times, starting from a new IKE_SA_INIT request. [...] Does this look OK? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 04:16:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcJPE-0002Vl-EW for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 04:16:40 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11853 for ; Wed, 16 Nov 2005 04:16:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D46FAFB283; Wed, 16 Nov 2005 09:16:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EAB93FB27C; Wed, 16 Nov 2005 09:16:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C2594FB280; Wed, 16 Nov 2005 09:16:32 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 7B4DCFB262 for ; Wed, 16 Nov 2005 09:16:31 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAG9GMsd010664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2005 11:16:22 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAG9GHh1021473; Wed, 16 Nov 2005 11:16:17 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17274.63713.702792.895626@fireball.kivinen.iki.fi> Date: Wed, 16 Nov 2005 11:16:17 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <437A27F3.8080707@piuha.net> References: <13E3DA8B48E17D4C96D261A36A23FCD6D099A5@xmb-rtp-208.amer.cisco.com> <17272.52976.354312.130526@fireball.kivinen.iki.fi> <437A27F3.8080707@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 26 min Cc: Pasi.Eronen@nokia.com, mobike@machshav.com Subject: Re: [Mobike] Issue 73: Port numbers in examples X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > I agree with what Tero is writing below. But from > what I understood we are just describing the port > numbers in the example, not adding any other new > text. Correct? That is my understanding, though I could add something about this to the design draft under the NAT-T section. Something like this at the end of 5.2.3 of the design draft: ---------------------------------------------------------------------- 5.2.3. Moving to behind NAT and back ... Enabling NAT-T has few different things, one is to enable the UDP encapsulation of ESP packets. Another is to change the IKE SA ports from port 500 to port 4500. We do not want to do unnecessary UDP encapsulation unless there is really a NAT between peers, i.e. it should only be enabled when we actually detect NAT. On the other hand as all implementations supporting NAT-T must be able to respond to port 4500 all the time, it is simpler from the protocol point of view to change the port numbers from 500 to 4500 immediately when we detect that other end supports NAT-T. This way we do not need to start changing ports when we detect NAT, which would cause complications in the to the protocol. If we would do the actual changing of the port only after we detect NAT, then the responder would not be able to use the IKE and IPsec SAs immediately after their address is changed to be behind NAT, as it would need to wait for the next packet from the initiator to see what IP and port numbers are used after the initiator changed its port from 500 to 4500. Responder would not also be able to send anything to the initiator before the initiator has sent something to responder. If we do the port number changing immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we get the rid of this problem. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 06:34:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcLY9-0002Ol-6X for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 06:34:01 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18560 for ; Wed, 16 Nov 2005 06:33:27 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 60AFAFB28B; Wed, 16 Nov 2005 11:33:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4CD3EFB286; Wed, 16 Nov 2005 11:33:51 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A2643FB289; Wed, 16 Nov 2005 11:33:49 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E8437FB285 for ; Wed, 16 Nov 2005 11:33:47 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAGBXjCL013122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2005 13:33:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAGBXije001442; Wed, 16 Nov 2005 13:33:44 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17275.6424.392296.616295@fireball.kivinen.iki.fi> Date: Wed, 16 Nov 2005 13:33:44 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <437A2DB9.8090307@piuha.net> References: <17272.44161.579549.977879@fireball.kivinen.iki.fi> <437A2DB9.8090307@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 7 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 71: Failing RR (was: Do we need text about failing RR) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > OK. Somewhat edited version below: > > "MOBIKE uses the same Dead Peer Detection > method as normal IKEv2, but as addresses may change, it is > not sufficient to just verify that the peer is alive, but also that > it is synchronized with the address updates and has not, for > instance, ignored an address update due to failure to complete > return routability test. This means that when there are incoming > IPsec packets, MOBIKE nodes SHOULD inspect the addresses used > in those packets and determine that they correspond to those > that should be employed. If they do not, such packets SHOULD > NOT be used as evidence that the peer is able to communicate > with this node and or that the peer has received all address > updates." Looks good. I was planning to add something like this to the design document (new section 5.5.2 between current 5.5.1 and 5.5.2): ---------------------------------------------------------------------- 5.5.2. Return Routability Failures If the return routability fails, we need to tear down IKE SA if we are using IKEv2 INFORMATIONAL exchanges as a return routability checks. On the other hand return routability can only fail permanently if there was an attack by the other end, thus tearing down IKE SA is suitable action in that case. There is few other cases that needs to be considered here. In the first case there is no attacker, but the selected address pair stops working immediately after the address update, before the return routability check. What happens there is that initiator does the normal address update, and that succeeds, and then responder starts return routability check. If the address pair has broken down before that the responder will never get reply back to the return routability check. The responder might still be using the old IP address pair, which could still work. The initiator might be still seeing traffic from the responder, but using the old address pair. The initiator should detect that this traffic is not using the latest address pair, and after a while it should start dead peer detection on the current address pair. If that fails, then it should find new working address pair, and update addresses to that. The responder should notice that the address pair was updated after the return routability check was started, and change the ongoing return routability check to use the new address pair. The result of that return routability check needs to be discarded as it cannot be trusted as the packets were retransmitted to different IP address. So normally responder starts new return routability check after that with the new address pair. The second case is where there is attacker along the path modifying the IP addresses. The peers will detect this as NAT and will enable NAT-T recovery of changes in the NAT mappings. If the attacker is along the path long enough to the return routability check to succeed then the normal recovery of changes in the NAT mappings will take care of the problem. If the attacker disappears before return routability is finished, but after the update we have almost similar case than last time. The only difference is now that the dead peer detection started by the initiator will succeed, as responder will reply to the addresses in the headers, not the current address pair. The initiator will then detect that the NAT mappings are changed, and it will fix the situation by doing address update. Important thing for both of these cases is that initiator needs to see that responder is both alive and synchronized with initiator address pair updates. I.e. it is not enough that other end is sending traffic to initiator, it must be also using the correct IP addresses before initiator can belive it is alive and synchronized. From the implementation point of view this means that the initiator must not consider packets having wrong IP addresses as a packets that proof the other end being alive, i.e. they do not reset the dead peer detection timers. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 06:57:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcLub-0006or-Ba for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 06:57:13 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19612 for ; Wed, 16 Nov 2005 06:56:38 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 265CDFB28D; Wed, 16 Nov 2005 11:57:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 26B2BFB284; Wed, 16 Nov 2005 11:57:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9601AFB285; Wed, 16 Nov 2005 11:57:02 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 2AC3FFB27D for ; Wed, 16 Nov 2005 11:57:01 +0000 (UTC) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jAGBuxAn016186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Nov 2005 13:57:00 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jAGBuxBE012427; Wed, 16 Nov 2005 13:56:59 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17275.7819.541304.848801@fireball.kivinen.iki.fi> Date: Wed, 16 Nov 2005 13:56:59 +0200 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 60: Addresses in IKE_SA_INIT/AUTH X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 writes: > Here's proposed text for issue 60. > > Rephrase Section 3.3 (Initial Tunnel Header Addresses > > [...] The addresses in the IKE_SA are initialized from the IP > header of the first IKE_AUTH request. > > The addresses are taken from the IKE_AUTH request because IKEv2 > requires changing from port 500 to 4500 if a NAT is discovered. > [...] > > And in Section 3.9 (NAT Prohibition): > > [...] all messages that can update the addresses associated with > the IKE_SA and/or IPsec SAs (the first IKE_AUTH request and all > INFORMATIONAL requests that contain any of the following > notifications: UPDATE_SA_ADDRESSES, ADDITIONAL_IP4/6_ADDRESS, > NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED > notification. [...] If they do not match, a response containing > an UNEXPECTED_NAT_DETECTED notification is sent. [...] > > If the exchange initiator receives an UNEXPECTED_NAT_DETECTED > notification in response to its INFORMATIONAL request, it SHOULD > retry the operation several times using new INFORMATIONAL requests. > Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in > the IKE_AUTH exchange, it SHOULD retry IKE_SA establishment > several times, starting from a new IKE_SA_INIT request. [...] > > Does this look OK? Looks ok for me. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 08:42:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNYe-00054E-Br for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 08:42:40 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25436 for ; Wed, 16 Nov 2005 08:42:07 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 37FE0FB28A; Wed, 16 Nov 2005 13:42:36 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 874BCFB284; Wed, 16 Nov 2005 13:42:32 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DB0B6FB285; Wed, 16 Nov 2005 13:42:29 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E4688FB27D for ; Wed, 16 Nov 2005 13:42:28 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 0E74289863; Wed, 16 Nov 2005 15:42:25 +0200 (EET) Message-ID: <437B28B2.2070506@piuha.net> Date: Wed, 16 Nov 2005 14:40:18 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <13E3DA8B48E17D4C96D261A36A23FCD6D099A5@xmb-rtp-208.amer.cisco.com> <17272.52976.354312.130526@fireball.kivinen.iki.fi> <437A27F3.8080707@piuha.net> <17274.63713.702792.895626@fireball.kivinen.iki.fi> In-Reply-To: <17274.63713.702792.895626@fireball.kivinen.iki.fi> Cc: Pasi.Eronen@nokia.com, mobike@machshav.com Subject: Re: [Mobike] Issue 73: Port numbers in examples X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Ok. --Jari Tero Kivinen wrote: >Jari Arkko writes: > > >>I agree with what Tero is writing below. But from >>what I understood we are just describing the port >>numbers in the example, not adding any other new >>text. Correct? >> >> > >That is my understanding, though I could add something about this to >the design draft under the NAT-T section. > >Something like this at the end of 5.2.3 of the design draft: >---------------------------------------------------------------------- >5.2.3. Moving to behind NAT and back >... > Enabling NAT-T has few different things, one is to enable the UDP > encapsulation of ESP packets. Another is to change the IKE SA ports > from port 500 to port 4500. We do not want to do unnecessary UDP > encapsulation unless there is really a NAT between peers, i.e. it > should only be enabled when we actually detect NAT. On the other > hand as all implementations supporting NAT-T must be able to respond > to port 4500 all the time, it is simpler from the protocol point of > view to change the port numbers from 500 to 4500 immediately when we > detect that other end supports NAT-T. This way we do not need to > start changing ports when we detect NAT, which would cause > complications in the to the protocol. > > If we would do the actual changing of the port only after we detect > NAT, then the responder would not be able to use the IKE and IPsec > SAs immediately after their address is changed to be behind NAT, as > it would need to wait for the next packet from the initiator to see > what IP and port numbers are used after the initiator changed its > port from 500 to 4500. Responder would not also be able to send > anything to the initiator before the initiator has sent something to > responder. If we do the port number changing immediately after the > IKE_SA_INIT and before IKE_AUTH phase, then we get the rid of this > problem. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 08:44:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNaO-0005UP-S0 for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 08:44:28 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25537 for ; Wed, 16 Nov 2005 08:43:55 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A9F44FB27D; Wed, 16 Nov 2005 13:44:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C00FFFB284; Wed, 16 Nov 2005 13:44:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C8706FB285; Wed, 16 Nov 2005 13:44:21 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id B5E84FB27D for ; Wed, 16 Nov 2005 13:44:20 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3036D89863; Wed, 16 Nov 2005 15:44:18 +0200 (EET) Message-ID: <437B2923.1020407@piuha.net> Date: Wed, 16 Nov 2005 14:42:11 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen References: <17275.7819.541304.848801@fireball.kivinen.iki.fi> In-Reply-To: <17275.7819.541304.848801@fireball.kivinen.iki.fi> Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 60: Addresses in IKE_SA_INIT/AUTH X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Ok for me too. --Jari Tero Kivinen wrote: >Pasi.Eronen@nokia.com writes: > > >>Here's proposed text for issue 60. >> >>Rephrase Section 3.3 (Initial Tunnel Header Addresses >> >> [...] The addresses in the IKE_SA are initialized from the IP >> header of the first IKE_AUTH request. >> >> The addresses are taken from the IKE_AUTH request because IKEv2 >> requires changing from port 500 to 4500 if a NAT is discovered. >> [...] >> >>And in Section 3.9 (NAT Prohibition): >> >> [...] all messages that can update the addresses associated with >> the IKE_SA and/or IPsec SAs (the first IKE_AUTH request and all >> INFORMATIONAL requests that contain any of the following >> notifications: UPDATE_SA_ADDRESSES, ADDITIONAL_IP4/6_ADDRESS, >> NO_ADDITIONAL_ADDRESSES) MUST also include a NO_NATS_ALLOWED >> notification. [...] If they do not match, a response containing >> an UNEXPECTED_NAT_DETECTED notification is sent. [...] >> >> If the exchange initiator receives an UNEXPECTED_NAT_DETECTED >> notification in response to its INFORMATIONAL request, it SHOULD >> retry the operation several times using new INFORMATIONAL requests. >> Similarly, if the initiator receives UNEXPECTED_NAT_DETECTED in >> the IKE_AUTH exchange, it SHOULD retry IKE_SA establishment >> several times, starting from a new IKE_SA_INIT request. [...] >> >>Does this look OK? >> >> > >Looks ok for me. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 08:57:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcNnR-0008Ow-Ox for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 08:57:57 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26524 for ; Wed, 16 Nov 2005 08:57:24 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 1C99DFB28A; Wed, 16 Nov 2005 13:57:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8FEC4FB284; Wed, 16 Nov 2005 13:57:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B362BFB285; Wed, 16 Nov 2005 13:57:51 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id DCEC9FB27D for ; Wed, 16 Nov 2005 13:57:50 +0000 (UTC) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jAGDvnNk032306 for ; Wed, 16 Nov 2005 15:57:50 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 15:57:45 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 16 Nov 2005 15:57:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 16 Nov 2005 15:57:52 +0200 Message-ID: Thread-Topic: MOBIKE protocol draft -06 Thread-Index: AcXqtbxUwQqwl7VnRwqiGz3l8HUh4g== From: To: X-OriginalArrivalTime: 16 Nov 2005 13:57:44.0439 (UTC) FILETIME=[B7D97870:01C5EAB5] Subject: [Mobike] MOBIKE protocol draft -06 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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've submitted a new version of draft-ietf-mobike-protocol. This version handles the remaining open issues, and should be ready for AD evaluation. A temporary copy of the draft & diffs are available from the following addresses: http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-06.txt http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-06-from-05.html http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-06-from-06.a.ht ml Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 15:50:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcUEN-000460-Mx for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 15:50:13 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23506 for ; Wed, 16 Nov 2005 15:49:37 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CED00FB28D; Wed, 16 Nov 2005 15:50:07 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1A3C3FB286; Wed, 16 Nov 2005 15:50:06 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 92492FB289; Wed, 16 Nov 2005 15:50:04 -0500 (EST) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id 5A94EFB284 for ; Wed, 16 Nov 2005 15:50:03 -0500 (EST) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EcUED-0008T5-CL; Wed, 16 Nov 2005 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: Wed, 16 Nov 2005 15:50:01 -0500 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-protocol-06.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 --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-06.txt Pages : 36 Date : 2005-11-16 This document describes the MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows hosts to update the (outer) IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations. 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-06.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-06.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-06.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-11-16145919.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-protocol-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-protocol-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-11-16145919.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 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike --NextPart-- From mobike-bounces@machshav.com Wed Nov 16 18:22:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcWbY-0004kz-Iz for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 18:22:16 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06662 for ; Wed, 16 Nov 2005 18:21:42 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A0698FB284; Wed, 16 Nov 2005 18:22:14 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86202FB286; Wed, 16 Nov 2005 18:22:11 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A13ACFB289; Wed, 16 Nov 2005 18:22:09 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 06AF6FB284 for ; Wed, 16 Nov 2005 18:22:08 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E9B5289863 for ; Thu, 17 Nov 2005 01:22:07 +0200 (EET) Message-ID: <437BBEAD.2080507@piuha.net> Date: Thu, 17 Nov 2005 01:20:13 +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 Subject: [Mobike] preliminary notes from IETF-64 MOBIKE WG X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 Please send corrections, questions, or comments to the list and/or to the chairs. http://www3.ietf.org/proceedings/05nov/minutes/mobike.txt _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Nov 16 18:36:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EcWpH-0001Qi-F9 for mobike-archive@megatron.ietf.org; Wed, 16 Nov 2005 18:36:27 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07454 for ; Wed, 16 Nov 2005 18:35:52 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 3F40EFB298; Wed, 16 Nov 2005 18:36:25 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1D0BDFB289; Wed, 16 Nov 2005 18:36:20 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 48A14FB28A; Wed, 16 Nov 2005 18:36:17 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E55C9FB286 for ; Wed, 16 Nov 2005 18:36:15 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BFB8789863 for ; Thu, 17 Nov 2005 01:36:14 +0200 (EET) Message-ID: <437BC1FC.1040900@piuha.net> Date: Thu, 17 Nov 2005 01:34:20 +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 Subject: [Mobike] protocol draft progress and end of last call discussion X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 MOBIKE protocol document WGLC ended earlier, with a number of issues raised during the process. We have since then been discussing resolutions for these issues. There were quite many issues, but fortunately most if not even all of the issues had no impact on bits on the wire. I would like to to thank everyone who reviewed the document and participated in the discussion to produce text proposals - the amount of input we have gotten has been impressive. From what I can observe, we have converged on all issues in the meeting and on the mailing list. Pasi has submitted a 06 version which is already available in the directories [1]. We are now setting some time for the WG to check that the resolutions are indeed in the -06 as planned and, if you did not participate IETF-64, that you agree with the resolutions of issues that were discussed in the meeting [2, 3] and subsequently on the list. Please verify that the issues that you raised were correctly brought to the document according to the discussion, as well as perform a "sanity check" for the -06 version. Please do this prior to 24th of November, 2005 so that we can submit the draft to AD/IESG consideration (or I-D submission if mistakes are found) by the end of next week. Jari Arkko Co-chair of the MOBIKE WG [1] http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-06.txt [2] http://www3.ietf.org/proceedings/05nov/minutes/mobike.txt [3] http://www3.ietf.org/proceedings/05nov/slides/mobike-4.ppt _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Nov 25 05:50:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efb9X-0001ZL-LQ for mobike-archive@megatron.ietf.org; Fri, 25 Nov 2005 05:50:03 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09399 for ; Fri, 25 Nov 2005 05:49:21 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id A0D76FB28D; Fri, 25 Nov 2005 05:49:59 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9262FFB286; Fri, 25 Nov 2005 05:49:57 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7442DFB289; Fri, 25 Nov 2005 05:49:55 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 35EB8FB282 for ; Fri, 25 Nov 2005 05:49:54 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 51C0C89872 for ; Fri, 25 Nov 2005 12:49:52 +0200 (EET) Message-ID: <4386EC33.8020802@piuha.net> Date: Fri, 25 Nov 2005 12:49:23 +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 References: <437BC1FC.1040900@piuha.net> In-Reply-To: <437BC1FC.1040900@piuha.net> Subject: Re: [Mobike] protocol draft progress and end of last call discussion X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 No further comments were received during this period. I also personally re-reviewed the specification today one more time and as far as I could see, it matches the consensus on the issues we had in WGLC. As a result, we will be sending the draft to the ADs. --Jari Jari Arkko wrote: >MOBIKE protocol document WGLC ended earlier, with a >number of issues raised during the process. We have >since then been discussing resolutions for these issues. >There were quite many issues, but fortunately most if >not even all of the issues had no impact on bits on the >wire. I would like to to thank everyone who reviewed >the document and participated in the discussion to >produce text proposals - the amount of input we have gotten >has been impressive. > > From what I can observe, we have converged on all issues >in the meeting and on the mailing list. Pasi has submitted >a 06 version which is already available in the directories [1]. > >We are now setting some time for the WG to check that >the resolutions are indeed in the -06 as planned and, >if you did not participate IETF-64, that you agree with >the resolutions of issues that were discussed in the meeting >[2, 3] and subsequently on the list. > >Please verify that the issues that you raised were correctly >brought to the document according to the discussion, as >well as perform a "sanity check" for the -06 version. Please >do this prior to 24th of November, 2005 so that we can submit >the draft to AD/IESG consideration (or I-D submission if mistakes >are found) by the end of next week. > >Jari Arkko >Co-chair of the MOBIKE WG > >[1] http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-06.txt >[2] http://www3.ietf.org/proceedings/05nov/minutes/mobike.txt >[3] http://www3.ietf.org/proceedings/05nov/slides/mobike-4.ppt > >_______________________________________________ >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 Fri Nov 25 08:47:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfdvQ-0008PL-GT for mobike-archive@megatron.ietf.org; Fri, 25 Nov 2005 08:47:40 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26632 for ; Fri, 25 Nov 2005 08:46:59 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D0EFBFB290; Fri, 25 Nov 2005 08:47:37 -0500 (EST) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C7FC4FB289; Fri, 25 Nov 2005 08:47:34 -0500 (EST) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D7906FB28B; Fri, 25 Nov 2005 08:47:32 -0500 (EST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 4B8DAFB24A for ; Fri, 25 Nov 2005 08:47:31 -0500 (EST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 66E1B89863 for ; Fri, 25 Nov 2005 15:47:29 +0200 (EET) Message-ID: <438715D4.2010304@piuha.net> Date: Fri, 25 Nov 2005 15:47:00 +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 References: <43871569.9020008@piuha.net> In-Reply-To: <43871569.9020008@piuha.net> Subject: [Mobike] FW: request to publish draft-ietf-mobike-protocol-06.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.6 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 FYI > Russ, > > The following I-D has completed WG LC. This is a standards > track I-D. We would like you to now take it forward. > > Title: IKEv2 Mobility and Multihoming Protocol (MOBIKE) > I-D: draft-ietf-mobike-protocol-06.txt > > > 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? > Yes. The I-D is ready for IESG review 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 specification and its design choices have been discussed on > several IETF meetings. The WGLC process resulted in an extensive > discussion and numerous in-depth reviews. Some of the reviews > were received from outside the WG, including reviews from designers > of other multihoming/mobility mechanisms and a review from the > mobility directorate. > > > 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.)? > There are no such concerns. > > > 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. > > There are no such concerns. > > > 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 consensus is solid, at least among those people who > have participated the discussion. > > There has been a small number of issues where the consensus was > not unanimous, but most of the WG supported the chosen approach > in those cases. These cases were typically related to functionality > that we chose not to include in the MOBIKE base protocol but > could potentially do it later as an extension. > > > 6) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarize what are they upset about. > > No. > > > 7) Have the chairs verified that the document adheres to _all_ of the > ID nits? (see http://www.ietf.org/ID-nits.html). > > Yes. > > 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 references are formulated correctly. There are two unpublished > normative references, RFC2401bis and IKEv2, both of which are > already in the RFC Editor's queue. > > > 9) For Standards Track and BCP documents, the IESG approval > announcement includes a writeup section with the following > sections: > > - Technical Summary > > This specification describes MOBIKE, a mobility and multihoming > extension to Internet Key Exchange (IKEv2). This protocol > allows hosts to update the IP addresses associated with IKEv2 > and tunnel mode IPsec Security Associations. 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. > > - Working Group Summary > > The document has been presented at several IETF WG meetings and > been discussed extensively on the mailing list as well. The > document has been reviewed by a number of experts from different > areas. The working group last call resulted in a fairly large > number of issues, but only few (maybe just one) affects the > on-the-wire protocol. All issues have been addressed in > the current version of the I-D. There is consensus in the WG > to publish this I-D as a proposed standard. > > - Protocol Quality > > The basic MOBIKE idea is very simple. The hardest parts > of the protocol involve its co-existence with NAT-Traversal > capabilities of IKEv2, and the use of the IKEv2 communication > channel for dynamically changing messages and addresses. > Additionally, MOBIKE is only a part of a stack which > includes reliance also on other parts. For instance, > it is the IP layer, not MOBIKE, that detects when this > node has a new IP address. > > Contributors and reviewers have included experts > in IPsec, mobility, NAT traversal, IKEv2 implementation, > and other aspects. The chairs are happy with the level > of WG participation and review that the specification has > received. > > All issues during design and protocol specification time > have been tracked on a tracker at the WG page. This > specification was a part of the early RFC Editor copy > editing experiment, and has already gone through basic > editing phase prior to WGLC. Specification is in XML2RFC > format. > > No known implementations exist at this time. MOBIKE > is currently being referenced from one other IETF WG and > one external SDO. > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike