From mobike-bounces@machshav.com Sun Oct 02 21:27:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMF6z-0001oH-40 for mobike-archive@megatron.ietf.org; Sun, 02 Oct 2005 21:27:25 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12692 for ; Sun, 2 Oct 2005 21:27:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 14C43FB2B0; Sun, 2 Oct 2005 21:27:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DC657FB2A8; Sun, 2 Oct 2005 21:27:15 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B147CFB2AA; Sun, 2 Oct 2005 21:27:13 -0400 (EDT) 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 89226FB2A4 for ; Sun, 2 Oct 2005 21:27:12 -0400 (EDT) Received: (qmail 46031 invoked from network); 3 Oct 2005 01:27:11 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.54.32 with login) by smtp108.sbc.mail.mud.yahoo.com with SMTP; 3 Oct 2005 01:27:11 -0000 Message-ID: <00ce01c5c7b9$945d0b10$6401a8c0@adithya> From: "Mohan Parthasarathy" To: "MOBIKE Mailing List" Date: Sun, 2 Oct 2005 18:27:10 -0700 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 Subject: [Mobike] Comments on draft-ietf-mobike-protocol-03.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 A few comments/questions... - Section 4.4 The initiator receives a NAT_DETECTION_DESTINATION_IP notification that does not match the previous UPDATE_SA_ADDRESSES response (see Section 4.7 for a more detailed description). This does not work reliably when IKE rekeying happens which changes the IKE SPIs. The initiator is behind NAT, creates the IKE SA and notes the down the NAT_DETECTION_DESTINATION_IP notification value (hash of SPI, IP address and port). If rekeying happens sometime later but never received a NAT_DETECTION_DESTINATION_IP or received one before rekeying happened, then the hash may differ because the NAT rebooted causing ports to change OR SPIs changed because of rekeying. How do you tell the difference between the two ? According to section 4.7, the sender SHOULD send UPDATE_SA message. Though there is no harm in sending one, this case should be explained somewhere.. 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. I did not understand this step at all. If the IPsec SAs were updated, then the RR check won't be done. What is that got to do with NAT traversal ? If there are outstanding IKEv2 requests (requests for which the initiator has not yet received a reply), continues retransmitting them using the addresses in the IKE_SA (the new addresses). This does not have a corresponding section in what the responder. Though, trivial would make sense to include them. - Section 4.5 - What is the use of "NO_ADDITIONAL_ADDRESS" notification ? At least i did not see any description/hint of how one would use it. - What is the use in adding NO_NATS_ALLOWED along with ADDITIONAL_ADDRESS notification ? The receiver of ADDITIONAL_ADDRESS takes it from the notification payload and not from the IP header. Is it just that you want to include NO_NATS_ALLOWED with all possible notifications ? But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and UPDATE_SA, you take from the IP header and hence it makes sense. Why do we need it for ADDITIONAL_ADDRESS ? - The VPN gateway may have a single address but the client may have multiple addresses. In that case it is okay if it does not send ADDITIONAL_ADDRESS notification but it needs to process one from the client. The last paragraph states something different. - Section 4.7 If the initiator is behind NAT, and if he suspects that the peer is *dead*, he can send a DPD message with UPDATE_SA_ADDRESSES to recover faster. This was discussed in the mailing list sometime back. But i don't see this suggestion. Why do we have to know that the NAT mapping has changed explicitly ? If the path still does not work with UPDATE_SA_ADDRESSES, then probably the path has failed. - Section 4.9 Can we show the DPD exchange here with possible payloads ? - Section 6.1 The last paragraph talks about NO_NATS_ALLOWED. The attack of modifying the header to cause DoS attack is only possible if the attacker knows that NO_NATS_ALLOWED is carried within the payload. As payloads are encrypted, it may not be that easy always. It is easy if it is the IKE_SA_INIT message.It might be worth stating when the attack is possible. - Section 6.3 Normally such attacks would expire in a short time frame due to the lack of responses (such as transport layer acknowledgements) from the victim. However, as described in [Aura02], malicious participants would typically be able to spoof such acknowledgements and maintain the traffic flow for an extended period of time. This attack is possible because the victim does not have a valid SA for the incoming ESP traffic and never reaches the TCP layer and hence no TCP RSTs. Might be worth mentioning here. -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 03 05:51:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMMz9-0002Xp-5G for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 05:51:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17254 for ; Mon, 3 Oct 2005 05:51:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 450DAFB2B0; Mon, 3 Oct 2005 05:51:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9772AFB2A8; Mon, 3 Oct 2005 05:51:38 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 846D0FB2AA; Mon, 3 Oct 2005 05:51:36 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 094DEFB2A3 for ; Mon, 3 Oct 2005 05:51:35 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D532689864; Mon, 3 Oct 2005 12:51:30 +0300 (EEST) Message-ID: <4340FF2E.4020803@piuha.net> Date: Mon, 03 Oct 2005 12:51:42 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy References: <00ce01c5c7b9$945d0b10$6401a8c0@adithya> In-Reply-To: <00ce01c5c7b9$945d0b10$6401a8c0@adithya> Cc: MOBIKE Mailing List Subject: Re: [Mobike] Comments on draft-ietf-mobike-protocol-03.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 Hi Mohan, and thanks a lot for your comments! Pasi, can you register this as an issue? Or break down per section, Mohan's issues are quite separate below. Inline: >A few comments/questions... > > - Section 4.4 > > The initiator receives a NAT_DETECTION_DESTINATION_IP notification > that does not match the previous UPDATE_SA_ADDRESSES response (see > Section 4.7 for a more detailed description). > > This does not work reliably when IKE rekeying happens which changes the IKE SPIs. > The initiator is behind NAT, creates the IKE SA and notes the down the > NAT_DETECTION_DESTINATION_IP notification value (hash of SPI, > IP address and port). If rekeying happens sometime later but never received > a NAT_DETECTION_DESTINATION_IP or received one before rekeying happened, > then the hash may differ because the NAT rebooted causing ports to change OR SPIs > changed because of rekeying. How do you tell the difference between the two ? > According to section 4.7, the sender SHOULD send UPDATE_SA message. Though > there is no harm in sending one, this case should be explained somewhere.. > > I think you are correct. I agree though that this does not cause a serious problem. > 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. > > I did not understand this step at all. If the IPsec SAs were updated, then the > RR check won't be done. What is that got to do with NAT traversal ? > > Good question. I don't they have much to do with each other. It seems that the actions in this step should be done in any case. Also, "enables NAT traversal" is a bit vague. Presumably we are sending payloads and making specific actions on the results of seeing payloads come back. > If there are outstanding IKEv2 requests (requests for which the > initiator has not yet received a reply), continues retransmitting > them using the addresses in the IKE_SA (the new addresses). > > This does not have a corresponding section in what the responder. Though, trivial > would make sense to include them. > > Yes. >- Section 4.5 > - What is the use of "NO_ADDITIONAL_ADDRESS" notification ? At least i did not > see any description/hint of how one would use it. > > Missing text, I think. Section 4.5 or 5.3 should include something along the following lines: The ADDITIONAL_*_ADDRESS notification MUST be used when there's more than one address to be communicated to the peer. The NO_ADDITIONAL_ADDRESSES notification MUST be used when there is only one address, and the peer was previously informed of multiple addresses. As a result, NO_ADDITIONAL_ADDRESSES notification is not needed in the initial IKEv2 exchange, and the ADDITIONAL_*_ADDRESSES notification is needed in the the initial exchange only if there is more than one address. > - What is the use in adding NO_NATS_ALLOWED along with ADDITIONAL_ADDRESS > notification ? The receiver of ADDITIONAL_ADDRESS takes it from the notification payload > and not from the IP header. Is it just that you want to include NO_NATS_ALLOWED with > all possible notifications ? But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA > _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and UPDATE_SA, you > take from the IP header and hence it makes sense. Why do we need it for ADDITIONAL_ADDRESS ? > > I can't answer this. Pasi? > - The VPN gateway may have a single address but the client may have multiple addresses. > In that case it is okay if it does not send ADDITIONAL_ADDRESS notification but > it needs to process one from the client. The last paragraph states something different. > > Agreed, this is an issue. I think we wanted to say that clients that do not intend to use more than one address do not have to send ADDITIONAL_*_ADDRESS notifications. But they still need to be able to handle them. This is a part of the basic mobike protocol that devices supporting this rfc-to-be should support. >- Section 4.7 > > If the initiator is behind NAT, and if he suspects that the peer is *dead*, he can send a DPD message > with UPDATE_SA_ADDRESSES to recover faster. This was discussed in the mailing list sometime > back. But i don't see this suggestion. Why do we have to know that the NAT mapping has changed > explicitly ? If the path still does not work with UPDATE_SA_ADDRESSES, then probably the > path has failed. > > Tero, Pasi, can you say something about this? >- Section 4.9 > Can we show the DPD exchange here with possible payloads ? > > We have an example in Section 3.2. Would that be sufficient, or do you want more? >- Section 6.1 > > The last paragraph talks about NO_NATS_ALLOWED. The attack of modifying the header > to cause DoS attack is only possible if the attacker knows that NO_NATS_ALLOWED is > carried within the payload. As payloads are encrypted, it may not be that easy always. It is > easy if it is the IKE_SA_INIT message.It might be worth stating when the attack is possible. > > Right. Thanks for spotting this! >- Section 6.3 > > Normally such attacks would expire in a short time frame due to the > lack of responses (such as transport layer acknowledgements) from the > victim. However, as described in [Aura02], malicious participants > would typically be able to spoof such acknowledgements and maintain > the traffic flow for an extended period of time. > > This attack is possible because the victim does not have a valid SA for the incoming > ESP traffic and never reaches the TCP layer and hence no TCP RSTs. Might be worth > mentioning here. > > Ok. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 03 10:21:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRCE-0001yj-9q for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 10:21:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03884 for ; Mon, 3 Oct 2005 10:21:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C6724FB2B0; Mon, 3 Oct 2005 10:21:30 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4E5E3FB2A8; Mon, 3 Oct 2005 10:21:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8B0CEFB2AD; Mon, 3 Oct 2005 10:21:26 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id B7000FB2A4 for ; Mon, 3 Oct 2005 10:21:25 -0400 (EDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j93ELLXi013740 for ; Mon, 3 Oct 2005 17:21:24 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 17:21:21 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 17:20:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Oct 2005 17:20:30 +0300 Message-ID: Thread-Topic: Issue list status & plea for help Thread-Index: AcXIJZuwEhxxSy1KRXeIKrXflva4iA== From: To: X-OriginalArrivalTime: 03 Oct 2005 14:20:30.0127 (UTC) FILETIME=[9BAFEBF0:01C5C825] Subject: [Mobike] Issue list status & plea for help 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 have now marked all the issues on the issue list as closed. If we re-visit any of the topics later (which hopefully we don't), they will get new issue numbers. A couple of pleas for help from the issue list maintainer: - If you have many comments, please send them in several messages; this makes it much easier to track their status! Of course, not every typo needs a separate message, but if you have more than, say, 50 lines of comments, please split them. - Be constructive: just pointing out problems or saying "I didn't understand Section X.Y" is not forbidden, but it's much better to say what you would like to see changed in the document. Do you want a technical change in the protocol, or just rewording the description? Adding new functionality to the protocol? Or perhaps you don't want any changes, but are just asking a question about the protocol? (sometimes it's not easy to tell these apart) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 03 10:45:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRZS-0005UL-J5 for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 10:45:39 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08675 for ; Mon, 3 Oct 2005 10:45:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9A3BCFB29B; Mon, 3 Oct 2005 10:45:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F0426FB281; Mon, 3 Oct 2005 10:45:31 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A1327FB283; Mon, 3 Oct 2005 10:45:30 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id B9655FB27C for ; Mon, 3 Oct 2005 10:45:29 -0400 (EDT) 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 j93Egm7V006934; Mon, 3 Oct 2005 17:42:52 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 17:45:23 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 17:45:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Oct 2005 17:45:21 +0300 Message-ID: Thread-Topic: [Mobike] Issue 44: NAT mapping changes and rekeying (was: Comments on draft-ietf-mobike-protocol-03.txt) Thread-Index: AcXIAF+S5DbB8/jDT/uttYp7/Q4/aQAJsMrQ From: To: , X-OriginalArrivalTime: 03 Oct 2005 14:45:22.0983 (UTC) FILETIME=[157FAB70:01C5C829] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 44: NAT mapping changes and rekeying (was: Comments on draft-ietf-mobike-protocol-03.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 Jari Arkko wrote: > Hi Mohan, and thanks a lot for your comments! > > Pasi, can you register this as an issue? Or break down per > section, Mohan's issues are quite separate below. I'm breaking this to a couple of issues... > Inline: > > >A few comments/questions... > > > > - Section 4.4 > > > > The initiator receives a NAT_DETECTION_DESTINATION_IP > > notification that does not match the previous > > UPDATE_SA_ADDRESSES response (see Section 4.7 for a more > > detailed description). > > > > This does not work reliably when IKE rekeying happens which > > changes the IKE SPIs. The initiator is behind NAT, creates > > the IKE SA and notes the down the > > NAT_DETECTION_DESTINATION_IP notification value (hash of SPI, > > IP address and port). If rekeying happens sometime later but > > never received a NAT_DETECTION_DESTINATION_IP or received one > > before rekeying happened, then the hash may differ because > > the NAT rebooted causing ports to change OR SPIs changed > > because of rekeying. How do you tell the difference between > > the two ? According to section 4.7, the sender SHOULD send > > UPDATE_SA message. Though there is no harm in sending one, > > this case should be explained somewhere.. > > I think you are correct. I agree though that this does not cause > a serious problem. Hm... yes, this is true. Any suggestions what to do about this? Would just mentioning this be sufficient? (It doesn't seem to be a serious problem, especially since IKE_SA rekeying is not done very frequently.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 03 11:08:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMRv6-0001dc-4W for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 11:08:00 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10863 for ; Mon, 3 Oct 2005 11:07:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 40704FB2B2; Mon, 3 Oct 2005 11:07:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 11148FB28D; Mon, 3 Oct 2005 11:07:49 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1063EFB2AD; Mon, 3 Oct 2005 11:07:48 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 22C07FB281 for ; Mon, 3 Oct 2005 11:07:47 -0400 (EDT) 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 j93F58jp026989; Mon, 3 Oct 2005 18:05:10 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 18:07:45 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 18:06:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Oct 2005 18:06:43 +0300 Message-ID: Thread-Topic: [Mobike] Issue 45: Clarifications to security considerations (was: Comments on draft-ietf-mobike-protocol-03.txt) Thread-Index: AcXIAF+S5DbB8/jDT/uttYp7/Q4/aQAKd2Xg From: To: , X-OriginalArrivalTime: 03 Oct 2005 15:06:47.0490 (UTC) FILETIME=[131FE220:01C5C82C] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 45: Clarifications to security considerations (was: Comments on draft-ietf-mobike-protocol-03.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 > >- Section 6.1 > > > > The last paragraph talks about NO_NATS_ALLOWED. The attack > > of modifying the header to cause DoS attack is only possible > > if the attacker knows that NO_NATS_ALLOWED is carried within > > the payload. As payloads are encrypted, it may not be that > > easy always. It is easy if it is the IKE_SA_INIT message. It > > might be worth stating when the attack is possible. > > Right. Thanks for spotting this! Er.. since the last paragraph of Section 6.1 doesn't talk about DoS attacks, what exactly should be changed there? Causing DoS by modifying a packet containing NO_NATS_ALLOWED is mentioned in Section 4.8, but the attacker doesn't need to know which packets contain NO_NATS_ALLOWED: it's probably easier to modify all of them. (And the attacker could also make a pretty good guess just by looking at the unencrypted parts of the message: e.g. exchange type and message length). > >- Section 6.3 > > > > Normally such attacks would expire in a short time frame > > due to the lack of responses (such as transport layer > > acknowledgements) from the victim. However, as described > > in [Aura02], malicious participants would typically be able > > to spoof such acknowledgements and maintain the traffic > > flow for an extended period of time. > > > This attack is possible because the victim does not have a valid > > SA for the incoming ESP traffic and never reaches the TCP layer > > and hence no TCP RSTs. Might be worth mentioning here. > > Ok. Probably the packets would not even reach the TCP layer, since their destination IP address was not correct. So TCP RSTs would not happen anyway. Jari, do you have any text to suggest? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 03 11:23:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMSA2-0005k2-SG for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 11:23:27 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12153 for ; Mon, 3 Oct 2005 11:23:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 74343FB2B1; Mon, 3 Oct 2005 11:23:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 85166FB2AA; Mon, 3 Oct 2005 11:23:16 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 84D68FB2AD; Mon, 3 Oct 2005 11:23:15 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 784C2FB2A8 for ; Mon, 3 Oct 2005 11:23:14 -0400 (EDT) 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 j93FKZOH013078; Mon, 3 Oct 2005 18:20:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 18:23:12 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Oct 2005 18:23:12 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 3 Oct 2005 18:23:10 +0300 Message-ID: Thread-Topic: [Mobike] Issue 46: Questions about additional addresses (was: Comments on draft-ietf-mobike-protocol-03.txt) Thread-Index: AcXIAF+S5DbB8/jDT/uttYp7/Q4/aQALAx6A From: To: , X-OriginalArrivalTime: 03 Oct 2005 15:23:12.0467 (UTC) FILETIME=[5E377230:01C5C82E] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 46: Questions about additional addresses (was: Comments on draft-ietf-mobike-protocol-03.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 > >- Section 4.5 > > - What is the use of "NO_ADDITIONAL_ADDRESS" > > notification ? At least i did not see any > > description/hint of how one would use it. > > Missing text, I think. Section 4.5 or 5.3 should > include something along the following lines: > > The ADDITIONAL_*_ADDRESS notification MUST be used > when there's more than one address to be communicated > to the peer. The NO_ADDITIONAL_ADDRESSES notification > MUST be used when there is only one address, and the peer > was previously informed of multiple addresses. As a result, > NO_ADDITIONAL_ADDRESSES notification is not needed > in the initial IKEv2 exchange, and the ADDITIONAL_*_ADDRESSES > notification is needed in the the initial exchange only if there > is more than one address. This is already described in Section 5.3, but I agree, the text perhaps needs some clarification.. > > - What is the use in adding NO_NATS_ALLOWED along with > > ADDITIONAL_ADDRESS notification ? The receiver of > > ADDITIONAL_ADDRESS takes it from the notification payload > > and not from the IP header. Is it just that you want to > > include NO_NATS_ALLOWED with all possible notifications ? > > But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA > > _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and > > UPDATE_SA, you take from the IP header and hence it makes > > sense. Why do we need it for ADDITIONAL_ADDRESS ? > > I can't answer this. Pasi? Because just like in the IKE_SA_INIT case, the notifications contain addresses _in_addition_ to the one used in the IP header. So we need NO_NATS_ALLOWED to protect the one in the IP header. (We could change it so that all the addresses were in ADDITIONAL_*_ADDRESS notifications, but this way it's more uniform treatment IKE_SA_INIT vs. INFORMATIONAL, and NAT-T vs. NAT prohibition.) > > - The VPN gateway may have a single address but the client > > may have multiple addresses. In that case it is okay if it > > does not send ADDITIONAL_ADDRESS notification but it needs > > to process one from the client. The last paragraph states > > something different. > > Agreed, this is an issue. I think we wanted to say that clients that > do not intend to use more than one address do not have to send > ADDITIONAL_*_ADDRESS notifications. But they still need to be able > to handle them. This is a part of the basic mobike protocol that > devices supporting this rfc-to-be should support. The text actually says that "a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or understand ADDITIONAL_*_ADDRESS notifications. This is correct: the responder in this case does not have to understand ADDITIONAL_*_ADDRESS notifications because the only time it would use the information is when its own address changes. Or in other words, even if it did understand them, it would not make any difference since the information would not be used for anything. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 03 13:28:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMU7K-0004tz-45 for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 13:28:46 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19809 for ; Mon, 3 Oct 2005 13:28:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 13770FB2B2; Mon, 3 Oct 2005 13:28:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EB2A2FB2AD; Mon, 3 Oct 2005 13:28:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BFDB4FB2AF; Mon, 3 Oct 2005 13:28:36 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id C16A4FB2A8 for ; Mon, 3 Oct 2005 13:28:34 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 53C8F89864; Mon, 3 Oct 2005 20:28:33 +0300 (EEST) Message-ID: <43416A4D.9020101@piuha.net> Date: Mon, 03 Oct 2005 20:28:45 +0300 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: mohanp@sbcglobal.net, mobike@machshav.com Subject: Re: [Mobike] Issue 46: Questions about additional addresses (was: Comments on draft-ietf-mobike-protocol-03.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 Pasi.Eronen@nokia.com wrote: >>>- Section 4.5 >>> - What is the use of "NO_ADDITIONAL_ADDRESS" >>> notification ? At least i did not see any >>> description/hint of how one would use it. >>> >>> >>Missing text, I think. Section 4.5 or 5.3 should >>include something along the following lines: >> >> The ADDITIONAL_*_ADDRESS notification MUST be used >> when there's more than one address to be communicated >> to the peer. The NO_ADDITIONAL_ADDRESSES notification >> MUST be used when there is only one address, and the peer >> was previously informed of multiple addresses. As a result, >> NO_ADDITIONAL_ADDRESSES notification is not needed >> in the initial IKEv2 exchange, and the ADDITIONAL_*_ADDRESSES >> notification is needed in the the initial exchange only if there >> is more than one address. >> >> > >This is already described in Section 5.3, but I agree, the text >perhaps needs some clarification.. > > Ok. Use your judgment to edit this in. But I think the current text on this point is vague. >>> - What is the use in adding NO_NATS_ALLOWED along with >>> ADDITIONAL_ADDRESS notification ? The receiver of >>> ADDITIONAL_ADDRESS takes it from the notification payload >>> and not from the IP header. Is it just that you want to >>> include NO_NATS_ALLOWED with all possible notifications ? >>> But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA >>> _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and >>> UPDATE_SA, you take from the IP header and hence it makes >>> sense. Why do we need it for ADDITIONAL_ADDRESS ? >>> >>> >>I can't answer this. Pasi? >> >> > >Because just like in the IKE_SA_INIT case, the notifications >contain addresses _in_addition_ to the one used in the IP header. >So we need NO_NATS_ALLOWED to protect the one in the IP header. > > Hmm. Is that address used for something, beyond responding to the request? >>> - The VPN gateway may have a single address but the client >>> may have multiple addresses. In that case it is okay if it >>> does not send ADDITIONAL_ADDRESS notification but it needs >>> to process one from the client. The last paragraph states >>> something different. >>> >>> >>Agreed, this is an issue. I think we wanted to say that clients that >>do not intend to use more than one address do not have to send >>ADDITIONAL_*_ADDRESS notifications. But they still need to be able >>to handle them. This is a part of the basic mobike protocol that >>devices supporting this rfc-to-be should support. >> >> > >The text actually says that > > "a simple "VPN gateway" that has only a single address, and is > not going to change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > >This is correct: the responder in this case does not have to >understand ADDITIONAL_*_ADDRESS notifications because the only time >it would use the information is when its own address changes. Or >in other words, even if it did understand them, it would not make >any difference since the information would not be used for anything > > Ok. Now I understand. But you still had the other part in the text that said: A minimal "mobile client" could have a policy that says that only the responder's address specified in local configuration is acceptable. I can see that such a policy is possible. But I'm not sure I see the same initiator-decides effect here than was present in the gateway side. Since the client is responsible for address selection in both, it seems that a client that does not implement gateway ADDITIONAL_*_ADDRESS payloads does not implement the full protocol. We can of course choose what our mandatory-to-implement requirements are. Does the text above mean that a minimal mobile client can choose not to implement this part of the protocol, or only that its legal to configure it so that expects a single address from the other side? I'd rather see the latter... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 03 21:46:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMbt1-0003Wo-SK for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 21:46:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03964 for ; Mon, 3 Oct 2005 21:46:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BE5DCFB2AD; Mon, 3 Oct 2005 21:46:27 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D7962FB2A3; Mon, 3 Oct 2005 21:46:23 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BB209FB2A4; Mon, 3 Oct 2005 21:46:22 -0400 (EDT) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by machshav.com (Postfix) with SMTP id CBE65FB28D for ; Mon, 3 Oct 2005 21:46:21 -0400 (EDT) Received: (qmail 89158 invoked from network); 4 Oct 2005 01:46:21 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.215.14 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 4 Oct 2005 01:46:20 -0000 Message-ID: <010501c5c885$6b9d6590$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Date: Mon, 3 Oct 2005 18:46:19 -0700 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] Issue 44: NAT mapping changes and rekeying (was:Comments on draft-ietf-mobike-protocol-03.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 > > >A few comments/questions... > > > > > > - Section 4.4 > > > > > > The initiator receives a NAT_DETECTION_DESTINATION_IP > > > notification that does not match the previous > > > UPDATE_SA_ADDRESSES response (see Section 4.7 for a more > > > detailed description). > > > > > > This does not work reliably when IKE rekeying happens which > > > changes the IKE SPIs. The initiator is behind NAT, creates > > > the IKE SA and notes the down the > > > NAT_DETECTION_DESTINATION_IP notification value (hash of SPI, > > > IP address and port). If rekeying happens sometime later but > > > never received a NAT_DETECTION_DESTINATION_IP or received one > > > before rekeying happened, then the hash may differ because > > > the NAT rebooted causing ports to change OR SPIs changed > > > because of rekeying. How do you tell the difference between > > > the two ? According to section 4.7, the sender SHOULD send > > > UPDATE_SA message. Though there is no harm in sending one, > > > this case should be explained somewhere.. > > > > I think you are correct. I agree though that this does not cause > > a serious problem. > > Hm... yes, this is true. Any suggestions what to do about this? > Would just mentioning this be sufficient? (It doesn't seem > to be a serious problem, especially since IKE_SA rekeying is > not done very frequently.) > Do we really need this functionality ? Why does the initiator need to know explicitly that the NAT mapping has changed ? The initiator behind NAT sends the DPD always with UPDATE_SA_ADDRESS. It should fix it automatically. If it does not, then the PATH is broken. Wouldn't that work ? -mohan > 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 Oct 03 23:10:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMdCQ-0004fe-Eb for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 23:10:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07449 for ; Mon, 3 Oct 2005 23:10:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 79A8BFB2B0; Mon, 3 Oct 2005 23:10:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2E2F5FB2A4; Mon, 3 Oct 2005 23:10:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 19163FB2A8; Mon, 3 Oct 2005 23:10:27 -0400 (EDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by machshav.com (Postfix) with SMTP id 061FCFB2A3 for ; Mon, 3 Oct 2005 23:10:26 -0400 (EDT) Received: (qmail 64074 invoked from network); 4 Oct 2005 03:10:25 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.215.14 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 4 Oct 2005 03:10:25 -0000 Message-ID: <011101c5c891$29e6c590$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Date: Mon, 3 Oct 2005 20:10:24 -0700 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] Issue 45: Clarifications to security considerations(was: Comments on draft-ietf-mobike-protocol-03.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 > > > > > > The last paragraph talks about NO_NATS_ALLOWED. The attack > > > of modifying the header to cause DoS attack is only possible > > > if the attacker knows that NO_NATS_ALLOWED is carried within > > > the payload. As payloads are encrypted, it may not be that > > > easy always. It is easy if it is the IKE_SA_INIT message. It > > > might be worth stating when the attack is possible. > > > > Right. Thanks for spotting this! > > Er.. since the last paragraph of Section 6.1 doesn't talk about > DoS attacks, what exactly should be changed there? > > Causing DoS by modifying a packet containing NO_NATS_ALLOWED > is mentioned in Section 4.8, but the attacker doesn't need to know > which packets contain NO_NATS_ALLOWED: it's probably easier to > modify all of them. (And the attacker could also make a pretty > good guess just by looking at the unencrypted parts of the > message: e.g. exchange type and message length). If you read the previous paragraph : This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and update the addresses appropriately.It says when and how the attack can be launched. I just thought it wouldmake sense to do the same for NO_NATS_ALLOWED. > > > >- Section 6.3> > >> > > Normally such attacks would expire in a short time frame> > > due to the lack of responses (such as transport layer> > > acknowledgements) from the victim. However, as described> > > in [Aura02], malicious participants would typically be able> > > to spoof such acknowledgements and maintain the traffic> > > flow for an extended period of time.> >> > > This attack is possible because the victim does not have a valid> > > SA for the incoming ESP traffic and never reaches the TCP layer> > > and hence no TCP RSTs. Might be worth mentioning here.> > > > Ok.> > Probably the packets would not even reach the TCP layer, since> their destination IP address was not correct. So TCP RSTs would> not happen anyway.> I thought this attack is where you establish a TCP connection, redirectto a victim, and keep sending acknowledgements ?-mohan> Jari, do you have any text to suggest?> > 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 Oct 03 23:21:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMdNL-00074R-0S for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 23:21:57 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07947 for ; Mon, 3 Oct 2005 23:21:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 76BDEFB29F; Mon, 3 Oct 2005 23:21:51 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D60FAFB282; Mon, 3 Oct 2005 23:21:46 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 489D6FB285; Mon, 3 Oct 2005 23:21:45 -0400 (EDT) Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by machshav.com (Postfix) with SMTP id 2AF87FB281 for ; Mon, 3 Oct 2005 23:21:44 -0400 (EDT) Received: (qmail 65920 invoked from network); 4 Oct 2005 03:21:43 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.215.14 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 4 Oct 2005 03:21:43 -0000 Message-ID: <012301c5c892$be049940$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Date: Mon, 3 Oct 2005 20:21:42 -0700 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] Issue 46: Questions about additional addresses (was:Comments on draft-ietf-mobike-protocol-03.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 > > > >- Section 4.5 > > > - What is the use of "NO_ADDITIONAL_ADDRESS" > > > notification ? At least i did not see any > > > description/hint of how one would use it. > > > > Missing text, I think. Section 4.5 or 5.3 should > > include something along the following lines: > > > > The ADDITIONAL_*_ADDRESS notification MUST be used > > when there's more than one address to be communicated > > to the peer. The NO_ADDITIONAL_ADDRESSES notification > > MUST be used when there is only one address, and the peer > > was previously informed of multiple addresses. As a result, > > NO_ADDITIONAL_ADDRESSES notification is not needed > > in the initial IKEv2 exchange, and the ADDITIONAL_*_ADDRESSES > > notification is needed in the the initial exchange only if there > > is more than one address. > > This is already described in Section 5.3, but I agree, the text > perhaps needs some clarification.. > So, if i informed the peer about 5 addresses, and two of my addresses became invalid, what do i do then ? Why is returning to one valid address case special ? > > > - What is the use in adding NO_NATS_ALLOWED along with > > > ADDITIONAL_ADDRESS notification ? The receiver of > > > ADDITIONAL_ADDRESS takes it from the notification payload > > > and not from the IP header. Is it just that you want to > > > include NO_NATS_ALLOWED with all possible notifications ? > > > But section 4.8 allows only with IKE_SA_INIT and UPDATE_SA > > > _ADDRESS and ADDITIONAL_ADDRESS. In the IKE_SA_INIT and > > > UPDATE_SA, you take from the IP header and hence it makes > > > sense. Why do we need it for ADDITIONAL_ADDRESS ? > > > > I can't answer this. Pasi? > > Because just like in the IKE_SA_INIT case, the notifications > contain addresses _in_addition_ to the one used in the IP header. > So we need NO_NATS_ALLOWED to protect the one in the IP header. > Then, i should be able to use NO_NATS_ALLOWED in any message to protect the IP header. Sorry, i still can't understand. > (We could change it so that all the addresses were in > ADDITIONAL_*_ADDRESS notifications, but this way it's more > uniform treatment IKE_SA_INIT vs. INFORMATIONAL, and NAT-T > vs. NAT prohibition.) > > > > - The VPN gateway may have a single address but the client > > > may have multiple addresses. In that case it is okay if it > > > does not send ADDITIONAL_ADDRESS notification but it needs > > > to process one from the client. The last paragraph states > > > something different. > > > > Agreed, this is an issue. I think we wanted to say that clients that > > do not intend to use more than one address do not have to send > > ADDITIONAL_*_ADDRESS notifications. But they still need to be able > > to handle them. This is a part of the basic mobike protocol that > > devices supporting this rfc-to-be should support. > > The text actually says that > > "a simple "VPN gateway" that has only a single address, and is > not going to change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > > This is correct: the responder in this case does not have to > understand ADDITIONAL_*_ADDRESS notifications because the only time > it would use the information is when its own address changes. Or > in other words, even if it did understand them, it would not make > any difference since the information would not be used for anything. > Hmm.. but it can still change the peer's address given in the ADDITIONAL_ADDRESS. I understand that it does not have to change. But if the client has multiple addresses and there is some connectivity problem, it can try a different address, right ? -mohan -mohan > 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 Oct 03 23:34:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMdZR-0001wZ-Vh for mobike-archive@megatron.ietf.org; Mon, 03 Oct 2005 23:34:26 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09488 for ; Mon, 3 Oct 2005 23:34:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B79CAFB2B3; Mon, 3 Oct 2005 23:34:24 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B29A1FB285; Mon, 3 Oct 2005 23:34:17 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0918DFB289; Mon, 3 Oct 2005 23:34:16 -0400 (EDT) Received: from smtp112.sbc.mail.mud.yahoo.com (smtp112.sbc.mail.mud.yahoo.com [68.142.198.211]) by machshav.com (Postfix) with SMTP id B174FFB262 for ; Mon, 3 Oct 2005 23:34:14 -0400 (EDT) Received: (qmail 6048 invoked from network); 4 Oct 2005 03:34:14 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.215.14 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 4 Oct 2005 03:34:13 -0000 Message-ID: <012901c5c894$7d520750$6401a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Date: Mon, 3 Oct 2005 20:34:12 -0700 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] Issue 45: Clarifications to security considerations(was: Comments on draft-ietf-mobike-protocol-03.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 It looks like my previous response got garbled up..so retyping it here.. > > >- Section 6.1 > > > > > > The last paragraph talks about NO_NATS_ALLOWED. The attack > > > of modifying the header to cause DoS attack is only possible > > > if the attacker knows that NO_NATS_ALLOWED is carried within > > > the payload. As payloads are encrypted, it may not be that > > > easy always. It is easy if it is the IKE_SA_INIT message. It > > > might be worth stating when the attack is possible. > > > > Right. Thanks for spotting this! > > Er.. since the last paragraph of Section 6.1 doesn't talk about > DoS attacks, what exactly should be changed there? > > Causing DoS by modifying a packet containing NO_NATS_ALLOWED > is mentioned in Section 4.8, but the attacker doesn't need to know > which packets contain NO_NATS_ALLOWED: it's probably easier to > modify all of them. (And the attacker could also make a pretty > good guess just by looking at the unencrypted parts of the > message: e.g. exchange type and message length). > Hmm.. section 6.1 contains: However, just like with normal IKEv2, the actual IP addresses in the IP header are not covered by the integrity protection. This means that a NAT between the parties (or an attacker acting as a NAT) can modify the addresses and cause incorrect tunnel header (outer) IP addresses to be used for IPsec SAs. The scope of this attack is limited mainly to denial-of-service, since all traffic is protected using IPsec. ^ It talks about DoS attack here... This attack can only be launched by on-path attackers that are capable of modifying IKEv2 messages carrying NAT detection payloads (such as Dead Peer Detection messages). By modifying the IP header of these packets, the attackers can lead the peers believe a new NAT or a changed NAT binding exists between them. The attack can continue as long as the attacker is on the path, modifying the IKEv2 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms designed to detect NAT mapping changes will eventually recognize that the intended traffic is not getting through, and update the addresses appropriately. Here, it talks about how/why an attacker can launch attacks packets that carries NAT-D payloads. So, it might make sense to explain the same for NO_NATS_ALLOWED also. One can modify all ESP packets (without knowing whether NAT-D payload is included or not) to launch the attack described in the previous paragraph, but similar things can be done things outside of MOBIKE also and hence not very interesting.. > > >- Section 6.3 > > > > > > Normally such attacks would expire in a short time frame > > > due to the lack of responses (such as transport layer > > > acknowledgements) from the victim. However, as described > > > in [Aura02], malicious participants would typically be able > > > to spoof such acknowledgements and maintain the traffic > > > flow for an extended period of time. > > > > > This attack is possible because the victim does not have a valid > > > SA for the incoming ESP traffic and never reaches the TCP layer > > > and hence no TCP RSTs. Might be worth mentioning here. > > > > Ok. > > Probably the packets would not even reach the TCP layer, since > their destination IP address was not correct. So TCP RSTs would > not happen anyway. > My understanding of this attack is the client establishes the TCP connection, redirects the stream to a victim and sends false acknowledgements ? (Similar attack exists in MIP6 and packets get discarded because of Home address option at the IP layer). -mohan > Jari, do you have any text to suggest? > > 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 Tue Oct 04 01:24:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMfHY-0008Km-7o for mobike-archive@megatron.ietf.org; Tue, 04 Oct 2005 01:24:05 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13773 for ; Tue, 4 Oct 2005 01:24:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C317CFB2A4; Tue, 4 Oct 2005 01:23:58 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 344EEFB2A4; Tue, 4 Oct 2005 01:23:55 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 71BA4FB2A8; Tue, 4 Oct 2005 01:23:53 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 62550FB2A3 for ; Tue, 4 Oct 2005 01:23:52 -0400 (EDT) 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 j945LBGw009985 for ; Tue, 4 Oct 2005 08:21:13 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Oct 2005 08:23:50 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Oct 2005 00:23:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Oct 2005 00:23:44 -0500 Message-ID: Thread-Topic: [Mobike] Issue list status & plea for help Thread-Index: AcXIJZuwEhxxSy1KRXeIKrXflva4iAAeNY/A From: To: X-OriginalArrivalTime: 04 Oct 2005 05:23:48.0639 (UTC) FILETIME=[CC848AF0:01C5C8A3] Subject: Re: [Mobike] Issue list status & plea for help 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. The fact that we are only discussing tunnel mode is not explicitly mentioned until section 3.4 in this document. There is one place in the introduction that mentions it, but only in passing. Everywhere else, it is inferred and/or assumed. Although it is said explicitly in section 3.4, but that is after we have read a lot of text without knowing this. Also, it is called limitations, rather than scope. I suggest that you move this 3.4 to section 2. and call it scope. Here is suggested text: 2. Scope The scope of this document is limited to tunnel mode as the base version of the MOBIKE protocol. --------------------------------------------------------------- Some nits: MOBIKE allows both parties to have several addresses, and there are up to N*M pairs of IP addresses that could potentially be used. The decision of which of these pairs to use has to take into account several factors. First, the parties have may preferences about which interface should be used, due to performance and cost reasons, for instance. Second, the decision is constrained by the fact that some of the pairs may not work at all due to incompatible IP versions, outages somewhere in the network, problems at the local link at either end, and so on. How about changed text indicated by *: MOBIKE allows both parties to have *multiple points of attachment each represented by an IP address*, and there are up to N*M pairs of IP addresses that could potentially be used *for the tunnel endpoints*. The decision of which of these pairs to use has to take into account several factors. First, the parties have *many* preferences about which interface should be used, due to performance and cost reasons, for instance. Second, the decision is constrained by the fact that some of the pairs may not work at all due to incompatible IP versions, outages *delete somewhere* in the network, problems at the local link at either end, and so on. -- Maureen -----Original Message----- From: mobike-bounces@machshav.com [mailto:mobike-bounces@machshav.com] Sent: Monday, October 03, 2005 10:21 AM To: mobike@machshav.com Subject: [Mobike] Issue list status & plea for help I have now marked all the issues on the issue list as closed. If we re-visit any of the topics later (which hopefully we don't), they will get new issue numbers. A couple of pleas for help from the issue list maintainer: - If you have many comments, please send them in several messages; this makes it much easier to track their status! Of course, not every typo needs a separate message, but if you have more than, say, 50 lines of comments, please split them. - Be constructive: just pointing out problems or saying "I didn't understand Section X.Y" is not forbidden, but it's much better to say what you would like to see changed in the document. Do you want a technical change in the protocol, or just rewording the description? Adding new functionality to the protocol? Or perhaps you don't want any changes, but are just asking a question about the protocol? (sometimes it's not easy to tell these apart) 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 Tue Oct 04 09:11:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMmZz-0000HM-HF for mobike-archive@megatron.ietf.org; Tue, 04 Oct 2005 09:11:36 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16946 for ; Tue, 4 Oct 2005 09:11:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5FB4DFB29F; Tue, 4 Oct 2005 09:11:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CC0FDFB28B; Tue, 4 Oct 2005 09:11:21 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 65A45FB28D; Tue, 4 Oct 2005 09:11:20 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 4FAEBFB28A for ; Tue, 4 Oct 2005 09:11:19 -0400 (EDT) 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 j94D8cI4018717; Tue, 4 Oct 2005 16:08:39 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Oct 2005 16:11:13 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Oct 2005 16:11:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 4 Oct 2005 16:11:16 +0300 Message-ID: Thread-Topic: [Mobike] Issue 47: More comments from Mohan (was: Comments on draft-ietf-mobike-protocol-03.txt) Thread-Index: AcXIAF+S5DbB8/jDT/uttYp7/Q4/aQA4h/zw From: To: , X-OriginalArrivalTime: 04 Oct 2005 13:11:13.0194 (UTC) FILETIME=[186008A0:01C5C8E5] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 47: More comments from Mohan (was: Comments on draft-ietf-mobike-protocol-03.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 Jari Arkko wrote: > > 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. > > > > I did not understand this step at all. If the IPsec SAs were > > updated, then the RR check won't be done. What is that got > > to do with NAT traversal ? > > Good question. I don't they have much to do with each other. > It seems that the actions in this step should be done in any > case. > > Also, "enables NAT traversal" is a bit vague. Presumably we > are sending payloads and making specific actions on the results > of seeing payloads come back. The reasoning is that updating the addresses in IPsec SAs and enabling/disabling NAT Traversal go together: if you don't do RR check, you do both immediately; but if you wait for the RR check to finish, you also don't toggle NAT-T before you've updated the addresses in the SA. "Enabling NAT traversal" here means starting UDP encapsulating outgoing ESP packets and sending NAT-Keepalive packets (i.e., it doesn't involve sending any IKEv2 payloads, other than those already explicitly specified in that section). How about adding "(i.e., enables UDP encapsulation of outgoing ESP packets and sending of NAT-Keepalive packets)" there? > > If there are outstanding IKEv2 requests (requests for > > which the initiator has not yet received a reply), > > continues retransmitting them using the addresses in > > the IKE_SA (the new addresses). > > > > This does not have a corresponding section in what the > > responder. Though, trivial would make sense to include > > them. > > Yes. The responder processes the requests as usual: if the request was CREATE_CHILD_SA, creates the new SA or something, etc. Note that the responder's part start with this text: When processing an INFORMATIONAL request containing the UPDATE_SA_ADDRESSES notification, the responder: so I'm not sure what should be added here? > >- Section 4.7 > > > > If the initiator is behind NAT, and if he suspects > > that the peer is *dead*, he can send a DPD message > > with UPDATE_SA_ADDRESSES to recover faster. This was > > discussed in the mailing list sometime back. But i > > don't see this suggestion. Why do we have to know that > > the NAT mapping has changed explicitly ? If the path > > still does not work with UPDATE_SA_ADDRESSES, then > > probably the path has failed. > > Tero, Pasi, can you say something about this? Knowing that the NAT mapping has changed might be useful, since it allows you to adjust the keepalive interval. But the initiator could also send the UPDATE_SA_ADDRESSES immediately. How about adding "The initiator MAY also omit the separate exchange to detect the change in NAT mappings, and instead send UPDATE_SA_ADDRESSES immediately when doing dead peer detection." to 3rd paragraph of Section 4.7? > >- Section 4.9 > > Can we show the DPD exchange here with possible > > payloads ? > > We have an example in Section 3.2. Would that be sufficient, > or do you want more? There is no "DPD exchange" in IKEv2; any INFORMATIONAL exchange confirms the peer is alive (and thus it can include whatever payloads any other INFORMATIONAL exchange includes). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 04 11:35:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EMooz-0004AP-DE for mobike-archive@megatron.ietf.org; Tue, 04 Oct 2005 11:35:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02703 for ; Tue, 4 Oct 2005 11:35:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2B1AFFB2A4; Tue, 4 Oct 2005 11:35:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9E81CFB28D; Tue, 4 Oct 2005 11:35:02 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5F4B9FB29F; Tue, 4 Oct 2005 11:35:01 -0400 (EDT) Received: from fridge.docomolabs-usa.com (key1.docomolabs-usa.com [216.98.102.225]) by machshav.com (Postfix) with ESMTP id 84EBFFB28B for ; Tue, 4 Oct 2005 11:35:00 -0400 (EDT) Message-ID: <039c01c5c8f9$30481750$196115ac@dcml.docomolabsusa.com> From: "James Kempf" To: , References: Date: Tue, 4 Oct 2005 08:35:03 -0700 MIME-Version: 1.0 Subject: Re: [Mobike] Issue list status & plea for help 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 Maureen, Yes, I noticed this as well. I'd suggest including it even earlier, in the abstract: ...MOBIKE allows hostst to update the (outer) IP addresses associated with IKEv2 and **tunnel mode** IPsec Security Associations... jak ----- Original Message ----- From: To: Sent: Monday, October 03, 2005 10:23 PM Subject: Re: [Mobike] Issue list status & plea for help > OK. > > The fact that we are only discussing tunnel mode is not explicitly > mentioned until section 3.4 in this document. There is one place in the > introduction that mentions it, but only in passing. Everywhere else, it > is inferred and/or assumed. Although it is said explicitly in section > 3.4, but that is after we have read a lot of text without knowing this. > Also, it is called limitations, rather than scope. I suggest that you > move this 3.4 to section 2. and call it scope. > > Here is suggested text: > > 2. Scope > > The scope of this document is limited to tunnel mode as the base version > of the MOBIKE protocol. > > --------------------------------------------------------------- > Some nits: > > MOBIKE allows both parties to have several addresses, and there are > up to N*M pairs of IP addresses that could potentially be used. The > decision of which of these pairs to use has to take into account > several factors. First, the parties have may preferences about which > interface should be used, due to performance and cost reasons, for > instance. Second, the decision is constrained by the fact that some > of the pairs may not work at all due to incompatible IP versions, > outages somewhere in the network, problems at the local link at > either end, and so on. > > How about changed text indicated by *: > > MOBIKE allows both parties to have *multiple points of attachment each > represented by an IP address*, and there are > up to N*M pairs of IP addresses that could potentially be used *for > the tunnel endpoints*. The > decision of which of these pairs to use has to take into account > several factors. First, the parties have *many* preferences about > which > interface should be used, due to performance and cost reasons, for > instance. Second, the decision is constrained by the fact that some > of the pairs may not work at all due to incompatible IP versions, > outages *delete somewhere* in the network, problems at the local link > at > either end, and so on. > > -- Maureen > > > > > > -----Original Message----- > From: mobike-bounces@machshav.com [mailto:mobike-bounces@machshav.com] > Sent: Monday, October 03, 2005 10:21 AM > To: mobike@machshav.com > Subject: [Mobike] Issue list status & plea for help > > I have now marked all the issues on the issue list as closed. > If we re-visit any of the topics later (which hopefully we don't), > they will get new issue numbers. > > A couple of pleas for help from the issue list maintainer: > > - If you have many comments, please send them in several > messages; this makes it much easier to track their status! > Of course, not every typo needs a separate message, but if > you have more than, say, 50 lines of comments, please split > them. > > - Be constructive: just pointing out problems or saying "I didn't > understand Section X.Y" is not forbidden, but it's much better > to say what you would like to see changed in the document. Do > you want a technical change in the protocol, or just rewording > the description? Adding new functionality to the protocol? > Or perhaps you don't want any changes, but are just asking a > question about the protocol? (sometimes it's not easy to tell > these apart) > > 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 _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 05 22:03:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENL6p-00044V-Q5 for mobike-archive@megatron.ietf.org; Wed, 05 Oct 2005 22:03:48 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15966 for ; Wed, 5 Oct 2005 22:03:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BCCABFB27D; Wed, 5 Oct 2005 22:03:41 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C61CCFB280; Wed, 5 Oct 2005 22:03:37 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C98DDFB284; Wed, 5 Oct 2005 22:03:36 -0400 (EDT) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by machshav.com (Postfix) with SMTP id 845F2FB27D for ; Wed, 5 Oct 2005 22:03:35 -0400 (EDT) Received: (qmail 71975 invoked from network); 6 Oct 2005 02:03:32 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.55.253 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 6 Oct 2005 02:03:32 -0000 Message-ID: <007401c5ca1a$2ac04010$6501a8c0@adithya> From: "Mohan Parthasarathy" To: References: <004d01c5ca16$f9567010$6501a8c0@adithya> Date: Wed, 5 Oct 2005 19:03:37 -0700 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 Mailing List , jari.arkko@piuha.net Subject: Re: [Mobike] Issue 47: More comments from Mohan (was: Comments ondraft-ietf-mobike-protocol-03.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 > > The reasoning is that updating the addresses in IPsec SAs and > > enabling/disabling NAT Traversal go together: if you don't do RR > > check, you do both immediately; but if you wait for the RR check to > > finish, you also don't toggle NAT-T before you've updated the > > addresses in the SA. > > Ah! that makes sense. > > "Enabling NAT traversal" here means starting UDP encapsulating > > outgoing ESP packets and sending NAT-Keepalive packets (i.e., > > it doesn't involve sending any IKEv2 payloads, other than those > > already explicitly specified in that section). > > > > How about adding "(i.e., enables UDP encapsulation of outgoing ESP > > packets and sending of NAT-Keepalive packets)" there? > > Perhaps, instead of adding, just replace "enabling NAT traversal" with explicit text like what you suggest above. At the end of the same section, there is similar text "enable/disable NAT traversal". Perhaps, that also should say the same thing. > > > > If there are outstanding IKEv2 requests (requests for > > > > which the initiator has not yet received a reply), > > > > continues retransmitting them using the addresses in > > > > the IKE_SA (the new addresses). > > > > > > > > This does not have a corresponding section in what the > > > > responder. Though, trivial would make sense to include > > > > them. > > > > > > Yes. > > > > The responder processes the requests as usual: if the request > > was CREATE_CHILD_SA, creates the new SA or something, etc. > > Note that the responder's part start with this text: > > > > When processing an INFORMATIONAL request containing the > > UPDATE_SA_ADDRESSES notification, the responder: > > > > so I'm not sure what should be added here? > > But this does not cover the above case. When the window is closed, you are retransmitting requests/responses that does not contain the UPDATE_SA_ADDRESSES. So, it has to be included somewhere to say that "when the responder sees packets coming in with new addresses, it should not update the SA if MOBIKE is enabled". According to the IKEv2 base spec, the IKE SA will be updated if a NAT was detected earlier. > > > >- Section 4.7 > > > > > > > > If the initiator is behind NAT, and if he suspects > > > > that the peer is *dead*, he can send a DPD message > > > > with UPDATE_SA_ADDRESSES to recover faster. This was > > > > discussed in the mailing list sometime back. But i > > > > don't see this suggestion. Why do we have to know that > > > > the NAT mapping has changed explicitly ? If the path > > > > still does not work with UPDATE_SA_ADDRESSES, then > > > > probably the path has failed. > > > > > > Tero, Pasi, can you say something about this? > > > > Knowing that the NAT mapping has changed might be useful, since > > it allows you to adjust the keepalive interval. But the initiator > > could also send the UPDATE_SA_ADDRESSES immediately. > > > > How about adding "The initiator MAY also omit the separate > > exchange to detect the change in NAT mappings, and instead send > > UPDATE_SA_ADDRESSES immediately when doing dead peer detection." > > to 3rd paragraph of Section 4.7? > > But we still have a problem with the current approach right ? How are we going to fix that ? My experience with NAT keepalives has lead to a very conservative approach :-) If it is 45 seconds, your timer should be around 40 seconds or less to be completely sure that it works always. > > > >- Section 4.9 > > > > Can we show the DPD exchange here with possible > > > > payloads ? > > > > > > We have an example in Section 3.2. Would that be sufficient, > > > or do you want more? > > > > There is no "DPD exchange" in IKEv2; any INFORMATIONAL exchange > > confirms the peer is alive (and thus it can include whatever > > payloads any other INFORMATIONAL exchange includes). > > But i saw some exchange earlier in the draft. My only intent is to show the possible payloads that can be sent along with this from the MOBIKE perspective. -mohan > > 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 Fri Oct 07 07:47:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENqh3-0004VQ-DV for mobike-archive@megatron.ietf.org; Fri, 07 Oct 2005 07:47:19 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12571 for ; Fri, 7 Oct 2005 07:47:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 66D5AFB282; Fri, 7 Oct 2005 11:47:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 30182FB27C; Fri, 7 Oct 2005 11:47:07 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8744EFB280; Fri, 7 Oct 2005 11:47:05 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 0BF7AFB277 for ; Fri, 7 Oct 2005 11:47:04 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A487E89870; Fri, 7 Oct 2005 14:47:01 +0300 (EEST) Message-ID: <43466041.7040207@piuha.net> Date: Fri, 07 Oct 2005 14:47:13 +0300 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: <64A531765B7C8342BFA260497BE00457071CC258@RED-MSG-43.redmond.corp.microsoft.com> In-Reply-To: <64A531765B7C8342BFA260497BE00457071CC258@RED-MSG-43.redmond.corp.microsoft.com> Cc: Tuomas Aura Subject: [Mobike] FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03 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 Tuomas Aura wrote: >The security considerations section covers well the important issues. However, I have the following comments and questions. > >Comment 1: > >As explained in the security considerations section 6.1, an attacker can spoof the source address of UPDATE_SA_ADDRESSES and, thus, cause the responder to record the wrong address for the initiator. Essentially, the attacker behaves as a NAT for selected messages. I'd like to add the following observations: > >- Mobike hosts are more vulnerable to this attack than non-Mobike hosts that are behind a NAT and use IKE NAT-T negotiation (e.g., VPN clients at a home LAN). This is because a mobile host is more likely to visits untrusted access networks and to be exposed to attackers at its local link. > >- The sender-authentication of the address updates in Mobike is weaker than it is in other mobility protocols like Mobile IPv6 or HIP where the mobile's new address is included in the authenticated part of the location update. This may be surprising because Mobike uses the strong authentication provided by IKE. > >- As a possible defense mechanism, the initiator local policy can be configured to send NO_NATS_ALLOWED if and only if the initiator address at the local link is private or link-local. This does not require any changes to the specification. > >- As another defense mechanism, the responder could reject address updates where the initiator moves between two addresses on the same local link. This would prevent attacks by the most likely type of attacker that is on the same local link as the initiator and uses its own address as the spoofed source address. In IPv6, it is obvious which addresses are on the same local link. It should probably be the initiator that makes the decision about such a policy, in the same way as the initiator can decide whether to use NO_NAT_ALLOWED. In IPv4, the address mask would need to be communicated to the responder. I haven't considered the details. > >Comment 2: > >If the initiator does not support NAT traversal, is it required to send the NO_NATS_ALLOWED payload? Looks like this would make sense but I cannot find it anywhere in the spec. Or does it make sense for an initiator to behave otherwise. > >Comment 3: > >Does the SA recover from the attack of comment 1 if NAT traversal is not in use? > >Consider an initiator and responder at least one of which does not support NAT traversal, or an initiator that sends NO_NATS_ALLOWED. The attacker is located on the route between the initiator and the responder, for example, at the initiator's local link. The attacker intercepts the UPDATE_IP_ADDRESS notification, modifies its source address to be the attacker's address, and forwards the packet to the responder. The attacker receives the response and forwards it to the initiator. That is, the attacker behaves like a NAT for this one address pair. The result is that the responder has records the wrong address for the initiator. Moreover, the result of the NAT traversal negotiation is that NAT traversal will not be used between these two end hosts. The attacker now stops interfering with packets and leaves the network. Can the SA recover? > >The security considerations section 6.1 refers to "IKEv2 and Mobile mechanisms designed to detect NAT mapping changes" as the recovery mechanism. But these mechanisms will not kick in after the above attack because NAT traversal is not in use. It looks like the SA won't recover from this attack. Or is there some other recovery mechanism that I have missed? > >Comment 4: > >IPsec SAs are identified by the pair. Normally, these identifiers are unique for inbound SAs destination host is responsible for allocating the SPIs and for outbound SAs because the destination address identifies a unique host. In Mobike, the latter is no longer true. That is, identifier collisions may occur for outbound SAs at the responder. > >Consider the following example of an accidental collision: I1 and I2 are honest initiators that both have an SA with the same honest responder R. The outbound SAs from R happen, by change, to have the same SPI. (This is ok because the destination IP addresses differ.) I1 is first located at the address A1 and I2 is located at the address A2. Thus, tunnel-mode ESP packets from R to I1 have A1 as the outer destination address and I1 as the inner destination address; tunnel-mode ESP packets from R to I2 have A2 as the outer destination address and I2 as the inner destination address. Now, I2 becomes disconnected from the network and I1 moves to its old address A2. I1 sends the UPDATE_IP_ADDRESS notification to R. R updates the outbound SA to point to A2. It now has two outbound SAs with the same identifier . Can Mobike implementations cope with this? (Consider also a situation where both SAs were created from the same SPD entry with the destination addresses populated f rom packets.) > >One policy for dealing with accidental collisions of is to evict either the unchanged or the changed SA from SAD. Unfortunately, both policies enable a DoS attacks. If the unchanged SA is evicted, an attacker that sees a packet from R to I1 and learns the SPI can intentionally create another SA with the same SPI and then cause the collision. If the changed SA is evicted, the attacker can squat the pair if it knows the address to which the initiator will next move. In both cases, the result is the loss of the target SA. Both attacks require the attacker to be either at the initiator's local link or on the route between the initiator and the responder. > >While these attacks do not appear very serious, it is better to manage outbound SAs at the responder in such a way that collisions can be tolerated. Some implementations probably work like this already. > >Tuomas > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 07 11:32:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENuDH-0006WU-D4 for mobike-archive@megatron.ietf.org; Fri, 07 Oct 2005 11:32:48 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25702 for ; Fri, 7 Oct 2005 11:32:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DC16BFB27F; Fri, 7 Oct 2005 15:32:44 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1FC64FB27F; Fri, 7 Oct 2005 15:32:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94084FB280; Fri, 7 Oct 2005 15:32:39 +0000 (UTC) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 7EDBDFB27D for ; Fri, 7 Oct 2005 15:32:38 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j97FWbFE007512 for ; Fri, 7 Oct 2005 18:32:37 +0300 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 18:32:33 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Oct 2005 10:32:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Oct 2005 10:32:02 -0500 Message-ID: Thread-Topic: Re: [Mobike] Comments on draft-ietf-mobike-protocol-03.txt Thread-Index: AcXLVEMEjcmIMd/+TDq0gHbOes1baw== From: To: X-OriginalArrivalTime: 07 Oct 2005 15:32:04.0261 (UTC) FILETIME=[44D7C550:01C5CB54] Subject: Re: [Mobike] Comments on draft-ietf-mobike-protocol-03.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 These comments are all editorial. 4.7 Changes in NAT Mappings In MOBIKE, these messages can also be used to detect if NAT mappings have changed (for example, if the keepalive internal is too long, or the NAT box is rebooted). I think you meant to say keepalive interval not keepalive internal. ------------------------------------------------------- 5. Payload formats 5.1 MOBIKE_SUPPORTED Notify Payload I think these headers and text should more closely match what is in IKEv2. Also these messages should be split between what is an error, 5.5 and 5.8, and what is a status message all the rest. This is also how the split is done in IKEv2. See the template and text below which I stole from IKEv2. Here is the new suggested text: 5. Notify Payload The Notify Payload, denoted N in this document, is used to transmit informational data, such as error conditions and state transitions, to an IKE peer. A Notify Payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL Exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request. MOBIKE protocol message exchanges use the IKEv2 notify payload as specified below. 5.1 Notify Message Types Notify Messages - Status Types Value ---------------------------------------------- MOBIKE_SUPPORTED ADDITIONAL_IPv4/6_ADDRESS Etc. Notify Messages - Error Types Value ---------------------------------------------- UNACCEPTABLE ADDRESSES UNEXPECTED_NAT_DETECTED ----------------------------------------------------------------------- In addition, you might want to put in the format of the Notify payload. Again, this is taken directly from the IKEv2 document. If you decide to do this, it would be placed at the end of the section 5. but directly preceding 5.1. The Notify Payload 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID ! SPI Size ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Notification Payload Format o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications which do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE_SA, the SPI Size MUST be zero. o Notify Message Type (2 octets) - Specifies the type of notification message. o SPI (variable length) - Security Parameter Index. o Notification Data (variable length) - Informational or error data transmitted in addition to the Notify Message Type. Values for this field are type specific (see below). ------------------------------------------------------------------------ ---- The suggestion to put in the notify payload format is optional. The other suggestions I think are more relevant. -- Maureen _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 07 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 1ENyEP-0005Jg-01 for mobike-archive@megatron.ietf.org; Fri, 07 Oct 2005 15:50:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10476 for ; Fri, 7 Oct 2005 15:50:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9BFDEFB281; Fri, 7 Oct 2005 19:50:09 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 93074FB27C; Fri, 7 Oct 2005 19:50:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DCDE4FB27D; Fri, 7 Oct 2005 19:50:03 +0000 (UTC) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id 2DD32FB277 for ; Fri, 7 Oct 2005 19:50:03 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ENyEE-0000gQ-53; Fri, 07 Oct 2005 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 07 Oct 2005 15:50:02 -0400 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION: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: , 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-04.txt Pages : 30 Date : 2005-10-7 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 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-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-protocol-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-protocol-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-7115017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-protocol-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-7115017.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 Fri Oct 07 17:17:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ENzav-0001b2-4u for mobike-archive@megatron.ietf.org; Fri, 07 Oct 2005 17:17:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25215 for ; Fri, 7 Oct 2005 17:17:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 01C8CFB285; Fri, 7 Oct 2005 21:17:30 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D5186FB27D; Fri, 7 Oct 2005 21:17:26 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BC0C6FB27D; Fri, 7 Oct 2005 21:17:25 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 1F062FB24F for ; Fri, 7 Oct 2005 21: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 0AC2F89870; Sat, 8 Oct 2005 00:17:22 +0300 (EEST) Message-ID: <4346E5EF.9080503@piuha.net> Date: Sat, 08 Oct 2005 00:17:35 +0300 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 Cc: Paul Hoffman Subject: [Mobike] WG Last Call the MOBIKE Protocol 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 are now starting the official Working Group Last Call on the protocol document: http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-04.txt The last call will end on Wednesday, October 19th, 2005*. If you have not already started reading and verifying that the specification is as you want it to be, please start doing so NOW. This is your FINAL opportunity to comment on this protocol. Jari & Paul *) As announced earlier we are cutting the last call period a few days short in order to give Pasi some time to edit and submit before the October 24th I-D deadline. Note that since -04 revision consists entirely of RFC Editor's copy editing changes, the technical content has been available for review already since the publication of the -03 draft, and indeed we've already received a number of good review comments. Keep the coming! _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Oct 08 00:11:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EO63r-0003QA-DR for mobike-archive@megatron.ietf.org; Sat, 08 Oct 2005 00:11:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15654 for ; Sat, 8 Oct 2005 00:11:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 97B58FB293; Sat, 8 Oct 2005 04:11:47 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 35DFDFB286; Sat, 8 Oct 2005 04:11:45 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C2934FB28A; Sat, 8 Oct 2005 04:11:40 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 35E22FB285 for ; Sat, 8 Oct 2005 04:11:40 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3C43189870 for ; Sat, 8 Oct 2005 07:11:34 +0300 (EEST) Message-ID: <43474702.5000205@piuha.net> Date: Sat, 08 Oct 2005 07:11:46 +0300 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] MOBIKE meeting slot in Vancouver 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 This is our meeting slot in the current plan (subject to change): WEDNESDAY, November 9, 2005 1300-1500 Afternoon Session I APP geopriv Geographic Location/Privacy WG APP sieve Sieve Mail Filtering Language WG INT nemo Network Mobility WG INT trill Transparent Interconnection of Lots of Links WG RTG l1vpn Layer 1 Virtual Private Networks WG SEC inch Extended Incident Handling WG SEC mobike IKEv2 Mobility and Multihoming WG TSV sipping Session Initiation Protocol Investigation WG _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Oct 08 06:57:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOCOM-0000Uj-ST for mobike-archive@megatron.ietf.org; Sat, 08 Oct 2005 06:57:27 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14196 for ; Sat, 8 Oct 2005 06:57:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6F3ABFB291; Sat, 8 Oct 2005 10:57:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 27ED0FB286; Sat, 8 Oct 2005 10:57:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A6A4AFB28A; Sat, 8 Oct 2005 10:57:18 +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 7883DFB285 for ; Sat, 8 Oct 2005 10:57:17 +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 j98Av4827598; Sat, 8 Oct 2005 12:57:04 +0200 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 j98Av4xI078580; Sat, 8 Oct 2005 12:57:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510081057.j98Av4xI078580@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Sat, 08 Oct 2005 00:17:35 +0300. <4346E5EF.9080503@piuha.net> Date: Sat, 08 Oct 2005 12:57:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman Subject: Re: [Mobike] WG Last Call the MOBIKE Protocol 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 are now starting the official Working Group Last Call on the protocol document: http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-04.txt => is the delta between 03 and 04 available and small? The last call will end on Wednesday, October 19th, 2005*. If you have not already started reading and verifying that the specification is as you want it to be, please start doing so NOW. This is your FINAL opportunity to comment on this protocol. => it is not FINAL as the IESG and the IETF at large have other opportunities... 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 Sat Oct 08 07:33:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOCxR-0001Xd-AR for mobike-archive@megatron.ietf.org; Sat, 08 Oct 2005 07:33:41 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15343 for ; Sat, 8 Oct 2005 07:33:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C2600FB292; Sat, 8 Oct 2005 11:33:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 65ADEFB28A; Sat, 8 Oct 2005 11:33:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A1C3BFB28B; Sat, 8 Oct 2005 11:33:32 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E175CFB286 for ; Sat, 8 Oct 2005 11:33:31 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8323689870; Sat, 8 Oct 2005 14:33:21 +0300 (EEST) Message-ID: <4347AE86.7050808@piuha.net> Date: Sat, 08 Oct 2005 14:33:26 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200510081057.j98Av4xI078580@givry.rennes.enst-bretagne.fr> In-Reply-To: <200510081057.j98Av4xI078580@givry.rennes.enst-bretagne.fr> Cc: MOBIKE Mailing List , Paul Hoffman Subject: Re: [Mobike] WG Last Call the MOBIKE Protocol 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: >=> is the delta between 03 and 04 available and small? > > Small and editorial as far as I can see. Here's the diff: http://ietf.levkowetz.com/tools/rfcdiff/rfcdiff.pyht?url1=http://www.arkko.com/publications/mobike/draft-ietf-mobike-protocol-03.txt&url2=http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-04.txt (The URL may be handy for other purposes too. Another great tool from the tools team!) > The last call will end on Wednesday, October 19th, 2005*. If > you have not already started reading and verifying that the > specification is as you want it to be, please start doing so NOW. > This is your FINAL opportunity to comment on this protocol. > >=> it is not FINAL as the IESG and the IETF at large have other >opportunities... > > Well, its YOUR final chance in the WG :-) but then the AD, IESG and the rest of the IETF still have their say, that's true... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Oct 08 08:50:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOE9P-0005OD-6J for mobike-archive@megatron.ietf.org; Sat, 08 Oct 2005 08:50:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18655 for ; Sat, 8 Oct 2005 08:50:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2619DFB298; Sat, 8 Oct 2005 12:50:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DFD3FFB27C; Sat, 8 Oct 2005 12:49:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4E5DCFB28B; Sat, 8 Oct 2005 12:49:57 +0000 (UTC) Received: from av9-2-sn2.hy.skanova.net (av9-2-sn2.hy.skanova.net [81.228.8.180]) by machshav.com (Postfix) with ESMTP id 6DD9DFB286 for ; Sat, 8 Oct 2005 12:49:56 +0000 (UTC) Received: by av9-2-sn2.hy.skanova.net (Postfix, from userid 502) id 0D6C837F96; Sat, 8 Oct 2005 14:49:53 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av9-2-sn2.hy.skanova.net (Postfix) with ESMTP id 49B8037EB4; Sat, 8 Oct 2005 14:49:52 +0200 (CEST) Received: from shiraz.levkowetz.com (81-224-201-50-no45.tbcn.telia.com [81.224.201.50]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id AD9E937E42; Sat, 8 Oct 2005 14:49:51 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.52) id 1EOE99-0000Co-8R; Sat, 08 Oct 2005 14:49:51 +0200 Message-ID: <4347C06E.50101@levkowetz.com> Date: Sat, 08 Oct 2005 14:49:50 +0200 From: Henrik Levkowetz User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jari Arkko References: <200510081057.j98Av4xI078580@givry.rennes.enst-bretagne.fr> <4347AE86.7050808@piuha.net> In-Reply-To: <4347AE86.7050808@piuha.net> X-Enigmail-Version: 0.93.0.0 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false Cc: MOBIKE Mailing List , Francis Dupont , Paul Hoffman Subject: Re: [Mobike] WG Last Call the MOBIKE Protocol 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 on 2005-10-08 13:33 Jari Arkko said the following: > Francis Dupont wrote: > >>=> is the delta between 03 and 04 available and small? >> >> > Small and editorial as far as I can see. Here's the diff: > > http://ietf.levkowetz.com/tools/rfcdiff/rfcdiff.pyht?url1=http://www.arkko.com/publications/mobike/draft-ietf-mobike-protocol-03.txt&url2=http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-04.txt > > (The URL may be handy for other purposes too. Another > great tool from the tools team!) :-) Diffs are also available from the draft status page on tools.ietf.org as soon as a new version of a draft is available from the draft repository; check out http://tools.ietf.org/wg/mobike/draft-ietf-mobike-protocol/ which has a diff between the -03 and -04 of this draft at http://tools.ietf.org/wg/mobike/draft-ietf-mobike-protocol/draft-ietf-mobike-protocol-04-from-03.diff.html Regards, Henrik _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 10 04:45:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EOtHl-00079U-CC for mobike-archive@megatron.ietf.org; Mon, 10 Oct 2005 04:45:29 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25569 for ; Mon, 10 Oct 2005 04:45:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 400BAFB27D; Mon, 10 Oct 2005 08:45:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 31984FB27D; Mon, 10 Oct 2005 08:45:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 82117FB282; Mon, 10 Oct 2005 08:45:12 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id A9FC6FB27C for ; Mon, 10 Oct 2005 08:45:10 +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 j9A8j7G0020633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2005 11:45:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9A8j6KX007230; Mon, 10 Oct 2005 11:45:06 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17226.10770.490410.683279@fireball.kivinen.iki.fi> Date: Mon, 10 Oct 2005 11:45:06 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43466041.7040207@piuha.net> References: <64A531765B7C8342BFA260497BE00457071CC258@RED-MSG-43.redmond.corp.microsoft.com> <43466041.7040207@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 24 min Cc: Tuomas Aura , MOBIKE Mailing List Subject: [Mobike] FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03 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 >Comment 1: > >As explained in the security considerations section 6.1, an >attacker can spoof the source address of UPDATE_SA_ADDRESSES and, >thus, cause the responder to record the wrong address for the >initiator. Essentially, the attacker behaves as a NAT for selected >messages. I'd like to add the following observations: > >- Mobike hosts are more vulnerable to this attack than non-Mobike >hosts that are behind a NAT and use IKE NAT-T negotiation (e.g., >VPN clients at a home LAN). This is because a mobile host is more >likely to visits untrusted access networks and to be exposed to >attackers at its local link. > >- The sender-authentication of the address updates in Mobike is >weaker than it is in other mobility protocols like Mobile IPv6 or >HIP where the mobile's new address is included in the authenticated >part of the location update. This may be surprising because Mobike >uses the strong authentication provided by IKE. Yes, this is because of support for NAT-T. If you do not want to support NAT-T you will use NO_NATS_ALLOWED and that will provide stronger authentication. >- As a possible defense mechanism, the initiator local policy can >be configured to send NO_NATS_ALLOWED if and only if the initiator >address at the local link is private or link-local. This does not >require any changes to the specification. I assume you meant to say, that allow NAT-T only for private or link-local addresses, and use NO_NATS_ALLOWED if initiator have global routable ip-addresses? >- As another defense mechanism, the responder could reject address >updates where the initiator moves between two addresses on the same >local link. This would prevent attacks by the most likely type of >attacker that is on the same local link as the initiator and uses >its own address as the spoofed source address. In IPv6, it is >obvious which addresses are on the same local link. It should >probably be the initiator that makes the decision about such a >policy, in the same way as the initiator can decide whether to use >NO_NAT_ALLOWED. In IPv4, the address mask would need to be >communicated to the responder. I haven't considered the details. The problem there is to know which one to reject. If you select wrong one, you block all updates from the real client, not the attacker. There is not really way to detect which one is correct client. If the client is not behind NAT, then using NO_NAT_ALLOWED will fix the situation, and tell the other end which updates to reject. >Comment 2: > >If the initiator does not support NAT traversal, is it required to >send the NO_NATS_ALLOWED payload? Looks like this would make sense >but I cannot find it anywhere in the spec. Or does it make sense >for an initiator to behave otherwise. -04 says that all if NAT-T is not enabled, then messages which can update address MUST include NO_NATS_ALLOWED. >Comment 3: > >Does the SA recover from the attack of comment 1 if NAT traversal >is not in use? If NAT traverseal is not in use (i.e. disabled), then that situation cannot happen, as NO_NAT_ALLOWED will be used, and they will block all updates by the attacker. >Consider an initiator and responder at least one of which does not >support NAT traversal, or an initiator that sends NO_NATS_ALLOWED. >The attacker is located on the route between the initiator and the >responder, for example, at the initiator's local link. The attacker >intercepts the UPDATE_IP_ADDRESS notification, modifies its source >address to be the attacker's address, and forwards the packet to >the responder. Responder will reject that packet because the NO_NATS_ALLOWED contents do not match, and it will return error UNEXPTECTED_NAT_DETECTED. No update happens. > The attacker receives the response and forwards it >to the initiator. That is, the attacker behaves like a NAT for this >one address pair. The result is that the responder has records the >wrong address for the initiator. Moreover, the result of the NAT >traversal negotiation is that NAT traversal will not be used >between these two end hosts. The attacker now stops interfering >with packets and leaves the network. Can the SA recover? As no changes to SA happened, there is nothing to recover from. >The security considerations section 6.1 refers to "IKEv2 and Mobile >mechanisms designed to detect NAT mapping changes" as the recovery >mechanism. But these mechanisms will not kick in after the above >attack because NAT traversal is not in use. It looks like the SA >won't recover from this attack. Or is there some other recovery >mechanism that I have missed? You either have NO_NATS_ALLOWED or NAT_DETECTION_*_IP payaloads in the updates, so either it enables NAT-T on that attack, or disallows NAT, thus that should take care of that attack. >Comment 4: > >IPsec SAs are identified by the pair. >Normally, these identifiers are unique for inbound SAs destination >host is responsible for allocating the SPIs and for outbound SAs >because the destination address identifies a unique host. In >Mobike, the latter is no longer true. That is, identifier >collisions may occur for outbound SAs at the responder. ESPv3 the IPsec SA is identified by the SPI alone for the unicast SAs. There is no destination IP address threre anymore. Implementations are allowed to use SPI and IPsec protocol type also. (draft-ietf-ipsec-esp-v3-10.txt section 2.1). >Consider the following example of an accidental collision: I1 and >I2 are honest initiators that both have an SA with the same honest >responder R. The outbound SAs from R happen, by change, to have the >same SPI. (This is ok because the destination IP addresses differ.) This is not ok with the mobike, as it requires IKEv2, which requires RFC2401bis, which requires ESPv3... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 10 21:51:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP9J8-0002hk-Ki for mobike-archive@megatron.ietf.org; Mon, 10 Oct 2005 21:51:59 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07624 for ; Mon, 10 Oct 2005 21:51:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 64BFFFB28A; Tue, 11 Oct 2005 01:51:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C4B5CFB282; Tue, 11 Oct 2005 01:51:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0DE1BFB283; Tue, 11 Oct 2005 01:51:49 +0000 (UTC) Received: from smtp104.sbc.mail.mud.yahoo.com (smtp104.sbc.mail.mud.yahoo.com [68.142.198.203]) by machshav.com (Postfix) with SMTP id 0E7F2FB277 for ; Tue, 11 Oct 2005 01:51:48 +0000 (UTC) Received: (qmail 45634 invoked from network); 11 Oct 2005 01:51:47 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.186 with login) by smtp104.sbc.mail.mud.yahoo.com with SMTP; 11 Oct 2005 01:51:47 -0000 Message-ID: <00b701c5ce06$562c5a00$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" , "Jari Arkko" References: <64A531765B7C8342BFA260497BE00457071CC258@RED-MSG-43.redmond.corp.microsoft.com><43466041.7040207@piuha.net> <17226.10770.490410.683279@fireball.kivinen.iki.fi> Date: Mon, 10 Oct 2005 18:51:44 -0700 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: Tuomas Aura , MOBIKE Mailing List Subject: [Mobike] SPI collision Re: FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03 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, > >Comment 4: > > > >IPsec SAs are identified by the pair. > >Normally, these identifiers are unique for inbound SAs destination > >host is responsible for allocating the SPIs and for outbound SAs > >because the destination address identifies a unique host. In > >Mobike, the latter is no longer true. That is, identifier > >collisions may occur for outbound SAs at the responder. > > ESPv3 the IPsec SA is identified by the SPI alone for the unicast SAs. > There is no destination IP address threre anymore. Implementations are > allowed to use SPI and IPsec protocol type also. > (draft-ietf-ipsec-esp-v3-10.txt section 2.1). > Yes, but that concerns inbound processing. Here we are talking about outbound processing i thought. > >Consider the following example of an accidental collision: I1 and > >I2 are honest initiators that both have an SA with the same honest > >responder R. The outbound SAs from R happen, by change, to have the > >same SPI. (This is ok because the destination IP addresses differ.) > > This is not ok with the mobike, as it requires IKEv2, which requires > RFC2401bis, which requires ESPv3... > Are you saying that this problem cannot happen ? The I1 and I2 are two different hosts and they *can* choose the same SPI. When R is sending packets to I1 or I2, it does not use the SPI for lookup. It uses the selectors from the packet to lookup the SA. The selectors are unique (they are still I1 plus whatever the policy requires) even after I1 moves to A2. But this leads to two SAs with the same SPI. This should not cause any problem (in theory) because you never lookup this SA directly. You always lookup the SPD which points to the SA. But there are implementations (e.g. Linux) where this can cause problems if you update an SA that will result in the same values (dest address, SPI, protocol) as another SA. So, can you clarify ? -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 Oct 11 06:08:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPH3T-0005WA-W0 for mobike-archive@megatron.ietf.org; Tue, 11 Oct 2005 06:08:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11610 for ; Tue, 11 Oct 2005 06:08:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 88692FB28B; Tue, 11 Oct 2005 10:08:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C6C29FB282; Tue, 11 Oct 2005 10:08:07 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9BB8AFB283; Tue, 11 Oct 2005 10:08:06 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 03811FB277 for ; Tue, 11 Oct 2005 10:08:05 +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 j9BA82mb019105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2005 13:08:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9BA800U024786; Tue, 11 Oct 2005 13:08:00 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17227.36608.323890.496798@fireball.kivinen.iki.fi> Date: Tue, 11 Oct 2005 13:08:00 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" In-Reply-To: <00b701c5ce06$562c5a00$6501a8c0@adithya> References: <64A531765B7C8342BFA260497BE00457071CC258@RED-MSG-43.redmond.corp.microsoft.com> <43466041.7040207@piuha.net> <17226.10770.490410.683279@fireball.kivinen.iki.fi> <00b701c5ce06$562c5a00$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 25 min X-Total-Time: 27 min Cc: MOBIKE Mailing List , Tuomas Aura , Jari Arkko Subject: [Mobike] SPI collision Re: FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03 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: > Tero, > > > >Comment 4: > > > > > >IPsec SAs are identified by the pair. > > >Normally, these identifiers are unique for inbound SAs destination > > >host is responsible for allocating the SPIs and for outbound SAs > > >because the destination address identifies a unique host. In > > >Mobike, the latter is no longer true. That is, identifier > > >collisions may occur for outbound SAs at the responder. > > > > ESPv3 the IPsec SA is identified by the SPI alone for the unicast SAs. > > There is no destination IP address threre anymore. Implementations are > > allowed to use SPI and IPsec protocol type also. > > (draft-ietf-ipsec-esp-v3-10.txt section 2.1). > > > Yes, but that concerns inbound processing. Here we are talking about outbound > processing i thought. Ups, I seem to have read the question too quickly. > Are you saying that this problem cannot happen ? The I1 and I2 are > two different hosts and they *can* choose the same SPI. When R is > sending packets to I1 or I2, it does not use the SPI for lookup. It > uses the selectors from the packet to lookup the SA. The selectors > are unique (they are still I1 plus whatever the policy requires) > even after I1 moves to A2. But this leads to two SAs with the same > SPI. Same outbond SPI, so that is not a problem. > This should not cause any problem (in theory) because you never > lookup this SA directly. You always lookup the SPD which points to > the SA. But there are implementations (e.g. Linux) where this can > cause problems if you update an SA that will result in the same > values (dest address, SPI, protocol) as another SA. So, can you > clarify ? When you are sending packets outbound you do lookup from SPD-S based on the selectors (I1 or I2) and you get SA based on that. Then in the SA there is the SPI and destination IP to be used for the other end. Then you simply make tunnel encapsulation and send the packet along. I do not really see what is the problem there? So we have case where we have I1 and I2 using addresses A1 and A2 talking to the R and both have selected same SPI for the IPsec SA. Now if I2 disappears i.e. does not send IKE SA delete to destroy the IKE SA and the IPsec SA. If the I1 happens to get the same IP-address A2 in the local link, and sends UPDATE_IP_ADDRESSES to the R, we can have that situation. Note, that this I1 must get A2 before DPD notices that I2 is dead to this happen. As R uses selectors I1 and I2 to search from the SPD-S and the SPD-S will then point to the SA, there should be no problem for the R to send packets out. The I1 will discard those packets R sends which have keying material for the I2, and after a while R will start DPD for the I2 IKE SA and delete it as it does not see any traffic for it. When finding the SA based on the selectors we match those selectors against SPD-S, which have the exact selectors based on the SPD and the PFP flags (populate from packet), so there should not be problem even when they are using same PFP SPD rule. The case where we have multiple IKE SAs with the same IP address is already happening without MOBIKE, in case of NAT-T. The 4.4.2 of the RFC2401bis says: ... For outbound processing, each SAD entry is pointed to by entries in the SPD-S part of the SPD cache. ... The section 4.4.1 describes the SPD-S: ... - SPD-S: For traffic that is to be protected using IPsec, the entry consists of the values of the selectors that apply to the traffic to be protected via AH or ESP, controls on how to create SAs based on these selectors, and the parameters needed to effect this protection (e.g., algorithms, modes, etc.). Note that an SPD-S entry also contains information such as "populate from packet" (PFP) flag (see paragraphs below on "How To Derive the Values for an SAD entry") and bits indicating whether the SA lookup makes use of the local and remote IP addresses in addition to the SPI (see AH [Ken05b] or ESP [Ken05a] specifications). ... Does that (correctly) answer the (correct) question? -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 11 12:55:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPNP9-0007hv-P9 for mobike-archive@megatron.ietf.org; Tue, 11 Oct 2005 12:55:08 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14330 for ; Tue, 11 Oct 2005 12:55:03 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 715A6FB289; Tue, 11 Oct 2005 16:55:05 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 85167FB282; Tue, 11 Oct 2005 16:55:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B20E5FB283; Tue, 11 Oct 2005 16:55:00 +0000 (UTC) Received: from web80604.mail.yahoo.com (web80604.mail.yahoo.com [66.218.79.93]) by machshav.com (Postfix) with SMTP id 06034FB277 for ; Tue, 11 Oct 2005 16:54:59 +0000 (UTC) Received: (qmail 75521 invoked by uid 60001); 11 Oct 2005 16:54:58 -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=pMRnBQJFK1xPIi/Ij4zEmOLZ8ZNirbM9+86X30E3Ju2JicIO/5BbMNswxxHuv1myA8Y8TgedKNBPW89eNt4tErkk7vTLpXdqNaLhUHNdM4kBuyri/f4v/Ra1stPsQtnXoB5GERDTDX/hE4ERpGIADQ257nPnm1++eNOm0Y5e8Dg= ; Message-ID: <20051011165458.75519.qmail@web80604.mail.yahoo.com> Received: from [206.132.194.2] by web80604.mail.yahoo.com via HTTP; Tue, 11 Oct 2005 09:54:58 PDT Date: Tue, 11 Oct 2005 09:54:58 -0700 (PDT) From: Mohan Parthasarathy To: Tero Kivinen In-Reply-To: <17227.36608.323890.496798@fireball.kivinen.iki.fi> MIME-Version: 1.0 Cc: MOBIKE Mailing List , Tuomas Aura , Jari Arkko Subject: Re: [Mobike] SPI collision Re: FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03 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 > > > So we have case where we have I1 and I2 using > addresses A1 and A2 > talking to the R and both have selected same SPI for > the IPsec SA. Now > if I2 disappears i.e. does not send IKE SA delete to > destroy the IKE > SA and the IPsec SA. If the I1 happens to get the > same IP-address A2 > in the local link, and sends UPDATE_IP_ADDRESSES to > the R, we can have > that situation. Note, that this I1 must get A2 > before DPD notices that > I2 is dead to this happen. As R uses selectors I1 > and I2 to search > from the SPD-S and the SPD-S will then point to the > SA, there should > be no problem for the R to send packets out. > Yes, this is the case. Now, when R receives the UPDATE_IP_ADDRESSES, it need to update the information in SA about where the packets should be tunneled out. How do you locate the SA to update its peer address ? If you locate the SA based on peer SPI, destination address and protocol (it does not matter how the peer chose the SPI i.e it can be unique for the whole system etc.), some implementation might have wrongly assumed that it will be unique. As you point out below, it does not work for NAT-T. So, you need a different way to lookup the SA. I am merely *guessing* that the original question was based on this. > The I1 will discard those packets R sends which have > keying material > for the I2, and after a while R will start DPD for > the I2 IKE SA and > delete it as it does not see any traffic for it. > Yes, this is not an issue. > When finding the SA based on the selectors we match > those selectors > against SPD-S, which have the exact selectors based > on the SPD and the > PFP flags (populate from packet), so there should > not be problem even > when they are using same PFP SPD rule. > > The case where we have multiple IKE SAs with the > same IP address is > already happening without MOBIKE, in case of NAT-T. > Agreed. This happens when there are two hosts (I1 and I2) behind the SAME NAT establishing the SA with a responder (R). If I1 and I2 picks the same SPI, then the destination address (public address), SPI and protocol as seen by the responder R will not be unique. > The 4.4.2 of the RFC2401bis says: > ... > For outbound processing, each SAD entry is > pointed to by entries > in the SPD-S part of the SPD cache. > ... > > The section 4.4.1 describes the SPD-S: > ... > - SPD-S: For traffic that is to be protected > using IPsec, the > entry consists of the values of the > selectors that apply to the > traffic to be protected via AH or ESP, > controls on how to > create SAs based on these selectors, and > the parameters needed > to effect this protection (e.g., > algorithms, modes, etc.). Note > that an SPD-S entry also contains > information such as "populate > from packet" (PFP) flag (see paragraphs > below on "How To Derive > the Values for an SAD entry") and bits > indicating whether the > SA lookup makes use of the local and remote > IP addresses in > addition to the SPI (see AH [Ken05b] or ESP > [Ken05a] > specifications). > ... > > Does that (correctly) answer the (correct) question ? Yes. -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 11 15: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 1EPPmQ-0002Lm-GL for mobike-archive@megatron.ietf.org; Tue, 11 Oct 2005 15:27:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23958 for ; Tue, 11 Oct 2005 15:27:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9ECF2FB289; Tue, 11 Oct 2005 19:27:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 447F4FB283; Tue, 11 Oct 2005 19:27:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 64A6DFB286; Tue, 11 Oct 2005 19:27:10 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id CD6B1FB277 for ; Tue, 11 Oct 2005 19:27:08 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id F03B389870; Tue, 11 Oct 2005 22:27:07 +0300 (EEST) Message-ID: <434C1219.2020104@piuha.net> Date: Tue, 11 Oct 2005 22:27:21 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobike@machshav.com References: <17228.3405.164563.945674@gargle.gargle.HOWL> In-Reply-To: <17228.3405.164563.945674@gargle.gargle.HOWL> Cc: Pete McCann Subject: [Mobike] FW: Review of draft-ietf-mobike-protocol-03.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 Pete McCann's review was posted to the list, but hit the non-subscriber filter. Thanks Pete for the review! Forwarding contents: Pete McCann wrote: >Overall this draft is in good shape and it looks almost done. I have >only one technical comment and the rest are editorial. > > and attachment: Section 1 Introduction For instance, a user could start from fixed Ethernet in the office, and then disconnect the laptop and move to office wireless LAN. SHOULD BE: For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office's wireless LAN. When leaving the office the laptop could start using GPRS, and switch to a different wireless LAN when the user arrives home. SHOULD BE: When leaving the office, the laptop could start using GPRS. When the user arrives home, the laptop could switch to a home wireless LAN. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and others traffic selectors used inside the tunnel stay unchanged. SHOULD BE: MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and other traffic selectors used inside the tunnel stay unchanged. Section 2 Terminology and Notation In some cases, the diagrams also show what payloads defined in [IKEv2] would be typically included in, for instance, the IKE_AUTH exchange. SHOULD BE: To provide context, some diagrams also show the existing IKEv2 payloads in existing exchanges: for example, the IKE_AUTH exchange contains an encrypted AUTH payload. Throughout the document: don't use references like ``[IKEv2]'' as nouns in the sentence. A reference should augment the existing text [like so], not serve as a subject or object. Section 3.1 Basic Operation First, the parties have may preferences about which interface should be used, due to performance and cost reasons, for instance. SHOULD BE: First, the parties may have preferences about which interface should be used due to performance and/or cost differences. (the "client" in remote access VPN scenario) SHOULD BE: (the "client" in a remote access VPN scenario) is responsible for deciding which address pair is used for the IPsec SAs, and collecting the information SHOULD BE: is responsible for deciding which address pair is used for the IPsec SAs and for collecting the information (the "gateway" in remote access VPN scenario) SHOULD BE: (the "gateway" in a remote access VPN scenario) simply tells the initiator what addresses it has, but does not update SHOULD BE: simply tells the initiator what addresses it has but does not update and when a decision needs to be changed, are largely beyond the scope of MOBIKE. SHOULD BE: and when a decision needs to be changed are largely beyond the scope of MOBIKE. For instance, link layer and IP layer mechanisms can be used to track the status of connectivity within the local link [RFC2461], movement detection is being specified in for both IPv4 and IPv6 [DNA4] [DNA6], and so on. SHOULD BE: For instance, link layer and IP layer mechanisms can be used to track the status of connectivity within the local link [RFC2461], movement detection is being specified for both IPv4 and IPv6 [DNA4] [DNA6], and so on. Section 3.2 Example Protocol Runs (Initiator gets information from lower layers that its attachment point and address has changed.) SHOULD BE: (Initiator gets information from lower layers that its attachment point and address have changed.) In step 3, the initiator notices a change in its own address, and informs the responder about this. At this point, it also starts to use the new address as a source address in its own outgoing ESP traffic. The responder records the new address, and if so required by policy, performs a return routability check of the address. When this check completes, the responder starts to use the new address as the destination for its outgoing ESP traffic. Perhaps add some verbiage here about the essential mechanism used to update the SA. It isn't quite clear how this happens to the un-initated reader. Something like the following might help: In step 3, the initiator notices a change in its own address, and informs the responder about this by sending the UPDATE_SA_ADDRESSES payload within an IKEv2 packet that uses the new IP address pair but that has the same initiator and responder SPIs. At this point, the initiator also starts to use the new address as a source address in its own outgoing ESP traffic. Upon receiving and validating the integrity of the UPDATE_SA_ADDRESSES payload, the responder records the new address from the header of the containing packet, and if so required by policy, performs a return routability check of the address in step 4. When this check completes, the responder starts to use the new address as the destination for its outgoing ESP traffic. Another protocol run in multihoming scenario is illustrated below. SHOULD BE: Another protocol run in a multihoming scenario is illustrated below. Section 4.7 Changes in NAT Mappings have changed (for example, if the keepalive internal is too long, or SHOULD BE: have changed (for example, if the keepalive interval is too long, or Section 6 Security Considerations The main goals of this specification are to not reduce the security offered by usual IKEv2 procedures and to counter mobility related threats in an appropriate manner. SHOULD BE: The main goals of this specification are to maintain the security offered by usual IKEv2 procedures and to counter mobility related threats in an appropriate manner while allowing updates to the IP addresses of the IKE_SA and CHILD_SAs. See [IKEv2] for security considerations for IKEv2 in general. SHOULD BE: See IKEv2 [IKEv2] for security considerations for IKEv2 in general. Section 6.1 Traffic Redirection and Hijacking However, just like with normal IKEv2, SHOULD BE: However, as with normal IKEv2, _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 12 04:49:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPcIh-0005te-VF for mobike-archive@megatron.ietf.org; Wed, 12 Oct 2005 04:49:28 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07324 for ; Wed, 12 Oct 2005 04:49:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F2CA2FB28E; Wed, 12 Oct 2005 08:49:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 53421FB283; Wed, 12 Oct 2005 08:49:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 927ACFB28A; Wed, 12 Oct 2005 08:49:20 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 79882FB282 for ; Wed, 12 Oct 2005 08:49:19 +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 j9C8nHrQ022113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Oct 2005 11:49:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9C8nDbA017692; Wed, 12 Oct 2005 11:49:13 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17228.52745.906377.224335@fireball.kivinen.iki.fi> Date: Wed, 12 Oct 2005 11:49:13 +0300 From: Tero Kivinen To: Mohan Parthasarathy In-Reply-To: <20051011165458.75519.qmail@web80604.mail.yahoo.com> References: <17227.36608.323890.496798@fireball.kivinen.iki.fi> <20051011165458.75519.qmail@web80604.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min Cc: MOBIKE Mailing List , Tuomas Aura , Jari Arkko Subject: Re: [Mobike] SPI collision Re: FW: Tuomas Aura's review of draft-ietf-mobike-protocol-03 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: > Yes, this is the case. Now, when R receives the > UPDATE_IP_ADDRESSES, it need to update the information > in SA about where the packets should be tunneled out. > How do you locate the SA to update its peer address ? The UPDATE_IP_ADDRESSES is IKE SA operation, that is done on the IKE SA, and each IPsec SA is tied to the IKE SA, thus all IPsec SAs affected can be found by finding the IPsec SAs created by this IKE SA (similarly what you do when the IKE SA is deleted, and you need to find all IPsec SAs created by IKE SA so you can delete them). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 12 09:39:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPgpN-0007cp-KI for mobike-archive@megatron.ietf.org; Wed, 12 Oct 2005 09:39:29 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21491 for ; Wed, 12 Oct 2005 09:39:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C4CFCFB28E; Wed, 12 Oct 2005 13:39:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5CE5BFB283; Wed, 12 Oct 2005 13:39:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B5BE0FB28A; Wed, 12 Oct 2005 13:39:19 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id BEF4EFB282 for ; Wed, 12 Oct 2005 13:39:17 +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 j9CDdEUg029637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Oct 2005 16:39:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9CDdEbv015612; Wed, 12 Oct 2005 16:39:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17229.4610.296836.928434@fireball.kivinen.iki.fi> Date: Wed, 12 Oct 2005 16:39:14 +0300 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 50 min X-Total-Time: 77 min Subject: [Mobike] 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 1) In section 3.2. the second example should probably clarify that the exchange in step 3 is successful, i.e. the responder do respond to that in this example protocol run (as can be seen from the return packet sent by the responder, but the text below it gives feeling that it failed ("initiator gives up")). Perhaps there should also be example where that exchange is not successful. ---------------------------------------------------------------------- 2) In section 4.2 we should always take the IP-addresses from the IKE_AUTH request, as there might be multiple IKE_SA_INIT request, and some of those might not create state at all (cookie, invalid_ke_payload). I think it would be simplier to say that the IP-addresses are always taken from the IP header of the IKE_AUTH packet having SA payload (regardless of the NAT-T or no NAT-T). In normal IKEv2 this does not matter, as if no NAT-T is used then the IP address must stay same, and if NAT-T is used then we take the last packet seen and use the IP-addresses from there. In Mobike we do need to define the exact time what IP-address is used, and I think the packet having the ADDITIONAL_*_ADDRESSES would be the most logical choise (i.e. the IKE_AUTH packet having the SA payload). ---------------------------------------------------------------------- 3) I think that section 4.5 should clarify you use either ADDITIONAL_*_ADDRESSES or NO_ADDITIONAL_ADDRESSES, not both (but you always have either exactly one NO_ADDITIONAL_ADDRESSES or one or more ADDITIONAL_*_ADDRESSES), and also explain more when to use NO_ADDITIONAL_ADDRESSES. The actual usage of the NO_ADDITIONAL_ADDRESSES is not really explained anywhere (though it is quite obvious from the name if people understand that the ADDITIONAL_*_ADDRESSES are only used for the ADDITIONAL addresses beside the ones in the IP header of the exchange packet). Actually, I think even that text is missing, i.e. text saying that the ADDITIONAL_*_ADDRESSES are used in addition to the IP address of the current exchange packet. ---------------------------------------------------------------------- 4) The last sentence in the section 4.5 should say Similarly, a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or process ADDITIONAL_*_ADDRESS notifications. It needs to understand them so much it can ignore them. ---------------------------------------------------------------------- 5) In section 4.6 the paragraph: Any INFORMATIONAL exchange can be used for return routability purposes, with one exception: when a valid response is received, we know the other party can receive packets at the claimed address. should probably tell what is the one exception... Or more exactly what that paragraph is trying to tell us? ---------------------------------------------------------------------- 6) Perhaps the section 4.7 should also mention that DPD packets can also include UPDATE_SA_ADDRESSES in case the initiator suspects that the NAT mapping has changed, and that will save one round trip. ---------------------------------------------------------------------- 7) The section 4.8 says that NO_NATS_ALLOWED should be put to the IKE_SA_INIT (among other things), but we do want to keep IKE_SA_INIT as small as possible, so I think IKE_AUTH is much better place for that notify. That would also be in sync with my proposed change to the 4.2 where I proposed to say that use the IKE_AUTH packet having SA payload to get the IP address tobe used. NO_NATS_ALLOWED is not needed in the IKE_SA_INIT like NAT_DETECTION_*_IP notifies are, as they do not cause changing of the port numbers for the IKE_AUTH. Also moving that NOFITY to the encrypted IKE_AUTH packet will prevent passive attackers of getting the information about the IP addresses and ports used in case host behind NAT is configured to try first with NO_NATS_ALLOWED before falling back and enabling NAT-T. It will also make the attacker acting as a NAT between two hosts bit harder, as if it is sent inside the IKE_SA_INIT, attacker can simply flip a bit inside the NO_NATS_ALLOWED payload to cause DoS, otherwise he need to flip bit in the IP-address or ports, which requires it to catch the return packet and forward it to the original requestor to cause attack. It is not much, but offers again a bit more protection against attacks. ---------------------------------------------------------------------- 8) Perhaps the section 5.1 should say "There is no data associated with this Notify type, and the when processing Notify received from the other end the notify data MUST be ignored." Then we can later add some data there and old version will ignore it. That will allow us possibility to extend this payload later. With the current text implementations can simply fail the whole IKE SA negotiation if there is data in the this notify. (or if you consider this to be too close to the already covered no-version-numbers case, then feel free to ignore this comment). ---------------------------------------------------------------------- 9) I agree with the previous proposal that we should split those notifies to error and status notifies, and have separate section for each of those. ---------------------------------------------------------------------- 10) The section 5.7 of the NO_NATS_ALLOWED could have a bit more text explaining the exact data put in, i.e. something like Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | dst-ip (4 or 16 bytes) | dst-port (2 bytes) All data is stored in the network byte order without any padding. The lenght of the data is 12 bytes for IPv4, and 36 bytes for the IPv6. ---------------------------------------------------------------------- 11) The section 6.1 should probably also mention that NO_NATS_ALLOWED might be used with IPv6 in general, where NATs are not (yet) used. ---------------------------------------------------------------------- 12) The section 6.5 should mention that those information is generally available only for the other peer, not to the passive listeners (it is encrypted). There is two (or one if we move the NO_NATS_ALLOWED) exceptions to the rule: NAT_DETECTION_*_IP packets of the IKE_SA_INIT and the NO_NATS_ALLOWED (if sent inside the IKE_SA_INIT). Those payloads having IP-address information is sent in clear. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 12 13:12:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPk93-0008Rd-Qf for mobike-archive@megatron.ietf.org; Wed, 12 Oct 2005 13:12:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05908 for ; Wed, 12 Oct 2005 13:11:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CB8D9FB28E; Wed, 12 Oct 2005 17:11:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5D565FB282; Wed, 12 Oct 2005 17:11:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0EF8DFB28B; Wed, 12 Oct 2005 14:07:39 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8FBE6FB283 for ; Wed, 12 Oct 2005 14:07:36 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4104E89870; Wed, 12 Oct 2005 17:07:34 +0300 (EEST) Message-ID: <434D18B3.2040100@piuha.net> Date: Wed, 12 Oct 2005 17:07:47 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List X-Mailman-Approved-At: Wed, 12 Oct 2005 17:11:51 +0000 Subject: [Mobike] FW: Marcelo's review of mobike protocol 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 forwarding Marcelo's review of the MOBIKE protocol draft -04. Thank you very much for the review, Marcelo! Folks, please see his comments below: ------ Below you can find the review of the draft-ietf-mobike-protocol-04.txt that you requested. Please note that i have not been following the work of mobike neither the comments received in the last call, so probably some of these comments may have been raised before or may simple be the consequence of the lack of in-depth understanding of the protocol design. First of all, i think that the document is in very good shape, and it covers all the aspects that i needed to follow it. In addition, i have the following comments/questions: 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. 2. As i understand it, as currently defined, mobike does not supports multiple address pairs simultaneously in a given SA, right? Moreover, as i read it, all the IPSec SAs created with the same IKE SA have the same address pair right? If any of these are so, IMHO this should be explicitly noted in the document, since it would imho have two immediate consequences: 2.1 No load sharing, load balancing, traffic engineering or policing/preference setting would be supported, like distributing different traffics through different address pairs/links, which should be noted imho 2.2 No unidirectional paths are supported i.e. if a address pair is working in one direction and another address pair is working in the other direction, this cannot work, which should be noted explicitly too in the spec imho. 3. The previous point brings me to this point, which is about ingress filtering compatibility. There is no mention to ingress filtering comaptibility here. As you know, when multiple addresses are available, packets may be dropped by incompatibility between ingress filters and the selected source address. This document does not considers this as a problem. Becuase of ingress filters, many unidirectional paths may result (packets are dropped when flowing in one direction). However, as i understand it, mobike does not supports unidirectional paths (since the same address pair is used in both directions). So, my point is that in a case where no ingress filtering compatibility mechanism is provided and because no unidirectional paths are supported, the mobike protocol is likely to perform poorly in this scenario. I guess that at least you should mention this, if not fix it. 4. Establishment of the initial IKE session. No reference is made about how the initial contact between the two parties is made. I mean, in case that both have multiple addresses, and that some of them are not working, the initial contact may not be trivial. Maybe this is out of the scope of mobike, but current specs don't support this scenario, so maybe it would be worth noting it. 5. In the document, it seems that an important design choice that was made was that (section 3.1) MOBIKE solves this problem by taking a simple approach: the party that initiated the IKE_SA (the "client" in a remote access VPN scenario) is responsible for deciding which address pair is used for the IPsec SAs, and for collecting the information it needs to make this decision (such as determining which address pairs work or do not work). The other party (the "gateway" in a remote access VPN scenario) simply tells the initiator what addresses it has, but does not update the IPsec SAs until it receives a message from the initiator to do so. Now what i would like to understand is what parts of the mobike protocol would not support the more general scenario, where both parties can change the address pair used for the communication. As i see it, this was a constraint to simplify the protocol to a case like the VPN which was useful. My question at this point is how much of the resulting protocol actually relies on this constraint? As i read it, this resulted in the following constraints: - Tunnel mode only is supported - Only the initiator can be behind a nat - no simultaneous movement is supported Now, i can see that supporting those may increase the complexity of the protocol However, in addition, it seems that the protocol artificially imposes that - failure detection, path exploration and path selection can only be performed by the initiator (client) - it includes a couple of corner cases where the responder can change its address for dealing with specific cases. Wouldn't it be simpler to define a symmetric operation of the protocol (without corner cases) and simply stating the three constraints above? Or are there other constraints imposed by this model that i am missing? Next, some more text-specific comments: 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) 7. In section 3.3 it is stated that: For simplicity, MOBIKE does not attempt to handle all possible NAT- related scenarios. Instead, MOBIKE assumes that if NATs are present, the initiator is the party "behind" the NAT, and does not fully support the case where the responder's addresses change. But later on, in section 4.3. it is stated that Note that if some of the initiator's interfaces are behind a NAT (from the responder's point of view), the addresses received by the responder will be incorrect. This means the procedure for changing responder addresses described in Section 4.5 does not fully work when the initiator is behind a NAT. For the same reason, the peers also SHOULD NOT use this information for any other purposes than what is explicitly described in this document. So from the first paragraph it seems that the configuration where the initiator is behind a nat is supported, while in the second paragraph seems that it isn't. This is quite confusing to me... 8. I think that many other constraints should be listed in the Limitations section 3.4 For instance, that the protocol doesn't fully supports the case that the responder is behind the nat (i know it is mentioned before, but this is a limitation too) That no simultaneous movement is supported That no unidirectional paths are supported. (and that in presece of ingress filtering this may imply that the protocol will perform poorly) That only local failures are repaired (and that other more distant failures may not be repaired by the protocol) That a single address pair is supported in all the SAs created through a single IKE_SA That the protocol may not be able to establish a communication if a failure has occurred before initial contact 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 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 INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS notifications is received. This means the peer's addresses may have changed. o An UNACCEPTABLE_ADDRESSES notification is received as a response to address update request (described below). o The initiator receives a NAT_DETECTION_DESTINATION_IP notification that does not match the previous UPDATE_SA_ADDRESSES response (see Section 4.7 for a more detailed description). (included just to point out which part of the doc i was talking about) 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). 11. In section 4.5. the NO_ADDITIONAL_ADDRESSES notification is presented. As i understand it, this is the only way to delete addresses from the address set, right? This is kind of twisted, i think. I mean, if a node wants to delete one address because is no longer available it, must: - delete all the addresses using a NO_ADDITIONAL_ADDRESSES notification message - add other addresses with a ADDITIONAL_ADDRESSES notification is this so? If yes, i think this should be clearly stated imho (at least that the NO_ADDITIONAL_ADDRESSES notification serves to delete addresses) 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) 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. 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. I don't see that these attacks could actually cause dos attacks, but just added DPD traffic. Well, i hope you find some of this stuff useful, _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 13 08:27:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2B1-0007lV-RV for mobike-archive@megatron.ietf.org; Thu, 13 Oct 2005 08:27:16 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14388 for ; Thu, 13 Oct 2005 08:27:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 82DFBFB28E; Thu, 13 Oct 2005 12:27:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DC383FB282; Thu, 13 Oct 2005 12:27:08 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 599ABFB283; Thu, 13 Oct 2005 12:27:07 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 6BDA6FB277 for ; Thu, 13 Oct 2005 12:27:05 +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 j9DCR2vr023027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Oct 2005 15:27:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9DCR2l1013561; Thu, 13 Oct 2005 15:27:02 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17230.21142.330797.663268@fireball.kivinen.iki.fi> Date: Thu, 13 Oct 2005 15:27:02 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <434D18B3.2040100@piuha.net> References: <434D18B3.2040100@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 18 min Cc: MOBIKE Mailing List Subject: [Mobike] FW: Marcelo's review of mobike protocol 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: > 2. As i understand it, as currently defined, mobike does not supports > multiple address pairs simultaneously in a given SA, right? Moreover, as > i read it, all the IPSec SAs created with the same IKE SA have the same > address pair right? If any of these are so, IMHO this should be > explicitly noted in the document, since it would imho have two immediate > consequences: > 2.1 No load sharing, load balancing, traffic engineering or > policing/preference setting would be supported, like distributing > different traffics through different address pairs/links, which should > be noted imho > 2.2 No unidirectional paths are supported i.e. if a address pair is > working in one direction and another address pair is working in the > other direction, this cannot work, which should be noted explicitly too > in the spec imho. Most of those things should be covered by the design document, but short mention in the introduction could be good thing. > 3. The previous point brings me to this point, which is about ingress > filtering compatibility. There is no mention to ingress filtering > comaptibility here. As you know, when multiple addresses are available, > packets may be dropped by incompatibility between ingress filters and > the selected source address. This document does not considers this as a > problem. Becuase of ingress filters, many unidirectional paths may > result (packets are dropped when flowing in one direction). However, as > i understand it, mobike does not supports unidirectional paths (since > the same address pair is used in both directions). So, my point is that > in a case where no ingress filtering compatibility mechanism is provided > and because no unidirectional paths are supported, the mobike protocol > is likely to perform poorly in this scenario. I guess that at least you > should mention this, if not fix it. There should not be problems with the ingress filters, as we always use the source address associated to the given interface when sending packets out. I.e. if we have two interfaces A and B, having IPa and IPb, when we send packets out using IPa we always select interface A. The network connected to the interface should allow IPa to pass through it as it is IP address given by the network to the host for that interface. Implementations might need to do specific things to bypass routing of those packets (using default route or similar) to make use they are really sent out from the host using proper interface. > 4. Establishment of the initial IKE session. No reference is made about > how the initial contact between the two parties is made. I mean, in case > that both have multiple addresses, and that some of them are not > working, the initial contact may not be trivial. Maybe this is out of > the scope of mobike, but current specs don't support this scenario, so > maybe it would be worth noting it. I think the assumption is that the initiator knows the IP address (or IP-addresses) of the other peer before the connection is even initiated, thus MOBIKE will simply try the different addresses trying to find working one. > > 5. In the document, it seems that an important design choice that was > made was that (section 3.1) ... [about the initiator selects approach] That discussion about why that approach was selected and what it causes does not belong to the protocol document. It should be something that is in the design document. > 11. In section 4.5. the NO_ADDITIONAL_ADDRESSES notification is > presented. As i understand it, this is the only way to delete addresses > from the address set, right? > This is kind of twisted, i think. I mean, if a node wants to delete one > address because is no longer available it, must: > - delete all the addresses using a NO_ADDITIONAL_ADDRESSES notification > message > - add other addresses with a ADDITIONAL_ADDRESSES notification > is this so? > If yes, i think this should be clearly stated imho (at least that the > NO_ADDITIONAL_ADDRESSES notification serves to delete addresses) No, I have not understood that section that way. I assumed that the new list of addresses (ADDITIONAL_ADDRESSES) always overwrites the whole previous list. I.e. it is not incremental update, but it is full list every time. In some cases where you have only one IP-address, the ADDITIONAL_ADDRESSES notify would not be there, and you need to have some way to tell that there is no other addresses than the one that is used in the IP-headers of this packet. > 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) If the certificate is self signed, and it is trusted by the recipient there is no problem. The basic idea is that in the VPN case where multiple sites are connected together with VPN gateways each having one or two addresses, each VPN gateway can have certificate which lists the IP-addresses they have. The VPN gateways are not going to get new address on the fly, thus they can use IP-addresses from the certificates. Also the most common case of road warrior will probably be that the gateway is authenticated with certificate and the client is authenticated with some EAP method. In that case it would be useless for clients to do return routability to the server's second address, when the first address happen to go down. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Oct 15 10:55:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQnRC-0006ra-Pa for mobike-archive@megatron.ietf.org; Sat, 15 Oct 2005 10:55:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12444 for ; Sat, 15 Oct 2005 10:54:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BD38AFB283; Sat, 15 Oct 2005 14:55:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A1001FB262; Sat, 15 Oct 2005 14:54:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 07FC1FB277; Sat, 15 Oct 2005 14:54:53 +0000 (UTC) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.136.123]) by machshav.com (Postfix) with ESMTP id C7193FB249 for ; Sat, 15 Oct 2005 14:54:50 +0000 (UTC) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4CD6D8207E; Sat, 15 Oct 2005 16:54:49 +0200 (CEST) Received: from [163.117.203.36] (unknown [163.117.203.36]) by smtp03.uc3m.es (Postfix) with ESMTP id 5CC818209A; Sat, 15 Oct 2005 16:54:42 +0200 (CEST) In-Reply-To: <17230.21142.330797.663268@fireball.kivinen.iki.fi> References: <434D18B3.2040100@piuha.net> <17230.21142.330797.663268@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: From: marcelo bagnulo braun Date: Sat, 15 Oct 2005 16:38:38 +0200 To: Tero Kivinen X-Mailer: Apple Mail (2.623) Cc: MOBIKE Mailing List , Jari Arkko Subject: Re: [Mobike] FW: Marcelo's review of mobike protocol 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable El 13/10/2005, a las 14:27, Tero Kivinen escribi=F3: > Jari Arkko writes: >> 2. As i understand it, as currently defined, mobike does not supports >> multiple address pairs simultaneously in a given SA, right? Moreover, = >> as >> i read it, all the IPSec SAs created with the same IKE SA have the = >> same >> address pair right? If any of these are so, IMHO this should be >> explicitly noted in the document, since it would imho have two = >> immediate >> consequences: >> 2.1 No load sharing, load balancing, traffic engineering or >> policing/preference setting would be supported, like distributing >> different traffics through different address pairs/links, which should >> be noted imho >> 2.2 No unidirectional paths are supported i.e. if a address pair is >> working in one direction and another address pair is working in the >> other direction, this cannot work, which should be noted explicitly = >> too >> in the spec imho. > > Most of those things should be covered by the design document, but > short mention in the introduction could be good thing. > >> 3. The previous point brings me to this point, which is about ingress >> filtering compatibility. There is no mention to ingress filtering >> comaptibility here. As you know, when multiple addresses are = >> available, >> packets may be dropped by incompatibility between ingress filters and >> the selected source address. This document does not considers this as = >> a >> problem. Becuase of ingress filters, many unidirectional paths may >> result (packets are dropped when flowing in one direction). However, = >> as >> i understand it, mobike does not supports unidirectional paths (since >> the same address pair is used in both directions). So, my point is = >> that >> in a case where no ingress filtering compatibility mechanism is = >> provided >> and because no unidirectional paths are supported, the mobike protocol >> is likely to perform poorly in this scenario. I guess that at least = >> you >> should mention this, if not fix it. > > There should not be problems with the ingress filters, as we always > use the source address associated to the given interface when sending > packets out. I.e. if we have two interfaces A and B, having IPa and > IPb, when we send packets out using IPa we always select interface A. > The network connected to the interface should allow IPa to pass > through it as it is IP address given by the network to the host for > that interface. Implementations might need to do specific things to > bypass routing of those packets (using default route or similar) to > make use they are really sent out from the host using proper > interface. > yes in this case there shouldn't be problems with ingress filters. = However, as i understand it, it is expected that a common multihoming = scenario is that multiple PA address blocks are assigned to a = multihomed site (one per isp serving the site), so that there will be = multiple global addresses assigned to each interface connected to the = multihomed site. In this case, selecting the egress interface doesn't help you selecting = among the multiple addresses assigned to that interface. However, you still may have problem with ingress filters because each = address has been assigned by a different ISP, implying that if ingress = filters are in place, each isp will only route those packets that = contain the prefix delegated by the particular isp in the source = address of the packet. hence, we may have ingress filters = incompatibility issues, so unidirectional paths may be quite frequent = if no ingress filters compatibility mechanisms are in place (for more = about this check draft-huitema-shim6-ingress-filtering-00.txt >> 4. Establishment of the initial IKE session. No reference is made = >> about >> how the initial contact between the two parties is made. I mean, in = >> case >> that both have multiple addresses, and that some of them are not >> working, the initial contact may not be trivial. Maybe this is out of >> the scope of mobike, but current specs don't support this scenario, so >> maybe it would be worth noting it. > > I think the assumption is that the initiator knows the IP address (or > IP-addresses) of the other peer before the connection is even > initiated, thus MOBIKE will simply try the different addresses trying > to find working one. > i guess that this at least needs to be specified i.e. that mobike will = try with different addresses.... question: is mobike going to retry = using only different destination addresses or it will also try with = different source addresses? i guess it makes sense to try with = different source addresses as well, in particular, with all the = possible combinations src and dst addresses available. However, while it may be quite common that a node retires with = different dest addresses (hey, rfc3484 says that a node SHOULD do it) = currently, it is not usual AFAIK retrials with different source = addresses, hence why mobike should explicitly mention it if you want = this imho >> >> 5. In the document, it seems that an important design choice that was >> made was that (section 3.1) > ... [about the initiator selects approach] > > That discussion about why that approach was selected and what it > causes does not belong to the protocol document. It should be > something that is in the design document. > right however, my intention was somehow different than the rationale for this = choice is included in the doc. my point was that: - as i understand it, when designing the protocol, the wg decided to = assume this asymetrical roles, where the initiator is kind of = responsible for selecting addresses and so on. - based on this choice, the protocol was designed. - now, once that protocol is ready, the assumption is still there. My point was to identify how this asumption really affects the = resulting protocol and see if it is still needed. As i see it, the protocol is quite symetrical and there only a few = corner cases where this assumption is needed. In particular, for - simultaneous movement - responder behind a nat. OTOH, there are a couple of special cases described in the protocol, in = order to allow the responder to change addresses to deal with some = situations. So my question is: wouldn't it be easier/simpler to define a symetrical protocol stating = that simultaneous movement and both aprties behind nat situations are = not supported. If this can be done, the protocol would be more general and there = wouldn't be needed those special situations where one of the parties = need to do special operations (responder changing addresses) >> 11. In section 4.5. the NO_ADDITIONAL_ADDRESSES notification is >> presented. As i understand it, this is the only way to delete = >> addresses >> from the address set, right? >> This is kind of twisted, i think. I mean, if a node wants to delete = >> one >> address because is no longer available it, must: >> - delete all the addresses using a NO_ADDITIONAL_ADDRESSES = >> notification >> message >> - add other addresses with a ADDITIONAL_ADDRESSES notification >> is this so? >> If yes, i think this should be clearly stated imho (at least that the >> NO_ADDITIONAL_ADDRESSES notification serves to delete addresses) > > No, I have not understood that section that way. I assumed that the > new list of addresses (ADDITIONAL_ADDRESSES) always overwrites the > whole previous list. I.e. it is not incremental update, but it is full > list every time. In some cases where you have only one IP-address, the > ADDITIONAL_ADDRESSES notify would not be there, and you need to have > some way to tell that there is no other addresses than the one that is > used in the IP-headers of this packet. > ok, i think we have identified an important element here: my reading of = this was that additional addresses are incremental to the set already = available. I think that it would be very important to explictly state whether the = addresses in the additional address is a complete set or an incremental = update. >> 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) > > If the certificate is self signed, and it is trusted by the recipient > there is no problem. The basic idea is that in the VPN case where > multiple sites are connected together with VPN gateways each having > one or two addresses, each VPN gateway can have certificate which > lists the IP-addresses they have. The VPN gateways are not going to > get new address on the fly, thus they can use IP-addresses from the > certificates. Also the most common case of road warrior will probably > be that the gateway is authenticated with certificate and the client > is authenticated with some EAP method. In that case it would be > useless for clients to do return routability to the server's second > address, when the first address happen to go down. > ok regards, marcelo > -- = > 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 Sun Oct 16 12:03:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERAz3-0004z7-90 for mobike-archive@megatron.ietf.org; Sun, 16 Oct 2005 12:03:37 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08300 for ; Sun, 16 Oct 2005 12:03:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 30206FB286; Sun, 16 Oct 2005 16:03:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7D95BFB27D; Sun, 16 Oct 2005 16:03:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B119AFB281; Sun, 16 Oct 2005 16:03:28 +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 B69F3FB262 for ; Sun, 16 Oct 2005 16:03:26 +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 j9GG2ol08956; Sun, 16 Oct 2005 18:02:50 +0200 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 j9GG2orZ014545; Sun, 16 Oct 2005 18:02:51 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510161602.j9GG2orZ014545@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: mobike@machshav.com Date: Sun, 16 Oct 2005 18:02:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: pasi.eronen@nokia.com Subject: [Mobike] review 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: , 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 Here is my review of draft-ietf-mobike-protocol-04.txt. I've seen some comments in the list but had not enough time to really read them, so I apologize if I point some already known problems... - in 1 page 3 IKEv2 is used for performing mutual authentication and establishing and maintaining IPsec Security Associations (SAs). => too many "and"s - in 3.1 page 5 Making the decision at the initiator is consistent with how normal IKEv2 works: the initiator decides which addresses it uses when contacting the responder. It also makes sense, especially when the initiator is the mobile node: it is in a better position to decide which of its network interfaces should be used for both upstream and downstream traffic. => as this has some limitations IMHO there should be a pointer to the section 3.4 "Limitations". - in 3.2 page 6 and others Initiator Responder ----------- ----------- 1) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) ... => I believe the illustration needs the IP addresses and ports from IP and UDP headers. If someone finds a good way to add them, the whole stuff will become far more readable. - in 4.3 page 10 Note that if some of the initiator's interfaces are behind a NAT (from the responder's point of view), the addresses received by the responder will be incorrect. This means the procedure for changing responder addresses described in Section 4.5 does not fully work when the initiator is behind a NAT. For the same reason, the peers also SHOULD NOT use this information for any other purposes than what is explicitly described in this document. => I have a problem with "this document". I propose to relax it in "MOBIKE documents". - in 4.4 page 11 The reasons why the initiator wishes to change the addresses are largely beyond the scope of MOBIKE. Typically, triggers include information received from lower layers, such as changes in IP addresses or link-down indications. Some of this information can be unreliable: for instance, ICMP messages could be spoofed by an attacker. Unreliable information itself MUST NOT be used to conclude than an update is needed: instead, the initiator SHOULD trigger dead peer detection (that is, send an INFORMATIONAL request). => this at the first read seems to conflict with path testing (4.9). IMHO some clarification is needed, I propose something like (after "an update is needed") "because the current path seems to be no more usable"... - about 4.4: if/when we'd like to extend the mechanism, two things seem to be interesting: - the capability to move to another addresses (than the addresses in the IP header of the message), for instance for network controlled mobility. - the capability to limit the update to a SA set (i.e., partial update). Both will be easier with a payload... - in 4.5 page 14 As described in Section 4.3, 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. => there is no explanation about NO_ADDITIONAL_ADDRESSES: 4.3 can't help because it doesn't use it. I propose to move or copy some text from 5.3 where the notification is described. - in 4.6 page 15 To ensure that the peer cannot generate the correct INFORMATIONAL response without seeing the request, a new payload is added to INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY include a COOKIE2 notification, and if included, the recipient of an INFORMATIONAL request MUST copy the notification as-is to the response. When processing the response, the original sender MUST verify that the value is the same one as sent. If the values do not match, the IKE_SA MUST be closed. => there is no explanation about COOKIE2, I propose an explicit pointer to section 5.6. - in 4.9 page 17 IKEv2 Dead Peer Detection allows the peers to detect if the currently used path has stopped working. However, if either of the peers has several addresses, Dead Peer Detection alone does not tell which of the other paths might work. => this text is fine but perhaps a bit late in the document (i.e., path testing should be in the overview too)? - in 5 => I believe "notification" is better English than "notify" but as the IKEv2 document uses "notify payloads"... - in 5.3 page 18 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 4.5 for more detailed description). => in fact in the *current* document there is no description at all of NO_ADDITIONAL_ADDRESSES... - in 6.1 page 20 MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. This feature is mainly intended for site-to-site VPN cases, where the administrators may know beforehand that valid NATs are not present, and thus any modification to the packet can be considered an attack. => IPv6 environments are other obvious candidates for NO_NATS_ALLOWED! 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 Oct 17 06:37:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERSNM-00074D-0L for mobike-archive@megatron.ietf.org; Mon, 17 Oct 2005 06:37:54 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02638 for ; Mon, 17 Oct 2005 06:37:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E2EAFFB289; Mon, 17 Oct 2005 10:37:49 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B244DFB280; Mon, 17 Oct 2005 10:37:45 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 95720FB284; Mon, 17 Oct 2005 10:37:44 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E5A13FB262 for ; Mon, 17 Oct 2005 10:37:42 +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 j9HAbcNV015217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2005 13:37:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9HAbbgj003815; Mon, 17 Oct 2005 13:37:37 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17235.32497.539908.156312@fireball.kivinen.iki.fi> Date: Mon, 17 Oct 2005 13:37:37 +0300 From: Tero Kivinen To: marcelo bagnulo braun In-Reply-To: References: <434D18B3.2040100@piuha.net> <17230.21142.330797.663268@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 15 min Cc: Jari Arkko , MOBIKE Mailing List Subject: Re: [Mobike] FW: Marcelo's review of mobike protocol 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 marcelo bagnulo braun writes: > > There should not be problems with the ingress filters, as we always > > use the source address associated to the given interface when sending > > packets out. I.e. if we have two interfaces A and B, having IPa and > > IPb, when we send packets out using IPa we always select interface A. > > The network connected to the interface should allow IPa to pass > > through it as it is IP address given by the network to the host for > > that interface. Implementations might need to do specific things to > > bypass routing of those packets (using default route or similar) to > > make use they are really sent out from the host using proper > > interface. > > > > yes in this case there shouldn't be problems with ingress filters. > However, as i understand it, it is expected that a common multihoming > scenario is that multiple PA address blocks are assigned to a > multihomed site (one per isp serving the site), so that there will be > multiple global addresses assigned to each interface connected to the > multihomed site. I do not think that will be the case of the roaming laptop case, i.e. the GPRS, WLAN and fixed ethernet links all give out exctly one IP-address to the connected interface, and you are only supposed to use that IP-address through that interface to which it was given to. > In this case, selecting the egress interface doesn't help you selecting > among the multiple addresses assigned to that interface. > However, you still may have problem with ingress filters because each > address has been assigned by a different ISP, implying that if ingress > filters are in place, each isp will only route those packets that > contain the prefix delegated by the particular isp in the source > address of the packet. hence, we may have ingress filters > incompatibility issues, so unidirectional paths may be quite frequent > if no ingress filters compatibility mechanisms are in place (for more > about this check draft-huitema-shim6-ingress-filtering-00.txt This could be the case in the multihomed VPN case. Note, that MOBIKE should still work perfect, if that unidirectional path does not work (i.e. packets does not get back when IP-addresses are reversed), then that address pair is not used, and we finally end up selecting address pair which does not have that problem with ingress filters. > i guess that this at least needs to be specified i.e. that mobike will > try with different addresses.... question: is mobike going to retry > using only different destination addresses or it will also try with > different source addresses? i guess it makes sense to try with > different source addresses as well, in particular, with all the > possible combinations src and dst addresses available. If it has multiple IP addresses associated to the IKE SA (even before it is created) then it should try all combinations of them through the normal IKE SA retransmission policy. > However, while it may be quite common that a node retires with > different dest addresses (hey, rfc3484 says that a node SHOULD do it) > currently, it is not usual AFAIK retrials with different source > addresses, hence why mobike should explicitly mention it if you want > this imho Yes, might be good idea explicitly mention this anyways. > So my question is: > wouldn't it be easier/simpler to define a symetrical protocol stating > that simultaneous movement and both aprties behind nat situations are > not supported. With fully symmetric protocol we cannot really support NAT-T at all. Neither for initiator or responder, as with symmetric protocol there is no difference in that. The end host which is behind NAT must take asymmetric action and fix the situation which its addresses change, as the other end cannot send packets to the new address before host behind NAT has done so. This means that the protocol will always be asymmetric if NAT-T is desired. > If this can be done, the protocol would be more general and there > wouldn't be needed those special situations where one of the parties > need to do special operations (responder changing addresses) This was quite extensively discussed on the list and meetings before the selection of the "initiator decices" was done. We did try few protocols that tried to be symmetric, but they did get much more complicated immediately when NAT-T was added. Actually my initial protocol was one of those symmetric ones but it didn't support any NAT traversal. I still think all the discussion about this belongs to the design draft. > > ok, i think we have identified an important element here: my reading of > this was that additional addresses are incremental to the set already > available. > > I think that it would be very important to explictly state whether the > addresses in the additional address is a complete set or an incremental > update. Agree on that. (and it is complete set). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 17 06:44:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERSTW-0000B9-QG for mobike-archive@megatron.ietf.org; Mon, 17 Oct 2005 06:44:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02911 for ; Mon, 17 Oct 2005 06:44:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id ECCA6FB291; Mon, 17 Oct 2005 10:44:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 60C06FB286; Mon, 17 Oct 2005 10:44:07 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9ACF4FB28A; Mon, 17 Oct 2005 10:44:05 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 69182FB285 for ; Mon, 17 Oct 2005 10:44:04 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9294989884; Mon, 17 Oct 2005 13:43:58 +0300 (EEST) Message-ID: <4353807B.40208@piuha.net> Date: Mon, 17 Oct 2005 13:44:11 +0300 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: <434D18B3.2040100@piuha.net> <17230.21142.330797.663268@fireball.kivinen.iki.fi> <17235.32497.539908.156312@fireball.kivinen.iki.fi> In-Reply-To: <17235.32497.539908.156312@fireball.kivinen.iki.fi> Cc: MOBIKE Mailing List Subject: Re: [Mobike] FW: Marcelo's review of mobike protocol 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: >marcelo bagnulo braun writes: > > >>>There should not be problems with the ingress filters, as we always >>>use the source address associated to the given interface when sending >>>packets out. I.e. if we have two interfaces A and B, having IPa and >>>IPb, when we send packets out using IPa we always select interface A. >>>The network connected to the interface should allow IPa to pass >>>through it as it is IP address given by the network to the host for >>>that interface. Implementations might need to do specific things to >>>bypass routing of those packets (using default route or similar) to >>>make use they are really sent out from the host using proper >>>interface. >>> >>> >>> >>yes in this case there shouldn't be problems with ingress filters. >>However, as i understand it, it is expected that a common multihoming >>scenario is that multiple PA address blocks are assigned to a >>multihomed site (one per isp serving the site), so that there will be >>multiple global addresses assigned to each interface connected to the >>multihomed site. >> >> > >I do not think that will be the case of the roaming laptop case, i.e. >the GPRS, WLAN and fixed ethernet links all give out exctly one >IP-address to the connected interface, and you are only supposed to >use that IP-address through that interface to which it was given to. > > In IPv6 it is indeed possible that you have multiple addresses and prefixes on a single interface. Then the issues that Marcelo refers to become possible. But from what I understand we can deal with that in an orthogonal way, i.e., this is an issue in MOBIKE usage, in SHIM6 usage, and even when no multihoming protocol is used at all. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 17 06:45:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERSUb-0000Qb-8O for mobike-archive@megatron.ietf.org; Mon, 17 Oct 2005 06:45:21 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02989 for ; Mon, 17 Oct 2005 06:45:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2DD5EFB28F; Mon, 17 Oct 2005 10:45:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 04F6EFB28A; Mon, 17 Oct 2005 10:45:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8ECF4FB28D; Mon, 17 Oct 2005 10:45:14 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 8850DFB285 for ; Mon, 17 Oct 2005 10:45:13 +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 j9HAjAhH012432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Oct 2005 13:45:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9HAj9rK023454; Mon, 17 Oct 2005 13:45:09 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17235.32949.739999.592156@fireball.kivinen.iki.fi> Date: Mon, 17 Oct 2005 13:45:09 +0300 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200510161602.j9GG2orZ014545@givry.rennes.enst-bretagne.fr> References: <200510161602.j9GG2orZ014545@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: pasi.eronen@nokia.com, mobike@machshav.com Subject: [Mobike] review 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 Francis Dupont writes: > - in 3.2 page 6 and others > > Initiator Responder > ----------- ----------- > 1) HDR, SAi1, KEi, Ni, > N(NAT_DETECTION_*_IP) --> > > <-- HDR, SAr1, KEr, Nr, > N(NAT_DETECTION_*_IP) > ... > > => I believe the illustration needs the IP addresses and ports from > IP and UDP headers. If someone finds a good way to add them, the whole > stuff will become far more readable. Yes. Perhaps something like HDR(IP1:500,IP2:500) would be readable enough? -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 17 12:16:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXes-00078k-5e for mobike-archive@megatron.ietf.org; Mon, 17 Oct 2005 12:16:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22080 for ; Mon, 17 Oct 2005 12:16:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9C17CFB286; Mon, 17 Oct 2005 16:16:15 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 64277FB280; Mon, 17 Oct 2005 16:16:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AA704FB284; Mon, 17 Oct 2005 16:16:09 +0000 (UTC) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by machshav.com (Postfix) with ESMTP id 0B07EFB280 for ; Mon, 17 Oct 2005 16:16:08 +0000 (UTC) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E972E9D290; Mon, 17 Oct 2005 18:16:03 +0200 (CEST) Received: from [163.117.203.24] (unknown [163.117.203.24]) by smtp01.uc3m.es (Postfix) with ESMTP id 16F929D274; Mon, 17 Oct 2005 18:16:01 +0200 (CEST) In-Reply-To: <4353807B.40208@piuha.net> References: <434D18B3.2040100@piuha.net> <17230.21142.330797.663268@fireball.kivinen.iki.fi> <17235.32497.539908.156312@fireball.kivinen.iki.fi> <4353807B.40208@piuha.net> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <43f2568865703b32e2a7a45a03df283a@it.uc3m.es> From: marcelo bagnulo braun Date: Mon, 17 Oct 2005 18:14:30 +0200 To: Jari Arkko X-Mailer: Apple Mail (2.623) Cc: MOBIKE Mailing List , Tero Kivinen Subject: Re: [Mobike] FW: Marcelo's review of mobike protocol 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable El 17/10/2005, a las 12:44, Jari Arkko escribi=F3: > Tero Kivinen wrote: > >> marcelo bagnulo braun writes: >> >>>> There should not be problems with the ingress filters, as we always >>>> use the source address associated to the given interface when = >>>> sending >>>> packets out. I.e. if we have two interfaces A and B, having IPa and >>>> IPb, when we send packets out using IPa we always select interface = >>>> A. >>>> The network connected to the interface should allow IPa to pass >>>> through it as it is IP address given by the network to the host for >>>> that interface. Implementations might need to do specific things to >>>> bypass routing of those packets (using default route or similar) to >>>> make use they are really sent out from the host using proper >>>> interface. >>>> >>>> >>> yes in this case there shouldn't be problems with ingress filters. = >>> However, as i understand it, it is expected that a common = >>> multihoming scenario is that multiple PA address blocks are assigned = >>> to a multihomed site (one per isp serving the site), so that there = >>> will be multiple global addresses assigned to each interface = >>> connected to the multihomed site. >>> >> >> I do not think that will be the case of the roaming laptop case, i.e. >> the GPRS, WLAN and fixed ethernet links all give out exctly one >> IP-address to the connected interface, and you are only supposed to >> use that IP-address through that interface to which it was given to. >> > In IPv6 it is indeed possible that you have multiple > addresses and prefixes on a single interface. Then the > issues that Marcelo refers to become possible. But > from what I understand we can deal with that in an > orthogonal way, i.e., this is an issue in MOBIKE usage, > in SHIM6 usage, and even when no multihoming protocol > is used at all. > right, but supporting unidirectional paths in the protocol makes the = protocol to perform better in such scenarios I mean, as i see it, or you assume that there is something that will = take care of ingress filtering compatibility, in which case, supporting = unidirectional connectivity support doesn't brings you much, or you = don't assume some ingress filtering compatibility mechanism and then = supporting unidirectional paths does buy you some extra performance. = but the mobike protocol doesn't seems to do none of them afaict (or at = least it doesn't state anything about this) regards, marcelo > --Jari > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 17 12:16:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXf4-0007Fg-HA for mobike-archive@megatron.ietf.org; Mon, 17 Oct 2005 12:16:30 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22122 for ; Mon, 17 Oct 2005 12:16:22 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DA8A8FB297; Mon, 17 Oct 2005 16:16:28 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1D36BFB28E; Mon, 17 Oct 2005 16:16:18 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7A6DFFB283; Mon, 17 Oct 2005 16:16:10 +0000 (UTC) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by machshav.com (Postfix) with ESMTP id 00D37FB27D for ; Mon, 17 Oct 2005 16:16:08 +0000 (UTC) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 89C7A9D28C; Mon, 17 Oct 2005 18:16:06 +0200 (CEST) Received: from [163.117.203.24] (unknown [163.117.203.24]) by smtp01.uc3m.es (Postfix) with ESMTP id 15FA99D294; Mon, 17 Oct 2005 18:16:04 +0200 (CEST) In-Reply-To: <17235.32497.539908.156312@fireball.kivinen.iki.fi> References: <434D18B3.2040100@piuha.net> <17230.21142.330797.663268@fireball.kivinen.iki.fi> <17235.32497.539908.156312@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <50d1b963376378a928966199b7ec1051@it.uc3m.es> From: marcelo bagnulo braun Date: Mon, 17 Oct 2005 18:09:41 +0200 To: Tero Kivinen X-Mailer: Apple Mail (2.623) Cc: MOBIKE Mailing List , Jari Arkko Subject: Re: [Mobike] FW: Marcelo's review of mobike protocol 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable El 17/10/2005, a las 12:37, Tero Kivinen escribi=F3: > marcelo bagnulo braun writes: >>> There should not be problems with the ingress filters, as we always >>> use the source address associated to the given interface when sending >>> packets out. I.e. if we have two interfaces A and B, having IPa and >>> IPb, when we send packets out using IPa we always select interface = >>> A. >>> The network connected to the interface should allow IPa to pass >>> through it as it is IP address given by the network to the host for >>> that interface. Implementations might need to do specific things to >>> bypass routing of those packets (using default route or similar) to >>> make use they are really sent out from the host using proper >>> interface. >>> >> >> yes in this case there shouldn't be problems with ingress filters. >> However, as i understand it, it is expected that a common multihoming >> scenario is that multiple PA address blocks are assigned to a >> multihomed site (one per isp serving the site), so that there will be >> multiple global addresses assigned to each interface connected to the >> multihomed site. > > I do not think that will be the case of the roaming laptop case, i.e. > the GPRS, WLAN and fixed ethernet links all give out exctly one > IP-address to the connected interface, and you are only supposed to > use that IP-address through that interface to which it was given to. > >> In this case, selecting the egress interface doesn't help you = >> selecting >> among the multiple addresses assigned to that interface. >> However, you still may have problem with ingress filters because each >> address has been assigned by a different ISP, implying that if ingress >> filters are in place, each isp will only route those packets that >> contain the prefix delegated by the particular isp in the source >> address of the packet. hence, we may have ingress filters >> incompatibility issues, so unidirectional paths may be quite frequent >> if no ingress filters compatibility mechanisms are in place (for more >> about this check draft-huitema-shim6-ingress-filtering-00.txt > > This could be the case in the multihomed VPN case. Note, that MOBIKE > should still work perfect, if that unidirectional path does not work > (i.e. packets does not get back when IP-addresses are reversed), then > that address pair is not used, and we finally end up selecting address > pair which does not have that problem with ingress filters. > right, if such path exists It maybe the case, that only disjunct unidirectional paths exists, = because of ingress filters. In this case, mobike protocol wouldn't achieve to communicate, even if = a path exists, and it would be possible to communicate if the mobike = protocol supported different addresses in the different peers of the = communication >> i guess that this at least needs to be specified i.e. that mobike will >> try with different addresses.... question: is mobike going to retry >> using only different destination addresses or it will also try with >> different source addresses? i guess it makes sense to try with >> different source addresses as well, in particular, with all the >> possible combinations src and dst addresses available. > > If it has multiple IP addresses associated to the IKE SA (even before > it is created) then it should try all combinations of them through the > normal IKE SA retransmission policy. does the IKE SA retransmission policy tries different source addresses? regards, marcelo _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 17 12:23:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERXmH-0008B6-IM for mobike-archive@megatron.ietf.org; Mon, 17 Oct 2005 12:23:59 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22467 for ; Mon, 17 Oct 2005 12:23:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5A982FB23E; Mon, 17 Oct 2005 16:23:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7AA6EFB249; Mon, 17 Oct 2005 16:23:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 01375FB249; Mon, 17 Oct 2005 16:23:48 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 49B34FB28D for ; Mon, 17 Oct 2005 16:23:47 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9B8258988C; Mon, 17 Oct 2005 19:23:45 +0300 (EEST) Message-ID: <4353D01F.9030902@piuha.net> Date: Mon, 17 Oct 2005 19:23:59 +0300 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 References: <434D18B3.2040100@piuha.net> <17230.21142.330797.663268@fireball.kivinen.iki.fi> <17235.32497.539908.156312@fireball.kivinen.iki.fi> <4353807B.40208@piuha.net> <43f2568865703b32e2a7a45a03df283a@it.uc3m.es> In-Reply-To: <43f2568865703b32e2a7a45a03df283a@it.uc3m.es> Cc: MOBIKE Mailing List , Tero Kivinen Subject: Re: [Mobike] FW: Marcelo's review of mobike protocol 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 marcelo bagnulo braun wrote: > right, but supporting unidirectional paths in the protocol makes the > protocol to perform better in such scenarios That's right. But such support is hard (as we have found out in shim6... which only supports this partially). Perhaps more importantly, MOBIKE had a discussion about the unidirectional paths some months ago and made a decision in the WG that we're not doing it. Reasons behind this included toughness of supporting it with NAT traversal, among others. I'd rather not re-open that discussion unless we find a serious problem. We are already aware that we can't support some scenarios due to this - that's fine. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 17 15:12:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERaOt-0007PN-Ue for mobike-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:12:00 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01801 for ; Mon, 17 Oct 2005 15:11:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6E223FB285; Mon, 17 Oct 2005 19:11:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E4A7DFB27D; Mon, 17 Oct 2005 19:11:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A11EFB280; Mon, 17 Oct 2005 19:11:51 +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 B206BFB23C for ; Mon, 17 Oct 2005 19:11:50 +0000 (UTC) Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Oct 2005 15:11:50 -0400 X-IronPort-AV: i="3.97,222,1125892800"; d="scan'208"; a="73883167:sNHT25041004" 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 j9HJBJFA017743 for ; Mon, 17 Oct 2005 15:11:48 -0400 (EDT) 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); Mon, 17 Oct 2005 15:11:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 17 Oct 2005 15:11:44 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD6B35453@xmb-rtp-208.amer.cisco.com> Thread-Topic: Stephane Beaulieu's comments on draft-mobike-protocol-04.txt Thread-Index: AcXTTpytZ145wdCkR0W5V0f285uAOQ== From: "Stephane Beaulieu (stephane)" To: X-OriginalArrivalTime: 17 Oct 2005 19:11:44.0857 (UTC) FILETIME=[9D389C90:01C5D34E] Subject: [Mobike] Stephane Beaulieu's comments on draft-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 Section 3. "MOBIKE allows both parties to have several addresses, and there are up to N*M pairs of IP addresses that could potentially be used." - Do we not also allow a party to temporarily have 0 addresses? While I walk from the office to Starbucks across the street, I may loose all wireless for a few minutes. ++++++++++++++++++++++++++ Section 3.2 (2nd example) "(The initiator gives up on the current address pair, and tests the other available address pair.)" - Can the initiator test multiple address pairs simultaneously? (assuming he has the window space to do so). - If not, how many retries and how many seconds between each retry on a single address pair before we move on to the next? Are there recommendations for this, or is this purely implementation detail? +++++++++++++++++++++++++++++ Section 3.2 - Is there a way to remove an address? (ex. Pull out my wireless adapter). Tero mentioned in another thread that he assumed that sending a new ADDITIONAL_X_ADDRESS notify overwrote all past addresses, but this isn't clear to me from the text. ++++++++++++++++++++++++++++++ Section 3.3 IMO, there should be text in this section that explains that Mobike tries to detect sporadic NAT mapping changes by adding NATD payloads in the DPD msgs. I know this is explained later, but I would expect to hear something about this in this section, since this is the "NAT" section. ++++++++++++++++++++++++++++++ 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? Thanks, Stephane. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 18 03:43:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERm88-00030F-2C for mobike-archive@megatron.ietf.org; Tue, 18 Oct 2005 03:43:30 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10490 for ; Tue, 18 Oct 2005 03:43:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DEBEEFB285; Tue, 18 Oct 2005 07:43:25 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1265CFB27D; Tue, 18 Oct 2005 07:43:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 56FF8FB280; Tue, 18 Oct 2005 07:43:20 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 212A8FB262 for ; Tue, 18 Oct 2005 07:43:19 +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 j9I7h9xH007900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2005 10:43:09 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9I7h7jm008845; Tue, 18 Oct 2005 10:43:07 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17236.42891.929945.265721@fireball.kivinen.iki.fi> Date: Tue, 18 Oct 2005 10:43:07 +0300 From: Tero Kivinen To: marcelo bagnulo braun In-Reply-To: <50d1b963376378a928966199b7ec1051@it.uc3m.es> References: <434D18B3.2040100@piuha.net> <17230.21142.330797.663268@fireball.kivinen.iki.fi> <17235.32497.539908.156312@fireball.kivinen.iki.fi> <50d1b963376378a928966199b7ec1051@it.uc3m.es> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: MOBIKE Mailing List , Jari Arkko Subject: Re: [Mobike] FW: Marcelo's review of mobike protocol 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 marcelo bagnulo braun writes: > right, if such path exists Yes. We do assume there is working IP-pair that allows us to get packets in both direction. This does not really matter if this consists of two unidirectional paths, as long as it is routers who take care of that (i.e. not MOBIKE). > It maybe the case, that only disjunct unidirectional paths exists, > because of ingress filters. > In this case, mobike protocol wouldn't achieve to communicate, even if > a path exists, and it would be possible to communicate if the mobike > protocol supported different addresses in the different peers of the > communication If I understand correctly TCP would not work in that case too (i.e. TCP also assumes you can send and receive packets using same IP-pair in both ends, just reverse the IP-addresses). Both TCP or MOBIKE can be made so that they do not really cares which interface was used to send packet out and from which interface it was received, but that is operating system issue, not protocol issue. MOBIKE does not try to work in cases where you need to use different IP-address pair in one direction and another pair to the other direction. > > If it has multiple IP addresses associated to the IKE SA (even before > > it is created) then it should try all combinations of them through the > > normal IKE SA retransmission policy. > > does the IKE SA retransmission policy tries different source addresses? MOBIKE section 4.4. tells what to do if IKEv2 request has been re-transmited several times with no reply, and when initiator decides new address, he should go through all possible address combinations before giving up. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 18 04:20:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERmhU-00072u-1u for mobike-archive@megatron.ietf.org; Tue, 18 Oct 2005 04:20:00 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12376 for ; Tue, 18 Oct 2005 04:19:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 42649FB285; Tue, 18 Oct 2005 08:19:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C5AB2FB284; Tue, 18 Oct 2005 08:19:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B0A9AFB285; Tue, 18 Oct 2005 08:19:44 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id BBC8DFB283 for ; Tue, 18 Oct 2005 08:19:41 +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 j9I8JZDQ018099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Oct 2005 11:19:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9I8JYV8014691; Tue, 18 Oct 2005 11:19:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17236.45078.849125.672904@fireball.kivinen.iki.fi> Date: Tue, 18 Oct 2005 11:19:34 +0300 From: Tero Kivinen To: "Stephane Beaulieu (stephane)" In-Reply-To: <13E3DA8B48E17D4C96D261A36A23FCD6B35453@xmb-rtp-208.amer.cisco.com> References: <13E3DA8B48E17D4C96D261A36A23FCD6B35453@xmb-rtp-208.amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 26 min X-Total-Time: 33 min Cc: mobike@machshav.com Subject: [Mobike] Stephane Beaulieu's comments on draft-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 (stephane) writes: > > Section 3. > "MOBIKE allows both parties to have several addresses, and there are > up to N*M pairs of IP addresses that could potentially be used." > > - Do we not also allow a party to temporarily have 0 addresses? While I > walk from the office to Starbucks across the street, I may loose all > wireless for a few minutes. No we do not allow zero addresses. See issue 5 in the issue list. Also the current protocol implictly always have the IP-address in headers in the address set, so there is no way to express that in the protocol. > Section 3.2 (2nd example) > "(The initiator gives up on the current address pair, and tests the > other available address pair.)" > > - Can the initiator test multiple address pairs simultaneously? > (assuming he has the window space to do so). As he is using the single message to test all addresse pairs he would not need window to test multiple address pairs, but on the other hand in the issue 14 we decided that we want to test them sequentially and using exponential back-off procedure (to make sure we do not make the congestion worse). > - If not, how many retries and how many seconds between each retry on a > single address pair before we move on to the next? Are there > recommendations for this, or is this purely implementation detail? Implementation datails. My guess is that as the most of those IKE packets are very fast to respond to, we should mostly count only the round trip time (unless the message we are trying to send has some expensive calculations like Diffie-Helmman). I.e. the first retransmission can happen after 2 * RTT, and next for example 1.4 * from that, and after 2-3 tries with one IP pair you can move to the next one, keeping the retries to use same exponential timer up to certain max limit. So if you have IPa1 and IPa2 in your end and IPb1 and IPb2 for the other end, you end up following retransmissions: Time Cumulative Time Src-IP Dst-IP from prev from start --------- ---------- ------ ------ 0.000 0.000 IPa1 IPb1 0.400 0.400 IPa1 IPb1 0.560 0.960 IPa1 IPb1 0.784 1.744 IPa1 IPb2 1.098 2.842 IPa1 IPb2 1.537 4.378 IPa1 IPb2 2.151 6.530 IPa2 IPb2 3.012 9.541 IPa2 IPb2 4.217 13.758 IPa2 IPb2 5.903 19.661 IPa2 IPb1 8.264 27.925 IPa2 IPb1 11.570 39.496 IPa2 IPb1 After that it has tried all addresses, and none of them work, so he might want to start testing them rapidly, to see if one of them is going to get fixed during the rest of time (and stop slowing the retransmission after 30 seconds): 16.198 55.694 IPa1 IPb1 22.678 78.371 IPa1 IPb2 30.000 108.371 IPa2 IPb2 30.000 138.371 IPa2 IPb1 30.000 168.371 IPa1 IPb1 30.000 198.371 IPa1 IPb2 30.000 228.371 IPa2 IPb2 And finally give up after 4 minutes of trying. The exact value of exponent, the initial retransmission timer, number of tries per IP and the max limit for the timer etc are all of course implementation and scenario dependent. For example in the GRPS network you might want to use initial timer of 2 seconds, use exponent of 2, try each IP-address only twice, and have a max limit of 10 seconds. > 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. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 18 09:54:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ERrvA-000153-BP for mobike-archive@megatron.ietf.org; Tue, 18 Oct 2005 09:54:28 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00871 for ; Tue, 18 Oct 2005 09:54:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9BA41FB27D; Tue, 18 Oct 2005 13:54:25 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E83D0FB262; Tue, 18 Oct 2005 13:54:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1FBE8FB27D; Tue, 18 Oct 2005 13:54:16 +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 B3DC0FB246 for ; Tue, 18 Oct 2005 13:54:14 +0000 (UTC) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 18 Oct 2005 06:54:12 -0700 X-IronPort-AV: i="3.97,228,1125903600"; d="scan'208"; a="353616220:sNHT29674948" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9IDrlup008696; Tue, 18 Oct 2005 06:54:10 -0700 (PDT) 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); Tue, 18 Oct 2005 09:54:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 18 Oct 2005 09:54:02 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD6B3565B@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Mobike] Stephane Beaulieu's comments ondraft-mobike-protocol-04.txt Thread-Index: AcXTvLXwciLk+hgBQ2aCm1S4TQs5jQALgkpQ From: "Stephane Beaulieu (stephane)" To: "Tero Kivinen" X-OriginalArrivalTime: 18 Oct 2005 13:54:03.0775 (UTC) FILETIME=[665810F0:01C5D3EB] Cc: mobike@machshav.com Subject: Re: [Mobike] Stephane Beaulieu's comments ondraft-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 Inline [SB] > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, October 18, 2005 4:20 AM > To: Stephane Beaulieu (stephane) > Cc: mobike@machshav.com > Subject: [Mobike] Stephane Beaulieu's comments > ondraft-mobike-protocol-04.txt > > Stephane Beaulieu (stephane) writes: > > > > Section 3. > > "MOBIKE allows both parties to have several addresses, and there are > > up to N*M pairs of IP addresses that could potentially be used." > > > > - Do we not also allow a party to temporarily have 0 > addresses? While > > I walk from the office to Starbucks across the street, I > may loose all > > wireless for a few minutes. > > No we do not allow zero addresses. See issue 5 in the issue > list. Also the current protocol implictly always have the > IP-address in headers in the address set, so there is no way > to express that in the protocol. [SB] Thanks. Went back and re-read the notes on issue #5, and I see the reasoning behind it. > > > Section 3.2 (2nd example) > > "(The initiator gives up on the current address pair, and tests the > > other available address pair.)" > > > > - Can the initiator test multiple address pairs simultaneously? > > (assuming he has the window space to do so). > > As he is using the single message to test all addresse pairs > he would not need window to test multiple address pairs, but > on the other hand in the issue 14 we decided that we want to > test them sequentially and using exponential back-off > procedure (to make sure we do not make the congestion worse). [SB] OK. Some text to that effect would be helpful. > > > - If not, how many retries and how many seconds between > each retry on > > a single address pair before we move on to the next? Are there > > recommendations for this, or is this purely implementation detail? > > Implementation datails. My guess is that as the most of those > IKE packets are very fast to respond to, we should mostly > count only the round trip time (unless the message we are > trying to send has some expensive calculations like > Diffie-Helmman). I.e. the first retransmission can happen > after 2 * RTT, and next for example 1.4 * from that, and > after 2-3 tries with one IP pair you can move to the next > one, keeping the retries to use same exponential timer up to > certain max limit. [SB] OK. This is fine with me. > > So if you have IPa1 and IPa2 in your end and IPb1 and IPb2 > for the other end, you end up following retransmissions: > > Time Cumulative Time Src-IP Dst-IP > from prev from start > --------- ---------- ------ ------ > 0.000 0.000 IPa1 IPb1 > 0.400 0.400 IPa1 IPb1 > 0.560 0.960 IPa1 IPb1 > 0.784 1.744 IPa1 IPb2 > 1.098 2.842 IPa1 IPb2 > 1.537 4.378 IPa1 IPb2 > 2.151 6.530 IPa2 IPb2 > 3.012 9.541 IPa2 IPb2 > 4.217 13.758 IPa2 IPb2 > 5.903 19.661 IPa2 IPb1 > 8.264 27.925 IPa2 IPb1 > 11.570 39.496 IPa2 IPb1 > > After that it has tried all addresses, and none of them work, > so he might want to start testing them rapidly, to see if one > of them is going to get fixed during the rest of time (and > stop slowing the retransmission after 30 seconds): > > 16.198 55.694 IPa1 IPb1 > 22.678 78.371 IPa1 IPb2 > 30.000 108.371 IPa2 IPb2 > 30.000 138.371 IPa2 IPb1 > 30.000 168.371 IPa1 IPb1 > 30.000 198.371 IPa1 IPb2 > 30.000 228.371 IPa2 IPb2 > > And finally give up after 4 minutes of trying. > > The exact value of exponent, the initial retransmission > timer, number of tries per IP and the max limit for the timer > etc are all of course implementation and scenario dependent. > > For example in the GRPS network you might want to use initial timer of > 2 seconds, use exponent of 2, try each IP-address only twice, > and have a max limit of 10 seconds. > > > 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. > -- > kivinen@safenet-inc.com > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 19 03:51:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ES8jA-0001s1-5S for mobike-archive@megatron.ietf.org; Wed, 19 Oct 2005 03:51:12 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27960 for ; Wed, 19 Oct 2005 03:51:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0A900FB289; Wed, 19 Oct 2005 07:51:02 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D5502FB283; Wed, 19 Oct 2005 07:50:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0D06DFB284; Wed, 19 Oct 2005 07:50:57 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 50DADFB27D for ; Wed, 19 Oct 2005 07:50:56 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7863189854 for ; Wed, 19 Oct 2005 10:50:54 +0300 (EEST) Message-ID: <4355FAEC.4040507@piuha.net> Date: Wed, 19 Oct 2005 10:51:08 +0300 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: <4346E5EF.9080503@piuha.net> In-Reply-To: <4346E5EF.9080503@piuha.net> Subject: [Mobike] REMINDER: WGLC on MOBIKE protocol ends today 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 This is a reminder that the last call ends today. Please review and comment if you haven't already done so! >We are now starting the official Working Group Last Call >on the protocol document: > > http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-04.txt > >The last call will end on Wednesday, October 19th, 2005*. If >you have not already started reading and verifying that the >specification is as you want it to be, please start doing so NOW. >This is your FINAL opportunity to comment on this protocol. > >Jari & Paul > >*) As announced earlier we are cutting the last call period a few >days short in order to give Pasi some time to edit and submit before >the October 24th I-D deadline. Note that since -04 revision consists >entirely of RFC Editor's copy editing changes, the technical content >has been available for review already since the publication of the -03 >draft, and indeed we've already received a number of good review >comments. Keep the coming! > >_______________________________________________ >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 Oct 19 08:39:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESDE4-0006Y5-SC for mobike-archive@megatron.ietf.org; Wed, 19 Oct 2005 08:39:24 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13277 for ; Wed, 19 Oct 2005 08:39:14 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 47D07FB286; Wed, 19 Oct 2005 12:39:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3D29EFB283; Wed, 19 Oct 2005 12:39:18 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A8EE7FB284; Wed, 19 Oct 2005 12:39:15 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 8BF32FB27D for ; Wed, 19 Oct 2005 12:39:14 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9JCdC9u031635; Wed, 19 Oct 2005 15:39:13 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Oct 2005 15:39:12 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Oct 2005 15:39:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 19 Oct 2005 15:39:14 +0300 Message-ID: Thread-Topic: Issue 51: SPI collision Thread-Index: AcXOS8+OELO1+hKyScGGgCiUwlUuIwGXJ+eA From: To: X-OriginalArrivalTime: 19 Oct 2005 12:39:13.0130 (UTC) FILETIME=[1C1FC4A0:01C5D4AA] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 51: SPI collision 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: > When you are sending packets outbound you do lookup from SPD-S > based on the selectors (I1 or I2) and you get SA based on > that. Then in the SA there is the SPI and destination IP to be > used for the other end. Then you simply make tunnel > encapsulation and send the packet along. I do not really see > what is the problem there? > The 4.4.2 of the RFC2401bis says: > ... > For outbound processing, each SAD entry is pointed to by > entries in the SPD-S part of the SPD cache. It seems the issue is about how exactly this "pointing" is implemented. I think Tuomas was saying that storing the (remote tunnel header IP, remote SPI) pair is not a right way to implement this pointing, since it does not always uniquely identify an outbound SA. And as you pointed out, this is not new to MOBIKE: it obviously happens with NAT Traversal, but can happen without NAT-T too (one peer goes away without deleting the SAs; another peer comes in, gets the same address, and creates new SAs with that). I'm not sure what, if anything, the spec should say about this. 2401bis itself is quite clear that it's describing a nominal model, and is not intended to match any real implementations. Clearly there are several ways to implement the pointer, depending on e.g. how exactly the required information is stored (there's no requirement that an implementation has two different data structures, one called SAD and another called SPD), and what programming language is used. But the details of C pointers, Java references, Prolog clauses, or LISP expressions are really beyond the scope of 2401bis (and MOBIKE). So, my gut feeling would be that if something needs to be said about this, the best place would be 2401bis, since the issue is not specific to MOBIKE. Also, it's an implementation detail, so there's no need to specify one single way to do it. However... I think some IPsec implementations have actually got this wrong. Mohan mentioned Linux, and based on a quick look, yes, it seems the 2.6 kernel IPsec uses (remote tunnel header IP, remote SPI, protocol) as the outbound SA lookup key. So maybe it would be worthwhile to mention this, perhaps in a non-normative "implementation considerations" appendix? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 19 13:32:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESHnL-00064A-2J for mobike-archive@megatron.ietf.org; Wed, 19 Oct 2005 13:32:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00200 for ; Wed, 19 Oct 2005 13:31:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 36F33FB286; Wed, 19 Oct 2005 17:32:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DFFDEFB283; Wed, 19 Oct 2005 17:31:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 18075FB284; Wed, 19 Oct 2005 17:31:57 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8B7FEFB27D for ; Wed, 19 Oct 2005 17:31:55 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 37F6A89854 for ; Wed, 19 Oct 2005 20:31:54 +0300 (EEST) Message-ID: <43568317.9040404@piuha.net> Date: Wed, 19 Oct 2005 20:32:07 +0300 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] jari's review of protocol-04 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 are my LC comments. Overall, I'm quite happy with specification as it is. Some technical and editorial issues are listed below, however. I have added names for technical issues to assist in keeping track of what issues we have. Technical: *imprecise explanation of what nat cases are not supported* > "Does not fully support" means that no special effort is made to > support this functionality. However, if the alternative is losing > connectivity completely, the responder can still attempt to proceed > with the change, and depending on, e.g., the exact type of NAT, it > may succeed. However, analyzing the exact circumstances when this > will or will not work is not done in this document. > > I'm OK with the text being vague about the type of scenarios supported beyond the basic client-inside-NAT case. However, the above text appears to say that the responder is capable of detecting such situations, which I don't think is at least always true. *certain vs. possible changed address info* > o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS > notifications is received. This means the peer's addresses may > have changed. > > I think we have two cases: the list (and source) either contains the addresses that we currently know of and use, or they don't. In the former case addresses may have changed, but in the latter case they surely have. For instance, if the peer sends us a message saying that its now in address B instead of A, we really need to take that into account, rather than continuing to use A. Suggestion: explain this in the bullet item, or split the item in two. *minimal conformance requirements* > Note that both peers can have their own policies about what addresses > are acceptable to use. A minimal "mobile client" could have a policy > that says that only the responder's address specified in local > configuration is acceptable. This kind of client does not have to > send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a > simple "VPN gateway" that has only a single address, and is not going > to change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > > I think we discussed this previously (and I have not yet checked what the result of that discussion was). However, the above client text sounds a bit too flexible in my opinion. *RR requirements according to earlier decisions* > Both parties can optionally verify that the other party can actually > receive packets at the claimed address. This "return routability > check" can be done before updating the IPsec SAs, immediately after > updating them, or continuously during the connection. > > 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 think we decided earlier that the RR checks are by default on, and that they are by default done before updating the SAs. The above text seems to omit the former default. Suggested fix: Both parties can optionally verify that the other party can actually receive packets at the claimed address. By default, this "return routability check" SHOULD be performed. 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. The check can be done before updating the IPsec SAs, immediately after updating them, or continuously during the connection. By default, the return routability check SHOULD be done before updating the IPsec SAs, but in some environments it MAY be postponed until after the IPsec SAs have been updated. *meta issue about specification completeness* Pasi, as you have edited ikev2-clarifications, what kind of issues have you seen that have caused so many clarifications needed? If you have a list of these issue types, can we go over our spec to ensure that we don't introduce the same unclarities? I'm asking because the specification style is close to what we had in IKEv2. Do we need add tables of what attributes are possible in what messages, state machines, or spend more effort in detailed processing algorithms? (But I did not see anything on my review that would be obviously prone for interpretation.) Editorial: >In the current > specifications, the IPsec and IKE SAs are created implicitly between > the IP addresses that are used when the IKE_SA is established. > s/current specifications/base IKEv2 protocol/ > user interaction for authentication (entering a code from a token > card, for instance). > .... authentication, such as entering ... >3.1. Basic Operation > 2nd para: it would be useful to state early that ike exchange initiator decides the addresses to use for that exchange. Right now you only talk about IPsec addresses. I know this is part of ikev2, but the reader may not have the background to understand this. >3.2. Example Protocol Runs > 2nd example, Step 3 needs to show that the response is lost. The 2nd example should also explain better why COOKIE2 is needed in Step 4. >3.4. Limitations > > Probably worthwhile to explain this earlier, maybe as Section 1.1. >4.8. NAT Prohibition > This section would benefit from a message flow example. > The attackers in this threat can be either outsiders or even one of > the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers > can be easily dealt with if the authentication performed in the > initial IKEv2 negotiation can be traced to persons who can be held > responsible for the attack. This may not be the case in all > scenarios, particularly with opportunistic approaches to security. > > s/persons/persons or devices/? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 19 15:05:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJFl-0007rB-Fd for mobike-archive@megatron.ietf.org; Wed, 19 Oct 2005 15:05:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07132 for ; Wed, 19 Oct 2005 15:05:22 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 65DD1FB28F; Wed, 19 Oct 2005 19:05:29 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 78D58FB284; Wed, 19 Oct 2005 19:05:25 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 55F10FB285; Wed, 19 Oct 2005 19:05:24 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id AA76EFB283 for ; Wed, 19 Oct 2005 19:05:23 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4320289854; Wed, 19 Oct 2005 22:05:18 +0300 (EEST) Message-ID: <435698FB.3010906@piuha.net> Date: Wed, 19 Oct 2005 22:05:31 +0300 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: <17229.4610.296836.928434@fireball.kivinen.iki.fi> In-Reply-To: <17229.4610.296836.928434@fireball.kivinen.iki.fi> Cc: mobike@machshav.com Subject: [Mobike] Issue 61 (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, >Perhaps the section 5.1 should say "There is no data associated with >this Notify type, and the when processing Notify received from the >other end the notify data MUST be ignored." Then we can later add some >data there and old version will ignore it. That will allow us >possibility to extend this payload later. With the current text >implementations can simply fail the whole IKE SA negotiation if there >is data in the this notify. (or if you consider this to be too close >to the already covered no-version-numbers case, then feel free to >ignore this comment). > > I don't want to re-open the old issue. But this approach to specifying processing of payloads is in general what I want to see in any payload, its simply makes sense from an extensibility point of view. So I'd like to see Tero's proposal adopted. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 19 15:11:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESJLe-0000uY-Jo for mobike-archive@megatron.ietf.org; Wed, 19 Oct 2005 15:11:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07476 for ; Wed, 19 Oct 2005 15:11:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1E298FB291; Wed, 19 Oct 2005 19:11:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A94E8FB285; Wed, 19 Oct 2005 19:11:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F3336FB286; Wed, 19 Oct 2005 19:11:33 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 6F4D9FB262 for ; Wed, 19 Oct 2005 19:11:32 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C331389854 for ; Wed, 19 Oct 2005 22:11:31 +0300 (EEST) Message-ID: <43569A71.10602@piuha.net> Date: Wed, 19 Oct 2005 22:11:45 +0300 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] issues 58 - deleting addresses 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 The consensus seems to be that the text in question needs to be clarified to say that the new list overwrites the old. (Note: I think we decided a long time ago that we're not doing incremental updates but rather entire new lists. We're not reopening that discussion. However, our reviewers indicate that the text isn't clear.) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 19 17:40:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESLfz-0006US-5S for mobike-archive@megatron.ietf.org; Wed, 19 Oct 2005 17:40:47 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05862 for ; Wed, 19 Oct 2005 17:40:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E8BBAFB28D; Wed, 19 Oct 2005 21:40:44 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8F885FB284; Wed, 19 Oct 2005 21:40:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C78B0FB285; Wed, 19 Oct 2005 21:40:39 +0000 (UTC) Received: from web80605.mail.yahoo.com (web80605.mail.yahoo.com [66.218.79.94]) by machshav.com (Postfix) with SMTP id C8658FB283 for ; Wed, 19 Oct 2005 21:40:38 +0000 (UTC) Received: (qmail 25834 invoked by uid 60001); 19 Oct 2005 21:12:38 -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=ph2NhggqtFcjnNngWDIbFn3qWPL54pcmtlVEoPy1HKkQxW9/13pbBmsTpjnJtD+SwqoDtHKjQE/JlHjc4wQ+N8mNOx/wtlnNrivPZIi0Qg0hZ4P/iYsXNy0dFhFB/7Ss7+DIXQkcuJH5wQcRYGqmzS2dwU7l65qNmaiZ+t31aKA= ; Message-ID: <20051019211238.25832.qmail@web80605.mail.yahoo.com> Received: from [206.132.194.3] by web80605.mail.yahoo.com via HTTP; Wed, 19 Oct 2005 14:12:38 PDT Date: Wed, 19 Oct 2005 14:12:38 -0700 (PDT) From: Mohan Parthasarathy To: Pasi.Eronen@nokia.com, kivinen@iki.fi In-Reply-To: MIME-Version: 1.0 Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 51: SPI collision 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 don't think it would hurt to point this out. For folks that are using Linux, they can know immediately that MOBIKE does not work and it might get fixed soon :-) -mohan --- Pasi.Eronen@nokia.com wrote: > Tero Kivinen wrote: > > When you are sending packets outbound you do > lookup from SPD-S > > based on the selectors (I1 or I2) and you get SA > based on > > that. Then in the SA there is the SPI and > destination IP to be > > used for the other end. Then you simply make > tunnel > > encapsulation and send the packet along. I do not > really see > > what is the problem there? > > > > > The 4.4.2 of the RFC2401bis says: > > ... > > For outbound processing, each SAD entry is > pointed to by > > entries in the SPD-S part of the SPD cache. > > It seems the issue is about how exactly this > "pointing" is > implemented. I think Tuomas was saying that storing > the (remote > tunnel header IP, remote SPI) pair is not a right > way to implement > this pointing, since it does not always uniquely > identify an > outbound SA. > > And as you pointed out, this is not new to MOBIKE: > it obviously > happens with NAT Traversal, but can happen without > NAT-T too (one > peer goes away without deleting the SAs; another > peer comes in, > gets the same address, and creates new SAs with > that). > > I'm not sure what, if anything, the spec should say > about this. > 2401bis itself is quite clear that it's describing a > nominal > model, and is not intended to match any real > implementations. > Clearly there are several ways to implement the > pointer, depending > on e.g. how exactly the required information is > stored (there's no > requirement that an implementation has two different > data > structures, one called SAD and another called SPD), > and what > programming language is used. But the details of C > pointers, > Java references, Prolog clauses, or LISP expressions > are really > beyond the scope of 2401bis (and MOBIKE). > > So, my gut feeling would be that if something needs > to be said > about this, the best place would be 2401bis, since > the issue > is not specific to MOBIKE. Also, it's an > implementation detail, > so there's no need to specify one single way to do > it. > > However... I think some IPsec implementations have > actually got > this wrong. Mohan mentioned Linux, and based on a > quick look, > yes, it seems the 2.6 kernel IPsec uses (remote > tunnel header IP, > remote SPI, protocol) as the outbound SA lookup key. > So maybe > it would be worthwhile to mention this, perhaps in a > non-normative > "implementation considerations" appendix? > > 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 Thu Oct 20 03:53:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVEk-0006T8-ON for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 03:53:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22622 for ; Thu, 20 Oct 2005 03:53:08 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 523F6FB289; Thu, 20 Oct 2005 07:53:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0EA3DFB283; Thu, 20 Oct 2005 07:53:11 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A8096FB284; Thu, 20 Oct 2005 07:53:07 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id B8715FB27D for ; Thu, 20 Oct 2005 07:53:06 +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 j9K7nfAR001877 for ; Thu, 20 Oct 2005 10:49:42 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 10:52:59 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 10:52:59 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Oct 2005 10:52:59 +0300 Message-ID: Thread-Topic: [Mobike] Issue 61 (was: Comments ofdraft-ietf-mobike-protocol-04.txt) Thread-Index: AcXU4CfmnwTotMn3QZq/PjRLpsSnswAabY4A From: To: X-OriginalArrivalTime: 20 Oct 2005 07:52:59.0596 (UTC) FILETIME=[4A5030C0:01C5D54B] Subject: Re: [Mobike] Issue 61 (was: Comments ofdraft-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 Jari Arkko wrote: > Tero, > > >Perhaps the section 5.1 should say "There is no data associated > >with this Notify type, and the when processing Notify received from > >the other end the notify data MUST be ignored." Then we can later > >add some data there and old version will ignore it. That will allow > >us possibility to extend this payload later. With the current text > >implementations can simply fail the whole IKE SA negotiation if > >there is data in the this notify. (or if you consider this to be > >too close to the already covered no-version-numbers case, then feel > >free to ignore this comment). > > I don't want to re-open the old issue. But this approach to > specifying processing of payloads is in general what I want to see > in any payload, its simply makes sense from an extensibility point > of view. > > So I'd like to see Tero's proposal adopted. Exactly this was proposed also earlier, during the discussion on issue 35. But this is so small change that maybe we could do it. How about replacing this text in Section 5.1 The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The Protocol ID and SPI Size fields are set to zero. There is no data associated with this Notify type. with this? The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The Protocol ID and SPI Size fields are set to zero. The notification data field MUST be left empty (zero-length) when sending, and its contents (if any) MUST be ignored when this notification is received. This allows the field to be used by future versions of this protocol. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 03:55:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVHJ-0007b1-85 for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 03:55:58 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22901 for ; Thu, 20 Oct 2005 03:55:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 158AFFB28E; Thu, 20 Oct 2005 07:55:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6467FFB283; Thu, 20 Oct 2005 07:55:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9AFFFFB284; Thu, 20 Oct 2005 07:55:48 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 6B330FB27D for ; Thu, 20 Oct 2005 07:55:47 +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 j9K7tdT2014781; Thu, 20 Oct 2005 10:55:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 10:55:42 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 10:55:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Oct 2005 10:55:42 +0300 Message-ID: Thread-Topic: [Mobike] Issue 60: Addresses in IKE_SA_INIT/AUTH (was: Comments of draft-ietf-mobike-protocol-04.txt) Thread-Index: AcXPMnpw+W6Yt54zSnOcaHo7Vo14NQGGQYCw From: To: , X-OriginalArrivalTime: 20 Oct 2005 07:55:42.0391 (UTC) FILETIME=[AB58BC70:01C5D54B] 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: > 2) > > In section 4.2 we should always take the IP-addresses from the > IKE_AUTH request, as there might be multiple IKE_SA_INIT request, > and some of those might not create state at all (cookie, > invalid_ke_payload). I think it would be simplier to say that the > IP-addresses are always taken from the IP header of the IKE_AUTH > packet having SA payload (regardless of the NAT-T or no NAT-T). > > In normal IKEv2 this does not matter, as if no NAT-T is used then > the IP address must stay same, and if NAT-T is used then we take the > last packet seen and use the IP-addresses from there. In Mobike we > do need to define the exact time what IP-address is used, and I > think the packet having the ADDITIONAL_*_ADDRESSES would be the most > logical choise (i.e. the IKE_AUTH packet having the SA payload). There's a reason why I wrote it that way: when not doing NAT-T, the address should be taken from the same packet which contains NO_NATS_ALLOWED. And it seems that putting NO_NATS_ALLOWED in IKE_SA_INIT is simpler than IKE_AUTH; see below on this... > The section 4.8 says that NO_NATS_ALLOWED should be put to the > IKE_SA_INIT (among other things), but we do want to keep IKE_SA_INIT > as small as possible, so I think IKE_AUTH is much better place for > that notify. That would also be in sync with my proposed change to > the 4.2 where I proposed to say that use the IKE_AUTH packet having > SA payload to get the IP address tobe used. NO_NATS_ALLOWED is not > needed in the IKE_SA_INIT like NAT_DETECTION_*_IP notifies are, as > they do not cause changing of the port numbers for the IKE_AUTH. NO_NATS_ALLOWED takes less space than NAT_DETECTION_*_IP payloads, so IMHO it's not unreasonable to put it in IKE_SA_INIT. The real reason to put NO_NATS_ALLOWED in IKE_SA_INIT is that it's much simpler to retry the request if we get UNEXPECTED_NAT_DETECTED error back. In particular, this text from Section 4.8 would need major revision if we take the address from IKE_AUTH: More specifically, when NAT Traversal is not enabled, all messages that can update the addresses associated with the IKE_SA and/or IPsec SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS notifications) MUST also include a NO_NATS_ALLOWED notification. The exchange responder MUST verify that the contents of the NO_NATS_ALLOWED notification match the addresses in the IP header. If they do not match, a response containing an UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the IKE_SA_INIT exchange, no state is created at the responder). The response message is sent to the address and port that the corresponding request came from, not to the address contained in the NO_NATS_ALLOWED notification. If the exchange initiator receives an UNEXPECTED_NAT_DETECTION notification in response to its request, it SHOULD retry the operation several times using new IKE_SA_INIT/INFORMATIONAL requests. This ensures that an attacker who is able to modify only a single packet does not unnecessarily cause a path to remain unused. > Also moving that NOFITY to the encrypted IKE_AUTH packet will > prevent passive attackers of getting the information about the IP > addresses and ports used in case host behind NAT is configured to > try first with NO_NATS_ALLOWED before falling back and enabling > NAT-T. It will also make the attacker acting as a NAT between two > hosts bit harder, as if it is sent inside the IKE_SA_INIT, attacker > can simply flip a bit inside the NO_NATS_ALLOWED payload to cause > DoS, otherwise he need to flip bit in the IP-address or ports, which > requires it to catch the return packet and forward it to the > original requestor to cause attack. It is not much, but offers again > a bit more protection against attacks. A host that is worried about an attack as obscure as this is IMHO unlikely to have a policy "first try without NAT-T; but if there's a NAT, enable NAT-T". Furthermore, moving the payload doesn't actually prevent anything. If there's no NAT, the addresses are visible in the IP header. If there is a NAT, and the host behind NAT falls back to NAT-T, the eavesdropper can get the addresses anyway with a quite trivial amount of computation (as is already pointed out in the IKEv2 spec, hashing does not prevent NAT detection payloads from leaking the internal addresses). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 03:59:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVKn-0001pX-0u for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 03:59:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23126 for ; Thu, 20 Oct 2005 03:59:21 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 831BFFB289; Thu, 20 Oct 2005 07:59:30 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D365BFB283; Thu, 20 Oct 2005 07:59:28 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CD587FB284; Thu, 20 Oct 2005 07:59:26 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id B5119FB27D for ; Thu, 20 Oct 2005 07:59:25 +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 j9K7xJMF022416 for ; Thu, 20 Oct 2005 10:59:24 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 10:59:24 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 10:59:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Oct 2005 10:59:25 +0300 Message-ID: Thread-Topic: Issue list status Thread-Index: AcXVTDARQBn89fuaTSWdfpSfu7gKcQ== From: To: X-OriginalArrivalTime: 20 Oct 2005 07:59:24.0461 (UTC) FILETIME=[2FB5EDD0:01C5D54C] Subject: [Mobike] Issue list 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 I've gone through the comments posted on the mailing list so far, and filed them as 21 separate issues in the issue list: http://www.vpnc.org/ietf-mobike/issues.html (It also seems that my instructions on how the comments should be sent were quite poorly written, since almost everyone understood them exactly the opposite way I had intended... :-) Most of the issues seem to be mainly editorial, suggesting that the existing text should be clarified in some places. This hopefully means the protocol itself is in a good shape. We also received several reviews from outside the WG, another good thing. Some reviewers also sent general observations (suggesting neither editorial nor technical changes) or questions asking how the protocol works or why it was designed this way. I have stored these comments in the issue list along with the others. However, we should try to identify these kind of comments and marked the as "closed" soon -- at this phase, the issue list should IMHO contain only things that may need to be changed in the document before sending it to IETF last call. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 04:30:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESVp7-0007Rb-3o for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 04:30:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24409 for ; Thu, 20 Oct 2005 04:30:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C419AFB289; Thu, 20 Oct 2005 08:30:51 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 37E3FFB283; Thu, 20 Oct 2005 08:30:47 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E2D91FB284; Thu, 20 Oct 2005 08:30:45 +0000 (UTC) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id BE051FB283 for ; Thu, 20 Oct 2005 08:30:43 +0000 (UTC) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9K8UgEV028529 for ; Thu, 20 Oct 2005 11:30:42 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 11:30:42 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 11:30:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Oct 2005 11:30:19 +0300 Message-ID: Thread-Topic: [Mobike] Issue 59: Editorial comments from Tero (was: Comments of draft-ietf-mobike-protocol-04.txt) Thread-Index: AcXPMnpw+W6Yt54zSnOcaHo7Vo14NQGHWfsg From: To: X-OriginalArrivalTime: 20 Oct 2005 08:30:42.0538 (UTC) FILETIME=[8F21BCA0:01C5D550] Subject: Re: [Mobike] Issue 59: Editorial comments from Tero (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: > 1) > > In section 3.2. the second example should probably clarify that > the exchange in step 3 is successful, i.e. the responder do > respond to that in this example protocol run (as can be seen from > the return packet sent by the responder, but the text below it > gives feeling that it failed ("initiator gives up")). > > Perhaps there should also be example where that exchange is not > successful. Hmm... the example was written by Jari, but I suspect the intention was that step 3 is not successful (the initiator doesn't receive a reply -- but then step 4 is wrong, as the initiator has to continue retransmitting the first request). Jari, could you clarify? > 4) > > The last sentence in the section 4.5 should say > > Similarly, a simple "VPN gateway" that has only a single > address, and is not going to change it, does not need to send > or process ADDITIONAL_*_ADDRESS notifications. > > It needs to understand them so much it can ignore them. Yes, but that's already required by IKEv2 ("Notify payloads with status types ... MUST be ignored if not recognized."). > 5) > > In section 4.6 the paragraph: > > Any INFORMATIONAL exchange can be used for return routability > purposes, with one exception: when a valid response is > received, we know the other party can receive packets at the > claimed address. > > should probably tell what is the one exception... Or more exactly > what that paragraph is trying to tell us? OK, I'll try to clarify that the exception here refers to the last paragraph of 4.6. > 6) > > Perhaps the section 4.7 should also mention that DPD packets can > also include UPDATE_SA_ADDRESSES in case the initiator suspects > that the NAT mapping has changed, and that will save one round > trip. Hmm, yes, I had intended to include that already in -03, but somehow that was forgotten. How about adding this to the 3rd paragraph? If the initiator suspects that the NAT mapping has changed, it MAY also skip the detection step and send UPDATE_SA_ADDRESSES immediately. This saves one roundtrip if the NAT mapping has indeed changed. > 9) > > I agree with the previous proposal that we should split those > notifies to error and status notifies, and have separate section > for each of those. I'm wondering why? To me it seems the only reader of this spec who needs to know about the error/status distinction is IANA (and that's already covered in the IANA considerations section)... (But if there's a good reason to do it, maybe we could re-arrange the subsections in Section 5 to, say, list those notifications whose number comes from the status type range first.) > 10) > > The section 5.7 of the NO_NATS_ALLOWED could have a bit more > text explaining the exact data put in, i.e. something like > > Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | > dst-ip (4 or 16 bytes) | dst-port (2 bytes) > > All data is stored in the network byte order without any > padding. The lenght of the data is 12 bytes for IPv4, and 36 > bytes for the IPv6. Ok, will be clarified with something along those lines. > 11) > > The section 6.1 should probably also mention that NO_NATS_ALLOWED > might be used with IPv6 in general, where NATs are not (yet) used. I think IPv6 implementations will often need to support NAT traversal anyway, because UDP is more likely to get through stateful firewalls than plain ESP... But yes, perhaps IPv6 could be mentioned there anyway. How about rephrasing that to "This feature is mainly intendeed for IPv6 and site-to-site VPN cases, where..."? > 12) > > The section 6.5 should mention that those information is > generally available only for the other peer, not to the passive > listeners (it is encrypted). There is two (or one if we move the > NO_NATS_ALLOWED) exceptions to the rule: NAT_DETECTION_*_IP > packets of the IKE_SA_INIT and the NO_NATS_ALLOWED (if sent > inside the IKE_SA_INIT). Those payloads having IP-address > information is sent in clear. How about adding this to the end of the 5th paragraph of 6.5: Furthermore, the ADDITIONAL_IP4/6_ADDRESS notifications are sent encrypted, so the addresses are not visible to eavesdroppers (unless, of course, they are later used for sending IKEv2/IPsec traffic). NO_NATS_ALLOWED is a bit different: since it's used only when we know beforehand that there are no NATs, so it contains the same address as the IP header -- so encrypting it does not provide anything extra... Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 05:00:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESWIE-00031m-8H for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 05:00:58 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25967 for ; Thu, 20 Oct 2005 05:00:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6A5C5FB28B; Thu, 20 Oct 2005 09:00:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3D2E7FB283; Thu, 20 Oct 2005 09:00:49 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A2A28FB284; Thu, 20 Oct 2005 09:00:47 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 97085FB27D for ; Thu, 20 Oct 2005 09:00:46 +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 j9K90dht015918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 12:00:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9K90d5V012884; Thu, 20 Oct 2005 12:00:39 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.23735.97798.48217@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 12:00:39 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 13 min Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 61 (was: Comments ofdraft-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 Pasi.Eronen@nokia.com writes: > The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The > Protocol ID and SPI Size fields are set to zero. The notification > data field MUST be left empty (zero-length) when sending, and its > contents (if any) MUST be ignored when this notification is > received. This allows the field to be used by future versions of > this protocol. Perfect for me. Actually I would like that to be the default case for most of the notify payloads, if we could change the IKEv2 draft I think we should put that to the generic notify payload processing, but for that I am too late... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 06:24:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXao-0003ej-DO for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:24:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29927 for ; Thu, 20 Oct 2005 06:24:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A3490FB262; Thu, 20 Oct 2005 10:24:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EF0D8FB283; Thu, 20 Oct 2005 10:24:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C8824FB284; Thu, 20 Oct 2005 10:24:03 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 78412FB27D for ; Thu, 20 Oct 2005 10:24: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 j9KANxxq013197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 13:23:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KANwve025156; Thu, 20 Oct 2005 13:23:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.28734.827449.444182@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 13:23:58 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 39 min X-Total-Time: 80 min 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 Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > > 2) > > > > In section 4.2 we should always take the IP-addresses from the > > IKE_AUTH request, as there might be multiple IKE_SA_INIT request, > > and some of those might not create state at all (cookie, > > invalid_ke_payload). I think it would be simplier to say that the > > IP-addresses are always taken from the IP header of the IKE_AUTH > > packet having SA payload (regardless of the NAT-T or no NAT-T). > > > > In normal IKEv2 this does not matter, as if no NAT-T is used then > > the IP address must stay same, and if NAT-T is used then we take the > > last packet seen and use the IP-addresses from there. In Mobike we > > do need to define the exact time what IP-address is used, and I > > think the packet having the ADDITIONAL_*_ADDRESSES would be the most > > logical choise (i.e. the IKE_AUTH packet having the SA payload). > > There's a reason why I wrote it that way: when not doing NAT-T, > the address should be taken from the same packet which contains > NO_NATS_ALLOWED. And it seems that putting NO_NATS_ALLOWED in > IKE_SA_INIT is simpler than IKE_AUTH; see below on this... That reason is not explained anywhere, thus it is very hard to understand why it is done that way (i.e. why do we have more complicated processing here). > > > The section 4.8 says that NO_NATS_ALLOWED should be put to the > > IKE_SA_INIT (among other things), but we do want to keep IKE_SA_INIT > > as small as possible, so I think IKE_AUTH is much better place for > > that notify. That would also be in sync with my proposed change to > > the 4.2 where I proposed to say that use the IKE_AUTH packet having > > SA payload to get the IP address tobe used. NO_NATS_ALLOWED is not > > needed in the IKE_SA_INIT like NAT_DETECTION_*_IP notifies are, as > > they do not cause changing of the port numbers for the IKE_AUTH. > > NO_NATS_ALLOWED takes less space than NAT_DETECTION_*_IP payloads, > so IMHO it's not unreasonable to put it in IKE_SA_INIT. True, not unreasonable, but I still unnecessary to put them there. > The real reason to put NO_NATS_ALLOWED in IKE_SA_INIT is that it's > much simpler to retry the request if we get UNEXPECTED_NAT_DETECTED > error back. In particular, this text from Section 4.8 would need major > revision if we take the address from IKE_AUTH: I do not think there is any difference in the complexity of the retry even if the NO_NATS_ALLOWED is in the IKE_AUTH, you simply delete half created IKE SA and start over (from the IKE_SA_INIT) when you get error in both cases. There will be performance penalty, as we need to do Diffie-Hellman again, but on the other hand we do not need to add another test matrix case to test the checking that we take the IP addresses in IKE_AUTH for NAT-T and from IKE_SA_INIT for non-NAT-T case. The question simply is whether this is felt like being important enough to have performance optimizations when trying to revert this attack, and costing more in the code complexity and testing time. Note, that the whole idea of retrying is something that does not really make attack that much harder especially in the initial contact step. If someone can modify one packet he can usually modify all the packets. Also moving them to IKE_AUTH does make the attack a bit harder, as now the attacker must be able to get the return packets and forward them to the real destination. If we know there was no NAT between us in the first place, then it is quite safe to assume that such thing does not appear on the path suddenly, thus retrying is ok for the existing IKE SA (i.e. for the INFORMATIONAL exchanges). If the initial contact seems to have NAT between, then it is must likely going to be real NAT, thus retrying by protocol is not really useful. We could simply say that the IKE SA initiation fails in that case, and then when the next trigger packets comes in (or user retries by pressing "connect" again) we retry the exchange from the beginning again. > If the exchange initiator receives an UNEXPECTED_NAT_DETECTION > notification in response to its request, it SHOULD retry the > operation several times using new IKE_SA_INIT/INFORMATIONAL requests. > This ensures that an attacker who is able to modify only a single > packet does not unnecessarily cause a path to remain unused. The change needed would be something like: If the exchange initiator receives an UNEXPECTED_NAT_DETECTION notification in response to its INFORMATIONAL request, it SHOULD retry the operation several times using new INFORMATIONAL requests. This ensures that an attacker who is able to modify only a single packet does not unnecessarily cause a path to remain unused. If initiator receives UNEXPECTED_NAT_DETECTION during IKE SA creation (i.e. in IKE_AUTH state), then it should abort the IKE SA creation, and retry it later when it gets next trigger for that connection. >From the code point of view, that retry does not need any new code, simply fail the IKE SA and other parts of the code will already take care of the retry. 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? Only benefit they will give is to inform the initiator that there was attacker between him and the responder. There is really nothing initiator can do for that, except retry. If his policy does not allow NATs between, then he will not enable NAT-T even when there would be NAT between, thus he will be just out of connectivity. > > Also moving that NOFITY to the encrypted IKE_AUTH packet will > > prevent passive attackers of getting the information about the IP > > addresses and ports used in case host behind NAT is configured to > > try first with NO_NATS_ALLOWED before falling back and enabling > > NAT-T. It will also make the attacker acting as a NAT between two > > hosts bit harder, as if it is sent inside the IKE_SA_INIT, attacker > > can simply flip a bit inside the NO_NATS_ALLOWED payload to cause > > DoS, otherwise he need to flip bit in the IP-address or ports, which > > requires it to catch the return packet and forward it to the > > original requestor to cause attack. It is not much, but offers again > > a bit more protection against attacks. > > A host that is worried about an attack as obscure as this is IMHO > unlikely to have a policy "first try without NAT-T; but if there's > a NAT, enable NAT-T". I agree that the revealing of the IP addresses is not very serious case, but there are people who consider that unacceptable (that is why the NAT-T uses hashes, as people did consider leaking the IP-addresses a problem). If we leak them again here, there needs to be at least security considerations section explaining the issue, and also explain why we require them to be sent in clear when they could also be sent as encrypted (i.e. hidden from passive attackers). > Furthermore, moving the payload doesn't actually prevent anything. > If there's no NAT, the addresses are visible in the IP header. > If there is a NAT, and the host behind NAT falls back to NAT-T, > the eavesdropper can get the addresses anyway with a quite trivial > amount of computation (as is already pointed out in the IKEv2 spec, > hashing does not prevent NAT detection payloads from leaking the > internal addresses). True, that is mentioned in the IKEv2 spec, and its implications are explained there. We are now adding another case, so we need to explain it in the security considerations section. There is nothing about NO_NATS_ALLOWED in the security considerations now. Hmm... I got completely new idea, dont know if it is good or bad, but how about adding the flag in the IKE generic header flags field to tell that include IP-addresses and ports to the MAC. Then we wouldn't need to send those IP-addresses/ports at all, and the responder would simply ignore all packets having wrong MAC (i.e. modified IP-addresses or ports). Either end could put that bit in case they want to make sure the IP-addresses are protected (i.e when they would send NO_NATS_ALLOWED). Hmm.. the problem with that is that it is not backward compatible, i.e. if the other end does not support MOBIKE, then he do not know about flag, thus will not be able to calculate the MAC correctly. So ignore that suggestion (this would probably have been the way to do it if we would still be modifying IKEv2 draft). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 06:26:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXdD-0004JX-Ms for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:26:43 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00013 for ; Thu, 20 Oct 2005 06:26:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6ED3DFB28B; Thu, 20 Oct 2005 10:26:39 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CC9C7FB283; Thu, 20 Oct 2005 10:26:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8EB50FB284; Thu, 20 Oct 2005 10:26:34 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 5C574FB246 for ; Thu, 20 Oct 2005 10:26: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 j9KAQWrw020860 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 13:26:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KAQWLY001221; Thu, 20 Oct 2005 13:26:32 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.28888.375177.994353@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 13:26:32 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: mobike@machshav.com Subject: [Mobike] Issue list 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 Pasi.Eronen@nokia.com writes: > (It also seems that my instructions on how the comments should be > sent were quite poorly written, since almost everyone understood > them exactly the opposite way I had intended... :-) I did try to separate each comment to separate section, but didn't want to start sending dozen of separate emails to the list. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 06:29:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXfl-0006AZ-BY for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:29:21 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00203 for ; Thu, 20 Oct 2005 06:29:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6DF38FB28D; Thu, 20 Oct 2005 10:29:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E1277FB283; Thu, 20 Oct 2005 10:29:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EAAC4FB284; Thu, 20 Oct 2005 10:29:13 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 25246FB246 for ; Thu, 20 Oct 2005 10:29:12 +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 j9KATB2o003891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 13:29:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KATBVj014938; Thu, 20 Oct 2005 13:29:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.29047.32052.905562@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 13:29:11 +0300 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: Editorial comments from Tero (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 Pasi.Eronen@nokia.com writes: > > 5) > > > > In section 4.6 the paragraph: > > > > Any INFORMATIONAL exchange can be used for return routability > > purposes, with one exception: when a valid response is > > received, we know the other party can receive packets at the > > claimed address. > > > > should probably tell what is the one exception... Or more exactly > > what that paragraph is trying to tell us? > > OK, I'll try to clarify that the exception here refers to > the last paragraph of 4.6. Ok, now I know what the exception is... I didn't know what the exception was before, that was why I asked it there... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 06:31:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXho-0006cV-U3 for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:31:28 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00382 for ; Thu, 20 Oct 2005 06:31:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D87BAFB292; Thu, 20 Oct 2005 10:31:25 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2D182FB283; Thu, 20 Oct 2005 10:31:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C0D72FB284; Thu, 20 Oct 2005 10:31:20 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id B0496FB246 for ; Thu, 20 Oct 2005 10:31:19 +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 j9KAVICZ004889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 13:31:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KAVIZT015925; Thu, 20 Oct 2005 13:31:18 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.29174.690945.386416@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 13:31:18 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 1 min Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59: Editorial comments from Tero (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 [trying to now answer via separate emails] Pasi.Eronen@nokia.com writes: > > 4) > > > > The last sentence in the section 4.5 should say > > > > Similarly, a simple "VPN gateway" that has only a single > > address, and is not going to change it, does not need to send > > or process ADDITIONAL_*_ADDRESS notifications. > > > > It needs to understand them so much it can ignore them. > > Yes, but that's already required by IKEv2 ("Notify payloads > with status types ... MUST be ignored if not recognized."). Yes, but as we are working over IKEv2, we can also change some of the requirements, just wanted to make sure that we are not going to lower that restriction specified in the IKEv2 document here. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 06:32:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXiO-0006lz-Mo for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:32:04 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00456 for ; Thu, 20 Oct 2005 06:31:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 752B4FB28D; Thu, 20 Oct 2005 10:32:02 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 39B02FB283; Thu, 20 Oct 2005 10:31:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 80095FB284; Thu, 20 Oct 2005 10:31:57 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 7240AFB246 for ; Thu, 20 Oct 2005 10:31: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 j9KAVtQr017603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 13:31:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KAVtwP028414; Thu, 20 Oct 2005 13:31:55 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.29211.273711.381983@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 13:31:55 +0300 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 59: Editorial comments from Tero (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 Pasi.Eronen@nokia.com writes: > > 6) > > > > Perhaps the section 4.7 should also mention that DPD packets can > > also include UPDATE_SA_ADDRESSES in case the initiator suspects > > that the NAT mapping has changed, and that will save one round > > trip. > > Hmm, yes, I had intended to include that already in -03, but > somehow that was forgotten. How about adding this to the 3rd > paragraph? > > If the initiator suspects that the NAT mapping has changed, > it MAY also skip the detection step and send UPDATE_SA_ADDRESSES > immediately. This saves one roundtrip if the NAT mapping > has indeed changed. Sounds good. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 06:35:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXlf-00082y-Lk for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:35:27 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00841 for ; Thu, 20 Oct 2005 06:35:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C5831FB28D; Thu, 20 Oct 2005 10:35:25 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 013D2FB283; Thu, 20 Oct 2005 10:35:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D5016FB284; Thu, 20 Oct 2005 10:35:19 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 3E7C3FB246 for ; Thu, 20 Oct 2005 10:35:18 +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 j9KAZHQa008345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 13:35:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KAZH95007699; Thu, 20 Oct 2005 13:35:17 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.29413.56406.527580@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 13:35:17 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59: Editorial comments from Tero (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 Pasi.Eronen@nokia.com writes: > > 9) > > > > I agree with the previous proposal that we should split those > > notifies to error and status notifies, and have separate section > > for each of those. > > I'm wondering why? To me it seems the only reader of this spec who > needs to know about the error/status distinction is IANA (and that's > already covered in the IANA considerations section)... > > (But if there's a good reason to do it, maybe we could re-arrange > the subsections in Section 5 to, say, list those notifications > whose number comes from the status type range first.) Because as you said in the earlier, unknown status notifications are ignored, and unknown error notifications cause request to fail entirely. So there is difference for them in the processing point of view too. Thats why it might be good idea to also keep them separate in the documentation too. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 06:36:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXmW-0000MW-Or for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:36:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00936 for ; Thu, 20 Oct 2005 06:36:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9C4BBFB28B; Thu, 20 Oct 2005 10:36:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EC2D9FB283; Thu, 20 Oct 2005 10:36:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 70CD3FB284; Thu, 20 Oct 2005 10:36:13 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 5E515FB23E for ; Thu, 20 Oct 2005 10:36:12 +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 j9KAaBch012496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 13:36:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KAaBOI016925; Thu, 20 Oct 2005 13:36:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.29467.419983.143026@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 13:36:11 +0300 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: Editorial comments from Tero (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 Pasi.Eronen@nokia.com writes: > > 11) > > > > The section 6.1 should probably also mention that NO_NATS_ALLOWED > > might be used with IPv6 in general, where NATs are not (yet) used. > > I think IPv6 implementations will often need to support NAT > traversal anyway, because UDP is more likely to get through > stateful firewalls than plain ESP... > > But yes, perhaps IPv6 could be mentioned there anyway. How > about rephrasing that to "This feature is mainly intendeed for > IPv6 and site-to-site VPN cases, where..."? That would be enough 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 Thu Oct 20 06:40:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESXqH-00026c-91 for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 06:40:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01120 for ; Thu, 20 Oct 2005 06:40:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E0226FB28F; Thu, 20 Oct 2005 10:40:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D35D1FB286; Thu, 20 Oct 2005 10:40:07 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7E231FB289; Thu, 20 Oct 2005 10:40:06 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 72415FB284 for ; Thu, 20 Oct 2005 10:40:05 +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 j9KAe4qL020291 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 13:40:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KAe4Ac011505; Thu, 20 Oct 2005 13:40:04 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.29700.310731.159189@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 13:40:04 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59: Editorial comments from Tero (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 Pasi.Eronen@nokia.com writes: > NO_NATS_ALLOWED is a bit different: since it's used only when we > know beforehand that there are no NATs, so it contains the same > address as the IP header -- so encrypting it does not provide > anything extra... I disagree with that. How can we know there is no NAT between beforehand? We have not tested the path or anything, so we do not know if there is NAT or not. We can hope there is no NAT, as if there is one, then we cannot establish connection, but we cannot know anything about presense of NATs. Even if our configurations says there must not be NATs between us, it does not mean that this is necessarely true, and it does not mean that we can reveal the IP-addresses to the listeners. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 07:12:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESYLt-0007kU-DW for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 07:12:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02686 for ; Thu, 20 Oct 2005 07:12:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 07748FB28E; Thu, 20 Oct 2005 11:12:50 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3C31BFB286; Thu, 20 Oct 2005 11:12:48 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B40EEFB289; Thu, 20 Oct 2005 11:12:46 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id D463AFB283 for ; Thu, 20 Oct 2005 11:12:45 +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 j9KB96pN009381; Thu, 20 Oct 2005 14:09:21 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 14:12:44 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Oct 2005 14:12:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 20 Oct 2005 14:12:43 +0300 Message-ID: Thread-Topic: [Mobike] Issue 59: Editorial comments from Tero (was: Commentsof draft-ietf-mobike-protocol-04.txt) Thread-Index: AcXVYrJfmwt7jt2jQfmILRfBvmVXagAA/fjw From: To: X-OriginalArrivalTime: 20 Oct 2005 11:12:44.0007 (UTC) FILETIME=[31942F70:01C5D567] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59: Editorial comments from Tero (was: Commentsof 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: > > Pasi.Eronen@nokia.com writes: > > NO_NATS_ALLOWED is a bit different: since it's used only when we > > know beforehand that there are no NATs, so it contains the same > > address as the IP header -- so encrypting it does not provide > > anything extra... > > I disagree with that. How can we know there is no NAT between > beforehand? We have not tested the path or anything, so we do not know > if there is NAT or not. We can hope there is no NAT, as if there is > one, then we cannot establish connection, but we cannot know anything > about presense of NATs. > > Even if our configurations says there must not be NATs between us, it > does not mean that this is necessarely true, and it does not mean that > we can reveal the IP-addresses to the listeners. NO_NATS_ALLOWED means that your policy is not to use the link if it contains a NAT. IMHO this policy implies that you're not especially concerned about revealing your IP address. (And like I already mentioned in the mail about issue 60, NAT Traversal reveals the addresses, too, as is clearly said in the IKEv2 spec.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 20 08:28:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESZXD-0005dK-90 for mobike-archive@megatron.ietf.org; Thu, 20 Oct 2005 08:28:39 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07689 for ; Thu, 20 Oct 2005 08:28:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 33526FB28A; Thu, 20 Oct 2005 12:28:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C3A37FB27D; Thu, 20 Oct 2005 12:28:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 17952FB283; Thu, 20 Oct 2005 12:28:33 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 869E8FB262 for ; Thu, 20 Oct 2005 12:28: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 j9KCST7p021875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Oct 2005 15:28:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9KCSS3n029885; Thu, 20 Oct 2005 15:28:28 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17239.36204.436531.264864@fireball.kivinen.iki.fi> Date: Thu, 20 Oct 2005 15:28:28 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 7 min Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59: Editorial comments from Tero (was: Commentsof 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 Pasi.Eronen@nokia.com writes: > Tero Kivinen wrote: > > > > Pasi.Eronen@nokia.com writes: > > > NO_NATS_ALLOWED is a bit different: since it's used only when we > > > know beforehand that there are no NATs, so it contains the same > > > address as the IP header -- so encrypting it does not provide > > > anything extra... > > > > I disagree with that. How can we know there is no NAT between > > beforehand? We have not tested the path or anything, so we do not know > > if there is NAT or not. We can hope there is no NAT, as if there is > > one, then we cannot establish connection, but we cannot know anything > > about presense of NATs. > > > > Even if our configurations says there must not be NATs between us, it > > does not mean that this is necessarely true, and it does not mean that > > we can reveal the IP-addresses to the listeners. > > NO_NATS_ALLOWED means that your policy is not to use the link if it > contains a NAT. IMHO this policy implies that you're not especially > concerned about revealing your IP address. I might not be that much concerned, but the network I am using might be concerned. I personally think that the internal IP-address space used in any network do not have any security implications, so we can freely tell it to the world. Some people do not feel that way, and they might not like that misconfigured machines will tell the internal IP-addresses out. I mean if the employee actually goes and actively posts all the ip-address information to the public web-page he can be fired because he violated the company policy. If the employee has misconfigured IPsec client for that environment (but completely valid configuration in other environments) he really cannot be fired because of that... If there is anybody who feel that IP-addresses needs to be proteced, the same person will also want them to be protected even in case the user using his network has a configuration error in his machine. > (And like I already mentioned in the mail about issue 60, NAT Traversal > reveals the addresses, too, as is clearly said in the IKEv2 spec.) Digging out the IP-addresses from IKEv2 packets is a bit more work than simply getting reading them from the net. I mean it is actually much cheaper to act as a man in the middle in the exchange and check out the ID payload, than to dig out the IP-addresses used in the NAT-T. On the other hand storing all the NO_NATS_ALLOWED packets going past you in the net is again much cheaper than either one of those two. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 21 06:39:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESuIr-0005R1-KH for mobike-archive@megatron.ietf.org; Fri, 21 Oct 2005 06:39:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12706 for ; Fri, 21 Oct 2005 06:39:00 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D3833FB27F; Fri, 21 Oct 2005 10:39:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9D36AFB24F; Fri, 21 Oct 2005 10:39:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B890FFB27F; Fri, 21 Oct 2005 10:39:07 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id E5CACFB249 for ; Fri, 21 Oct 2005 10:39:05 +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 j9LAasJC004152; Fri, 21 Oct 2005 13:36:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 13:38:43 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 13:38:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Oct 2005 13:38:46 +0300 Message-ID: Thread-Topic: [Mobike] Issue 59: Editorial comments from Tero (was:Comments of draft-ietf-mobike-protocol-04.txt) Thread-Index: AcXVYhbpnAnIy4wDSPCY/K8Pqgg0bAAyJUvA From: To: X-OriginalArrivalTime: 21 Oct 2005 10:38:43.0033 (UTC) FILETIME=[9B7A0490:01C5D62B] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59: Editorial comments from Tero (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: > Because as you said in the earlier, unknown status notifications are > ignored, and unknown error notifications cause request to fail > entirely. So there is difference for them in the processing point of > view too. Thats why it might be good idea to also keep them separate > in the documentation too. That processing applies to _unknown_ notifications: anyone implementing this spec will process them as described in this spec, and he/she doesn't have to know which type they are. But OK, I'll add something to the beginning of Section 5 to make this distinction... BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 21 08:07:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESvfw-0003Sq-Fl for mobike-archive@megatron.ietf.org; Fri, 21 Oct 2005 08:07:08 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17386 for ; Fri, 21 Oct 2005 08:06:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8A5F9FB24F; Fri, 21 Oct 2005 12:07:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8E7B6FB24A; Fri, 21 Oct 2005 12:07:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7C1CCFB24F; Fri, 21 Oct 2005 12:06:59 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 2904CFB249 for ; Fri, 21 Oct 2005 12:06:57 +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 j9LC3OTR030557; Fri, 21 Oct 2005 15:03:28 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 15:06:54 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Oct 2005 15:06:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 21 Oct 2005 15:06:54 +0300 Message-ID: Thread-Topic: [Mobike] Issue 62: Editorial comments from Francis (was: review of draft-ietf-mobike-protocol-04.txt) Thread-Index: AcXSazmH6i3NA/y2R2aaX7YVwsXKAgDzHjQA From: To: , X-OriginalArrivalTime: 21 Oct 2005 12:06:54.0346 (UTC) FILETIME=[ED584EA0:01C5D637] Subject: [Mobike] Issue 62: Editorial comments from Francis (was: review 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 Francis Dupont wrote: > - in 1 page 3 > > IKEv2 is used for performing mutual authentication and establishing > and maintaining IPsec Security Associations (SAs). > > => too many "and"s Ok, I'll rephrase that. > - in 3.1 page 5 > > Making the decision at the initiator is consistent with how normal > IKEv2 works: the initiator decides which addresses it uses when > contacting the responder. It also makes sense, especially when the > initiator is the mobile node: it is in a better position to decide > which of its network interfaces should be used for both upstream and > downstream traffic. > > => as this has some limitations IMHO there should be a pointer to > the section 3.4 "Limitations". Earlier I've received comments that the document has too many pointers back and forth, so I've tried to avoid them (unless the paragraph will be difficult to understand with them). Here section 3.4 just provides some additional information the reader doesn't yet need at this point, and she/he will get to that section eventually :) > - in 3.2 page 6 and others > > Initiator Responder > ----------- ----------- > 1) HDR, SAi1, KEi, Ni, > N(NAT_DETECTION_*_IP) --> > > <-- HDR, SAr1, KEr, Nr, > N(NAT_DETECTION_*_IP) > ... > > => I believe the illustration needs the IP addresses and ports from > IP and UDP headers. If someone finds a good way to add them, the > whole stuff will become far more readable. Yes, that's a good suggestion. How about something like this: 1) (IP_I1:500 -> IP_R1:500) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) 3) (IP_I2:500 -> IP_R1:500) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP) } --> That is, use IP_I1,IP_I2,,.. for initiator addresses and IP_R1,IP_R2,... for responder addresses...? > - in 4.3 page 10 > > Note that if some of the initiator's interfaces are behind a > NAT (from the responder's point of view), the addresses > received by the responder will be incorrect. This means the > procedure for changing responder addresses described in > Section 4.5 does not fully work when the initiator is behind a > NAT. For the same reason, the peers also SHOULD NOT use this > information for any other purposes than what is explicitly > described in this document. > > => I have a problem with "this document". I propose to relax it in > "MOBIKE documents". How about rephrasing that to "...for any other purpose than what is explicitly described either in this document or a future specification updating it" ? > - in 4.4 page 11 > > The reasons why the initiator wishes to change the addresses > are largely beyond the scope of MOBIKE. Typically, triggers > include information received from lower layers, such as changes > in IP addresses or link-down indications. Some of this > information can be unreliable: for instance, ICMP messages > could be spoofed by an attacker. Unreliable information itself > MUST NOT be used to conclude than an update is needed: instead, > the initiator SHOULD trigger dead peer detection (that is, send > an INFORMATIONAL request). > > => this at the first read seems to conflict with path testing > (4.9). IMHO some clarification is needed, I propose something > like (after "an update is needed") "because the current path > seems to be no more usable"... Hmm, yes, the paragraph needs some clarification. In some sense, most of the information available to the host is to some degree unreliable, and there's no way to avoid using some of that. How about rewriting the last sentence as follows? "Unreliable information SHOULD be treated only as a hint that there might be a problem, and the initiator SHOULD trigger dead peer detection (that is, send an INFORMATIONAL request) to determine if the current path is still usable." > - in 4.6 page 15 > > To ensure that the peer cannot generate the correct > INFORMATIONAL response without seeing the request, a new > payload is added to INFORMATIONAL messages. The sender of an > INFORMATIONAL request MAY include a COOKIE2 notification, and > if included, the recipient of an INFORMATIONAL request MUST > copy the notification as-is to the response. When processing > the response, the original sender MUST verify that the value is > the same one as sent. If the values do not match, the IKE_SA > MUST be closed. > > => there is no explanation about COOKIE2, I propose an explicit > pointer to section 5.6. Ok, will be added. > - in 4.9 page 17 > IKEv2 Dead Peer Detection allows the peers to detect if the > currently used path has stopped working. However, if either of > the peers has several addresses, Dead Peer Detection alone does > not tell which of the other paths might work. > > => this text is fine but perhaps a bit late in the document > (i.e., path testing should be in the overview too)? Since this is not really new to MOBIKE, but just explains that the existing Informational exchange works, I'm not sure if adding more forward pointers would make any difference to the reader? > - in 5 > > => I believe "notification" is better English than "notify" but > as the IKEv2 document uses "notify payloads"... I've tried to make this reasonably consistent with the IKEv2 spec (but yes, IKEv2 could have been more consistent itself :-). > - in 6.1 page 20 > > MOBIKE introduces the NO_NATS_ALLOWED notification that is used > to detect modification, by outsiders, of the addresses in the > IP header. When this notification is used, communication > through NATs and other address translators is impossible, so it > is sent only when not doing NAT Traversal. This feature is > mainly intended for site-to-site VPN cases, where the > administrators may know beforehand that valid NATs are not > present, and thus any modification to the packet can be > considered an attack. > > => IPv6 environments are other obvious candidates for > NO_NATS_ALLOWED! Yes, Tero also pointed this out (see issue 59 for my proposal for text). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 21 12:10:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ESzT3-0006Fz-0h for mobike-archive@megatron.ietf.org; Fri, 21 Oct 2005 12:10:05 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15762 for ; Fri, 21 Oct 2005 12:09:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D1F4FFB27D; Fri, 21 Oct 2005 16:09:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AEC57FB24A; Fri, 21 Oct 2005 16:09:56 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 43843FB24F; Fri, 21 Oct 2005 16:09:55 +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 081B7FB249 for ; Fri, 21 Oct 2005 16:09:53 +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 j9LG9Z420692; Fri, 21 Oct 2005 18:09:35 +0200 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 j9LG9Zo0059896; Fri, 21 Oct 2005 18:09:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510211609.j9LG9Zo0059896@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com In-reply-to: Your message of Fri, 21 Oct 2005 15:06:54 +0300. Date: Fri, 21 Oct 2005 18:09:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 62: Editorial comments from Francis (was: review 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: , 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: > => as this has some limitations IMHO there should be a pointer to > the section 3.4 "Limitations". Earlier I've received comments that the document has too many pointers back and forth, so I've tried to avoid them (unless the paragraph will be difficult to understand with them). => this is a matter of taste: with pointers you have to turn pages when you read the document, without pointers you have to read it twice to catch the whole thing... I don't know what is the best for everybody, for me it is the first (pointers). > => I believe the illustration needs the IP addresses and ports from > IP and UDP headers. If someone finds a good way to add them, the > whole stuff will become far more readable. Yes, that's a good suggestion. How about something like this: 1) (IP_I1:500 -> IP_R1:500) HDR, SAi1, KEi, Ni, N(NAT_DETECTION_*_IP) --> <-- (IP_R1:500 -> IP_I1:500) HDR, SAr1, KEr, Nr, N(NAT_DETECTION_*_IP) 3) (IP_I2:500 -> IP_R1:500) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP) } --> That is, use IP_I1,IP_I2,,.. for initiator addresses and IP_R1,IP_R2,... for responder addresses...? => this seems fine, thanks! > - in 4.3 page 10 > > Note that if some of the initiator's interfaces are behind a > NAT (from the responder's point of view), the addresses > received by the responder will be incorrect. This means the > procedure for changing responder addresses described in > Section 4.5 does not fully work when the initiator is behind a > NAT. For the same reason, the peers also SHOULD NOT use this > information for any other purposes than what is explicitly > described in this document. > > => I have a problem with "this document". I propose to relax it in > "MOBIKE documents". How about rephrasing that to "...for any other purpose than what is explicitly described either in this document or a future specification updating it" ? => in the documents I thought about the "transport mode" one which uses the additional addresses but can't be qualified as "updating". I believe my proposal is better (and simpler/shorter). Hmm, yes, the paragraph needs some clarification. In some sense, most of the information available to the host is to some degree unreliable, and there's no way to avoid using some of that. How about rewriting the last sentence as follows? "Unreliable information SHOULD be treated only as a hint that there might be a problem, and the initiator SHOULD trigger dead peer detection (that is, send an INFORMATIONAL request) to determine if the current path is still usable." => fine. > - in 4.9 page 17 > IKEv2 Dead Peer Detection allows the peers to detect if the > currently used path has stopped working. However, if either of > the peers has several addresses, Dead Peer Detection alone does > not tell which of the other paths might work. > > => this text is fine but perhaps a bit late in the document > (i.e., path testing should be in the overview too)? Since this is not really new to MOBIKE, but just explains that the existing Informational exchange works, I'm not sure if adding more forward pointers would make any difference to the reader? => it was just a suggession. > => IPv6 environments are other obvious candidates for > NO_NATS_ALLOWED! Yes, Tero also pointed this out (see issue 59 for my proposal for text). => I'll try to reread all the other comments in time. 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 Fri Oct 21 18:50:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ET5iE-0007R5-09 for mobike-archive@megatron.ietf.org; Fri, 21 Oct 2005 18:50:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23270 for ; Fri, 21 Oct 2005 18:49:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E4E3CFB281; Fri, 21 Oct 2005 22:50:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 06A12FB24A; Fri, 21 Oct 2005 22:50:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 778DFFB277; Fri, 21 Oct 2005 22:50:03 +0000 (UTC) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id 8905AFB249 for ; Fri, 21 Oct 2005 22:50:02 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1ET5i5-0004vG-TK; Fri, 21 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 21 Oct 2005 18:50:01 -0400 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-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: , 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 : Design of the MOBIKE Protocol Author(s) : T. Kivinen, H. Tschofenig Filename : draft-ietf-mobike-design-04.txt Pages : 35 Date : 2005-10-21 The MOBIKE (IKEv2 Mobility and Multihoming) working group is developing extensions for the Internet Key Exchange Protocol version 2 (IKEv2). These extensions should enable an efficient management of IKE and IPsec Security Associations when a host possesses multiple IP addresses and/or where IP addresses of an IPsec host change over time (for example, due to mobility). This document discusses the involved network entities, and the relationship between IKEv2 signaling and information provided by other protocols. Design decisions for the MOBIKE protocol, background information and discussions within the working group are recorded. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-design-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-design-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-21155418.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-design-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-design-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-21155418.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 Sat Oct 22 02:59:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETDLg-0001As-JF for mobike-archive@megatron.ietf.org; Sat, 22 Oct 2005 02:59:24 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22824 for ; Sat, 22 Oct 2005 02:59:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 477ECFB281; Sat, 22 Oct 2005 06:59:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9592DFB277; Sat, 22 Oct 2005 06:59:20 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A527EFB27C; Sat, 22 Oct 2005 06:59:18 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 5438AFB24A for ; Sat, 22 Oct 2005 06:59:17 +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 j9M6xFGb025686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 22 Oct 2005 09:59:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9M6xF6D007994; Sat, 22 Oct 2005 09:59:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17241.58179.109033.462812@fireball.kivinen.iki.fi> Date: Sat, 22 Oct 2005 09:59:15 +0300 From: Tero Kivinen To: mobike@machshav.com In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-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 Internet-Drafts@ietf.org writes: > 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 : Design of the MOBIKE Protocol > Author(s) : T. Kivinen, H. Tschofenig > Filename : draft-ietf-mobike-design-04.txt > Pages : 35 > Date : 2005-10-21 > > The MOBIKE (IKEv2 Mobility and Multihoming) working group is > developing extensions for the Internet Key Exchange Protocol version > 2 (IKEv2). These extensions should enable an efficient management of > IKE and IPsec Security Associations when a host possesses multiple IP > addresses and/or where IP addresses of an IPsec host change over time > (for example, due to mobility). > > This document discusses the involved network entities, and the > relationship between IKEv2 signaling and information provided by > other protocols. Design decisions for the MOBIKE protocol, > background information and discussions within the working group are > recorded. In this new version of the design draft, there is some mostly rewritten sections about the choosing addresses and about NAT traversal, some of the other parts are reorganized, and quite a lot of text was also removed. So when reading this through, better keep that in mind, i.e. even when you remember that the old version had something about issue X later, do not assume so, but check it if you think the issue X needs to be in the draft. One change that I didn't yet do for this version was to check out the terminology, and the need for that. There was a suggestion that we do not need that section at all, but removing that would have required rewriting the scenarios and scope sections also, so I decided not to do it on this version. This document is trying to give some background and design information why we ended up using certaing method in the actual protocol document. I.e. the protocol document should say we do X, and this document is trying to tell why we ended up doing X, and what were the other options, and why they were not selected. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Oct 22 13:04:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETMn0-0002t6-KT for mobike-archive@megatron.ietf.org; Sat, 22 Oct 2005 13:04:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21042 for ; Sat, 22 Oct 2005 13:04:00 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EB6C9FB283; Sat, 22 Oct 2005 17:04:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E7D11FB277; Sat, 22 Oct 2005 17:04:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A7C95FB281; Sat, 22 Oct 2005 17:04:08 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 7594EFB24A for ; Sat, 22 Oct 2005 17:04:07 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4EE6A89848; Sat, 22 Oct 2005 20:04:05 +0300 (EEST) Message-ID: <435A7111.7030509@piuha.net> Date: Sat, 22 Oct 2005 20:04:17 +0300 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 59: Editorial comments from Tero (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 Pasi.Eronen@nokia.com wrote: >>In section 3.2. the second example should probably clarify that >>the exchange in step 3 is successful, i.e. the responder do >>respond to that in this example protocol run (as can be seen from >>the return packet sent by the responder, but the text below it >>gives feeling that it failed ("initiator gives up")). >> >>Perhaps there should also be example where that exchange is not >>successful. >> >> > >Hmm... the example was written by Jari, but I suspect the intention >was that step 3 is not successful (the initiator doesn't receive a >reply -- but then step 4 is wrong, as the initiator has to continue >retransmitting the first request). > >Jari, could you clarify? > > It was indeed intention that the return packet in step 3 would be lost. We forgot to draw this in the flow, however. I have used something like REQ ------------------------------------------------> RESP /---------------------------------- elsewhere. But the real question is I guess step 4 correctness. Yes, I actually thought that we could switch to another request, but as you point out, this is incorrect. Hmm... this means that we can't piggyback the RR test/cookie2 all of a sudden. Oh well, that means another roundtrip in this case. Retransmit the step 3 packet to a different address, then do an RR test separately. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Oct 22 13:33:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETNFF-0005C6-KJ for mobike-archive@megatron.ietf.org; Sat, 22 Oct 2005 13:33:25 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22406 for ; Sat, 22 Oct 2005 13:33:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 599ACFB289; Sat, 22 Oct 2005 17:33:24 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AA31EFB283; Sat, 22 Oct 2005 17:33:22 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 28668FB286; Sat, 22 Oct 2005 17:33:21 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2DC57FB277 for ; Sat, 22 Oct 2005 17:33:20 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7598F89848 for ; Sat, 22 Oct 2005 20:33:19 +0300 (EEST) Message-ID: <435A77EB.9010101@piuha.net> Date: Sat, 22 Oct 2005 20:33:31 +0300 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] issue summary from wglc 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 The following is my understanding of what the issue situation is. We need to work hard until I-D submission deadline on monday to get all these resolved with detailed text changes. Please comment on the issues and continue the discussion where necessary. Most importantly, post text. Also, let me know if the classification below is incorrect for some issue(s). --- Technical issues without solution and discussion hasn't ended: 68 - minimal conformance requirements 63 - extensibility and payload 60 - addresses in ike sa_init/auth Technical issues without proposed text but discussion has converged (or is uncontroversial) 67 - certain vs. possible changed address info 66 - imprecise explanation of what nat cases are not supported 61 - version number, again 57 - question about initiator decides (we're not reversing an earlier decision. but is there a specific text change needed? I did not see it, but...) 55 - mobike scope and limitations 52 - security of address updates 51 - spi collisions 45 - clarifications on security considerations (I will propose the remaining text) 44 - nat changes and ike rekey (we just need to note the limitation, nothing else we can do) Technical issues that have proposed text and discussion has converged 69 - rr requirements (aligning text to prior agreement on issues) 56 - ingress filtering (we've already decided that unidirectional is not supported -- even with impacts to some ingress filtering cases) 47 - more comments from mohan (or is some part still being discussed?) Editorial comments without proposed text 65 - jari's editorial issues (I will propose text) 64 - stephane's editorial issues 59 - tero's editorial comments (some text exists, not all) 58 - deleting an address (note: we are not reopening the discussion on diff/overwrite semantics. but there may be a clarification needed.) 54 - marcelo's editorial comments Editorial comments with proposed text 62 - editorial comments from francis 53 - editorial comments from pete 50 - more editorial comments from maureen 49 - editorial comments from maureen 48 - editorial comments from james (mostly has text, but is some part missing?) 46 - question about additional addresses (has proposed text. note that there's a link to one of parts of issue 68) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 06:03:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETchC-0001lb-WC for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 06:03:19 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25540 for ; Sun, 23 Oct 2005 06:03:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1D955FB27D; Sun, 23 Oct 2005 10:03:17 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 44FBCFB24A; Sun, 23 Oct 2005 10:03:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7BD4EFB277; Sun, 23 Oct 2005 10:03:13 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 884E5FB249 for ; Sun, 23 Oct 2005 10:03:12 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D0E0489848 for ; Sun, 23 Oct 2005 13:03:11 +0300 (EEST) Message-ID: <435B5FEC.2030200@piuha.net> Date: Sun, 23 Oct 2005 13:03:24 +0300 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] 68 - minimal conformance requirements 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 >> Note that both peers can have their own policies about what addresses >> are acceptable to use. A minimal "mobile client" could have a policy >> that says that only the responder's address specified in local >> configuration is acceptable. This kind of client does not have to >> send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a >> simple "VPN gateway" that has only a single address, and is not going >> to change it, does not need to send or understand >> ADDITIONAL_*_ADDRESS notifications. >> >> >I think we discussed this previously (and I have not >yet checked what the result of that discussion was). >However, the above client text sounds a bit too flexible >in my opinion. > I checked issue #46 where we discussed this before. The conclusion appeared to be that for the gateway the current text is OK. On the client part I don't think we decided anything. However, when thinking about this it seems that even the gateway part is suspect. It is true that you don't need the additional addresses on a gateway that is a responder. However, if this gateway is working in gateway-to-gateway mode and is an initiator towards the peer gateway which has multiple addresses, then we need it. We could try to describe all this, but I think the cost of that is greater than simply saying that nodes that conform to this specification need to be able to understand the additional addresses. It is another matter what needs to be sent. Here's a proposed text change: Note that both peers can have their own policies about what addresses are acceptable to use. A minimal "mobile client" could have a policy that says that only the responder's address specified in local configuration is acceptable. This kind of client does not have to send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or understand ADDITIONAL_*_ADDRESS notifications. => Note that a node that has only a single address at any given time does not need to send ADDITIONAL_*_ADDRESS notifications, but all nodes that support this specification must understand the reception of such notifications. However, nodes MAY have their own policies about what addresses are acceptable to use. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 06:14:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETcsB-00081j-M7 for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 06:14:40 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25900 for ; Sun, 23 Oct 2005 06:14:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 95285FB27D; Sun, 23 Oct 2005 10:14:37 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3070DFB24A; Sun, 23 Oct 2005 10:14:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 16044FB277; Sun, 23 Oct 2005 10:14:34 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 568DFFB249 for ; Sun, 23 Oct 2005 10:14:33 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id A0F7589848; Sun, 23 Oct 2005 13:14:32 +0300 (EEST) Message-ID: <435B6295.5070205@piuha.net> Date: Sun, 23 Oct 2005 13:14:45 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: MOBIKE Mailing List Subject: [Mobike] 63 - extensibility and payload 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 > > >- about 4.4: if/when we'd like to extend the mechanism, two things >seem to be interesting: > - the capability to move to another addresses (than the addresses in > the IP header of the message), for instance for network controlled > mobility. > - the capability to limit the update to a SA set (i.e., partial update). >Both will be easier with a payload... > > I agree that there are potentially interesting extensions, such as some kind of network control or limiting the SA set. As we have decided earlier, these are indeed future extensions and not a part of the initial base RFC. But lets talk about what design is best to accommodate for such future extensions. In both cases that you mention, it seems that the addition of a payload (with appropriate previous capability negotiation) does the job. For instance, if we would like to design a "limited SA set update" feature, then in the IKE init phase we can find out if both peers support that. Then, if this particular movement is a limited update, we can include a new payload to that effect in the IKE exchange that tells the peer about the move. Creating such payload now, however, would change the design quite a bit and would imho make it hard to support NATs. So, I would suggest that there are no text changes needed for the current document. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 06:26:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETd3w-000574-K4 for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 06:26:48 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26613 for ; Sun, 23 Oct 2005 06:26:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4BAC6FB27C; Sun, 23 Oct 2005 10:26:46 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B3ECEFB24A; Sun, 23 Oct 2005 10:26:44 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 01E4FFB277; Sun, 23 Oct 2005 10:26:42 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 5E4D6FB249 for ; Sun, 23 Oct 2005 10:26:41 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8C3E489848; Sun, 23 Oct 2005 13:26:39 +0300 (EEST) Message-ID: <435B656B.2090100@piuha.net> Date: Sun, 23 Oct 2005 13:26:51 +0300 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: <17239.28734.827449.444182@fireball.kivinen.iki.fi> In-Reply-To: <17239.28734.827449.444182@fireball.kivinen.iki.fi> Cc: mobike@machshav.com, Pasi.Eronen@nokia.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: >I agree that the revealing of the IP addresses is not very serious >case, but there are people who consider that unacceptable (that is why >the NAT-T uses hashes, as people did consider leaking the IP-addresses >a problem). If we leak them again here, there needs to be at least >security considerations section explaining the issue, and also explain >why we require them to be sent in clear when they could also be sent >as encrypted (i.e. hidden from passive attackers). > > We probably need the security considerations text in any case, because we have ADDITIONAL_*_ADDRESS. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 06:47:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETdNp-0005dN-03 for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 06:47:21 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27317 for ; Sun, 23 Oct 2005 06:47:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2ED22FB281; Sun, 23 Oct 2005 10:47:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2E759FB24A; Sun, 23 Oct 2005 10:47:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94A17FB277; Sun, 23 Oct 2005 10:47:13 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8541BFB249 for ; Sun, 23 Oct 2005 10:47:12 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D6BD889848 for ; Sun, 23 Oct 2005 13:47:11 +0300 (EEST) Message-ID: <435B6A3C.1000608@piuha.net> Date: Sun, 23 Oct 2005 13:47:24 +0300 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: <435B5FEC.2030200@piuha.net> In-Reply-To: <435B5FEC.2030200@piuha.net> Subject: Re: [Mobike] 68 - minimal conformance requirements 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 a proposed text change: > > Note that both peers can have their own policies about what addresses > are acceptable to use. A minimal "mobile client" could have a policy > that says that only the responder's address specified in local > configuration is acceptable. This kind of client does not have to > send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a > simple "VPN gateway" that has only a single address, and is not going > to change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > >=> > > Note that a node that has only a single address at any given time > does not need to send ADDITIONAL_*_ADDRESS notifications, but > all nodes that support this specification must understand the reception > of such notifications. However, nodes MAY have their own policies > about what addresses are acceptable to used. > > I noticed that Section 6.5 also has some text on this. Aligning the above proposal with that: Note that a node that has only a single address at any given time does not need to send ADDITIONAL_*_ADDRESS notifications, but all nodes that support this specification must understand the reception of such notifications. However, nodes MAY have their own policies about what local or peer addresses are acceptable. One possible policy on a client is that it refuses to talk to other gateway addresses than the configured one. This policy would imply that it should ignore peer's additional addresses, and, since it is the initiator, it does not need to send its own additional addresses as it will be in charge of all address changes in any case. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 06:48:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETdOz-0006Ra-4u for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 06:48:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27363 for ; Sun, 23 Oct 2005 06:48:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B75F7FB27D; Sun, 23 Oct 2005 10:48:30 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2F1F4FB277; Sun, 23 Oct 2005 10:48:28 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C2E4CFB27C; Sun, 23 Oct 2005 10:48:26 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 1F629FB249 for ; Sun, 23 Oct 2005 10:48:26 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6178589848; Sun, 23 Oct 2005 13:48:25 +0300 (EEST) Message-ID: <435B6A86.8050209@piuha.net> Date: Sun, 23 Oct 2005 13:48:38 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen , Pasi.Eronen@nokia.com References: <17239.28734.827449.444182@fireball.kivinen.iki.fi> In-Reply-To: <17239.28734.827449.444182@fireball.kivinen.iki.fi> 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 Having read through this thread, I tend to agree with Pasi on this, i.e., take the addresses from where they are currently taken from and use NO_NATS_ALLOWED where its currently in. I do not think the leakage of addresses is an issue, and if it is, we are already doing it in ADDITIONAL_*_ADDRESS. The rest of the issue is really a debate about aesthetics and complexity of variant 1 or variant 2; personally I think what's in the document right now seems better. Here's a suggested addition to the Security Considerations, Section 6.5, after the fourth paragraph: The use of NO_NATS_ALLOWED will also disclose the internal address to the peer, in case NAT was in the path. However, this has relevance only if the node is configured to first try with NO_NATS_ALLOWED and only then fallback to the use of NAT traversal if that fails. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 08:06:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETebz-0003CB-K0 for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 08:06:04 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00898 for ; Sun, 23 Oct 2005 08:05:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EE536FB283; Sun, 23 Oct 2005 12:06:00 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B5094FB24A; Sun, 23 Oct 2005 12:05:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0FBB5FB277; Sun, 23 Oct 2005 12:05:58 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 65F71FB249 for ; Sun, 23 Oct 2005 12:05:57 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7004C89848 for ; Sun, 23 Oct 2005 15:05:55 +0300 (EEST) Message-ID: <435B7CB0.8090909@piuha.net> Date: Sun, 23 Oct 2005 15:06:08 +0300 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] 67 - certain vs. possible changed address info 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 > > >> o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS >> notifications is received. This means the peer's addresses may >> have changed. >> >> >I think we have two cases: the list (and source) either >contains the addresses that we currently know of and >use, or they don't. In the former case addresses may >have changed, but in the latter case they surely have. >For instance, if the peer sends us a message saying >that its now in address B instead of A, we really need >to take that into account, rather than continuing to >use A. > >Suggestion: explain this in the bullet item, or split the >item in two. > Here's some suggested text: o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS notifications is received. This means the peer's addresses may have changed. => o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESSES notifications is received. This means the peer's addresses may have changed. This is particularly important if the currently used address for peer is no longer in the announced set of addresses. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 08:40:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETf9n-0003J8-Mn for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 08:40:59 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02799 for ; Sun, 23 Oct 2005 08:40:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B611BFB281; Sun, 23 Oct 2005 12:40:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 32572FB24A; Sun, 23 Oct 2005 12:40:51 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 344FDFB277; Sun, 23 Oct 2005 12:40:49 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 22DAAFB249 for ; Sun, 23 Oct 2005 12:40:48 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6E6D889884 for ; Sun, 23 Oct 2005 15:40:47 +0300 (EEST) Message-ID: <435B84DC.7050004@piuha.net> Date: Sun, 23 Oct 2005 15:41:00 +0300 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] 66 - imprecise explanation of what nat cases are not supported 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 > > >> "Does not fully support" means that no special effort is made to >> support this functionality. However, if the alternative is losing >> connectivity completely, the responder can still attempt to proceed >> with the change, and depending on, e.g., the exact type of NAT, it >> may succeed. However, analyzing the exact circumstances when this >> will or will not work is not done in this document. >> >> >I'm OK with the text being vague about the type of >scenarios supported beyond the basic client-inside-NAT >case. However, the above text appears to say that the >responder is capable of detecting such situations, >which I don't think is at least always true. > Here's some proposed text: "Does not fully support" means that no special effort is made to support this functionality. However, if the alternative is losing connectivity completely, the responder can still attempt to proceed with the change, and depending on, e.g., the exact type of NAT, it may succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document. => "Does not fully support" means that no special effort is made to support this functionality. Responders may also be unaware of NATs or specific types of NATs they are behind. However, when a change has occurred that will cause a loss of connectivity, MOBIKE responders will still attempt to inform the initiator of the change. Depending on, e.g., the exact type of NAT, it may or may not succeed. However, analyzing the exact circumstances when this will or will not work is not done in this document. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 08:51:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETfKL-0007NB-3q for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 08:51:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03126 for ; Sun, 23 Oct 2005 08:51:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id EB7ECFB28A; Sun, 23 Oct 2005 12:51:51 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D0065FB24A; Sun, 23 Oct 2005 12:51:45 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3E9AAFB277; Sun, 23 Oct 2005 12:51:44 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9E669FB249 for ; Sun, 23 Oct 2005 12:51:43 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E06A889848; Sun, 23 Oct 2005 15:51:42 +0300 (EEST) Message-ID: <435B8767.8040702@piuha.net> Date: Sun, 23 Oct 2005 15:51:51 +0300 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: <17239.23735.97798.48217@fireball.kivinen.iki.fi> In-Reply-To: <17239.23735.97798.48217@fireball.kivinen.iki.fi> Cc: mobike@machshav.com, Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 61 (was: Comments ofdraft-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: >Pasi.Eronen@nokia.com writes: > > >> The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The >> Protocol ID and SPI Size fields are set to zero. The notification >> data field MUST be left empty (zero-length) when sending, and its >> contents (if any) MUST be ignored when this notification is >> received. This allows the field to be used by future versions of >> this protocol. >> >> > >Perfect for me. > > Works for me too. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 09:20:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETflq-0008L9-DQ for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 09:20:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04087 for ; Sun, 23 Oct 2005 09:20:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C2019FB27C; Sun, 23 Oct 2005 13:20:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9BA61FB24A; Sun, 23 Oct 2005 13:20:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 69D38FB277; Sun, 23 Oct 2005 13:20:12 +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 25EB8FB249 for ; Sun, 23 Oct 2005 13:20:11 +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 j9NDJss04490; Sun, 23 Oct 2005 15:19:54 +0200 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 j9NDJscO077006; Sun, 23 Oct 2005 15:19:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510231319.j9NDJscO077006@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Sun, 23 Oct 2005 13:14:45 +0300. <435B6295.5070205@piuha.net> Date: Sun, 23 Oct 2005 15:19:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List Subject: Re: [Mobike] 63 - extensibility and payload 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: So, I would suggest that there are no text changes needed for the current document. => my comment was about future (if/when...). 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 Sun Oct 23 09:39:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETg40-00060A-E8 for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 09:39:04 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04740 for ; Sun, 23 Oct 2005 09:38:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 26132FB283; Sun, 23 Oct 2005 13:39:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9B8CFFB24A; Sun, 23 Oct 2005 13:38:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2FEFEFB277; Sun, 23 Oct 2005 13:38:58 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 0CA89FB249 for ; Sun, 23 Oct 2005 13:38:57 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CB0C589848; Sun, 23 Oct 2005 16:38:55 +0300 (EEST) Message-ID: <435B927C.9000207@piuha.net> Date: Sun, 23 Oct 2005 16:39:08 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy , Pasi Eronen Cc: MOBIKE Mailing List Subject: [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 Looking at this again... >- Section 6.1 > >The last paragraph talks about NO_NATS_ALLOWED. The attack of >modifying the header to cause DoS attack is only possible if the >attacker knows that NO_NATS_ALLOWED is carried within the payload. As >payloads are encrypted, it may not be that easy always. It is easy if >it is the IKE_SA_INIT message.It might be worth stating when the >attack is possible. > > I think the only thing that Mohan wanted to do was to explain the condition of the attack that NO_NATS_ALLOWED protects against. Here's the simple text modification: MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. ... => MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. Such modifications can only be performed by attackers who are on the path and capable of modifying the IKEv2 and IPsec packets. ... >- Section 6.3 > > Normally such attacks would expire in a short time frame due to the > lack of responses (such as transport layer acknowledgements) from the > victim. However, as described in [Aura02], malicious participants > would typically be able to spoof such acknowledgements and maintain > the traffic flow for an extended period of time. > >This attack is possible because the victim does not have a valid SA >for the incoming ESP traffic and never reaches the TCP layer and hence >no TCP RSTs. Might be worth mentioning here. > > Add the following text to the end of this paragraph: ... Such an attack could also be defeated by use of negative acknowledgements, such as TCP RST and ICMP errors. However, too eager reliance on such acknowledgements has some denial-of-service issues itself. Also, many networks filter ICMP messages, and in our case the lack of a valid SA in the victim prevents TCP processing of incoming ESP packets. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 09:39:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETg4j-0006Jg-6Q for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 09:39:49 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04764 for ; Sun, 23 Oct 2005 09:39:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 122FEFB27D; Sun, 23 Oct 2005 13:39:48 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 037FDFB24A; Sun, 23 Oct 2005 13:39:47 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DDC7DFB277; Sun, 23 Oct 2005 13:39:44 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 743F8FB249 for ; Sun, 23 Oct 2005 13:39:43 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C8F2589848; Sun, 23 Oct 2005 16:39:42 +0300 (EEST) Message-ID: <435B92AB.6020808@piuha.net> Date: Sun, 23 Oct 2005 16:39:55 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200510231319.j9NDJscO077006@givry.rennes.enst-bretagne.fr> In-Reply-To: <200510231319.j9NDJscO077006@givry.rennes.enst-bretagne.fr> Cc: MOBIKE Mailing List Subject: Re: [Mobike] 63 - extensibility and payload 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 Right. Francis Dupont wrote: > In your previous mail you wrote: > > So, I would suggest that there are no text changes needed > for the current document. > >=> my comment was about future (if/when...). > >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 Sun Oct 23 10:07:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETgVy-0006nr-7D for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 10:07:58 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06300 for ; Sun, 23 Oct 2005 10:07:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CBC8FFB28B; Sun, 23 Oct 2005 14:07:55 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7C8A4FB281; Sun, 23 Oct 2005 14:07:53 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A9E59FB286; Sun, 23 Oct 2005 14:07:51 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 19733FB277 for ; Sun, 23 Oct 2005 14:07:51 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6695289848 for ; Sun, 23 Oct 2005 17:07:50 +0300 (EEST) Message-ID: <435B9942.6040007@piuha.net> Date: Sun, 23 Oct 2005 17:08:02 +0300 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] 44 - nat changes and ike rekey 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 Text proposal: Section 4.4 The initiator receives a NAT_DETECTION_DESTINATION_IP notification that does not match the previous UPDATE_SA_ADDRESSES response (see Section 4.7 for a more detailed description). => The initiator receives a NAT_DETECTION_DESTINATION_IP notification with a value that does not match the value in a previous UPDATE_SA_ADDRESSES response (see Section 4.7 for a more detailed description). Note that this may cause an extra address update when IKE rekeying is in progress, because the NAT_DETECTION_DESTINATION_IP notification only contains a hash of the address and some other values such as the SPIs which change upon IKE rekey. Such an extra address update is harmless, however. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 10:47:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETh8E-0003Zq-Rd for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 10:47:31 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08789 for ; Sun, 23 Oct 2005 10:47:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 67592FB27D; Sun, 23 Oct 2005 14:47:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 41A6AFB24A; Sun, 23 Oct 2005 14:47:18 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CB891FB277; Sun, 23 Oct 2005 14:47:16 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A39BDFB249 for ; Sun, 23 Oct 2005 14:47:15 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 159FC89848 for ; Sun, 23 Oct 2005 17:47:14 +0300 (EEST) Message-ID: <435BA26B.70906@piuha.net> Date: Sun, 23 Oct 2005 17:47:07 +0300 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] 65 - jari's editorial issues 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 Proposed text: >>In the current >> specifications, the IPsec and IKE SAs are created implicitly between >> the IP addresses that are used when the IKE_SA is established. >> >s/current specifications/base IKEv2 protocol/ > > See above. >> user interaction for authentication (entering a code from a token >> card, for instance). >> >.... authentication, such as entering ... > > See above. >>3.1. Basic Operation >> >2nd para: it would be useful to state early that ike exchange >initiator decides the addresses to use for that exchange. Right >now you only talk about IPsec addresses. I know this is part of >ikev2, but the reader may not have the background to understand >this. > > MOBIKE solves this problem by taking a simple approach: the party that initiated the IKE_SA ... => MOBIKE solves this problem by taking a simple approach Firstly, for every IKE exchange, the initiator of that exchange decides which addresses to use for IKE itself. Secondly, the party that initiated the IKE_SA ... >>3.2. Example Protocol Runs >> >2nd example, Step 3 needs to show that the response is lost. > >The 2nd example should also explain better why COOKIE2 >is needed in Step 4. > > This was already discussed in the context of issue 59 so I won't add the text here. >>3.4. Limitations >> >> >Probably worthwhile to explain this earlier, maybe as Section >1.1. > > Just move it there. >>4.8. NAT Prohibition >> >This section would benefit from a message flow example. > >> The attackers in this threat can be either outsiders or even one of >> the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers >> can be easily dealt with if the authentication performed in the >> initial IKEv2 negotiation can be traced to persons who can be held >> responsible for the attack. This may not be the case in all >> scenarios, particularly with opportunistic approaches to security. >> >> >s/persons/persons or devices/? > See above. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 11:51:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETi8H-0007vC-P4 for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 11:51:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11965 for ; Sun, 23 Oct 2005 11:51:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D020DFB27C; Sun, 23 Oct 2005 15:51:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BFBA0FB24A; Sun, 23 Oct 2005 15:51:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 921B3FB277; Sun, 23 Oct 2005 15:51:31 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 1ACE0FB249 for ; Sun, 23 Oct 2005 15:51:30 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5826289848; Sun, 23 Oct 2005 18:51:28 +0300 (EEST) Message-ID: <435BB18C.3090100@piuha.net> Date: Sun, 23 Oct 2005 18:51:40 +0300 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] 55 - scope and limitations (marcelo's issue) 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 Thanks again Marcelo for your comments. This is very useful. There was really a number of subissues: 1) Are multiple address pairs allowed? 2) Are unidirectional address pairs allowed? 3) Multihoming for the establishment phase v.s only later? 3b) If MOBIKE retries in establishment phase, does it vary source address? 4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR 5) Is simultaneous movement supported? 6) Are only local failures supported? I think the consensus has been that we don't want to go too much in to the reasons of why something is the way it is in this document (that's the job of the design document). However, we do need to describe the limitations. I'll first go through Marcelo's items from above and try to explain what I think the situation is. At the end I'll have suggested text for a new limitations section. 1) Are multiple address pairs allowed? Yes. Multiple pairs are allowed. Their simultaneous use for payload traffic is, however, outside the scope of the document, and would probably need extra mechanisms (e.g. ensure its different TCP streams) to work well. 2) Are unidirectional address pairs allowed? No. Explicit design decision to make things easy. 3) Multihoming for the establishment phase v.s only later? MOBIKE is for later phases only, but we can provide some guidance on what (limited) things can be done in the establishment phase. 3b) If MOBIKE retries in establishment phase, does it vary source address? It should. I'm a bit scared here to step on the area that your future enhanced RFC 3484 version will say, though. Technically, these are components; when 3484bis is available things sudddenly start working better. But I'll suggest something vague about this. 4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR This isn't an issue, really, but rather a misunderstanding of the text. There's no problem when the initiator (behind NAT) decides to use new addresses. The problem is when the responder moves; some NAT types don't allow this, and it may even be that the addresses provided for this emergency in ADDITIONAL_*_ADDRESS are internal, and not reachable by peer. I'd say no text changes. 5) Is simultaneous movement supported? No. Needs to be documented. 6) Are only local failures supported? No. MOBIKE, like SHIM6, supports both lower layers telling you that the link went away as well as experienced failures in IP communication (IKE DPD vs. SHIM6 reachability packets not getting through). Ok. So here's an attempt at some new text for Section 1.1, what used to be 3.4 Limitations: 1.1 Limitations This document focuses on the main scenario outlined above, and supports only tunnel mode. The mobility support in MOBIKE allows either party to move, but not both at the same time. This implies that MOBIKE is best suited for client - gateway or gateway - gateway applications. Two mobile clients would find it hard to use MOBIKE directly between themselves, and for such applications a gateway is recommended between the communicating clients. The multihoming support in MOBIKE allows either party to have multiple addresses. This specification does not guarantee that more than pair of such addresses can be used for payload traffic at any one time, however. This implies that load-balancing applications are out of scope in the base protocol. Similarly, due to the nature of the IKEv2 protocol and NAT considerations, MOBIKE is only guaranteed to work correctly over bidirectionally operational address pairs. That is, the same pair of addresses is used in both directions. Indeed, the protocol mechanisms used to determine reachability of the peer ensure that such a pair is in use. The MOBIKE protocol can only be used once the IKE SAs have been established. This implies that movements or additional addresses for the peer can not be discovered until a working connection to the peer has been established. This implies that the IKE SA establishment phase has limitations with regards to initial discovery of alternative addresses, unless those addresses are known in the configuration and/or DNS. For details, see Section 4.0. NATs introduce additional limitations beyond those listed above. For details, refer to Section 3.3. The base version of the MOBIKE protocol may also not cover all potential future use scenarios, such as transport mode, application to securing SCTP, or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. And a new Section 4.0 between 4. and 4.1: 4.0 Addresses for the Initial IKE Exchange The initiator is responsible for finding a working pair of addresses so that the initial IKE exchange can be carried out. Any information from MOBIKE extensions will only be available later, when the exchange has progressed far enough. IKE initiator may retrieve the peer address(es) from various sources, such as the outgoing packet that triggered the IKE exchange, configuration, or DNS. Similarly, the initiator knows its own address(es). If multiple peer addresses are known, the initiator SHOULD vary the destination address in retranmissions, in case the address used in the first attempt is inoperational. Similarly, if these addresses do not appear to respond, the initiator MAY vary the source address it uses for itself, in case there is a problem in a particular address prefix or the failure is due to an ingress filtering problem. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Oct 23 11:52:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETi8s-00080b-VV for mobike-archive@megatron.ietf.org; Sun, 23 Oct 2005 11:52:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12005 for ; Sun, 23 Oct 2005 11:52:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C20A3FB281; Sun, 23 Oct 2005 15:52:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C2CB0FB277; Sun, 23 Oct 2005 15:52:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6C45AFB27C; Sun, 23 Oct 2005 15:52:11 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 57D42FB249 for ; Sun, 23 Oct 2005 15:52:10 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9FE5589848 for ; Sun, 23 Oct 2005 18:52:09 +0300 (EEST) Message-ID: <435BB1B5.60406@piuha.net> Date: Sun, 23 Oct 2005 18:52:21 +0300 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] issue summary from wglc, take 2 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 Updated list: Technical issues with proposed text but some discussion may still be needed: 68 - minimal conformance requirements 60 - addresses in ike sa_init/auth Technical issues without proposed text but discussion has converged (or is uncontroversial) 57 - question about initiator decides (we're not reversing an earlier decision. but is there a specific text change needed? I did not see it, but...) 52 - security of address updates 51 - spi collisions Technical issues that have proposed text and discussion has converged 69 - rr requirements (aligning text to prior agreement on issues) 67 - certain vs. possible changed address info 66 - imprecise explanation of what nat cases are not supported 63 - extensibility and payload (no changes needed) 61 - version number, again 56 - ingress filtering (we've already decided that unidirectional is not supported -- even with impacts to some ingress filtering cases) 55 - mobike scope and limitations 47 - more comments from mohan (or is some part still being discussed?) 45 - clarifications on security considerations 44 - nat changes and ike rekey Editorial comments without proposed text 64 - stephane's editorial issues 59 - tero's editorial comments (some text exists, not all) 58 - deleting an address (note: we are not reopening the discussion on diff/overwrite semantics. but there may be a clarification needed.) 54 - marcelo's editorial comments Editorial comments with proposed text 65 - jari's editorial issues (but make sure 59 is solved too) 62 - editorial comments from francis 53 - editorial comments from pete 50 - more editorial comments from maureen 49 - editorial comments from maureen 48 - editorial comments from james (mostly has text, but is some part missing?) 46 - question about additional addresses (has proposed text. note that there's a link to one of parts of issue 68) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 03:54:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxA7-0003mO-Kb for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 03:54:31 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23151 for ; Mon, 24 Oct 2005 03:54:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8F92DFB283; Mon, 24 Oct 2005 07:54:28 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B4848FB27C; Mon, 24 Oct 2005 07:54:26 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B241FFB280; Mon, 24 Oct 2005 07:54:24 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id ABE19FB249 for ; Mon, 24 Oct 2005 07:54:23 +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 j9O7sHoA010946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2005 10:54:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9O7sGEV020726; Mon, 24 Oct 2005 10:54:16 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17244.37672.713976.558411@fireball.kivinen.iki.fi> Date: Mon, 24 Oct 2005 10:54:16 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <435B5FEC.2030200@piuha.net> References: <435B5FEC.2030200@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 0 min X-Total-Time: 0 min Cc: MOBIKE Mailing List Subject: [Mobike] 68 - minimal conformance requirements 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: > Here's a proposed text change: > > Note that both peers can have their own policies about what addresses > are acceptable to use. A minimal "mobile client" could have a policy > that says that only the responder's address specified in local > configuration is acceptable. This kind of client does not have to > send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a > simple "VPN gateway" that has only a single address, and is not going > to change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > > => > > Note that a node that has only a single address at any given time > does not need to send ADDITIONAL_*_ADDRESS notifications, but > all nodes that support this specification must understand the reception > of such notifications. However, nodes MAY have their own policies > about what addresses are acceptable to use. That is 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 Mon Oct 24 04:02:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxI5-0005Vr-O7 for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 04:02:45 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23488 for ; Mon, 24 Oct 2005 04:02:27 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B3107FB280; Mon, 24 Oct 2005 08:02:39 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C0E91FB280; Mon, 24 Oct 2005 08:02:35 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94C25FB27C; Mon, 24 Oct 2005 08:02:32 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 2A866FB23E for ; Mon, 24 Oct 2005 08:02: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 j9O82USh016529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2005 11:02:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9O82TEg027817; Mon, 24 Oct 2005 11:02:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17244.38165.742830.299119@fireball.kivinen.iki.fi> Date: Mon, 24 Oct 2005 11:02:29 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <435B6A86.8050209@piuha.net> References: <17239.28734.827449.444182@fireball.kivinen.iki.fi> <435B6A86.8050209@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 7 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.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 Jari Arkko writes: > Having read through this thread, I tend to agree with > Pasi on this, i.e., take the addresses from where they > are currently taken from and use NO_NATS_ALLOWED > where its currently in. > > I do not think the leakage of addresses is an issue, and > if it is, we are already doing it in ADDITIONAL_*_ADDRESS. > The rest of the issue is really a debate about aesthetics > and complexity of variant 1 or variant 2; personally I think > what's in the document right now seems better. I have really started to hate different variations in the protocol. It causes lots of different new tests to be done. In the last interop we already did around 50 different tests to get through the basic exchanges. That didn't include testing different ciphers or macs, only different variations of the IKE protocol (auth methods, rekeying, cookies, invalid ke notify, liveness, basic NAT). The more versions of protocol we have for mobike, the more complex test matrix we need to generate for it too. > Here's a suggested addition to the Security Considerations, > Section 6.5, after the fourth paragraph: > > The use of NO_NATS_ALLOWED will also disclose the > internal address to the peer, in case NAT was in the path. > However, this has relevance only if the node is configured to first > try with NO_NATS_ALLOWED and only then fallback to > the use of NAT traversal if that fails. NO_NATS_ALLOWED discloses the internal address to the WORLD, not to the peer. It relevant in case NO_NATS_ALLOWED is ever configured, and that node is ever behind NAT whose IP-addresses adminstrators are not willing to disclose. The fallback case is not the only case it is also about misconfigurations. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 04:15:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxUG-0001Qw-2y for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 04:15:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24189 for ; Mon, 24 Oct 2005 04:15:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C88E1FB286; Mon, 24 Oct 2005 08:15:18 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D4FE2FB280; Mon, 24 Oct 2005 08:15:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D0A23FB281; Mon, 24 Oct 2005 08:15:13 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 5F583FB27C for ; Mon, 24 Oct 2005 08:15:11 +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 j9O8F8ig024911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2005 11:15:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9O8F7P1018480; Mon, 24 Oct 2005 11:15:07 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17244.38923.424593.923409@fireball.kivinen.iki.fi> Date: Mon, 24 Oct 2005 11:15:07 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <435BB18C.3090100@piuha.net> References: <435BB18C.3090100@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 8 min Cc: MOBIKE Mailing List Subject: [Mobike] 55 - scope and limitations (marcelo's issue) 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: > Thanks again Marcelo for your comments. This is > very useful. There was really a number of subissues: > > 1) Are multiple address pairs allowed? > 2) Are unidirectional address pairs allowed? > 3) Multihoming for the establishment phase v.s only later? > 3b) If MOBIKE retries in establishment phase, does it vary source address? > 4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR > 5) Is simultaneous movement supported? > 6) Are only local failures supported? I think these are mostly questions for the design draft. I tried to check that at least some of those are answered by the new version of design draft, but you might want to check that I didn't miss something (I was a bit hurry when making that draft to get it out before deadline). > 1.1 Limitations > > This document focuses on the main scenario outlined above, and > supports only tunnel mode. > > The mobility support in MOBIKE allows either party to move, > but not both at the same time. This implies that MOBIKE is best > suited for client - gateway or gateway - gateway applications. Two > mobile clients would find it hard to use MOBIKE directly between > themselves, and for such applications a gateway is recommended > between the communicating clients. > > The multihoming support in MOBIKE allows either party to have > multiple addresses. This specification does not guarantee that > more than pair of such addresses can be used for payload traffic > at any one time, however. This implies that load-balancing applications > are out of scope in the base protocol. Similarly, due to the nature > of the IKEv2 protocol and NAT considerations, MOBIKE is only guaranteed > to work correctly over bidirectionally operational address pairs. > That is, the same pair of addresses is used in both directions. Indeed, > the protocol mechanisms used to determine reachability of the > peer ensure that such a pair is in use. > > The MOBIKE protocol can only be used once the IKE SAs have > been established. This implies that movements or additional > addresses for the peer can not be discovered until a working > connection to the peer has been established. This implies that > the IKE SA establishment phase has limitations with regards to > initial discovery of alternative addresses, unless those addresses > are known in the configuration and/or DNS. For details, see > Section 4.0. > > NATs introduce additional limitations beyond those listed above. > For details, refer to Section 3.3. > > The base version of the MOBIKE protocol may also not cover all potential > future use scenarios, such as transport mode, application to securing > SCTP, or optimizations desirable in specific circumstances. Future > extensions may be defined later to support additional requirements. Perhaps add pointer to the design draft also (to the point where it explains more about these issues, i.e. section 5.1 for choosing addresses, multihoming, unidirectional paths etc, and section 5.2. for NAT, at least). But that text is good summary of the limitations. > And a new Section 4.0 between 4. and 4.1: > > 4.0 Addresses for the Initial IKE Exchange > > The initiator is responsible for finding a working pair of > addresses so that the initial IKE exchange can be carried > out. Any information from MOBIKE extensions will only be > available later, when the exchange has progressed far enough. > > IKE initiator may retrieve the peer address(es) from various > sources, such as the outgoing packet that triggered the > IKE exchange, configuration, or DNS. Similarly, the initiator > knows its own address(es). > > If multiple peer addresses are known, the initiator SHOULD > vary the destination address in retranmissions, in case the > address used in the first attempt is inoperational. Similarly, > if these addresses do not appear to respond, the initiator > MAY vary the source address it uses for itself, in case there > is a problem in a particular address prefix or the failure is > due to an ingress filtering problem. That is also good section to be added. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 04:32:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxkq-00063T-HR for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 04:32:31 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24786 for ; Mon, 24 Oct 2005 04:32:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3C366FB286; Mon, 24 Oct 2005 08:32:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9AC7EFB27C; Mon, 24 Oct 2005 08:32:23 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D581DFB280; Mon, 24 Oct 2005 08:32:21 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id B4F6DFB249 for ; Mon, 24 Oct 2005 08:32:20 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C7B4989848; Mon, 24 Oct 2005 11:32:10 +0300 (EEST) Message-ID: <435C9C17.9080302@piuha.net> Date: Mon, 24 Oct 2005 11:32:23 +0300 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 , Tuomas Aura , Tero Kivinen Subject: [Mobike] 52 - security of address updates 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 There seems to be six issues: 1) Noting that mobike hosts are more vulnerable to various attacks than static hosts, due to the variety of links they visit We can do this. Add this to Section 6, first paragraph, between the first and second paragraphs: "Mobile nodes are also more likely to encounter malicious environments, given the many networks that they travel in." 2) The lack of address authentication This is due to NATs, and there's little we can do about it. NO_NATS_ALLOWED, however, fixes this (where it can be used is another matter). 3) Defense 1: use NO_NATS_ALLOWED if on a public address This would be good to have as an option. Here's some suggested text: Insert to 4.8, at the end of the 2nd paragraph: An initiator may also have a policy that if it has an address that is know to be a public address, it employs NO_NATS_ALLOWED. This prevents the vulnerability to address changing attacks when the node has an obviously public address. (However, some firewalls may require UDP encapsulation to be used even in such cases.) 4) Defense 2: disallow movements on the same link I would rather not do this. This would make RFC 3041 harder, and I'm not sure we can reliably detect when two addresses "are on the same link". 5) Is NO_NATS_ALLOWED mandatory if NAT-T is not supported It is. See 4.8 in -04. 6) Can the protocol recover from an attack when NO_NATS_ALLOWED is in use. I think it can. As part of some other issues we've inserted text that talks about retrying rather than giving immediately upon when an address appears to have changed. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 04:33:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETxlz-0006L0-No for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 04:33:39 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24837 for ; Mon, 24 Oct 2005 04:33:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 79A2BFB281; Mon, 24 Oct 2005 08:33:38 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C296AFB249; Mon, 24 Oct 2005 08:33:36 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A78E2FB280; Mon, 24 Oct 2005 08:33:35 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2BF75FB246 for ; Mon, 24 Oct 2005 08:33:35 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5FF2189848; Mon, 24 Oct 2005 11:33:34 +0300 (EEST) Message-ID: <435C9C6A.6010703@piuha.net> Date: Mon, 24 Oct 2005 11:33:46 +0300 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: <435BB18C.3090100@piuha.net> <17244.38923.424593.923409@fireball.kivinen.iki.fi> In-Reply-To: <17244.38923.424593.923409@fireball.kivinen.iki.fi> Cc: MOBIKE Mailing List Subject: Re: [Mobike] 55 - scope and limitations (marcelo's issue) 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: >Perhaps add pointer to the design draft also > > Yes. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 05:31:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyfV-0003ks-3M for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 05:31:01 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27100 for ; Mon, 24 Oct 2005 05:30:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0D4E4FB283; Mon, 24 Oct 2005 09:30:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DF3B6FB280; Mon, 24 Oct 2005 09:30:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9E238FB281; Mon, 24 Oct 2005 09:30:54 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 005DAFB249 for ; Mon, 24 Oct 2005 09:30:54 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id BE21B89848; Mon, 24 Oct 2005 12:30:52 +0300 (EEST) Message-ID: <435CA9D9.5010207@piuha.net> Date: Mon, 24 Oct 2005 12:31:05 +0300 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: <17239.28734.827449.444182@fireball.kivinen.iki.fi> <435B6A86.8050209@piuha.net> <17244.38165.742830.299119@fireball.kivinen.iki.fi> In-Reply-To: <17244.38165.742830.299119@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 Tero Kivinen wrote: >I have really started to hate different variations in the protocol. > > I hate that too, but is there something we can do in this specific issue about that? Are you saying that your option would not create a new variant? >>Here's a suggested addition to the Security Considerations, >>Section 6.5, after the fourth paragraph: >> >>The use of NO_NATS_ALLOWED will also disclose the >>internal address to the peer, in case NAT was in the path. >>However, this has relevance only if the node is configured to first >>try with NO_NATS_ALLOWED and only then fallback to >>the use of NAT traversal if that fails. >> >> > >NO_NATS_ALLOWED discloses the internal address to the WORLD, not to >the peer. > > Hm. I missed this. Why does it reveal the address to the world? Because its sent in a too early IKE message that is not yet encrypted? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 05:49:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyx4-0007zk-5F for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 05:49:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27890 for ; Mon, 24 Oct 2005 05:48:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3172CFB286; Mon, 24 Oct 2005 09:49:08 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9E981FB249; Mon, 24 Oct 2005 09:49:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 886B3FB280; Mon, 24 Oct 2005 09:49:02 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 62CEEFB246 for ; Mon, 24 Oct 2005 09:49:01 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D7A1A89848; Mon, 24 Oct 2005 12:48:59 +0300 (EEST) Message-ID: <435CAE18.6030205@piuha.net> Date: Mon, 24 Oct 2005 12:49:12 +0300 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 , marcelo bagnulo braun , Tero Kivinen Subject: [Mobike] 57 - question about initiator decides 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 It seems that discussion about this particular design choice belongs to the design document. So no text changes to protocol-04. FWIW, I'm at least personally quite happy about this decision. You have good questions, Marcelo, and I hope this will improve our design document! Some further discussion below: >Now what i would like to understand is what parts of the mobike protocol >would not support the more general scenario, where both parties can >change the address pair used for the communication. > > We need to separate the ability to use different addresses and the protocol's internal process at arriving a decision from each other. Now, just because initiator decides in MOBIKE, it doesn't mean that responder's addresses could not change, or that the responder's input is not taken into account. In other words, its not a constraint that only X can do something, but an arrangement where X gets information and is the party responsible for final decisions and coordination. An analogy may be a distributed system where one of the nodes is elected to be a leader. We found that the arrangement simplifies the operation of the protocol. >As i see it, this was a constraint to simplify the protocol to a case >like the VPN which was useful. My question at this point is how much of >the resulting protocol actually relies on this constraint? >As i read it, this resulted in the following constraints: >- Tunnel mode only is supported > > I don't think this is a result of the initiator-decides design. Transport mode has fundamentally different issues, including survivability of transport sessions. >- Only the initiator can be behind a nat > > There are limited cases where the responder can also be behind a nat. However, the question is whether limitations in responder's location are due to design of if they are fundamental limitations caused by NATs. I think the latter. >- no simultaneous movement is supported > > Not sure how well initiator-decides affected this, but at least there's another fundamental issue at the bottom: without a home-agent or DNS or DHT like schemes we can not implement simultaneous movements. (Same applies to SHIM6 too, btw.) >Now, i can see that supporting those may increase the complexity of the >protocol >However, in addition, it seems that the protocol artificially imposes that >- failure detection, path exploration and path selection can only be >performed by the initiator (client) > > Well, it only means that the final decision is done by one party - not that the other party would be unable to be a part of an exploration process. Having said that, the exploration process in MOBIKE is very simple compared to some other cases, because we assumed bidirectional connectivity. >- it includes a couple of corner cases where the responder can change >its address for dealing with specific cases. >Wouldn't it be simpler to define a symmetric operation of the protocol >(without corner cases) and simply stating the three constraints above? > > I think we tried, but it didn't appear to be simpler. --jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 05:49:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETyxq-00088m-12 for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 05:49:58 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27934 for ; Mon, 24 Oct 2005 05:49:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 29D12FB28A; Mon, 24 Oct 2005 09:49:56 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 25A01FB280; Mon, 24 Oct 2005 09:49:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3F0D7FB281; Mon, 24 Oct 2005 09:49:53 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 2D4B1FB246 for ; Mon, 24 Oct 2005 09:49:52 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9000789848 for ; Mon, 24 Oct 2005 12:49:51 +0300 (EEST) Message-ID: <435CAE4B.6030105@piuha.net> Date: Mon, 24 Oct 2005 12:50:03 +0300 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] issue summary from wglc, take 3 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 Updated list: Technical issues with proposed text but some discussion may still be needed: 60 - addresses in ike sa_init/auth Technical issues without proposed text but discussion has converged (or is uncontroversial) 52 - security of address updates 51 - spi collisions Technical issues that have proposed text and discussion has converged 69 - rr requirements (aligning text to prior agreement on issues) 68 - minimal conformance requirements 67 - certain vs. possible changed address info 66 - imprecise explanation of what nat cases are not supported 63 - extensibility and payload (no changes needed) 61 - version number, again 57 - question about initiator decides (no text changes but input for design document) 56 - ingress filtering (we've already decided that unidirectional is not supported -- even with impacts to some ingress filtering cases) 55 - mobike scope and limitations 47 - more comments from mohan (or is some part still being discussed?) 45 - clarifications on security considerations 44 - nat changes and ike rekey Editorial comments without proposed text 64 - stephane's editorial issues 59 - tero's editorial comments (some text exists, not all) 58 - deleting an address (note: we are not reopening the discussion on diff/overwrite semantics. but there may be a clarification needed.) 54 - marcelo's editorial comments Editorial comments with proposed text 65 - jari's editorial issues (but make sure 59 is solved too) 62 - editorial comments from francis 53 - editorial comments from pete 50 - more editorial comments from maureen 49 - editorial comments from maureen 48 - editorial comments from james (mostly has text, but is some part missing?) 46 - question about additional addresses (has proposed text. note that there's a link to one of parts of issue 68) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 05:53:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETz0r-0000cH-Dn for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 05:53:05 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28075 for ; Mon, 24 Oct 2005 05:52:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 62457FB286; Mon, 24 Oct 2005 09:53:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0F915FB28A; Mon, 24 Oct 2005 09:53:00 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F1145FB28D; Mon, 24 Oct 2005 09:52:56 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id E2611FB281 for ; Mon, 24 Oct 2005 09:52:55 +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 j9O9nDaf014418; Mon, 24 Oct 2005 12:49:18 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 12:52:47 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 12:52:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 12:52:44 +0300 Message-ID: Thread-Topic: [Mobike] 68 - minimal conformance requirements Thread-Index: AcXXuRo2NhhdgI7SS5+rPQ8osKraIwAxNCgQ From: To: , X-OriginalArrivalTime: 24 Oct 2005 09:52:47.0322 (UTC) FILETIME=[B02F23A0:01C5D880] Subject: Re: [Mobike] 68 - minimal conformance requirements 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: > I checked issue #46 where we discussed this before. > The conclusion appeared to be that for the gateway the > current text is OK. On the client part I don't think we > decided anything. > > However, when thinking about this it seems that even > the gateway part is suspect. It is true that you don't > need the additional addresses on a gateway that is > a responder. However, if this gateway is working in > gateway-to-gateway mode and is an initiator towards > the peer gateway which has multiple addresses, then > we need it. > > We could try to describe all this, but I think the cost > of that is greater than simply saying that nodes that > conform to this specification need to be able to understand > the additional addresses. It is another matter what needs > to be sent. I think the problem can be fixed simply by changing "client" to "initiator" and "gateway" to "responder". > Here's a proposed text change: > > Note that both peers can have their own policies about what > addresses are acceptable to use. A minimal "mobile client" > could have a policy that says that only the responder's > address specified in local configuration is acceptable. This > kind of client does not have to send or process > ADDITIONAL_*_ADDRESS notifications. Similarly, a simple "VPN > gateway" that has only a single address, and is not going to > change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > > => > > Note that a node that has only a single address at any given > time does not need to send ADDITIONAL_*_ADDRESS > notifications, but all nodes that support this specification > must understand the reception of such notifications. However, > nodes MAY have their own policies about what addresses are > acceptable to use. IMHO this is even more confusing than the original text... Having a single address at any given time doesn't really have much to do with this paragraph. Even if a node has several addresses, it does not need to send ADDITIONAL_*_ADDRESS notifications if either (1) it doesn't want to use those addresses for IPsec traffic, or (2) the node is the initiator, and it does not want to use any other responder addresses. Furthermore, the responder does not have to understand ADDITIONAL_*_ADDRESS notifications (beyond treating them like any other unrecognized status notification; that is, ignoring them) if it's not going to change its address. How about rephrasing this as follows? Note that both peers can have their own policies about what addresses are acceptable to use, and certain types of policies may simplify implementation. For instance, if the responder has a single fixed address, it does need to process ADDITIONAL_*_ADDRESS notifications it receives (beyond ignoring unrecognized status notifications as already required in [IKEv2]). Furthermore, if the initiator has a policy saying that only the responder address specified in local configuration is acceptable, it does not have to send its own additional addresses to the responder (since the responder does not need them except when changing its own address). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:03:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzAs-0003j1-B3 for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:03:26 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28715 for ; Mon, 24 Oct 2005 06:03:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1174EFB289; Mon, 24 Oct 2005 10:03:23 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 85D70FB281; Mon, 24 Oct 2005 10:03:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A301FB286; Mon, 24 Oct 2005 10:03:19 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 79772FB280 for ; Mon, 24 Oct 2005 10:03:18 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D8E0089848; Mon, 24 Oct 2005 13:03:17 +0300 (EEST) Message-ID: <435CB172.8050403@piuha.net> Date: Mon, 24 Oct 2005 13:03:30 +0300 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] 68 - minimal conformance requirements 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: >IMHO this is even more confusing than the original text... Having >a single address at any given time doesn't really have much to do >with this paragraph. Even if a node has several addresses, it does >not need to send ADDITIONAL_*_ADDRESS notifications if either > >(1) it doesn't want to use those addresses for IPsec traffic, or >(2) the node is the initiator, and it does not want to use >any other responder addresses. > > Yes. >Furthermore, the responder does not have to understand >ADDITIONAL_*_ADDRESS notifications (beyond treating them like any >other unrecognized status notification; that is, ignoring them) >if it's not going to change its address. > > Yes -- as long as we are talking about a "responder" and not a "gateway". >How about rephrasing this as follows? > > Note that both peers can have their own policies about what > addresses are acceptable to use, and certain types of policies > may simplify implementation. For instance, if the responder > has a single fixed address, it does need to process > ADDITIONAL_*_ADDRESS notifications it receives (beyond > ignoring unrecognized status notifications as already required > in [IKEv2]). Furthermore, if the initiator has a policy saying > that only the responder address specified in local > configuration is acceptable, it does not have to send its own > additional addresses to the responder (since the responder > does not need them except when changing its own address). > > Works for me. Thanks. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:11:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzIN-00066X-5Q for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:11:11 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29102 for ; Mon, 24 Oct 2005 06:10:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0DD12FB28D; Mon, 24 Oct 2005 10:11:09 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E817EFB281; Mon, 24 Oct 2005 10:11:04 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3F751FB286; Mon, 24 Oct 2005 10:11:03 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 013E3FB246 for ; Mon, 24 Oct 2005 10:11:02 +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 j9OAAxhl008431 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2005 13:10:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9OAAxk4026434; Mon, 24 Oct 2005 13:10:59 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17244.45875.323161.655633@fireball.kivinen.iki.fi> Date: Mon, 24 Oct 2005 13:10:59 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <435CA9D9.5010207@piuha.net> References: <17239.28734.827449.444182@fireball.kivinen.iki.fi> <435B6A86.8050209@piuha.net> <17244.38165.742830.299119@fireball.kivinen.iki.fi> <435CA9D9.5010207@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min 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 Jari Arkko writes: > Tero Kivinen wrote: > > >I have really started to hate different variations in the protocol. > > > > > I hate that too, but is there something we can do in this > specific issue about that? Are you saying that your option > would not create a new variant? At least we take the IP-addresses from the same place regardless if there is NAT-T enabled or not. Testing whether the MOBIKE will take the IP-addresses from the correct packet is going to be painfull anyways (i.e. requires changing the IP-addresses during the exchange itself and so on). Not sure how big the real impact will be, but still would avoid it if possible. > >>Here's a suggested addition to the Security Considerations, > >>Section 6.5, after the fourth paragraph: > >> > >>The use of NO_NATS_ALLOWED will also disclose the > >>internal address to the peer, in case NAT was in the path. > >>However, this has relevance only if the node is configured to first > >>try with NO_NATS_ALLOWED and only then fallback to > >>the use of NAT traversal if that fails. > >> > >> > > > >NO_NATS_ALLOWED discloses the internal address to the WORLD, not to > >the peer. > > > > > Hm. I missed this. Why does it reveal the address to the world? > Because its sent in a too early IKE message that is not yet > encrypted? Yes, it is sent in the IKE_SA_INIT thus it is not encrypted nor authenticated. It will be authenticated at the end of IKE_AUTH phase, but not before that. It will not be encrypted at all, thus everybody along the path can see it. Moving it to the IKE_AUTH will get it encrypted, thus reading it requires man in the middle attack, and also changes the protocol so we can always take the IP address from the IKE_AUTH packet (no need to separate processing for NAT-T allowed or no NAT-T allowed). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:15:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzMt-0007Cl-D5 for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:15:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29288 for ; Mon, 24 Oct 2005 06:15:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 80478FB28D; Mon, 24 Oct 2005 10:15:46 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 534DAFB286; Mon, 24 Oct 2005 10:15:45 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ADB54FB289; Mon, 24 Oct 2005 10:15:43 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 26AE8FB281 for ; Mon, 24 Oct 2005 10:15:43 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4F12F89848; Mon, 24 Oct 2005 13:15:42 +0300 (EEST) Message-ID: <435CB45A.60102@piuha.net> Date: Mon, 24 Oct 2005 13:15:54 +0300 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: <17239.28734.827449.444182@fireball.kivinen.iki.fi> <435B6A86.8050209@piuha.net> <17244.38165.742830.299119@fireball.kivinen.iki.fi> <435CA9D9.5010207@piuha.net> <17244.45875.323161.655633@fireball.kivinen.iki.fi> In-Reply-To: <17244.45875.323161.655633@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 Tero, >Moving it to the IKE_AUTH will get it encrypted, thus reading it >requires man in the middle attack, and also changes the protocol so we >can always take the IP address from the IKE_AUTH packet (no need to >separate processing for NAT-T allowed or no NAT-T allowed). > > Hmm... OK, now I'm starting to like this better. Pasi? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:22:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzTi-0000u7-2p for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:22:54 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29623 for ; Mon, 24 Oct 2005 06:22:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D320CFB28E; Mon, 24 Oct 2005 10:22:52 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BC6CAFB289; Mon, 24 Oct 2005 10:22:50 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1DBB2FB28B; Mon, 24 Oct 2005 10:22:49 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 3670EFB286 for ; Mon, 24 Oct 2005 10:22:48 +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 j9OAJAdR017651; Mon, 24 Oct 2005 13:19:12 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 13:22:46 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 13:22:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 13:22:33 +0300 Message-ID: Thread-Topic: [Mobike] 65 - jari's editorial issues Thread-Index: AcXX4LaKmjys0TbyTjGgUetbY2F0yAAoxvNw From: To: , X-OriginalArrivalTime: 24 Oct 2005 10:22:46.0388 (UTC) FILETIME=[E082D340:01C5D884] Subject: Re: [Mobike] 65 - jari's editorial issues 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: > >>3.1. Basic Operation > >> > >2nd para: it would be useful to state early that ike exchange > >initiator decides the addresses to use for that exchange. Right > >now you only talk about IPsec addresses. I know this is part of > >ikev2, but the reader may not have the background to understand > >this. > > > > > MOBIKE solves this problem by taking a simple approach: the party > that initiated the IKE_SA ... > > => > > MOBIKE solves this problem by taking a simple approach > Firstly, for every IKE exchange, the initiator of that exchange > decides which addresses to use for IKE itself. Secondly, the > party that initiated the IKE_SA ... How about just adding "This approach applies to the addresses in the IPsec SAs; in the IKE_SA case, the exchange initiator can decide which addresses are used." to the end of that paragraph? > >>4.8. NAT Prohibition > >> > >This section would benefit from a message flow example. > > > >> The attackers in this threat can be either outsiders or > >> even one of > >> the IKEv2 peers. In usual VPN usage scenarios, attacks > >> by the peers > >> can be easily dealt with if the authentication performed in the > >> initial IKEv2 negotiation can be traced to persons who > >> can be held > >> responsible for the attack. This may not be the case in all > >> scenarios, particularly with opportunistic approaches to > >> security. > >> > >> > >s/persons/persons or devices/? Hmm... IMHO "held responsible" is something that mostly applies to people, and using it with devices doesn't sound too good to me.. BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:42:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzmI-0005XG-QF for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:42:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00688 for ; Mon, 24 Oct 2005 06:41:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 61F5BFB28A; Mon, 24 Oct 2005 10:42:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8DCF5FB283; Mon, 24 Oct 2005 10:42:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6282EFB286; Mon, 24 Oct 2005 10:42:00 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3EEE8FB281 for ; Mon, 24 Oct 2005 10:41:59 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 45DAA89848; Mon, 24 Oct 2005 13:41:58 +0300 (EEST) Message-ID: <435CBA82.9030109@piuha.net> Date: Mon, 24 Oct 2005 13:42:10 +0300 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] 65 - jari's editorial issues 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: >> MOBIKE solves this problem by taking a simple approach: the party >> that initiated the IKE_SA ... >> >>=> >> >> MOBIKE solves this problem by taking a simple approach >> Firstly, for every IKE exchange, the initiator of that exchange >> decides which addresses to use for IKE itself. Secondly, the >> party that initiated the IKE_SA ... >> >> > >How about just adding "This approach applies to the addresses >in the IPsec SAs; in the IKE_SA case, the exchange initiator can >decide which addresses are used." to the end of that paragraph? > > Sure. >>>>4.8. NAT Prohibition >>>> >>>> >>>> >>>This section would benefit from a message flow example. >>> >>> >>> >>>> The attackers in this threat can be either outsiders or >>>> even one of >>>> the IKEv2 peers. In usual VPN usage scenarios, attacks >>>> by the peers >>>> can be easily dealt with if the authentication performed in the >>>> initial IKEv2 negotiation can be traced to persons who >>>> can be held >>>> responsible for the attack. This may not be the case in all >>>> scenarios, particularly with opportunistic approaches to >>>> security. >>>> >>>> >>>> >>>> >>>s/persons/persons or devices/? >>> >>> > >Hmm... IMHO "held responsible" is something that mostly applies >to people, and using it with devices doesn't sound too good to me.. > > True. OTOH, the most likely case is that the person isn't really responsible, but his device has some malware. I'm not sure I have a better text suggestion for you. Let it be. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:42:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzmn-0005aE-Sb for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:42:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00709 for ; Mon, 24 Oct 2005 06:42:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C7A78FB293; Mon, 24 Oct 2005 10:42:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 445B0FB283; Mon, 24 Oct 2005 10:42:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A0C89FB28A; Mon, 24 Oct 2005 10:42:31 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 0BD8BFB281 for ; Mon, 24 Oct 2005 10:42:31 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2387D89848; Mon, 24 Oct 2005 13:42:30 +0300 (EEST) Message-ID: <435CBAA2.6010000@piuha.net> Date: Mon, 24 Oct 2005 13:42:42 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tuomas Aura , Tero Kivinen , Pasi Eronen , Mohan.Parthasarathy@nokia.com Cc: MOBIKE Mailing List Subject: [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 It seems that we now have the same understanding of this issue. I asked Tero to write some text for an implementation note. Here goes: Add to the end of Section 4.4 an indented implementation note as follows: Implementation note: In MOBIKE (and also in IKEv2) it is possible to have cases where the SPI, protocol and destination address may not be uniquely distinguish SA to be used for outgoing traffic. In those cases implementations need to have a direct pointer from the matched traffic selectors of the outgoing traffic to the outbound SA to be used. That is, it is not enough to store SPI, protocol, and destination address to the SPD-S, but some kind of unique identifier is also needed. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:43:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETznF-0005d9-TD for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:43:05 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00755 for ; Mon, 24 Oct 2005 06:42:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9F148FB28E; Mon, 24 Oct 2005 10:43:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 762F6FB286; Mon, 24 Oct 2005 10:43:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DEEE2FB28A; Mon, 24 Oct 2005 10:43:00 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 08FA9FB281 for ; Mon, 24 Oct 2005 10:43:00 +0000 (UTC) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9OAgqHG010460 for ; Mon, 24 Oct 2005 13:42:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 13:42:59 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 13:42:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 13:42:51 +0300 Message-ID: Thread-Topic: [Mobike] Issue 50: More editorial comments from Maureen (was: Comments on draft-ietf-mobike-protocol-03.txt) Thread-Index: AcXLVEMEjcmIMd/+TDq0gHbOes1bawNMy1kQ From: To: , X-OriginalArrivalTime: 24 Oct 2005 10:42:58.0378 (UTC) FILETIME=[B2E9D2A0:01C5D887] Subject: [Mobike] Issue 50: More editorial comments from Maureen (was: Comments on draft-ietf-mobike-protocol-03.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 Maureen Stillman wrote: > These comments are all editorial. > > 4.7 Changes in NAT Mappings > > In MOBIKE, these messages can also be used to detect if NAT mappings > have changed (for example, if the keepalive internal is > too long, or the NAT box is rebooted). > > I think you meant to say keepalive interval not keepalive internal. Yes, that's right... > 5. Payload formats > > 5.1 MOBIKE_SUPPORTED Notify Payload > > I think these headers and text should more closely match what is in > IKEv2. Also these messages should be split between what is an error, > 5.5 and 5.8, and what is a status message all the rest. This is also > how the split is done in IKEv2. See the template and text > below which I > stole from IKEv2. > > Here is the new suggested text: Hmm.. the Notify payload itself is defined in the IKEv2 spec, and IMHO we don't need to copy its definition here. Copying it might even be confusing, since it could give the impression we're defining a new payload. But I'll add some text to the beginning of section 5 to clarify this (including the error/status types distinction). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:43:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzo7-0005tG-Ev for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:43:59 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00833 for ; Mon, 24 Oct 2005 06:43:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 42CBDFB298; Mon, 24 Oct 2005 10:43:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 92FD3FB281; Mon, 24 Oct 2005 10:43:54 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 10CCEFB28E; Mon, 24 Oct 2005 10:43:52 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id EFDB6FB281 for ; Mon, 24 Oct 2005 10:43:50 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5DBEC89848 for ; Mon, 24 Oct 2005 13:43:50 +0300 (EEST) Message-ID: <435CBAF2.2070002@piuha.net> Date: Mon, 24 Oct 2005 13:44:02 +0300 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] issue summary from wglc, take 4 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 Updated list: Technical issues that are open: 60 - addresses in ike sa_init/auth Technical issues without proposed text but discussion has converged (or is uncontroversial) - Technical issues that have proposed text and discussion has converged 69 - rr requirements (aligning text to prior agreement on issues) 68 - minimal conformance requirements 67 - certain vs. possible changed address info 66 - imprecise explanation of what nat cases are not supported 63 - extensibility and payload (no changes needed) 61 - version number, again 57 - question about initiator decides (no text changes but input for design document) 56 - ingress filtering (we've already decided that unidirectional is not supported -- even with impacts to some ingress filtering cases) 55 - mobike scope and limitations 52 - security of address updates 51 - spi collisions 47 - more comments from mohan (or is some part still being discussed?) 45 - clarifications on security considerations 44 - nat changes and ike rekey Editorial comments without proposed text 64 - stephane's editorial issues 59 - tero's editorial comments (some text exists, not all) 58 - deleting an address (note: we are not reopening the discussion on diff/overwrite semantics. but there may be a clarification needed.) 54 - marcelo's editorial comments Editorial comments with proposed text 65 - jari's editorial issues (but make sure 59 is solved too) 62 - editorial comments from francis 53 - editorial comments from pete 50 - more editorial comments from maureen 49 - editorial comments from maureen 48 - editorial comments from james (mostly has text, but is some part missing?) 46 - question about additional addresses (has proposed text. note that there's a link to one of parts of issue 68) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 06:45:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETzpU-0006Ov-B9 for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 06:45:24 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00929 for ; Mon, 24 Oct 2005 06:45:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C31C0FB28F; Mon, 24 Oct 2005 10:45:22 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5FD8FFB28A; Mon, 24 Oct 2005 10:45:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E09C3FB28E; Mon, 24 Oct 2005 10:45:18 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 5BD7BFB281 for ; Mon, 24 Oct 2005 10:45:18 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B2D3089848; Mon, 24 Oct 2005 13:45:17 +0300 (EEST) Message-ID: <435CBB4A.4080304@piuha.net> Date: Mon, 24 Oct 2005 13:45:30 +0300 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: Maureen.Stillman@nokia.com, mobike@machshav.com Subject: Re: [Mobike] Issue 50: More editorial comments from Maureen (was: Comments on draft-ietf-mobike-protocol-03.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 >the Notify payload itself is defined in the IKEv2 spec, and IMHO >we don't need to copy its definition here. Copying it might even be >confusing, since it could give the impression we're defining a new >payload. > > Yes. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 07: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 1EU05I-0002SQ-Uw for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:01:45 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01786 for ; Mon, 24 Oct 2005 07:01:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1131AFB283; Mon, 24 Oct 2005 11:01:41 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id EF632FB280; Mon, 24 Oct 2005 11:01:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1A892FB281; Mon, 24 Oct 2005 11:01:37 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 3045BFB249 for ; Mon, 24 Oct 2005 11:01:36 +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 j9OB1YKO013407; Mon, 24 Oct 2005 14:01:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 14:01:35 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 14:01:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 14:01:36 +0300 Message-ID: Thread-Topic: issue 45 - clarifications to security considerations Thread-Index: AcXX1yH92js16QavS6Kb+ips/OFBzQAsgPwQ From: To: X-OriginalArrivalTime: 24 Oct 2005 11:01:34.0969 (UTC) FILETIME=[4C741690:01C5D88A] 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: > > I think the only thing that Mohan wanted to do was to > explain the condition of the attack that NO_NATS_ALLOWED > protects against. Here's the simple text modification: > > MOBIKE introduces the NO_NATS_ALLOWED notification that is used to > detect modification, by outsiders, of the addresses in the > IP header. > ... > > => > > MOBIKE introduces the NO_NATS_ALLOWED notification that is used to > detect modification, by outsiders, of the addresses in the > IP header. > Such modifications can only be performed by attackers who are on > the path and capable of modifying the IKEv2 and IPsec packets. This sounds redundant to me: it basically says that modifications can be performed only by attackers who can modify the packets...?? (And attacks by the IKE peer are discussed in section 6.3, not here) > Add the following text to the end of this paragraph: > > ... Such an attack could also be defeated by use of > negative acknowledgements, such as TCP RST and ICMP > errors. However, too eager reliance on such acknowledgements > has some denial-of-service issues itself. Also, many networks > filter ICMP messages, and in our case the lack of a valid SA > in the victim prevents TCP processing of incoming ESP packets. No, this is misleading: the victim sees only a bunch of ESP packets it cannot decrypt, and it doesn't even know who the real sender (e.g., TCP endpoint) is. And if you don't know that, where do you send the TCP RSTs or other negative acks? BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 07:05:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU08k-00031a-NC for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:05:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01916 for ; Mon, 24 Oct 2005 07:05:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A61B7FB28B; Mon, 24 Oct 2005 11:05:11 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D4980FB286; Mon, 24 Oct 2005 11:05:10 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0A52EFB289; Mon, 24 Oct 2005 11:05:08 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 25844FB283 for ; Mon, 24 Oct 2005 11:05:07 +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 j9OB1O4T006416; Mon, 24 Oct 2005 14:01:31 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 14:05:04 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 14:05:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 14:05:06 +0300 Message-ID: Thread-Topic: 51 - spi collisions Thread-Index: AcXYh9LNcTQB7R5oTOemnjoPhA7UfQAArLxA From: To: , X-OriginalArrivalTime: 24 Oct 2005 11:05:04.0988 (UTC) FILETIME=[C9A271C0:01C5D88A] 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 The basic idea in the text seems to be right, but IMHO we need much longer explanation than that (at least if we want people who didn't read the mailing list discussion to understand what the note says). I can try to write something (but not today)... BR, Pasi > -----Original Message----- > From: ext Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: 24 October, 2005 13:43 > To: Tuomas Aura; Tero Kivinen; Eronen Pasi > (Nokia-NRC/Helsinki); Parthasarathy Mohan (Nokia-NET/MtView) > Cc: MOBIKE Mailing List > Subject: 51 - spi collisions > > > It seems that we now have the same understanding of > this issue. I asked Tero to write some text for an > implementation note. Here goes: > > Add to the end of Section 4.4 an indented implementation > note as follows: > > Implementation note: In MOBIKE (and also in IKEv2) it is possible > to have cases where the SPI, protocol and destination address > may not be uniquely distinguish SA to be used for outgoing > traffic. In those cases implementations need to have a direct > pointer from the matched traffic selectors of the outgoing traffic > to the outbound SA to be used. That is, it is not enough > to store SPI, protocol, and destination address to the SPD-S, > but some kind of unique identifier is also needed. > > --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 07:15:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0Ib-0006GK-U6 for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:15:32 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02344 for ; Mon, 24 Oct 2005 07:15:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B05C9FB28B; Mon, 24 Oct 2005 11:15:28 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C991CFB280; Mon, 24 Oct 2005 11:15:26 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6D1B2FB283; Mon, 24 Oct 2005 11:15:24 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id DD7BDFB246 for ; Mon, 24 Oct 2005 11:15:23 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4300289848; Mon, 24 Oct 2005 14:15:22 +0300 (EEST) Message-ID: <435CC256.6020004@piuha.net> Date: Mon, 24 Oct 2005 14:15:34 +0300 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: tuomaura@microsoft.com, 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 wrote: >The basic idea in the text seems to be right, but IMHO we need >much longer explanation than that (at least if we want people >who didn't read the mailing list discussion to understand what >the note says). > >I can try to write something (but not today)... > > Would this text + a pointer to design draft be sufficient? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 07:18:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0LH-00070D-Sj for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:18:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02455 for ; Mon, 24 Oct 2005 07:18:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 76059FB28D; Mon, 24 Oct 2005 11:18:14 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E09D1FB28A; Mon, 24 Oct 2005 11:18:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F3F19FB28B; Mon, 24 Oct 2005 11:18:12 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 16FF4FB283 for ; Mon, 24 Oct 2005 11:18:11 +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 j9OBEXK0022016; Mon, 24 Oct 2005 14:14:35 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 14:18:10 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 14:18:09 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 14:18:13 +0300 Message-ID: Thread-Topic: [Mobike] 52 - security of address updates Thread-Index: AcXYdejNbqETv9xqTfeEvVekBRscdwAFeDGg From: To: , X-OriginalArrivalTime: 24 Oct 2005 11:18:09.0618 (UTC) FILETIME=[9D4F7B20:01C5D88C] Subject: Re: [Mobike] 52 - security of address updates 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: > There seems to be six issues: > > 1) Noting that mobike hosts are more vulnerable to various > attacks than static hosts, due to the variety of links they visit > > We can do this. Add this to Section 6, first paragraph, between > the first and second paragraphs: "Mobile nodes are also more > likely to encounter malicious environments, given the many > networks that they travel in." This text is confusing "mobile node" and "node implementing MOBIKE". E.g. my laptop is already a "mobile node", and visits malicious environments. Adding MOBIKE would make it less cumbersome for me (no need to find my SecurID token etc.), but it does not change the environment... can be used is another matter). > > 3) Defense 1: use NO_NATS_ALLOWED if on a public address > > This would be good to have as an option. Here's some > suggested text: > > Insert to 4.8, at the end of the 2nd paragraph: > > An initiator may also have a policy that if it > has an address that is know to be a public address, > it employs NO_NATS_ALLOWED. This prevents the > vulnerability to address changing attacks when > the node has an obviously public address. (However, > some firewalls may require UDP encapsulation > to be used even in such cases.) IMHO the leap from "public address" to "no NAT" is not correct. IKEv2 NAT-T does the right thing, and does not try to hard-code lists of addresses which are NATted: it's much better to just detect that. BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 07:21:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0OY-0007ll-Ad for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:21:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02628 for ; Mon, 24 Oct 2005 07:21:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9683DFB289; Mon, 24 Oct 2005 11:21:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 07DB5FB249; Mon, 24 Oct 2005 11:21:34 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 61631FB249; Mon, 24 Oct 2005 11:21:32 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id AA60DFB28A for ; Mon, 24 Oct 2005 11:21:31 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1540589848; Mon, 24 Oct 2005 14:21:31 +0300 (EEST) Message-ID: <435CC3C7.20202@piuha.net> Date: Mon, 24 Oct 2005 14:21:43 +0300 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 Pasi.Eronen@nokia.com wrote: >This sounds redundant to me: > > Ok, lets not add anything here then. >>Add the following text to the end of this paragraph: >> >> ... Such an attack could also be defeated by use of >> negative acknowledgements, such as TCP RST and ICMP >> errors. However, too eager reliance on such acknowledgements >> has some denial-of-service issues itself. Also, many networks >> filter ICMP messages, and in our case the lack of a valid SA >> in the victim prevents TCP processing of incoming ESP packets. >> >> > >No, this is misleading: the victim sees only a bunch of ESP >packets it cannot decrypt, and it doesn't even know who >the real sender (e.g., TCP endpoint) is. And if you don't know >that, where do you send the TCP RSTs or other negative acks? > > 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. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 07:27:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0UY-00019G-JQ for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:27:50 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02895 for ; Mon, 24 Oct 2005 07:27:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 425A0FB28D; Mon, 24 Oct 2005 11:27:48 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4B795FB283; Mon, 24 Oct 2005 11:27:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9AE0BFB289; Mon, 24 Oct 2005 11:27:44 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 902C2FB281 for ; Mon, 24 Oct 2005 11:27:43 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id DE0E889848; Mon, 24 Oct 2005 14:27:42 +0300 (EEST) Message-ID: <435CC53B.7010104@piuha.net> Date: Mon, 24 Oct 2005 14:27:55 +0300 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: Tuomas Aura , mobike@machshav.com Subject: Re: [Mobike] 52 - security of address updates 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 The first text appears to be correct (its the mobility, not MOBIKE support that makes you more likely to hit bad environments). But maybe that's a moot point if your opinion is that the heuristic for deciding about possible existence of NATs is too weak and likely to cause errors. It certainly can fail in the case of certain firewalls where it would be better to run NAT-T. I have some sympathy for this argument. This would mean not adding anything about this defensive policy to the document. What do others think? --Jari Pasi.Eronen@nokia.com wrote: >Jari Arkko wrote: > > >>There seems to be six issues: >> >>1) Noting that mobike hosts are more vulnerable to various >> attacks than static hosts, due to the variety of links they visit >> >> We can do this. Add this to Section 6, first paragraph, between >> the first and second paragraphs: "Mobile nodes are also more >> likely to encounter malicious environments, given the many >> networks that they travel in." >> >> > >This text is confusing "mobile node" and "node implementing MOBIKE". >E.g. my laptop is already a "mobile node", and visits malicious >environments. Adding MOBIKE would make it less cumbersome for me >(no need to find my SecurID token etc.), but it does not change >the environment... > > > can be used is another matter). > > >>3) Defense 1: use NO_NATS_ALLOWED if on a public address >> >> This would be good to have as an option. Here's some >> suggested text: >> >> Insert to 4.8, at the end of the 2nd paragraph: >> >> An initiator may also have a policy that if it >> has an address that is know to be a public address, >> it employs NO_NATS_ALLOWED. This prevents the >> vulnerability to address changing attacks when >> the node has an obviously public address. (However, >> some firewalls may require UDP encapsulation >> to be used even in such cases.) >> >> > >IMHO the leap from "public address" to "no NAT" is not correct. >IKEv2 NAT-T does the right thing, and does not try to hard-code >lists of addresses which are NATted: it's much better to just >detect that. > >BR, >Pasi > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 07:33:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0a6-0002VR-Qe for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:33:39 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03260 for ; Mon, 24 Oct 2005 07:33:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B1E23FB289; Mon, 24 Oct 2005 11:33:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D646BFB249; Mon, 24 Oct 2005 11:33:31 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2C24AFB28F; Mon, 24 Oct 2005 10:50:41 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 60255FB28D for ; Mon, 24 Oct 2005 10:50:40 +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 j9OAmLP3032598; Mon, 24 Oct 2005 13:48:22 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 13:50:36 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 13:50:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 13:50:33 +0300 Message-ID: Thread-Topic: [Mobike] Issue 49: Editorial comments from Maureen (was: Issue list status & plea for help) Thread-Index: AcXI+V2F9M9BShrSRBe2K28BNp0b5wPjt7Cw From: To: , X-OriginalArrivalTime: 24 Oct 2005 10:50:35.0890 (UTC) FILETIME=[C39C9D20:01C5D888] X-Mailman-Approved-At: Mon, 24 Oct 2005 11:33:30 +0000 Subject: [Mobike] Issue 49: Editorial comments from Maureen (was: Issue list status & plea for help) 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 James Kempf wrote:Subject: Re: [Mobike] Issue list status & plea for help > > Maureen, > > Yes, I noticed this as well. > > I'd suggest including it even earlier, in the abstract: > > ...MOBIKE allows hostst to update the (outer) IP > addresses associated with IKEv2 and **tunnel mode** IPsec > Security Associations... Ok with me (although the fact we're dealing with tunnel mode is already mentioned in Section 1: transport mode SAs don't have "outer (tunnel header)" addresses). BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 07:37:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU0df-0003jJ-Mm for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 07:37:16 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03442 for ; Mon, 24 Oct 2005 07:37:00 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 205FFFB28A; Mon, 24 Oct 2005 11:37:13 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3EB0DFB281; Mon, 24 Oct 2005 11:37:12 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3DD67FB283; Mon, 24 Oct 2005 11:37:09 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 37F05FB249 for ; Mon, 24 Oct 2005 11:37:08 +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 j9OBb5nI027092 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Oct 2005 14:37:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9OBb5mm024988; Mon, 24 Oct 2005 14:37:05 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17244.51041.847311.851279@fireball.kivinen.iki.fi> Date: Mon, 24 Oct 2005 14:37:05 +0300 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: 1 min Cc: mobike@machshav.com, tuomaura@microsoft.com, jari.arkko@piuha.net 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: > The basic idea in the text seems to be right, but IMHO we need > much longer explanation than that (at least if we want people > who didn't read the mailing list discussion to understand what > the note says). As this is only implementation hint and the same problem is already in the IKEv2 (i.e. the issue is not created by MOBIKE, it just might make it more common), I do not think we need too much text about 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 Oct 24 08:17:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1GP-0006me-FE for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 08:17:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06041 for ; Mon, 24 Oct 2005 08:17:03 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C48F5FB28A; Mon, 24 Oct 2005 12:17:15 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E31C5FB280; Mon, 24 Oct 2005 12:17:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7DD02FB281; Mon, 24 Oct 2005 12:17:12 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 747CDFB249 for ; Mon, 24 Oct 2005 12:17:11 +0000 (UTC) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9OCH4cJ000685; Mon, 24 Oct 2005 15:17:08 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:17:08 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:17:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 15:17:03 +0300 Message-ID: Thread-Topic: [Mobike] 55 - scope and limitations (marcelo's issue) Thread-Index: AcXX6bdg454G2n2UTJ6oTuT3MxW+wwAqurXg From: To: , X-OriginalArrivalTime: 24 Oct 2005 12:17:08.0464 (UTC) FILETIME=[DAA08700:01C5D894] Cc: mobike@machshav.com Subject: Re: [Mobike] 55 - scope and limitations (marcelo's issue) 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 a "slightly" edited version of the text. Does it look ok? -- 1.2. Scope and Limitations This document focuses on the main scenario outlined above, and supports only tunnel mode IPsec SAs. The mobility support in MOBIKE allows both parties to move, but does not provide a "rendezvous" mechanism that would allow simultaneous movement of both parties, or discovering the addresses when the IKE_SA is first established. This implies that MOBIKE is best suited for situations where the address of at least one endpoint is relatively stable, and can be discovered using existing mechanisms such as DNS (see Section 3.1). MOBIKE allows both parties to be multihomed; however, only one pair of addresses is used for an SA at a time. In particular, load balancing is beyond the scope of this specification. 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 paths. NATs introduce additional limitations beyond those listed above. For details, refer to Section 2.3. The base version of the MOBIKE protocol does not cover all potential future use scenarios, such as transport mode, application to securing SCTP, or optimizations desirable in specific circumstances. Future extensions may be defined later to support additional requirements. Readers are encouraged to consult the MOBIKE design document [Design] for further information and rationale behind these limitations. -- 3.1. Initial IKE Exchange The initiator is responsible for finding a working pair of addresses so that the initial IKE exchange can be carried out. Any information from MOBIKE extensions will only be available later, when the exchange has progressed far enough. Exactly how the addresses used for the initial exchange are discovered is beyond the scope of this specification; typical sources of information include local configuration and DNS. If either or both of the peers have multiple addresses, some combinations may not work. Thus, the initiator SHOULD try various source and destination address combinations when retransmitting the IKE_SA_INIT request. --- BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 08:25:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1OK-0000Mx-N5 for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 08:25:28 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06400 for ; Mon, 24 Oct 2005 08:25:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 79F2CFB28A; Mon, 24 Oct 2005 12:25:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AEC12FB280; Mon, 24 Oct 2005 12:25:25 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 41961FB281; Mon, 24 Oct 2005 12:25:24 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 73D47FB249 for ; Mon, 24 Oct 2005 12:25:23 +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 j9OCN8SD012133; Mon, 24 Oct 2005 15:23:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:25:22 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:25:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 15:25:16 +0300 Message-ID: Thread-Topic: [Mobike] 67 - certain vs. possible changed address info Thread-Index: AcXXyjBObczUsYXZQyKJWBPVXQOUPAAy7Qrw From: To: , X-OriginalArrivalTime: 24 Oct 2005 12:25:22.0864 (UTC) FILETIME=[014FFB00:01C5D896] Subject: Re: [Mobike] 67 - certain vs. possible changed address info 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 some suggested text: > > o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS > notifications is received. This means the peer's addresses may > have changed. > > => > > o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS > or NO_ADDITIONAL_ADDRESSES notifications is received. > This means > the peer's addresses may have changed. This is > particularly important > if the currently used address for peer is no longer in > the announced set of addresses. Looks good, I rephrased it slightly to this: o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS notifications is received. This means the peer's addresses may have changed. This is particularly important if the announced set of address no longer contains the currently used address. BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 08:25:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1OS-0000Nw-BM for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 08:25:36 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06409 for ; Mon, 24 Oct 2005 08:25:22 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 14D7FFB291; Mon, 24 Oct 2005 12:25:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8418CFB28D; Mon, 24 Oct 2005 12:25:32 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 59CE7FB28E; Mon, 24 Oct 2005 12:25:30 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 24E00FB283 for ; Mon, 24 Oct 2005 12:25:26 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id B64F289848; Mon, 24 Oct 2005 15:25:24 +0300 (EEST) Message-ID: <435CD2C1.1070005@piuha.net> Date: Mon, 24 Oct 2005 15:25:37 +0300 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] 55 - scope and limitations (marcelo's issue) 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 Pasi.Eronen@nokia.com wrote: >Here's a "slightly" edited version of the text. Does it look ok? > >-- > >1.2. Scope and Limitations > > This document focuses on the main scenario outlined above, and > supports only tunnel mode IPsec SAs. > > The mobility support in MOBIKE allows both parties to move, but does > not provide a "rendezvous" mechanism that would allow simultaneous > movement of both parties, or discovering the addresses when the > IKE_SA is first established. This implies that MOBIKE is best suited > for situations where the address of at least one endpoint is > relatively stable, and can be discovered using existing mechanisms > such as DNS (see Section 3.1). > > MOBIKE allows both parties to be multihomed; however, only one pair > of addresses is used for an SA at a time. In particular, load > balancing is beyond the scope of this specification. > > 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 paths. > > NATs introduce additional limitations beyond those listed above. For > details, refer to Section 2.3. > > The base version of the MOBIKE protocol does not cover all potential > future use scenarios, such as transport mode, application to securing > SCTP, or optimizations desirable in specific circumstances. Future > extensions may be defined later to support additional requirements. > > Readers are encouraged to consult the MOBIKE design document [Design] > for further information and rationale behind these limitations. > >-- > >3.1. Initial IKE Exchange > > The initiator is responsible for finding a working pair of addresses > so that the initial IKE exchange can be carried out. Any information > from MOBIKE extensions will only be available later, when the > exchange has progressed far enough. Exactly how the addresses used > for the initial exchange are discovered is beyond the scope of this > specification; typical sources of information include local > configuration and DNS. > > If either or both of the peers have multiple addresses, some > combinations may not work. Thus, the initiator SHOULD try various > source and destination address combinations when retransmitting the > IKE_SA_INIT request. > >--- > >BR, >Pasi > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 08:27:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1QC-0001RN-06 for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 08:27:24 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06464 for ; Mon, 24 Oct 2005 08:27:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C22FCFB289; Mon, 24 Oct 2005 12:27:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 94F50FB280; Mon, 24 Oct 2005 12:27:20 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 69B38FB281; Mon, 24 Oct 2005 12:27:18 +0000 (UTC) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 90495FB249 for ; Mon, 24 Oct 2005 12:27:17 +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 j9OCP0ex013873; Mon, 24 Oct 2005 15:25:02 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:27:14 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:27:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 15:27:08 +0300 Message-ID: Thread-Topic: [Mobike] 66 - imprecise explanation of what nat cases are notsupported Thread-Index: AcXXzxAz9TiEjgxLTa+GswFAF4scpwAxxnMg From: To: , X-OriginalArrivalTime: 24 Oct 2005 12:27:14.0150 (UTC) FILETIME=[43A4E060:01C5D896] Subject: Re: [Mobike] 66 - imprecise explanation of what nat cases are notsupported 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 some proposed text: > > "Does not fully support" means that no special effort is made to > support this functionality. However, if the alternative is losing > connectivity completely, the responder can still attempt to proceed > with the change, and depending on, e.g., the exact type of NAT, it > may succeed. However, analyzing the exact circumstances when this > will or will not work is not done in this document. > > => > > "Does not fully support" means that no special effort is made to > support this functionality. Responders may also be unaware of > NATs or specific types of NATs they are behind. However, when > a change has occurred that will cause a loss of connectivity, > MOBIKE responders will still attempt to inform the initiator of the > change. Depending on, e.g., the exact type of NAT, it may or may > not succeed. However, analyzing the exact circumstances when > this will or will not work is not done in this document. Works for me. BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 08:50:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU1mD-0008Gj-VU for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 08:50:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07637 for ; Mon, 24 Oct 2005 08:49:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9087CFB289; Mon, 24 Oct 2005 12:50:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BF0BDFB280; Mon, 24 Oct 2005 12:50:05 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7FD9AFB281; Mon, 24 Oct 2005 12:50:04 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id A7A20FB249 for ; Mon, 24 Oct 2005 12:50:03 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9OCnv1b030363; Mon, 24 Oct 2005 15:50:03 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:50:00 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 15:50:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 15:49:51 +0300 Message-ID: Thread-Topic: [Mobike] 44 - nat changes and ike rekey Thread-Index: AcXX2zmF/Sm7+TgAQ7iUeAqpjB2VIAAveJDg From: To: , X-OriginalArrivalTime: 24 Oct 2005 12:50:00.0162 (UTC) FILETIME=[71D9C420:01C5D899] Subject: Re: [Mobike] 44 - nat changes and ike rekey 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: > Text proposal: > > Section 4.4 > > The initiator receives a NAT_DETECTION_DESTINATION_IP > notification that does not match the previous UPDATE_SA_ADDRESSES > response (see Section 4.7 for a more detailed description). > > => > > The initiator receives a NAT_DETECTION_DESTINATION_IP > notification with a value that does not match the value in a > previous UPDATE_SA_ADDRESSES response (see Section 4.7 > for a more detailed description). > > Note that this may cause an extra address update when > IKE rekeying is in progress, because the > NAT_DETECTION_DESTINATION_IP > notification only contains a hash of the address and some > other values such as the SPIs which change upon IKE rekey. > Such an extra address update is harmless, however. Probably the "Changes in NAT Mappings" section is a better place for this text than 4.4. I rephrased it slightly as follows: Note that this approach to detecting NAT mapping changes may cause an extra address update when the IKE_SA is rekeyed. This is because the NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which change when performing rekeying. This unnecessary update is harmless, however. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 09:07:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU23S-0004iP-Sr for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 09:07:58 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08636 for ; Mon, 24 Oct 2005 09:07:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 97370FB28A; Mon, 24 Oct 2005 13:07:57 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 95660FB249; Mon, 24 Oct 2005 13:07:56 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 020BEFB283; Mon, 24 Oct 2005 13:07:53 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 9943EFB249 for ; Mon, 24 Oct 2005 13:07:50 +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 j9OD4Bu0031639; Mon, 24 Oct 2005 16:04:14 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 16:07:49 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 16:07:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 16:07:38 +0300 Message-ID: Thread-Topic: [Mobike] Issue 59: Editorial comments from Tero (was: Comments of draft-ietf-mobike-protocol-04.txt) Thread-Index: AcXXKr/hV75BuOcmThuX78Ab9Xc1wwBcPu5g From: To: X-OriginalArrivalTime: 24 Oct 2005 13:07:49.0753 (UTC) FILETIME=[EF606690:01C5D89B] Cc: mobike@machshav.com Subject: Re: [Mobike] Issue 59: Editorial comments from Tero (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 Jari Arkko wrote: > It was indeed intention that the return packet in step 3 > would be lost. We forgot to draw this in the flow, however. > I have used something like > > REQ > ------------------------------------------------> > RESP > /---------------------------------- > > elsewhere. But the real question is I guess step 4 > correctness. Yes, I actually thought that we could > switch to another request, but as you point out, > this is incorrect. Hmm... this means that we can't > piggyback the RR test/cookie2 all of a sudden. Oh > well, that means another roundtrip in this case. > Retransmit the step 3 packet to a different address, > then do an RR test separately. I edited it like this: (The initiator suspects a problem in the currently used address pair, and probes its liveness.) 3) (IP_I1:500 -> IP_R1:500) HDR, SK { N(NAT_DETECTION_*_IP) } --> (IP_I1:500 -> IP_R1:500) HDR, SK { N(NAT_DETECTION_*_IP) } --> ... (Eventually, the initiator gives up on the current address pair, and tests the other available address pair.) 4) (IP_I1:500 -> IP_R2:500) HDR, SK { N(NAT_DETECTION_*_IP) } <-- (IP_R2:500 -> IP_I1:500) HDR, SK { N(NAT_DETECTION_*_IP) } (This worked, and the initiator requests the peer to switch to new addresses.) 5) (IP_I1:500 -> IP_R2:500) HDR, SK { N(UPDATE_SA_ADDRESSES), N(NAT_DETECTION_*_IP), N(COOKIE2) } --> <-- (IP_R2:500 -> IP_I1:500) HDR, SK { N(NAT_DETECTION_*_IP), N(COOKIE2) } Does this look right? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 09:18:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2DN-0008Bp-0K for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 09:18:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09311 for ; Mon, 24 Oct 2005 09:17:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A5BF2FB289; Mon, 24 Oct 2005 13:18:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1B74CFB280; Mon, 24 Oct 2005 13:18:10 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C0996FB281; Mon, 24 Oct 2005 13:18:08 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id EBA20FB249 for ; Mon, 24 Oct 2005 13:18:07 +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 j9ODEUjp011779 for ; Mon, 24 Oct 2005 16:14:32 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 16:18:06 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 24 Oct 2005 16:18:06 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 24 Oct 2005 16:17:53 +0300 Message-ID: Thread-Topic: Protocol document update Thread-Index: AcXYnVdchLuMJdE8RSG06bSAXr5G1A== From: To: X-OriginalArrivalTime: 24 Oct 2005 13:18:06.0183 (UTC) FILETIME=[5ECC2770:01C5D89D] Subject: [Mobike] Protocol document update 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 an update to the protocol document. Until it appears in the I-D directory, a temporary copy and a diff is available from here: http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-05.txt http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-05-from-04.html Note that this version does not address all the issues we have (see issue list for current status). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 09:20:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2Fw-0000PO-SA for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 09:20:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09497 for ; Mon, 24 Oct 2005 09:20:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 65744FB289; Mon, 24 Oct 2005 13:20:51 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E4A44FB280; Mon, 24 Oct 2005 13:20:49 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 64399FB281; Mon, 24 Oct 2005 13:20:48 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id C3DD1FB249 for ; Mon, 24 Oct 2005 13:20:47 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 2AC8189848; Mon, 24 Oct 2005 16:20:47 +0300 (EEST) Message-ID: <435CDFBB.1020902@piuha.net> Date: Mon, 24 Oct 2005 16:20:59 +0300 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] 44 - nat changes and ike rekey 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: >Probably the "Changes in NAT Mappings" section is a better place >for this text than 4.4. I rephrased it slightly as follows: > > Note that this approach to detecting NAT mapping changes may cause an > extra address update when the IKE_SA is rekeyed. This is because the > NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which > change when performing rekeying. This unnecessary update is > harmless, however. > > Ok. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 24 09:21:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EU2Gt-00013T-1O for mobike-archive@megatron.ietf.org; Mon, 24 Oct 2005 09:21:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09516 for ; Mon, 24 Oct 2005 09:21:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C6BB2FB281; Mon, 24 Oct 2005 13:21:49 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 886BEFB249; Mon, 24 Oct 2005 13:21:46 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B6E15FB280; Mon, 24 Oct 2005 13:21:44 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 9C7DFFB246 for ; Mon, 24 Oct 2005 13:21:43 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D3BE389848; Mon, 24 Oct 2005 16:21:42 +0300 (EEST) Message-ID: <435CDFF3.7060400@piuha.net> Date: Mon, 24 Oct 2005 16:21:55 +0300 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 59: Editorial comments from Tero (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 Yes. Thanks. --Jari Pasi.Eronen@nokia.com wrote: >Jari Arkko wrote: > > > >>It was indeed intention that the return packet in step 3 >>would be lost. We forgot to draw this in the flow, however. >>I have used something like >> >> REQ >> ------------------------------------------------> >> RESP >> /---------------------------------- >> >>elsewhere. But the real question is I guess step 4 >>correctness. Yes, I actually thought that we could >>switch to another request, but as you point out, >>this is incorrect. Hmm... this means that we can't >>piggyback the RR test/cookie2 all of a sudden. Oh >>well, that means another roundtrip in this case. >>Retransmit the step 3 packet to a different address, >>then do an RR test separately. >> >> > >I edited it like this: > > (The initiator suspects a problem in the currently used address pair, > and probes its liveness.) > > 3) (IP_I1:500 -> IP_R1:500) > HDR, SK { N(NAT_DETECTION_*_IP) } --> > > (IP_I1:500 -> IP_R1:500) > HDR, SK { N(NAT_DETECTION_*_IP) } --> > > ... > > (Eventually, the initiator gives up on the current address pair, and > tests the other available address pair.) > > 4) (IP_I1:500 -> IP_R2:500) > HDR, SK { N(NAT_DETECTION_*_IP) } > > <-- (IP_R2:500 -> IP_I1:500) > HDR, SK { N(NAT_DETECTION_*_IP) } > > (This worked, and the initiator requests the peer to switch to new > addresses.) > > 5) (IP_I1:500 -> IP_R2:500) > HDR, SK { N(UPDATE_SA_ADDRESSES), > N(NAT_DETECTION_*_IP), > N(COOKIE2) } --> > > <-- (IP_R2:500 -> IP_I1:500) > HDR, SK { N(NAT_DETECTION_*_IP), > N(COOKIE2) } > >Does this look right? > >Best regards, >Pasi > > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 25 01:01:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUGwG-0000gn-Fe for mobike-archive@megatron.ietf.org; Tue, 25 Oct 2005 01:01:34 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19826 for ; Tue, 25 Oct 2005 01:01:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1F74EFB28E; Tue, 25 Oct 2005 05:01:26 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1E9F6FB280; Tue, 25 Oct 2005 05:01:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 233D1FB281; Tue, 25 Oct 2005 05:01:18 +0000 (UTC) Received: from smtp114.sbc.mail.mud.yahoo.com (smtp114.sbc.mail.mud.yahoo.com [68.142.198.213]) by machshav.com (Postfix) with SMTP id 4BD02FB249 for ; Tue, 25 Oct 2005 05:01:17 +0000 (UTC) Received: (qmail 54049 invoked from network); 25 Oct 2005 05:01:14 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.38 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 25 Oct 2005 05:01:14 -0000 Message-ID: <00fc01c5d921$210d6000$6801a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "Francis Dupont" References: <435B6295.5070205@piuha.net> Date: Mon, 24 Oct 2005 22:01:13 -0700 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 Mailing List Subject: Re: [Mobike] 63 - extensibility and payload 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 > > > > > >- about 4.4: if/when we'd like to extend the mechanism, two things > >seem to be interesting: > > - the capability to move to another addresses (than the addresses in > > the IP header of the message), for instance for network controlled > > mobility. > > - the capability to limit the update to a SA set (i.e., partial update). > >Both will be easier with a payload... > > > > > > I agree that there are potentially interesting extensions, > such as some kind of network control or limiting the SA > set. As we have decided earlier, these are indeed future > extensions and not a part of the initial base RFC. > > But lets talk about what design is best to accommodate for > such future extensions. In both cases that you mention, > it seems that the addition of a payload (with appropriate > previous capability negotiation) does the job. For instance, > if we would like to design a "limited SA set update" feature, > then in the IKE init phase we can find out if both peers support > that. Then, if this particular movement is a limited update, > we can include a new payload to that effect in the IKE > exchange that tells the peer about the move. > I agree that the new payload is the way to go. -mohan > Creating such payload now, however, would change the > design quite a bit and would imho make it hard to support > NATs. > > So, I would suggest that there are no text changes needed > for the current document. > > --Jari > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 25 01:17:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHBn-0007Hh-D8 for mobike-archive@megatron.ietf.org; Tue, 25 Oct 2005 01:17:35 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20619 for ; Tue, 25 Oct 2005 01:17:21 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DFBA5FB28D; Tue, 25 Oct 2005 05:17:30 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 42960FB289; Tue, 25 Oct 2005 05:17:29 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 16F70FB28A; Tue, 25 Oct 2005 05:17:28 +0000 (UTC) Received: from smtp111.sbc.mail.mud.yahoo.com (smtp111.sbc.mail.mud.yahoo.com [68.142.198.210]) by machshav.com (Postfix) with SMTP id 3FB05FB280 for ; Tue, 25 Oct 2005 05:17:27 +0000 (UTC) Received: (qmail 21614 invoked from network); 25 Oct 2005 05:17:26 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.38 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 25 Oct 2005 05:17:26 -0000 Message-ID: <010f01c5d923$646d13c0$6801a8c0@adithya> From: "Mohan Parthasarathy" To: , , References: Date: Mon, 24 Oct 2005 22:17:27 -0700 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 Subject: Re: [Mobike] 44 - nat changes and ike rekey 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: > > Text proposal: > > > > Section 4.4 > > > > The initiator receives a NAT_DETECTION_DESTINATION_IP > > notification that does not match the previous UPDATE_SA_ADDRESSES > > response (see Section 4.7 for a more detailed description). > > > > => > > > > The initiator receives a NAT_DETECTION_DESTINATION_IP > > notification with a value that does not match the value in a > > previous UPDATE_SA_ADDRESSES response (see Section 4.7 > > for a more detailed description). > > > > Note that this may cause an extra address update when > > IKE rekeying is in progress, because the > > NAT_DETECTION_DESTINATION_IP > > notification only contains a hash of the address and some > > other values such as the SPIs which change upon IKE rekey. > > Such an extra address update is harmless, however. > > Probably the "Changes in NAT Mappings" section is a better place > for this text than 4.4. I rephrased it slightly as follows: > > Note that this approach to detecting NAT mapping changes may cause an > extra address update when the IKE_SA is rekeyed. This is because the > NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which > change when performing rekeying. This unnecessary update is > harmless, however. > I am okay with this. Note we are talking about "Changes in NAT mappings". Is it okay for an implementation to implement just one of the two schemes 1) send NAT-D payloads in DPD messages, compare the response with the previou UPDATE_SA_ADDRESS response 2) send NAT-D payloads in DPD messages with UPDATE_SA_ADDRESSES -mohan > 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 Tue Oct 25 01:27:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHLE-0002QU-CY for mobike-archive@megatron.ietf.org; Tue, 25 Oct 2005 01:27:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20820 for ; Tue, 25 Oct 2005 01:27:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 38E17FB28F; Tue, 25 Oct 2005 05:27:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B729FFB28D; Tue, 25 Oct 2005 05:27:15 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1EA0FFB28D; Tue, 25 Oct 2005 05:27:14 +0000 (UTC) Received: from smtp102.sbc.mail.mud.yahoo.com (smtp102.sbc.mail.mud.yahoo.com [68.142.198.201]) by machshav.com (Postfix) with SMTP id 0B38CFB289 for ; Tue, 25 Oct 2005 05:27:13 +0000 (UTC) Received: (qmail 23108 invoked from network); 25 Oct 2005 05:27:12 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.38 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 25 Oct 2005 05:27:12 -0000 Message-ID: <012b01c5d924$c18fbd40$6801a8c0@adithya> From: "Mohan Parthasarathy" To: , , References: Date: Mon, 24 Oct 2005 22:27:13 -0700 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 Subject: Re: [Mobike] 68 - minimal conformance requirements 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 checked issue #46 where we discussed this before. > > The conclusion appeared to be that for the gateway the > > current text is OK. On the client part I don't think we > > decided anything. > > > > However, when thinking about this it seems that even > > the gateway part is suspect. It is true that you don't > > need the additional addresses on a gateway that is > > a responder. However, if this gateway is working in > > gateway-to-gateway mode and is an initiator towards > > the peer gateway which has multiple addresses, then > > we need it. > > > > We could try to describe all this, but I think the cost > > of that is greater than simply saying that nodes that > > conform to this specification need to be able to understand > > the additional addresses. It is another matter what needs > > to be sent. > > I think the problem can be fixed simply by changing "client" > to "initiator" and "gateway" to "responder". > > > Here's a proposed text change: > > > > Note that both peers can have their own policies about what > > addresses are acceptable to use. A minimal "mobile client" > > could have a policy that says that only the responder's > > address specified in local configuration is acceptable. This > > kind of client does not have to send or process > > ADDITIONAL_*_ADDRESS notifications. Similarly, a simple "VPN > > gateway" that has only a single address, and is not going to > > change it, does not need to send or understand > > ADDITIONAL_*_ADDRESS notifications. > > > > => > > > > Note that a node that has only a single address at any given > > time does not need to send ADDITIONAL_*_ADDRESS > > notifications, but all nodes that support this specification > > must understand the reception of such notifications. However, > > nodes MAY have their own policies about what addresses are > > acceptable to use. > > IMHO this is even more confusing than the original text... Having > a single address at any given time doesn't really have much to do > with this paragraph. Even if a node has several addresses, it does > not need to send ADDITIONAL_*_ADDRESS notifications if either > > (1) it doesn't want to use those addresses for IPsec traffic, or > (2) the node is the initiator, and it does not want to use > any other responder addresses. > > Furthermore, the responder does not have to understand > ADDITIONAL_*_ADDRESS notifications (beyond treating them like any > other unrecognized status notification; that is, ignoring them) > if it's not going to change its address. > > How about rephrasing this as follows? > > Note that both peers can have their own policies about what > addresses are acceptable to use, and certain types of policies > may simplify implementation. For instance, if the responder > has a single fixed address, it does need to process > ADDITIONAL_*_ADDRESS notifications it receives (beyond > ignoring unrecognized status notifications as already required > in [IKEv2]). Furthermore, if the initiator has a policy saying In section 4.5, it talks about how a responder can try a different address for its peer. The responder itself has only one address but it can try different peer addresses. Or Are you saying that the policy says don't try different peer addresses ? > that only the responder address specified in local > configuration is acceptable, it does not have to send its own > additional addresses to the responder (since the responder > does not need them except when changing its own address). > This is still confusing to me :-) -mohan > 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 Tue Oct 25 01:33:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUHR7-0004A6-MZ for mobike-archive@megatron.ietf.org; Tue, 25 Oct 2005 01:33:27 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21089 for ; Tue, 25 Oct 2005 01:33:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3EB5CFB297; Tue, 25 Oct 2005 05:33:23 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 58B4FFB28D; Tue, 25 Oct 2005 05:33:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E5CEAFB293; Tue, 25 Oct 2005 05:33:18 +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 063B6FB28A for ; Tue, 25 Oct 2005 05:33:18 +0000 (UTC) Received: (qmail 74911 invoked from network); 25 Oct 2005 05:33:17 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.38 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 25 Oct 2005 05:33:17 -0000 Message-ID: <013f01c5d925$9b115970$6801a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , References: <435CC256.6020004@piuha.net> Date: Mon, 24 Oct 2005 22:33:17 -0700 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: tuomaura@microsoft.com, 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 wrote: > > >The basic idea in the text seems to be right, but IMHO we need > >much longer explanation than that (at least if we want people > >who didn't read the mailing list discussion to understand what > >the note says). > > > >I can try to write something (but not today)... > > > > > > Would this text + a pointer to design draft be sufficient? > 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. -mohan > --Jari > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Oct 25 11:09:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUQQk-0005Bd-Lk for mobike-archive@megatron.ietf.org; Tue, 25 Oct 2005 11:09:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27579 for ; Tue, 25 Oct 2005 11:09:21 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1B50DFB28A; Tue, 25 Oct 2005 15:09:34 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9D893FB280; Tue, 25 Oct 2005 15:09:27 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4EBECFB281; Tue, 25 Oct 2005 15:09:25 +0000 (UTC) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.136.122]) by machshav.com (Postfix) with ESMTP id 63B18FB24A for ; Tue, 25 Oct 2005 15:09:23 +0000 (UTC) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 150C583875; Tue, 25 Oct 2005 17:09:22 +0200 (CEST) Received: from [163.117.139.52] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.52]) by smtp02.uc3m.es (Postfix) with ESMTP id 9A5958385B; Tue, 25 Oct 2005 17:09:21 +0200 (CEST) In-Reply-To: <435BB18C.3090100@piuha.net> References: <435BB18C.3090100@piuha.net> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <50f83187e0e941d36fd916d77e40c92b@it.uc3m.es> From: marcelo bagnulo braun Date: Tue, 25 Oct 2005 17:09:35 +0200 To: Jari Arkko X-Mailer: Apple Mail (2.623) Cc: MOBIKE Mailing List , Tero Kivinen Subject: Re: [Mobike] 55 - scope and limitations (marcelo's issue) 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com Content-Transfer-Encoding: quoted-printable Hi Jari, i think that the proposed text looks good. just a couple of clarifications, not really expecting to change the = text, but just to explain some points... El 23/10/2005, a las 17:51, Jari Arkko escribi=F3: > > Thanks again Marcelo for your comments. This is > very useful. There was really a number of subissues: > > 1) Are multiple address pairs allowed? > 2) Are unidirectional address pairs allowed? > 3) Multihoming for the establishment phase v.s only later? > 3b) If MOBIKE retries in establishment phase, does it vary source = > address? > 4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR > 5) Is simultaneous movement supported? > 6) Are only local failures supported? > > I think the consensus has been that we don't want to go > too much in to the reasons of why something is the way > it is in this document (that's the job of the design document). > However, we do need to describe the limitations. > > I'll first go through Marcelo's items from above and try > to explain what I think the situation is. At the end I'll > have suggested text for a new limitations section. > > 1) Are multiple address pairs allowed? > > Yes. Multiple pairs are allowed. Their simultaneous use for > payload traffic is, however, outside the scope of the document, > and would probably need extra mechanisms (e.g. ensure its different > TCP streams) to work well. > > 2) Are unidirectional address pairs allowed? > > No. Explicit design decision to make things easy. > > 3) Multihoming for the establishment phase v.s only later? > > MOBIKE is for later phases only, but we can provide some > guidance on what (limited) things can be done in the > establishment phase. > > 3b) If MOBIKE retries in establishment phase, does it vary source = > address? > > It should. I'm a bit scared here to step on the area that your > future enhanced RFC 3484 version will say, though. Technically, > these are components; when 3484bis is available things sudddenly > start working better. > > But I'll suggest something vague about this. > > 4) Initiator vs. responder behind NAT limitations and ADDITIONAL_*_ADDR > > This isn't an issue, really, but rather a misunderstanding of > the text. There's no problem when the initiator (behind NAT) decides = > to use > new addresses. The problem is when the responder moves; some > NAT types don't allow this, and it may even be that the addresses > provided for this emergency in ADDITIONAL_*_ADDRESS are > internal, and not reachable by peer. > > I'd say no text changes. > > 5) Is simultaneous movement supported? > > No. Needs to be documented. > > 6) Are only local failures supported? > > No. MOBIKE, like SHIM6, supports both lower layers telling > you that the link went away as well as experienced failures > in IP communication (IKE DPD vs. SHIM6 reachability packets > not getting through). > my point here is that the only tool that seems to be available to = mobike is to change the address used for the communication. This is clearly enough to address local failures but it is not clear = that this is good enough to deal with other failure modes. In shim, changing the source address is assumed to result in exploring = different exit paths (from the multihomed site) this is the case when the source address affects somehow the exit path, = which is coherent with the existance of some form of ingress filtering = capability in the multihomed site. So, either you assume some form of source address dependent routing so = that changing the source address result in different exit paths or the = host don't really have the capability of forcing the exit path, so it = is probably that it won't be able to cope with remote failures in = general (in particular in failures in the egress paths) > Ok. So here's an attempt at some new text for Section 1.1, > what used to be 3.4 Limitations: > this text looks good > 1.1 Limitations > > This document focuses on the main scenario outlined above, and > supports only tunnel mode. > > The mobility support in MOBIKE allows either party to move, > but not both at the same time. This implies that MOBIKE is best > suited for client - gateway or gateway - gateway applications. Two > mobile clients would find it hard to use MOBIKE directly between > themselves, and for such applications a gateway is recommended > between the communicating clients. > > The multihoming support in MOBIKE allows either party to have > multiple addresses. This specification does not guarantee that > more than pair of such addresses can be used for payload traffic > at any one time, however. This implies that load-balancing = > applications > are out of scope in the base protocol. Similarly, due to the nature > of the IKEv2 protocol and NAT considerations, MOBIKE is only = > guaranteed > to work correctly over bidirectionally operational address pairs. > That is, the same pair of addresses is used in both directions. = > Indeed, > the protocol mechanisms used to determine reachability of the > peer ensure that such a pair is in use. > > The MOBIKE protocol can only be used once the IKE SAs have > been established. This implies that movements or additional > addresses for the peer can not be discovered until a working > connection to the peer has been established. This implies that > the IKE SA establishment phase has limitations with regards to > initial discovery of alternative addresses, unless those addresses > are known in the configuration and/or DNS. For details, see > Section 4.0. > > NATs introduce additional limitations beyond those listed above. > For details, refer to Section 3.3. > > The base version of the MOBIKE protocol may also not cover all = > potential > future use scenarios, such as transport mode, application to securing > SCTP, or optimizations desirable in specific circumstances. Future > extensions may be defined later to support additional requirements. > > And a new Section 4.0 between 4. and 4.1: > > 4.0 Addresses for the Initial IKE Exchange > > The initiator is responsible for finding a working pair of > addresses so that the initial IKE exchange can be carried > out. Any information from MOBIKE extensions will only be > available later, when the exchange has progressed far enough. > > IKE initiator may retrieve the peer address(es) from various > sources, such as the outgoing packet that triggered the > IKE exchange, configuration, or DNS. Similarly, the initiator > knows its own address(es). > If multiple peer addresses are known, the initiator SHOULD > vary the destination address in retranmissions, in case the > address used in the first attempt is inoperational. Similarly, > if these addresses do not appear to respond, the initiator > MAY vary the source address it uses for itself, in case there i would suggest a SHOULD here regards, marcelo > is a problem in a particular address prefix or the failure is > due to an ingress filtering problem. > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 03:37:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUfqo-0001eV-Oh for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 03:37:34 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29982 for ; Wed, 26 Oct 2005 03:37:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 82C56FB28B; Wed, 26 Oct 2005 07:37:31 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9FAD9FB280; Wed, 26 Oct 2005 07:37:28 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7A5B6FB285; Wed, 26 Oct 2005 07:37:26 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id B4E8BFB262 for ; Wed, 26 Oct 2005 07:37:25 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 5E1C089848 for ; Wed, 26 Oct 2005 10:37:24 +0300 (EEST) Message-ID: <435F3240.8030904@piuha.net> Date: Wed, 26 Oct 2005 10:37:36 +0300 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] 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 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 (Pasi Eronen) http://www.vpnc.org/ietf-org/draft-ietf-mobike-protocol-06.txt (to appear) - Discussion of remaining last call issue resolutions, if any - We intend to close everything before Vancouver and once the document submission re-opens, submit and send the draft to the ADs Design Draft (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 (Please submit agenda requests. Transport, SCTP, API, etc?) Discussion of next steps (chairs) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 04:56:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUh5P-0006Ef-CE for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 04:56:43 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05104 for ; Wed, 26 Oct 2005 04:56:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 785A4FB28A; Wed, 26 Oct 2005 08:56:40 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9AA32FB280; Wed, 26 Oct 2005 08:56:39 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94F0CFB285; Wed, 26 Oct 2005 08:56:37 +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 64FD1FB262 for ; Wed, 26 Oct 2005 08:56:36 +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 j9Q8uNA12788; Wed, 26 Oct 2005 10:56:23 +0200 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 j9Q8uNWU012345; Wed, 26 Oct 2005 10:56:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510260856.j9Q8uNWU012345@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Wed, 26 Oct 2005 10:37:36 +0300. <435F3240.8030904@piuha.net> Date: Wed, 26 Oct 2005 10:56:23 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List 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: Extensions and New Work (Please submit agenda requests. Transport, SCTP, API, etc?) => I don't believe it is very useful to discuss about the transport mode/Mobike I-D (according to comments about it in the list, BTW the I-D does not address issue #7). For SCTP it is clear there is something to do but not so clear what... BTW is the RFC 3554 supported? (if it is we should get the feedback from an implementor) For multi-homing in general I believe we should reconsider the issues #8 and #20. Of course the issue #63 could apply. (who should present this? IMHO we mainly need a discussion) Regards Francis.Dupont@enst-bretagne.fr PS: http://www.vpnc.org/ietf-mobike/issues.html _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 07:34:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjXk-0002wo-Uy for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 07:34:09 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12779 for ; Wed, 26 Oct 2005 07:33:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 21855FB28A; Wed, 26 Oct 2005 11:34:06 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2A0ACFB280; Wed, 26 Oct 2005 11:34:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D5FD9FB285; Wed, 26 Oct 2005 11:34:00 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id B66CBFB262 for ; Wed, 26 Oct 2005 11:33:59 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1044C89848; Wed, 26 Oct 2005 14:33:58 +0300 (EEST) Message-ID: <435F69B3.3010800@piuha.net> Date: Wed, 26 Oct 2005 14:34:11 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont References: <200510260856.j9Q8uNWU012345@givry.rennes.enst-bretagne.fr> In-Reply-To: <200510260856.j9Q8uNWU012345@givry.rennes.enst-bretagne.fr> Cc: MOBIKE Mailing List 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 wrote: >=> I don't believe it is very useful to discuss about the >transport mode/Mobike I-D (according to comments about it in >the list, BTW the I-D does not address issue #7). > >For SCTP it is clear there is something to do but not so clear what... >BTW is the RFC 3554 supported? (if it is we should get the feedback >from an implementor) > >For multi-homing in general I believe we should reconsider >the issues #8 and #20. Of course the issue #63 could apply. >(who should present this? IMHO we mainly need a discussion) > > The transport draft does not have too many details. We do not have a written proposal on the table for SCTP support nor issue #8 extension of MOBIKE*. However, as we are progressing with the base protocol we now have some possibilities to discuss future things. I think we should use this opportunity now, and if you think some of the above issues are important, I would recommend reserving a slot to talk about it. It may require some preparation from you, however, such as figuring out what the SCTP implementation situation is or what issues are in providing additional IPsec/MOBIKE support for SCTP. Obviously, drafts and details are going to be needed at some point, but what we actually wanted to talk about in the meeting, I think, is more about the requirements more than the bits. What do we want to achieve? Who would use that, and would it fall within our job or somewhere else? Details would also be useful in order to get an understanding of what functionality X would mean in terms of the bits, but they are not an absolute requirement. --Jari *) I don't think #8 extension needs #20, and personally I'd rather not see #20 changed. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 07:35:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUjYj-0003EK-Mu for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 07:35:09 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12821 for ; Wed, 26 Oct 2005 07:34:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 792BBFB292; Wed, 26 Oct 2005 11:35:07 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 008E5FB28A; Wed, 26 Oct 2005 11:35:03 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C4938FB28B; Wed, 26 Oct 2005 11:35:01 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id DC918FB289 for ; Wed, 26 Oct 2005 11:34:59 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 429E389848 for ; Wed, 26 Oct 2005 14:34:59 +0300 (EEST) Message-ID: <435F69EF.4090307@piuha.net> Date: Wed, 26 Oct 2005 14:35:11 +0300 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] MOBIKE WG Agenda for IETF-64, take 2 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 (Pasi Eronen) http://www.vpnc.org/ietf-org/draft-ietf-mobike-protocol-06.txt (to appear) - Discussion of remaining last call issue resolutions, if any - We intend to close everything before Vancouver and once the document submission re-opens, submit and send the draft to the ADs Design Draft (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 (Hannes Tschofenig) http://www.tschofenig.com/drafts/draft-schilcher-mobike-pfkey-extension-01.txt Application Programming Interface to a Trigger Database for MOBIKE (Hannes Tschofenig) http://www.tschofenig.com/drafts/draft-schilcher-mobike-trigger-api-02.txt (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 Wed Oct 26 08:39:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUkZQ-0004TD-Q0 for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 08:39:56 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16157 for ; Wed, 26 Oct 2005 08:39:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6D741FB289; Wed, 26 Oct 2005 12:39:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 09AF3FB280; Wed, 26 Oct 2005 12:39:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 93F7FFB285; Wed, 26 Oct 2005 12:39:50 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 7A781FB262 for ; Wed, 26 Oct 2005 12:39:49 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C1A5489848 for ; Wed, 26 Oct 2005 15:39:47 +0300 (EEST) Message-ID: <435F791F.1060806@piuha.net> Date: Wed, 26 Oct 2005 15:39:59 +0300 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 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 We now have a new draft version 05 available (see links [1] and [2]). Pasi worked hard on the edits, and there was good discussion on the list. But we did not quite get all issues resolved in time for the I-D deadline. Therefore, the plan is to produce version 06 just before IETF and submit it for AD review and IESG either during or right after the meeting. At this time I'd like to call some issues closed and invite (a) further discussion on the remaining issues so that we can get them resolved and (b) review that your issues have been correctly resolved in -05. We are very close to getting everything agreed on, so we're setting a new deadline on Wednesday 2nd Nov (next week) to complete all discussion about the resolutions of issues raised in WGLC. The issue list is at [3]. The issues that I believe still need further discussion are 68 - minimal conformance requirements 60 - addresses in ike sa_init/auth 56 - ingress filtering 51 - spi collisions 46 - question about additional addresses 45 - clarifications on security considerations These also need editing: 64 - stephane's editorial issues (just needs editing?) 58 - deleting an address (just needs editing, we're not reopening old issue) 54 - marcelo's editorial comments 52 - security of address updates The closed issues are as follows. (Of course, these would benefit from their submitters checking correct implementation in -05.) 69 - rr requirements 67 - certain vs. possible changed address info 66 - imprecise explanation of what nat cases are not supported 65 - jari's editorial issues 63 - extensibility and payload 62 - editorial comments from francis 61 - version number, again 59 - tero's editorial comments (Tero - please check -05) 57 - question about initiator decides (I think the feeling was that nothing will be added to the protocol document, but Pasi's list marked this as open. Pasi?) 55 - mobike scope and limitations (Everyone - please check -05; Pasi I think you mark this as closed because people were agreeing to the text) 53 - editorial comments from pete 50 - more editorial comments from maureen 47 - more comments from mohan (Mohan - please check -05) 49 - editorial comments from maureen 48 - editorial comments from james 44 - nat changes and ike rekey (Pasi I think people were agreeing to the text) Let us know if something was misclassified above... Pointers: [1] http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-05.txt [2] http://people.nokia.net/~pasi/draft-ietf-mobike-protocol-05-from-04.html [3] http://www.vpnc.org/ietf-mobike/issues.html _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 09:36:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlSP-00041Q-IH for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 09:36:45 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19851 for ; Wed, 26 Oct 2005 09:36:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9FDBFFB289; Wed, 26 Oct 2005 13:36:43 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1DE1CFB280; Wed, 26 Oct 2005 13:36:42 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 43A82FB285; Wed, 26 Oct 2005 13:36:40 +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 8EAF0FB262 for ; Wed, 26 Oct 2005 13:36: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 j9QDaUA05570; Wed, 26 Oct 2005 15:36:30 +0200 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 j9QDaUol013607; Wed, 26 Oct 2005 15:36:30 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510261336.j9QDaUol013607@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko In-reply-to: Your message of Wed, 26 Oct 2005 14:34:11 +0300. <435F69B3.3010800@piuha.net> Date: Wed, 26 Oct 2005 15:36:30 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List 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: >=> I don't believe it is very useful to discuss about the >transport mode/Mobike I-D (according to comments about it in >the list, BTW the I-D does not address issue #7). > >For SCTP it is clear there is something to do but not so clear what... >BTW is the RFC 3554 supported? (if it is we should get the feedback >from an implementor) > >For multi-homing in general I believe we should reconsider >the issues #8 and #20. Of course the issue #63 could apply. >(who should present this? IMHO we mainly need a discussion) The transport draft does not have too many details. => it doesn't need to get more details (:-). What do you want which is not in issue #7? We do not have a written proposal on the table for SCTP support nor issue #8 extension of MOBIKE*. => for SCTP we have to know what is really need. For the issue #8 the proposal is to simply add the list of IKE and IPsec SAs to update with a simpler form which updates every SAs (as we already have). However, as we are progressing with the base protocol we now have some possibilities to discuss future things. I think we should use this opportunity now, and if you think some of the above issues are important, I would recommend reserving a slot to talk about it. => I believe this was implied by my answer to the agenda call? It may require some preparation from you, however, such as figuring out what the SCTP implementation situation is or what issues are in providing additional IPsec/MOBIKE support for SCTP. => I prefer we get first feedback for RFC 3554 implementors: IMHO if nobody has implemented it and nobody cares, it is the sign the RFC 3554 way is wrong. Obviously, drafts and details are going to be needed at some point, but what we actually wanted to talk about in the meeting, I think, is more about the requirements more than the bits. => this is why I've begun with old issues which are about design choice, i.e., requirements. What do we want to achieve? Who would use that, and would it fall within our job or somewhere else? Details would also be useful in order to get an understanding of what functionality X would mean in terms of the bits, but they are not an absolute requirement. => I agree: it depends on the case. *) I don't think #8 extension needs #20, and personally I'd rather not see #20 changed. => the "initiator decides" is very bad for multi-homing and full freedom can become too easily full mess. My idea is to split between initial and update: - initial IKE SA addresses are the addresses used in initial exchanges (IKE_SA_INIT and IKE_AUTH) - initial IPsec SA addresses are the addresses of the IKE SA which creates it at the creation time - updates can change any IKE SA or IPsec SA pair addresses (the new remote one has to be in the set declared by the peer). etc. IMHO this setup then move is enough and simple enough to be well understood. 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 Wed Oct 26 12:59:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUocQ-00022j-2S for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 12:59:19 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07315 for ; Wed, 26 Oct 2005 12:59:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 35FF0FB289; Wed, 26 Oct 2005 16:59:16 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ADE59FB262; Wed, 26 Oct 2005 16:59:14 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 371B7FB284; Wed, 26 Oct 2005 16:59:12 +0000 (UTC) Received: from web80606.mail.yahoo.com (web80606.mail.yahoo.com [66.218.79.95]) by machshav.com (Postfix) with SMTP id 6BF1AFB24A for ; Wed, 26 Oct 2005 16:59:11 +0000 (UTC) Received: (qmail 28789 invoked by uid 60001); 26 Oct 2005 16:59:10 -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=6DsHSvNMOEwoo0Hgery9t8oCksb/IyY6ECudaW51LwZKTgjdgJ3BR2Lzx9MdJGyXPLlrc5TyGcGnsvpNyV8kVek4D33ugn4Kg5oi+aCKlrbPa/HUTr5OItytbtvCdz+QUpMjIIfumkQFZVRvR76BTWpz+9X3PHkg7yzCsz3bTs4= ; Message-ID: <20051026165910.28787.qmail@web80606.mail.yahoo.com> Received: from [206.132.194.3] by web80606.mail.yahoo.com via HTTP; Wed, 26 Oct 2005 09:59:10 PDT Date: Wed, 26 Oct 2005 09:59:10 -0700 (PDT) From: Mohan Parthasarathy To: Jari Arkko , Francis Dupont In-Reply-To: <435F69B3.3010800@piuha.net> MIME-Version: 1.0 Cc: MOBIKE Mailing List 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 --- Jari Arkko wrote: > Francis Dupont wrote: > > >=> I don't believe it is very useful to discuss > about the > >transport mode/Mobike I-D (according to comments > about it in > >the list, BTW the I-D does not address issue #7). > > > >For SCTP it is clear there is something to do but > not so clear what... > >BTW is the RFC 3554 supported? (if it is we should > get the feedback > >from an implementor) > > > >For multi-homing in general I believe we should > reconsider > >the issues #8 and #20. Of course the issue #63 > could apply. > >(who should present this? IMHO we mainly need a > discussion) > > > > > The transport draft does not have too many details. > We do not have a written proposal on the table for > SCTP support nor issue #8 extension of MOBIKE*. > >From what i can remember reading the transport draft last time, it is not clear to me what it was trying to address. It talked about how MOBIKE can be used for MIPv6 BU protection and SCTP which are both transport mode. Today, it already works with IKEv1/IKEv2. So, why do we need MOBIKE ? Another *possibility* for transport mode MOBIKE is the following. Today NAT-T works for transport mode SAs also. This means if you establish a TCP connection across a NAT to the server on a public address, and the NAT changes the mapping and the TCP connection would still work. TCP connection on the server is still bound to the old NAT public address but IPsec has updated itself to the new address. Now i don't know how many implementations really work for this case. (Perhaps it works only for L2TP, GRE over IPsec like tunnels). With MOBIKE, one can still change the address and send an UPDATE to the peer. The transport connection should work without a change. I have not thought out all the details. Is this an interesting case to be solved by MOBIKE ? -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 13:24:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUp1F-0007I0-Bs for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 13:24:57 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08692 for ; Wed, 26 Oct 2005 13:24:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F3EF2FB285; Wed, 26 Oct 2005 17:24:54 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ED9C7FB262; Wed, 26 Oct 2005 17:24:52 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4F491FB284; Wed, 26 Oct 2005 17:24:51 +0000 (UTC) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id C7B8BFB24A for ; Wed, 26 Oct 2005 17:24:50 +0000 (UTC) Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j9QHOncd077630 for ; Wed, 26 Oct 2005 10:24:50 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <435F791F.1060806@piuha.net> References: <435F791F.1060806@piuha.net> Date: Wed, 26 Oct 2005 10:24:48 -0700 To: MOBIKE Mailing List From: Paul Hoffman Subject: Re: [Mobike] 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 At 3:39 PM +0300 10/26/05, Jari Arkko wrote: >Therefore, the plan >is to produce version 06 just before IETF and submit it >for AD review and IESG either during or right after the >meeting. Just to be clear, the order of the coming steps are: 1) The editor produces -06. 2) The WG chairs ask the WG for a sanity check (no need to do another formal WG last call). 3) The WG chairs pass the draft to the AD with a statement about the consensus. 4) The AD considers the document. If he has concerns, he brings them back to the WG, and the WG either answers his concerns in a message or the editors fix the concerns with a new draft. Loop back to step 3. 5) The AD asks for an IETF-wide last call, which lasts two weeks. 6) If the IETF-wide last call brings up issues, the WG deals with them, and possibly a new draft is issued. 7) The IESG starts its review. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 13:28:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUp4C-0008MH-SI for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 13:28:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08875 for ; Wed, 26 Oct 2005 13:27:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9D105FB28B; Wed, 26 Oct 2005 17:27:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 03686FB285; Wed, 26 Oct 2005 17:27:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B3A50FB289; Wed, 26 Oct 2005 17:27: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 56179FB284 for ; Wed, 26 Oct 2005 17:27: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 j9QHRM527982; Wed, 26 Oct 2005 19:27:22 +0200 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 j9QHRMIW015083; Wed, 26 Oct 2005 19:27:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510261727.j9QHRMIW015083@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy In-reply-to: Your message of Wed, 26 Oct 2005 09:59:10 PDT. <20051026165910.28787.qmail@web80606.mail.yahoo.com> Date: Wed, 26 Oct 2005 19:27:22 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) 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: From what i can remember reading the transport draft last time, it is not clear to me what it was trying to address. It talked about how MOBIKE can be used for MIPv6 BU protection and SCTP which are both transport mode. Today, it already works with IKEv1/IKEv2. So, why do we need MOBIKE ? => MIPv6 BU protection and SCTP have an authorization issue (remember the zillion of messages in the mip WG mailing list about this). The address management provided my MOBIKE is a clean and simple solution to this issue. So MOBIKE is not needed but simplifies the world. (you should reread the draft, even you are one of the few persons I know they have read it :-). Another *possibility* for transport mode MOBIKE is the following. Today NAT-T works for transport mode SAs also. => not in the IKEv2 framework (i.e., NAT-T support for transport mode is an extension). This means if you establish a TCP connection across a NAT to the server on a public address, and the NAT changes the mapping and the TCP connection would still work. TCP connection on the server is still bound to the old NAT public address but IPsec has updated itself to the new address. Now i don't know how many implementations really work for this case. => only a little number because the IPsec marker is VPN, i.e., tunnel mode only. (Perhaps it works only for L2TP, GRE over IPsec like tunnels). With MOBIKE, one can still change the address and send an UPDATE to the peer. => note with transport mode you don't change the endpoint addresses but the traffic selectors. The transport connection should work without a change. I have not thought out all the details. Is this an interesting case to be solved by MOBIKE ? => this is the issue #7 and I explicitely didn't propose to reopen it (you can but please don't mix this with my transport mode/MOBIKE draft). 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 Wed Oct 26 14:22:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUpun-0004hK-Qn for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 14:22:22 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11760 for ; Wed, 26 Oct 2005 14:22:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 07A58FB28A; Wed, 26 Oct 2005 18:22:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AA78DFB284; Wed, 26 Oct 2005 18:22:18 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3554BFB285; Wed, 26 Oct 2005 18:22:17 +0000 (UTC) Received: from web80602.mail.yahoo.com (web80602.mail.yahoo.com [66.218.79.91]) by machshav.com (Postfix) with SMTP id 41EFDFB262 for ; Wed, 26 Oct 2005 18:22:16 +0000 (UTC) Received: (qmail 20404 invoked by uid 60001); 26 Oct 2005 18:22:15 -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=enhHvk6OSBADTIT6w8Mycf0wqy7n6jEp4nBGstYhLEbmkeU4v+2qzd4E1CRYSJoNMfkgAkaDGjxYfL6O+OGXrRBzh0ZWC/iINNQJrnj+oQS2TrA1RTGx4ERXH9UaOshKOaPvulIUCr7kPV2gS1FA7TfKIqXLEM0OT3BgbUtlwBg= ; Message-ID: <20051026182215.20402.qmail@web80602.mail.yahoo.com> Received: from [206.132.194.3] by web80602.mail.yahoo.com via HTTP; Wed, 26 Oct 2005 11:22:15 PDT Date: Wed, 26 Oct 2005 11:22:15 -0700 (PDT) From: Mohan Parthasarathy To: Francis Dupont In-Reply-To: <200510261727.j9QHRMIW015083@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Cc: Jari Arkko , MOBIKE Mailing List 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 wrote: > In your previous mail you wrote: > > From what i can remember reading the transport > draft > last time, it is not clear to me what it was > trying to > address. It talked about how MOBIKE can be used > for > MIPv6 BU protection and SCTP which are both > transport > mode. Today, it already works with IKEv1/IKEv2. > So, > why do we need MOBIKE ? > > => MIPv6 BU protection and SCTP have an > authorization issue > (remember the zillion of messages in the mip WG > mailing list > about this). The address management provided my > MOBIKE > is a clean and simple solution to this issue. > So MOBIKE is not needed but simplifies the world. > (you should reread the draft, even you are one of > the few > persons I know they have read it :-). > In the case of MIP6 it might make sense because MN-HA MUST use IPsec to protect BUs and MOBIKE provides the RR check for the CoA. But SCTP has to solve the authorization issue anyway because you may not use IPsec with SCTP always. > Another *possibility* for transport mode MOBIKE > is the > following. Today NAT-T works for transport mode > SAs > also. > > => not in the IKEv2 framework (i.e., NAT-T support > for > transport mode is an extension). > I am not sure i understand this. Can you point me to a section in IKEv2 draft which states this ? > This means if you establish a TCP connection > across a NAT to the server on a public address, > and > the NAT changes the mapping and the TCP > connection > would still work. TCP connection on the server is > still bound to the old NAT public address but > IPsec > has updated itself to the new address. Now i > don't > know how many implementations really work for > this > case. > > => only a little number because the IPsec marker is > VPN, > i.e., tunnel mode only. > Agreed. > (Perhaps it works only for L2TP, GRE over IPsec > like tunnels). With MOBIKE, one can still change > the address and send an UPDATE to the peer. > > => note with transport mode you don't change the > endpoint > addresses but the traffic selectors. > Not in this case. In this case the traffic selectors don't change across mobility. I just realised that this has the same problems as the "spi collisions" issue. The transport connection is still bound to the original address which can be reused by some other node. But should be less of an issue with "IP-IP" transport mode like tunnels i guess. > The transport connection should work without a > change. > I have not thought out all the details. Is this > an > interesting case to be solved by MOBIKE ? > > => this is the issue #7 and I explicitely didn't > propose > to reopen it (you can but please don't mix this with > my > transport mode/MOBIKE draft). > Issue 7 is about transport mode. You have to reopen it for your draft too :-) -mohan > Regards > > Francis.Dupont@enst-bretagne.fr > > _______________________________________________ > 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 Oct 26 17:08:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUsVI-0002H9-6r for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 17:08:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24599 for ; Wed, 26 Oct 2005 17:07:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D38B3FB285; Wed, 26 Oct 2005 21:08:08 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 291C7FB262; Wed, 26 Oct 2005 21:08:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 23A8FFB284; Wed, 26 Oct 2005 21:08:02 +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 90FAAFB246 for ; Wed, 26 Oct 2005 21:08:00 +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 j9QL7ii12773; Wed, 26 Oct 2005 23:07:44 +0200 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 j9QL7hIn016243; Wed, 26 Oct 2005 23:07:44 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510262107.j9QL7hIn016243@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy In-reply-to: Your message of Wed, 26 Oct 2005 11:22:15 PDT. <20051026182215.20402.qmail@web80602.mail.yahoo.com> Date: Wed, 26 Oct 2005 23:07:43 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) 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: > => MIPv6 BU protection and SCTP have an > authorization issue > (remember the zillion of messages in the mip WG > mailing list > about this). The address management provided my > MOBIKE > is a clean and simple solution to this issue. > So MOBIKE is not needed but simplifies the world. > (you should reread the draft, even you are one of > the few > persons I know they have read it :-). In the case of MIP6 it might make sense because MN-HA MUST use IPsec to protect BUs and MOBIKE provides the RR check for the CoA. => hum, it seems we are in complete misunderstanding... In MIPv6 the MN-HA IKE is run over the CoA but the IPsec SA pair in transport mode must be established with the HoA. So IKE has to check if the MN has the authorization to use this particular HoA. In place to have a dedicated code for MIPv6 in IKE I simply propose to use the MOBIKE framework to add the HoA as an additional address and to check (not using RR please :-) if it is authorized. But SCTP has to solve the authorization issue anyway because you may not use IPsec with SCTP always. => I am talking about authorization of additional peer addresses in IKE/IPsec. > => not in the IKEv2 framework (i.e., NAT-T support > for transport mode is an extension). I am not sure i understand this. Can you point me to a section in IKEv2 draft which states this ? => I believed there was no NAT-T support for transport mode because there is no NAT-OA but you are right: The original source and destination IP address required for the transport mode TCP and UDP packet checksum fixup (see [Hutt04]) are obtained from the Traffic Selectors associated with the exchange. Note this makes more complex to path the Traffic Selectors (:-). But should be less of an issue with "IP-IP" transport mode like tunnels i guess. => yes, the IP-IP transport mode is clearly a special case. (there is a comment by Joe Touch about this in issue #7) Issue 7 is about transport mode. You have to reopen it for your draft too :-) => the issue #7 question is a bit ambiguous but as it is from a comment of mine, the real issue is about peer address change for transport mode SAs (so not addressed by my draft) So can we agree that to reopen the issue #7 is to look at if/how to update transport mode SAs? BTW my opinion is the complexity is too high and the current solution (reestablish SAs with new addresses) is enough in the general case. Regards Francis.Dupont@enst-bretagne.fr PS: for the tunnel special case (the traffic is selected by it is in the tunnel, i.e., a particular interface and protocol) we have two choices: - write a specific document - add it in the transport document (I can provide the current version in xml2rfc to a co-author who shall write the text). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 17:55:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUtEd-0007dT-8j for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 17:55:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29038 for ; Wed, 26 Oct 2005 17:54:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 165B0FB289; Wed, 26 Oct 2005 21:55:02 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 33C9CFB284; Wed, 26 Oct 2005 21:55:00 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3E226FB285; Wed, 26 Oct 2005 21:54:58 +0000 (UTC) Received: from web80603.mail.yahoo.com (web80603.mail.yahoo.com [66.218.79.92]) by machshav.com (Postfix) with SMTP id 4D573FB262 for ; Wed, 26 Oct 2005 21:54:57 +0000 (UTC) Received: (qmail 45141 invoked by uid 60001); 26 Oct 2005 21:54:56 -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=UUmLYwvxzy2sOuiVA5v8jilCwvlB7wCwBgYVa062II1+2bpo7roPn1K5mNvQzz7ukudz1zZDkryz6IWIck9mzZH2gcu4Fz7+M1SDRjq4E8oBArFfcu+1Vo/Q5P9+mPIh5mw/Fu1ARN5S1dyrZMstDvH5vylaVZtkJTGzjiK/15Q= ; Message-ID: <20051026215456.45139.qmail@web80603.mail.yahoo.com> Received: from [206.132.194.2] by web80603.mail.yahoo.com via HTTP; Wed, 26 Oct 2005 14:54:56 PDT Date: Wed, 26 Oct 2005 14:54:56 -0700 (PDT) From: Mohan Parthasarathy To: Francis Dupont In-Reply-To: <200510262107.j9QL7hIn016243@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 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 wrote: > In your previous mail you wrote: > > > => MIPv6 BU protection and SCTP have an > > authorization issue > > (remember the zillion of messages in the mip WG > > mailing list > > about this). The address management provided my > > MOBIKE > > is a clean and simple solution to this issue. > > So MOBIKE is not needed but simplifies the > world. > > (you should reread the draft, even you are one > of > > the few > > persons I know they have read it :-). > > In the case of MIP6 it might make sense because > MN-HA MUST use IPsec to protect BUs and MOBIKE > provides the RR check for the CoA. > > => hum, it seems we are in complete > misunderstanding... > hmm.. i am not sure whether there were zillions of mail on this case :-) > In MIPv6 the MN-HA IKE is run over the CoA but the > IPsec SA > pair in transport mode must be established with the > HoA. > So IKE has to check if the MN has the authorization > to use > this particular HoA. In place to have a dedicated > code for MIPv6 > in IKE I simply propose to use the MOBIKE framework > to add the > HoA as an additional address and to check (not using > RR please :-) > if it is authorized. > So, the authorization still happens the same way as defined in RFC 3776. It is just that you are using a different mechanism to convey the home address i.e instead of ID/Traffic selectors i.e you are using MOBIKE mechanism. Am i understanding this right ? > But SCTP has to > solve the authorization issue anyway because you > may not use IPsec with SCTP always. > > => I am talking about authorization of additional > peer addresses > in IKE/IPsec. > > > => not in the IKEv2 framework (i.e., NAT-T > support > > for transport mode is an extension). > > But should be less of an issue with "IP-IP" > transport mode like tunnels i guess. > > => yes, the IP-IP transport mode is clearly a > special case. > (there is a comment by Joe Touch about this in issue > #7) > > Issue 7 is about transport mode. You have to > reopen > it for your draft too :-) > > => the issue #7 question is a bit ambiguous but as > it is from > a comment of mine, the real issue is about peer > address change > for transport mode SAs (so not addressed by my > draft) > So can we agree that to reopen the issue #7 is to > look at > if/how to update transport mode SAs? > At least that was my understanding :-) > BTW my opinion is the complexity is too high and the > current > solution (reestablish SAs with new addresses) is > enough > in the general case. > I am not sure i agree on why this is more complex. -mohan > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: for the tunnel special case (the traffic is > selected by it is > in the tunnel, i.e., a particular interface and > protocol) we have > two choices: > - write a specific document > - add it in the transport document (I can provide > the current > version in xml2rfc to a co-author who shall write > the text). > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Oct 26 18:41:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUtxC-0004rY-Nn for mobike-archive@megatron.ietf.org; Wed, 26 Oct 2005 18:41:06 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01729 for ; Wed, 26 Oct 2005 18:40:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0F213FB28A; Wed, 26 Oct 2005 22:41:04 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8F9E8FB284; Wed, 26 Oct 2005 22:41:02 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 654D4FB285; Wed, 26 Oct 2005 22:41:00 +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 1E925FB262 for ; Wed, 26 Oct 2005 22:40:59 +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 j9QMehi18806; Thu, 27 Oct 2005 00:40:43 +0200 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 j9QMehCh016981; Thu, 27 Oct 2005 00:40:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510262240.j9QMehCh016981@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy In-reply-to: Your message of Wed, 26 Oct 2005 14:54:56 PDT. <20051026215456.45139.qmail@web80603.mail.yahoo.com> Date: Thu, 27 Oct 2005 00:40:43 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) 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: So, the authorization still happens the same way as defined in RFC 3776. => yes, the authorization is still needed. It is just that you are using a different mechanism to convey the home address i.e instead of ID/Traffic selectors i.e you are using MOBIKE mechanism. => I still use the traffic selectors but never the ID. Am i understanding this right ? => more but perhaps not yet the whole idea. How to do express the authorization in your favorite IKE implementation? Does it work well with a dynamic HoA? With MOBIKE there is no problem, or if your prefer, MOBIKE has the problems and MIPv6 relies on the solutions used for MOBIKE. > So can we agree that to reopen the issue #7 is to > look at if/how to update transport mode SAs? At least that was my understanding :-) > BTW my opinion is the complexity is too high and the... I am not sure i agree on why this is more complex. => I have done many times the code for MIPv6 (updating tunnel endpoints in IPsec SAs, SPDs, IKE) so I know it is not so difficult. I don't know how to do for general transport mode, i.e, updating traffic selectors. So I prefer to avoid a specification which is too hard to implement (so won't be implemented) without a proof of a real need. 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 Thu Oct 27 03:24:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV27R-0004dn-SD for mobike-archive@megatron.ietf.org; Thu, 27 Oct 2005 03:24:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11592 for ; Thu, 27 Oct 2005 03:23:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 34DB5FB28A; Thu, 27 Oct 2005 07:24:08 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E54C2FB27F; Thu, 27 Oct 2005 07:24:06 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 822A8FB283; Thu, 27 Oct 2005 07:24:05 +0000 (UTC) Received: from p130.piuha.net (unknown [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 5E2DEFB262 for ; Thu, 27 Oct 2005 07:24:04 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 63AD089871; Thu, 27 Oct 2005 10:23:33 +0300 (EEST) Message-ID: <43608081.5060609@piuha.net> Date: Thu, 27 Oct 2005 10:23:45 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy , Francis Dupont References: <20051026165910.28787.qmail@web80606.mail.yahoo.com> In-Reply-To: <20051026165910.28787.qmail@web80606.mail.yahoo.com> Cc: MOBIKE Mailing List 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 Hi Mohan, >>From what i can remember reading the transport draft >last time, it is not clear to me what it was trying to >address. It talked about how MOBIKE can be used for >MIPv6 BU protection and SCTP which are both transport >mode. Today, it already works with IKEv1/IKEv2. So, >why do we need MOBIKE ? > > And Francis wrote: >So MOBIKE is not needed but simplifies the world. > These are precisely the type of questions we'd have to figure out before starting work. >Another *possibility* for transport mode MOBIKE is the >following. Today NAT-T works for transport mode SAs >also. This means if you establish a TCP connection >across a NAT to the server on a public address, and >the NAT changes the mapping and the TCP connection >would still work. TCP connection on the server is >still bound to the old NAT public address but IPsec >has updated itself to the new address. Now i don't >know how many implementations really work for this >case. (Perhaps it works only for L2TP, GRE over IPsec >like tunnels). With MOBIKE, one can still change >the address and send an UPDATE to the peer. The >transport connection should work without a change. >I have not thought out all the details. Is this an >interesting case to be solved by MOBIKE ? > > Possibly. What I'd like to see before taking on any new work is a rationale why some function is needed and a scenario where this is used. I can see what you are saying technically, but we'd have to figure out who would use it. Where is transport mode IPsec used today, and would it benefit from MOBIKE support? Would potential users adopt it? --jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Oct 27 10:50:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV958-0003YF-Ms for mobike-archive@megatron.ietf.org; Thu, 27 Oct 2005 10:50:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04055 for ; Thu, 27 Oct 2005 10:50:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A2172FB289; Thu, 27 Oct 2005 14:50:09 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5D421FB280; Thu, 27 Oct 2005 14:50:08 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 65AE7FB283; Thu, 27 Oct 2005 14:50:06 +0000 (UTC) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id B0E8FFB262 for ; Thu, 27 Oct 2005 14:50:05 +0000 (UTC) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EV94s-0000Je-Ux; Thu, 27 Oct 2005 10:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 27 Oct 2005 10:50:02 -0400 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-protocol-05.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-05.txt Pages : 33 Date : 2005-10-27 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-05.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-05.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-05.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-10-27101735.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-protocol-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-protocol-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-27101735.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 Thu Oct 27 12:12:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVAME-0001IL-4D for mobike-archive@megatron.ietf.org; Thu, 27 Oct 2005 12:12:02 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06468 for ; Thu, 27 Oct 2005 12:11:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 496F1FB28A; Thu, 27 Oct 2005 16:11:56 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9C0B5FB280; Thu, 27 Oct 2005 16:11:54 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 720ABFB282; Thu, 27 Oct 2005 16:11:53 +0000 (UTC) Received: from smtp110.sbc.mail.mud.yahoo.com (smtp110.sbc.mail.mud.yahoo.com [68.142.198.209]) by machshav.com (Postfix) with SMTP id F0F98FB262 for ; Thu, 27 Oct 2005 16:11:50 +0000 (UTC) Received: (qmail 71524 invoked from network); 27 Oct 2005 16:11:42 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.215.108 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 27 Oct 2005 16:11:40 -0000 Message-ID: <005a01c5db11$212e3310$6801a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , "Francis Dupont" References: <20051026165910.28787.qmail@web80606.mail.yahoo.com> <43608081.5060609@piuha.net> Date: Thu, 27 Oct 2005 09:11:45 -0700 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 Mailing List 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 > Possibly. What I'd like to see before taking > on any new work is a rationale why some > function is needed and a scenario where this > is used. I can see what you are saying technically, > but we'd have to figure out who would use > it. Where is transport mode IPsec used today, > and would it benefit from MOBIKE support? > Would potential users adopt it? > Completely agreed. -mohan > --jari > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 03:54:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVP49-0001Fl-WD for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 03:54:22 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29467 for ; Fri, 28 Oct 2005 03:54:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 18DC6FB292; Fri, 28 Oct 2005 07:54:19 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 747CFFB290; Fri, 28 Oct 2005 07:54:16 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DF400FB291; Fri, 28 Oct 2005 07:54:14 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 620C9FB28E for ; Fri, 28 Oct 2005 07:54:11 +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 j9S7s6f7014962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 10:54:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9S7s55d016324; Fri, 28 Oct 2005 10:54:05 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17249.55581.775717.407102@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 10:54:05 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <435F791F.1060806@piuha.net> References: <435F791F.1060806@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 23 min X-Total-Time: 25 min Cc: MOBIKE Mailing List Subject: [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 Jari Arkko writes: > 59 - tero's editorial comments (Tero - please check -05) Checking... Hmm... 1, 4, 5, 6 seems to be in the draft. 9 is missing, and 10 is missing the picture. 11 and 12 seems also be missing. Here is actual changes needed to be made to 05: Change ---------------------------------------------------------------------- 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 20 4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 20 4.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 20 4.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 20 4.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 21 4.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 21 4.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 21 4.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 21 ---------------------------------------------------------------------- to ---------------------------------------------------------------------- 4. Payload Formats 4.1 Notify messages - Error types 4.1.1 UNACCEPTABLE_ADDRESSES Notify Payload 4.1.2 UNEXPECTED_NAT_DETECTED Notify Payload 4.2 Notify messages - Status types 4.2.1. MOBIKE_SUPPORTED Notify Payload 4.2.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads 4.2.3. NO_ADDITIONAL_ADDRESSES Notify Payload 4.2.4. UPDATE_SA_ADDRESSES Notify Payload 4.2.5. COOKIE2 Notify Payload 4.2.6. NO_NATS_ALLOWED Notify Payload ---------------------------------------------------------------------- And change the section ---------------------------------------------------------------------- 4. Payload Formats This specification defines several new IKEv2 Notify payload types. The UNACCEPTABLE_ADDRESSES and UNEXPECTED_NAT_DETECTED notifications are "error types"; the other notifications are "status types". See [IKEv2] Section 3.10 for a general description of the Notify payload. ---------------------------------------------------------------------- to: ---------------------------------------------------------------------- 4. Payload Formats This specification defines several new IKEv2 Notify payload types. See [IKEv2] Section 3.10 for a general description of the Notify payload. 4.1 Notify messages - Error types 4.1.1 UNACCEPTABLE_ADDRESSES Notify Payload ... 4.2 Notify messages - Status types ... ---------------------------------------------------------------------- Also change the section 6. IANA Considerations from: ---------------------------------------------------------------------- Notify Message Value --------------------------- ----- MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) COOKIE2 TBD-BY-IANA7 (16396..40959) NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) ---------------------------------------------------------------------- to ---------------------------------------------------------------------- NOTIFY MESSAGES - ERROR TYPES Value ------------------------------ ----- UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) NOTIFY MESSAGES - STATUS TYPES Value ------------------------------ ----- MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) COOKIE2 TBD-BY-IANA7 (16396..40959) NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) ---------------------------------------------------------------------- Just to align with the format used in the IKEv2. For 10 change: ---------------------------------------------------------------------- 4.7. NO_NATS_ALLOWED Notify Payload See Section 3.9 for a description of this notification. The data field of this notification contains the following information: the IP address from which the packet was sent (4 or 16 bytes), the port from which the packet was sent (2 bytes, network byte order), the IP addresss to which the packet was sent (4 or 16 bytes), and the port to which the packet was sent (2 bytes, network byte order). The total length of the data field is thus 12 bytes for IPv4 and 36 bytes for IPv6. The Notify Message Type for this message is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to zero. ---------------------------------------------------------------------- to (just added the picture) ---------------------------------------------------------------------- 4.7. NO_NATS_ALLOWED Notify Payload See Section 3.9 for a description of this notification. The data field of this notification contains the following information: the IP address from which the packet was sent (4 or 16 bytes), the port from which the packet was sent (2 bytes, network byte order), the IP addresss to which the packet was sent (4 or 16 bytes), and the port to which the packet was sent (2 bytes, network byte order). The total length of the data field is thus 12 bytes for IPv4 and 36 bytes for IPv6. Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | dst-ip (4 or 16 bytes) | dst-port (2 bytes) The Notify Message Type for this message is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to zero. ---------------------------------------------------------------------- For 11 change: (there is also some half-written sentence there that I fixed at the same time) ---------------------------------------------------------------------- MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. Such modifications can only be performed by attackers who are on the path and capable of modifying the When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. ---------------------------------------------------------------------- to ---------------------------------------------------------------------- MOBIKE introduces the NO_NATS_ALLOWED notification that is used to detect modification, by outsiders, of the addresses in the IP header. When this notification is used, communication through NATs and other address translators is impossible, so it is sent only when not doing NAT Traversal. One of the main uses for this feature is the IPv6 networks. ---------------------------------------------------------------------- For 12 change: ---------------------------------------------------------------------- MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications reveal information about which networks the peers are connected to. ---------------------------------------------------------------------- to ---------------------------------------------------------------------- MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications reveal information about which networks the peers are connected to. Note, that this information is only available to the other peers, not to the passive listeners of the traffic. ---------------------------------------------------------------------- -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 04:45:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVPrC-0003wq-9l for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 04:45:02 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01713 for ; Fri, 28 Oct 2005 04:44:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4D8DAFB292; Fri, 28 Oct 2005 08:44:59 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4AE13FB290; Fri, 28 Oct 2005 08:44:57 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3C998FB291; Fri, 28 Oct 2005 08:44:56 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E6609FB28E for ; Fri, 28 Oct 2005 08:44: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 j9S8iqHn014877 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 11:44:52 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9S8ipfe007495; Fri, 28 Oct 2005 11:44:51 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17249.58627.276353.689034@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 11:44:51 +0300 From: Tero Kivinen To: Francis Dupont In-Reply-To: <200510261336.j9QDaUol013607@givry.rennes.enst-bretagne.fr> References: <435F69B3.3010800@piuha.net> <200510261336.j9QDaUol013607@givry.rennes.enst-bretagne.fr> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 20 min X-Total-Time: 49 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: > It may > require some preparation from you, however, such > as figuring out what the SCTP implementation situation > is or what issues are in providing additional IPsec/MOBIKE > support for SCTP. > > => I prefer we get first feedback for RFC 3554 implementors: > IMHO if nobody has implemented it and nobody cares, it is the > sign the RFC 3554 way is wrong. 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. 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. The traffic selectors used in the IPsec SAs are lists so there should not be problem to use those in the SCTP. 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. 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. 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). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 05:02:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQ8E-0005Ug-Ct for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 05:02:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02823 for ; Fri, 28 Oct 2005 05:02:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D59ECFB292; Fri, 28 Oct 2005 09:02:35 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 701DAFB290; Fri, 28 Oct 2005 09:02:33 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4E44EFB291; Fri, 28 Oct 2005 09:02:31 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 75306FB28E for ; Fri, 28 Oct 2005 09:02:30 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 957D789842; Fri, 28 Oct 2005 12:02:09 +0300 (EEST) Message-ID: <4361E91C.60007@piuha.net> Date: Fri, 28 Oct 2005 12:02:20 +0300 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: <435F69B3.3010800@piuha.net> <200510261336.j9QDaUol013607@givry.rennes.enst-bretagne.fr> <17249.58627.276353.689034@fireball.kivinen.iki.fi> In-Reply-To: <17249.58627.276353.689034@fireball.kivinen.iki.fi> Cc: MOBIKE Mailing List , Francis Dupont Subject: [Mobike] SCTP (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 Tero Kivinen wrote: >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. > > Real experts should be answering this, but draft-ietf-tsvwg-addip-sctp-12.txt appears to be able to do that. Tracker says the draft is "active", which does not tell me much. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 05:04:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQA6-0006Ma-Ou for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 05:04:34 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02886 for ; Fri, 28 Oct 2005 05:04:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B6A1FFB292; Fri, 28 Oct 2005 09:04:32 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F0272FB290; Fri, 28 Oct 2005 09:04:30 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 571B9FB291; Fri, 28 Oct 2005 09:04:28 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 13C73FB28E for ; Fri, 28 Oct 2005 09:04:27 +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 j9S94Pag007939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 12:04:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9S94Pf0015409; Fri, 28 Oct 2005 12:04:25 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17249.59801.296664.947952@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 12:04:25 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <435F791F.1060806@piuha.net> References: <435F791F.1060806@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 9 min Cc: MOBIKE Mailing List Subject: [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 Jari Arkko writes: > The issue list is at [3]. The issues that I believe still > need further discussion are > 56 - ingress filtering Actually I think the design draft should have enough text about this (see section 5.1.2. Connectivity). I do not think we need more than what is now in the protocol draft already i.e: ---------------------------------------------------------------------- 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 paths. ---------------------------------------------------------------------- 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... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 05:11:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQGK-0001Ig-RD for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 05:11:00 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02987 for ; Fri, 28 Oct 2005 05:10:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E6A64FB299; Fri, 28 Oct 2005 09:10:58 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6EE2CFB291; Fri, 28 Oct 2005 09:10:55 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A079AFB292; Fri, 28 Oct 2005 09:10:53 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 50150FB290 for ; Fri, 28 Oct 2005 09:10:52 +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 j9S9Ap44014364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 12:10:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9S9AoDh029631; Fri, 28 Oct 2005 12:10:50 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17249.60186.904922.201619@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 12:10:50 +0300 From: Tero Kivinen To: Jari Arkko In-Reply-To: <435F791F.1060806@piuha.net> References: <435F791F.1060806@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: MOBIKE Mailing List Subject: [Mobike] Issue 46 (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 Jari Arkko writes: > The issue list is at [3]. The issues that I believe still > need further discussion are > > 46 - question about additional addresses There are some changes still missing from the 05 for this. The beginning of the 3.6 would need to be changed, i.e. change ---------------------------------------------------------------------- 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. The message exchange will look as follows: ---------------------------------------------------------------------- to ---------------------------------------------------------------------- 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. The NO_ADDITIONAL_ADDRESSES notify is used to indicate that there are no additional addresses besides the address used in the IP-headers. The ADDITIONAL_IP4/6_ADDRESS are used to give complete list of additional addresses (in addition to the one in the IP-header). The new address list will completely overwrite the previous list. The message exchange will look as follows: ---------------------------------------------------------------------- -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 05:33:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQbh-0004aR-4o for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 05:33:05 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03849 for ; Fri, 28 Oct 2005 05:32:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 155DCFB294; Fri, 28 Oct 2005 09:33:03 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 65C54FB290; Fri, 28 Oct 2005 09:32:58 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0B182FB291; Fri, 28 Oct 2005 09:32:56 +0000 (UTC) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by machshav.com (Postfix) with ESMTP id 19FB3FB28E for ; Fri, 28 Oct 2005 09:32:55 +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 j9S9WlhR005601; Fri, 28 Oct 2005 11:32:47 +0200 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 j9S9Vpls005423; Fri, 28 Oct 2005 11:31:51 +0200 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 j9S9Ubo1026081; Fri, 28 Oct 2005 11:30:37 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510280930.j9S9Ubo1026081@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: Fri, 28 Oct 2005 11:30:37 +0200 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: > => I prefer we get first feedback for RFC 3554 implementors: > IMHO if nobody has implemented it and nobody cares, it is the > sign the RFC 3554 way is wrong. We have rfc3554 implemented => fine! It seems we have found the right person to launch the discussion. 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 Oct 28 05:38:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVQgq-0007Ta-2h for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 05:38:24 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04039 for ; Fri, 28 Oct 2005 05:38:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CA9FCFB297; Fri, 28 Oct 2005 09:38:21 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 61E80FB292; Fri, 28 Oct 2005 09:38:20 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 34F7BFB293; Fri, 28 Oct 2005 09:38:19 +0000 (UTC) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by machshav.com (Postfix) with ESMTP id 3D7D0FB291 for ; Fri, 28 Oct 2005 09:38:18 +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 j9S9cBhR006475; Fri, 28 Oct 2005 11:38:11 +0200 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 j9S9avls006333; Fri, 28 Oct 2005 11:36:57 +0200 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 j9S9ZeO7026163; Fri, 28 Oct 2005 11:35:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200510280935.j9S9ZeO7026163@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen In-reply-to: Your message of Fri, 28 Oct 2005 12:04:25 +0300. <17249.59801.296664.947952@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 11:35:40 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: MOBIKE Mailing List , Jari Arkko 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: , 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: MOBIKE follows the IKEv2 practice where a response message is sent to => in fact this is more a requirement than a practice... Francis.Dupont@enst-bretagne.fr PS: I am okay for the proposed change. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 06:19:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRKd-0004v0-8r for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 06:19:31 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05644 for ; Fri, 28 Oct 2005 06:19:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5A7F4FB294; Fri, 28 Oct 2005 10:19:28 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6187DFB290; Fri, 28 Oct 2005 10:19:26 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3E6F3FB291; Fri, 28 Oct 2005 10:19:24 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 693E8FB28E for ; Fri, 28 Oct 2005 10:19:23 +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 j9SAFOve016781; Fri, 28 Oct 2005 13:15:35 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 13:19:20 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 13:19:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Oct 2005 13:19:20 +0300 Message-ID: Thread-Topic: [Mobike] 44 - nat changes and ike rekey Thread-Index: AcXZI3HFiCBUzMI/TZuRFJWxYmogYwChNjiA From: To: , X-OriginalArrivalTime: 28 Oct 2005 10:19:20.0162 (UTC) FILETIME=[0F3E3C20:01C5DBA9] Subject: Re: [Mobike] 44 - nat changes and ike rekey 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: > > I am okay with this. > > Note we are talking about "Changes in NAT mappings". Is it > okay for an implementation to implement just one of the > two schemes > > 1) send NAT-D payloads in DPD messages, compare the response > with the previou UPDATE_SA_ADDRESS response > 2) send NAT-D payloads in DPD messages with UPDATE_SA_ADDRESSES The spec allows the initiator to decide which way it wants to do, but doesn't require any particular method of choosing. Hardcoding is obviously one valid way (but so are a configuration option and dynamic selection based on some heuristic). The responder will support both anyway (but doesn't really need additional code, since it cannot know whether a message is "DPD message" or something else). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 06:25:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVRQo-0006vQ-4g for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 06:25:54 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05932 for ; Fri, 28 Oct 2005 06:25:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C4F19FB297; Fri, 28 Oct 2005 10:25:51 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2CE05FB292; Fri, 28 Oct 2005 10:25:51 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A26EFB293; Fri, 28 Oct 2005 10:25:49 +0000 (UTC) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id ADEDFFB291 for ; Fri, 28 Oct 2005 10:25:48 +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 j9SALucn023695; Fri, 28 Oct 2005 13:22:01 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 13:25:47 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 13:25:47 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Oct 2005 13:25:48 +0300 Message-ID: Thread-Topic: [Mobike] 68 - minimal conformance requirements Thread-Index: AcXZJMtPNkdIaGXJRPCCt3n+j2O8SwChJNcA From: To: , X-OriginalArrivalTime: 28 Oct 2005 10:25:47.0647 (UTC) FILETIME=[F633C0F0:01C5DBA9] Subject: Re: [Mobike] 68 - minimal conformance requirements 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: > > How about rephrasing this as follows? > > > > Note that both peers can have their own policies about what > > addresses are acceptable to use, and certain types of policies > > may simplify implementation. For instance, if the responder > > has a single fixed address, it does need to process > > ADDITIONAL_*_ADDRESS notifications it receives (beyond > > ignoring unrecognized status notifications as already required > > in [IKEv2]). Furthermore, if the initiator has a policy saying > > In section 4.5, it talks about how a responder can try a different > address for its peer. The responder itself has only one address > but it can try different peer addresses. Or Are you saying that > the policy says don't try different peer addresses ? That part of Section 4.5 (in -04; Section 3.6 in -05) talks about what is done when the responder's address changes. The text about having a "single _fixed_ address" was trying to say that the address doesn't change, so that part of Section 4.5 doesn't apply. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 08:02:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVSvz-0002Jn-KP for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 08:02:11 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10115 for ; Fri, 28 Oct 2005 08:01:53 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 00C46FB292; Fri, 28 Oct 2005 12:02:09 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 42474FB290; Fri, 28 Oct 2005 12:02:07 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D5B0DFB291; Fri, 28 Oct 2005 12:02:04 +0000 (UTC) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id A026EFB28E for ; Fri, 28 Oct 2005 12:02:03 +0000 (UTC) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j9SC212Y019512; Fri, 28 Oct 2005 15:02:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 15:02:01 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Oct 2005 15:02:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 28 Oct 2005 15:02:00 +0300 Message-ID: Thread-Topic: [Mobike] Issue 59 (was: protocol draft status and moving forward) Thread-Index: AcXblPGw03gRh2i5SyW4jZmkCjIJTgAIl2Vw From: To: X-OriginalArrivalTime: 28 Oct 2005 12:02:02.0093 (UTC) FILETIME=[680A49D0:01C5DBB7] 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: > Checking... > > Hmm... 1, 4, 5, 6 seems to be in the draft. > 9 is missing, and 10 is missing the picture. > 11 and 12 seems also be missing. > > Here is actual changes needed to be made to 05: > > Just to align with the format used in the IKEv2. The need for a fifty-page clarifications document suggests that on editorial issues, we probably shouldn't align with IKEv2 too closely :-) But OK, I'll make this change so we get this issue closed... > For 10 change: > to (just added the picture) > ---------------------------------------------------------------------- > 4.7. NO_NATS_ALLOWED Notify Payload > > See Section 3.9 for a description of this notification. > > The data field of this notification contains the following > information: the IP address from which the packet was sent (4 or 16 > bytes), the port from which the packet was sent (2 bytes, network > byte order), the IP addresss to which the packet was sent (4 or 16 > bytes), and the port to which the packet was sent (2 bytes, network > byte order). The total length of the data field is thus > 12 bytes for IPv4 and 36 bytes for IPv6. > > Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | > dst-ip (4 or 16 bytes) | dst-port (2 bytes) > > The Notify Message Type for this message is TBD-BY-IANA8. The > Protocol ID and SPI Size fields are set to zero. > ---------------------------------------------------------------------- IMHO we shouldn't repeat exactly the same information twice. Do you think there's a danger than an implementors would misunderstand the current text and get interop problems? (if yes, we should rewrite the text; if not, it's good enough and doesn't need polishing) > For 11 change: (there is also some half-written sentence there > that I fixed at the same time) > to > MOBIKE introduces the NO_NATS_ALLOWED notification that is used to > detect modification, by outsiders, of the addresses in the IP > header. When this notification is used, communication through NATs > and other address translators is impossible, so it is sent only > when not doing NAT Traversal. One of the main uses for this feature > is the IPv6 networks. For sub-issue 11, I already added a mention of IPv6 elsewhere. E.g. Section 3.9 says "This feature is mainly intended for IPv6 and site-to-site VPN cases..." Is mentioning IPv6 some more helpful for the reader..? > For 12 change: > Note, that this information is only available to the other peers, > not to the passive listeners of the traffic. For sub-isuse 12, I already added this later in the same section: Furthermore, the ADDITIONAL_IP4/6_ADDRESS notifications are sent encrypted, so the addresses are not visible to eavesdroppers (unless, of course, they are later used for sending IKEv2/IPsec traffic). Is that sufficient? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 09:21:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUAl-0005hF-9j for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 09:21:31 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14052 for ; Fri, 28 Oct 2005 09:21:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A10BDFB299; Fri, 28 Oct 2005 13:21:29 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5F49CFB290; Fri, 28 Oct 2005 13:21:21 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3C17DFB291; Fri, 28 Oct 2005 13:21:19 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 7B21FFB28E for ; Fri, 28 Oct 2005 13:21:17 +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 j9SDLEP9028850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 16:21:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9SDLEbS024037; Fri, 28 Oct 2005 16:21:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17250.9674.161357.584414@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 16:21:14 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 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: > The need for a fifty-page clarifications document suggests that > on editorial issues, we probably shouldn't align with IKEv2 > too closely :-) True, but thats why I do want to add the text in this document, not on the mobike-clarifications document. Thus lets put all the text here please, and do not try to condence things that you think are not needed (as we later will notice that people will misunderstand those and we need clarifications document). > > ---------------------------------------------------------------------- > > 4.7. NO_NATS_ALLOWED Notify Payload > > > > See Section 3.9 for a description of this notification. > > > > The data field of this notification contains the following > > information: the IP address from which the packet was sent (4 or 16 > > bytes), the port from which the packet was sent (2 bytes, network > > byte order), the IP addresss to which the packet was sent (4 or 16 > > bytes), and the port to which the packet was sent (2 bytes, network > > byte order). The total length of the data field is thus > > 12 bytes for IPv4 and 36 bytes for IPv6. > > > > Data = src-ip (4 or 16 bytes) | src-port (2 bytes) | > > dst-ip (4 or 16 bytes) | dst-port (2 bytes) > > > > The Notify Message Type for this message is TBD-BY-IANA8. The > > Protocol ID and SPI Size fields are set to zero. > > ---------------------------------------------------------------------- > > IMHO we shouldn't repeat exactly the same information twice. Do you > think there's a danger than an implementors would misunderstand the > current text and get interop problems? (if yes, we should rewrite > the text; if not, it's good enough and doesn't need polishing) 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. There was several missinterpretations of the IKEv2 section 2.15 which do not have picture what is signed in the auth payload, but just text explaining that. This was clarified in the section 3.1 of the clarifiation draft. > > For 11 change: (there is also some half-written sentence there > > that I fixed at the same time) > > > to > > MOBIKE introduces the NO_NATS_ALLOWED notification that is used to > > detect modification, by outsiders, of the addresses in the IP > > header. When this notification is used, communication through NATs > > and other address translators is impossible, so it is sent only > > when not doing NAT Traversal. One of the main uses for this feature > > is the IPv6 networks. > > For sub-issue 11, I already added a mention of IPv6 elsewhere. > E.g. Section 3.9 says "This feature is mainly intended for IPv6 > and site-to-site VPN cases..." > > 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. > > For 12 change: > > > Note, that this information is only available to the other peers, > > not to the passive listeners of the traffic. > > For sub-isuse 12, I already added this later in the same section: > > Furthermore, the ADDITIONAL_IP4/6_ADDRESS notifications are sent > encrypted, so the addresses are not visible to eavesdroppers > (unless, of course, they are later used for sending IKEv2/IPsec > traffic). > > Is that sufficient? Hmm.... I would like it to be mentioned in the first paragraph, as it will clearly identify the problem to the reader immediately, so he can skip the whole section if that does not apply to him, but I think it could be enough to have it there where it is now. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 09:26:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUF9-0006w1-Md for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 09:26:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14218 for ; Fri, 28 Oct 2005 09:25:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 65A89FB297; Fri, 28 Oct 2005 13:26:01 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 57EA6FB290; Fri, 28 Oct 2005 13:25:59 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0B161FB291; Fri, 28 Oct 2005 13:25:57 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 932F5FB28E for ; Fri, 28 Oct 2005 13:25: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 j9SDPrrS027556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 16:25:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9SDPr4L028404; Fri, 28 Oct 2005 16:25:53 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17250.9953.651539.836546@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 16:25:53 +0300 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: Pasi.Eronen@nokia.com Subject: [Mobike] one more editorial comment 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 think the section 3.5 should change the text: ---------------------------------------------------------------------- o If the response contains an UNACCEPTABLE_ADDRESSES notification, the initiator MAY select another addresses and retry the exchange, keep on using the current addresses, or disconnect. ---------------------------------------------------------------------- to ---------------------------------------------------------------------- o If the response contains an UNACCEPTABLE_ADDRESSES notification, the initiator MAY select another addresses and retry the exchange, keep on using the previously used addresses, or disconnect. ---------------------------------------------------------------------- as we have already updated the current used addresses of the IKE SA when we stared the process (i.e. in step 1 of section 3.5) Actually it might good to use numbered list of the steps, so it would be easier to point in to that list... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 09:50:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUcg-00044p-Ey for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 09:50:22 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15749 for ; Fri, 28 Oct 2005 09:50:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8AFA1FB292; Fri, 28 Oct 2005 13:50:20 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C94C2FB290; Fri, 28 Oct 2005 13:50:18 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4C661FB291; Fri, 28 Oct 2005 13:50:17 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id B10D1FB28E for ; Fri, 28 Oct 2005 13:50:15 +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 j9SDoEMp012948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2005 16:50:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9SDoE5D021586; Fri, 28 Oct 2005 16:50:14 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17250.11414.323634.642707@fireball.kivinen.iki.fi> Date: Fri, 28 Oct 2005 16:50:14 +0300 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 24 min X-Total-Time: 24 min Cc: Pasi.Eronen@nokia.com Subject: [Mobike] 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 The current document is missing text what happens if the return routability check fails. Should we add some text about that? If there it is genuine attack then we of course want to tear down the IKE SA (i.e. we do not get any reply back for the RR at all). The problem is that this might cause IKE SA to teared down even when there is no attack in case the selected link goes down before the RR but after the update. I.e the case is like this: Initiator Responder --------- --------- Currently using IP_I1 and IP_R1 for traffic Send address update (IP_I2:500 -> IP_R1:500) HDR, SK { N(UPDATE_SA_ADDRESSES) } --> Responder processes the request and send ACK. <-- (IP_R1:500 -> IP_I2:500) HDR, SK { } Initiator updates the IPsec SAs to IP_I2, IP_R1. Link between IP_I2 and IP_R1 breaks down. Responder starts DPD lost <-- (IP_R1:500 -> IP_I2:500) HDR, SK { N(COOKIE2) } lost <-- (IP_R1:500 -> IP_I2:500) HDR, SK { N(COOKIE2) } lost <-- (IP_R1:500 -> IP_I2:500) HDR, SK { N(COOKIE2) } The inititor will not see those return routability packets. The IPsec traffic is still going through from responder to initiator, as it uses old IP_R1 and IP_I1 addresses (they are not yet updated as the RR has not finished yet). <-- (IP_R1 -> IP_I1) ESP packet Data from initiator to the responder does not go through as he is using new IP addresses (IP_I2 -> IP_R1) ESP packet --> lost <-- (IP_R1 -> IP_I1) ESP packet Initiator will still see packets coming from the responder but to the old address. Now the Initiator needs to understand that even if he is getting packets in, he should start DPD in case those packets are coming from the different address than where they should be coming. This is not mentioned in the document now. If initiator does that, this will fix the situation. Responder is still doing RR. lost <-- (IP_R1:500 -> IP_I2:500) HDR, SK { N(COOKIE2) } Initiator notices that is not getting any trafic to the address pair where he is sending traffic, and decides to start DPD. (IP_I2:500 -> IP_R1:500) HDR, SK { } --> lost (IP_I2:500 -> IP_R1:500) HDR, SK { } --> lost (IP_I2:500 -> IP_R1:500) HDR, SK { } --> lost Initiator notices it is not getting data back, thus tries other addresses (IP_I1:500 -> IP_R1:500) HDR, SK { } --> Responder will get get that and reply to it. <-- (IP_R1:500 -> IP_I1:500) HDR, SK { } Initiator detects that IP_I2, IP_R1 address pair is not working and switches to the working IP_I1, IP_R1 address pair. (IP_I1:500 -> IP_R1:500) HDR, SK { N(UPDATE_SA_ADDRESSES) } --> Responder processes the request and send ACK. <-- (IP_R1:500 -> IP_I2:500) HDR, SK { } Responder retransmits the old ongoing RR to the new updated address. <-- (IP_R1:500 -> IP_I1:500) HDR, SK { N(COOKIE2) } Initiator respondeds to RR. (IP_I1:500 -> IP_R1:500) HDR, SK { N(COOKIE2) } --> Responder gets ack to RR, but notices that address has changed since it was started, so he need to restart the RR <-- (IP_R1:500 -> IP_I1:500) HDR, SK { N(COOKIE2') } Initiator respondeds to new RR. (IP_I1:500 -> IP_R1:500) HDR, SK { N(COOKIE2') } --> Responder is now happy, and will update the IPsec SAs to the IP_R1, IP_I2 address pair (or actually they are already there, as it never got them changed, but they might have moved to some new address). So we probably want to say something about this, as it do require the initiator to understand that even when it is getting ESP packets in it might need to start DPD in case the IP addresses of the ESP packets are different from what he thinks they should be. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 09:56:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVUiK-0006XH-RY for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 09:56:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18739 for ; Fri, 28 Oct 2005 09:55:53 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 99049FB294; Fri, 28 Oct 2005 13:56:10 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 898C7FB290; Fri, 28 Oct 2005 13:56:09 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 246C9FB291; Fri, 28 Oct 2005 13:56:06 +0000 (UTC) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 94A97FB28E for ; Fri, 28 Oct 2005 13:56:04 +0000 (UTC) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E551789842; Fri, 28 Oct 2005 16:54:53 +0300 (EEST) Message-ID: <43622DAB.4000405@piuha.net> Date: Fri, 28 Oct 2005 16:54:51 +0300 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: <17250.11414.323634.642707@fireball.kivinen.iki.fi> In-Reply-To: <17250.11414.323634.642707@fireball.kivinen.iki.fi> Cc: Pasi.Eronen@nokia.com, mobike@machshav.com Subject: Re: [Mobike] 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: >So we probably want to say something about this, as it do require the >initiator to understand that even when it is getting ESP packets in it >might need to start DPD in case the IP addresses of the ESP packets >are different from what he thinks they should be. > > Isn't that already stated somewhere? Seems like its a part of the NAT behaviour... Anyway, I believe we do need to say something about the case that you mentioned. It is indeed possible that an update fails in any of its stages, including RR. What I would suggest is that if you don't complete the update then you continue operating as if it didn't happen, and be prepared to accept/initiate another address update. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Oct 28 13:38:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVYBg-0001B8-EM for mobike-archive@megatron.ietf.org; Fri, 28 Oct 2005 13:38:44 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00094 for ; Fri, 28 Oct 2005 13:38:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 95031FB292; Fri, 28 Oct 2005 17:38:42 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 626FCFB290; Fri, 28 Oct 2005 17:38:41 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 14ABBFB291; Fri, 28 Oct 2005 17:38:39 +0000 (UTC) Received: from web80604.mail.yahoo.com (web80604.mail.yahoo.com [66.218.79.93]) by machshav.com (Postfix) with SMTP id ACCC1FB28E for ; Fri, 28 Oct 2005 17:38:37 +0000 (UTC) Received: (qmail 41405 invoked by uid 60001); 28 Oct 2005 17:38:33 -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=6dIAjWOsEGs527xzrM81D8igcjs/Es726RKGw3f8IkYe8lznMYmfhT6LHfbm4dNmqdyxCyuS3BO0ew1Vha9nPO5ksqY9fHTWnGt0fhb4i0oKMyoM6UlKByG4FyhJz82G0vKLzUuJyrp1zBgXOU3JxZQmlzX/G44HyvJQvTVc3Zs= ; Message-ID: <20051028173833.41403.qmail@web80604.mail.yahoo.com> Received: from [206.132.194.3] by web80604.mail.yahoo.com via HTTP; Fri, 28 Oct 2005 10:38:32 PDT Date: Fri, 28 Oct 2005 10:38:32 -0700 (PDT) From: Mohan Parthasarathy To: Tero Kivinen , Jari Arkko In-Reply-To: <17249.60186.904922.201619@fireball.kivinen.iki.fi> MIME-Version: 1.0 Cc: MOBIKE Mailing List Subject: Re: [Mobike] Issue 46 (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 > > The issue list is at [3]. The issues that I > believe still > > need further discussion are > > > > 46 - question about additional addresses > > There are some changes still missing from the 05 for > this. > > The beginning of the 3.6 would need to be changed, > i.e. change > > ---------------------------------------------------------------------- > 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. > The message exchange will look as follows: > ---------------------------------------------------------------------- > > to > > ---------------------------------------------------------------------- > 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. The NO_ADDITIONAL_ADDRESSES notify > is used to > indicate that there are no additional addresses > besides the address > used in the IP-headers. The 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. -thanks mohan > ADDITIONAL_IP4/6_ADDRESS are used to > give complete list of additional addresses (in > addition to the one > in the IP-header). The new address list will > completely overwrite > the previous list. > > The message exchange will look as follows: > ---------------------------------------------------------------------- > -- > 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 Mon Oct 31 04:52:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWWKj-0003sT-S9 for mobike-archive@megatron.ietf.org; Mon, 31 Oct 2005 04:52:06 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24894 for ; Mon, 31 Oct 2005 04:51:45 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id CED48FB28E; Mon, 31 Oct 2005 09:52:02 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0D77BFB283; Mon, 31 Oct 2005 09:52:01 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 52ACAFB28D; Mon, 31 Oct 2005 09:51:59 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 00A86FB282 for ; Mon, 31 Oct 2005 09:51:58 +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 j9V9pniu025636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2005 11:51:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9V9pman004284; Mon, 31 Oct 2005 11:51: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: <17253.59700.847545.971743@fireball.kivinen.iki.fi> Date: Mon, 31 Oct 2005 11:51:48 +0200 From: Tero Kivinen To: Jari Arkko In-Reply-To: <43622DAB.4000405@piuha.net> References: <17250.11414.323634.642707@fireball.kivinen.iki.fi> <43622DAB.4000405@piuha.net> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: Pasi.Eronen@nokia.com, mobike@machshav.com Subject: Re: [Mobike] 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: > >So we probably want to say something about this, as it do require the > >initiator to understand that even when it is getting ESP packets in it > >might need to start DPD in case the IP addresses of the ESP packets > >are different from what he thinks they should be. > > > > > Isn't that already stated somewhere? Seems like its a > part of the NAT behaviour... At least it is not mentioned in the NAT-T drafts and I do not think it is mentioned in the IKEv2 draft either. Protocol draft says: ---------------------------------------------------------------------- IKEv2 performs Dead Peer Detection (DPD) if there has recently been only outgoing traffic on all of the SAs associated with the IKE_SA. ---------------------------------------------------------------------- and that is under NAT-T. IKEv2 draft says: ---------------------------------------------------------------------- ... If there has only been outgoing traffic on all of the SAs associated with an IKE_SA, it is essential to confirm liveness of the other endpoint to avoid black holes. If no cryptographically protected messages have been received on an IKE_SA or any of its CHILD_SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. Receipt of a fresh cryptographically protected message on an IKE_SA or any of its CHILD_SAs assures liveness of the IKE_SA and all of its CHILD_SAs. Note that this places requirements on the failure modes of an IKE endpoint. An implementation MUST NOT continue sending on any SA if some failure prevents it from receiving on all of the associated SAs. If CHILD_SAs can fail independently from one another without the associated IKE_SA being able to send a delete message, then they MUST be negotiated by separate IKE_SAs. ---------------------------------------------------------------------- So that does not say anything about the IP-addresses. I think we need some paragraph about that to the mobike draft. > Anyway, I believe we do need to say something about > the case that you mentioned. It is indeed possible that > an update fails in any of its stages, including RR. What > I would suggest is that if you don't complete the update > then you continue operating as if it didn't happen, and > be prepared to accept/initiate another address update. The problem in the failing in the RR step is that it is negotiatiation initiated by the responder, thus it cannot fall back to other addresses. It is also normal IKEv2 message, which means it must get reply back or otherwise the whole IKE SA is deleted. So we cannot fail that RR, we must finish it, and we can only finish it with the help of initiator noticing that the path does not work, and falling back to some other path. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Oct 31 04:56:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EWWOl-0004ex-HU for mobike-archive@megatron.ietf.org; Mon, 31 Oct 2005 04:56:15 -0500 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25257 for ; Mon, 31 Oct 2005 04:55:54 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id D5A1CFB297; Mon, 31 Oct 2005 09:56:12 +0000 (UTC) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A4FAEFB283; Mon, 31 Oct 2005 09:56:10 +0000 (UTC) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8B078FB28D; Mon, 31 Oct 2005 09:56:09 +0000 (UTC) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 49C74FB282 for ; Mon, 31 Oct 2005 09:56:08 +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 j9V9u7Z1008803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 31 Oct 2005 11:56:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j9V9u6Jm000658; Mon, 31 Oct 2005 11:56:06 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <17253.59958.496661.679698@fireball.kivinen.iki.fi> Date: Mon, 31 Oct 2005 11:56:06 +0200 From: Tero Kivinen To: Mohan Parthasarathy In-Reply-To: <20051028173833.41403.qmail@web80604.mail.yahoo.com> References: <17249.60186.904922.201619@fireball.kivinen.iki.fi> <20051028173833.41403.qmail@web80604.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: MOBIKE Mailing List , Jari Arkko Subject: Re: [Mobike] Issue 46 (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 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. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike