From mobike-bounces@machshav.com Fri Jul 08 11:30:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqunx-0001GV-FF for mobike-archive@megatron.ietf.org; Fri, 08 Jul 2005 11:30:17 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21329 for ; Fri, 8 Jul 2005 11:30:14 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 82B00FB28A; Fri, 8 Jul 2005 11:30:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2C4FCFB266; Fri, 8 Jul 2005 11:30:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E5A33FB27F; Fri, 8 Jul 2005 11:30:04 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id 4948EFB262 for ; Fri, 8 Jul 2005 11:30:04 -0400 (EDT) Received: from [63.249.99.114] (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 j68FU2Hj018326 for ; Fri, 8 Jul 2005 08:30:03 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 8 Jul 2005 08:30:01 -0700 To: mobike@machshav.com From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Mobike] Getting comments on draft-ietf-mobike-protocol-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Greetings again. Pasi was good enough to get the -00 out early so people could review it, but we haven't seen any comments on the mailing list yet. If we get comments and agreement on some issues within a week, Pasi can get a -01 out before the Paris meeting. Of course, if the -00 is perfect and fully reflects the desires of the WG, the Paris meeting will be quite easy. :-) At 3:50 PM -0400 6/29/05, Internet-Drafts@ietf.org wrote: >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-00.txt > Pages : 21 > Date : 2005-6-29 > > This document describes the MOBIKE protocol, a mobility and > multihoming extension to IKEv2. The purpose of MOBIKE is to update > the (outer) IP addresses associated with IKE and IPsec Security > Associations (SAs). The main scenario for MOBIKE is making it > possible for a remote access VPN user to move from one address to > another without re-establishing all security associations with the > VPN gateway. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-00.txt --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 08 15:35:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dqyd4-0005xc-A7 for mobike-archive@megatron.ietf.org; Fri, 08 Jul 2005 15:35:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10715 for ; Fri, 8 Jul 2005 15:35:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DE5CFFB286; Fri, 8 Jul 2005 15:35:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C67BCFB266; Fri, 8 Jul 2005 15:34:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B16D0FB27F; Fri, 8 Jul 2005 15:16:52 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by machshav.com (Postfix) with ESMTP id 47283FB24A for ; Fri, 8 Jul 2005 15:16:50 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j68JGldd022483 for ; Fri, 8 Jul 2005 12:16:47 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j68JGi50024811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 8 Jul 2005 12:16:45 -0700 (PDT) Message-ID: <42CED11D.7060304@qualcomm.com> Date: Fri, 08 Jul 2005 15:16:45 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mobike@machshav.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 08 Jul 2005 15:34:54 -0400 Subject: [Mobike] Review of draft-ietf-mobike-protocol-00 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Content-Transfer-Encoding: 7bit Overall the document is very well written and excellent for a -00-. Please look for " " below for some suggested revisions. Thanks. regards, Lakshminath ++++++++++++ Network Working Group P. Eronen, Ed. Wrong WG name +++++++++snip+++++++++ Abstract This document describes the MOBIKE protocol, a mobility and multihoming extension to IKEv2. The purpose of MOBIKE is to update the (outer) IP addresses associated with IKE and IPsec Security Associations (SAs). The main scenario for MOBIKE is making it possible for a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway. Perhaps the abstract could be revised to include what's being done for multihoming as well. The last sentence could be: MOBIKE allows IPsec end points to change addresses (for multihoming or due to mobility) without re-establishing all SAs with peers. (that sentence didn't come out all that well, but a revision thereof might be better) +++++++++++++++snip+++++++++++++++ 1.2 Paragraph 3 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 better position to decide Edit: s/in better position/in a better position which of its network interfaces should be used for both upstream and downstream traffic. Section 1.2, last paragraph Updating the addresses of IPsec SAs naturally has to take into account several security considerations. MOBIKE includes two features design to address these considerations. First, a "return routability" check can be used to verify the addresses provided by the peer. This makes it more difficult flood third parties with This sentence is garbled. Please rewrite. large amounts of traffic. Second, a "NAT prevention" feature ensures I may have overlooked the discussion on terminology, but prevention doesn't seem to convey the intended meaning. that IP addresses have not been modified by NATs, IPv4/IPv6 translation agents, or other similar devices. This feature is mainly intended for site-to-site VPNs where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered to be an attack. 1.3 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. IPsec Security Association (SA) An ESP or AH Security Association. Path A particular combination of source IP address and destination IP address (note: this definition does not consider the route taken by the packets in the network). Terminology again: why not use the phrase "address pair" instead of path. I realize that it results in a large number of changes in the document, but this is still a -00- 2. MOBIKE protocol exchanges 2.1 Signaling support for MOBIKE Implementations that wish to use MOBIKE for a particular IKE_SA MUST include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request and response messages. Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, N(MOBIKE_SUPPORTED), [N(NAT_DETECTION_*)] --> <-- HDR, SAr1, KEr, Nr, [N(NAT_DETECTION_*)], [CERTREQ], N(MOBIKE_SUPPORTED) The MOBIKE_SUPPORTED notification payload is described in Section 3. NAT_DETECTION_* needs to be explained. Also, IKEv2 (-17) uses NAT_DETECTION_*_IP. 2.2 Additional addresses Both the initiator and responder MAY include one or more ADDITIONAL_ADDRESS notification payloads in the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the message containing the SA payload). Initiator Responder ----------- ----------- HDR, SK { IDi, [CERT], [IDr], AUTH, [CP(CFG_REQUEST)] SAi2, TSi, TSr, [N(ADDITIONAL_ADDRESS)*] } --> <-- HDR, SK { IDr, [CERT], AUTH, [CP(CFG_REPLY)], SAr2, TSi, TSr, [N(ADDITIONAL_ADDRESS)*] } Does the * above mean that zero or more ADDITIONAL ADDRESS payloads MAY be included? 2.3 Changing path of IPsec SAs In MOBIKE, the initiator of the IKE_SA decides what addresses are used in the IPsec SAs. That is, the responder never updates any IPsec SAs without receiving an explicit CHANGE_PATH request from the initiator. (As described below, the responder can, however, update the IKE_SA in some circumstances.) The description in this section assumes that the initiator has already decided what the new addresses should be. How this decision is made is beyond the scope of this specification. When this decision has been made, the initiator o Updates the IKE_SA and IPsec SAs with the new addresses, and sets the "pending_update" flag in the IKE_SA. o 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. o When the window size allows, sends an INFORMATIONAL request containing the CHANGE_PATH notification payload (which does not contain any data), and clears the "pending_update" flag. Since this is optional, suggest using the keyword MAY or OPTIONAL Initiator Responder ----------- ----------- HDR, SK { N(CHANGE_PATH), N(COOKIE2), [N(NAT_DETECTION_*),] [N(NAT_PREVENTION)] } --> This is the first occurrence of COOKIE2. Suggest briefly explaining what it is or providing a forward reference to the appropriate section where it is defined. o Updates the IP addresses in the IKE_SA and IPsec SAs with the values from the IP header. Suggest adding a sentence here or in a more appropriate place that the address changes are implicit, in that the new addresses are not obtained from the IP header, not IKEv2 or MOBIKE payloads. o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal. I may be wrong, but is disabling NAT Traversal a possibility here? o Replies with an INFORMATIONAL response: Initiator Responder ----------- ----------- <-- HDR, SK { N(COOKIE2), [N(NAT_DETECTION_*)] } Should the other optional Notification payloads be present in this message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are discussed below, but are not in the above message. When the initiator receives the reply, it o If the response contains the NAT_PREVENTED payload, processes it as described in Section 2.7. o If the response contains an UNACCEPTABLE_PATH notification payload, the initiator MAY select another path and retry the exchange, keep on using the current path, or disconnect. o If NAT Traversal is supported and NAT detection payloads were included, enables or disables NAT Traversal. 2.4 Updating additional addresses As described in Section 2.2, both the initiator and responder can send a list of additional addresses (in addition to the one used for IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH exchange. If this list of addresses changes, a new list can be sent in any INFORMATIONAL exchange request message. When the responder (of the original IKE_SA) receives an INFORMATIONAL request containing ADDITIONAL_ADDRESS payloads, it simply stores the information, but no other action is taken. ++++++++++snip+++++++++++ Initiator Responder ----------- ----------- HDR, SK { N(ADDITIONAL_ADDRESS)+, N(COOKIE2) } --> <-- HDR, SK { N(COOKIE2) } When the initiator receives an INFORMATIONAL request containing ADDITIONAL_ADDRESS, it stores the information and also determines whether the currently used path needs to be changed (for instance, if the currently used address is no longer included in the list); if it does, the initiator proceeds as described in the previous section. I must say that I don't like overloading the Notification payload with IP addresses. IKEv2 uses ID payloads for this purpose, why not use those? Initiator Responder ----------- ----------- <-- HDR, SK { N(ADDITIONAL_ADDRESS)+, N(COOKIE2) } HDR, SK { N(COOKIE2) } --> If the implementation supports window sizes greater than one, it also has to keep track of the Message ID of the latest update it has received, to avoid the situation where new information is overwritten by older. +++++++++snip++++++++ In Section 2.5, there is a reference to "as described in the previous section" Please replace the "previous section" with the section name, since a reorganization of the sections might make that an incorrect reference. 2.6 Return routability check Both the initiator and the responder 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. Please use one of the 2119 keywords, MAY or OPTIONAL in the above paragraph. By default, return routability check SHOULD be done before updating the IPsec SAs. In environments where the peer is expected to be well-behaving (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 skipped or postponed until after the IPsec SAs have been updated. 2.7 NAT prevention IKEv2/IPsec implementations that do not support NAT Traversal can, in fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in tunnel mode. This may be considered a problem in some circumstances, since in some sense any modification of the IP addresses can be considered to be an attack. The "NAT prevention" feature allows both the initiator and responder to have a policy that prevents the use of paths that contain NATs, IPv4/IPv6 translation agents, or other nodes that modify the addresses in the IP header. This feature is mainly intended for site-to-site VPN cases, where the administrators may know beforehand that NATs are not present, and thus any modification to the packet can be considered to be an attack. This specification addresses the issue as follows. When an IPsec SA is created, the tunnel header IP addresses (and port if doing UDP encapsulation) are taken from the IKE_SA, not the message IP header. The NAT_PREVENTION payload is used to guarantee that NATs have not modified the address used in IKE_SA. However, all response messages are still sent to the address and port the corresponding request came from. The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT request. The responder MUST compare the NAT_PREVENTION payload with the values from the IP header. If they do not match, the responder The sentence "The responder MUST compare ..." might need to be rewritten. The responder recomputes the hash included in the NAT_PREVENTION payload using the address from the IP header to verify if the claim that there is no NAT, is indeed true. Eronen Expires December 30, 2005 [Page 11] Internet-Draft MOBIKE Protocol June 2005 replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any state. The labels NAT_PREVENTION, NAT_PREVENTED are confusing. For a little while I thought they are the same, but realize they are different. NAT_PREVENTION seem to mean that the sender is guaranteeing/indicating that there is no NAT. Perhaps, NAT_NOTSUPPORTED or NAT_ABSENT or something like that might be more appropriate. Instead of NAT_PREVENTED, NAT_PRESENT or NAT_DETECTED might be more appropriate. The Initiator then can compare its claim from its state that NAT_ABSENT against NAT_PRESENT to detect that its claim is incorrect. If the values do match, the responder initializes (local_address, local_port, peer_address, peer_port) in the to-be-created IKE_SA with values from the IP header. The same applies if neither NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if the responder does not support NAT Traversal. If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but no NAT_PREVENTION payload, the situation is different since the initiator may at this point change from port 500 to 4500. In this case, the responder initializes (local_address, local_port, peer_address, peer_port) from the first IKE_AUTH request. It may also decide to perform a return routability check soon after the IKE_AUTH exchanges have been completed. Is the may a "MAY" in the sentence above? IKEv2 requires that if an IPsec endpoint discovers a NAT between it and its correspondent, it MUST send all subsequent traffic to and from port 4500. To simplify things, implementations that support both this specification and NAT Traversal MUST change to port 4500 if the correspondent also supports both, even if no NAT was detected between them. +++++++++++snip++++++++++++++ 4. 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. In some specific cases MOBIKE is also capable of protecting address changes better than existing NAT Traversal procedures. Since we cannot use bold or other types of emphasis, I suggest using subsections so that each of the topics below stand out. The threats arising in scenarios targeted by MOBIKE are: Traffic redirection and hijacking Insecure mobility management mechanisms may allow inappropriate redirection of traffic. This may allow inspection of the traffic as well as man-in-the-middle and session hijacking attacks. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jul 11 01:45:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Drr6j-0008GA-Bl for mobike-archive@megatron.ietf.org; Mon, 11 Jul 2005 01:45:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21182 for ; Mon, 11 Jul 2005 01:45:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E86CFFB266; Mon, 11 Jul 2005 01:45:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3B158FB246; Mon, 11 Jul 2005 01:45:18 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D2739FB24A; Mon, 11 Jul 2005 01:45:16 -0400 (EDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by machshav.com (Postfix) with SMTP id 501E2FB240 for ; Mon, 11 Jul 2005 01:45:15 -0400 (EDT) Received: (qmail 52952 invoked from network); 11 Jul 2005 05:45:14 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.35 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 11 Jul 2005 05:45:14 -0000 Message-ID: <00ce01c585db$b3617d90$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "MOBIKE Mailing List" Date: Sun, 10 Jul 2005 22:45:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Considering all the discussions we had, this draft is simple to read. The details on exactly on how the protocol works (section 2.3) needs to be expanded more in the future revision. Also, the NAT traversal details need a little more detail :-) Here are some of my comments.. Technical ---------- -Section 2.3: - Does not explain, what happens when the "window size does not allow ? It retransmits the existing message with the new address and responder sends back to the new address but without updating the SAs ? This is sort of implicit in the text because the SAs are updated with the new address pair in the first step and any retransmissions will happen with the new address. - What is "latest_update_received" counter ? Where else is it used other than this step? Either the counter is updated or not. It is not clear what this counter is used for as it just appears in this step alone. -Path testing: - The security impact of this is not discussed in the Security consideration section ? - It states that the reason for new message type is to support window size 1. But it does not state why it can't be secure ? You can still have a separate window space for this message and still provide security, right ? This was discussed in the mailing list. Do you see problems with it ? - Section 2.7 - NAT Prevention stuff.. This specification addresses the issue as follows. When an IPsec SA is created, the tunnel header IP addresses (and port if doing UDP encapsulation) are taken from the IKE_SA, not the message IP header. The NAT_PREVENTION payload is used to guarantee that NATs have not modified the address used in IKE_SA. However, all response messages are still sent to the address and port the corresponding request came from. If we are reached the stage of creating the IPsec SA and we have used NAT_ PREVENTION, the IP header and value carried in the NAT_PREVENTION payload is same. So, just taking from the IP header should be fine. Is this talking about not updating from the IP header of the IPsec packets (as required by standard NAT-T) in general ? Editorial -------- - section 1.1, In some cases, the the problem can be solved by simply creating new IKE and IPsec SAs after the IP address has changed. In static multihoming scenarios, it may even be possible to have several IKE and IPsec SAs simultaneously, and perform some kind of dynamic routing over them [RFC3884]. However, this can be problematic for several reasons. Creating a new IKE_SA may require user interaction for authentication (entering a code from a token card, for instance). Creating new SAs often also involves expensive calculations and possibly a large number of roundtrips. Due to these reasons, a mechanism for updating the IP addresses of existing IKE and IPsec SAs is needed. The MOBIKE protocol described in this document provides such a mechanism. This paragraph is trying to provide the real motivation but things don't seem well connected. The multihoming and creating a new IKE SA with user interaction does not seem to go well. The following is one possible rewording. Though the problem can be solved by creating new IKE and IPsec SAs after the IP address has changed, this may not be optimal for serveral reasons. In some cases, creating a new IKE SA may require user interaction for authentication (entering a code from a token card, for instance). Creating new SAs often also involves expensive calculations and possibly a large number of roundtrips. Due to these reasons, a mechanism for updating the IP addresses of existing IKE and IPsec SAs is needed. The MOBIKE protocol described in this document provides such a mechanism. And move the static multihoming to the previous paragraph where different scenarios are described - section 1.1, The main scenario for MOBIKE is making it possible for a remote access VPN user to move from one address to another without re- establishing all security associations with the VPN gateway. .... More complex scenarios arise when the VPN gateway also has several network interfaces Though the more complex scenario is supported, the wording does not indicate that. -In section 1.2, 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 better position to decide which of its network interfaces should be used for both upstream and downstream traffic. Can we not talk about NAT also here ? -In section 1.2, Here MOBIKE assumes that the initiator is the party "behind" the NAT, and does not fully support the case where the responder's addresses change when NATs are present. What do you mean by "fully" ? -mohan Here it says "values from IP header" ? This is for the IKE SA i guess. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jul 11 12:31:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ds1CF-0004Qr-82 for mobike-archive@megatron.ietf.org; Mon, 11 Jul 2005 12:31:55 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26655 for ; Mon, 11 Jul 2005 12:31:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 02454FB27F; Mon, 11 Jul 2005 12:31:40 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 377E6FB266; Mon, 11 Jul 2005 12:31:36 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1E0ADFB27D; Mon, 11 Jul 2005 12:31:35 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id D11FCFB24A for ; Mon, 11 Jul 2005 12:31:33 -0400 (EDT) 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 j6BGSGZ0024560 for ; Mon, 11 Jul 2005 19:28:19 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jul 2005 19:31:26 +0300 Received: from daebe102.NOE.Nokia.com ([10.241.35.115]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Jul 2005 11:31:12 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Jul 2005 11:31:07 -0500 Message-ID: Thread-Topic: Comments on draft-ietf-mobike-protocol-00.txt Thread-Index: AcWGNfEcJPY3w1ZuToSa1oUOVy1RPQ== From: To: X-OriginalArrivalTime: 11 Jul 2005 16:31:12.0508 (UTC) FILETIME=[F3694BC0:01C58635] Subject: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Sections 1, 2 and 3 look great to me. Thanks for the fast turnaround. Comments on 4. Security considerations The IESG security reviewer of this section will be concerned with 3 issues: 1. Is there a mitigation for every threat? 2. Which mitigations are associated with which threats? 3. For each threat, what are the specific mitigation(s)? This section does not make this explicit. Here is a suggestion for this, which is to label the threats and countermeasures and refer to them, but other ways will work as well. I have included more technical comments inline. Threat 1: Traffic redirection and hijacking Insecure mobility management mechanisms may allow inappropriate redirection of traffic. This may allow inspection of the traffic as well as man-in-the-middle and session hijacking attacks. The scope of these attacks in the MOBIKE case is limited, as all traffic is protected using IPsec. Mitigation: Countermeasure 1 - Payload traffic protection, etc. (* Delete this and move to threat 2 *) However, it should be observed that security associations originally created for the protection of a specific flow between specific addresses may be moved through MOBIKE. The level of required protection may be different in a new location of a VPN client, for instance. I would argue that this second paragraph is really a separate threat that has nothing to do with traffic redirection and hijacking. So I have made a separate threat number 2 as follows.=20 Threat 2: Roaming into a network with a different security policy Note that security associations originally created for the protection of a specific flow between specific addresses may be moved through MOBIKE. The level of required protection may be different in a new location of a VPN client, for instance. Mitigation: Countermeasure 6 - Policy enforcement for roaming clients, etc. Threat 3: Third-party denial-of-service through flooding Mitigation: Countermeasure 6 - Strong authentication for IKEv2, etc. Threat 4: Spoofing indications related to network connectivity (* There is a discussion here of this issue and then a similar discussion is repeated in the countermeasure section OUTSIDE of the list of countermeasures. It starts with the sentence: "MOBIKE does not provide any protection of its own for indications..." I'm not sure why it is structured this way and it is confusing.*) =20 Mitigation: Countermeasure 5 - Use of security mechanisms in network and lower layers, etc.=20 Threat 5: Denial-of-service of the participants through MOBIKE Mitigation: Countermeasure 5 - Use of security mechanisms in network and lower layers, etc. MOBIKE addresses these threats using the following countermeasures: Countermeasure 1: Payload traffic protection Countermeasure 2: Protection of MOBIKE payloads Countermeasure 3: Explicit Address change When NAT Traversal is supported, the peer's address may be updated automatically to allow changes in NAT mappings. The "continued return routability" feature, implemented by the COOKIE2 payload, allows verification of the new address after the change. This limits the duration of any "third party bombing" attack by off- path (relative to the victim) attackers. *** I'm not sure what a "continued return routability" feature means. It is not defined anywhere else. You need another sentence or something in the earlier section on return routability to clarify this. *** Countermeasure 4: Return routability tests ***Delete the last paragraph beginning with: MOBIKE does not provide any protection of its own for indications from other parts of the protocol stack. However, MOBIKE is resistant to incorrect information from these sources in the sense that it provides its own security for both the signaling of addressing information as well as actual payload data transmission. Denial-of- service vulnerabilities remain, however. Some aspects of these vulnerabilities can be mitigated through the use of techniques specific to the other parts of the stack, such as properly dealing with ICMP errors [ICMPAttacks], link layer security, or the use of [SEND] to protect IPv6 Router and Neighbor Discovery.*** Substitute this with a countermeasure: Countermeasure 5: Use of security mechanisms in network and lower layers These vulnerabilities can be mitigated through the use of techniques specific to the other parts of the stack, such as properly dealing with ICMP errors [ICMPAttacks], link layer security, or the use of [SEND] to protect IPv6 Router and Neighbor Discovery. Countermeasure 6: Policy enforcement for roaming clients This mitigation is strictly dependent on policy so there are many acceptable scenarios for mitigating this risk. The following scenario is included for illustrative purposes only. Suppose the level of protection is greater at the new location than it is at the old. Then this new address should not be included in any address list and a new security association should be created when this client moves. Suppose the level of protection is less at the new location that at the old. Then it is allowable to include this network address in the additional address list.=20 This may seem overly nit picking, but what I'm really doing here is making the case that you have a sound security threat analysis and a list of effective countermeasures that will stand up under security scrutiny. I haven't worked out all the text here and I realize there are holes in this writeup but this shows the general idea. =20 As always, just my 2 euros. Good job on the security section as well.=20 -- Maureen _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 04:42:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsGLK-00031T-7s for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 04:42:18 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01621 for ; Tue, 12 Jul 2005 04:42:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9B867FB284; Tue, 12 Jul 2005 04:42:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5BADEFB27D; Tue, 12 Jul 2005 04:42:06 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8745BFB281; Tue, 12 Jul 2005 04:42:05 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id CEF59FB266 for ; Tue, 12 Jul 2005 04:42:03 -0400 (EDT) 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 j6C8fxuc006068; Tue, 12 Jul 2005 11:42:02 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 11:41:30 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 11:41:30 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Review of draft-ietf-mobike-protocol-00 (issue 21) Date: Tue, 12 Jul 2005 11:41:30 +0300 Message-ID: Thread-Topic: [Mobike] Review of draft-ietf-mobike-protocol-00 Thread-Index: AcWD9EqgRMrWWyPATw2Le4izQkiJ3wCyIlPg From: To: , X-OriginalArrivalTime: 12 Jul 2005 08:41:30.0133 (UTC) FILETIME=[7FD1E450:01C586BD] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Thanks for your review, Lakshminath! I've filed the editorial comments as issue 21 and the more=20 technical comments as issues 22..24 in the issue list: http://www.vpnc.org/ietf-mobike/issues.html I'll reply to the technical comments in separate emails to make the issue tracking easier. Replies to some of the=20 editorial comments: > Abstract >=20 > This document describes the MOBIKE protocol, a mobility and > multihoming extension to IKEv2. The purpose of MOBIKE is to > update the (outer) IP addresses associated with IKE and > IPsec Security Associations (SAs). The main scenario for > MOBIKE is making it possible for a remote access VPN user to > move from one address to another without re-establishing all > security associations with the VPN gateway. >=20 > Perhaps the abstract could be revised to include what's > being done for multihoming as well. The last sentence could > be: MOBIKE allows IPsec end points to change addresses (for > multihoming or due to mobility) without re-establishing all > SAs with peers. (that sentence didn't come out all that well, > but a revision thereof might be better)=20 > Yes, the abstract was written in a bit of an hurry..:-) How about rewriting it to This document describes the MOBIKE protocol, a mobility and multihoming extension to IKEv2. MOBIKE allows mobile and/or multihomed hosts to update the (outer) IP addresses associated with IKE and IPsec Security Associations (SAs). The main scenario for MOBIKE is making it possible for a remote access VPN user to move from one address to another while keeping the VPN connection with the gateway active. > large amounts of traffic. Second, a "NAT prevention"=20 > feature ensures >=20 > I may have overlooked the discussion on terminology,=20 > but prevention doesn't seem to convey the intended meaning. > Hmm... I agree that NAT prevention is perhaps not the best possible word. Any better suggestions? Would "address integrity protection" be any better..? Comments from anyone else? > Path >=20 > A particular combination of source IP address and > destination IP address (note: this definition does not > consider the route taken by the packets in the network). >=20 > Terminology again: why not use the phrase "address pair"=20 > instead of path. I realize that it results in a large number=20 > of changes in the document, but this is still a -00- > Mainly because "path" is shorter and leads IMHO to more understandable text. RFC 2960 (SCTP) also uses the word "path" with pretty much the same meaning in many places. > 2.3 Changing path of IPsec SAs >=20 > In MOBIKE, the initiator of the IKE_SA decides what > addresses are used in the IPsec SAs. That is, the responder > never updates any IPsec SAs without receiving an explicit > CHANGE_PATH request from the initiator. (As described > below, the responder can, however, update the IKE_SA in some > circumstances.) >=20 > The description in this section assumes that the initiator > has already decided what the new addresses should be. How > this decision is made is beyond the scope of this > specification. When this decision has been made, the > initiator >=20 > o Updates the IKE_SA and IPsec SAs with the new addresses, > and sets the "pending_update" flag in the IKE_SA. >=20 > o If NAT Traversal is not enabled, and the responder supports > NAT Traversal (as indicated by NAT detection payloads in=20 > the IKE_SA_INIT exchange), and the initiator either suspects=20 > or knows that a NAT is likely to be present, enables NAT=20 > Traversal. >=20 > o When the window size allows, sends an INFORMATIONAL request > containing the CHANGE_PATH notification payload (which does > not contain any data), and clears the "pending_update" flag. >=20 > Since this is optional, suggest using the keyword MAY or=20 > OPTIONAL Which part are you referring to? > o Updates the IP addresses in the IKE_SA and IPsec SAs with=20 > the values from the IP header. >=20 > Suggest adding a sentence here or in a more appropriate=20 > place that the address changes are implicit, in that the new=20 > addresses are not obtained from the IP header, not IKEv2 or=20 > MOBIKE payloads. > Hmm.. it's not "implicit" in the sense that change of address is explicitly requested by the initiator (as opposed to just updating the SAs based on some more vague hints that a change might be needed)... but I'll add something to clarify this. > o Replies with an INFORMATIONAL response: >=20 > Initiator Responder > ----------- ----------- > <-- HDR, SK { N(COOKIE2), > [N(NAT_DETECTION_*)] } >=20 > > Should the other optional Notification payloads be present in=20 > this message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are=20 > discussed below, but are not in the above message. > Hmm, actually no, since this step in the process is never=20 reached if the NAT_PREVENTED or UNACCEPTABLE_PATH cases happen (they're already handled in earlier steps). > 4. Security considerations >=20 > 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. In some > specific cases MOBIKE is also capable of protecting address > changes better than existing NAT Traversal procedures. >=20 > Since we cannot use bold or other types of emphasis, I=20 > suggest using subsections so that each of the topics below=20 > stand out. > Hm... they're pretty short to be separate subsections, but I could try changing the indentation from 3 to 6 or something... Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 05:08:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsGkO-0002Ua-1C for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 05:08:12 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03510 for ; Tue, 12 Jul 2005 05:08:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AB4C4FB284; Tue, 12 Jul 2005 05:08:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9E1F4FB27D; Tue, 12 Jul 2005 05:08:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 043B1FB281; Tue, 12 Jul 2005 05:08:04 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id C61BFFB266 for ; Tue, 12 Jul 2005 05:08:02 -0400 (EDT) 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 j6C94kMO006649; Tue, 12 Jul 2005 12:04:47 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 12:08:01 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 12:08:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt (issue 25) Date: Tue, 12 Jul 2005 12:08:01 +0300 Message-ID: Thread-Topic: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt Thread-Index: AcWF2/G7CJZPJyz1QECua8aRxYzGfgA4ZnCw From: To: , X-OriginalArrivalTime: 12 Jul 2005 09:08:01.0477 (UTC) FILETIME=[3455B750:01C586C1] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Hi Mohan, I've filed your comments as issues 25 (editorial), 26 (window size/latest_update counter), 27 (security and path testing) and 24 (details of NAT prevention) I'll start with the editorial ones: > - section 1.1, >=20 > In some cases, the the problem can be solved by simply > creating new IKE and IPsec SAs after the IP address has > changed. In static multihoming scenarios, it may even be > possible to have several IKE and IPsec SAs simultaneously, > and perform some kind of dynamic routing over them > [RFC3884]. However, this can be problematic for several > reasons. Creating a new IKE_SA may require user > interaction for authentication (entering a code from a > token card, for instance). Creating new SAs often also > involves expensive calculations and possibly a large number > of roundtrips. Due to these reasons, a mechanism for > updating the IP addresses of existing IKE and IPsec SAs is > needed. The MOBIKE protocol described in this document > provides such a mechanism. > > This paragraph is trying to provide the real motivation but > things don't seem well connected. The multihoming and creating > a new IKE SA with user interaction does not seem to go > well. The following is one possible rewording. >=20 > Though the problem can be solved by creating new IKE and > IPsec SAs after the IP address has changed, this may not be > optimal for serveral reasons. In some cases, creating a > new IKE SA may require user interaction for authentication > (entering a code from a token card, for instance). > Creating new SAs often also involves expensive calculations > and possibly a large number of roundtrips. Due to these > reasons, a mechanism for updating the IP addresses of > existing IKE and IPsec SAs is needed. The MOBIKE protocol > described in this document provides such a mechanism. >=20 > And move the static multihoming to the previous paragraph > where different scenarios are described Hmm... I rewrote that to=20 Although the problem can be solved by creating new IKE and IPsec SAs when the addresses need to be changed, this may not be optimal for several reasons. In some cases, creating a new IKE_SA may require user interaction [...] The "when the addresses need to be changed" tries to capture any reasons why the address needs to be changed, mobility or otherwise. > -In section 1.2, >=20 > 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 > better position to decide which of its network interfaces > should be used for both upstream and downstream traffic. >=20 > Can we not talk about NAT also here ? The section does talk about NATs a couple of paragraphs down; I'm not sure if mentioning them already in this point would be necessary.. > -In section 1.2, >=20 > Here MOBIKE assumes that the initiator is the party > "behind" the NAT, and does not fully support the case where > the responder's addresses change when NATs are present. >=20 > What do you mean by "fully" ? There's no special effort done to support it, and in most cases it does not work (and even can't be made to work),=20 but there are some cases where it works anyway (or making it not work would take some extra effort), mainly involving=20 "full cone" NATs. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 05:16:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsGsl-00053Q-L7 for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 05:16:51 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03933 for ; Tue, 12 Jul 2005 05:16:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CA95DFB282; Tue, 12 Jul 2005 05:16:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 38A3FFB27D; Tue, 12 Jul 2005 05:16:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B8420FB281; Tue, 12 Jul 2005 05:16:46 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id D3338FB266 for ; Tue, 12 Jul 2005 05:16:45 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6C9DSwE014780; Tue, 12 Jul 2005 12:13:30 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 12:15:48 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 12:15:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2005 12:15:48 +0300 Message-ID: Thread-Topic: [Mobike] Review of draft-ietf-mobike-protocol-00 Thread-Index: AcWD9EqgRMrWWyPATw2Le4izQkiJ3wCzPb5w From: To: , X-OriginalArrivalTime: 12 Jul 2005 09:15:48.0768 (UTC) FILETIME=[4ADCAA00:01C586C2] Subject: [Mobike] Issue 22: is disabling NAT traversal a possibility (was: Review of draft-ietf-mobike-protocol-00) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Lakshminath Dondeti wrote: >=20 > o If NAT Traversal is supported and NAT detection payloads=20 > were included, enables or disables NAT Traversal. >=20 > I may be wrong, but is disabling NAT Traversal a=20 > possibility here? > Hmm.. any reasons why it wouldn't be? The text is a bit short here, but it roughly means that "if NAT=20 detection payloads show that there's no NAT, then don't use UDP=20 encapsulation for outgoing ESP packets any more" (Or did you mean that it would be better to use some other words than "enable" and "disable" here?) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 05:26:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsH1t-00088Y-Cj for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 05:26:17 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04551 for ; Tue, 12 Jul 2005 05:26:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C032BFB282; Tue, 12 Jul 2005 05:26:15 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 97705FB281; Tue, 12 Jul 2005 05:26:14 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A83EFB282; Tue, 12 Jul 2005 05:26:12 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 851A7FB27D for ; Tue, 12 Jul 2005 05:26:11 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6C9Mq7Q023135; Tue, 12 Jul 2005 12:22:55 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 12:25:27 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 12:25:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2005 12:25:27 +0300 Message-ID: Thread-Topic: [Mobike] Review of draft-ietf-mobike-protocol-00 Thread-Index: AcWD9EqgRMrWWyPATw2Le4izQkiJ3wCziiyw From: To: , X-OriginalArrivalTime: 12 Jul 2005 09:25:27.0099 (UTC) FILETIME=[A392F8B0:01C586C3] Subject: [Mobike] Issue 23: Payload type for addresses (was: Review of draft-ietf-mobike-protocol-00) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Lakshminath Dondeti wrote: > When the initiator receives an INFORMATIONAL request > containing ADDITIONAL_ADDRESS, it stores the information and > also determines whether the currently used path needs to be > changed (for instance, if the currently used address is no > longer included in the list); if it does, the initiator > proceeds as described in the previous section. >=20 > I must say that I don't like overloading the Notification > payload with IP addresses. IKEv2 uses ID payloads for this > purpose, why not use those? IMHO the purpose of ID payloads is very different from this one (they're not usually IP addresses, and even when they are,=20 they're not necessarily addresses that actually appear in any=20 packets). And besides, there are cases when the same message needs to contain both ADDITIONAL_ADDRESS and ID payloads. But we could of course promote ADDITIONAL_ADDRESS from a Notification to a real "top-level" payload type. Any comments from others about this? The main difference seems to be that payload type field is only 8 bits while Notification type is 16 bits. And Notification status types are already overloaded for a dozen different purposes (some of which might have deserved their own "top-level" payload type, BTW), so keeping this as a Notification would=20 at least be in line with the IKEv2 base spec :-) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 06:02:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsHac-0004CC-KD for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 06:02:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07138 for ; Tue, 12 Jul 2005 06:02:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E89D6FB28E; Tue, 12 Jul 2005 06:02:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 10047FB27D; Tue, 12 Jul 2005 06:01:58 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 720BCFB281; Tue, 12 Jul 2005 06:01:56 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 86196FB266 for ; Tue, 12 Jul 2005 06:01:55 -0400 (EDT) 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 j6C9wdmX021013; Tue, 12 Jul 2005 12:58:39 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 13:01:53 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 13:01:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2005 13:01:53 +0300 Message-ID: Thread-Topic: [Mobike] Review of draft-ietf-mobike-protocol-00 Thread-Index: AcWD9EqgRMrWWyPATw2Le4izQkiJ3wCz19Ew From: To: , X-OriginalArrivalTime: 12 Jul 2005 10:01:53.0592 (UTC) FILETIME=[BAD35380:01C586C8] Subject: [Mobike] Issue 24: NAT prevention details (was: Review of draft-ietf-mobike-protocol-00) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Lakshminath Dondeti wrote: >=20 > The labels NAT_PREVENTION, NAT_PREVENTED are confusing. > For a little while I thought they are the same, but realize > they are different. NAT_PREVENTION seem to mean that the > sender is guaranteeing/indicating that there is no NAT. > Perhaps, NAT_NOTSUPPORTED or NAT_ABSENT or something like that > might be more appropriate. Instead of NAT_PREVENTED, > NAT_PRESENT or NAT_DETECTED might be more appropriate. The > Initiator then can compare its claim from its state that > NAT_ABSENT against NAT_PRESENT to detect that its claim is > incorrect. Hmm... here the sender of the NAT_PREVENTION payload (initiator) is informing the responder that its policy is not to use paths that contain NATs. If the responder notices that a NAT is present anyway, the request fails with error code NAT_PREVENTED. But maybe we could figure out better names for these payloads. How about "NAT_PREVENTION_FAILURE" instead of "NAT_PREVENTED"? It would perhaps tell more clearly that it's an error indiciation? Or NO_NAT_POLICY and NAT_POLICY_ERROR? Best regarts, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 06:28:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsI0Z-0003l1-JX for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 06:28:59 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08917 for ; Tue, 12 Jul 2005 06:28:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C8E5BFB282; Tue, 12 Jul 2005 06:28:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 06E72FB27D; Tue, 12 Jul 2005 06:28:53 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8E495FB281; Tue, 12 Jul 2005 06:28:51 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 8BFFAFB266 for ; Tue, 12 Jul 2005 06:28:50 -0400 (EDT) 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 j6CASmxo019833; Tue, 12 Jul 2005 13:28:49 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 13:28:30 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 13:28:27 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2005 13:28:27 +0300 Message-ID: Thread-Topic: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt Thread-Index: AcWF2/G7CJZPJyz1QECua8aRxYzGfgA7OJlA From: To: , X-OriginalArrivalTime: 12 Jul 2005 10:28:27.0208 (UTC) FILETIME=[70B1D480:01C586CC] Subject: [Mobike] Issue 26: Window size and latest_update_counter (was: Comments on draft-ietf-mobike-protocol-00.txt) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Mohan Parthasarathy wrote: > -Section 2.3: >=20 > - Does not explain, what happens when the "window size does > not allow ? It retransmits the existing message with the new > address and responder sends back to the new address but > without updating the SAs ? This is sort of implicit in the > text because the SAs are updated with the new address pair in > the first step and any retransmissions will happen with the > new address. Yes, it keeps retransmitting the outstanding requests using the addresses in the IKE_SA (=3Dthe new addresses). I'll add something about this in -01... > - What is "latest_update_received" counter ? Where else is it > used other than this step? Either the counter is updated or > not. It is not clear what this counter is used for as it just > appears in this step alone. It's not used anywhere else except in this step. The purpose of the counter is to ensure correct behavior if the responder receives several address update requests out of order: it should follow the newest update, and ignore older ones (except that a reply needs to be sent anyway). (Receiving requests out of order can of course only happen with window size greater than 1). But I agree, the text could be clearer. How about changing this o Compares the Message ID with the latest_update_received counter in the IKE_SA. If latest_update_received is greater than the received Message ID, the reply is sent as usual, but no other action is taken; otherwise, updates the latest_update_received counter. to this? o Determines whether it has already received a newer CHANGE_PATH request than this one (if the responder uses a window size greater than one, it is possible that requests are received out of order). If it has, a response message is sent, but no other action is taken. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 07:56:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJNL-0003jZ-FT for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 07:56:35 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13740 for ; Tue, 12 Jul 2005 07:56:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4587CFB283; Tue, 12 Jul 2005 07:56:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9430FFB266; Tue, 12 Jul 2005 07:56:29 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E6BE8FB27D; Tue, 12 Jul 2005 07:56:27 -0400 (EDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by machshav.com (Postfix) with ESMTP id A29A2FB266 for ; Tue, 12 Jul 2005 07:56:26 -0400 (EDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j6CBuPOL000106 for ; Tue, 12 Jul 2005 13:56:25 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j6CBuO27003734 for ; Tue, 12 Jul 2005 13:56:25 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.146]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Jul 2005 13:56:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 24: NAT prevention details (was: Review ofdraft-ietf-mobike-protocol-00) Date: Tue, 12 Jul 2005 13:55:56 +0200 Message-ID: Thread-Topic: [Mobike] Issue 24: NAT prevention details (was: Review ofdraft-ietf-mobike-protocol-00) Thread-Index: AcWD9EqgRMrWWyPATw2Le4izQkiJ3wCz19EwAAU9yUA= From: "Pashalidis, Andreas" To: X-OriginalArrivalTime: 12 Jul 2005 11:56:23.0297 (UTC) FILETIME=[B97D1F10:01C586D8] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Hi all, Regarding the naming of labels. IMHO, one cannot "prevent" a NAT (from being on a path). What one can do is *detect* the presence of a NAT, and, then, possibly *avoid* it (or, more precisely, avoid the continuation of the session). In terms of policies, one cannot have a policy that "prevents" NATs (from being present on a path). Instead, one can have=20 a policy that mandates the *avoidance* of paths on which NATs have been detected. I believe that naming the labels using the above terms=20 is more intuitive than using the term "prevention". Regards, Andreas -----Original Message----- From: mobike-bounces@machshav.com [mailto:mobike-bounces@machshav.com] On Behalf Of Pasi.Eronen@nokia.com Sent: Tuesday, July 12, 2005 12:02 PM To: ldondeti@qualcomm.com; mobike@machshav.com Subject: [Mobike] Issue 24: NAT prevention details (was: Review ofdraft-ietf-mobike-protocol-00) Lakshminath Dondeti wrote: >=20 > The labels NAT_PREVENTION, NAT_PREVENTED are confusing. > For a little while I thought they are the same, but realize > they are different. NAT_PREVENTION seem to mean that the > sender is guaranteeing/indicating that there is no NAT. > Perhaps, NAT_NOTSUPPORTED or NAT_ABSENT or something like that > might be more appropriate. Instead of NAT_PREVENTED, > NAT_PRESENT or NAT_DETECTED might be more appropriate. The > Initiator then can compare its claim from its state that > NAT_ABSENT against NAT_PRESENT to detect that its claim is > incorrect. Hmm... here the sender of the NAT_PREVENTION payload (initiator) is informing the responder that its policy is not to use paths that contain NATs. If the responder notices that a NAT is present anyway, the request fails with error code NAT_PREVENTED. But maybe we could figure out better names for these payloads. How about "NAT_PREVENTION_FAILURE" instead of "NAT_PREVENTED"? It would perhaps tell more clearly that it's an error indiciation? Or NO_NAT_POLICY and NAT_POLICY_ERROR? Best regarts, 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 Jul 12 08:37:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsK0z-00038c-MF for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 08:37:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17264 for ; Tue, 12 Jul 2005 08:37:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 559A4FB284; Tue, 12 Jul 2005 08:37:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CD064FB27D; Tue, 12 Jul 2005 08:37:27 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ECE96FB282; Tue, 12 Jul 2005 08:37:23 -0400 (EDT) Received: from mgw-ext04.nokia.com (mgw-ext04.nokia.com [131.228.20.96]) by machshav.com (Postfix) with ESMTP id 323E2FB27D for ; Tue, 12 Jul 2005 08:37:20 -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 j6CBdYjY000845; Tue, 12 Jul 2005 14:39:37 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 14:44:43 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 14:44:43 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Jul 2005 14:44:43 +0300 Message-ID: Thread-Topic: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt Thread-Index: AcWF2/G7CJZPJyz1QECua8aRxYzGfgA8JV8g From: To: , X-OriginalArrivalTime: 12 Jul 2005 11:44:43.0641 (UTC) FILETIME=[18761690:01C586D7] Subject: [Mobike] Issue 27: Security and path testing (was: Comments on draft-ietf-mobike-protocol-00.txt) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Mohan Parthasarathy wrote: > -Path testing:=20 >- The security impact of this is not discussed in the=20 > Security consideration section ? True, something needs to be added. > - It states that the reason for new message type is to support > window size 1. But it does not state why it can't be secure ?=20 > You can still have a separate window space for this message and=20 > still provide security, right ? This was discussed in the mailing=20 > list. Do you see problems with it ? It certainly would be possible to encrypt and integrity protect the path test messages, but I'm not sure if this would actually improve the security at all. - An attacker can see the contents of the messages, but since they don't actually contain anything interesting, encryption does not help here (e.g. NAT detection payloads are sent in=20 clear even in normal IKEv2). - An attacker could drop the messages and cause the initiator=20 to believe the path does not work (well, that would be a=20 reasonably correct belief in this case). Clearly integrity protection does not help here. - An attacker could modify the contents of the messages.=20 Modifying the COOKIE2 payload has the same effect as dropping=20 the message (initiator thinks the path does not work, reasonably correctly so), so no benefit from integrity protection here either. Modifying the NAT detection payloads seems to have roughly the same effect as modifying the IP header or UDP ports, causing the parties to detect a NAT where one doesn't exist. - An attacker can "manufacture" a path test request: not a=20 problem, since this achieves nothing. - An attacker can "manufacture" a path test response (if it sees the corresponding request): I don't think this is a problem either. If the attacker has a working path to the responder, it could just forward the packet, and let the response come back without manufacturing anything. And the path test message is not used as a substitute for dead peer detection anyway, so if the peer is really dead, an attacker can't hide that. And encrypting and integrity protecting these messages is not as easy as it sounds. For instance, if the response message is lost, and the initiator retransmits the same request, does the new response have to be identical to the previous one? (For normal IKEv2 messages, the answer is yes. But this implies keeping state in the responder, with window mechanism to limit the amount of state that needs to be kept. If the answer would be yes for path test messages as well, how many path test messages would have to be kept?) But perhaps there's some angle I haven't thought about yet; more comments are welcome... Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 10:51:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsM6f-0003Ox-4D for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 10:51:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29819 for ; Tue, 12 Jul 2005 10:51:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8A1D6FB28B; Tue, 12 Jul 2005 10:51:24 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CF073FB27D; Tue, 12 Jul 2005 10:51:16 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E9BEAFB281; Tue, 12 Jul 2005 10:51:14 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 76F99FB262 for ; Tue, 12 Jul 2005 10:51:13 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6CEp2mA028078 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 12 Jul 2005 17:51:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6CEoxxa028075; Tue, 12 Jul 2005 17:50:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17107.55507.331103.64077@fireball.kivinen.iki.fi> Date: Tue, 12 Jul 2005 17:50:59 +0300 From: Tero Kivinen To: Subject: [Mobike] Issue 27: Security and path testing (was: Comments on draft-ietf-mobike-protocol-00.txt) In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 6 min Cc: mohanp@sbcglobal.net, mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > - An attacker could modify the contents of the messages. > > Modifying the COOKIE2 payload has the same effect as dropping > the message (initiator thinks the path does not work, reasonably > correctly so), so no benefit from integrity protection here > either. Nope. The section 2.6 says that if N(COOKIE2) values do not match the IKE_SA MUST be closed... so modifying the path test message COOKIE2, allows easy DoS attack with single modified packet to close the whole connection, and as the path test message only has constant data otherwise, it will cause attacker to be able to create those packets by just knowing IP and port numbers of the connection... Or is the COOKIE2 processing different in the informational exchange and in the path test exchange? If so that is not mentioned in the draft anywhere. > And encrypting and integrity protecting these messages is not as > easy as it sounds. For instance, if the response message is It is actually quite easy, we simply do not use separate exchange for those... Not using separate exchange (i.e. getting rid of PATH_TEST exchange) means that we simply need to define the proper retransmission policy for IKE packets (which we need to do anyways, and which is missing from the document), and we need to say that NO changes to the IKE_SA IP-addresses are done ever unless the there explicit request by CHANGE_PATH nofity from the other end. (I will write more about that along with my comments of the draft). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 10:53:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsM8W-0003qQ-Tg for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 10:53:28 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00166 for ; Tue, 12 Jul 2005 10:53:25 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A3A7AFB284; Tue, 12 Jul 2005 10:53:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9E860FB27D; Tue, 12 Jul 2005 10:53:24 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F22A2FB282; Tue, 12 Jul 2005 10:53:22 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 9E801FB262 for ; Tue, 12 Jul 2005 10:53:21 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6CErEKb028863 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 12 Jul 2005 17:53:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6CErDB8028860; Tue, 12 Jul 2005 17:53:13 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17107.55641.773885.313666@fireball.kivinen.iki.fi> Date: Tue, 12 Jul 2005 17:53:13 +0300 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Subject: [Mobike] Comments to draft-ietf-mobike-design-02.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit I decided to start reading the protocol draft, by first reading the design draft... that way I can see we keep those two in sync. Here is my comments to the design draft: > 5.2.1 Storing a single or multiple addresses ... > The single IP address approach will not work if both peers happen to > loose their IP address at the same time (due to, say, the failure of > one of the links that both nodes are connected to). It may also > require the IKEv2 window size to be larger than 1, especially if only > direct indications are used. This is because the host needs to be > able to send the IP address change notifications before it can switch > to another address, and depending on the return routability checks, > retransmissions policies etc, it might be hard to make the protocol > such that it works with window size of 1 too. Furthermore, the > single IP address approach does not really benefit much from indirect > indications as the peer receiving these indications might not be able > to fix the situation by itself (e.g., even if a peer receives an ICMP > host unreachable message for the old IP address, it cannot try other > IP addresses, since they are unknown). This paragraph here refers to direct and indirect indications, which are defined only in the next section 5.2.2. > 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection Should we have a section about "connectivity tests using completely new protocol (or exchange)"? The current protocol uses that, but we do not have any reason or rational for that, or even mention that as an option... > 5.4 NAT Traversal ... > There is no way to distinguish the cases where there is NAT along the > path that modifies the header information in packets or whether an > adversary mounts an attack. If NAT is detected in the IKE SA > creation, that should automatically disable the MOBIKE extensions and > use NAT-T. I think the last sentence does not anymore reflect the current status of the working group concensus... Perhaps change to "One option would be that if NAT is deteced ..." Btw perhaps it would be also good to check the issue tracker and see if all decided issues there are reflected in this draft too (i.e. add and paragraph at the end of sections saying that "working group decided to select option xxx", as is already done for some sections). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 11:06:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsMLG-0007bh-L4 for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 11:06:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02821 for ; Tue, 12 Jul 2005 11:06:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C7918FB284; Tue, 12 Jul 2005 11:06:35 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DE460FB262; Tue, 12 Jul 2005 11:06:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6E937FB27D; Tue, 12 Jul 2005 11:06:31 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by machshav.com (Postfix) with ESMTP id A9F6BFB240 for ; Tue, 12 Jul 2005 11:06:30 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CF6Odd028770; Tue, 12 Jul 2005 08:06:25 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CF6KRq026424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 08:06:21 -0700 (PDT) Message-ID: <42D3DC6B.4010205@qualcomm.com> Date: Tue, 12 Jul 2005 11:06:19 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com Subject: [Mobike] Re: Issue 24: NAT prevention details (was: Review of draft-ietf-mobike-protocol-00) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Content-Transfer-Encoding: 7bit +++++++++ Or NO_NAT_POLICY and NAT_POLICY_ERROR? Best regarts, Pasi ++++++++++ The above suggestions sound more intuitive. The sender is trying to establish/enforce its local policy of NO_NATs in the way and the receiver helps by saying I detected none, or there was a NAT and therefore your policy cannot be supported. We might wait a little to see if others might have suggestions too (Andreas had some thoughts). thanks, Lakshminath Pasi.Eronen@nokia.com wrote: >Lakshminath Dondeti wrote: > > >> The labels NAT_PREVENTION, NAT_PREVENTED are confusing. >>For a little while I thought they are the same, but realize >>they are different. NAT_PREVENTION seem to mean that the >>sender is guaranteeing/indicating that there is no NAT. >>Perhaps, NAT_NOTSUPPORTED or NAT_ABSENT or something like that >>might be more appropriate. Instead of NAT_PREVENTED, >>NAT_PRESENT or NAT_DETECTED might be more appropriate. The >>Initiator then can compare its claim from its state that >>NAT_ABSENT against NAT_PRESENT to detect that its claim is >>incorrect. >> >> > >Hmm... here the sender of the NAT_PREVENTION payload (initiator) >is informing the responder that its policy is not to use paths >that contain NATs. If the responder notices that a NAT is >present anyway, the request fails with error code NAT_PREVENTED. > >But maybe we could figure out better names for these payloads. >How about "NAT_PREVENTION_FAILURE" instead of "NAT_PREVENTED"? >It would perhaps tell more clearly that it's an error >indiciation? > >Or NO_NAT_POLICY and NAT_POLICY_ERROR? > >Best regarts, >Pasi > > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 11:26:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsMeL-0001pe-QZ for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 11:26:21 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08729 for ; Tue, 12 Jul 2005 11:26:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 811EDFB284; Tue, 12 Jul 2005 11:26:18 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 33AECFB281; Tue, 12 Jul 2005 11:26:14 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B9862FB282; Tue, 12 Jul 2005 11:26:12 -0400 (EDT) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by machshav.com (Postfix) with ESMTP id 73DB7FB262 for ; Tue, 12 Jul 2005 11:26:10 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CFQ62m005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2005 08:26:07 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CFQ150014699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 08:26:03 -0700 (PDT) Message-ID: <42D3E108.2000900@qualcomm.com> Date: Tue, 12 Jul 2005 11:26:00 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Review of draft-ietf-mobike-protocol-00 (issue 21) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com 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 Content-Transfer-Encoding: 7bit Hi Pasi, Please see inline: -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Tue 7/12/2005 1:41 AM To: Dondeti, Lakshminath; mobike@machshav.com Subject: RE: [Mobike] Review of draft-ietf-mobike-protocol-00 (issue 21) Thanks for your review, Lakshminath! I've filed the editorial comments as issue 21 and the more technical comments as issues 22..24 in the issue list: http://www.vpnc.org/ietf-mobike/issues.html I'll reply to the technical comments in separate emails to make the issue tracking easier. Replies to some of the editorial comments: > Abstract > > This document describes the MOBIKE protocol, a mobility and > multihoming extension to IKEv2. The purpose of MOBIKE is to > update the (outer) IP addresses associated with IKE and > IPsec Security Associations (SAs). The main scenario for > MOBIKE is making it possible for a remote access VPN user to > move from one address to another without re-establishing all > security associations with the VPN gateway. > > Perhaps the abstract could be revised to include what's > being done for multihoming as well. The last sentence could > be: MOBIKE allows IPsec end points to change addresses (for > multihoming or due to mobility) without re-establishing all > SAs with peers. (that sentence didn't come out all that well, > but a revision thereof might be better) > Yes, the abstract was written in a bit of an hurry..:-) How about rewriting it to This document describes the MOBIKE protocol, a mobility and multihoming extension to IKEv2. MOBIKE allows mobile and/or multihomed hosts to update the (outer) IP addresses associated with IKE and IPsec Security Associations (SAs). The main scenario for MOBIKE is making it possible for a remote access VPN user to move from one address to another while keeping the VPN connection with the gateway active. Sounds ok. We can revisit that later too. I guess my point was that multihoming is also what this protocol sets out to handle, so as long that gets similar prominence, we are ok. > large amounts of traffic. Second, a "NAT prevention" > feature ensures > > I may have overlooked the discussion on terminology, > but prevention doesn't seem to convey the intended meaning. > Hmm... I agree that NAT prevention is perhaps not the best possible word. Any better suggestions? Would "address integrity protection" be any better..? Comments from anyone else? Address integrity protection sounds fine, but having the word NAT in there might help. Let us see if anyone has some ideas. > Path > > A particular combination of source IP address and > destination IP address (note: this definition does not > consider the route taken by the packets in the network). > > Terminology again: why not use the phrase "address pair" > instead of path. I realize that it results in a large number > of changes in the document, but this is still a -00- > Mainly because "path" is shorter and leads IMHO to more understandable text. RFC 2960 (SCTP) also uses the word "path" with pretty much the same meaning in many places. I read that draft just now and found this definition: "Path: The route taken by the SCTP packets sent by one SCTP endpoint to a specific destination transport address of its peer SCTP endpoint. Sending to different destination transport addresses does not necessarily guarantee getting separate paths." That is closer to the dictionary definition of the word path than MOBIKE uses, no? I think address pair is still better, while not as convenient path, it imparts the correct meaning. > 2.3 Changing path of IPsec SAs > > In MOBIKE, the initiator of the IKE_SA decides what > addresses are used in the IPsec SAs. That is, the responder > never updates any IPsec SAs without receiving an explicit > CHANGE_PATH request from the initiator. (As described > below, the responder can, however, update the IKE_SA in some > circumstances.) > > The description in this section assumes that the initiator > has already decided what the new addresses should be. How > this decision is made is beyond the scope of this > specification. When this decision has been made, the > initiator > > o Updates the IKE_SA and IPsec SAs with the new addresses, > and sets the "pending_update" flag in the IKE_SA. > > o 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. > > o When the window size allows, sends an INFORMATIONAL request > containing the CHANGE_PATH notification payload (which does > not contain any data), and clears the "pending_update" flag. > > Since this is optional, suggest using the keyword MAY or > OPTIONAL Which part are you referring to? Ok, this may be a bit of nitpicking but I am trying to have documents "spell out" what's clearly optional. "When the window size allows" does mean that sending CHANGE_PATH notification is optional. Or are you saying that "when the window size allows" it is a MUST. > o Updates the IP addresses in the IKE_SA and IPsec SAs with > the values from the IP header. > > Suggest adding a sentence here or in a more appropriate > place that the address changes are implicit, in that the new > addresses are not obtained from the IP header, not IKEv2 or > MOBIKE payloads. > Hmm.. it's not "implicit" in the sense that change of address is explicitly requested by the initiator (as opposed to just updating the SAs based on some more vague hints that a change might be needed)... but I'll add something to clarify this. Thanks. > o Replies with an INFORMATIONAL response: > > Initiator Responder > ----------- ----------- > <-- HDR, SK { N(COOKIE2), > [N(NAT_DETECTION_*)] } > > > Should the other optional Notification payloads be present in > this message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are > discussed below, but are not in the above message. > Hmm, actually no, since this step in the process is never reached if the NAT_PREVENTED or UNACCEPTABLE_PATH cases happen (they're already handled in earlier steps). Ok, I should have read a bit more carefully! There is some inconsistency in that page though. The case of UNACCEPTABLE_PATH is inline with the text and the case of NAT_DETECTION_* is specified with headers and such. Please make it consistent in the future versions -- or perhaps use my suggestion and say that the resultant message after considering all the steps would be HDR, SK{N(COOKIE2), [N()], N[]}. Perhaps your way of separating them out is better, but please make it consistent. > 4. 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. In some > specific cases MOBIKE is also capable of protecting address > changes better than existing NAT Traversal procedures. > > Since we cannot use bold or other types of emphasis, I > suggest using subsections so that each of the topics below > stand out. > Hm... they're pretty short to be separate subsections, but I could try changing the indentation from 3 to 6 or something... Others on the list had some suggestions on this section. Let us wait and see how it evolves. At this point, let me say again that you did a great job for a -00-. The draft is already on an excellent path already (hope there are no NATs in the way) :-). cheers, Lakshminath Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 12:37:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNkq-0006ke-K2 for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 12:37:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14188 for ; Tue, 12 Jul 2005 12:37:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 039F8FB28B; Tue, 12 Jul 2005 12:37:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id AB1A3FB27D; Tue, 12 Jul 2005 12:36:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E9124FB281; Tue, 12 Jul 2005 12:32:22 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 381E6FB262 for ; Tue, 12 Jul 2005 12:32:17 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6CGW85V018920 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 12 Jul 2005 19:32:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6CGW5SA018908; Tue, 12 Jul 2005 19:32:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17107.61572.626229.253188@fireball.kivinen.iki.fi> Date: Tue, 12 Jul 2005 19:32:04 +0300 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 96 min X-Total-Time: 98 min X-Mailman-Approved-At: Tue, 12 Jul 2005 12:36:53 -0400 Subject: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit > 1.2 MOBIKE protocol overview ... > One important aspect of this information gathering that has to be > visible in the messages is determining whether a certain pair of > addresses can be used. IKEv2 Dead Peer Detection (DPD) feature can > provide information that the currently used pair does or does not > work. There are, however, some complications in using it for other > addresses, and thus MOBIKE adds a new IKEv2 message that can be used > to "test" whether some particular pair of addresses works or not, > without yet committing to changing the addresses currently in use. I do not agree on that reason. It is very simple to say in the MOBIKE protocol, that implementations MUST NOT do dynamical address update if MOBIKE extensions are enabled, i.e. they MUST always do address updates only when receiving CHANGE_PATH message in case MOBIKE extensions are enabled. That will take care of all the problems using normal IKEv2 packet to test path. > 1.3 Terminology > > Path > > A particular combination of source IP address and destination IP > address (note: this definition does not consider the route taken > by the packets in the network). Any reason why the draft-ietf-mobike-design-02.txt and this document defined Path differently? The Path from the design draft do include the route, the Path here matches the more or less the (operantional) address pair in the design draft. I think we should try to keep them in sync. > 2. MOBIKE protocol exchanges > > 2.1 Signaling support for MOBIKE > > Implementations that wish to use MOBIKE for a particular IKE_SA MUST > include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request > and response messages. > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni, > N(MOBIKE_SUPPORTED), > [N(NAT_DETECTION_*)] --> > > <-- HDR, SAr1, KEr, Nr, > [N(NAT_DETECTION_*)], > [CERTREQ], > N(MOBIKE_SUPPORTED) As we are probably going to follow the IKEv2 document style, which says that payload MUST come in the order they appear in pictures, I think we might want to keep this and IKEv2 documents consistent. The CERTREQ is mentioned in the IKEv2 document, so it's order is fixed, so I would move NAT_DETECTION_*_IP from the reply to the end, i.e: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni, N(MOBIKE_SUPPORTED), [N(NAT_DETECTION_*)] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ], N(MOBIKE_SUPPORTED), [N(NAT_DETECTION_*)] > 2.3 Changing path of IPsec SAs > > In MOBIKE, the initiator of the IKE_SA decides what addresses are > used in the IPsec SAs. That is, the responder never updates any > IPsec SAs without receiving an explicit CHANGE_PATH request from the > initiator. (As described below, the responder can, however, update > the IKE_SA in some circumstances.) I think we should say that responder never updates IKE_SA without explicit CHANGE_PATH. Not by any dynamic updates because of NAT-T code or any other reason. We simpy say that it always keeps the IKE_SA addresses intact. > The description in this section assumes that the initiator has > already decided what the new addresses should be. How this decision > is made is beyond the scope of this specification. When this > decision has been made, the initiator > > o Updates the IKE_SA and IPsec SAs with the new addresses, and sets > the "pending_update" flag in the IKE_SA. > > o 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 assume that this implicitly means that retransmissions sent during that time are sent to new address instead of old one? This is not really mentioned anywhere, and it needs a lot of text more to describe that. That same text is also needed if we want to get rid of the PATH_TEST exchange completely. This text should be enough: ---------------------------------------------------------------------- When sending any IKE packets we first try the operational address pair. If we do not get reply back from that we try all other address pairs until we get reply back, or the exchange times out, in which case the IKE SA is deleted. The order in which the address pairs are tried is implementation specific, and can use information from various places. The other end receiving those packets, should reply to all of them it receives, with the addresses and ports reversed. Recipient of any other packet than N(CHANGE_PATH) MUST NOT cause any update in the IKE_SA or IPsec SA addresses (also in case when NAT-T is used). This way any IKE packet can be used to test weather the path works or not. If during the sending of IKE packet we detect that the operational address pair is not working anymore, the original initiator (not the exchange initiator) should take actions to fix the situation by finding new operational address pair, and sending N(CHANGE_PATH) for the new operational address pair. If it was original initiator who was initiating the IKE exchange, then after the exchange finishes it already knows the new address pair which works, so he can simply send N(CHANGE_PATH) to update to new working operational address pair. If it was original responder who was initiating the IKE exchange, it does NOT do any updates itself, it simply assumes that original initiator seeing IKE packets coming from different address pair than current one is, initiates a DPD test itself to verify weather the operational address pair is working, and after that will fall back to another address pairs, and result update to the operational address pair in initiator, it will then send N(CHANGE_PATH) notify to update the operational address pair. If operational address pair is broken down when we are sending N(CHANGE_PATH) exchange, then it is possible that the responder will be updated to the some other address pair than what initiator originally intended (in case of uni-directional connection, i.e. responder getting the first N(CHANGE_PATH) in, but initiator not getting the reply back, thus trying other addresses, and finally getting reply back). In this case the initiator should immediately update his own operational address pair to the one that is working, and do another N(CHANGE_PATH) exchange with the known working address pair to make sure that the initiator and responder do agree on the address pair. Only after when he gets reply back from the address pair he intended to use in the first place, he can be sure that both peers agree on the address pair. In case NAT-T is enabled then implemenations MUST make sure that initiator does DPD in a way that will take care of the updating the other peers addresses in case the NAT mapping is lost. This means that when initiator who is behind NAT start DPD because of the lack of packets from the other peer, he includes the N(CHANGE_PATH) to the exchange too, to make sure that the other peer will update its mapping. If it does not get reply back using operational address pair, it tries other address pairs, and if it does get reply back it does normal operation, i.e. restarts the N(CHANGE_PATH) for that new operational address pair. ---------------------------------------------------------------------- > Note that if the responder has NAT Traversal enabled, it can update > the addresses in both the IKE_SA and IPsec SAs as usual (if it > implements the "SHOULD" from [IKEv2] Section 2.23. There is no reason for the other end to enable the SHOULD in case the MOBIKE is used. We can simply say that it MUST NOT do the dynamic address updates in case MOBIKE is enabled. > 2.4 Updating additional addresses ... > There is one additional complication: when the responder wants to > send a new additional address list, the currently used path may no > longer work. In this case, the responder uses the additional address > list received from the initiator, the list of its own addresses, and, > if necessary, the path testing feature (see Section 2.5) to determine > a path that works, updates the addresses in the IKE_SA (but not IPsec > SAs), and then sends the INFORMATIONAL request. This is the only > time the responder uses the additional address list received from the > initiator. This is no way only related to the updating addresses, it might be also break down during any other exchange, and if the responder does not do try all address pairs when sending IKE packets, it will cause IKE SA to deleted because of timed out exchange unless the initiators DPD timers are much shorter than responders negotiation timeout timers. I mean if initiator does DPD, and notices that everything is fine, then address pair breaks down, and then responder starts sending some IKE packet. If this IKE packet manages to time out before the next DPD has started, and detected the problem, and found the new working address pair, and sent an address update by N(CHANGE_PATH) then the responder will delete the IKE SA. There are cases where the responder cannot do anything, because of the NATs, so in those cases this will happen anyways, but if there is no NATs preventing original responder for sending packets to original initiator then the original responder can simply try other address pairs, to see if them work. If not, then delete the IKE SA, if one of them work, fine, he did get his operation done, and original initiator probably got some hint about something being wrong... If we decide that we do not need this feature, then we can simply leave out the address lists in the responder side completely, and say that responder will not try to fix any situations, and it will not support break-before-make style movement to new addresses unknown by the initiator. > 2.5 Path testing If we take my previous text in 2.3, then this section would simply say: Any IKE packets can be used for path testing as long as it has property that responder cannot generate reply packet to it without seeing the request packet. Normally any INFORMATIONAL exchange with N(COOKIE2) is enough. > MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing > connectivity. This exchange is not part of any IKE_SA, so it is not > cryptographically protected. It also does not result in the > responder keeping any state. I do not like this non-protected exchange, as its security implications are not known. For example the text below, does not say what to do if the N(COOKIE2) are not matching. The other place said we tear down IKE SA, but we do not want to do it here. > The reason for introducing a new exchange type, instead of using > INFORMATIONAL exchanges, is to simplify implementations by allowing > MOBIKE to work with window size 1. I do not think it will simplify implementations at all. We need the similar processing of the outgoing IKE exchanges anyways, i.e. each IKE exchange needs to be able to be retransmitted using another address pair, thus doing it 2-3 times (first with broken address pair, then detecting that address pair does not work, and finding out new address pair using PATH_TEST and then chaging to that new address pair, and perhaps that new pair broke down before we managed to use it) or 10 times (use the IKE packet to do the PATH_TEST, i.e. iterate through all addess pairs) does not really make it more complicated. We do not need window size above 1 even for those. Also taking care of the dynamic updates in case if NAT-T is easy, we simply say you MUST NOT do those if MOBIKE is enabled. If we simply want to test weather the address pair works we do INFORMATIONAL without N(CHANGE_PATH). > 2.6 Return routability check ... > To ensure that the peer cannot generate the correct INFORMATIONAL > response without seeing the request, a new payload is added to all > INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST > include a COOKIE2 notification payload, and the recipient of an > INFORMATIONAL request MUST copy the payload 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. I donot think we need to moify all INFORMATIONAL exhcnages to include N(COOKIE2), only those that are used for the return routability checks. > There is one additional issue that must be taken into account. If > the destination address in the IKE_SA has been updated after the > INFORMATIONAL request was sent, then it is possible that the request > has been sent to several different addresses. In this case, > receiving the INFORMATIONAL response does not tell which address is > the working one; thus, a new INFORMATIONAL request needs to be sent. This should probably be clarified better, i.e. if we fall back to the other addresses, then the malicious peer can take those later messages that did reach him and send them back using different address pair, i.e. faking the reply of return routability check. There is no description here what should be done in that case. We need to send ACK to the N(CHANGE_PATH) quite soon, we cannot wait for the return routability check to finish, as it might be so that the initiator sends N(CHANGE_PATH) and then address pair stops working, thus we cannot do return routability check, but on the other hand initiator cannot do anything to fix the situation as he might have window size of 1, and cannot send another N(CHANGE_PATH) before the one that is being processed is ACK'ed. So we probably want to return ACK to N(CHANGE_PATH) immediately, but update the actual IP-addresses only after the return routability checks finish, and if during that time we get new N(CHANGE_PATH) we simply change the base address where to do return routability checks. > 2.7 NAT prevention ... > If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but > no NAT_PREVENTION payload, the situation is different since the > initiator may at this point change from port 500 to 4500. In this > case, the responder initializes (local_address, local_port, > peer_address, peer_port) from the first IKE_AUTH request. It may > also decide to perform a return routability check soon after the > IKE_AUTH exchanges have been completed. Why does it need to do the return routability check? IKEv2 NAT-T does not do return routability checks there, why should we do? Note, that the initiator will not see any IPsec packets thus he cannot for example start TCP sessions, as those are not retransmittede to secondary addresses. I cannot really see how he could mount any real attack at this phase. > IKEv2 requires that if an IPsec endpoint discovers a NAT between it > and its correspondent, it MUST send all subsequent traffic to and > from port 4500. To simplify things, implementations that support > both this specification and NAT Traversal MUST change to port 4500 if > the correspondent also supports both, even if no NAT was detected > between them. What does that simplify? In normal case implementations will never do that as it wastes 4 bytes for each IKE packet. > 3. Payload formats > > 3.1 MOBIKE_SUPPORTED notification payload > > The MOBIKE_SUPPORTED notification payload is included in the > IKE_SA_INIT messages to indicate that the implementation supports > this specification. > > The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA > (16396..40959). The Protocol ID field is set to one (1), and SPI > Size is set to zero. There is no data associated with this Notify > type. How about adding 32 bits of data, with the MOBIKE version number, initially 0? Also I think this notify does not relate to existing SA, so the protocol ID should be 0. > 3.2 ADDITIONAL_ADDRESS notification payload > > Both initiator and responder can include ADDITIONAL_ADDRESS payloads > in the IKE_AUTH exchange and INFORMATIONAL exchange request messages; > see Section 2.2 and Section 2.4 for more detailed description. > > The Notify Message Type for ADDITIONAL_ADDRESS is TBD-BY-IANA > (16396..40959). The Protocol ID field is set to one (1), and SPI > Size is set to zero. The data associated with this Notify type is > either an IPv4 address or an IPv6 address; the type is determined by > the payload length. I think it is better to take 2 different notification types for IPv4 and IPv6. Checking the lenght is bad, as then we cannot extend the structure later by adding more information to the notification data. The design draft asks this in the section 5.11, i.e. make the format so we can extend in the future it with new data, like load balancing weight (currently out of scope, but one of the possible future works). Also I think this notify does not relate to existing SA, so the protocol ID should be 0. > 3.3 CHANGE_PATH notification payload > > This payload is included in INFORMATIONAL exchange requests sent by > the initiator of the IKE_SA to update addresses of the IKE_SA and > IPsec SAs (see Section 2.3). > > The Notify Message Type for CHANGE_PATH is TBD-BY-IANA > (16396..40959). The Protocol ID field is set to one (1), and SPI > Size is set to zero. There is no data associated with this Notify > type. Also I think this notify does not relate to existing SA, so the protocol ID should be 0. > 3.4 UNACCEPTABLE_PATH notification payload > > The responder can include this notification payload in an > INFORMATIONAL exchange response to indicate that the address change > in the corresponding request message (which contained a CHANGE_PATH > notification payload) was not carried out. > > The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA > (40..8191). The Protocol ID field is set to one (1), and SPI Size is > set to zero. There is no data associated with this Notify type. There is a problem in case the UNACCEPTABLE_PATH is not for address in the IP header but some other address pair. I mean the initiator sends packet with IPA1, IPB1 N(CHANGE_PATH). That reaches the responder, but he decides to send N(UNACCEPTABLE_PATH) back. The reply never reaches the initiator because of uni-directional connection or something. The initiator retransmits the packet with IPA2, IPB2 N(CHANGE_PATH). This would be ok for the responder, but as he has already generated the reply N(UNACCEPTABLE_PATH) he will retransmit that back. This will reach the initiator and he will be receiving wrong information which path was unacceptable. Fixing this is quite simply, we add the address pair that was unacceptable to the notify data. In case there is NAT in the path the responder might not recognize all the addresses, but in case of no NATs it immediately knows which address pair wasn't acceptable. Also I think this notify does not relate to existing SA, so the protocol ID should be 0. > 3.5 COOKIE2 notification payload > > This payload is included in all INFORMATIONAL exchange messages for > return routability check purposes (see Section 2.6). It is also used > in PATH_TEST messages to match requests and responses (see > Section 2.5). I would say we define this in more generic way: ---------------------------------------------------------------------- This payload MAY be included in any IKEv2 exchange. The data associated with this notification MUST be between 8 and 64 octets in length (inclusive), and MUST be chosen in a way that is unpredictable to the recipient. The recipient MUST copy this notification to his reply packet. The negotation initiator MUST then check that the N(COOKIE2) received from the other peer matches the one he sent out. This message MUST be included in the IKE exchanges used as a return routability check. The Notify Message Type for this message is TBD-BY-IANA (16396..40959). The Protocol ID field is set to zero (0), and SPI Size is set to zero. ---------------------------------------------------------------------- (already changed protocol id to zero). > 3.6 NAT_PREVENTION notification payload > > See Section 2.7 for a description of this payload. > > The data associated with this notification is the SHA-1 hash > [FIPS180-2] of the following data: IKE SPIs (in the order they appear > in the header), the IP address and port from which the packet was > sent, and the IP address and port to which the packet was sent. The > Notify Message Type for this message is TBD-BY-IANA (16396..40959). > The Protocol ID field is set to one (1), and SPI Size is set to zero. Also I think this notify does not relate to existing SA, so the protocol ID should be 0. > 3.7 NAT_PREVENTED notification payload > > See Section 2.7 for a description of this payload. > > The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191). > The Protocol ID field is set to one (1), and SPI Size is set to zero. > There is no data associated with this Notify type. Also I think this notify does not relate to existing SA, so the protocol ID should be 0. > 4. Security considerations ... > Protection of MOBIKE payloads > > The payloads used in MOBIKE are encrypted, integrity protected, > and replay protected. This assures that no one except the > participants can, for instance, give a control message to change > the addresses. This is not true, as PATH_TEST packets in the current document are not encrypted or proteced. This should be mentioned here, and security analysis of all possible attacks this new protocol might cause should be done. I remember that I promised to write a section describing how to do the protocol without nerw PATH_TEST protocol, but instead of using the any IKE packets with that, and with working for window size 1. The text up there in section 2.3 comments should actually be enough. I do not think we need more text, but we can remove all references to the PATH_TEST exchange. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 12:41:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNpS-0007Qk-Ff for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 12:41:54 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14447 for ; Tue, 12 Jul 2005 12:41:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 08E93FB28A; Tue, 12 Jul 2005 12:41:52 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 47CDAFB283; Tue, 12 Jul 2005 12:41:51 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 930CFFB284; Tue, 12 Jul 2005 12:41:49 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 36CD1FB281 for ; Tue, 12 Jul 2005 12:41:48 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6CGfel1023011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 12 Jul 2005 19:41:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6CGfeLm023008; Tue, 12 Jul 2005 19:41:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17107.62148.321038.301417@fireball.kivinen.iki.fi> Date: Tue, 12 Jul 2005 19:41:40 +0300 From: Tero Kivinen To: mobike@machshav.com X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min Subject: [Mobike] Re: Comments to draft-ietf-mobike-protocol-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Note, that my mail about the comments to the draft-ietf-mobike-protocol-00.txt was too big (22715 bytes) for the anti-virus filters we have for the mailing list (10kB) so it needed approval. This means that if you reply to that and do not trim the replies back all the replies will also be caught by the same filter. So when replying to it please try to trim down and remove lines or sections not needed. I will try to approve those emails that go to queue waiting for approval for being to big as quickly as I can, but it might cause 10-15 hour delay before it is approved. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 23:00:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXUN-0006bX-Vt for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 23:00:48 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19729 for ; Tue, 12 Jul 2005 23:00:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 99B48FB283; Tue, 12 Jul 2005 23:00:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 569B4FB27D; Tue, 12 Jul 2005 23:00:43 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 66ACFFB281; Tue, 12 Jul 2005 23:00:41 -0400 (EDT) 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 35EBBFB266 for ; Tue, 12 Jul 2005 23:00:40 -0400 (EDT) Received: (qmail 35682 invoked from network); 13 Jul 2005 03:00:39 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.205 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2005 03:00:38 -0000 Message-ID: <00a001c58757$0b710d30$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Subject: Re: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt (issue 25) Date: Tue, 12 Jul 2005 20:00:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Fine with the changes you proposed. -mohan ----- Original Message ----- From: To: ; Sent: Tuesday, July 12, 2005 2:08 AM Subject: RE: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt (issue 25) Hi Mohan, I've filed your comments as issues 25 (editorial), 26 (window size/latest_update counter), 27 (security and path testing) and 24 (details of NAT prevention) I'll start with the editorial ones: > - section 1.1, > > In some cases, the the problem can be solved by simply > creating new IKE and IPsec SAs after the IP address has > changed. In static multihoming scenarios, it may even be > possible to have several IKE and IPsec SAs simultaneously, > and perform some kind of dynamic routing over them > [RFC3884]. However, this can be problematic for several > reasons. Creating a new IKE_SA may require user > interaction for authentication (entering a code from a > token card, for instance). Creating new SAs often also > involves expensive calculations and possibly a large number > of roundtrips. Due to these reasons, a mechanism for > updating the IP addresses of existing IKE and IPsec SAs is > needed. The MOBIKE protocol described in this document > provides such a mechanism. > > This paragraph is trying to provide the real motivation but > things don't seem well connected. The multihoming and creating > a new IKE SA with user interaction does not seem to go > well. The following is one possible rewording. > > Though the problem can be solved by creating new IKE and > IPsec SAs after the IP address has changed, this may not be > optimal for serveral reasons. In some cases, creating a > new IKE SA may require user interaction for authentication > (entering a code from a token card, for instance). > Creating new SAs often also involves expensive calculations > and possibly a large number of roundtrips. Due to these > reasons, a mechanism for updating the IP addresses of > existing IKE and IPsec SAs is needed. The MOBIKE protocol > described in this document provides such a mechanism. > > And move the static multihoming to the previous paragraph > where different scenarios are described Hmm... I rewrote that to Although the problem can be solved by creating new IKE and IPsec SAs when the addresses need to be changed, this may not be optimal for several reasons. In some cases, creating a new IKE_SA may require user interaction [...] The "when the addresses need to be changed" tries to capture any reasons why the address needs to be changed, mobility or otherwise. > -In section 1.2, > > 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 > better position to decide which of its network interfaces > should be used for both upstream and downstream traffic. > > Can we not talk about NAT also here ? The section does talk about NATs a couple of paragraphs down; I'm not sure if mentioning them already in this point would be necessary.. > -In section 1.2, > > Here MOBIKE assumes that the initiator is the party > "behind" the NAT, and does not fully support the case where > the responder's addresses change when NATs are present. > > What do you mean by "fully" ? There's no special effort done to support it, and in most cases it does not work (and even can't be made to work), but there are some cases where it works anyway (or making it not work would take some extra effort), mainly involving "full cone" NATs. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 23:02:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXW5-0007dp-Ja for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 23:02:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19822 for ; Tue, 12 Jul 2005 23:02:31 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 84713FB28B; Tue, 12 Jul 2005 23:02:30 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C7C02FB281; Tue, 12 Jul 2005 23:02:25 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 091FEFB282; Tue, 12 Jul 2005 23:02:23 -0400 (EDT) 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 700C9FB27D for ; Tue, 12 Jul 2005 23:02:21 -0400 (EDT) Received: (qmail 31825 invoked from network); 13 Jul 2005 03:02:21 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.205 with login) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2005 03:02:20 -0000 Message-ID: <00a801c58757$481afd40$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Subject: Re: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt (issue 25) Date: Tue, 12 Jul 2005 20:02:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi, For the NAT prevention, we should at least try to provide details on what happens when we move from "NO-NAT" to "NAT" and "NAT" to "NO-NAT". -mohan ----- Original Message ----- From: To: ; Sent: Tuesday, July 12, 2005 2:08 AM Subject: RE: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt (issue 25) Hi Mohan, I've filed your comments as issues 25 (editorial), 26 (window size/latest_update counter), 27 (security and path testing) and 24 (details of NAT prevention) I'll start with the editorial ones: > - section 1.1, > > In some cases, the the problem can be solved by simply > creating new IKE and IPsec SAs after the IP address has > changed. In static multihoming scenarios, it may even be > possible to have several IKE and IPsec SAs simultaneously, > and perform some kind of dynamic routing over them > [RFC3884]. However, this can be problematic for several > reasons. Creating a new IKE_SA may require user > interaction for authentication (entering a code from a > token card, for instance). Creating new SAs often also > involves expensive calculations and possibly a large number > of roundtrips. Due to these reasons, a mechanism for > updating the IP addresses of existing IKE and IPsec SAs is > needed. The MOBIKE protocol described in this document > provides such a mechanism. > > This paragraph is trying to provide the real motivation but > things don't seem well connected. The multihoming and creating > a new IKE SA with user interaction does not seem to go > well. The following is one possible rewording. > > Though the problem can be solved by creating new IKE and > IPsec SAs after the IP address has changed, this may not be > optimal for serveral reasons. In some cases, creating a > new IKE SA may require user interaction for authentication > (entering a code from a token card, for instance). > Creating new SAs often also involves expensive calculations > and possibly a large number of roundtrips. Due to these > reasons, a mechanism for updating the IP addresses of > existing IKE and IPsec SAs is needed. The MOBIKE protocol > described in this document provides such a mechanism. > > And move the static multihoming to the previous paragraph > where different scenarios are described Hmm... I rewrote that to Although the problem can be solved by creating new IKE and IPsec SAs when the addresses need to be changed, this may not be optimal for several reasons. In some cases, creating a new IKE_SA may require user interaction [...] The "when the addresses need to be changed" tries to capture any reasons why the address needs to be changed, mobility or otherwise. > -In section 1.2, > > 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 > better position to decide which of its network interfaces > should be used for both upstream and downstream traffic. > > Can we not talk about NAT also here ? The section does talk about NATs a couple of paragraphs down; I'm not sure if mentioning them already in this point would be necessary.. > -In section 1.2, > > Here MOBIKE assumes that the initiator is the party > "behind" the NAT, and does not fully support the case where > the responder's addresses change when NATs are present. > > What do you mean by "fully" ? There's no special effort done to support it, and in most cases it does not work (and even can't be made to work), but there are some cases where it works anyway (or making it not work would take some extra effort), mainly involving "full cone" NATs. 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 Jul 12 23:04:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXXb-0008Ut-4o for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 23:04:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19900 for ; Tue, 12 Jul 2005 23:04:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7E2B0FB28E; Tue, 12 Jul 2005 23:04:05 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D3943FB282; Tue, 12 Jul 2005 23:04:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C65C9FB284; Tue, 12 Jul 2005 23:04:00 -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 9F30EFB281 for ; Tue, 12 Jul 2005 23:03:59 -0400 (EDT) Received: (qmail 74610 invoked from network); 13 Jul 2005 03:03:59 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.205 with login) by smtp112.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2005 03:03:58 -0000 Message-ID: <00b201c58757$828f6fb0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Date: Tue, 12 Jul 2005 20:03:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: [Mobike] Re: Issue 26: Window size and latest_update_counter (was: Comments on draft-ietf-mobike-protocol-00.txt) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit The text looks fine to me. -mohan ----- Original Message ----- From: To: ; Sent: Tuesday, July 12, 2005 3:28 AM Subject: Issue 26: Window size and latest_update_counter (was: Comments on draft-ietf-mobike-protocol-00.txt) Mohan Parthasarathy wrote: > -Section 2.3: > > - Does not explain, what happens when the "window size does > not allow ? It retransmits the existing message with the new > address and responder sends back to the new address but > without updating the SAs ? This is sort of implicit in the > text because the SAs are updated with the new address pair in > the first step and any retransmissions will happen with the > new address. Yes, it keeps retransmitting the outstanding requests using the addresses in the IKE_SA (=the new addresses). I'll add something about this in -01... > - What is "latest_update_received" counter ? Where else is it > used other than this step? Either the counter is updated or > not. It is not clear what this counter is used for as it just > appears in this step alone. It's not used anywhere else except in this step. The purpose of the counter is to ensure correct behavior if the responder receives several address update requests out of order: it should follow the newest update, and ignore older ones (except that a reply needs to be sent anyway). (Receiving requests out of order can of course only happen with window size greater than 1). But I agree, the text could be clearer. How about changing this o Compares the Message ID with the latest_update_received counter in the IKE_SA. If latest_update_received is greater than the received Message ID, the reply is sent as usual, but no other action is taken; otherwise, updates the latest_update_received counter. to this? o Determines whether it has already received a newer CHANGE_PATH request than this one (if the responder uses a window size greater than one, it is possible that requests are received out of order). If it has, a response message is sent, but no other action is taken. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jul 12 23:18:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsXlp-0007Yv-Iz for mobike-archive@megatron.ietf.org; Tue, 12 Jul 2005 23:18:49 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20715 for ; Tue, 12 Jul 2005 23:18:46 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DDF50FB289; Tue, 12 Jul 2005 23:18:47 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E2CE0FB283; Tue, 12 Jul 2005 23:18:45 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 740FBFB284; Tue, 12 Jul 2005 23:18:44 -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 2620CFB282 for ; Tue, 12 Jul 2005 23:18:43 -0400 (EDT) Received: (qmail 76153 invoked from network); 13 Jul 2005 03:18:42 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.205 with login) by smtp110.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2005 03:18:42 -0000 Message-ID: <00bc01c58759$90ec46d0$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Date: Tue, 12 Jul 2005 20:18:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: [Mobike] Re: Issue 27: Security and path testing (was: Comments on draft-ietf-mobike-protocol-00.txt) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit - An attacker can "manufacture" a path test response (if it sees the corresponding request): I don't think this is a problem either. If the attacker has a working path to the responder, it could just forward the packet, and let the response come back without manufacturing anything. And the path test message is not used as a substitute for dead peer detection anyway, so if the peer is really dead, an attacker can't hide that. mohanp> This is the one i was mainly concerned with. DPD is mohanp> done only for the already working path. If we need mohanp> to know whether an alternate path (.e.g cheaper path) mohanp> works or not, we need to send PATH_TEST message mohanp> If you get a false response e.g. when it mohanp> is not working, attacker sending a response back can cause mohanp> a failover unncessarily. Yes, DPD now can now mohanp> detect this and fail back to the other path. But the mohanp> other path (which was working and still working) can be mohanp> "failed" by the attacker by sending a false response. mohanp> I think this is undesirable. So, i see the PATH_TEST message mohanp> as DPD but sent with different address pair. And encrypting and integrity protecting these messages is not as easy as it sounds. For instance, if the response message is lost, and the initiator retransmits the same request, does the new response have to be identical to the previous one? (For normal IKEv2 messages, the answer is yes. But this implies keeping state in the responder, with window mechanism to limit the amount of state that needs to be kept. If the answer would be yes for path test messages as well, how many path test messages would have to be kept?) mohanp> Why do we need to keep state on the responder for mohanp> sending back same response to a PATH_TEST message? mohanp> The response is an empty message back to the addresses mohanp> where it came from. NAT-detection is also stateless. mohanp> So, i am missing something here.. -mohan But perhaps there's some angle I haven't thought about yet; more comments are welcome... Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 01:14:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsZZP-00014r-LC for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 01:14:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27085 for ; Wed, 13 Jul 2005 01:14:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F05FEFB284; Wed, 13 Jul 2005 01:14:02 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 324E6FB27D; Wed, 13 Jul 2005 01:13:57 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 75A94FB281; Wed, 13 Jul 2005 01:13:55 -0400 (EDT) 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 3D9E4FB266 for ; Wed, 13 Jul 2005 01:13:54 -0400 (EDT) Received: (qmail 79841 invoked from network); 13 Jul 2005 05:13:53 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.160.53.205 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 13 Jul 2005 05:13:53 -0000 Message-ID: <014801c58769$a759c040$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" , References: <17107.61572.626229.253188@fireball.kivinen.iki.fi> Subject: Re: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Date: Tue, 12 Jul 2005 22:13:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit > > If it was original responder who was initiating the IKE > exchange, it does NOT do any updates itself, it simply assumes > that original initiator seeing IKE packets coming from > different address pair than current one is, initiates a DPD > test itself to verify weather the operational address pair is > working, and after that will fall back to another address > As the responder does not know whether there is a NAT in this new path, he can only hope that it works. > pairs, and result update to the operational address pair in > initiator, it will then send N(CHANGE_PATH) notify to update > the operational address pair. > > > In case NAT-T is enabled then implemenations MUST make sure > that initiator does DPD in a way that will take care of the > updating the other peers addresses in case the NAT mapping is > lost. This means that when initiator who is behind NAT start > DPD because of the lack of packets from the other peer, he This step is confusing to me. I may want to test a new path even when the current path is working. The usage of word "DPD" is confusing here. The intiator just sends a message that looks like DPD (we need to invent a better name for MOBIKE) with new addresses. > includes the N(CHANGE_PATH) to the exchange too, to make sure > that the other peer will update its mapping. If it does not Don't you have to first detect NAT in the new path ? The other end updates only if the initiator is behind NAT. As there are multiple paths and only some paths may be behind a NAT, the initiator can update only if a NAT was detected on this new path ? So, i should be able to test new PATHs with NAT-D payloads without using CHANGE_PATH message also ? -mohan > get reply back using operational address pair, it tries other > address pairs, and if it does get reply back it does normal > operation, i.e. restarts the N(CHANGE_PATH) for that new > operational address pair. > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 04:25:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DscYz-0008UR-AT for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 04:25:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14577 for ; Wed, 13 Jul 2005 04:25:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 48F54FB283; Wed, 13 Jul 2005 04:25:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 12862FB27D; Wed, 13 Jul 2005 04:25:49 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 603B7FB281; Wed, 13 Jul 2005 04:25:47 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 3D0EBFB266 for ; Wed, 13 Jul 2005 04:25:46 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6D8PX22015502 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Jul 2005 11:25:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6D8PSRE015499; Wed, 13 Jul 2005 11:25:28 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17108.53240.119932.537256@fireball.kivinen.iki.fi> Date: Wed, 13 Jul 2005 11:25:28 +0300 From: Tero Kivinen To: Subject: [Mobike] Issue 24: NAT prevention details (was: Review of draft-ietf-mobike-protocol-00) In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min Cc: mobike@machshav.com, ldondeti@qualcomm.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > that contain NATs. If the responder notices that a NAT is > present anyway, the request fails with error code NAT_PREVENTED. NAT_PREVENTED would say that you somehow managed to get rid of the NAT... If you can get that one working in a way, that it will actually remove the physical NAT, som people would be more than happy :-) > But maybe we could figure out better names for these payloads. > How about "NAT_PREVENTION_FAILURE" instead of "NAT_PREVENTED"? > It would perhaps tell more clearly that it's an error > indiciation? NAT_PREVENTION_FAILURE indicates that you failed to prevent nat... > Or NO_NAT_POLICY and NAT_POLICY_ERROR? Hmm... NO_NAT_BY_POLICY or something like that could be possible... but perhaps having word POLICY there is too dangerous... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 05:04:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsdAd-0001LS-Va for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 05:04:48 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16609 for ; Wed, 13 Jul 2005 05:04:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 01060FB266; Wed, 13 Jul 2005 05:04:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 88C4AFB27D; Wed, 13 Jul 2005 05:04:39 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EE8E5FB281; Wed, 13 Jul 2005 05:04:37 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id D74FCFB266 for ; Wed, 13 Jul 2005 05:04:35 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6D94XlH018464 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 13 Jul 2005 12:04:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6D94WuT018461; Wed, 13 Jul 2005 12:04:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17108.55584.151056.864627@fireball.kivinen.iki.fi> Date: Wed, 13 Jul 2005 12:04:32 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt In-Reply-To: <014801c58769$a759c040$6501a8c0@adithya> References: <17107.61572.626229.253188@fireball.kivinen.iki.fi> <014801c58769$a759c040$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 25 min X-Total-Time: 24 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > > If it was original responder who was initiating the IKE > > exchange, it does NOT do any updates itself, it simply assumes > > that original initiator seeing IKE packets coming from > > different address pair than current one is, initiates a DPD > > test itself to verify weather the operational address pair is > > working, and after that will fall back to another address > > > As the responder does not know whether there is a NAT > in this new path, he can only hope that it works. Yes. If there is restricted NAT between and the path breaks down, the original responder can try to send updates or something, but most likely he needs to wait for the initiator to detect the problem, and just hope he does not time out his negotiations before that. > > In case NAT-T is enabled then implemenations MUST make sure > > that initiator does DPD in a way that will take care of the > > updating the other peers addresses in case the NAT mapping is > > lost. This means that when initiator who is behind NAT start > > DPD because of the lack of packets from the other peer, he > > This step is confusing to me. I may want to test a new path > even when the current path is working. The usage of word > "DPD" is confusing here. The intiator just sends a message that > looks like DPD (we need to invent a better name for MOBIKE) > with new addresses. Path testing can be done with empty INFORMATIONAL exchange (or one having COOKIE2). That will not have any effect on the other end. DPD (dead peer detection) can be also done with similar packets. The operational address pair updates are done with INFORMATIONAL having COOKIE2 and CHANGE_PATH. The difference between path test and DPD is really why you are doing that. Path testing is done when you want to see if some of the other paths works without modifying the path. DPD is done when you want to make sure that some of the paths work, i.e. after you have some reason to belive that something is wrong. Operational address pair update is done when you know you want to change to some new operational address pair (and you already know it works because of path test or some other exchange). If the initiator is behind the NAT, the DPD can also be used to do to simulate the dynamic updates of the non MOBIKE NAT-T, by so that we send the INFORMATIONAL exchange with COOKIE2 and CHANGE_PATH message as a DPD message, when we suspect that something is wrong. This is really like using the operational address pair update messages as a DPD just to make sure the operational address pair matches the NAT mapping in the NAT box. I.e. if host A is behind NAT, and host B is the gateway, and host A and B has MOBIKE IPsec connection established between them. Then the NAT box is rebooted. The host B will detect that host A starts using new IP-address, but because this is MOBIKE NAT-T he does not do anything, simply continues using the old address pair (his packets will be dropped by NAT). The Host A notices that he is not getting any messages (IKE or IPsec) back, and starts DPD to verify that everything is ok. He sends DPD (or actually operationl address pair update packet is used as DPD) with COOKIE2 and CHANGE_PATH to the host B. Host B receives that, and replies to it, and in the same time also updates the operational address pair to this new one. After that host A can see reply and the packets start flowing again, and situation is fixed. Note, that is is very corner case and the reboot of the NAT did already caused packets to be lost. I.e. the reboot time of the NAT box could be 30 seconds, and MOBIKE recovery may add another ten seconds to that (as the Host A might have already noticed during that 30 seconds that he is not getting anything, and might have already started DPD before the NAT even was up again). > > includes the N(CHANGE_PATH) to the exchange too, to make sure > > that the other peer will update its mapping. If it does not > > Don't you have to first detect NAT in the new path ? Not really, as the we are talking about already existing connection, with the address pair we have been using before. I mean I do not really see cases where someone could remove NAT from the path, in a such way that your IP-address still would remain same. I do not remember what we decided (or if this was even decided), but I think we should say that adding or removing NAT to/from the already working address pair (without changing the addresses) is something we do not need to support. > The other end updates only if the initiator is behind NAT. With my modification the NAT-T would never do automatic update if MOBIKE is enabled, and other peer would update if and only if he sees the N(CHANGE_PATH) notify. > As there are multiple paths and only some paths may be behind a NAT, > the initiator can update only if a NAT was detected on this new > path? The text I was writing there talked about the current operational address pair having NAT and how to recover that NAT being rebooted. If we have new address pairs that may or may not have NATs that is completely different case, and is handled with the text above. > So, i should be able to test new PATHs with NAT-D payloads without > using CHANGE_PATH message also ? Sure. Path tests should have NAT-D payloads, and also COOKIE2 payloads. They MUST NOT have CHANGE_PATH as that would not be path test anymore, as they would then be a real update for the operational address pair instead of path test. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 08:10:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsg4b-0001E6-Oj for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 08:10:45 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00512 for ; Wed, 13 Jul 2005 08:10:44 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2739EFB27D; Wed, 13 Jul 2005 08:10:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A4269FB266; Wed, 13 Jul 2005 08:10:39 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6748CFB27C; Wed, 13 Jul 2005 08:10:37 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id 21EE3FB24A for ; Wed, 13 Jul 2005 08:10:36 -0400 (EDT) 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 j6DCASHU025349; Wed, 13 Jul 2005 15:10:32 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 15:10:11 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 15:10:11 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Review of draft-ietf-mobike-protocol-00 (issue 21) Date: Wed, 13 Jul 2005 15:10:11 +0300 Message-ID: Thread-Topic: [Mobike] Review of draft-ietf-mobike-protocol-00 (issue 21) Thread-Index: AcWG9i0fJHKnNRY+QhGjALp4yc4U/QAqyWkw From: To: X-OriginalArrivalTime: 13 Jul 2005 12:10:11.0586 (UTC) FILETIME=[D199BE20:01C587A3] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Lakshminath Dondeti wrote: > > Terminology again: why not use the phrase "address pair" > > instead of path. I realize that it results in a large number > > of changes in the document, but this is still a -00- > > >=20 > Mainly because "path" is shorter and leads IMHO to more > understandable text. RFC 2960 (SCTP) also uses the word "path" > with pretty much the same meaning in many places. >=20 > > I read that draft just now and found this definition: >=20 > "Path: The route taken by the SCTP packets sent by one SCTP > endpoint to a specific destination transport address of=20 > its peer SCTP endpoint. Sending to different destination=20 > transport addresses does not necessarily guarantee getting=20 > separate paths." >=20 > That is closer to the dictionary definition of the word path > than MOBIKE uses, no? I think address pair is still better, > while not as convenient path, it imparts the correct meaning. > Well, RFC 2960 continues at that point: "Primary Path: The primary path is the destination and source address that will be...", so it's also using the word path to refer to an address pair in some cases. > > o When the window size allows, sends an INFORMATIONAL=20 > > request containing the CHANGE_PATH notification payload=20 > > (which does not contain any data), and clears the=20 > > "pending_update" flag. > > > > Since this is optional, suggest using the keyword MAY=20 > > or OPTIONAL >=20 > Which part are you referring to? >=20 > > Ok, this may be a bit of nitpicking but I am trying to have > documents "spell out" what's clearly optional. "When the > window size allows" does mean that sending CHANGE_PATH > notification is optional. Or are you saying that "when the > window size allows" it is a MUST. > That text is part of the process the initiator follows when it already has decided to change the path; that involves sending a CHANGE_PATH notification, so it's not optional (once you've made the decision). "When the window size allows" simply means that initiator may have to wait for responses to previous requests before it can send a new request. Since it's just descriptive text and not a new requirement, probably there's no need for any RFC 2119 keywords. > > o Replies with an INFORMATIONAL response: > > > > Initiator Responder > > ----------- ----------- > > <-- HDR, SK { N(COOKIE2), > > [N(NAT_DETECTION_*)] } > > > > > > Should the other optional Notification payloads be present in > > this message as well? NAT_PREVENTED, UNACCEPTABLE_PATH are > > discussed below, but are not in the above message. > > >=20 > Hmm, actually no, since this step in the process is never > reached if the NAT_PREVENTED or UNACCEPTABLE_PATH cases happen > (they're already handled in earlier steps). >=20 > > Ok, I should have read a bit more carefully! There is some > inconsistency in that page though. The case of > UNACCEPTABLE_PATH is inline with the text and the case of > NAT_DETECTION_* is specified with headers and such. Please > make it consistent in the future versions -- or perhaps use my > suggestion and say that the resultant message after > considering all the steps would be HDR, SK{N(COOKIE2), [N()], > N[]}. Perhaps your way of separating them out is better, but > please make it consistent. > Currently the logic is that the "normal case" (when everything succeeds) is shown in a separate message diagram, but error cases (which hopefully occur only rarely) are described in-line with the text. But I'll try to make it more consistent in future versions.. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 09:09:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsgzC-0004hr-Df for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 09:09:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04673 for ; Wed, 13 Jul 2005 09:09:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 783BBFB27C; Wed, 13 Jul 2005 09:09:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 78904FB24A; Wed, 13 Jul 2005 09:09:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A4792FB266; Wed, 13 Jul 2005 09:08:59 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id C8517FB249 for ; Wed, 13 Jul 2005 09:08:58 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6DD8uhJ008444; Wed, 13 Jul 2005 16:08:57 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 16:08:53 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 16:08:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Date: Wed, 13 Jul 2005 16:08:53 +0300 Message-ID: Thread-Topic: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Thread-Index: AcWHAIA+aQqcB46ESLeA680R+6D05wAqxbrw From: To: , X-OriginalArrivalTime: 13 Jul 2005 13:08:53.0583 (UTC) FILETIME=[04DFD5F0:01C587AC] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Wow, that was a _lot_ of comments (nearly as long as the protocol draft itself :-). I've filed your comments=20 in the issue list as follows: - Separate ADDITIONAL_ADDRESS payloads for IPv4 and IPv6:=20 added this to existing issue 23 - Security of path test messages: added to existing issue 27. - Mostly editorial things: new issue 29 - Protocol ID in notifications: new issue 30 - Responder address changes: new issue 31 - Omitting COOKIE2 from non-RR messages: new issue 32 - Changing ports 500/4500 and RR: new issue 33 - Separate path test, handling changes in NAT mappings: new issue 34 - Adding version number to MOBIKE_SUPPORTED: new issue 35. - Handling UNACCEPTABLE_PATH: new issue 36 Please include the issue number in the subject line when=20 discussing these! (I'll reply to each of these separately..) Best regards, Pasi > -----Original Message----- > From: Tero Kivinen > Sent: Tuesday, July 12, 2005 7:32 PM > To: mobike@machshav.com > Subject: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 09:23:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DshD7-00030S-Tf for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 09:23:37 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05748 for ; Wed, 13 Jul 2005 09:23:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 95E4CFB281; Wed, 13 Jul 2005 09:23:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DDC35FB262; Wed, 13 Jul 2005 09:23:29 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C1558FB27C; Wed, 13 Jul 2005 09:23:28 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id A3008FB24A for ; Wed, 13 Jul 2005 09:23:27 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6DDNQ61022362; Wed, 13 Jul 2005 16:23:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 16:23:26 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 16:23:22 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2005 16:23:22 +0300 Message-ID: Thread-Topic: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Thread-Index: AcWHAIA+aQqcB46ESLeA680R+6D05wAq66Rg From: To: , X-OriginalArrivalTime: 13 Jul 2005 13:23:22.0559 (UTC) FILETIME=[0AD30CF0:01C587AE] Subject: [Mobike] Issue 30: Protocol ID in notifications X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > > 3. Payload formats > >=20 > > 3.1 MOBIKE_SUPPORTED notification payload > >=20 > > The MOBIKE_SUPPORTED notification payload is included in > > the IKE_SA_INIT messages to indicate that the implementation > > supports this specification. > >=20 > > The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA > > (16396..40959). The Protocol ID field is set to one (1), and > > SPI Size is set to zero. There is no data associated with=20 > > this Notify type. > Also I think this notify does not relate to existing SA, so the > protocol ID should be 0. > > > 3.2 ADDITIONAL_ADDRESS notification payload > Also I think this notify does not relate to existing SA, so the > protocol ID should be 0. Hmm... IKEv2 is not very clear on that part. There are some notifications that are clearly about existing ESP/AH SAs, but in some sense all the other notifications are (loosely) related to=20 the IKE_SA. Draft-eronen-ipsec-ikev2-clarifications-03 also has=20 text about this: > 6.10 Protocol ID/SPI fields in Notify payloads > > Section 3.10 says that the Protocol ID field in Notify > payloads "For notifications which do not relate to an > existing SA, this field MUST be sent as zero and MUST be > ignored on receipt". However, the specification does not > clearly say which notifications are related to existing SAs > and which are not. > > Since the main purpose of the Protocol ID field is to > specify the type of the SPI, our interpretation is that the > Protocol ID field should be non-zero only when the SPI field > is non-empty. > > There are currently only two notifications where this is the > case: INVALID_SELECTORS and REKEY_SA. The text above would seem to imply that Protocol ID 1 is never used in notifications, so MOBIKE should also use ID 0. This is OK with me.. (Do you agree with the text in the clarifications draft?) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 10:55:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsidv-00005y-Nk for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 10:55:23 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13929 for ; Wed, 13 Jul 2005 10:55:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id CAAE6FB281; Wed, 13 Jul 2005 10:55:03 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 16869FB266; Wed, 13 Jul 2005 10:55:01 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0D08CFB27C; Wed, 13 Jul 2005 10:54:59 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id E9D41FB262 for ; Wed, 13 Jul 2005 10:54:57 -0400 (EDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6DEst9C010322; Wed, 13 Jul 2005 17:54:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 17:54:04 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 17:54:03 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2005 17:54:03 +0300 Message-ID: Thread-Topic: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Thread-Index: AcWHAIA+aQqcB46ESLeA680R+6D05wAuQO7A From: To: , X-OriginalArrivalTime: 13 Jul 2005 14:54:03.0174 (UTC) FILETIME=[B5AF0460:01C587BA] Subject: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote:=20 > It is very simple to say in the MOBIKE protocol, that > implementations MUST NOT do dynamical address update if MOBIKE > extensions are enabled, i.e. they MUST always do address > updates only when receiving CHANGE_PATH message in case MOBIKE > extensions are enabled. > > That will take care of all the problems using normal IKEv2 > packet to test path. > > > > Note that if the responder has NAT Traversal enabled, it=20 > > can update the addresses in both the IKE_SA and IPsec SAs=20 > > as usual (if it implements the "SHOULD" from [IKEv2]=20 > > Section 2.23. > > There is no reason for the other end to enable the SHOULD in=20 > case the MOBIKE is used. We can simply say that it MUST NOT do=20 > the dynamic address updates in case MOBIKE is enabled. Hmm... it seems the issue of a separate path test message vs. using normal informational exchange for path testing=20 depends a lot on how we handle changes in NAT mappings (if=20 e.g. NAT is rebooted or keepalive interval is too long). It seems that we have several possibilities here. Some preliminary thoughts of what the alternatives might be (but other alternatives might exist too): Option 1: Existing IKEv2 NAT Traversal and its dynamic updates (when using NAT-T, host outside NAT automatically updates the address/port from any authenticated packet). Option 2: Disable the NAT-T dynamic updates, and create a new mechanism for handling NAT mapping changes in MOBIKE. Option 2a: Responder (outside NAT) could notify the initiator when it sees that the port changed, but wait for initiator's CHANGE_PATH message before updating anything. =20 Option 2b: Initiator could send CHANGE_PATH messages all the time just in case the NAT mappings might have changed (even though from its point of view, nothing has changed). =20 Option 2c: More alternatives certainly exist.. Option 3: Disable NAT-T dynamic updates, but don't specify any alternatives for handling NAT mappings changes (=3D=3Dessentially break when NAT mappings change). I'm strongly for option 1 here (although it seems that we probably need a separate path test message then). Option 3=20 does not sound very attractive compared to 1, and at least 2a would IMHO require rechartering the WG. (The charter says "the WG shall NOT develop mechanisms for the following functions: [..] IP address changes done by third parties (NATs, firewalls etc). [..] MOBIKE handles IP address changes initiated by one of the endpoints of the security associations. NAT traversal handles other address changes.") Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 11:06:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsioE-0003RD-5r for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 11:06:03 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16252 for ; Wed, 13 Jul 2005 11:05:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0FBE7FB280; Wed, 13 Jul 2005 11:05:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 52AE6FB266; Wed, 13 Jul 2005 11:05:56 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DDDEFFB27C; Wed, 13 Jul 2005 11:05:54 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id DFB8EFB262 for ; Wed, 13 Jul 2005 11:05:53 -0400 (EDT) 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 j6DF5pQk022614; Wed, 13 Jul 2005 18:05:52 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 18:05:48 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Jul 2005 18:05:48 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Jul 2005 18:05:48 +0300 Message-ID: Thread-Topic: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Thread-Index: AcWHAIA+aQqcB46ESLeA680R+6D05wAuop0g From: To: , X-OriginalArrivalTime: 13 Jul 2005 15:05:48.0483 (UTC) FILETIME=[5A14A130:01C587BC] Subject: [Mobike] Issue 33: Changing ports 500/4500 and RR X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: >> 2.7 NAT prevention >... >> If the IKE_SA_INIT request included NAT_DETECTION_*_IP >> payloads but no NAT_PREVENTION payload, the situation is >> different since the initiator may at this point change >> from port 500 to 4500. In this case, the responder >> initializes (local_address, local_port, peer_address, >> peer_port) from the first IKE_AUTH request. It may also >> decide to perform a return routability check soon after >> the IKE_AUTH exchanges have been completed. > Why does it need to do the return routability check? IKEv2 > NAT-T does not do return routability checks there, why should > we do? Note, that the initiator will not see any IPsec packets > thus he cannot for example start TCP sessions, as those are > not retransmittede to secondary addresses. I cannot really see > how he could mount any real attack at this phase. Hmm.. you're probably right, there's no good reason to do the return routability check at this stage. I guess we can delete the last sentence..? >> IKEv2 requires that if an IPsec endpoint discovers a NAT >> between it and its correspondent, it MUST send all >> subsequent traffic to and from port 4500. To simplify >> things, implementations that support both this >> specification and NAT Traversal MUST change to port 4500 >> if the correspondent also supports both, even if no NAT >> was detected between them. > > What does that simplify? In normal case implementations will > never do that as it wastes 4 bytes for each IKE packet. We don't need to change ports later if we move to a path that has a NAT (if we would change ports, we'd need to specify when exactly the changes happen and how, etc.). (I don't think wasting 4 bytes in IKE (not ESP) packets is a big problem...) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 13 21:19:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DssNX-0003jb-KQ for mobike-archive@megatron.ietf.org; Wed, 13 Jul 2005 21:19:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00319 for ; Wed, 13 Jul 2005 21:19:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C3C7EFB285; Wed, 13 Jul 2005 21:19:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5B3AEFB283; Wed, 13 Jul 2005 21:19:03 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0C9A9FB284; Wed, 13 Jul 2005 21:19:02 -0400 (EDT) Received: from dsl092-223-002.sfo1.dsl.speakeasy.net (mail1.azairenet.com [66.92.223.4]) by machshav.com (Postfix) with ESMTP id 426B1FB281 for ; Wed, 13 Jul 2005 21:19:00 -0400 (EDT) Received: from no.name.available by dsl092-223-002.sfo1.dsl.speakeasy.net via smtpd (for machshav.com [147.28.0.16]) with ESMTP; Wed, 13 Jul 2005 18:19:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: [MOBIKE] Issue 36: Handling UNACCEPTABLE_PATH Date: Wed, 13 Jul 2005 18:19:00 -0700 Message-ID: Thread-Topic: [MOBIKE] Issue 36: Handling UNACCEPTABLE_PATH Thread-Index: AcWIEgSPJUG79/yOTwq2IuVrpsiJuQ== From: "Heeseon Lim" To: X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen (2005-07-12): > 3.4 UNACCEPTABLE_PATH notification payload >=20 > The responder can include this notification payload in an > INFORMATIONAL exchange response to indicate that the address change > in the corresponding request message (which contained a CHANGE_PATH > notification payload) was not carried out. >=20 > The Notify Message Type for UNACCEPTABLE_PATH is TBD-BY-IANA > (40..8191). The Protocol ID field is set to one (1), and SPI Size is > set to zero. There is no data associated with this Notify type. =20 There is a problem in case the UNACCEPTABLE_PATH is not for address in the IP header but some other address pair. I mean the initiator sends packet with IPA1, IPB1 N(CHANGE_PATH). That reaches the responder, but he decides to send N(UNACCEPTABLE_PATH) back. The reply never reaches the initiator because of uni-directional connection or something. The initiator retransmits the packet with IPA2, IPB2 N(CHANGE_PATH). This would be ok for the responder, but as he has already generated the reply N(UNACCEPTABLE_PATH) he will retransmit that back. This will reach the initiator and he will be receiving wrong information which path was unacceptable. =20 ************************** I could not quite understand this. Why would the responder send the reply N(UNACCEPTABLE_PATH) to the request with the new address pair? I think the responder should check the IP address to see if this is acceptable, and send the response according to this check. If the new address pair is ok, then it should snot send the N(UNACCEPTABLE_PATH). =20 One more comment on UNACCEPTABLE_PATH. Section 2.3 says, o If the response contains an UNACCEPTABLE_PATH notification payload, the initiator MAY select another path and retry the exchange, keep on using the current path, or disconnect. It is not very clear which path is meant by 'current path'. Is current path the old path or new path? If it's a new path, then it would not make sense because this path is not acceptable from the responder. If it's an old path, then the initiator cannot just keep on using the current path, because its IKE SA address has already been changed. So in this case, the initiator should update the IKE SA to the previous path. Then the question is 'should the initiator perform the change path procedure again or would it just stop after changing the IKE SA?' It would be simpler to do the change path procedure again from MOBIKE state machine point of view, I think. BR, Heeseon _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 03:24:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsy4o-00018M-D4 for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 03:24:10 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12469 for ; Thu, 14 Jul 2005 03:24:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 60E3AFB286; Thu, 14 Jul 2005 03:24:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E3FEFFB282; Thu, 14 Jul 2005 03:23:59 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 650EEFB283; Thu, 14 Jul 2005 03:23:58 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 93DBFFB266 for ; Thu, 14 Jul 2005 03:23:57 -0400 (EDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6E7KXK1022868; Thu, 14 Jul 2005 10:20:35 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 10:23:10 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 10:23:10 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2005 10:23:10 +0300 Message-ID: Thread-Topic: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Thread-Index: AcWHAIA+aQqcB46ESLeA680R+6D05wBRDFrw From: To: , X-OriginalArrivalTime: 14 Jul 2005 07:23:10.0787 (UTC) FILETIME=[E39E1930:01C58844] Subject: [Mobike] Issue 35: Adding version number to MOBIKE_SUPPORTED X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: >> 3. Payload formats >>=20 >> 3.1 MOBIKE_SUPPORTED notification payload >>=20 >> The MOBIKE_SUPPORTED notification payload is included in >> the IKE_SA_INIT messages to indicate that the >> implementation supports this specification. >> >>=20 >> The Notify Message Type for MOBIKE_SUPPORTED is >> TBD-BY-IANA (16396..40959). The Protocol ID field is set >> to one (1), and SPI Size is set to zero. There is no data >> associated with this Notify type. >=20 > How about adding 32 bits of data, with the MOBIKE version=20 > number, initially 0? If someone later creates a version of MOBIKE with more functionality (or something), we could always negotiate the support for it the same way we do now (add a new notification payload). I don't quite see what would be the advantage of creating a separate negotiation mechanism just for MOBIKE...? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 03:26:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsy7C-0001Zu-Bv for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 03:26:38 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12653 for ; Thu, 14 Jul 2005 03:26:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C98BAFB282; Thu, 14 Jul 2005 03:26:36 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3441FFB281; Thu, 14 Jul 2005 03:26:35 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 09497FB282; Thu, 14 Jul 2005 03:26:33 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id AE8D1FB266 for ; Thu, 14 Jul 2005 03:26:31 -0400 (EDT) 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 j6E7NAIc025315; Thu, 14 Jul 2005 10:23:12 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 10:26:24 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 10:26:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2005 10:26:24 +0300 Message-ID: Thread-Topic: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Thread-Index: AcWHAIA+aQqcB46ESLeA680R+6D05wBRGTZQ From: To: , X-OriginalArrivalTime: 14 Jul 2005 07:26:24.0593 (UTC) FILETIME=[57228C10:01C58845] Subject: [Mobike] Issue 29: Editorial comments from Tero X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > > 1.3 Terminology > >=20 > > Path > >=20 > > A particular combination of source IP address and=20 > > destination IPaddress (note: this definition does not=20 > > consider the route taken by the packets in the network). >=20 > Any reason why the draft-ietf-mobike-design-02.txt and this > document defined Path differently? The Path from the design > draft do include the route, the Path here matches the more or > less the (operantional) address pair in the design draft. >=20 > I think we should try to keep them in sync. The design document also uses the word "path" in senses that don't include the route taken by the packets (see e.g. the definition for "primary path"). Also, some of the terminology in the design document needs a bit revision, since it implicitly assumes the SCTP-like "option 1" for issue 20, instead of the "initiator decides" we chose. > As we are probably going to follow the IKEv2 document style, > which says that payload MUST come in the order they appear in > pictures, I think we might want to keep this and IKEv2 > documents consistent. The CERTREQ is mentioned in the IKEv2 > document, so it's order is fixed, so I would move > NAT_DETECTION_*_IP from the reply to the end, i.e: I've actually considered this, and checked that the ordering=20 is consistent with IKEv2 :-) (According to IKEv2 Section 2.23,=20 NAT_DETECTION_*_IP in reply comes after Nr but before CERTREQ.) > > There is one additional issue that must be taken into > > account. If the destination address in the IKE_SA has > > been updated after the INFORMATIONAL request was sent, > > then it is possible that the request has been sent to > > several different addresses. In this case, receiving the > > INFORMATIONAL response does not tell which address is the > > working one; thus, a new INFORMATIONAL request needs to > > be sent. >=20 > This should probably be clarified better, i.e. if we fall back > to the other addresses, then the malicious peer can take those > later messages that did reach him and send them back using > different address pair, i.e. faking the reply of return > routability check. Yes, this was the idea: if we have sent the request to more than one address (=3D=3Dupdated the destination address in the IKE_SA, at least currently), we need to send a new INFORMATIONAL request to check RR. I'll rephrase that paragraph to make it clearer... =20 > There is no description here what should be done in that > case. We need to send ACK to the N(CHANGE_PATH) quite soon, we > cannot wait for the return routability check to finish, as it > might be so that the initiator sends N(CHANGE_PATH) and then > address pair stops working, thus we cannot do return > routability check, but on the other hand initiator cannot do > anything to fix the situation as he might have window size of > 1, and cannot send another N(CHANGE_PATH) before the one that > is being processed is ACK'ed. > > So we probably want to return ACK to N(CHANGE_PATH) > immediately, but update the actual IP-addresses only after the > return routability checks finish, and if during that time we > get new N(CHANGE_PATH) we simply change the base address where > to do return routability checks. Yes, this was what I had in mind, too (reply to CHANGE_PATH immediately, but update IPsec SAs only after RR check finishes). I'll attempt to clarify this in -01. Cheers, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 03:40:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyKM-0000x0-Sz for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 03:40:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13701 for ; Thu, 14 Jul 2005 03:40:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 263A4FB289; Thu, 14 Jul 2005 03:40:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A3052FB282; Thu, 14 Jul 2005 03:40:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C3033FB284; Thu, 14 Jul 2005 03:40:05 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id F1D1CFB281 for ; Thu, 14 Jul 2005 03:40:03 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6E7e01X003510 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Jul 2005 10:40:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6E7dxig003504; Thu, 14 Jul 2005 10:39:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.5839.725009.198391@fireball.kivinen.iki.fi> Date: Thu, 14 Jul 2005 10:39:59 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: mobike@machshav.com Subject: [Mobike] Issue 30: Protocol ID in notifications X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > > 6.10 Protocol ID/SPI fields in Notify payloads > > > > Section 3.10 says that the Protocol ID field in Notify > > payloads "For notifications which do not relate to an > > existing SA, this field MUST be sent as zero and MUST be > > ignored on receipt". However, the specification does not > > clearly say which notifications are related to existing SAs > > and which are not. > > > > Since the main purpose of the Protocol ID field is to > > specify the type of the SPI, our interpretation is that the > > Protocol ID field should be non-zero only when the SPI field > > is non-empty. > > > > There are currently only two notifications where this is the > > case: INVALID_SELECTORS and REKEY_SA. > > The text above would seem to imply that Protocol ID 1 is never > used in notifications, so MOBIKE should also use ID 0. > This is OK with me.. I do agree on the clarification document text. I.e. the protocol ID is associated with the SPI field, in a way that it is there only and only when there is SPI in the SPI field of notification, and it is there to distinguish from what protocol the SPI in the payload is. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 03:46:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyQg-0003YD-6d for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 03:46:46 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14132 for ; Thu, 14 Jul 2005 03:46:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B02BDFB28B; Thu, 14 Jul 2005 03:46:40 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3DB5FFB284; Thu, 14 Jul 2005 03:46:38 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 08B1FFB285; Thu, 14 Jul 2005 03:46:37 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 25FCCFB282 for ; Thu, 14 Jul 2005 03:46:36 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 594FB89879; Thu, 14 Jul 2005 10:46:34 +0300 (EEST) Message-ID: <42D61867.7030403@piuha.net> Date: Thu, 14 Jul 2005 10:46:47 +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 Subject: Re: [Mobike] Issue 35: Adding version number to MOBIKE_SUPPORTED References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, kivinen@iki.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit I agree. --Jari Pasi.Eronen@nokia.com wrote: >Tero Kivinen wrote: > > >>>3. Payload formats >>> >>>3.1 MOBIKE_SUPPORTED notification payload >>> >>> The MOBIKE_SUPPORTED notification payload is included in >>> the IKE_SA_INIT messages to indicate that the >>> implementation supports this specification. >> >>> >>> The Notify Message Type for MOBIKE_SUPPORTED is >>> TBD-BY-IANA (16396..40959). The Protocol ID field is set >>> to one (1), and SPI Size is set to zero. There is no data >>> associated with this Notify type. >>> >>> >>How about adding 32 bits of data, with the MOBIKE version >>number, initially 0? >> >> > >If someone later creates a version of MOBIKE with more >functionality (or something), we could always negotiate the >support for it the same way we do now (add a new notification >payload). I don't quite see what would be the advantage >of creating a separate negotiation mechanism just for MOBIKE...? > >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 Jul 14 03:47:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsyR3-0003gb-Ta for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 03:47:09 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14181 for ; Thu, 14 Jul 2005 03:47:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 12202FB286; Thu, 14 Jul 2005 03:47:07 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 757A1FB284; Thu, 14 Jul 2005 03:47:04 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 242CDFB285; Thu, 14 Jul 2005 03:47:03 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 7803DFB282 for ; Thu, 14 Jul 2005 03:47:02 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C25E489879; Thu, 14 Jul 2005 10:47:01 +0300 (EEST) Message-ID: <42D61883.20100@piuha.net> Date: Thu, 14 Jul 2005 10:47:15 +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 Subject: Re: [Mobike] Issue 29: Editorial comments from Tero References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, kivinen@iki.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >Tero Kivinen wrote: > > >>>1.3 Terminology >>> >>> Path >>> >>> A particular combination of source IP address and >>> destination IPaddress (note: this definition does not >>> consider the route taken by the packets in the network). >>> >>> >>Any reason why the draft-ietf-mobike-design-02.txt and this >>document defined Path differently? The Path from the design >>draft do include the route, the Path here matches the more or >>less the (operantional) address pair in the design draft. >> >>I think we should try to keep them in sync. >> >> > >The design document also uses the word "path" in senses that >don't include the route taken by the packets (see e.g. the >definition for "primary path"). > > My feeling is that, for practical reasons, we should try to get rid of the term path, unless we use it in the route-included sense. There are too many people that will complain when they will see their favorite term misused :-) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 04:00:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsydi-000264-FY for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 04:00:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15181 for ; Thu, 14 Jul 2005 04:00:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BA9D2FB285; Thu, 14 Jul 2005 04:00:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F081DFB282; Thu, 14 Jul 2005 04:00:06 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 78F93FB283; Thu, 14 Jul 2005 04:00:04 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 996C7FB281 for ; Thu, 14 Jul 2005 04:00:03 -0400 (EDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6E802Vb030366; Thu, 14 Jul 2005 11:00:02 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 11:00:01 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 11:00:01 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 14 Jul 2005 11:00:01 +0300 Message-ID: Thread-Topic: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Thread-Index: AcWHAIA+aQqcB46ESLeA680R+6D05wBSDMOQ From: To: , X-OriginalArrivalTime: 14 Jul 2005 08:00:01.0656 (UTC) FILETIME=[0965EF80:01C5884A] Subject: [Mobike] Issue 23: Payload type for addresses X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > > 3.2 ADDITIONAL_ADDRESS notification payload > >=20 > > Both initiator and responder can include > > ADDITIONAL_ADDRESS payloads in the IKE_AUTH exchange and > > INFORMATIONAL exchange request messages; see Section 2.2 > > and Section 2.4 for more detailed description. > >=20 > > The Notify Message Type for ADDITIONAL_ADDRESS is > > TBD-BY-IANA (16396..40959). The Protocol ID field is set > > to one (1), and SPI Size is set to zero. The data > > associated with this Notify type is either an IPv4 > > address or an IPv6 address; the type is determined by the > > payload length. > > I think it is better to take 2 different notification types > for IPv4 and IPv6. Checking the lenght is bad, as then we > cannot extend the structure later by adding more information > to the notification data. The design draft asks this in the > section 5.11, i.e. make the format so we can extend in the > future it with new data, like load balancing weight (currently > out of scope, but one of the possible future works). Sounds OK to me; I'll change that to ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS in -01. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 04:14:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsyr2-0000dh-AL for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 04:14:00 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16065 for ; Thu, 14 Jul 2005 04:13:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id DEC4EFB283; Thu, 14 Jul 2005 04:13:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E59E8FB281; Thu, 14 Jul 2005 04:13:56 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F3E8EFB282; Thu, 14 Jul 2005 04:13:56 -0400 (EDT) Received: from mgw-ext01.nokia.com (mgw-ext01.nokia.com [131.228.20.93]) by machshav.com (Postfix) with ESMTP id EBE5BFB266 for ; Thu, 14 Jul 2005 04:13:54 -0400 (EDT) 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 j6E8DrNE030825; Thu, 14 Jul 2005 11:13:54 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 11:13:53 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 11:13:53 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 29: Editorial comments from Tero Date: Thu, 14 Jul 2005 11:13:53 +0300 Message-ID: Thread-Topic: [Mobike] Issue 29: Editorial comments from Tero Thread-Index: AcWISEWqd+vudA2GTPSd1NJdPm70zgAAfZ8A From: To: X-OriginalArrivalTime: 14 Jul 2005 08:13:53.0609 (UTC) FILETIME=[F947E390:01C5884B] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Jari Arkko wrote: > >The design document also uses the word "path" in senses that > >don't include the route taken by the packets (see e.g. the > >definition for "primary path"). >=20 > My feeling is that, for practical reasons, we should try to > get rid of the term path, unless we use it in the route-included > sense. There are too many people that will complain when > they will see their favorite term misused :-) Well, it certainly seems so... =20 I've now changed those instances of "path" that don't really=20 consider the route to something else (but I've kept expressions like "paths that contain NATs", "off-path", or "currently used=20 path has stopped working", which are more about the route than just a pair of addresses). CHANGE_PATH notification was renamed to UPDATE_SA_ADDRESSES. Once I get -01 out, let's see if this is better than -00... Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 04:20:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsywv-0004oc-PY for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 04:20:06 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16540 for ; Thu, 14 Jul 2005 04:20:02 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 98544FB285; Thu, 14 Jul 2005 04:20:03 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2CC57FB282; Thu, 14 Jul 2005 04:19:58 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5D4E0FB283; Thu, 14 Jul 2005 04:19:56 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id DBE09FB281 for ; Thu, 14 Jul 2005 04:19:52 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6E8JohI003865 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Jul 2005 11:19:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6E8JooW003862; Thu, 14 Jul 2005 11:19:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.8230.250955.929942@fireball.kivinen.iki.fi> Date: Thu, 14 Jul 2005 11:19:50 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 31 min X-Total-Time: 38 min Cc: mobike@machshav.com Subject: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Hmm... it seems the issue of a separate path test message > vs. using normal informational exchange for path testing > depends a lot on how we handle changes in NAT mappings (if > e.g. NAT is rebooted or keepalive interval is too long). Not really. The problem only occurs if we want to use the path test to test previously broken path without affecting the currect path and there is NAT-T between. If we use path test only when the operational address pair has already broken down then we do not need to modify dynamic address updates of the NAT-T. > Option 1: Existing IKEv2 NAT Traversal and its dynamic updates > (when using NAT-T, host outside NAT automatically updates the > address/port from any authenticated packet). Note, that the dynamic automatically NAT-T address updates is SHOULD in the IKEv2 draft, and it is SHOULD because implementors said they will not implement it, and do not want it to be MUST so they can leave it out... I do not know if anybody has yet really implemented it (I know that our code do have some hooks for it so it can be added, but currently it is still not implemented). I do not even know if anybody ever implemented that on the IKEv1 NAT-T. I think most of the implementors consider that feature so small corner case, that they do not bother implementing it and testing it. > Option 2: Disable the NAT-T dynamic updates, and create a new > mechanism for handling NAT mapping changes in MOBIKE. As IKEv2 NAT-T does not need to do dynamic updates, we might want to implement our own mechanism anyways, if we consider problem important. > Option 2a: Responder (outside NAT) could notify the initiator > when it sees that the port changed, but wait for initiator's > CHANGE_PATH message before updating anything. I do not see need for that. The rebooting of the NAT already caused lots of packets to be dropped, so the user is going to notice it anyways. For the non NAT-T user rebooting of the NAT did cause all the connections to be broken. We can simply assume that the initiator fixes the issue when it notices it (by not receiving any packets). > Option 2b: Initiator could send CHANGE_PATH messages all the > time just in case the NAT mappings might have changed (even > though from its point of view, nothing has changed). Initiator does not know if anything has changed, but something might have changed, so he might want to make sure that both peers share the same view of the operational addresses, thus sending CHANGE_PATH messages, when it sees no traffic from the other end. > Option 2c: More alternatives certainly exist.. One option is the initiator to start DPD with NAT-D payloads, and when it receives reply from the other end, he can compare those NAT-D payloads to the NAT-D payloads it received earlier, and if they do not match, he knows the NAT has been rebooted, and can start corrective actions (i.e. send CHANGE_PATH). I think 2b is simpliest and offers fast enough recovery in the rebooting NAT case. The good thing about that is that it does not require any extra code in the responder (except that responder needs to disable dynamic automatic updates in case it happened to support those, and MOBIKE is enabled), and requires very little code in the initiator (i.e. if NAT-T was enabled, add CHANGE_PATH notify to DPD packet). > Option 3: Disable NAT-T dynamic updates, but don't specify any > alternatives for handling NAT mappings changes (==essentially > break when NAT mappings change). I think this is the most common case of the IKEv1 and IKEv2 NAT-T handling today. And would be quite ok for us too, but as the 2b is better, and it requires so small implementation changes that it will get implemented, I think that is better. The MOBIKE implementations needs to implement the CHANGE_PATH anyways (and yes, I think most of the implementations will at that point also implement the dynamic automatic updates for regular NAT-T (when no MOBIKE) as it comes almost free after the infrastructure required for MOBIKE and CHANGE_PATH is there. > I'm strongly for option 1 here (although it seems that we > probably need a separate path test message then). Option 1 does not require separate path test unless you want to be able to test unidirectional broken paths, and do not want to cause any lost packets during the process. > Option 3 does not sound very attractive compared to 1, and at least > 2a would IMHO require rechartering the WG. Yes, I do not think the option 3 is really useful option, as it simply leaves the problem open. > (The charter says "the WG shall NOT develop mechanisms for the > following functions: [..] IP address changes done by third > parties (NATs, firewalls etc). [..] MOBIKE handles IP address > changes initiated by one of the endpoints of the security > associations. NAT traversal handles other address changes.") I am not sure if even the 2a would require rechartering, at least 2b and 2c is more or less describing "how they interact" (NAT-T and MOBIKE). Actually the original idea behind the charter was that MOBIKE would not do anything about NATs, i.e. if NAT is detected, then we do not use MOBIKE, but simply use normal NAT-T (note the "if any" in the text saying "MOBIKE should not be tightly coupled with the NAT traversal function, but it is necessary to specify in which cases (if any) they can be used together, and how they interact"). This was already decided in the WG that we do want to use MOBIKE and NAT-T together. My understanding of the that charter text is that we are not allowed to modify actual UDP encapsulation part of the NAT-T, and we must use the NAT-T mechanisms in the IKEv2, but we can profile the NAT-T (i.e. say which features are mandatory to implement and which are not, or which features must be enabled or disabled). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 04:25:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsz1u-0007OX-E1 for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 04:25:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16893 for ; Thu, 14 Jul 2005 04:25:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 27B87FB285; Thu, 14 Jul 2005 04:25:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C1253FB281; Thu, 14 Jul 2005 04:25:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id AA835FB282; Thu, 14 Jul 2005 04:25:06 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 8014CFB266 for ; Thu, 14 Jul 2005 04:25:05 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6E8P39N003962 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Jul 2005 11:25:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6E8P2kD003959; Thu, 14 Jul 2005 11:25:02 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.8542.304023.573806@fireball.kivinen.iki.fi> Date: Thu, 14 Jul 2005 11:25:02 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: mobike@machshav.com Subject: [Mobike] Issue 33: Changing ports 500/4500 and RR X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > We don't need to change ports later if we move to a path that > has a NAT (if we would change ports, we'd need to specify when > exactly the changes happen and how, etc.). (I don't think > wasting 4 bytes in IKE (not ESP) packets is a big problem...) Hmm... True, it does make things a simplier in that case. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 04:25:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dsz2W-0007UA-Cg for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 04:25:52 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16951 for ; Thu, 14 Jul 2005 04:25:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D1CC6FB285; Thu, 14 Jul 2005 04:25:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1061CFB281; Thu, 14 Jul 2005 04:25:50 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1E745FB282; Thu, 14 Jul 2005 04:25:48 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 774B7FB266 for ; Thu, 14 Jul 2005 04:25:47 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CD69089879; Thu, 14 Jul 2005 11:25:46 +0300 (EEST) Message-ID: <42D62198.40905@piuha.net> Date: Thu, 14 Jul 2005 11:26:00 +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 Subject: Re: [Mobike] Issue 29: Editorial comments from Tero References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >I've now changed those instances of "path" that don't really >consider the route to something else (but I've kept expressions >like "paths that contain NATs", "off-path", or "currently used >path has stopped working", which are more about the route >than just a pair of addresses). CHANGE_PATH notification was >renamed to UPDATE_SA_ADDRESSES. > > Sounds good. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 04:51:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DszR6-0002l8-Hn for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 04:51:16 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19484 for ; Thu, 14 Jul 2005 04:51:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 46031FB285; Thu, 14 Jul 2005 04:51:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 89FB5FB281; Thu, 14 Jul 2005 04:51:08 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1E5D0FB282; Thu, 14 Jul 2005 04:51:07 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id EDFACFB266 for ; Thu, 14 Jul 2005 04:51:05 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6E8p3oE004250 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Jul 2005 11:51:03 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6E8p3e0004247; Thu, 14 Jul 2005 11:51:03 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.10103.105838.43632@fireball.kivinen.iki.fi> Date: Thu, 14 Jul 2005 11:51:03 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 8 min Cc: mobike@machshav.com Subject: [Mobike] Issue 35: Adding version number to MOBIKE_SUPPORTED X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > If someone later creates a version of MOBIKE with more > functionality (or something), we could always negotiate the > support for it the same way we do now (add a new notification > payload). I don't quite see what would be the advantage > of creating a separate negotiation mechanism just for MOBIKE...? Because I do not want to see: HDR, SAi1, KEi, Ni, N(MOBIKE_SUPPORTED), N(MOBIKE_SUPPORTED_VER01), N(MOBIKE_SUPPORTED_VER02), N(FOO_SUPPORTED_VER00), N(BAR_SUPPORTED), [N(NAT_DETECTION_*)] --> etc.... Like you already see in IKEv1 NAT-T. Implementations send out lots of different vendor IDs. I think our current implementation sends 5 different NAT-T IKEv1 vendor ids: md5(draft-stenberg-ipsec-nat-traversal-02) md5(draft-huttunen-ipsec-esp-in-udp-00.txt) md5(draft-ietf-ipsec-nat-t-ike-02) md5(draft-ietf-ipsec-nat-t-ike-03) md5(RFC 3947) and there is even some vendors sending out vendor id's for md5(draft-ietf-ipsec-nat-t-ike-0{4,5,6,7,8}) even when those documents didn't have the vendor ID defined, so nobody would ever implement them. I really do not want to that happen to MOBIKE too. Adding 4 bytes of version number to the payload is quite easy way to fix that. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 04:56:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DszVi-0005C9-6p for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 04:56:02 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20545 for ; Thu, 14 Jul 2005 04:55:58 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 547E7FB286; Thu, 14 Jul 2005 04:55:59 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 85923FB281; Thu, 14 Jul 2005 04:55:54 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6D96CFB282; Thu, 14 Jul 2005 04:55:52 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 4890BFB23C for ; Thu, 14 Jul 2005 04:55:51 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 07AF289879; Thu, 14 Jul 2005 11:55:50 +0300 (EEST) Message-ID: <42D628A3.3090806@piuha.net> Date: Thu, 14 Jul 2005 11:56:03 +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 Subject: Re: [Mobike] Issue 35: Adding version number to MOBIKE_SUPPORTED References: <17110.10103.105838.43632@fireball.kivinen.iki.fi> In-Reply-To: <17110.10103.105838.43632@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Tero, Let me try to understand your worry better. Are you worried about (a) Some functional deficiency of the N(feature) scheme that is corrected in the scheme that you proposed? (b) Waste of bits, N(featurevers1)+N(featurevers2) is bigger than N(feature)+bits? (c) Headache when you look at IKEv2 packets in Ethereal? --Jari Tero Kivinen wrote: >Pasi.Eronen@nokia.com writes: > > >>If someone later creates a version of MOBIKE with more >>functionality (or something), we could always negotiate the >>support for it the same way we do now (add a new notification >>payload). I don't quite see what would be the advantage >>of creating a separate negotiation mechanism just for MOBIKE...? >> >> > >Because I do not want to see: > > HDR, SAi1, KEi, Ni, > N(MOBIKE_SUPPORTED), > N(MOBIKE_SUPPORTED_VER01), > N(MOBIKE_SUPPORTED_VER02), > N(FOO_SUPPORTED_VER00), > N(BAR_SUPPORTED), > [N(NAT_DETECTION_*)] --> > > >etc.... > >Like you already see in IKEv1 NAT-T. Implementations send out lots of >different vendor IDs. > >I think our current implementation sends 5 different NAT-T IKEv1 >vendor ids: > >md5(draft-stenberg-ipsec-nat-traversal-02) >md5(draft-huttunen-ipsec-esp-in-udp-00.txt) >md5(draft-ietf-ipsec-nat-t-ike-02) >md5(draft-ietf-ipsec-nat-t-ike-03) >md5(RFC 3947) > >and there is even some vendors sending out vendor id's for >md5(draft-ietf-ipsec-nat-t-ike-0{4,5,6,7,8}) even when those documents >didn't have the vendor ID defined, so nobody would ever implement >them. > >I really do not want to that happen to MOBIKE too. Adding 4 bytes of >version number to the payload is quite easy way to fix that. > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 05:01:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dszad-0002uU-Ok for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 05:01:07 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21303 for ; Thu, 14 Jul 2005 05:01:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5333DFB286; Thu, 14 Jul 2005 05:01:05 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 85D3AFB282; Thu, 14 Jul 2005 05:01:02 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C7FEDFB283; Thu, 14 Jul 2005 05:01:01 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 287AEFB281 for ; Thu, 14 Jul 2005 05:01:00 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6E90pLX004408 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Jul 2005 12:00:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6E90oUP004405; Thu, 14 Jul 2005 12:00:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.10690.823307.66960@fireball.kivinen.iki.fi> Date: Thu, 14 Jul 2005 12:00:50 +0300 From: Tero Kivinen To: In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 6 min X-Total-Time: 7 min Cc: mobike@machshav.com Subject: [Mobike] Issue 29: Editorial comments from Tero X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > The design document also uses the word "path" in senses that > don't include the route taken by the packets (see e.g. the > definition for "primary path"). Actually the "primary path" does not say weather the route of the packet is included or not. The definition of "Path" do say that route is included. > Also, some of the terminology in the design document needs a bit > revision, since it implicitly assumes the SCTP-like "option 1" > for issue 20, instead of the "initiator decides" we chose. Better send updates then and say where it mentiones that we selected option 1 so we can fix it. Note, that in multiple places it tries not to say which option we have selected when describing the problem, and only in the end of section mentions which of those options were selected. Also decribing the other problems can still use more generic text, even when we could use less generic one because of the some options we selected in some other places. This way if we decide to select some option, we do not need to modify other parts of the document, as the generic text is still valid there. > I've actually considered this, and checked that the ordering > is consistent with IKEv2 :-) (According to IKEv2 Section 2.23, > NAT_DETECTION_*_IP in reply comes after Nr but before CERTREQ.) True, I didn't remember it was explicitly mentioned in the text. Some of the other optional ones are not mentioned. > Yes, this was the idea: if we have sent the request to more than one > address (==updated the destination address in the IKE_SA, at least > currently), we need to send a new INFORMATIONAL request to check > RR. I'll rephrase that paragraph to make it clearer... Try to include also description of the attack, not only the solution, as it do make the text more understandable to know why it is done that way. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 05:13:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DszmO-0001n6-88 for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 05:13:16 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22339 for ; Thu, 14 Jul 2005 05:13:13 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4528AFB284; Thu, 14 Jul 2005 05:13:14 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 14A33FB281; Thu, 14 Jul 2005 05:13:13 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 60393FB282; Thu, 14 Jul 2005 05:13:11 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 84AA0FB266 for ; Thu, 14 Jul 2005 05:13:09 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6E9D3nV004526 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Jul 2005 12:13:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6E9D2Xl004523; Thu, 14 Jul 2005 12:13:02 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.11422.625970.150746@fireball.kivinen.iki.fi> Date: Thu, 14 Jul 2005 12:13:02 +0300 From: Tero Kivinen To: "Heeseon Lim" Subject: [MOBIKE] Issue 36: Handling UNACCEPTABLE_PATH In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 11 min X-Total-Time: 11 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Heeseon Lim writes: > There is a problem in case the UNACCEPTABLE_PATH is not for address in > the IP header but some other address pair. I mean the initiator sends > packet with IPA1, IPB1 N(CHANGE_PATH). That reaches the responder, but > he decides to send N(UNACCEPTABLE_PATH) back. The reply never reaches > the initiator because of uni-directional connection or something. The > initiator retransmits the packet with IPA2, IPB2 N(CHANGE_PATH). This > would be ok for the responder, but as he has already generated the > reply N(UNACCEPTABLE_PATH) he will retransmit that back. This will > reach the initiator and he will be receiving wrong information which > path was unacceptable. > > ************************** > I could not quite understand this. Why would the responder send the > reply N(UNACCEPTABLE_PATH) to the request with the new address pair? I Because the message ID is same and once a request or reply for that message id is generated it must be retransmitted without any modifications. > think the responder should check the IP address to see if this is > acceptable, and send the response according to this check. If the > new address pair is ok, then it should snot send the > N(UNACCEPTABLE_PATH). That would be ok, if this would be the different message, but as it could be retransmission of the same message it must be sent back simlarly than before. Lets take example. We have ip-addresses of A1, A2, B1, and B2, and the responder feels that A1 is not allowed because of the policy. Now A sends update. Initiator Responder ========= ========= (A1, B1) N(CHANGE_PATH), N(COOKIE2) -> Responder notices that the header has A1, so he decides to send N(UNACCEPTABLE_PATH) back. lost <- (B1, A1) N(UNACCEPTABLE_PATH) The N(UNACCEPTABLE_PATH) from responder was lost because of unidirectional link. A retransmits the packet: (A1, B1) N(CHANGE_PATH), N(COOKIE2) -> B sees retranmissions, and replies with the retransmission packet. lost <- (B1, A1) N(UNACCEPTABLE_PATH) The N(UNACCEPTABLE_PATH) is still lost. A notices he is not getting packets back, so he decides to try to use some other IP-address: (A1, B2) N(CHANGE_PATH), N(COOKIE2) -> B retransmits its previous packet. lost <- (B2, A1) N(UNACCEPTABLE_PATH) A tries again: (A2, B2) N(CHANGE_PATH), N(COOKIE2) -> B retransmits its previous packet. <- (B2, A2) N(UNACCEPTABLE_PATH) Now the A do receive the packet and notices that the path was unacceptable, but he does not know which path was unacceptable: (A1, B1), (A1, B2) or (A2, B2). It could have been so that the (A1, *) packets never reached the responder, and only thie (A2, B2) packet reached the responder, and that path was unacceptable, or it could be like now that the (A1, B1) path was unacceptable. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 06:46:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt1Em-0005rq-4J for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 06:46:40 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28422 for ; Thu, 14 Jul 2005 06:46:36 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8C38BFB284; Thu, 14 Jul 2005 06:46:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 17612FB281; Thu, 14 Jul 2005 06:46:36 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5AD05FB282; Thu, 14 Jul 2005 06:46:34 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 82C3CFB266 for ; Thu, 14 Jul 2005 06:46:32 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6EAkT2W005535 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Jul 2005 13:46:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6EAkKht005530; Thu, 14 Jul 2005 13:46:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.17020.287494.405629@fireball.kivinen.iki.fi> Date: Thu, 14 Jul 2005 13:46:20 +0300 From: Tero Kivinen To: Jari Arkko Subject: Re: [Mobike] Issue 35: Adding version number to MOBIKE_SUPPORTED In-Reply-To: <42D628A3.3090806@piuha.net> References: <17110.10103.105838.43632@fireball.kivinen.iki.fi> <42D628A3.3090806@piuha.net> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 13 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Jari Arkko writes: > (a) Some functional deficiency of the N(feature) scheme > that is corrected in the scheme that you proposed? I do not want to see multiple different notifications each negotiating something small in the IKEv2. > (b) Waste of bits, N(featurevers1)+N(featurevers2) is > bigger than N(feature)+bits? Yes, as for version 11 (current IKEv1 NAT-T (stenberg, huttunen, nat-t-ike version 01-08, RFC version) it will be N(feature)+bits, compared to the N(version1) + N(version2) + N(version3) + N(version4) + N(version5) + N(version6) + N(version7) + N(version8) + N(version9) + N(version10) + N(version11). There is already lots of concerns in the IESG that the IKEv2 packets will be too big, and there will be UDP fragmentation which will cause IKEv2 to break. It is especially important to keep the FIRST IKE_SA_INIT packet as small as possible to prevent fragmentation, as it is required for stateless operations when under attack. I mean if you are using stateless cookies of IKEv2 because you are under attack, you do not want to do reassembly of the IKEv2 packets before you can see the cookie, thus the first IKEv2 packet (IKE_SA_INIT) should not be fragmented. For the bit D-H group we are already quite close to the fragmentation limit, and I do not want to add 8*11 bytes to that packet, when I can go with 12 bytes... > (c) Headache when you look at IKEv2 packets in > Ethereal? That too :-) It is ugly to add new notification for each version, as it makes it so that you cannot ever get rid of those notifications. I mean I am pretty much sure we cannot get ever rid of the very early IKEv1 NAT-T draft compatibility code, as there is still our old implementations out there using those so they will be there for ever (or until we switch to IKEv2). I do not want the same thing happening to IKEv2, when we can avoid it with version number of the extension. It is good practice to make sure there is version numbers in the protocol, and well tought plan how to do extensions to the protocol (i.e. suitable reserved bits, or at least make sure there can be new data added later). What is the reason NOT to add the version number? Saving 4 bytes now, but wasting lot later? (or saving paragraph or two describing how version number and extensions work together, i.e. say that all later versions much include all features of the older ones, and newer versions should not use the features other peer does not unrestand). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 07:51:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2FX-0003AN-0q for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 07:51:31 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01896 for ; Thu, 14 Jul 2005 07:51:28 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4323BFB284; Thu, 14 Jul 2005 07:51:27 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 10B01FB281; Thu, 14 Jul 2005 07:51:26 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6B7C8FB282; Thu, 14 Jul 2005 07:51:23 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 936BBFB266 for ; Thu, 14 Jul 2005 07:51:22 -0400 (EDT) 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 j6EBlxC1007753; Thu, 14 Jul 2005 14:48:02 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 14:51:20 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 14:51:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 35: Adding version number to MOBIKE_SUPPORTED Date: Thu, 14 Jul 2005 14:51:15 +0300 Message-ID: Thread-Topic: [Mobike] Issue 35: Adding version number to MOBIKE_SUPPORTED Thread-Index: AcWIYXGdH/GtVbVjSaOE257MdVvxrgABOVtw From: To: , X-OriginalArrivalTime: 14 Jul 2005 11:51:15.0395 (UTC) FILETIME=[56CA8130:01C5886A] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > > What is the reason NOT to add the version number? Saving 4 > bytes now, but wasting lot later? (or saving paragraph or two > describing how version number and extensions work together, > i.e. say that all later versions much include all features of > the older ones, and newer versions should not use the features > other peer does not unrestand). I think it's more likely that we'll have extensions that are=20 (to some degree) independent of each other, and don't follow a=20 nice linear progression where each new version includes all=20 features from the older ones. If that happens, adding a version number will waste bytes instead of saving them. (But predicting the future is of course difficult, so it might be so that we'll have linear versions instead. Or we might not have many versions at all.) If we really want to keep this option open, we could of course say that "hosts implementing this version don't send any data in the notification, but ignore any data they receive". Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 08:21:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt2im-0002R7-D5 for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 08:21:44 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03846 for ; Thu, 14 Jul 2005 08:21:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0E36CFB284; Thu, 14 Jul 2005 08:21:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A9124FB281; Thu, 14 Jul 2005 08:21:40 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CD45BFB282; Thu, 14 Jul 2005 08:21:38 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id AD4A0FB266 for ; Thu, 14 Jul 2005 08:21:37 -0400 (EDT) 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 j6ECIHQu030695; Thu, 14 Jul 2005 15:18:17 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 15:21:35 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Jul 2005 15:21:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Date: Thu, 14 Jul 2005 15:21:33 +0300 Message-ID: Thread-Topic: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Thread-Index: AcWITR443mlUDQtoQ2+y9aRNdIW/fQAEr0RQ From: To: X-OriginalArrivalTime: 14 Jul 2005 12:21:35.0932 (UTC) FILETIME=[93EA67C0:01C5886E] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: >=20 > Pasi.Eronen@nokia.com writes: > > Hmm... it seems the issue of a separate path test message > > vs. using normal informational exchange for path testing=20 > > depends a lot on how we handle changes in NAT mappings (if=20 > > e.g. NAT is rebooted or keepalive interval is too long). >=20 > Not really. The problem only occurs if we want to use the path > test to test previously broken path without affecting the > currect path and there is NAT-T between. If we use path test > only when the operational address pair has already broken down > then we do not need to modify dynamic address updates of the > NAT-T. This was discussed already in May 2005... At least some people thought that it would be useful to allow path testing even when the current path is working (and without disrupting ongoing communication). > > Option 1: Existing IKEv2 NAT Traversal and its dynamic updates > > (when using NAT-T, host outside NAT automatically updates the > > address/port from any authenticated packet). >=20 > Note, that the dynamic automatically NAT-T address updates is > SHOULD in the IKEv2 draft, and it is SHOULD because > implementors said they will not implement it, and do not want > it to be MUST so they can leave it out... >=20 > I do not know if anybody has yet really implemented it (I know > that our code do have some hooks for it so it can be added, > but currently it is still not implemented). >=20 > I do not even know if anybody ever implemented that on the > IKEv1 NAT-T. I think most of the implementors consider that > feature so small corner case, that they do not bother > implementing it and testing it. Linux (Open|something)SWAN implements it for IKEv1 NAT-T.=20 I don't know about others... > > Option 2: Disable the NAT-T dynamic updates, and create a new > > mechanism for handling NAT mapping changes in MOBIKE. >=20 > As IKEv2 NAT-T does not need to do dynamic updates, we might want=20 > to implement our own mechanism anyways, if we consider problem=20 > important. I'm not quite sure how important problem this is, but since the problem is already solved in IKEv2 NAT-T, I think we should have really good reasons for not using that solution. (Much better ones than "I didn't bother to implement that SHOULD in my product" or "Not invented here / We just like doing things differently"). > The MOBIKE implementations needs to implement the CHANGE_PATH > anyways (and yes, I think most of the implementations will at > that point also implement the dynamic automatic updates for > regular NAT-T (when no MOBIKE) as it comes almost free after > the infrastructure required for MOBIKE and CHANGE_PATH is > there. If that's the case, wouldn't it be simpler to just use the=20 same mechanism (dynamic automatic updates) when NAT-T is used with and without MOBIKE? BR, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 09:23:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dt3gD-0006Fx-6r for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 09:23:09 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07948 for ; Thu, 14 Jul 2005 09:23:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7325FFB284; Thu, 14 Jul 2005 09:23:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 1C71BFB281; Thu, 14 Jul 2005 09:22:58 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7F40CFB282; Thu, 14 Jul 2005 09:22:56 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 64104FB266 for ; Thu, 14 Jul 2005 09:22:54 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6EDMoAd007162 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 14 Jul 2005 16:22:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6EDMo9J007159; Thu, 14 Jul 2005 16:22:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17110.26410.1808.320720@fireball.kivinen.iki.fi> Date: Thu, 14 Jul 2005 16:22:50 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 33 min X-Total-Time: 34 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > > > Hmm... it seems the issue of a separate path test message > > > vs. using normal informational exchange for path testing > > > depends a lot on how we handle changes in NAT mappings (if > > > e.g. NAT is rebooted or keepalive interval is too long). > > > > Not really. The problem only occurs if we want to use the path > > test to test previously broken path without affecting the > > currect path and there is NAT-T between. If we use path test > > only when the operational address pair has already broken down > > then we do not need to modify dynamic address updates of the > > NAT-T. > > This was discussed already in May 2005... At least some people > thought that it would be useful to allow path testing even when > the current path is working (and without disrupting ongoing > communication). Yes, I know it was discussed earlier, but simply pointed it out here to explain why we need to do things here like I explained. So now people can really decide wheather they want that complication to the protocol for that feature. > I'm not quite sure how important problem this is, but since the > problem is already solved in IKEv2 NAT-T, I think we should have > really good reasons for not using that solution. (Much better > ones than "I didn't bother to implement that SHOULD in my > product" or "Not invented here / We just like doing things > differently"). I do not think it was solved in the IKEv2 NAT-T. If the IKEv2 NAT-T would be ok, then there would be not need at all to MOBIKE, simply use IKEv2 NAT-T all the time. We would loose the multihoming aspect and would waste some bytes on packets, but it would work for the mobility part. I do not think the dynamic automatic updates are good for MOBIKE. I want MOBIKE to be more secure than IKEv2 NAT-T, which means more controlled way on changing paths on MOBIKE than in IKEv2 NAT-T. If we also do the same thing on the NAT-T with MOBIKE, then we can get more security for that part too. If we only do updating of operational address pair on explicit notify, then the attacker cannot take any packet and change the addresses of packet to redirect the packets to some other address. Instead attacker needs to first distrupt the normal processing of the packets to get the initiator to do the DPD with address pair update notify, before he can change the operational address pair, and in that case it is also processed in the responder site as normal addres pair updating, which means it is subject to the return routability checks etc. If we do use the dynamic automatic update of the IP address of the IKEv2 NAT-T, then we do not do return routability checks, thus we do not have as good protection against flooding attacks as we would have in case of MOBIKE style address update. > If that's the case, wouldn't it be simpler to just use the > same mechanism (dynamic automatic updates) when NAT-T is > used with and without MOBIKE? Yes, it would be marginally simplier for the NAT-T case, but we add more complexity for all other cases, by adding new protocol to be implemented. And then we do not get the protection provided by the MOBIKE. No return routability checks, no N(COOKIE2) etc. I do not think we want to add new protocol to do path testing, as it can be done without any extra effort inside the normal IKEv2 MOBIKE processing. What are the benefits of the separate path tests? Can you list me reasons why we need to have that? My reasons why I do not want to have separate path test protocol is: 1) I do not want to add yet another extra protocol to same port as IKEv2 (we already have 4 there (IKEv1, IKEv2, UDP encapsulation, UDP encapsulation keepalives)). (It is not IKEv2 exchange, as it does not follow encryption, authentication, message-id, windowing etc specifications of the IKEv2). 2) Security implications of non-encrypted, non-authenticated protocol are not completely tought out (at least yet). 3) We have already existing code we can use inside the MOBIKE IKEv2 implementations which can do the same thing. This code is needed to be there regardless wheater we have or have not separate path test protocol (i.e we need to be able to handle the situation when the path breaks down during the IKE negotiation, i.e. we must be able to retransmit the IKE packets to alternative addresses). This means that by reusing that code we can do the path test, with less added code implementations, which means fewer bugs. (The code that needs to be added is: disable the (probably not yet implemented) automatic dynamic updating of NAT-T address changes; add check to DPD that if we are behind NAT and MOBIKE is enabled add N(CHANGE_PATH) to the DPD message). -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 16:41:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtAWa-0003F6-I6 for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 16:41:43 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04526 for ; Thu, 14 Jul 2005 16:41:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C9007FB284; Thu, 14 Jul 2005 16:41:33 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 52D3BFB281; Thu, 14 Jul 2005 16:41:32 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CA558FB282; Thu, 14 Jul 2005 16:41:31 -0400 (EDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by machshav.com (Postfix) with ESMTP id 1E46CFB27C for ; Thu, 14 Jul 2005 16:41:31 -0400 (EDT) Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j6EKfNvU006617 for ; Thu, 14 Jul 2005 14:41:23 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j6EKfMC2010184 for ; Thu, 14 Jul 2005 16:41:23 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6EKfKfU208991; Thu, 14 Jul 2005 16:41:21 -0400 (EDT) Subject: Re: [Mobike] Issue 24: NAT prevention details (was: Review of draft-ietf-mobike-protocol-00) From: Bill Sommerfeld To: Tero Kivinen In-Reply-To: <17108.53240.119932.537256@fireball.kivinen.iki.fi> References: <17108.53240.119932.537256@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1121373679.207125.183.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.316 Date: Thu, 14 Jul 2005 16:41:20 -0400 Content-Transfer-Encoding: 7bit Cc: ldondeti@qualcomm.com, mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit On Wed, 2005-07-13 at 04:25, Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: > > that contain NATs. If the responder notices that a NAT is > > present anyway, the request fails with error code NAT_PREVENTED. > > NAT_PREVENTED would say that you somehow managed to get rid of the > NAT... How about "NAT_DETECTED" or "UNEXPECTED_NAT_DETECTED" ? - Bill _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jul 14 20:33:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtE92-00019b-Bi for mobike-archive@megatron.ietf.org; Thu, 14 Jul 2005 20:33:36 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24288 for ; Thu, 14 Jul 2005 20:33:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 62806FB284; Thu, 14 Jul 2005 20:33:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BD53CFB281; Thu, 14 Jul 2005 20:33:28 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A4F1DFB282; Thu, 14 Jul 2005 20:33:27 -0400 (EDT) Received: from smtp105.sbc.mail.mud.yahoo.com (smtp105.sbc.mail.mud.yahoo.com [68.142.198.204]) by machshav.com (Postfix) with SMTP id B8478FB27C for ; Thu, 14 Jul 2005 20:33:26 -0400 (EDT) Received: (qmail 88955 invoked from network); 15 Jul 2005 00:33:24 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.56.122 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 15 Jul 2005 00:33:23 -0000 Message-ID: <00b401c588d4$d01be320$6501a8c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <17107.61572.626229.253188@fireball.kivinen.iki.fi><014801c58769$a759c040$6501a8c0@adithya> <17108.55584.151056.864627@fireball.kivinen.iki.fi> Subject: Re: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt Date: Thu, 14 Jul 2005 17:33:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit > If the initiator is behind the NAT, the DPD can also be used to do to > simulate the dynamic updates of the non MOBIKE NAT-T, by so that we > send the INFORMATIONAL exchange with COOKIE2 and CHANGE_PATH message > as a DPD message, when we suspect that something is wrong. This is > really like using the operational address pair update messages as a DPD > just to make sure the operational address pair matches the NAT mapping > in the NAT box. > > I.e. if host A is behind NAT, and host B is the gateway, and host A > and B has MOBIKE IPsec connection established between them. Then the > NAT box is rebooted. The host B will detect that host A starts using > new IP-address, but because this is MOBIKE NAT-T he does not do > anything, simply continues using the old address pair (his packets > will be dropped by NAT). > > The Host A notices that he is not getting any messages (IKE or IPsec) > back, and starts DPD to verify that everything is ok. He sends DPD (or > actually operationl address pair update packet is used as DPD) with > COOKIE2 and CHANGE_PATH to the host B. Host B receives that, and > replies to it, and in the same time also updates the operational > address pair to this new one. After that host A can see reply and the > packets start flowing again, and situation is fixed. > If the operational pair is not working and the intiator is behind NAT, it could be multiple reasons : NAT reboot, some router crashed etc. You assumed that NAT rebooted above. If the NAT did not reboot, then the PATH did not really change. In this case, the initiator would still not see any response and hence try a new PATH later. Does this mean that the initiator behind NAT always have to try sending DPD with CHANGE_PATH and then try new PATH ? If we think this is a corner case, i am not sure whether it is worth it. -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 15 00: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 1DtHur-0000D1-EU for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 00: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 AAA08060 for ; Fri, 15 Jul 2005 00:35:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 68315FB284; Fri, 15 Jul 2005 00:35:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 100B2FB281; Fri, 15 Jul 2005 00:35:10 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ADAE8FB282; Fri, 15 Jul 2005 00:35:08 -0400 (EDT) Received: from smtp103.sbc.mail.mud.yahoo.com (smtp103.sbc.mail.mud.yahoo.com [68.142.198.202]) by machshav.com (Postfix) with SMTP id 37C3EFB266 for ; Fri, 15 Jul 2005 00:35:07 -0400 (EDT) Received: (qmail 15478 invoked from network); 15 Jul 2005 04:35:06 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.56.122 with login) by smtp103.sbc.mail.mud.yahoo.com with SMTP; 15 Jul 2005 04:35:06 -0000 Message-ID: <010a01c588f6$9300e950$6501a8c0@adithya> From: "Mohan Parthasarathy" To: , References: Subject: Re: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Date: Thu, 14 Jul 2005 21:35:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi, > Pasi.Eronen@nokia.com writes: > > Hmm... it seems the issue of a separate path test message > > vs. using normal informational exchange for path testing > > depends a lot on how we handle changes in NAT mappings (if > > e.g. NAT is rebooted or keepalive interval is too long). > > Not really. The problem only occurs if we want to use the path > test to test previously broken path without affecting the > currect path and there is NAT-T between. If we use path test > only when the operational address pair has already broken down > then we do not need to modify dynamic address updates of the > NAT-T. This was discussed already in May 2005... At least some people thought that it would be useful to allow path testing even when the current path is working (and without disrupting ongoing communication). mohanp> Yes, this would be nice. By having the path test outside the SA, mohanp> you never update any SA with the new addresses while mohanp> testing the new path. Hence, you avoid changing the mohanp> existing NAT-T behavior (which may or may not be desirable). mohanp> But there a case in the draft today for which the message mohanp> is sent with the different address from that of the operational mohanp> pair and the peer does not update the address i.e when mohanp> the operational pair does not work, you reransmit the existing mohanp> message in the window with the new address but the peer mohanp > does not update with the new address until the CHANGE_PATH mohanp> is sent (section 2.3 ). If there is a NAT in this path, are we not mohanp> changing the behavior already ? So, why can't this be extended mohanp> to path test message also i.e path test messages don't update mohanp> the addresses on the SA unless explictly notified? Am i missing mohanp> something.... -thanks mohan > > Option 1: Existing IKEv2 NAT Traversal and its dynamic updates > > (when using NAT-T, host outside NAT automatically updates the > > address/port from any authenticated packet). > > Note, that the dynamic automatically NAT-T address updates is > SHOULD in the IKEv2 draft, and it is SHOULD because > implementors said they will not implement it, and do not want > it to be MUST so they can leave it out... > > I do not know if anybody has yet really implemented it (I know > that our code do have some hooks for it so it can be added, > but currently it is still not implemented). > > I do not even know if anybody ever implemented that on the > IKEv1 NAT-T. I think most of the implementors consider that > feature so small corner case, that they do not bother > implementing it and testing it. Linux (Open|something)SWAN implements it for IKEv1 NAT-T. I don't know about others... > > Option 2: Disable the NAT-T dynamic updates, and create a new > > mechanism for handling NAT mapping changes in MOBIKE. > > As IKEv2 NAT-T does not need to do dynamic updates, we might want > to implement our own mechanism anyways, if we consider problem > important. I'm not quite sure how important problem this is, but since the problem is already solved in IKEv2 NAT-T, I think we should have really good reasons for not using that solution. (Much better ones than "I didn't bother to implement that SHOULD in my product" or "Not invented here / We just like doing things differently"). > The MOBIKE implementations needs to implement the CHANGE_PATH > anyways (and yes, I think most of the implementations will at > that point also implement the dynamic automatic updates for > regular NAT-T (when no MOBIKE) as it comes almost free after > the infrastructure required for MOBIKE and CHANGE_PATH is > there. If that's the case, wouldn't it be simpler to just use the same mechanism (dynamic automatic updates) when NAT-T is used with and without MOBIKE? BR, 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 Jul 15 04:44:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtLo3-00064L-DA for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 04:44:27 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15271 for ; Fri, 15 Jul 2005 04:44:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 93A6BFB285; Fri, 15 Jul 2005 04:44:25 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DDD25FB283; Fri, 15 Jul 2005 04:44:23 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2952BFB284; Fri, 15 Jul 2005 04:44:22 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 1D0A7FB281 for ; Fri, 15 Jul 2005 04:44:21 -0400 (EDT) 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 j6F8ewco004458; Fri, 15 Jul 2005 11:40:59 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 11:44:15 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 11:44:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Date: Fri, 15 Jul 2005 11:44:15 +0300 Message-ID: Thread-Topic: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Thread-Index: AcWId35+y0ZAJlFMRyambip6d+/QgwAnkOCg From: To: X-OriginalArrivalTime: 15 Jul 2005 08:44:15.0013 (UTC) FILETIME=[6155D550:01C58919] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen write: >=20 > Pasi.Eronen@nokia.com writes: > > > > Hmm... it seems the issue of a separate path test message > > > > vs. using normal informational exchange for path testing=20 > > > > depends a lot on how we handle changes in NAT mappings (if=20 > > > > e.g. NAT is rebooted or keepalive interval is too long). > > >=20 > > > Not really. The problem only occurs if we want to use the path > > > test to test previously broken path without affecting the > > > currect path and there is NAT-T between. If we use path test > > > only when the operational address pair has already broken down > > > then we do not need to modify dynamic address updates of the > > > NAT-T. > >=20 > > This was discussed already in May 2005... At least some people > > thought that it would be useful to allow path testing even when > > the current path is working (and without disrupting ongoing > > communication). >=20 > Yes, I know it was discussed earlier, but simply pointed it out here > to explain why we need to do things here like I explained. So now > people can really decide wheather they want that complication to the > protocol for that feature.=20 Hmm, actually it might be that having a separate exchange for *path testing* isn't the real issue; the real issue might be that informational exchange might be unsuitable for changing the path... Informational exchange requires us to keep retransmitting the same request until we get an response; or in other words, it assumes that once we decide to do something, we won't change our mind. This applies pretty well to things informational exchange is used currently in IKEv2, but it does not apply that well to changing addresses: if we get new information, insisting that we continue with something we already know to be wrong just causes problems (for instance, issue 36 with UNACCEPTABLE_PATH that looks quite tricky... and a similar issue probably exists with NAT prevention). How about if we instead create a separate ADDRESS_UPDATE exchange=20 with slightly different semantics: the initiator is not required to retransmit a message forever, but can instead decide to stop and send a new message instead? (The messages would be encrypted and integrity protected, but they probably would have a different Message ID space or something..) As someone who's been involved in implementing IKEv2, I know that adding this kind of new exchange would require some work. But we're talking about days here; in designing a MOBIKE protocol that actually works properly with informational exchange in all cases, we've already spent more than 1.5 years. So it might be a very good tradeoff (and would probably simplify other parts of the protocol). Any comments? Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 15 05:11:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtMEH-0003Mk-8f for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 05:11:33 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16895 for ; Fri, 15 Jul 2005 05:11:30 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 94703FB286; Fri, 15 Jul 2005 05:11:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 2F0C0FB283; Fri, 15 Jul 2005 05:11:30 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B8265FB284; Fri, 15 Jul 2005 05:11:28 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 2958CFB281 for ; Fri, 15 Jul 2005 05:11:27 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6F9BNJm020135 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Jul 2005 12:11:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6F9BL3g020132; Fri, 15 Jul 2005 12:11:21 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17111.32185.411160.682583@fireball.kivinen.iki.fi> Date: Fri, 15 Jul 2005 12:11:21 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] Comments to draft-ietf-mobike-protocol-00.txt In-Reply-To: <00b401c588d4$d01be320$6501a8c0@adithya> References: <17107.61572.626229.253188@fireball.kivinen.iki.fi> <014801c58769$a759c040$6501a8c0@adithya> <17108.55584.151056.864627@fireball.kivinen.iki.fi> <00b401c588d4$d01be320$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 9 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > If the operational pair is not working and the intiator is behind NAT, > it could be multiple reasons : NAT reboot, some router crashed etc. > You assumed that NAT rebooted above. If the NAT did not reboot, > then the PATH did not really change. In this case, the initiator would > still not see any response and hence try a new PATH later. The first thing that initiator does when it does not see packets is to start DPD on the operational address pair. It does this regardless if it is behind NAT or not. The only change there is that if it is behind NAT he should put CHANGE_PATH notify there too. If the problem was NAT booting, then the CHANGE_PATH will update the responder side (it is processed there as normal IP-address change). If the lack of traffic was because of some other reason, then the CHANGE_PATH does not do anything, as it would only change the operational address pair to be same that as it is already now (i.e. no operation for the responder side, this situation can happen quite often in other cases too, so responder must be able to process that correctly). If this was because path having NAT broke down, then the DPD will try other address pairs too when it cannot get packets back with the current operational address pair. Then initiator will find the proper working address pair, and finishe the DPD and do the another CHANGE_PATH to that (as specified in normal case where the packet having CHANGE_PATH is retransmitted to multiple address pairs). So the only change really is the addition of CHANGE_PATH in the DPD packet if behind NAT. > Does this mean that the initiator behind NAT always have to try > sending DPD with CHANGE_PATH and then try new PATH ? Yes, but actually the DPD with CHANGE_PATH will be used to search for the new path. I.e after it finishes we have new address pair that works, because we do retransmit that packet to other addresses too. > If we think this is a corner case, i am not sure whether it is worth > it. Nat booting is corner case, but adding the CHANGE_PATH to DPD when behind NAT is so small change that I think we should do it. All the other processing is still same than in normal case. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 15 06:07:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtN6q-0003bt-A0 for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 06:07:56 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20640 for ; Fri, 15 Jul 2005 06:07:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 900C6FB289; Fri, 15 Jul 2005 06:07:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 654D9FB285; Fri, 15 Jul 2005 06:07:48 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D99F0FB286; Fri, 15 Jul 2005 06:07:45 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 2A82DFB283 for ; Fri, 15 Jul 2005 06:07:44 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6FA7f2Z020728 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Jul 2005 13:07:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6FA7fEV020725; Fri, 15 Jul 2005 13:07:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17111.35564.966901.286269@fireball.kivinen.iki.fi> Date: Fri, 15 Jul 2005 13:07:40 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings In-Reply-To: <010a01c588f6$9300e950$6501a8c0@adithya> References: <010a01c588f6$9300e950$6501a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Mohan Parthasarathy writes: > mohanp> But there a case in the draft today for which the message > mohanp> is sent with the different address from that of the operational > mohanp> pair and the peer does not update the address i.e when > mohanp> the operational pair does not work, you reransmit the existing > mohanp> message in the window with the new address but the peer > mohanp > does not update with the new address until the CHANGE_PATH > mohanp> is sent (section 2.3 ). Actually I think the responder will change the path, but the initiator will simply issue new CHANGE_PATH when the first one finishes and the window again has space. The second one will make sure they have same information of the current operational address pair. > mohanp> If there is a NAT in this path, are we not > mohanp> changing the behavior already ? So, why can't this be extended > mohanp> to path test message also i.e path test messages don't update > mohanp> the addresses on the SA unless explictly notified? Am i missing > mohanp> something.... In my opinion any of the messages should not update the address pair unless there is explicit CHANGE_PATH notify in the packet. The problem case can happen when when we are sending that CHANGE_PATH and then we notice that the address pair we tried to use to send that one (i.e. the one where we tried to change the address pair to) is broken, and we need to retransmit it again with different addresses. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 15 06:30:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtNSN-0008Ge-Ai for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 06:30:11 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22128 for ; Fri, 15 Jul 2005 06:30:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7ABE8FB286; Fri, 15 Jul 2005 06:30:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 04320FB281; Fri, 15 Jul 2005 06:30:02 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C3D60FB283; Fri, 15 Jul 2005 06:30:00 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 04237FB249 for ; Fri, 15 Jul 2005 06:29:59 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6FATtg4020927 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Jul 2005 13:29:55 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6FAToek020922; Fri, 15 Jul 2005 13:29:50 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17111.36893.963932.807280@fireball.kivinen.iki.fi> Date: Fri, 15 Jul 2005 13:29:49 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 20 min X-Total-Time: 22 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > Hmm, actually it might be that having a separate exchange for > *path testing* isn't the real issue; the real issue might be > that informational exchange might be unsuitable for changing > the path... I donot think the informational exchanges are unsuitable for changing the path. They are not optimal as we need to get reply back before we can change the contents, but I still do not think we can work with those. > Informational exchange requires us to keep retransmitting the > same request until we get an response; or in other words, it > assumes that once we decide to do something, we won't change our > mind. Yes. This applies to all IKEv2 packets inside the IKE SA. > This applies pretty well to things informational exchange > is used currently in IKEv2, but it does not apply that well to > changing addresses: if we get new information, insisting that we > continue with something we already know to be wrong just causes > problems (for instance, issue 36 with UNACCEPTABLE_PATH that > looks quite tricky... and a similar issue probably exists > with NAT prevention). But we do know something went wrong, so we can simply fix it with next exchange, which we can start immediately when this one ends. > How about if we instead create a separate ADDRESS_UPDATE exchange > with slightly different semantics: the initiator is not required > to retransmit a message forever, but can instead decide to stop > and send a new message instead? (The messages would be > encrypted and integrity protected, but they probably would have > a different Message ID space or something..) And the responder needs to process them all, and it needs to know which one of the retransmits is the most authorative, and which one it should skip, because the information is not up to date anymore (or actually it can be up to date, but the initiator might not know it is up to date, as there was some delay in the path etc). Defining that protocol will take some effort, especially making sure there is no replay, delayed packets, denial of service etc attacks. > As someone who's been involved in implementing IKEv2, I know > that adding this kind of new exchange would require some work. That is not a new exchange, as it does not follow IKEv2 windowing, retransmission, replay prevention, message id etc specifications. It is completely new protocol. > But we're talking about days here; in designing a MOBIKE > protocol that actually works properly with informational > exchange in all cases, we've already spent more than 1.5 years. > So it might be a very good tradeoff (and would probably simplify > other parts of the protocol). I haven't used 1.5 years to designing or implementing the protocol using informational exchanges. We have been really talking about the protocol for few months now, before that we worked in the design and requirements. We have much better understanding now what we require from the protocol than when we startted this process. The current thing I am proposing is about the same than my original proposal year ago, except it didn't take NAT's in the account (I considered them out of scope), and it also wasn't initiator decides, but both end tried to fix situations. Anyways regardless what we do for the path test and address update, we need to take care of the situation when the IKE SA ip address pair changes in the middle of the ongoing IKEv2 exchange. Thus we cannot get rid of that code. If we move address update to separate protocol we still need to define what happens if the address changes in the middle of the exchange, and the responder might have already processed my previous exchange, and updated its address pairs, before I modify the packet and start informing next address pair etc. I actually think that would be more complicated than any of the proposals we have had before in the specification point of view, and also probably require more code, as we cannot necessarely share that much from the IKEv2 code (we need to rewrite at least the message id, replay prevention, and windowing code, we probably can reuse the authentication, encryption and packet format code). When using information exchanges we need to rwrite the retransmission code in a such way that it knows that it needs to start trying other addresses after it does not get reply back. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 15 07:32:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtOR5-0002Mk-Ml for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 07:32:55 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26564 for ; Fri, 15 Jul 2005 07:32:53 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A47C0FB286; Fri, 15 Jul 2005 07:32:53 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7F6A6FB283; Fri, 15 Jul 2005 07:32:52 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4DFE3FB284; Fri, 15 Jul 2005 07:32:50 -0400 (EDT) Received: from mgw-ext03.nokia.com (mgw-ext03.nokia.com [131.228.20.95]) by machshav.com (Postfix) with ESMTP id 3AC29FB281 for ; Fri, 15 Jul 2005 07:32:49 -0400 (EDT) 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 j6FBSxG1004369; Fri, 15 Jul 2005 14:29:24 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 14:32:41 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 14:32:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Date: Fri, 15 Jul 2005 14:32:41 +0300 Message-ID: Thread-Topic: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Thread-Index: AcWJKFeUU/i/dWo8Ta2LezIvmw59CQAB93rA From: To: X-OriginalArrivalTime: 15 Jul 2005 11:32:41.0407 (UTC) FILETIME=[E9372CF0:01C58930] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable BTW, choosing option 2b (disable NAT-T dynamic updates) does not really get rid of the need for a separate path test message. As I've repeatedly said before, if we have messages where the addresses from the IP header are used for something else than sending the reply, then just retransmitting the latest IKEv2 request cannot be used for path testing, _if_ we want to be=20 able to do path testing at any time without changing the=20 addresses currently in use. (Or at least so far nobody has described how to do it.) Disabling dynamic updates does not radically change the situation; we still have the CHANGE_PATH message left. It seems your proposal is "drop the last requirement; it's not a problem if path testing might disrupt the communications"? (And this does not occur only when unidirectional paths are present; random packet loss is sufficient.) IMHO this would actually complicate the protocol. It's easy enough to describe and implement the current PATH_TEST exchange, since you can send it at any time, and it doesn't depend on what else is going on. Otherwise, things get more complicated, since path testing can't be considered independently of the rest of the protocol anymore... (Or maybe some lazy implementor would just use IKE_SA_INIT for path testing, since it would actually work without disrupting anything else that's going on :-) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 15 08:41:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtPV1-0001IY-Al for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 08:41:04 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01390 for ; Fri, 15 Jul 2005 08:41:00 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6AC42FB285; Fri, 15 Jul 2005 08:40:58 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E5E17FB283; Fri, 15 Jul 2005 08:40:55 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EC93FFB284; Fri, 15 Jul 2005 08:40:53 -0400 (EDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 83EF0FB281 for ; Fri, 15 Jul 2005 08:40:49 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6FCejcS022413 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Jul 2005 15:40:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6FCehKM022410; Fri, 15 Jul 2005 15:40:44 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17111.44747.411361.969672@fireball.kivinen.iki.fi> Date: Fri, 15 Jul 2005 15:40:43 +0300 From: Tero Kivinen To: Subject: RE: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 28 min X-Total-Time: 28 min Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > BTW, choosing option 2b (disable NAT-T dynamic updates) does not > really get rid of the need for a separate path test message. > > As I've repeatedly said before, if we have messages where the > addresses from the IP header are used for something else than > sending the reply, then just retransmitting the latest IKEv2 > request cannot be used for path testing, _if_ we want to be > able to do path testing at any time without changing the > addresses currently in use. Are you talking about the case where the we need to retransmit the CHANGE_PATH message? I do not see any other cases where the IP header is used in any other than just replying to the packet. The CHANGE_PATH is different as there we MUST use the IP header information if we want to work with NATs. If we need to retransmit CHANGE_PATH then it will change the address pair to something else than what was initially intended, but unless there is uni-directional problems then the responder will change it to the working address pair, thus the second CHANGE_PATH done by the initiator will be simpy no-op for the responder. If there is uni-directional problems (where responder receives packets, but cannot send reply), then the responder will always update the address pair to wrong address pair first, regardless weather we are using INFORMATIONAL exchanges or completely new protocol to do that (unless we make the exchange 4 packet exchange or similar). You can use any non-CHANGE_PATH packet as a path test message, without any problems, as they do not cause any changes in the other end. And if you want to send CHANGE_PATH, that normally means that you have already verified with some other packet that the path already works, thus if that needs to be retransmitted to another address it means that the link did broke down between that test and update (again corner case), thus we are supposed to loos packets in that situation in all cases. > Disabling dynamic updates does not radically change the > situation; we still have the CHANGE_PATH message left. It seems > your proposal is "drop the last requirement; it's not a problem > if path testing might disrupt the communications"? Path testing will never disrupt communications, as you do not do path test with CHANGE_PATH packets. I.e. if you have working connection before, and you want to verify if the other address pair works, you do that with INFORMATIONAL exchange which do NOT have CHANGE_PATH, thus it does not cause any disruption to the communcations. Note, that am talking now about path testing function, i.e. the operation when you want to test wheather the address pair is working or not. I am not talking about the situation when we notice in the middle of the exchange that the current address pair does not work. That is not path testing, that is recovering from problem. To do that recovery you need to find new working address pair, but I and you do that with testing different addresses, but I do not consider that path testing, more like searching for working address pair. > (And this does not occur only when unidirectional paths are > present; random packet loss is sufficient.) Random packet loss of half a dozen packets, where all reply packets are dropped, is called unidirectional path. For that negotiation that path was unidirectional. It does not matter for some other traffic or some other exchange it is bi-directional, but for that exchange it was unidirectional. > IMHO this would actually complicate the protocol. It's easy > enough to describe and implement the current PATH_TEST exchange, > since you can send it at any time, and it doesn't depend on what > else is going on. Yes, it is easy to implement, but it does not help at all. You still need to take care of the IKE SA exchange that is going on while you loose the connection. I.e. the searching of the new address pair, and changing to use that. > Otherwise, things get more complicated, > since path testing can't be considered independently of the > rest of the protocol anymore... I do not agree on that. > (Or maybe some lazy implementor would just use IKE_SA_INIT for > path testing, since it would actually work without disrupting > anything else that's going on :-) Perhaps we need to make the terminology more clear: Address pair probe This is the case when both ends do have working address pair already established, but initiator wants to test if some other addtress pair works, to verify if he can change operational address pair to that by explicit exchange later. This MUST NOT disrupt the normal packet processing of the IKE and IPsec SAs. Recovering from lost address pair This is the case when the operational address pair does not work anymore, and MOBIKE needs to find new address pair that can be used as new operation address pair. As there is already packet loss happening when this is detected, this can cause disruption to packet flow, but this recovery process will find new working address pair. Note, that we cannot have this situation ever unless we already have IKE SA exchange active, as we only detect the loss of address pair when we do not get reply back for the other peer. After this state finishes, then the original initiator will issue address pair update to move all traffic to that new working address pair. Address pair update Exchange that updates the operational address pair. The address pair update can fail in case we need to do recovering from lost address pair while sending the address pair update. In that case the address pair update is done again with the new working address pair found during the recovering from lost address pair state. Your PATH_TEST can be used for both address pair probe, and during the recovering from lost address pair. In my case the INFORMATIONAL exchange without CHANGE_PATH would be used as a address pair probe, and the recovering from lost address pair, would use the currently active IKE SA exchange when testing different address pairs. Does that make things more understandable? -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 15 09:19:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtQ6a-0003rc-RO for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 09:19:52 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04339 for ; Fri, 15 Jul 2005 09:19:50 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 47E2EFB28B; Fri, 15 Jul 2005 09:19:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7A2D3FB286; Fri, 15 Jul 2005 09:19:47 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id ABED7FB28A; Fri, 15 Jul 2005 09:19:45 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 934A1FB284 for ; Fri, 15 Jul 2005 09:19:44 -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 j6FDJgxR031553; Fri, 15 Jul 2005 16:19:43 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 16:19:42 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 15 Jul 2005 16:19:42 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Date: Fri, 15 Jul 2005 16:19:42 +0300 Message-ID: Thread-Topic: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings Thread-Index: AcWJOpYLbkQQxOWOTIidryjFbn3ABwAArajQ From: To: X-OriginalArrivalTime: 15 Jul 2005 13:19:42.0570 (UTC) FILETIME=[DC86E4A0:01C5893F] Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > > As I've repeatedly said before, if we have messages where the > > addresses from the IP header are used for something else than > > sending the reply, then just retransmitting the latest IKEv2 > > request cannot be used for path testing, _if_ we want to be=20 > > able to do path testing at any time without changing the=20 > > addresses currently in use. >=20 > Are you talking about the case where the we need to retransmit=20 > the CHANGE_PATH message? >=20 > I do not see any other cases where the IP header is used in=20 > any other than just replying to the packet. Yes, CHANGE_PATH was what I had in mind (the other case is=20 NAT-T dynamic update, but here we assumed it's disabled). > Perhaps we need to make the terminology more clear: >=20 > Address pair probe >=20 > This is the case when both ends do have working address > pair already established, but initiator wants to test if > some other addtress pair works, to verify if he can > change operational address pair to that by explicit > exchange later. This MUST NOT disrupt the normal packet > processing of the IKE and IPsec SAs. >=20 > Recovering from lost address pair >=20 > This is the case when the operational address pair does > not work anymore, and MOBIKE needs to find new address > pair that can be used as new operation address pair. As > there is already packet loss happening when this is > detected, this can cause disruption to packet flow, but > this recovery process will find new working address > pair. Note, that we cannot have this situation ever > unless we already have IKE SA exchange active, as we > only detect the loss of address pair when we do not get > reply back for the other peer. After this state > finishes, then the original initiator will issue address > pair update to move all traffic to that new working > address pair. >=20 > Address pair update >=20 > Exchange that updates the operational address pair. The > address pair update can fail in case we need to do recovering > from lost address pair while sending the address pair update. > In that case the address pair update is done again with the > new working address pair found during the recovering from lost > address pair state. >=20 > Your PATH_TEST can be used for both address pair probe, and > during the recovering from lost address pair. In my case the > INFORMATIONAL exchange without CHANGE_PATH would be used as a > address pair probe, and the recovering from lost address pair, > would use the currently active IKE SA exchange when testing > different address pairs. >=20 > Does that make things more understandable? Yes, it does; it also shows what's the main difference between=20 a separate PATH_TEST message and your proposal: in your proposal an "address pair probe" cannot be done while an "address pair update" is in progress (note that a broken address pair is not the only possible reason for doing an update). But perhaps this is not a big problem, since an address pair update either finishes reasonably quickly (10-20 seconds at most, a couple of retransmissions), or if those couple of retransmissions don't work, turns into "recovering from lost address pair" situation.=20 So if we decide to handle NAT mapping changes by sending CHANGE_PATH messages all the time, we might drop the separate PATH_TEST exchange. (Of course, we already send DPD messages if we haven't received anything for a long time, but the time scales could be quite different. For DPD, even something like 30 minutes could be a sufficient value of "a long time"; but to recover decently from lost NAT mappings we're talking more like 30 seconds...) (That message would then replace NAT-T keepalives as well, for most practical purposes...) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jul 15 15:50:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DtWCN-0005ux-Rl for mobike-archive@megatron.ietf.org; Fri, 15 Jul 2005 15:50:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10996 for ; Fri, 15 Jul 2005 15:50:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 83C5CFB28D; Fri, 15 Jul 2005 15:50:05 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C3B56FB286; Fri, 15 Jul 2005 15:50:04 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A5DA1FB28A; Fri, 15 Jul 2005 15:50:03 -0400 (EDT) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id DE4F0FB284 for ; Fri, 15 Jul 2005 15:50:02 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DtWCA-0001tL-6v; Fri, 15 Jul 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, 15 Jul 2005 15:50:02 -0400 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-protocol-01.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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-01.txt Pages : 22 Date : 2005-7-15 This document describes the MOBIKE protocol, a mobility and multihoming extension to IKEv2. MOBIKE allows mobile and/or multihomed hosts to update the (outer) IP addresses associated with IKE and IPsec Security Associations (SAs). The main scenario for MOBIKE is making it possible for a remote access VPN user to move from one address to another while keeping the connection with the VPN gateway active. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-protocol-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-protocol-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-protocol-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-7-15131249.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-protocol-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-protocol-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-15131249.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 Mon Jul 18 09:58:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuW8j-0001FH-3C for mobike-archive@megatron.ietf.org; Mon, 18 Jul 2005 09:58:37 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12021 for ; Mon, 18 Jul 2005 09:58:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 45496FB283; Mon, 18 Jul 2005 09:58:29 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C58F2FB266; Mon, 18 Jul 2005 09:58:26 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 09477FB277; Mon, 18 Jul 2005 09:58:25 -0400 (EDT) Received: from mgw-ext02.nokia.com (mgw-ext02.nokia.com [131.228.20.94]) by machshav.com (Postfix) with ESMTP id 2E751FB24A for ; Mon, 18 Jul 2005 09:58:24 -0400 (EDT) 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 j6IDwB91001223 for ; Mon, 18 Jul 2005 16:58:21 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 16:58:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 18 Jul 2005 16:58:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Jul 2005 16:58:18 +0300 Message-ID: Thread-Topic: Issues handled in version -01: 21,23,25,26,29,30 Thread-Index: AcWLoMCgJCOUFlbhSP6ykRdUAqrCMQ== From: To: X-OriginalArrivalTime: 18 Jul 2005 13:58:19.0865 (UTC) FILETIME=[C0FB4C90:01C58BA0] Subject: [Mobike] Issues handled in version -01: 21,23,25,26,29,30 X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Version -01 of the protocol draft tries to handle the following issues: 21 (Editorial comments from Lakshminath): Fixed grammar and=20 clarified some parts based on discussion on mailing list. 23 (Payload type for addresses): Version -01 now has separate notification payloads for ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDERESS. These are still notification payloads (instead of "top-level" payloads), since it seems to be reasonably=20 in line with base IKEv2 spec. 25 (Editorial comments from Mohan): Clarified text based on discussion on mailing list. 26 (Window size and latest_update_counter): Clarified the text to better describe what happens in those steps. 29 (Editorial comments from Tero): Clarified some things, now avoids using the word "path" in senses that don't really consider the route taken by the packets. 30 (Protocol ID in notifications): Use protocol ID 0 as proposed=20 by Tero. If you submitted any of these issues, please check if you're happy with how they were handled. Unless there are any objections, I'll mark these issues as closed soon. Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 20 15:33:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKK7-0006M3-Kq for mobike-archive@megatron.ietf.org; Wed, 20 Jul 2005 15:33:43 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24239 for ; Wed, 20 Jul 2005 15:33:40 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 22305FB27F; Wed, 20 Jul 2005 15:33:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 694A9FB249; Wed, 20 Jul 2005 15:33:35 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 5C1A6FB277; Wed, 20 Jul 2005 15:33:34 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8F82FFB240 for ; Wed, 20 Jul 2005 15:33:33 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 521638980C for ; Wed, 20 Jul 2005 22:33:31 +0300 (EEST) Message-ID: <42DEA713.60004@piuha.net> Date: Wed, 20 Jul 2005 22:33:39 +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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] FW: I-D ACTION:draft-schilcher-mobike-pfkey-extension-01.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : MOBIKE Extensions for PF_KEY > Author(s) : U. Schilcher, et al. > Filename : draft-schilcher-mobike-pfkey-extension-01.txt > Pages : 21 > Date : 2005-7-19 > >PF_KEY is a generic key management API used for communication between > a trusted user level key management daemon and a key engine within > the operating system. With the extension of IKEv2 for mobility and > multihoming (MOBIKE) the existing capabilities of PF_KEY with regard > to the creation, maintenance and deletion of security associations > became insufficient. This document defines an extension to update an > entity in the security association database. Additionally, it is > necessary to reflect the newly offered integrity and encryption > algorithms with IKEv2 in PF_KEY. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-schilcher-mobike-pfkey-extension-01.txt > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jul 20 15:50:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvKa5-00060R-Im for mobike-archive@megatron.ietf.org; Wed, 20 Jul 2005 15:50:14 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25207 for ; Wed, 20 Jul 2005 15:50:10 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 426C0FB27F; Wed, 20 Jul 2005 15:50:07 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 17A75FB249; Wed, 20 Jul 2005 15:50:06 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C4B67FB277; Wed, 20 Jul 2005 15:50:03 -0400 (EDT) Received: from newodin.ietf.org (unknown [132.151.6.50]) by machshav.com (Postfix) with ESMTP id 0948DFB246 for ; Wed, 20 Jul 2005 15:50:03 -0400 (EDT) Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1DvKZu-0007iZ-Cz; Wed, 20 Jul 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: Wed, 20 Jul 2005 15:50:02 -0400 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-03.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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-03.txt Pages : 35 Date : 2005-7-20 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-03.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-03.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-03.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-7-20114654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-design-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-design-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-7-20114654.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 Jul 21 03:22:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvVNn-0004EC-AO for mobike-archive@megatron.ietf.org; Thu, 21 Jul 2005 03:22:15 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07330 for ; Thu, 21 Jul 2005 03:22:12 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4E0D1FB27F; Thu, 21 Jul 2005 03:22:11 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C534CFB262; Thu, 21 Jul 2005 03:22:09 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7DE32FB277; Thu, 21 Jul 2005 03:22:08 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id A8AFBFB246 for ; Thu, 21 Jul 2005 03:22:07 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1D6598980C for ; Thu, 21 Jul 2005 10:22:06 +0300 (EEST) Message-ID: <42DF4D26.3050705@piuha.net> Date: Thu, 21 Jul 2005 10:22:14 +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: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Mobike] FW: I-D ACTION:draft-schilcher-mobike-trigger-api-01.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Application Programming Interface to a Trigger > Database for MOBIKE > Author(s) : H. Tschofenig, et al. > Filename : draft-schilcher-mobike-trigger-api-01.txt > Pages : 23 > Date : 2005-7-20 > >The purpose of MOBIKE is the creation and maintenance a set of > available addresses and provide them to the communication partner. A > MOBIKE peer should have some information about the status of each > address and interface in order to execute the respective actions. > Examples may comprise switching from address or interface to another. > This information, which will be referred as trigger, is distributed > over a number of protocols daemons at an end host. To make this > information available to the MOBIKE daemon it is necessary to store > it centrally at the host (called trigger database) and to enable the > protocols to insert the triggers and to allow MOBIKE to obtain timely > information. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-schilcher-mobike-trigger-api-01.txt > > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 23 14:56:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwPAd-0005UA-Mq for mobike-archive@megatron.ietf.org; Sat, 23 Jul 2005 14:56:23 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13435 for ; Sat, 23 Jul 2005 14:56:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BCCD6FB28A; Sat, 23 Jul 2005 14:56:18 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8F58FFB284; Sat, 23 Jul 2005 14:56:17 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8A04AFB285; Sat, 23 Jul 2005 14:56:15 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id E6923FB281 for ; Sat, 23 Jul 2005 14:56:14 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9166189832; Sat, 23 Jul 2005 21:56:12 +0300 (EEST) Message-ID: <42E292D4.9090508@piuha.net> Date: Sat, 23 Jul 2005 21:56:20 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman Subject: [Mobike] mobike agenda for Paris, take one X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Please send comments, suggestions, and missing items to the Paul or myself. MOBIKE WG Meeting at IETF-63 in Paris WEDNESDAY, August 3, 2005, 1400-1630 Afternoon Session I AGENDA: 1. Preliminaries (5 min) -- Chairs - Blue sheets - Note takers - Agenda bashing - Document status 2. Protocol presentation (15 min) -- Pasi Eronen - walkthrough of the current protocol to set the stage for subsequent discussions - draft-ietf-mobike-protocol-01.txt 3. Protocol discussion (100 min) -- Pasi Eronen - brief reminder of issues already solved in -01 - walkthrough and discussion of open issues in -01 - open mike for additional discussion 4. Protocol design draft update (15 min) -- Hannes Tschofenig - status of the draft - remaining open issues - next steps 5. AOB & Wrapup (15 mins) -- Chairs _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 30 13:10:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyuqX-0006sj-NH for mobike-archive@megatron.ietf.org; Sat, 30 Jul 2005 13:10:02 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19686 for ; Sat, 30 Jul 2005 13:09:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 89522FB28A; Sat, 30 Jul 2005 13:09:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 76C20FB285; Sat, 30 Jul 2005 13:09:55 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 8CC52FB28B; Sat, 30 Jul 2005 13:09:52 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id AEF64FB27F for ; Sat, 30 Jul 2005 13:09:50 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 645AD89832; Sat, 30 Jul 2005 20:09:46 +0300 (EEST) Message-ID: <42EB9AC3.9090704@piuha.net> Date: Sat, 30 Jul 2005 18:20:35 +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 Subject: Re: [MOBIKE] Issue 36: Handling UNACCEPTABLE_PATH References: <17110.11422.625970.150746@fireball.kivinen.iki.fi> In-Reply-To: <17110.11422.625970.150746@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Tero Kivinen wrote: >There is a problem in case the UNACCEPTABLE_PATH is not for address in >the IP header but some other address pair. I mean the initiator sends >packet with IPA1, IPB1 N(CHANGE_PATH). That reaches the responder, but >he decides to send N(UNACCEPTABLE_PATH) back. The reply never reaches >the initiator because of uni-directional connection or something. The >initiator retransmits the packet with IPA2, IPB2 N(CHANGE_PATH). This >would be ok for the responder, but as he has already generated the >reply N(UNACCEPTABLE_PATH) he will retransmit that back. This will >reach the initiator and he will be receiving wrong information which >path was unacceptable. > > Agreed. >Fixing this is quite simply, we add the address pair that was >unacceptable to the notify data. In case there is NAT in the path the >responder might not recognize all the addresses, but in case of no >NATs it immediately knows which address pair wasn't acceptable. > > Hmm. Maybe it would then be better to introduce a counter or message id to N(CHANGE_PATH) and N(UNACCEPTABLE_PATH) rather than the addresses, which can change en-route? --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 30 13:10:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyuqp-0006w4-04 for mobike-archive@megatron.ietf.org; Sat, 30 Jul 2005 13:10:19 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19698 for ; Sat, 30 Jul 2005 13:10:15 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 80FB8FB29B; Sat, 30 Jul 2005 13:10:13 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E4344FB290; Sat, 30 Jul 2005 13:10:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id B87B6FB28A; Sat, 30 Jul 2005 13:09:53 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 3BE68FB289 for ; Sat, 30 Jul 2005 13:09:52 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 84D2D89879; Sat, 30 Jul 2005 20:09:43 +0300 (EEST) Message-ID: <42EB9774.3070109@piuha.net> Date: Sat, 30 Jul 2005 18:06:28 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Subject: Re: [Mobike] Issue 24: NAT prevention details (was: Review of draft-ietf-mobike-protocol-00) References: <17108.53240.119932.537256@fireball.kivinen.iki.fi> <1121373679.207125.183.camel@thunk> In-Reply-To: <1121373679.207125.183.camel@thunk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pasi.Eronen@nokia.com, mobike@machshav.com, ldondeti@qualcomm.com, Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit I agree that the naming needs to change. Maybe initiator -------------DISALLOW_NAT-------------------------------> <-----------UNEXPECTED_NAT_DETECTED-------responder I'm also wondering about this text in Section 2.7: If the values do match, the responder initializes (local_address, local_port, peer_address, peer_port) in the to-be-created IKE_SA with values from the IP header. The same applies if neither NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if the responder does not support NAT Traversal. which would seem to indicate that if you don't include any NAT-D payloads you get NAT-prevention by default... perhaps this would be the right way to signal DISALLOW_NAT -- but how would you do the comparison then? --Jari Bill Sommerfeld wrote: >On Wed, 2005-07-13 at 04:25, Tero Kivinen wrote: > > >>Pasi.Eronen@nokia.com writes: >> >> >>>that contain NATs. If the responder notices that a NAT is >>>present anyway, the request fails with error code NAT_PREVENTED. >>> >>> >>NAT_PREVENTED would say that you somehow managed to get rid of the >>NAT... >> >> >How about "NAT_DETECTED" or "UNEXPECTED_NAT_DETECTED" ? > > - Bill > > > >_______________________________________________ >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 Sat Jul 30 13:10:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyuqs-0006wG-GP for mobike-archive@megatron.ietf.org; Sat, 30 Jul 2005 13:10:22 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19701 for ; Sat, 30 Jul 2005 13:10:19 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6E9B4FB2A1; Sat, 30 Jul 2005 13:10:20 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 4C603FB294; Sat, 30 Jul 2005 13:10:12 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id CD233FB289; Sat, 30 Jul 2005 13:09:54 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id B1A00FB285 for ; Sat, 30 Jul 2005 13:09:50 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3A8C68987B; Sat, 30 Jul 2005 20:09:45 +0300 (EEST) Message-ID: <42EB9989.2000700@piuha.net> Date: Sat, 30 Jul 2005 18:15:21 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maureen.Stillman@nokia.com Subject: Re: [Mobike] Comments on draft-ietf-mobike-protocol-00.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Hi Maureen, and thanks for your comments! >Sections 1, 2 and 3 look great to me. Thanks for the fast turnaround. > >Comments on 4. Security considerations > >The IESG security reviewer of this section will be concerned with 3 >issues: > >1. Is there a mitigation for every threat? >2. Which mitigations are associated with which threats? >3. For each threat, what are the specific mitigation(s)? > >This section does not make this explicit. > Yes, this is an issue. >Here is a suggestion for >this, which is to label the threats and countermeasures and refer to >them, but other ways will work as well. I have included more technical >comments inline. > >Threat 1: Traffic redirection and hijacking > > Insecure mobility management mechanisms may allow inappropriate > redirection of traffic. This may allow inspection of the traffic > as well as man-in-the-middle and session hijacking attacks. > > The scope of these attacks in the MOBIKE case is limited, as all > traffic is protected using IPsec. > >Mitigation: Countermeasure 1 - Payload traffic protection, etc. > > (* Delete this and move to threat 2 *) However, it should be >observed > that security associations originally created for the protection > of a specific flow between specific addresses may be moved through > MOBIKE. The level of required protection may be different in a > new location of a VPN client, for instance. > > There may not be 1-to-1 mapping between the threats and countermeasures. But maybe it would help to number the threats as you suggested above, and then refer to the numbers when talkking about the countermeasures later on (e.g., this countermeasure addresses threat 1.). >I would argue that this second paragraph is really a separate threat >that has nothing to do with traffic redirection and hijacking. So I >have made a separate threat number 2 as follows. > > Makes sense. >Threat 2: Roaming into a network with a different security policy > > Note that security associations originally created for the >protection > of a specific flow between specific addresses may be moved through > MOBIKE. The level of required protection may be different in a > new location of a VPN client, for instance. > >Mitigation: Countermeasure 6 - Policy enforcement for roaming clients, >etc. > >Threat 3: Third-party denial-of-service through flooding > >Mitigation: Countermeasure 6 - Strong authentication for IKEv2, etc. > >Threat 4: Spoofing indications related to network connectivity > >(* There is a discussion here of this issue and then a similar >discussion is repeated in the countermeasure section OUTSIDE of the list >of countermeasures. It starts with the sentence: "MOBIKE does not >provide any protection of its own for indications..." I'm not sure why >it is structured this way and it is confusing.*) > > Hmm. Do you you have a suggested rewrite of this sentence? >Mitigation: Countermeasure 5 - Use of security mechanisms in network and >lower layers, etc. > >Threat 5: Denial-of-service of the participants through MOBIKE > >Mitigation: Countermeasure 5 - Use of security mechanisms in network and >lower layers, etc. > >MOBIKE addresses these threats using the following countermeasures: > >Countermeasure 1: Payload traffic protection > >Countermeasure 2: Protection of MOBIKE payloads > >Countermeasure 3: Explicit Address change > >When NAT Traversal is supported, the peer's address may be updated > automatically to allow changes in NAT mappings. The "continued > return routability" feature, implemented by the COOKIE2 payload, > allows verification of the new address after the change. This > limits the duration of any "third party bombing" attack by off- > path (relative to the victim) attackers. > >*** I'm not sure what a "continued return routability" feature means. >It is not defined anywhere else. You need another sentence or something >in the earlier section on return routability to clarify this. *** > > This needs to be synchronized with the rest of the draft. First paragraph of Section 2.6 does talk about that, so maybe a reference to that would be sufficient. >Countermeasure 4: Return routability tests > >***Delete the last paragraph beginning with: > MOBIKE does not provide any protection of its own for indications > from other parts of the protocol stack. However, MOBIKE is resistant > to incorrect information from these sources in the sense that it > provides its own security for both the signaling of addressing > information as well as actual payload data transmission. Denial-of- > service vulnerabilities remain, however. Some aspects of these > vulnerabilities can be mitigated through the use of techniques > specific to the other parts of the stack, such as properly dealing > with ICMP errors [ICMPAttacks], link layer security, or the use of > [SEND] to protect IPv6 Router and Neighbor Discovery.*** > >Substitute this with a countermeasure: > >Countermeasure 5: Use of security mechanisms in network and lower layers > > These > vulnerabilities can be mitigated through the use of techniques > specific to the other parts of the stack, such as properly dealing > with ICMP errors [ICMPAttacks], link layer security, or the use of > [SEND] to protect IPv6 Router and Neighbor Discovery. > > The new text is shorter, but it may not describe well why what happens in ND matters for MOBIKE. That was the intent of the sentence that talked about indications. >Countermeasure 6: Policy enforcement for roaming clients > >This mitigation is strictly dependent on policy so there are many >acceptable scenarios for mitigating this risk. The following scenario >is included for illustrative purposes only. > >Suppose the level of protection is greater at the new location than it >is at the old. Then this new address should not be included in any >address list and a new security association should be created when this >client moves. > >Suppose the level of protection is less at the new location that at the >old. Then it is allowable to include this network address in the >additional address list. > >This may seem overly nit picking, but what I'm really doing here is >making the case that you have a sound security threat analysis and a >list of effective countermeasures that will stand up under security >scrutiny. I haven't worked out all the text here and I realize there >are holes in this writeup but this shows the general idea. > > Thanks for the suggestions, I think this makes the section better, and does indeed help readers understand what is covered and what is not. Lets give Pasi some editing freedom to fix this... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 30 13:10:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyur6-0006wS-Ak for mobike-archive@megatron.ietf.org; Sat, 30 Jul 2005 13:10:36 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19704 for ; Sat, 30 Jul 2005 13:10:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4AFE9FB298; Sat, 30 Jul 2005 13:10:34 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 57A6CFB285; Sat, 30 Jul 2005 13:10:17 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6696AFB28A; Sat, 30 Jul 2005 13:09:56 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id B3EC7FB286 for ; Sat, 30 Jul 2005 13:09:50 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 464B98985E; Sat, 30 Jul 2005 20:09:42 +0300 (EEST) Message-ID: <42EB95D7.9010000@piuha.net> Date: Sat, 30 Jul 2005 17:59:35 +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 Subject: Re: [Mobike] Issue 22: is disabling NAT traversal a possibility (was: Review of draft-ietf-mobike-protocol-00) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, ldondeti@qualcomm.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >Lakshminath Dondeti wrote: > > >> o If NAT Traversal is supported and NAT detection payloads >> were included, enables or disables NAT Traversal. >> >> I may be wrong, but is disabling NAT Traversal a >>possibility here? >> >> >> > >Hmm.. any reasons why it wouldn't be? > >The text is a bit short here, but it roughly means that "if NAT >detection payloads show that there's no NAT, then don't use UDP >encapsulation for outgoing ESP packets any more" > >(Or did you mean that it would be better to use some other words >than "enable" and "disable" here?) > > I think your thinking is correct here, but the text needs to be expanded. We have the following cases: o NAT-T supported by responder, no NAT payloads from initiator, address changed o NAT-T supported by responder, no NAT payloads from initiator, address not changed o NAT-T supported by responder, NAT payloads from initiator, address changed o NAT-T supported by responder, NAT payloads from initiator, address not changed o NAT-T not supported by responder, no NAT payloads from initiator, address changed o NAT-T not supported by responder, no NAT payloads from initiator, address not changed o NAT-T not supported by responder, NAT payloads from initiator, address changed o NAT-T not supported by responder, NAT payloads from initiator, address not changed I believe only case 3 should lead to UDP encapsulation being turned on. Cases 2, 4, 6, 8 turn it off, and cases 1, 5, and 7 should lead to some kind of an error, I think... this may already be specified somehow in the original IKEv2 specs, I have not checked... --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sat Jul 30 13:22:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dyv2L-0000kL-6M for mobike-archive@megatron.ietf.org; Sat, 30 Jul 2005 13:22:13 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20038 for ; Sat, 30 Jul 2005 13:22:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8E2A4FB28D; Sat, 30 Jul 2005 13:22:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B9B86FB28A; Sat, 30 Jul 2005 13:22:07 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C6BBCFB28B; Sat, 30 Jul 2005 13:22:06 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 1EACEFB289 for ; Sat, 30 Jul 2005 13:22:06 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 35C7589832; Sat, 30 Jul 2005 20:22:05 +0300 (EEST) Message-ID: <42EBB746.4030404@piuha.net> Date: Sat, 30 Jul 2005 20:22:14 +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 Subject: Re: [Mobike] Issue 33: Changing ports 500/4500 and RR References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, kivinen@iki.fi X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: >Tero Kivinen wrote: > > > >>>2.7 NAT prevention >>> >>> >>... >> >> >>> If the IKE_SA_INIT request included NAT_DETECTION_*_IP >>> payloads but no NAT_PREVENTION payload, the situation is >>> different since the initiator may at this point change >>> from port 500 to 4500. In this case, the responder >>> initializes (local_address, local_port, peer_address, >>> peer_port) from the first IKE_AUTH request. It may also >>> decide to perform a return routability check soon after >>> the IKE_AUTH exchanges have been completed. >>> >>> > > > >>Why does it need to do the return routability check? IKEv2 >>NAT-T does not do return routability checks there, why should >>we do? Note, that the initiator will not see any IPsec packets >>thus he cannot for example start TCP sessions, as those are >>not retransmittede to secondary addresses. I cannot really see >>how he could mount any real attack at this phase. >> >> > >Hmm.. you're probably right, there's no good reason to do >the return routability check at this stage. I guess we can >delete the last sentence..? > > Agreed. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Jul 31 04:19:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz931-0000ms-JV for mobike-archive@megatron.ietf.org; Sun, 31 Jul 2005 04:19:53 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11705 for ; Sun, 31 Jul 2005 04:19:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5DC57FB292; Sun, 31 Jul 2005 04:19:43 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B0BDCFB289; Sun, 31 Jul 2005 04:19:39 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 040A1FB28A; Sun, 31 Jul 2005 04:19:37 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id 63211FB285 for ; Sun, 31 Jul 2005 04:19:35 -0400 (EDT) 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 j6V8JAR03727; Sun, 31 Jul 2005 10:19:10 +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 j6V8J87s004529; Sun, 31 Jul 2005 10:19:09 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200507310819.j6V8J87s004529@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Mobike] Issue 23: Payload type for addresses (was: Review of draft-ietf-mobike-protocol-00) In-reply-to: Your message of Tue, 12 Jul 2005 12:25:27 +0300. Date: Sun, 31 Jul 2005 10:19:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, ldondeti@qualcomm.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 In your previous mail you wrote: But we could of course promote ADDITIONAL_ADDRESS from a Notification to a real "top-level" payload type. Any comments from others about this? => I believe we should keep Notifications because this allows to declare additional addresses in the second exchange. This can be used for instance for the home registration BU/BA protection in MIPv6: IKE runs over the care-of address but the SA pair is a transport mode with the home address in the source traffic selector. The care-of address is authorized because IKE exchanges include an implicit return routability check, the home address is usually explicitly authorized through configuration and/or the mobile node certificate, and the transport mode in Mobike I-D applies... 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 Jul 31 04:47:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dz9TT-00088D-3t for mobike-archive@megatron.ietf.org; Sun, 31 Jul 2005 04:47:11 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12388 for ; Sun, 31 Jul 2005 04:47:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9C973FB285; Sun, 31 Jul 2005 04:47:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id CB741FB285; Sun, 31 Jul 2005 04:47:05 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2EAEFFB289; Sun, 31 Jul 2005 04:47:04 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by machshav.com (Postfix) with ESMTP id C6A01FB281 for ; Sun, 31 Jul 2005 04:47:02 -0400 (EDT) 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 j6V8ktR04617; Sun, 31 Jul 2005 10:46:55 +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 j6V8ksHf004605; Sun, 31 Jul 2005 10:46:54 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200507310846.j6V8ksHf004605@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Mobike] Issue 34: Separate path test, handling changes in NAT mappings In-reply-to: Your message of Thu, 14 Jul 2005 11:19:50 +0300. <17110.8230.250955.929942@fireball.kivinen.iki.fi> Date: Sun, 31 Jul 2005 10:46:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: mobike@machshav.com, Pasi.Eronen@nokia.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 In your previous mail you wrote: Actually the original idea behind the charter was that MOBIKE would not do anything about NATs, i.e. if NAT is detected, then we do not use MOBIKE, but simply use normal NAT-T (note the "if any" in the text saying "MOBIKE should not be tightly coupled with the NAT traversal function, but it is necessary to specify in which cases (if any) they can be used together, and how they interact"). => the original idea was the right one IMHO... This was already decided in the WG that we do want to use MOBIKE and NAT-T together. => and this even there is no real world case of MOBIKE+NAT-T... My understanding of the that charter text is that we are not allowed to modify actual UDP encapsulation part of the NAT-T, and we must use the NAT-T mechanisms in the IKEv2, but we can profile the NAT-T (i.e. say which features are mandatory to implement and which are not, or which features must be enabled or disabled). => if you mean that the NAT-T dynamic update is mandatory to implement I agree! 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 Jul 31 05:23:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzA2S-00064F-Ea for mobike-archive@megatron.ietf.org; Sun, 31 Jul 2005 05:23:20 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13428 for ; Sun, 31 Jul 2005 05:23:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F386CFB291; Sun, 31 Jul 2005 05:23:16 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6AA6EFB289; Sun, 31 Jul 2005 05:23:15 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A56E5FB28D; Sun, 31 Jul 2005 05:23:13 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 895B2FB285 for ; Sun, 31 Jul 2005 05:23:12 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 8FE6D89832; Sun, 31 Jul 2005 12:23:06 +0300 (EEST) Message-ID: <42EC9884.1020009@piuha.net> Date: Sun, 31 Jul 2005 12:23:16 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List Subject: [Mobike] issue 32 -- Omitting COOKIE2 from non-RR messages X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Tero wrote: >> 2.6 Return routability check >... >> To ensure that the peer cannot generate the correct INFORMATIONAL >> response without seeing the request, a new payload is added to all >> INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST >> include a COOKIE2 notification payload, and the recipient of an >> INFORMATIONAL request MUST copy the payload 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. > >I donot think we need to moify all INFORMATIONAL exhcnages to include >N(COOKIE2), only those that are used for the return routability >checks. > > I think I agree... >> 3.5 COOKIE2 notification payload >> >> This payload is included in all INFORMATIONAL exchange messages for >> return routability check purposes (see Section 2.6). It is also used >> in PATH_TEST messages to match requests and responses (see >> Section 2.5). > >I would say we define this in more generic way: > > This payload MAY be included in any IKEv2 exchange. The data > associated with this notification MUST be between 8 and 64 > octets in length (inclusive), and MUST be chosen in a way that > is unpredictable to the recipient. The recipient MUST copy > this notification to his reply packet. The negotation > initiator MUST then check that the N(COOKIE2) received from > the other peer matches the one he sent out. > > This message MUST be included in the IKE exchanges used as a > return routability check. > > The Notify Message Type for this message is TBD-BY-IANA > (16396..40959). The Protocol ID field is set to zero (0), and > SPI Size is set to zero. > > Ok. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Sun Jul 31 05:23:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzA2s-00064v-Pu for mobike-archive@megatron.ietf.org; Sun, 31 Jul 2005 05:23:46 -0400 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13439 for ; Sun, 31 Jul 2005 05:23:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8F75AFB294; Sun, 31 Jul 2005 05:23:45 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 26F29FB289; Sun, 31 Jul 2005 05:23:38 -0400 (EDT) X-Original-To: mobike@machshav.com Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E3BDDFB294; Sun, 31 Jul 2005 05:23:36 -0400 (EDT) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by machshav.com (Postfix) with ESMTP id 8B2EEFB285 for ; Sun, 31 Jul 2005 05:23:31 -0400 (EDT) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id C625889832; Sun, 31 Jul 2005 12:23:30 +0300 (EEST) Message-ID: <42EC8BE5.3010907@piuha.net> Date: Sun, 31 Jul 2005 11:29:25 +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 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List Subject: [Mobike] issue 31 -- responder address changes X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: 7bit Tero wrote: >> 2.4 Updating additional addresses >... >> There is one additional complication: when the responder wants to >> send a new additional address list, the currently used path may no >> longer work. In this case, the responder uses the additional address >> list received from the initiator, the list of its own addresses, and, >> if necessary, the path testing feature (see Section 2.5) to determine >> a path that works, updates the addresses in the IKE_SA (but not IPsec >> SAs), and then sends the INFORMATIONAL request. This is the only >> time the responder uses the additional address list received from the >> initiator. > >This is no way only related to the updating addresses, it might be >also break down during any other exchange, and if the responder does >not do try all address pairs when sending IKE packets, it will cause >IKE SA to deleted because of timed out exchange unless the initiators >DPD timers are much shorter than responders negotiation timeout >timers. > >I mean if initiator does DPD, and notices that everything is fine, >then address pair breaks down, and then responder starts sending some >IKE packet. If this IKE packet manages to time out before the next DPD >has started, and detected the problem, and found the new working >address pair, and sent an address update by N(CHANGE_PATH) then the >responder will delete the IKE SA > > Right. >There are cases where the responder cannot do anything, because of the >NATs, so in those cases this will happen anyways, but if there is no >NATs preventing original responder for sending packets to original >initiator then the original responder can simply try other address >pairs, to see if them work. If not, then delete the IKE SA, if one of >them work, fine, he did get his operation done, and original initiator >probably got some hint about something being wrong... > >If we decide that we do not need this feature, then we can simply >leave out the address lists in the responder side completely, and say >that responder will not try to fix any situations, and it will not >support break-before-make style movement to new addresses unknown by >the initiator. > > Right. But I think we want this feature. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike