From mobike-bounces@machshav.com Mon Jun 21 11:09:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19386 for ; Mon, 21 Jun 2004 11:09:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D6A60FB4E4; Mon, 21 Jun 2004 11:09:34 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E86CBFB4D9; Mon, 21 Jun 2004 11:09:31 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9A0CDFB4DB; Mon, 21 Jun 2004 11:09:29 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id CB887FB4D7 for ; Mon, 21 Jun 2004 11:09:28 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4CC28898C2; Mon, 21 Jun 2004 18:09:26 +0300 (EEST) Message-ID: <40D6F914.1030205@piuha.net> Date: Mon, 21 Jun 2004 18:04:52 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman / VPNC Subject: [Mobike] MOBIKE work X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 This list has been quiet for too long, given the level of interest people have expressed off-line. We would love to get the WG moving again so that we can move towards getting the protocol written. To that end, we have asked Tero to update the problem statement document. In order to do that, he needs more input on what the WG thinks about some of the open issues. Once we have more stability in the problem statement document, the editors of the three proposed protocol drafts can respond more intelligently in updated versions. That is, if we give a better set of parameters to the design space, the protocols will move towards those parameters. At that point, it will be easier to pick which protocol proposal(s) to move forwards with. In any case, the three editors have promised to update their documents for San Diego. The next few e-mails are about the open issues in the MOBIKE design. Please respond to the e-mails and let us know what you think should be done to the issues. There are probably some more issues as well -- if you think you have an issue that has not been discussed, please post that to the list as well, with a new Subject: line. At this time we would like to focus the discussion on the first group of issues, the user visible "requirements". This is because it seems that those issues have a big impact on the protocol design, and getting an answer to them will help us move forward. We have grouped the issues as follows: User-level visible "requirement" issues: ======================================== - Level of support for NAT-T - MOBIKE interaction? - Should MOBIKE react to problems that are not known locally: your interface went down vs. some router on the path died? - How much protection against 3rd party bombing should MOBIKE offer? - Should MOBIKE support movement from IPv4 to IPv6 and vice versa? - Are simultaneous movements of two mobile nodes supported by MOBIKE? Other issues which clearly need a lot of work: ============================================== - Explicit vs. implicit address changes. - Whether MOBIKE handles changes to individual addresses or paths (= address pairs). - How to do path testing & congestion control? Smaller issues that might be easy to decide: ============================================ - Signaling support for MOBIKE. - What the role of MOBIKE return routability tests is versus other similar tests in other protocols, such as Mobile IPv6? - Are empty informational exchanges sufficient for return routability test, or is a cookie needed? - Is a set of zero addresses allowed? - Move all SAs at once, or allow individual movements? - Window size issues. Paul & Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 21 11:24:53 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20239 for ; Mon, 21 Jun 2004 11:24:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7DA7EFB4E4; Mon, 21 Jun 2004 11:24:54 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 30D87FB4DB; Mon, 21 Jun 2004 11:24:53 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 39DBDFB4E0; Mon, 21 Jun 2004 11:24:51 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id A2E62FB4D7 for ; Mon, 21 Jun 2004 11:24:50 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id B01AF898C2; Mon, 21 Jun 2004 18:24:49 +0300 (EEST) Message-ID: <40D6FCB0.9060908@piuha.net> Date: Mon, 21 Jun 2004 18:20:16 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman / VPNC Subject: [Mobike] Issue: NAT-T interaction (#3) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 This is about the interaction with NAT traversal: does the MOBIKE protocol work one one party goes behind NAT, comes from behind NAT, or goes from one NAT to another? There was a lot of discussion about this at Seoul, so it is clearly an issue of concern to many people. Is limiting our protocol to only working if there is no NAT might be too restrictive because most users don't know when they are behind a NAT, or are about to move to behind a NAT? Or should MOBIKE and NAT-T be seen as alternative solutions; if you enable NAT-T then you use just that and live with its limitations & if you use MOBIKE then you don't have a NAT? In Seoul it seemed that the WG wanted MOBIKE and NAT-T to work together. If so, would testing for NATs occur after each address change? [Reminder: our charter says we shall not replace or modify NAT traversal, and that we should not integrate the protocol tightly with NAT traversal. However, we need to document how (and when) they work together.] _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 21 11:30:25 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20615 for ; Mon, 21 Jun 2004 11:30:24 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 4C00EFB4E4; Mon, 21 Jun 2004 11:30:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9EC25FB4D9; Mon, 21 Jun 2004 11:30:25 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C12C9FB4E0; Mon, 21 Jun 2004 11:30:23 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 5166CFB4D7 for ; Mon, 21 Jun 2004 11:30:23 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2DF0C898C2; Mon, 21 Jun 2004 18:30:22 +0300 (EEST) Message-ID: <40D6FDFC.7080507@piuha.net> Date: Mon, 21 Jun 2004 18:25:48 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman / VPNC Subject: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 Should MOBIKE only react to problems that are known to the nodes locally? For instance, if an interface in a host goes down, or it is assigned a new address, then the node knows about this and can tell its peer. Or should MOBIKE also deal with other problems, typically based on the symptom of not getting packets through? For instance, should MOBIKE attempt to do a failover upon seeing - DPD failure - ICMP error - No response to the MOBIKE protocol messages - No incoming payload packets _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 21 12:55:19 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02864 for ; Mon, 21 Jun 2004 12:55:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 68BF0FB4E6; Mon, 21 Jun 2004 12:55:19 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A5D37FB4D9; Mon, 21 Jun 2004 12:55:16 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E0EB4FB4DF; Mon, 21 Jun 2004 12:55:15 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by machshav.com (Postfix) with ESMTP id 25053FB4D7 for ; Mon, 21 Jun 2004 12:55:15 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5LGt9K24520; Mon, 21 Jun 2004 12:55:09 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id ; Mon, 21 Jun 2004 12:55:08 -0400 Message-ID: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com> From: "Jing Xiang" To: jari.arkko@piuha.net, MOBIKE Mailing List Subject: RE: [Mobike] Issue: NAT-T interaction (#3) Date: Mon, 21 Jun 2004 12:55:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1123112085==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1123112085== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C457B0.7F0365EA" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C457B0.7F0365EA Content-Type: text/plain; charset="ISO-8859-1" I would say any solution we come up MUST work with NAT, maybe not all types of NATs but at least basic NAT environment. Rather than testing NAT existance after each address change I would recommend us consider forcing UDP wrapper on for all mobile cases. The pro is that the connection will be re-established with no additional signaling and it will work even if NAT is added after address change without peers being aware of it. Of course the drawback is that we add extra 8 bytes to the data. Regards! /Jing -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Monday, June 21, 2004 11:20 AM To: MOBIKE Mailing List Cc: Paul Hoffman / VPNC Subject: [Mobike] Issue: NAT-T interaction (#3) This is about the interaction with NAT traversal: does the MOBIKE protocol work one one party goes behind NAT, comes from behind NAT, or goes from one NAT to another? There was a lot of discussion about this at Seoul, so it is clearly an issue of concern to many people. Is limiting our protocol to only working if there is no NAT might be too restrictive because most users don't know when they are behind a NAT, or are about to move to behind a NAT? Or should MOBIKE and NAT-T be seen as alternative solutions; if you enable NAT-T then you use just that and live with its limitations & if you use MOBIKE then you don't have a NAT? In Seoul it seemed that the WG wanted MOBIKE and NAT-T to work together. If so, would testing for NATs occur after each address change? [Reminder: our charter says we shall not replace or modify NAT traversal, and that we should not integrate the protocol tightly with NAT traversal. However, we need to document how (and when) they work together.] _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike ------_=_NextPart_001_01C457B0.7F0365EA Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Mobike] Issue: NAT-T interaction (#3)

I would say any solution we come up MUST work with = NAT, maybe not
all types of NATs but at least basic NAT = environment.

Rather than testing NAT existance after each address = change I would recommend us
consider forcing UDP wrapper on for all mobile = cases. The pro is that the connection
will be re-established with no additional signaling = and it will work even
if NAT is added after address change without peers = being aware of it.
Of course the drawback is that we add extra 8 bytes = to the data.

Regards!

/Jing


-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@piuha.net]
Sent: Monday, June 21, 2004 11:20 AM
To: MOBIKE Mailing List
Cc: Paul Hoffman / VPNC
Subject: [Mobike] Issue: NAT-T interaction = (#3)



This is about the interaction with NAT = traversal:
does the MOBIKE protocol work one one party goes = behind NAT,
comes from behind NAT, or goes from one NAT to = another?
There was a lot of discussion about this at Seoul, = so it
is clearly an issue of concern to many people. Is = limiting
our protocol to only working if there is no NAT = might be
too restrictive because most users don't know when = they
are behind a NAT, or are about to move to behind a = NAT?

Or should MOBIKE and NAT-T be seen as = alternative
solutions; if you enable NAT-T then you use = just
that and live with its limitations & if you = use
MOBIKE then you don't have a NAT?

In Seoul it seemed that the WG wanted MOBIKE = and
NAT-T to work together. If so, would testing = for
NATs occur after each address change?

[Reminder: our charter says we shall not = replace
or modify NAT traversal, and that we should = not
integrate the protocol tightly with NAT = traversal.
However, we need to document how (and when) = they
work together.]

_______________________________________________
Mobike mailing list
Mobike@machshav.com
https://www.machshav.com/mailman/listinfo.cgi/mobike

------_=_NextPart_001_01C457B0.7F0365EA-- --===============1123112085== 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 --===============1123112085==-- From mobike-bounces@machshav.com Mon Jun 21 14:29:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14233 for ; Mon, 21 Jun 2004 14:29:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E343FFB4E6; Mon, 21 Jun 2004 14:29:02 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 3EDD7FB4D8; Mon, 21 Jun 2004 14:29:00 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9D367FB4D9; Mon, 21 Jun 2004 14:28:58 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 2BD87FB4D7 for ; Mon, 21 Jun 2004 14:28:58 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 01253898C8; Mon, 21 Jun 2004 21:28:56 +0300 (EEST) Message-ID: <40D727D6.1080206@piuha.net> Date: Mon, 21 Jun 2004 21:24:22 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman / VPNC Subject: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 Does switching from IPv4 to IPv6 or vice versa work? (Presumably yes. Its hard to see why this would cause any problems.) _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 21 14:46:57 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15900 for ; Mon, 21 Jun 2004 14:46:56 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 80E18FB4E6; Mon, 21 Jun 2004 14:46:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 79F7AFB4D8; Mon, 21 Jun 2004 14:46:56 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 29F0FFB4D9; Mon, 21 Jun 2004 14:46:55 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 7F619FB4D7 for ; Mon, 21 Jun 2004 14:46:54 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 6FEAF898C8; Mon, 21 Jun 2004 21:46:53 +0300 (EEST) Message-ID: <40D72C0B.7010308@piuha.net> Date: Mon, 21 Jun 2004 21:42:19 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman / VPNC Subject: [Mobike] Issue: Simultaneous movements (#2) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 This is about the level of support for simultaneous movements by the communicating parties. There seems to be a number of different cases here: (a) Two mobile nodes getting a new address at the same time, and then being unable to tell each other where they are. This problem is called the rendevouz problem, and is traditionally solved using home agents (Mobile IPv6) or forwarding agents (Host Identity Protocol). Essentially, solving this problem requires the existence of a stable infrastructure node somewhere. Example: roaming laptop to another roaming laptop, no SGW involved. (b) Simultanous changes to addresses such that at least one of the new addresses was known by both peers before the change occurred. The primary problem in case (a) was not knowing the new addresses beforehand. Example 1: two SGWs failover to another path. Example 2: roaming laptop gets a new address at the same time as its SGW's primary interface goes down. (c) No simultaneous changes at all. [Our charter prohibits the creation of a fully fledged mobility protocol, so it seems that we should avoid introducing new network nodes to solve the rendevouz problem. Therefore, case (b) seems like a good candidate for us. This would still allow two SGWs to failover from one common interface to another. And of course, if someone wants to set up their IPsec tunnels so that everything always goes through one stable anchorpoint in the network, they can do so.] _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 21 14:50:29 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15977 for ; Mon, 21 Jun 2004 14:50:29 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 0496EFB4E8; Mon, 21 Jun 2004 14:50:30 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A02D8FB4D8; Mon, 21 Jun 2004 14:50:28 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0772FFB4D9; Mon, 21 Jun 2004 14:50:27 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by machshav.com (Postfix) with ESMTP id 5D657FB4D7 for ; Mon, 21 Jun 2004 14:50:26 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5LIoGK12222; Mon, 21 Jun 2004 14:50:16 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MXJCP1WR; Mon, 21 Jun 2004 14:50:15 -0400 Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M0RMXX13; Mon, 21 Jun 2004 14:50:14 -0400 Message-ID: <40D72DE6.1020901@nortelnetworks.com> Date: Mon, 21 Jun 2004 14:50:14 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Simultaneous movements (#2) References: <40D72C0B.7010308@piuha.net> In-Reply-To: <40D72C0B.7010308@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 (b) sounds like a reasonable choice. Lakshminath Jari Arkko wrote: > > This is about the level of support for simultaneous > movements by the communicating parties. > > There seems to be a number of different cases here: > > (a) Two mobile nodes getting a new address at the > same time, and then being unable to tell each > other where they are. This problem is called the > rendevouz problem, and is traditionally solved > using home agents (Mobile IPv6) or forwarding > agents (Host Identity Protocol). Essentially, > solving this problem requires the existence of > a stable infrastructure node somewhere. > > Example: roaming laptop to another roaming laptop, > no SGW involved. > > (b) Simultanous changes to addresses such that at > least one of the new addresses was known by > both peers before the change occurred. The > primary problem in case (a) was not knowing > the new addresses beforehand. > > Example 1: two SGWs failover to another path. > Example 2: roaming laptop gets a new address > at the same time as its SGW's primary interface > goes down. > > (c) No simultaneous changes at all. > > [Our charter prohibits the creation of a fully > fledged mobility protocol, so it seems that we > should avoid introducing new network nodes to > solve the rendevouz problem. Therefore, case (b) > seems like a good candidate for us. This would > still allow two SGWs to failover from one common > interface to another. And of course, if someone > wants to set up their IPsec tunnels so that everything > always goes through one stable anchorpoint in the > network, they can do so.] > > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 21 14:51:47 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16197 for ; Mon, 21 Jun 2004 14:51:47 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 27D6CFB4E9; Mon, 21 Jun 2004 14:51:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B68FFFB4E0; Mon, 21 Jun 2004 14:51:47 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E2CF4FB4E6; Mon, 21 Jun 2004 14:51:45 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by machshav.com (Postfix) with ESMTP id 64CFAFB4D7 for ; Mon, 21 Jun 2004 14:51:45 -0400 (EDT) Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5LIpd815793; Mon, 21 Jun 2004 13:51:39 -0500 (CDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zsc3c028.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MX267C9B; Mon, 21 Jun 2004 11:51:40 -0700 Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M0RMXX1S; Mon, 21 Jun 2004 14:51:38 -0400 Message-ID: <40D72E3A.9000808@nortelnetworks.com> Date: Mon, 21 Jun 2004 14:51:38 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) References: <40D727D6.1080206@piuha.net> In-Reply-To: <40D727D6.1080206@piuha.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 would think so too! Lakshminath Jari Arkko wrote: > > Does switching from IPv4 to IPv6 or vice versa work? > (Presumably yes. Its hard to see why this would cause > any problems.) > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 21 20:00:39 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18069 for ; Mon, 21 Jun 2004 20:00:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id C37E8FB4E0; Mon, 21 Jun 2004 20:00:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9FB73FB4D9; Mon, 21 Jun 2004 20:00:36 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9CD26FB4DF; Mon, 21 Jun 2004 20:00:34 -0400 (EDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by machshav.com (Postfix) with ESMTP id 26F41FB4D7 for ; Mon, 21 Jun 2004 20:00:34 -0400 (EDT) Received: from localhost ([130.194.13.85]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01LBLE0W1EUQ8ZGW8H@vaxh.its.monash.edu.au> for mobike@machshav.com; Tue, 22 Jun 2004 09:59:41 +1000 Received: from broink.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 4A481158007; Tue, 22 Jun 2004 09:59:41 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by broink.its.monash.edu.au (Postfix) with ESMTP id 3037A120004; Tue, 22 Jun 2004 09:59:41 +1000 (EST) Date: Tue, 22 Jun 2004 09:59:40 +1000 From: Greg Daley Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) To: jari.arkko@piuha.net Message-id: <40D7766C.7000605@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <40D6FDFC.7080507@piuha.net> Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: greg.daley@eng.monash.edu.au 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 Jari, Jari Arkko wrote: > > Should MOBIKE only react to problems that are known > to the nodes locally? For instance, if an interface > in a host goes down, or it is assigned a new address, > then the node knows about this and can tell its peer. > > Or should MOBIKE also deal with other problems, typically > based on the symptom of not getting packets through? > For instance, should MOBIKE attempt to do a failover > upon seeing > > - DPD failure > - ICMP error > - No response to the MOBIKE protocol messages > - No incoming payload packets I think that there's obviously an issue with using a mechanism which isn't in itself secured to indicate changes. This may prevent generic ICMP being used. The incoming payload packets or MOBIKE messages may be another matter, although it's worth considering that an orchestrated DoS attack against devices on the path between the two endpoints could be used to force selection of another path which is preferable to the attackers. I think these are generic concerns with such backup procedures though, not just for MOBIKE. Greg _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 04:10:41 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16269 for ; Tue, 22 Jun 2004 04:10:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5CDDCFB4D7; Tue, 22 Jun 2004 04:10:41 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 44613FB4D9; Tue, 22 Jun 2004 04:10:40 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id EE815FB4E0; Tue, 22 Jun 2004 04:10:37 -0400 (EDT) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by machshav.com (Postfix) with ESMTP id 37068FB4D7 for ; Tue, 22 Jun 2004 04:10:37 -0400 (EDT) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161] (may be forged)) by TYO202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i5M8AUY13484 for ; Tue, 22 Jun 2004 17:10:33 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i5M8AUD18740 for mobike@machshav.com; Tue, 22 Jun 2004 17:10:30 +0900 (JST) Received: from ncos.nec.co.jp (mailgate2.ncos.nec.co.jp [10.40.15.12]) by mailsv5.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with SMTP id i5M8ATa14260 for ; Tue, 22 Jun 2004 17:10:29 +0900 (JST) Received: (qmail 8886 invoked by uid 0); 22 Jun 2004 17:10:25 +0900 Received: from unknown (HELO platini.ntes.ipv6.nec.co.jp) (10.43.90.28) by 172.16.255.129 with SMTP; 22 Jun 2004 17:10:25 +0900 Received: from bn4p0048.bn4.bbn.ncos.nec.co.jp ([IPv6:5ffe:26:2591:1:203:47ff:feb1:ba04]) by platini.ntes.ipv6.nec.co.jp (8.12.11/8.12.11) with SMTP id i5M8ANiY018456; Tue, 22 Jun 2004 17:10:24 +0900 (JST) (envelope-from inoue@ntes.ipv6.nec.co.jp) Date: Tue, 22 Jun 2004 17:10:23 +0900 From: Satoshi Inoue To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) Message-Id: <20040622171023.2bde4c1b.inoue@ntes.ipv6.nec.co.jp> In-Reply-To: <40D6FDFC.7080507@piuha.net> References: <40D6FDFC.7080507@piuha.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, paul.hoffman@vpnc.org X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Mon, 21 Jun 2004 18:25:48 +0300 Jari Arkko wrote: > Or should MOBIKE also deal with other problems, typically > based on the symptom of not getting packets through? > For instance, should MOBIKE attempt to do a failover > upon seeing > > - DPD failure > - ICMP error > - No response to the MOBIKE protocol messages > - No incoming payload packets failover to clear SAs? If so, then it sounds like it's out of scope for MOBIKE. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 04:38:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17761 for ; Tue, 22 Jun 2004 04:38:51 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3ECB0FB4F3; Tue, 22 Jun 2004 04:38:53 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B6D93FB4EE; Tue, 22 Jun 2004 04:38:52 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3EEFDFB4F0; Tue, 22 Jun 2004 04:38:51 -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 1895BFB4E0 for ; Tue, 22 Jun 2004 04:38:50 -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 i5M8cNB07363; Tue, 22 Jun 2004 10:38:23 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5M8cMSj027907; Tue, 22 Jun 2004 10:38:22 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406220838.i5M8cMSj027907@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) In-reply-to: Your message of Mon, 21 Jun 2004 21:24:22 +0300. <40D727D6.1080206@piuha.net> Date: Tue, 22 Jun 2004 10:38:22 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: Does switching from IPv4 to IPv6 or vice versa work? (Presumably yes. Its hard to see why this would cause any problems.) => you can spread a bit the question: when an implementation supports many addresses for the same IPsec SA (cf RFC 3554, end of section 2), can the addresses mix IPv4 and IPv6? Regards Francis.Dupont@enst-bretagne.fr PS: IMHO the many simultaneous addresses per IPsec SA is not a good idea (not necessary and a bit hairy to implement) but when it is supported it should work with both IP versions at the same time. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 05:23:43 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20767 for ; Tue, 22 Jun 2004 05:23:42 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 20504FB4F8; Tue, 22 Jun 2004 05:23:44 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5BA4CFB4EE; Tue, 22 Jun 2004 05:23:42 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 77974FB4F0; Tue, 22 Jun 2004 05:23:40 -0400 (EDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by machshav.com (Postfix) with ESMTP id 8212DFB4E0 for ; Tue, 22 Jun 2004 05:23:39 -0400 (EDT) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.161] (may be forged)) by TYO201.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i5M9Nbp24382 for ; Tue, 22 Jun 2004 18:23:37 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i5M9NbC14580 for mobike@machshav.com; Tue, 22 Jun 2004 18:23:37 +0900 (JST) Received: from ncos.nec.co.jp (mailgate2.ncos.nec.co.jp [10.40.15.12]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with SMTP id i5M9Na609985 for ; Tue, 22 Jun 2004 18:23:36 +0900 (JST) Received: (qmail 16902 invoked by uid 0); 22 Jun 2004 18:23:36 +0900 Received: from unknown (HELO platini.ntes.ipv6.nec.co.jp) (10.43.90.28) by 172.16.255.130 with SMTP; 22 Jun 2004 18:23:36 +0900 Received: from bn4p0048.bn4.bbn.ncos.nec.co.jp ([IPv6:5ffe:26:2591:1:203:47ff:feb1:ba04]) by platini.ntes.ipv6.nec.co.jp (8.12.11/8.12.11) with SMTP id i5M9NY05020996; Tue, 22 Jun 2004 18:23:35 +0900 (JST) (envelope-from inoue@ntes.ipv6.nec.co.jp) Date: Tue, 22 Jun 2004 18:23:34 +0900 From: Satoshi Inoue To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) Message-Id: <20040622182334.24fde27c.inoue@ntes.ipv6.nec.co.jp> In-Reply-To: <40D727D6.1080206@piuha.net> References: <40D727D6.1080206@piuha.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com, paul.hoffman@vpnc.org X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Mon, 21 Jun 2004 21:24:22 +0300 Jari Arkko wrote: > Does switching from IPv4 to IPv6 or vice versa work? > (Presumably yes. Its hard to see why this would cause > any problems.) Hmmm... I don't think this would make life easier :-) How about IPvX capability/reachability checks? Some kind of signaling is done beforehand? BTW, are link-locals, scope-zones handled? Implementation dependent? Well, I think this is not much of a problem as on-link IPsec tunnels are not realistic though. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 05:33:00 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22052 for ; Tue, 22 Jun 2004 05:32:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 71541FB4E0; Tue, 22 Jun 2004 05:33:00 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C3305FB4F0; Tue, 22 Jun 2004 05:32:58 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 620C5FB4F2; Tue, 22 Jun 2004 05:32:57 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id DFB1AFB4E0 for ; Tue, 22 Jun 2004 05:32:56 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 2764489841; Tue, 22 Jun 2004 12:32:55 +0300 (EEST) Message-ID: <40D7FBB4.1050601@piuha.net> Date: Tue, 22 Jun 2004 12:28:20 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Satoshi Inoue Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) References: <40D6FDFC.7080507@piuha.net> <20040622171023.2bde4c1b.inoue@ntes.ipv6.nec.co.jp> In-Reply-To: <20040622171023.2bde4c1b.inoue@ntes.ipv6.nec.co.jp> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 Satoshi Inoue wrote: >>Or should MOBIKE also deal with other problems, typically >>based on the symptom of not getting packets through? >>For instance, should MOBIKE attempt to do a failover >>upon seeing >> >>- DPD failure >>- ICMP error >>- No response to the MOBIKE protocol messages >>- No incoming payload packets > > > failover to clear SAs? If so, then it sounds like it's out of scope > for MOBIKE. Do you mean that based on these "indirect" indications, MOBIKE would terminate the SAs? I think this is not necessary, normal IKEv2 mechanisms such as DPD will take care of it. However, the question is whether a MOBIKE node should attempt to use the peer's other address if one address seems not to work. (This would be in addition to using another address if the peer *told* you to use another address.) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 05:33:21 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22133 for ; Tue, 22 Jun 2004 05:33:20 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B7078FB4FB; Tue, 22 Jun 2004 05:33:22 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 98134FB4F0; Tue, 22 Jun 2004 05:33:21 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2826DFB4F2; Tue, 22 Jun 2004 05:33:20 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 9FBD5FB4E0 for ; Tue, 22 Jun 2004 05:33:18 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i5M9XGYu021298 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Jun 2004 12:33:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i5M9XFqX021295; Tue, 22 Jun 2004 12:33:15 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16599.64731.455264.603609@fireball.kivinen.iki.fi> Date: Tue, 22 Jun 2004 12:33:15 +0300 From: Tero Kivinen To: "Dondeti, Lakshminath" Subject: Re: [Mobike] Issue: Simultaneous movements (#2) In-Reply-To: <40D72DE6.1020901@nortelnetworks.com> References: <40D72C0B.7010308@piuha.net> <40D72DE6.1020901@nortelnetworks.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Dondeti, Lakshminath writes: > (b) sounds like a reasonable choice. I agree... > > (b) Simultanous changes to addresses such that at > > least one of the new addresses was known by > > both peers before the change occurred. The > > primary problem in case (a) was not knowing > > the new addresses beforehand. > > > > Example 1: two SGWs failover to another path. > > Example 2: roaming laptop gets a new address > > at the same time as its SGW's primary interface > > goes down. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 05:49:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23213 for ; Tue, 22 Jun 2004 05:49:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D9BFAFB4FA; Tue, 22 Jun 2004 05:49:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 42007FB4F2; Tue, 22 Jun 2004 05:49:05 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6A58FFB4F3; Tue, 22 Jun 2004 05:49:04 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id E4237FB4F0 for ; Tue, 22 Jun 2004 05:49:02 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i5M9n0Yu021397 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Jun 2004 12:49:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i5M9mvXx021394; Tue, 22 Jun 2004 12:48:57 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16600.137.619907.633510@fireball.kivinen.iki.fi> Date: Tue, 22 Jun 2004 12:48:57 +0300 From: Tero Kivinen To: "Jing Xiang" Subject: RE: [Mobike] Issue: NAT-T interaction (#3) In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com> References: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 14 min Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Jing Xiang writes: > I would say any solution we come up MUST work with NAT, maybe not > all types of NATs but at least basic NAT environment. The problem is that NAT-T does allow 3rd party bombing, and there is no way to prevent it, because we cannot authenticate the IP-address. Actually there is several different levels of 3rd party bombing. The first is one which can be done from anywhere from the net, simply by sending few faked packets. This can be prevented by return routability checks, i.e we verify that sender of the update packet can see packets destioned to the IP-address he gave. The next level is where the attacker is along the path to the party to be bombed. In this case return routability checks will not prevent the attack, as the attacker can reply to those checks, or forward them to the correct node, which will then answer to them. Only way to prevent 3rd party bombing is to require the other party authenticating the IP-address change, meaning it needs to know the IP-address seen by the other end and put it inside the payload. In this case the NAT is considered as an attacker along the path (it modified the packets), thus the checks will fail, and the address update is not done. So if we want to have full protection from 3rd party bombing (also those attackers who are along the path), we cannot use NAT-T. If we do not care about the 3rd party bombing, we can use NAT-T all the time. > Rather than testing NAT existance after each address change I would > recommend us consider forcing UDP wrapper on for all mobile cases. UDP wrapper is not really an issue here. We can negotiate that separately. The bigger issue is what we do for the 3rd party bombing. > The pro is that the connection will be re-established with no > additional signaling and it will work even if NAT is added after > address change without peers being aware of it. I cannot really see how there can be NAT coming along the path unless the peer notices it. If you had globally routable IP-address, why would you suddenly start NATing that to some other globally routable IP-address. In normal cases the peer who moves behind NAT, will notice that its IP-address change at the same time. > Of course the drawback is that we add extra 8 bytes to the data. My proposal would be to keep NAT-T and MOBIKE separate and you use one of them at time. If you are moved inside the NAT, and your policy allows NAT-T, then you move from MOBIKE to NAT-T. There is no need to send any address update notifications etc, as the NAT-T have built-in automatic IP-address change. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 05:52:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAB23473 for ; Tue, 22 Jun 2004 05:52:34 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 21450FB503; Tue, 22 Jun 2004 05:52:36 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A088DFB4FB; Tue, 22 Jun 2004 05:52:34 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 9FCC7FB500; Tue, 22 Jun 2004 05:52:32 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 89A52FB4FA for ; Tue, 22 Jun 2004 05:52:31 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i5M9qOYu021427 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 22 Jun 2004 12:52:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i5M9qNkV021424; Tue, 22 Jun 2004 12:52:23 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16600.343.525045.69465@fireball.kivinen.iki.fi> Date: Tue, 22 Jun 2004 12:52:23 +0300 From: Tero Kivinen To: greg.daley@eng.monash.edu.au Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) In-Reply-To: <40D7766C.7000605@eng.monash.edu.au> References: <40D6FDFC.7080507@piuha.net> <40D7766C.7000605@eng.monash.edu.au> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Greg Daley writes: > Hi Jari, > > Jari Arkko wrote: > > > > Should MOBIKE only react to problems that are known > > to the nodes locally? For instance, if an interface > > in a host goes down, or it is assigned a new address, > > then the node knows about this and can tell its peer. > > > > Or should MOBIKE also deal with other problems, typically > > based on the symptom of not getting packets through? > > For instance, should MOBIKE attempt to do a failover > > upon seeing > > > > - DPD failure > > - ICMP error > > - No response to the MOBIKE protocol messages > > - No incoming payload packets > > I think that there's obviously an issue with > using a mechanism which isn't in itself secured > to indicate changes. To indicate that there might be change, and we should start checks and perhaps a recovery. I.e. if we do not get any replies for out IKE packets then we should try to use other address for the other end, even when it have not send notification asking us to move to that address. The reason that address might be broken could be some router alogn the path which is dropping all packets. The other end cannot know that, thus it cannot send notifications to us, asking us to move to another address. ICMP host unreachable, can also used to trigger a dead peer detection check for the IKE sa, just to verify whether the IP-addresses still work. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 06:15:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25153 for ; Tue, 22 Jun 2004 06:15:06 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 30923FB507; Tue, 22 Jun 2004 06:15:08 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 13FE1FB500; Tue, 22 Jun 2004 06:15:06 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 878FDFB502; Tue, 22 Jun 2004 06:15:04 -0400 (EDT) Received: from TYO202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.202]) by machshav.com (Postfix) with ESMTP id 23081FB4FA for ; Tue, 22 Jun 2004 06:15:03 -0400 (EDT) Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.160] (may be forged)) by TYO202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i5MAF1Y12072 for ; Tue, 22 Jun 2004 19:15:01 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i5MAF1b29609 for mobike@machshav.com; Tue, 22 Jun 2004 19:15:01 +0900 (JST) Received: from mailsv3.ncos.nec.co.jp (mailgate2.ncos.nec.co.jp [10.40.15.12]) by mailsv4.nec.co.jp (8.11.7/3.7W-MAILSV4-NEC) with SMTP id i5MAF0629181 for ; Tue, 22 Jun 2004 19:15:00 +0900 (JST) Received: (qmail 14912 invoked by uid 0); 22 Jun 2004 19:14:59 +0900 Received: from unknown (HELO platini.ntes.ipv6.nec.co.jp) (10.43.90.28) by 172.16.255.131 with SMTP; 22 Jun 2004 19:14:59 +0900 Received: from bn4p0048.bn4.bbn.ncos.nec.co.jp ([IPv6:5ffe:26:2591:1:203:47ff:feb1:ba04]) by platini.ntes.ipv6.nec.co.jp (8.12.11/8.12.11) with SMTP id i5MAEwP8022766; Tue, 22 Jun 2004 19:14:58 +0900 (JST) (envelope-from inoue@ntes.ipv6.nec.co.jp) Date: Tue, 22 Jun 2004 19:14:58 +0900 From: Satoshi Inoue To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) Message-Id: <20040622191458.3277b4e5.inoue@ntes.ipv6.nec.co.jp> In-Reply-To: <40D7FBB4.1050601@piuha.net> References: <40D6FDFC.7080507@piuha.net> <20040622171023.2bde4c1b.inoue@ntes.ipv6.nec.co.jp> <40D7FBB4.1050601@piuha.net> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: mobike@machshav.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Tue, 22 Jun 2004 12:28:20 +0300 Jari Arkko wrote: > Do you mean that based on these "indirect" indications, > MOBIKE would terminate the SAs? I think this is not necessary, > normal IKEv2 mechanisms such as DPD will take care of it. Exactly. > However, the question is whether a MOBIKE node should > attempt to use the peer's other address if one address > seems not to work. (This would be in addition to using > another address if the peer *told* you to use another > address.) Oh, yes, I think it should. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 07:29:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01390 for ; Tue, 22 Jun 2004 07:29:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 71EA5FB4FA; Tue, 22 Jun 2004 07:29:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0A9BDFB502; Tue, 22 Jun 2004 07:29:03 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 027BDFB503; Tue, 22 Jun 2004 07:29:00 -0400 (EDT) Received: from ALPHA6.ITS.MONASH.EDU.AU (alpha6.its.monash.edu.au [130.194.1.25]) by machshav.com (Postfix) with ESMTP id 6E010FB4FA for ; Tue, 22 Jun 2004 07:29:00 -0400 (EDT) Received: from localhost ([130.194.13.83]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01LBM230CKFI8Y5008@vaxc.its.monash.edu.au> for mobike@machshav.com; Tue, 22 Jun 2004 21:28:37 +1000 Received: from splat.its.monash.edu.au (localhost.its.monash.edu.au [127.0.0.1]) by localhost (Postfix) with ESMTP id 8368D23C004; Tue, 22 Jun 2004 21:28:35 +1000 (EST) Received: from mail1.monash.edu.au (bigted.its.monash.edu.au [130.194.11.60]) by splat.its.monash.edu.au (Postfix) with ESMTP id 734FC16400A; Tue, 22 Jun 2004 21:28:35 +1000 (EST) Date: Tue, 22 Jun 2004 21:28:35 +1000 From: Greg Daley Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) To: Tero Kivinen Message-id: <22c579227504.22750422c579@mail1.monash.edu.au> MIME-version: 1.0 X-Mailer: Netscape Webmail Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Paul Hoffman / VPNC , greg.daley@eng.monash.edu.au X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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, ----- Original Message ----- From: Tero Kivinen Date: Tuesday, June 22, 2004 7:52 pm Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) > Greg Daley writes: > > Hi Jari, > > > > Jari Arkko wrote: > > > > > > Should MOBIKE only react to problems that are known > > > to the nodes locally? For instance, if an interface > > > in a host goes down, or it is assigned a new address, > > > then the node knows about this and can tell its peer. > > > > > > Or should MOBIKE also deal with other problems, typically > > > based on the symptom of not getting packets through? > > > For instance, should MOBIKE attempt to do a failover > > > upon seeing > > > > > > - DPD failure > > > - ICMP error > > > - No response to the MOBIKE protocol messages > > > - No incoming payload packets > > > > I think that there's obviously an issue with > > using a mechanism which isn't in itself secured > > to indicate changes. > > To indicate that there might be change, and we should start checks and > perhaps a recovery. I.e. if we do not get any replies for out IKE > packets then we should try to use other address for the other end, > even when it have not send notification asking us to move to that > address. The reason that address might be broken could be some router > alogn the path which is dropping all packets. The other end cannot > know that, thus it cannot send notifications to us, asking us to move > to another address. > > ICMP host unreachable, can also used to trigger a dead peer detection > check for the IKE sa, just to verify whether the IP-addresses still > work. Indeed. When there are other reasons to believe that the peer is alive though (packet exchange is actually occurring, or occurs a short period after the ICMP message), then these should be ignored. It may be that the DPD callback timer is shortened temporarily, and confirmed data exchange within the period resets it to normal levels without sending the R-U-Theres. Greg _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Tue Jun 22 12:59:42 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24965 for ; Tue, 22 Jun 2004 12:59:41 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2DF56FB508; Tue, 22 Jun 2004 12:59:42 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 54E84FB4F3; Tue, 22 Jun 2004 12:59:41 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BAAF5FB503; Tue, 22 Jun 2004 12:59:39 -0400 (EDT) Received: from smtp803.mail.sc5.yahoo.com (smtp803.mail.sc5.yahoo.com [66.163.168.182]) by machshav.com (Postfix) with SMTP id 56AB9FB4F0 for ; Tue, 22 Jun 2004 12:59:39 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp803.mail.sc5.yahoo.com with SMTP; 22 Jun 2004 16:59:38 -0000 Message-ID: <008801c4587a$4f0ca660$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , References: <200406220838.i5M8cMSj027907@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) Date: Tue, 22 Jun 2004 09:59:40 -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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 > In your previous mail you wrote: > > Does switching from IPv4 to IPv6 or vice versa work? > (Presumably yes. Its hard to see why this would cause > any problems.) > > => you can spread a bit the question: when an implementation supports > many addresses for the same IPsec SA (cf RFC 3554, end of section 2), > can the addresses mix IPv4 and IPv6? > The IKEv2 spec clearly allows this i.e mixing IPv4 and IPv6 traffic selectors on a single SA. But these are inner addresses. I thought Jari's question is about outer addresses ? Jari, can you clarify ? -mohan > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: IMHO the many simultaneous addresses per IPsec SA is not a good idea > (not necessary and a bit hairy to implement) but when it is supported > it should work with both IP versions at the same time. > _______________________________________________ > 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 Jun 22 13:13:45 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27863 for ; Tue, 22 Jun 2004 13:13:45 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8BF59FB50B; Tue, 22 Jun 2004 13:13:45 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E07D3FB4F3; Tue, 22 Jun 2004 13:13:44 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 692CAFB503; Tue, 22 Jun 2004 13:13:43 -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 550ACFB4F0 for ; Tue, 22 Jun 2004 13:13:42 -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 i5MHDRp15100; Tue, 22 Jun 2004 19:13:27 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5MHDRSj029706; Tue, 22 Jun 2004 19:13:27 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406221713.i5MHDRSj029706@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) In-reply-to: Your message of Tue, 22 Jun 2004 09:59:40 PDT. <008801c4587a$4f0ca660$861167c0@adithya> Date: Tue, 22 Jun 2004 19:13:27 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > => you can spread a bit the question: when an implementation supports > many addresses for the same IPsec SA (cf RFC 3554, end of section 2), > can the addresses mix IPv4 and IPv6? The IKEv2 spec clearly allows this i.e mixing IPv4 and IPv6 traffic selectors on a single SA. But these are inner addresses. I thought Jari's question is about outer addresses ? Jari, can you clarify ? => I've put the reference to avoid this issue: the question is about the outer addresses. 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 Tue Jun 22 17:04:22 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28274 for ; Tue, 22 Jun 2004 17:04:22 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AED80FB510; Tue, 22 Jun 2004 17:04:21 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 57DA5FB4F3; Tue, 22 Jun 2004 17:04:18 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 224E3FB503; Tue, 22 Jun 2004 17:04:17 -0400 (EDT) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by machshav.com (Postfix) with SMTP id B3ABFFB4F0 for ; Tue, 22 Jun 2004 17:04:16 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 22 Jun 2004 21:04:16 -0000 Message-ID: <01c301c4589c$7a454900$861167c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" , "Jing Xiang" References: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com> <16600.137.619907.633510@fireball.kivinen.iki.fi> Subject: Re: [Mobike] Issue: NAT-T interaction (#3) Date: Tue, 22 Jun 2004 14:04: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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Cc: jari.arkko@piuha.net, MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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, > > Of course the drawback is that we add extra 8 bytes to the data. > > My proposal would be to keep NAT-T and MOBIKE separate and you use one > of them at time. If you are moved inside the NAT, and your policy > allows NAT-T, then you move from MOBIKE to NAT-T. There is no need to > send any address update notifications etc, as the NAT-T have built-in > automatic IP-address change. So, you are saying that when you move behind NAT (the way you detect this is by sending address update with your address behind NAT, RR fails, the peer does not know how to reach you anymore, timeout and then detect NAT), negotiate a new SA (with NAT-T) ? Is that right ? At some point in time, there was a discussion about adding NAT-D payloads in mobike itself. I am not sure whether it was explored or not. If i move behind a NAT and if i can find what the public address that my NAT uses (a priori knowledge or some signalling), then it is possible to include it in mobike address change packets for it to work. There is no 3rd party bombing attack as your RR would succeed if the address used is a proper address or it would fail if the attacker used some random address. This assumes that Mobike exchange is using UDP for it to go through NAT. I agree that this is lot of work and not in scope. But at least wanted to understand what the real reason why we are not going forward with it. Note that if you move out of NAT, mobike still works but you have extra encapsulation for packets always. -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 23 05:03:19 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09293 for ; Wed, 23 Jun 2004 05:03:18 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 01E21FB512; Wed, 23 Jun 2004 05:03:18 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A6F09FB508; Wed, 23 Jun 2004 05:03:17 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2515BFB50F; Wed, 23 Jun 2004 05:03:16 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 7A9D8FB4F0 for ; Wed, 23 Jun 2004 05:03:15 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 26E6489817; Wed, 23 Jun 2004 12:03:12 +0300 (EEST) Message-ID: <40D9463D.7010205@piuha.net> Date: Wed, 23 Jun 2004 11:58:37 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont , Mohan Parthasarathy Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) References: <200406221713.i5MHDRSj029706@givry.rennes.enst-bretagne.fr> In-Reply-To: <200406221713.i5MHDRSj029706@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 Francis Dupont wrote: > In your previous mail you wrote: > > > => you can spread a bit the question: when an implementation supports > > many addresses for the same IPsec SA (cf RFC 3554, end of section 2), > > can the addresses mix IPv4 and IPv6? > > The IKEv2 spec clearly allows this i.e mixing IPv4 and IPv6 traffic > selectors on a single SA. But these are inner addresses. I thought > Jari's question is about outer addresses ? Jari, can you clarify ? > > => I've put the reference to avoid this issue: the question is about > the outer addresses. Yes, it is about the outer addresses. Originally when I sent the e-mail I was thinking about movement from an IPv4 address to an IPv6 address. But of course there's a similar issue with multihoming, as discussed in RFC 3554. As you Francis and Mohan pointed out, supporting multiple outer and inner addresses is already in current specifications. My expectation is that this should also work with MOBIKE, with both movements and multihoming. I propose that we close this issue until we find some evidence that we have a problem to support this :-) --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 23 05:17:07 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10263 for ; Wed, 23 Jun 2004 05:17:07 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 40CA6FB514; Wed, 23 Jun 2004 05:17:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0B405FB50F; Wed, 23 Jun 2004 05:17:07 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 311B4FB510; Wed, 23 Jun 2004 05:17:06 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id B2D55FB508 for ; Wed, 23 Jun 2004 05:17:05 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id AE7B189812; Wed, 23 Jun 2004 12:17:04 +0300 (EEST) Message-ID: <40D9497C.5000402@piuha.net> Date: Wed, 23 Jun 2004 12:12:28 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Mobike] Issue: NAT-T interaction (#3) References: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com> <16600.137.619907.633510@fireball.kivinen.iki.fi> In-Reply-To: <16600.137.619907.633510@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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: > My proposal would be to keep NAT-T and MOBIKE separate and you use one > of them at time. If you are moved inside the NAT, and your policy > allows NAT-T, then you move from MOBIKE to NAT-T. There is no need to > send any address update notifications etc, as the NAT-T have built-in > automatic IP-address change. I agree. But this would still leave some corner cases to worry about, such as having a multihomed scenario with one side having a NAT and the other not. Of course, you can move to NAT-T even on that case, but then you won't be able to let the peer know your two addresses; NAT-T only remembers the latest address. This may have an impact if we want the peer to attempt failover based on a communication problem with the current address. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 23 07:03:48 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA17907 for ; Wed, 23 Jun 2004 07:03:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 16DEBFB514; Wed, 23 Jun 2004 07:03:48 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 61F0FFB50F; Wed, 23 Jun 2004 07:03:47 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BAC50FB510; Wed, 23 Jun 2004 07:03:45 -0400 (EDT) Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by machshav.com (Postfix) with ESMTP id B7087FB4DD for ; Wed, 23 Jun 2004 07:03:44 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5NB3f218774; Wed, 23 Jun 2004 14:03:42 +0300 (EET DST) X-Scanned: Wed, 23 Jun 2004 14:02:31 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5NB2VOt010261; Wed, 23 Jun 2004 14:02:31 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00Z3M6og; Wed, 23 Jun 2004 14:02:29 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5NB2TH23567; Wed, 23 Jun 2004 14:02:29 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Jun 2004 14:02:24 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 23 Jun 2004 14:02:23 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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: NAT-T interaction (#3) Date: Wed, 23 Jun 2004 14:02:23 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C10D@esebe023.ntc.nokia.com> Thread-Topic: [Mobike] Issue: NAT-T interaction (#3) Thread-Index: AcRYPk2g6lNVVpErQDWr1kUKo5c7JQA0G4nA From: To: , X-OriginalArrivalTime: 23 Jun 2004 11:02:23.0759 (UTC) FILETIME=[8FF2D9F0:01C45911] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > > My proposal would be to keep NAT-T and MOBIKE separate and you > use one of them at time. If you are moved inside the NAT, and > your policy allows NAT-T, then you move from MOBIKE to NAT-T. > There is no need to send any address update notifications etc, > as the NAT-T have built-in automatic IP-address change. Here's another way to look at this issue: an implementation=20 that supports NAT-T has some additional information in=20 outbound security associations (conceptually speaking; an implementation could store this information in some other way as well): - UDP encapsulation on/off flag - keepalive sending on/off flag - "automatically update peer address and port" on/off flag - peer port Normally these are set when the SA is created, and never updated=20 after that (except the port).=20 IMHO it does not make much sense to say that NAT-T and MOBIKE=20 should be kept separate, or that you move from MOBIKE to NAT-T. The question should be whether something MOBIKE does can cause=20 this data to be changed after the SA was created, and I think the answer should be "yes" (taking into account e.g. possible=20 restrictions of local policy) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 23 07:11:58 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18645 for ; Wed, 23 Jun 2004 07:11:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D0DFEFB517; Wed, 23 Jun 2004 07:11:57 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 941F0FB510; Wed, 23 Jun 2004 07:11:54 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id C9BEBFB514; Wed, 23 Jun 2004 07:11:52 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 704CCFB4DD for ; Wed, 23 Jun 2004 07:11:50 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i5NBBmYu008739 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 23 Jun 2004 14:11:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i5NBBjI0008736; Wed, 23 Jun 2004 14:11:45 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16601.25969.657208.684816@fireball.kivinen.iki.fi> Date: Wed, 23 Jun 2004 14:11:45 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] Issue: NAT-T interaction (#3) In-Reply-To: <01c301c4589c$7a454900$861167c0@adithya> References: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com> <16600.137.619907.633510@fireball.kivinen.iki.fi> <01c301c4589c$7a454900$861167c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 17 min X-Total-Time: 36 min Cc: jari.arkko@piuha.net, Jing Xiang , MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > Tero, > > > > Of course the drawback is that we add extra 8 bytes to the data. > > > > My proposal would be to keep NAT-T and MOBIKE separate and you use one > > of them at time. If you are moved inside the NAT, and your policy > > allows NAT-T, then you move from MOBIKE to NAT-T. There is no need to > > send any address update notifications etc, as the NAT-T have built-in > > automatic IP-address change. > > So, you are saying that when you move behind NAT (the way you detect > this is by sending address update with your address behind NAT, RR > fails, the peer does not know how to reach you anymore, timeout and > then detect NAT), negotiate a new SA (with NAT-T) ? Is that right ? No. The detection goes so that you send address update to the address you have behind the NAT, and the other end see that the outer IP-address of the address update packet differes from the contents of address update. It will now know that : 1) There is attacker between modifying the packet outer headers 2) There is NAT between. Now, it have two options. Either ignore the address update packet it was modified by the attacker or continue. Next it does return routability check for the address given in the address update packet. If that fails, it will know that it either was malicious client in the other end or there was NAT between. If the RR check successed, it knows it was probably attacker modifying the packet. If the first RR fails, it can try to do RR of the outer IP-address given in the packet (i.e. the adderss of NAT). If that fails, it was again attacker. If it succeeds then it knows it is either attacker along the path towards the outer IP, or there was NAT between. After that it can do policy decision whether to enable NAT-T or not, and if it decides it is allowed, it will send packet to the other end (to the outer IP-address) requesting NAT-T to be enabled. Once the NAT-T is enabled we might keep that enabled for ever, meaning we will not move back from there. One think that needs to be done is to define who how the multihoming features work with NAT-T. This needs some more protocol work, as currently NAT-T only uses one address (the address last seen in the outer IP-header). > At some point in time, there was a discussion about adding NAT-D > payloads in mobike itself. I am not sure whether it was explored or > not. Address update packets are in the sense of NAT-D packets, as they contain the IP-addresses inside. > If i move behind a NAT and if i can find what the public > address that my NAT uses (a priori knowledge or some signalling), > then it is possible to include it in mobike address change packets > for it to work. That would require that our address update packets also include the port numbers for the IKEv2 traffic. Also securely finding out the external IP address of NAT is impossible with the normal NATs out there. > There is no 3rd party bombing attack as your RR > would succeed if the address used is a proper address or it would > fail if the attacker used some random address. This assumes that The attacker can modify the packets source IP (just like NAT), and it can then grab those RR packets from the net (it needs to be along the path towards the 3rd party victim, he is attacking), and forward them to the authenticated user. The user will then reply to those RRs to the attacker, and attacker can then send them back to the server, thus the RR will succeed. Only way to fix that is to include the IP-packets inside the packet authenticated with IKE SA, in which case attacker cannot forward them, but on the other hand that also makes the NAT-T impossible, as it is considered attacker there. > Mobike exchange is using UDP for it to go through NAT. I agree that > this is lot of work and not in scope. But at least wanted to > understand what the real reason why we are not going forward with > it. There is lots of things we still need to think about the NAT-T and MOBIKE, that is the reason it is here as an item. There is no point wasting our time to it, if we then later decide that no, we do not even want it. If we now decide yes, we want it, we might still later change our mind, and say "it is too hard"... > Note that if you move out of NAT, mobike still works but you have > extra encapsulation for packets always. Or, you can simply still use NAT-T. -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 23 07:57:54 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21417 for ; Wed, 23 Jun 2004 07:57:53 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F3598FB51C; Wed, 23 Jun 2004 07:57:53 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id E4D54FB516; Wed, 23 Jun 2004 07:57:51 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 45EFFFB517; Wed, 23 Jun 2004 07:57:50 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 75DD1FB514 for ; Wed, 23 Jun 2004 07:57:49 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 77C6489816; Wed, 23 Jun 2004 14:57:47 +0300 (EEST) Message-ID: <40D96F27.2070800@piuha.net> Date: Wed, 23 Jun 2004 14:53:11 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: MOBIKE Mailing List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Paul Hoffman / VPNC Subject: [Mobike] Issue: When to do return-routability tests (#6) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 This issue is about when to do return routability checks. Note: There are some further protocol details (#12, #15). We can discuss them later, but before that we need to discuss when the checks are needed. Basically, the purpose of the return routability tests in this context is to avoid 3rd party bombing attacks. The scenario is that the attacker claims that he has moved to the victim's location, and the victim then gets the traffic that was destined to the attacker. This can be troublesome particularly if we talk about TCP or other streams. (Note that the attacker can in some cases send faked TCP ACKs or similar to keep the stream going for a while, since they learned the TCP sequence numbers from the initial part of the stream.) There is nothing new in such attacks per se -- attackers can already send a packet to the victim directly or through some reflecting service; there have been known cases where DNS infrastructure, for instance, was used as the reflecting service. However, when we talk our scenario, attackers may gain some amplification for their attack, making it easier to launch a bigger attack with the same fixed amount of resources. The issue also has to do with the relationship of the two peers using IKEv2. When they are part of the same organization, getting a stream of packets from their SGW would lead you to complain to their administration, and the rogue peer would be shut down. OTOH, this can only be done after the fact, and assumes that the two peers really have a relationship. (Such relationships might not exist in the case of opportunistic IPsec, for instance, or if you used Verisign as your trust root. Both Mobile IPv6 and HIP have the assumption of no relationship between the parties.) As Tero pointed out in another e-mail (and Francis has reported earlier), NAT-T has no protection against such issues. Basically, an authentic packet with a new address causes the traffic to be moved to that address without verification. If you are satisfied with this, the UDP encapsulation overhead, and possibly weaker support for failover, you could actually use just NAT-T instead of MOBIKE. Here's some reading material related to the issue: - draft-ietf-mip6-ro-sec-00.txt (Section 3.2) - draft-dupont-mipv6-3bombing-00.txt (all of it) - draft-dupont-transient-pseudonat-03.txt (all of it) - draft-vogt-mipv6-credit-based-authorization-00.txt (Section 3) So, here's some of the options we have: - No tests at all. (Then you might ask whether NAT-T is sufficient.) - Mandatory tests all the time, done before the traffic is moved. Implies one RTT delay. - Mandatory tests all the time, done in parallel with the traffic movement. No delay, but some small amount of amplification may still be possible. This approach is similar to draft-vogt-mip6- early-binding-updates-00.txt, which was later abandoned for another scheme. - Some research-class solution to have no delay and still avoid amplification. See draft-vogt-mip6-credit-based-authorization-00.txt. (But these are complicated schemes and very new technology. Might be against our charter.) - Tests done prior to moving the traffic stream, but allow the tests to be configured off. Also, we need to decide what level of protection the tests should provide. It seems that we have the following options: - None, no tests. - A party willing to answer is on the path to the claimed address. This is the basic form of return routability test. - There is an answer from the tested address, and that answer was authenticated (including the address) to be from our peer. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 23 10:47:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04391 for ; Wed, 23 Jun 2004 10:47:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 2144FFB51F; Wed, 23 Jun 2004 10:47:34 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8A58EFB516; Wed, 23 Jun 2004 10:47:31 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id BFF8DFB518; Wed, 23 Jun 2004 10:47:29 -0400 (EDT) Received: from zcars0m9.nortelnetworks.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by machshav.com (Postfix) with ESMTP id EF71BFB514 for ; Wed, 23 Jun 2004 10:47:28 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5NElFr28803; Wed, 23 Jun 2004 10:47:15 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 23 Jun 2004 10:47:14 -0400 Message-ID: <6204FDDE129D364D8040A98BCCB290EF0E7D4F1A@zbl6c004.corpeast.baynetworks.com> From: "Jing Xiang" To: Pasi.Eronen@nokia.com, kivinen@iki.fi, mobike@machshav.com Subject: RE: [Mobike] Issue: NAT-T interaction (#3) Date: Wed, 23 Jun 2004 10:47:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0387001391==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0387001391== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45930.F7E28E7E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45930.F7E28E7E Content-Type: text/plain; charset="ISO-8859-1" I agree with Pasi's summary here. I think MOBIKE will definitely cause those NAT related SA info to change. Even if we use Address Update as NAT detection, we will probably still have to use the Address Update Ack to signal whether to turn UDP encap on or off, right? /Jing -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Wednesday, June 23, 2004 7:02 AM To: kivinen@iki.fi; mobike@machshav.com Subject: RE: [Mobike] Issue: NAT-T interaction (#3) Tero Kivinen wrote: > > My proposal would be to keep NAT-T and MOBIKE separate and you > use one of them at time. If you are moved inside the NAT, and > your policy allows NAT-T, then you move from MOBIKE to NAT-T. > There is no need to send any address update notifications etc, > as the NAT-T have built-in automatic IP-address change. Here's another way to look at this issue: an implementation that supports NAT-T has some additional information in outbound security associations (conceptually speaking; an implementation could store this information in some other way as well): - UDP encapsulation on/off flag - keepalive sending on/off flag - "automatically update peer address and port" on/off flag - peer port Normally these are set when the SA is created, and never updated after that (except the port). IMHO it does not make much sense to say that NAT-T and MOBIKE should be kept separate, or that you move from MOBIKE to NAT-T. The question should be whether something MOBIKE does can cause this data to be changed after the SA was created, and I think the answer should be "yes" (taking into account e.g. possible restrictions of local policy) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike ------_=_NextPart_001_01C45930.F7E28E7E Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Mobike] Issue: NAT-T interaction (#3)

I agree with Pasi's summary here.
I think MOBIKE will definitely cause those NAT = related SA info to change.
Even if we use Address Update as NAT detection, we = will probably
still have to use the Address Update Ack to signal =
whether to turn UDP encap on or off, right?

/Jing


-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]<= /FONT>
Sent: Wednesday, June 23, 2004 7:02 AM
To: kivinen@iki.fi; mobike@machshav.com
Subject: RE: [Mobike] Issue: NAT-T interaction = (#3)



Tero Kivinen wrote:
>
> My proposal would be to keep NAT-T and MOBIKE = separate and you
> use one of them at time. If you are moved = inside the NAT, and
> your policy allows NAT-T, then you move from = MOBIKE to NAT-T.
> There is no need to send any address update = notifications etc,
> as the NAT-T have built-in automatic IP-address = change.

Here's another way to look at this issue: an = implementation
that supports NAT-T has some additional information = in
outbound security associations (conceptually = speaking; an
implementation could store this information in some = other
way as well):

- UDP encapsulation on/off flag
- keepalive sending on/off flag
- "automatically update peer address and = port" on/off flag
- peer port

Normally these are set when the SA is created, and = never updated
after that (except the port).

IMHO it does not make much sense to say that NAT-T = and MOBIKE
should be kept separate, or that you move from = MOBIKE to NAT-T.
The question should be whether something MOBIKE does = can cause
this data to be changed after the SA was created, = and I think the
answer should be "yes" (taking into = account e.g. possible
restrictions of local policy)

Best regards,
Pasi
_______________________________________________
Mobike mailing list
Mobike@machshav.com
https://www.machshav.com/mailman/listinfo.cgi/mobike

------_=_NextPart_001_01C45930.F7E28E7E-- --===============0387001391== 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 --===============0387001391==-- From mobike-bounces@machshav.com Wed Jun 23 11:13:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06518 for ; Wed, 23 Jun 2004 11:12:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7512AFB51C; Wed, 23 Jun 2004 11:13:00 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 97902FB516; Wed, 23 Jun 2004 11:12:57 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DB1B3FB518; Wed, 23 Jun 2004 11:12:55 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by machshav.com (Postfix) with ESMTP id 18528FB514 for ; Wed, 23 Jun 2004 11:12:55 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5NFCnV01517; Wed, 23 Jun 2004 11:12:49 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MXJCQ6JP; Wed, 23 Jun 2004 11:12:48 -0400 Received: from nortelnetworks.com (atices-1.us.nortel.com [47.16.67.20]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id M0RMXY6G; Wed, 23 Jun 2004 11:12:49 -0400 Message-ID: <40D99DF0.9020209@nortelnetworks.com> Date: Wed, 23 Jun 2004 11:12:48 -0400 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Dondeti, Lakshminath" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: When to do return-routability tests (#6) References: <40D96F27.2070800@piuha.net> In-Reply-To: <40D96F27.2070800@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 see inline: Jari Arkko wrote: > > This issue is about when to do return routability checks. > Note: There are some further protocol details (#12, #15). > We can discuss them later, but before that we need to > discuss when the checks are needed. > > Basically, the purpose of the return routability tests > in this context is to avoid 3rd party bombing attacks. The > scenario is that the attacker claims that he has moved to > the victim's location, and the victim then gets the traffic > that was destined to the attacker. This can be troublesome > particularly if we talk about TCP or other streams. (Note > that the attacker can in some cases send faked TCP ACKs or > similar to keep the stream going for a while, since they > learned the TCP sequence numbers from the initial part of > the stream.) > > There is nothing new in such attacks per se -- attackers can > already send a packet to the victim directly or through some > reflecting service; there have been known cases where DNS > infrastructure, for instance, was used as the reflecting > service. However, when we talk our scenario, attackers may > gain some amplification for their attack, making it easier > to launch a bigger attack with the same fixed amount of > resources. > > The issue also has to do with the relationship of the > two peers using IKEv2. When they are part of the same > organization, getting a stream of packets from their > SGW would lead you to complain to their administration, > and the rogue peer would be shut down. OTOH, this can only > be done after the fact, and assumes that the two peers > really have a relationship. (Such relationships might not > exist in the case of opportunistic IPsec, for instance, > or if you used Verisign as your trust root. Both Mobile > IPv6 and HIP have the assumption of no relationship > between the parties.) > > As Tero pointed out in another e-mail (and Francis has > reported earlier), NAT-T has no protection against such > issues. Basically, an authentic packet with a new > address causes the traffic to be moved to that address > without verification. If you are satisfied with this, > the UDP encapsulation overhead, and possibly weaker support > for failover, you could actually use just NAT-T instead of > MOBIKE. > > Here's some reading material related to the issue: > > - draft-ietf-mip6-ro-sec-00.txt (Section 3.2) > - draft-dupont-mipv6-3bombing-00.txt (all of it) > - draft-dupont-transient-pseudonat-03.txt (all of it) > - draft-vogt-mipv6-credit-based-authorization-00.txt (Section 3) > > So, here's some of the options we have: > > - No tests at all. (Then you might ask whether NAT-T is > sufficient.) Not necessarily, MOBIKE still would have more functionality than NAT-T. > > - Mandatory tests all the time, done before the traffic is moved. > Implies one RTT delay. > > - Mandatory tests all the time, done in parallel with the traffic > movement. No delay, but some small amount of amplification may > still be possible. This approach is similar to draft-vogt-mip6- > early-binding-updates-00.txt, which was later abandoned for > another scheme. > > - Some research-class solution to have no delay and still > avoid amplification. See > draft-vogt-mip6-credit-based-authorization-00.txt. > (But these are complicated schemes and very new technology. > Might be against our charter.) After a quick scan, I got the impression that perhaps this or similar schemes can be implemented by the server. > > - Tests done prior to moving the traffic stream, but allow > the tests to be configured off. I think this is best, i.e., RR should be an option, that can be turned on either on a GW level or on a per IPsec association (based on the type of authentication of the client, say in RA scenarios). > > Also, we need to decide what level of protection the tests > should provide. It seems that we have the following options: > > - None, no tests. > > - A party willing to answer is on the path to the claimed > address. This is the basic form of return routability > test. > > - There is an answer from the tested address, and that > answer was authenticated (including the address) to be > from our peer. We were considering another option (in early May): That an empty informational exchange for RR verification might not work and that we should introduce a nonce for liveness of the test. I still like that option. regards, Lakshminath > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike > _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 23 13:06:32 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13764 for ; Wed, 23 Jun 2004 13:06:32 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A2A16FB516; Wed, 23 Jun 2004 13:06:31 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7EFA6FB518; Wed, 23 Jun 2004 13:06:28 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E779FFB51B; Wed, 23 Jun 2004 13:06:26 -0400 (EDT) Received: from smtp802.mail.sc5.yahoo.com (smtp802.mail.sc5.yahoo.com [66.163.168.181]) by machshav.com (Postfix) with SMTP id 12770FB516 for ; Wed, 23 Jun 2004 13:06:26 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp802.mail.sc5.yahoo.com with SMTP; 23 Jun 2004 17:06:25 -0000 Message-ID: <006201c45944$6c425070$861167c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com><16600.137.619907.633510@fireball.kivinen.iki.fi><01c301c4589c$7a454900$861167c0@adithya> <16601.25969.657208.684816@fireball.kivinen.iki.fi> Subject: Re: [Mobike] Issue: NAT-T interaction (#3) Date: Wed, 23 Jun 2004 10:06:27 -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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Cc: MOBIKE Mailing List , Jing Xiang , jari.arkko@piuha.net, Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 > > > > Of course the drawback is that we add extra 8 bytes to the data. > > > > > > My proposal would be to keep NAT-T and MOBIKE separate and you use one > > > of them at time. If you are moved inside the NAT, and your policy > > > allows NAT-T, then you move from MOBIKE to NAT-T. There is no need to > > > send any address update notifications etc, as the NAT-T have built-in > > > automatic IP-address change. > > > > So, you are saying that when you move behind NAT (the way you detect > > this is by sending address update with your address behind NAT, RR > > fails, the peer does not know how to reach you anymore, timeout and > > then detect NAT), negotiate a new SA (with NAT-T) ? Is that right ? > > No. > I should not have asked two questions in the same place. I am not sure to which you said "No" :-) I guess you were refering to the process to detect that you are behind NAT.. > The detection goes so that you send address update to the address you > have behind the NAT, and the other end see that the outer IP-address > of the address update packet differes from the contents of address > update. It will now know that : > > 1) There is attacker between modifying the packet outer > headers > 2) There is NAT between. > > Now, it have two options. Either ignore the address update packet it > was modified by the attacker or continue. > > Next it does return routability check for the address given in the > address update packet. If that fails, it will know that it either was > malicious client in the other end or there was NAT between. > > If the RR check successed, it knows it was probably attacker > modifying the packet. > Ah! I missed this part. > If the first RR fails, it can try to do RR of the outer IP-address > given in the packet (i.e. the adderss of NAT). If that fails, it was > again attacker. If it succeeds then it knows it is either attacker > along the path towards the outer IP, or there was NAT between. > > After that it can do policy decision whether to enable NAT-T or not, > and if it decides it is allowed, it will send packet to the other end > (to the outer IP-address) requesting NAT-T to be enabled. Once the > NAT-T is enabled we might keep that enabled for ever, meaning we will > not move back from there. > > One think that needs to be done is to define who how the multihoming > features work with NAT-T. This needs some more protocol work, as > currently NAT-T only uses one address (the address last seen in the > outer IP-header). > Ok. > > At some point in time, there was a discussion about adding NAT-D > > payloads in mobike itself. I am not sure whether it was explored or > > not. > > Address update packets are in the sense of NAT-D packets, as they > contain the IP-addresses inside. > > > If i move behind a NAT and if i can find what the public > > address that my NAT uses (a priori knowledge or some signalling), > > then it is possible to include it in mobike address change packets > > for it to work. > > That would require that our address update packets also include the > port numbers for the IKEv2 traffic. Also securely finding out the > external IP address of NAT is impossible with the normal NATs out > there. > I at least know the external IP address of my NAT at home :-) It seems to be reasonably stable. Assume i am reading my company email on the way home (connected to my company through the IPsec tunnel) and i get into my house where there is a NAT, but still would like to read my email without disruption/packet-loss :-) > > There is no 3rd party bombing attack as your RR > > would succeed if the address used is a proper address or it would > > fail if the attacker used some random address. This assumes that > > The attacker can modify the packets source IP (just like NAT), and it > can then grab those RR packets from the net (it needs to be along the If the attacker modifies the source address on the address-update packet before it reaches the other end, then the peer will detect that the source IP does not match the address (the public address of NAT) contained in the payload (which is protected) and hence can decide either to drop the packet or do RR on the address contained in the payload. So, i am missing something.. > path towards the 3rd party victim, he is attacking), and forward them > to the authenticated user. The user will then reply to those RRs to > the attacker, and attacker can then send them back to the server, thus > the RR will succeed. Only way to fix that is to include the IP-packets > inside the packet authenticated with IKE SA, in which case attacker > cannot forward them, but on the other hand that also makes the NAT-T > impossible, as it is considered attacker there. > > > Mobike exchange is using UDP for it to go through NAT. I agree that > > this is lot of work and not in scope. But at least wanted to > > understand what the real reason why we are not going forward with > > it. > > There is lots of things we still need to think about the NAT-T and > MOBIKE, that is the reason it is here as an item. There is no point > wasting our time to it, if we then later decide that no, we do not > even want it. If we now decide yes, we want it, we might still later > change our mind, and say "it is too hard"... > I agree that there are some hard issues to think about. If we can at least discuss all the issues, we can avoid the same question repeated again by someone or me again in the future :-) > > Note that if you move out of NAT, mobike still works but you have > > extra encapsulation for packets always. > > Or, you can simply still use NAT-T. Yes. -mohan > -- > kivinen@safenet-inc.com > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 03:15:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09551 for ; Thu, 24 Jun 2004 03:15:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 7DD40FB4F0; Thu, 24 Jun 2004 03:15:37 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 77929FB4F5; Thu, 24 Jun 2004 03:15:36 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 3CA3BFB4F6; Thu, 24 Jun 2004 03:15:35 -0400 (EDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by machshav.com (Postfix) with ESMTP id 8C497FB4F0 for ; Thu, 24 Jun 2004 03:15:34 -0400 (EDT) Received: from piuha.net (p2.piuha.net [131.160.192.2]) by p2.piuha.net (Postfix) with ESMTP id 4334689845; Thu, 24 Jun 2004 10:15:32 +0300 (EEST) Message-ID: <40DA7E7F.9070601@piuha.net> Date: Thu, 24 Jun 2004 10:10:55 +0300 From: Jari Arkko Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dondeti, Lakshminath" Subject: Re: [Mobike] Issue: When to do return-routability tests (#6) References: <40D96F27.2070800@piuha.net> <40D99DF0.9020209@nortelnetworks.com> In-Reply-To: <40D99DF0.9020209@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list Reply-To: jari.arkko@piuha.net 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 Thanks for your comments! One follow-up below: >> Also, we need to decide what level of protection the tests >> should provide. It seems that we have the following options: >> >> - None, no tests. >> >> - A party willing to answer is on the path to the claimed >> address. This is the basic form of return routability >> test. >> >> - There is an answer from the tested address, and that >> answer was authenticated (including the address) to be >> from our peer. > > > We were considering another option (in early May): That an empty > informational exchange for RR verification might not work and that we > should introduce a nonce for liveness of the test. I still like that > option. Yes. This is a related issue, but partly different too. I agree that empty informational exchanges are not sufficient for an RR test, and a nonce is needed. Basically, an empty informational exchange just proves that the answer came from the peer, but not that it came from the address we wanted to test. I guess you could amend my list above as follows; - None, no tests. - A party willing to answer is on the path to the claimed address. This is the basic form of return routability test. - There is an answer from the tested address, and that answer was authenticated (including the address) to be from our peer. - There was an authenticated answer from the peer, but it is not guaranteed to be from the tested address or path to it (because the peer can construct a response without seeing the request). The last option corresponds to making an empty informational exchange. I think the first and the last options are not practical options; its either the second or the third option that we should adopt. --Jari _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 07:14:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26129 for ; Thu, 24 Jun 2004 07:14:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id AAEFBFB500; Thu, 24 Jun 2004 07:14:23 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C1362FB4E0; Thu, 24 Jun 2004 07:14:20 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DC627FB4F0; Thu, 24 Jun 2004 07:14:18 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 2F8C7FB4DD for ; Thu, 24 Jun 2004 07:14:17 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i5OBEEYu024430 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 24 Jun 2004 14:14:14 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i5OBE688024427; Thu, 24 Jun 2004 14:14:06 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16602.46974.407205.338462@fireball.kivinen.iki.fi> Date: Thu, 24 Jun 2004 14:14:06 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Mobike] Issue: NAT-T interaction (#3) In-Reply-To: <006201c45944$6c425070$861167c0@adithya> References: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com> <16600.137.619907.633510@fireball.kivinen.iki.fi> <01c301c4589c$7a454900$861167c0@adithya> <16601.25969.657208.684816@fireball.kivinen.iki.fi> <006201c45944$6c425070$861167c0@adithya> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 4 min Cc: jari.arkko@piuha.net, Jing Xiang , MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > I should not have asked two questions in the same place. > I am not sure to which you said "No" :-) I guess you were > refering to the process to detect that you are behind NAT.. My answer was mostly saying that there are all kind of options. > > The detection goes so that you send address update to the address you > > have behind the NAT, and the other end see that the outer IP-address > > of the address update packet differes from the contents of address > > update. It will now know that : > > > > 1) There is attacker between modifying the packet outer > > headers > > 2) There is NAT between. > > > > Now, it have two options. Either ignore the address update packet it > > was modified by the attacker or continue. > > > > Next it does return routability check for the address given in the > > address update packet. If that fails, it will know that it either was > > malicious client in the other end or there was NAT between. > > > > If the RR check successed, it knows it was probably attacker > > modifying the packet. > > > Ah! I missed this part. This wasn't really explained anywhere, I was just thinking the things at the same tiem I wrote the message. > > That would require that our address update packets also include the > > port numbers for the IKEv2 traffic. Also securely finding out the > > external IP address of NAT is impossible with the normal NATs out > > there. > > > I at least know the external IP address of my NAT at home :-) It seems > to be reasonably stable. Assume i am reading my company email on the way > home (connected to my company through the IPsec tunnel) and i get into my > house where there is a NAT, but still would like to read my email without > disruption/packet-loss :-) True. I have similar setup in my home, and the NAT is actually configured to be static for my laptop (it will always get the same external IP, only allocated for it). Perhaps we need to think whether the protocol should take account those things too... > > > There is no 3rd party bombing attack as your RR > > > would succeed if the address used is a proper address or it would > > > fail if the attacker used some random address. This assumes that > > > > The attacker can modify the packets source IP (just like NAT), and it > > can then grab those RR packets from the net (it needs to be along the > > If the attacker modifies the source address on the address-update > packet before it reaches the other end, then the peer will detect > that the source IP does not match the address (the public address of > NAT) contained in the payload (which is protected) and hence can > decide either to drop the packet or do RR on the address contained > in the payload. So, i am missing something.. The data in the payload is the address behind the NAT, not the exteran address of the NAT, thus attacker and NAT look identical. In both cases the outer IP address and the address inside does not match. There is no way to know wheter it was attacker who modified the packet or whether it was NAT (which actually is an attacker who modifies the packets :-) -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 10:01:55 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13346 for ; Thu, 24 Jun 2004 10:01:54 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id A970DFB4F6; Thu, 24 Jun 2004 10:01:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 7E909FB4DE; Thu, 24 Jun 2004 10:01:54 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 86E13FB4E0; Thu, 24 Jun 2004 10:01:52 -0400 (EDT) Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by machshav.com (Postfix) with ESMTP id 75798FB4DD for ; Thu, 24 Jun 2004 10:01:51 -0400 (EDT) Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5OE1n605444 for ; Thu, 24 Jun 2004 17:01:49 +0300 (EET DST) X-Scanned: Thu, 24 Jun 2004 17:01:20 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i5OE1Kiq016307 for ; Thu, 24 Jun 2004 17:01:20 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks001.ntc.nokia.com 00U9kBfC; Thu, 24 Jun 2004 17:01:19 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5OE1EH19529 for ; Thu, 24 Jun 2004 17:01:14 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 24 Jun 2004 17:01:13 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 24 Jun 2004 17:01:13 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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: When to do return-routability tests (#6) Date: Thu, 24 Jun 2004 17:01:13 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C113@esebe023.ntc.nokia.com> Thread-Topic: [Mobike] Issue: When to do return-routability tests (#6) Thread-Index: AcRZu5DhYqTaXPdRT+y9ZtVf/Zau4wANvYtw From: To: X-OriginalArrivalTime: 24 Jun 2004 14:01:13.0724 (UTC) FILETIME=[B5EB53C0:01C459F3] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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:=20 > > This is a related issue, but partly different too. I agree that > empty informational exchanges are not sufficient for an RR > test, and a nonce is needed. Basically, an empty informational > exchange just proves that the answer came from the peer, but > not that it came from the address we wanted to test. I guess > you could amend my list above as follows; >=20 > - None, no tests. >=20 > - A party willing to answer is on the path to the claimed > address. This is the basic form of return routability > test. >=20 > - There is an answer from the tested address, and that > answer was authenticated (including the address) to be > from our peer. >=20 > - There was an authenticated answer from the peer, but > it is not guaranteed to be from the tested address > or path to it (because the peer can construct a > response without seeing the request). >=20 > The last option corresponds to making an empty informational > exchange. I think the first and the last options are not > practical options; its either the second or the third > option that we should adopt. I my opinion, "Return routability" usually means the second one: we verify that we have a route back to the party who made the=20 request. This is also what normal IKEv2 provides (either statelessly using COOKIE payload, or with state and Ni/Nr). Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 11:50:39 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22757 for ; Thu, 24 Jun 2004 11:50:38 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id E7595FB4F9; Thu, 24 Jun 2004 11:50:36 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9EE9FFB4E0; Thu, 24 Jun 2004 11:50:35 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 14DF6FB4E2; Thu, 24 Jun 2004 11:50:34 -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 F121AFB4DE for ; Thu, 24 Jun 2004 11:50:32 -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 i5OFnuq32372; Thu, 24 Jun 2004 17:49:56 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OFnsSj039251; Thu, 24 Jun 2004 17:49:55 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241549.i5OFnsSj039251@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] MOBIKE work In-reply-to: Your message of Mon, 21 Jun 2004 18:04:52 +0300. <40D6F914.1030205@piuha.net> Date: Thu, 24 Jun 2004 17:49:54 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: We have grouped the issues as follows: => I like the requirement/mechanism/policy grouping but... User-level visible "requirement" issues: ======================================== - How much protection against 3rd party bombing should MOBIKE offer? => this is a policy issue with another suit, or do you refer to what I call the "transient pseudo-NAT attack"? Other issues which clearly need a lot of work: ============================================== - Explicit vs. implicit address changes. => in fact this is more a charter issue (:-)! Smaller issues that might be easy to decide: ============================================ - Signaling support for MOBIKE. => are signaling and mechanism the same thing. I don't understand the question for sure. - Are empty informational exchanges sufficient for return routability test, or is a cookie needed? => this question has no meaning (i.e., the answer is trivial) in the IKEv2 context. - Is a set of zero addresses allowed? => interesting question but not a "small issue" at all! - Move all SAs at once, or allow individual movements? => not small too, IMHO this is the main difference between my and Tero's proposal. - Window size issues. => can you explain? IKEv2 is a sequenced protected exchange protocol. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 12:02:36 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23698 for ; Thu, 24 Jun 2004 12:02:35 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D14F4FB4FB; Thu, 24 Jun 2004 12:02:36 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 86DEEFB4E2; Thu, 24 Jun 2004 12:02:35 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 94EBAFB4F5; Thu, 24 Jun 2004 12:02:34 -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 737AFFB4DE for ; Thu, 24 Jun 2004 12:02:33 -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 i5OG2OY02235; Thu, 24 Jun 2004 18:02:24 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OG2OSj039308; Thu, 24 Jun 2004 18:02:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241602.i5OG2OSj039308@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) In-reply-to: Your message of Wed, 23 Jun 2004 11:58:37 +0300. <40D9463D.7010205@piuha.net> Date: Thu, 24 Jun 2004 18:02:24 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: Mohan Parthasarathy , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: Yes, it is about the outer addresses. Originally when I sent the e-mail I was thinking about movement from an IPv4 address to an IPv6 address. But of course there's a similar issue with multihoming, as discussed in RFC 3554. As you Francis and Mohan pointed out, supporting multiple outer and inner addresses is already in current specifications. => but there is a real difference: - it is expected that multiple inner addresses will be supported by nearly every implementations (the only way to avoid the support is to require only single traffic selector pairs but this is like to reject not initial exchanges: legal but only for dumb implementations). - multiple outer addresses for IPsec SAs are very complex to implement. BTW, does someone know a complete implementation of RFC 3554? My expectation is that this should also work with MOBIKE, with both movements and multihoming. I propose that we close this issue until we find some evidence that we have a problem to support this :-) => I believe that there is a real problem but the problem is partially outside the scope of MOBIKE. I propose to *not* require the support of multiple simultaneous outer addresses for IPsec SA without a strong support from the IPsec WG (as something specific in the 2401bis for instance). Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 12:20:38 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24907 for ; Thu, 24 Jun 2004 12:20:37 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3D9B7FB50D; Thu, 24 Jun 2004 12:20:39 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D9A03FB4E2; Thu, 24 Jun 2004 12:20:36 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 31740FB4F5; Thu, 24 Jun 2004 12:20:35 -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 0C3AEFB4DE for ; Thu, 24 Jun 2004 12:20:34 -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 i5OGKKY03489; Thu, 24 Jun 2004 18:20:20 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OGKKSj039369; Thu, 24 Jun 2004 18:20:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241620.i5OGKKSj039369@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: NAT-T interaction (#3) In-reply-to: Your message of Mon, 21 Jun 2004 18:20:16 +0300. <40D6FCB0.9060908@piuha.net> Date: Thu, 24 Jun 2004 18:20:20 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: This is about the interaction with NAT traversal: does the MOBIKE protocol work one one party goes behind NAT, comes from behind NAT, or goes from one NAT to another? => please note there is far more than one question in this statement! The first one is "one party goes behind NAT": IMHO this is more an IKEv2 question and the IPsec WG already decided to not support directly this case, i.e., the IKE SA is broken and everything restart from the beginning. MOBIKE is like IKEv2: peer address "floating" is accepted only from a peer known to be behind a NAT, so there is no detection issue and we can go to the last case. The last one is "one party goes from one NAT to another": IMHO we should not try to handle this case and leave it to NAT-T itself. The real question is whether is one party using NAT-T (and behind a NAT) with the other party using MOBIKE a real world case? Without a concrete example of such a situation I propose to not require the support of this case. The second one is "one party comes from behind NAT": IMHO this is more a NAT-T issue and the real question is the opposite of the first one: NAT-T to no-NAT-T transition. The simplest answer is just to keep the NAT-T mode but there is a bidding down attack on this (bidding down because NAT-T has a larger overhead and provides less security than "plain" IPsec). My proposal is to accept this possible attack but to require a per peer configuration switch which enables or disables NAT-T (note this is a different switch than NAT-T support itself. for instance NAT detection can (should!) be performed even when the switch is on "disabled"). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 12:31:49 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26698 for ; Thu, 24 Jun 2004 12:31:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 6C708FB500; Thu, 24 Jun 2004 12:31:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 07FD6FB4E2; Thu, 24 Jun 2004 12:31:49 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id F278FFB4F5; Thu, 24 Jun 2004 12:31:47 -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 E2C65FB4DE for ; Thu, 24 Jun 2004 12:31:46 -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 i5OGVYY04586; Thu, 24 Jun 2004 18:31:34 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OGVZSj039432; Thu, 24 Jun 2004 18:31:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241631.i5OGVZSj039432@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Jing Xiang" Subject: Re: [Mobike] Issue: NAT-T interaction (#3) In-reply-to: Your message of Mon, 21 Jun 2004 12:55:03 EDT. <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com> Date: Thu, 24 Jun 2004 18:31:35 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , jari.arkko@piuha.net, Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: Rather than testing NAT existance after each address change => in fact in IKEv2 NAT existence is checked only in the initial exchange and can be forced by putting junked NAT-D stuff. I would recommend us consider forcing UDP wrapper on for all mobile cases. => IMHO this is not a stupid option when there is likely a NAT on the path. But as a counterpart one should have a switch to disable NAT-T. Of course the drawback is that we add extra 8 bytes to the data. => NAT-T is also less secure (as Tero explained...) Regards Francis.Dupont@enst-bretagne.fr PS: one extra issue is the support of NAT-T when both peers are behind a NAT. IMHO there is nothing in the protocol against this. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 12:48:09 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28121 for ; Thu, 24 Jun 2004 12:48:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 1AE90FB4E2; Thu, 24 Jun 2004 12:48:10 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 309F0FB4E2; Thu, 24 Jun 2004 12:48:08 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DD128FB4F5; Thu, 24 Jun 2004 12:48:06 -0400 (EDT) Received: from smtp808.mail.sc5.yahoo.com (smtp808.mail.sc5.yahoo.com [66.163.168.187]) by machshav.com (Postfix) with SMTP id 65EC2FB4DE for ; Thu, 24 Jun 2004 12:48:06 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp808.mail.sc5.yahoo.com with SMTP; 24 Jun 2004 16:48:01 -0000 Message-ID: <003801c45a0b$052ad610$861167c0@adithya> From: "Mohan Parthasarathy" To: "Tero Kivinen" References: <6204FDDE129D364D8040A98BCCB290EF0E70B10D@zbl6c004.corpeast.baynetworks.com><16600.137.619907.633510@fireball.kivinen.iki.fi><01c301c4589c$7a454900$861167c0@adithya><16601.25969.657208.684816@fireball.kivinen.iki.fi><006201c45944$6c425070$861167c0@adithya> <16602.46974.407205.338462@fireball.kivinen.iki.fi> Subject: Re: [Mobike] Issue: NAT-T interaction (#3) Date: Thu, 24 Jun 2004 09:48: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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Cc: jari.arkko@piuha.net, Jing Xiang , MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 > > > > That would require that our address update packets also include the > > > port numbers for the IKEv2 traffic. Also securely finding out the > > > external IP address of NAT is impossible with the normal NATs out > > > there. > > > > > I at least know the external IP address of my NAT at home :-) It seems > > to be reasonably stable. Assume i am reading my company email on the way > > home (connected to my company through the IPsec tunnel) and i get into my > > house where there is a NAT, but still would like to read my email without > > disruption/packet-loss :-) > > True. I have similar setup in my home, and the NAT is actually > configured to be static for my laptop (it will always get the same > external IP, only allocated for it). Perhaps we need to think whether > the protocol should take account those things too... > > > > > There is no 3rd party bombing attack as your RR > > > > would succeed if the address used is a proper address or it would > > > > fail if the attacker used some random address. This assumes that > > > > > > The attacker can modify the packets source IP (just like NAT), and it > > > can then grab those RR packets from the net (it needs to be along the > > > > If the attacker modifies the source address on the address-update > > packet before it reaches the other end, then the peer will detect > > that the source IP does not match the address (the public address of > > NAT) contained in the payload (which is protected) and hence can > > decide either to drop the packet or do RR on the address contained > > in the payload. So, i am missing something.. > > The data in the payload is the address behind the NAT, not the exteran > address of the NAT, thus attacker and NAT look identical. In both As i mentioned in my first mail, i assume that i can learn the public IP address of my NAT (which is possible in my home case) and i include that in the MOBIKE address exchange packet. Yes, it involves more work in terms of getting the address in most of the cases. Assume i get the public address of my NAT, wouldn't this work ? > cases the outer IP address and the address inside does not match. > There is no way to know wheter it was attacker who modified the packet > or whether it was NAT (which actually is an attacker who modifies the > packets :-) > -- > kivinen@safenet-inc.com -mohan _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 12:51:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28486 for ; Thu, 24 Jun 2004 12:51:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 55208FB4E2; Thu, 24 Jun 2004 12:51:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 46030FB4E2; Thu, 24 Jun 2004 12:51:15 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 00E1AFB4F5; Thu, 24 Jun 2004 12:51:13 -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 C684BFB4DE for ; Thu, 24 Jun 2004 12:51:12 -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 i5OGofY07180; Thu, 24 Jun 2004 18:50:41 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OGoeSj039500; Thu, 24 Jun 2004 18:50:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241650.i5OGoeSj039500@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Tero Kivinen Subject: Re: [Mobike] Issue: NAT-T interaction (#3) In-reply-to: Your message of Tue, 22 Jun 2004 12:48:57 +0300. <16600.137.619907.633510@fireball.kivinen.iki.fi> Date: Thu, 24 Jun 2004 18:50:40 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: jari.arkko@piuha.net, Jing Xiang , MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: The problem is that NAT-T does allow 3rd party bombing, and there is no way to prevent it, because we cannot authenticate the IP-address. => this is the transient pseudo-NAT attack (cf. my I-D about this problem in MIPv4 and IKE). NAT-T mitigates it by its keep-alive mechanism: when the attacker goes outside the path (cf. the "transient" key word) the peer not behind a NAT will receive a packet with the right source address and stop the spurious redirect. Actually there is several different levels of 3rd party bombing. The first is one which can be done from anywhere from the net, simply by sending few faked packets. This can be prevented by return routability checks, i.e we verify that sender of the update packet can see packets destioned to the IP-address he gave. => this attack doesn't work with NAT-T IPsec (but the next one does). The next level is where the attacker is along the path to the party to be bombed. In this case return routability checks will not prevent the attack, as the attacker can reply to those checks, or forward them to the correct node, which will then answer to them. => in fact the attacker must be along the path between the two parties too because IPsec packets are protected (unfortunately not their headers, and of course one has again the choice between either header protection or NAT traversal). This attack works well without any direct defense... Only way to prevent 3rd party bombing is to require the other party authenticating the IP-address change, meaning it needs to know the IP-address seen by the other end and put it inside the payload. In this case the NAT is considered as an attacker along the path (it modified the packets), thus the checks will fail, and the address update is not done. => this is my "either NAT-T or security" argument with other words. So if we want to have full protection from 3rd party bombing (also those attackers who are along the path), we cannot use NAT-T. If we do not care about the 3rd party bombing, we can use NAT-T all the time. => please note that the 3rd party bombing can (and should!) be easily mitigated in this case (IPsec NAT traversal). > Of course the drawback is that we add extra 8 bytes to the data. My proposal would be to keep NAT-T and MOBIKE separate and you use one of them at time. => I fully agree! If you are moved inside the NAT, and your policy allows NAT-T, then you move from MOBIKE to NAT-T. There is no need to send any address update notifications etc, as the NAT-T have built-in automatic IP-address change. => same! BTW we have here both a MOBIKE justification and the answer to the implicit/explicit issue: - NAT-T must be implicit (there is no choice) - MOBIKE must be explicit (there is a choice but explicit is strictly better). Perhaps we should keep these messages for a MOBIKE vs NAT-T document? Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 12:54:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28840 for ; Thu, 24 Jun 2004 12:54:16 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3AA2AFB4E2; Thu, 24 Jun 2004 12:54:17 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B7691FB4E2; Thu, 24 Jun 2004 12:54:15 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D35D8FB4F5; Thu, 24 Jun 2004 12:54:14 -0400 (EDT) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by machshav.com (Postfix) with SMTP id 30CDDFB4DE for ; Thu, 24 Jun 2004 12:54:14 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 24 Jun 2004 16:52:31 -0000 Message-ID: <004201c45a0b$a5c6b620$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , References: <200406241602.i5OG2OSj039308@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) Date: Thu, 24 Jun 2004 09:52:34 -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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 > In your previous mail you wrote: > > Yes, it is about the outer addresses. > > Originally when I sent the e-mail I was thinking about movement > from an IPv4 address to an IPv6 address. But of course there's > a similar issue with multihoming, as discussed in RFC 3554. > > As you Francis and Mohan pointed out, supporting multiple > outer and inner addresses is already in current specifications. > > => but there is a real difference: > - it is expected that multiple inner addresses will be supported > by nearly every implementations (the only way to avoid the support > is to require only single traffic selector pairs but this is like > to reject not initial exchanges: legal but only for dumb > implementations). > - multiple outer addresses for IPsec SAs are very complex to > implement. BTW, does someone know a complete implementation > of RFC 3554? > > My expectation is that this should also work with MOBIKE, with > both movements and multihoming. I propose that we close this > issue until we find some evidence that we have a problem to > support this :-) > > => I believe that there is a real problem but the problem is partially > outside the scope of MOBIKE. I propose to *not* require the support > of multiple simultaneous outer addresses for IPsec SA without a strong > support from the IPsec WG (as something specific in the 2401bis for > instance). > I miss something here. I thought RFC 3554 has the support of the IPsec WG. All we are saying that this address set can change. And changing addresses is the core of MOBIKE. -mohan > Thanks > > Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 12:58:49 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29286 for ; Thu, 24 Jun 2004 12:58:49 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 85E8DFB500; Thu, 24 Jun 2004 12:58:50 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C96FBFB4E2; Thu, 24 Jun 2004 12:58:48 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 148C7FB4F0; Thu, 24 Jun 2004 12:58:47 -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 EC791FB4DE for ; Thu, 24 Jun 2004 12:58:45 -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 i5OGwNY08569; Thu, 24 Jun 2004 18:58:23 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OGwNSj039556; Thu, 24 Jun 2004 18:58:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241658.i5OGwNSj039556@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] Issue: NAT-T interaction (#3) In-reply-to: Your message of Tue, 22 Jun 2004 14:04:15 PDT. <01c301c4589c$7a454900$861167c0@adithya> Date: Thu, 24 Jun 2004 18:58:23 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Jing Xiang , jari.arkko@piuha.net, Paul Hoffman / VPNC , Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: So, you are saying that when you move behind NAT (the way you detect this is by sending address update with your address behind NAT, RR fails, the peer does not know how to reach you anymore, timeout and then detect NAT), negotiate a new SA (with NAT-T) ? Is that right ? => your scenario is wrong: when you move behind NAT your peer detect this at the first IKE packet it receives from you and even knows how to reach you. Then it will close the IKE SA and let you restart from the beginning with hopefully NAT detection and NAT-T support. At some point in time, there was a discussion about adding NAT-D payloads in mobike itself. => MOBIKE needs something similar and more which can provide as a side effect NAT detection. But NAT-D itself is not necessary in MOBIKE and the IPsec WG decided to forbid direct no-NAT-T to NAT-T transition. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 13:06:24 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29977 for ; Thu, 24 Jun 2004 13:06:23 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 61C55FB4F5; Thu, 24 Jun 2004 13:06:26 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 38A20FB4E2; Thu, 24 Jun 2004 13:06:23 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 360E3FB4F0; Thu, 24 Jun 2004 13:06:22 -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 1CD7BFB4DE for ; Thu, 24 Jun 2004 13:06:21 -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 i5OH66Y09418; Thu, 24 Jun 2004 19:06:06 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OH66Sj039592; Thu, 24 Jun 2004 19:06:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241706.i5OH66Sj039592@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: NAT-T interaction (#3) In-reply-to: Your message of Wed, 23 Jun 2004 12:12:28 +0300. <40D9497C.5000402@piuha.net> Date: Thu, 24 Jun 2004 19:06:06 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman / VPNC , Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: I agree. But this would still leave some corner cases to worry about, such as having a multihomed scenario with one side having a NAT and the other not. Of course, you can move to NAT-T even on that case, but then you won't be able to let the peer know your two addresses; NAT-T only remembers the latest address. This may have an impact if we want the peer to attempt failover based on a communication problem with the current address. => this is somthing that MOBIKE can't solve by itself because of the way NATs "work". My proposal is to send an informational message to the peer behind the NAT with the extra other peer addresses, so it will be able to open parallel IKE and IPsec SAs using these addresses. Regards Francis.Dupont@enst-bretagne.fr PS: the issue is the NAT cannot know all the addresses belong to the same node and may use different mapping for the peer behind it (and will use if there is more than IPsec node behind it). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 13:19:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01521 for ; Thu, 24 Jun 2004 13:19:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id D65B0FB50E; Thu, 24 Jun 2004 13:19:16 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id BD913FB4E2; Thu, 24 Jun 2004 13:19:15 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id DB2EAFB4F0; Thu, 24 Jun 2004 13:19:14 -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 A8E5AFB4DE for ; Thu, 24 Jun 2004 13:19:13 -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 i5OHJ1Y10811; Thu, 24 Jun 2004 19:19:01 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OHJ1Sj039714; Thu, 24 Jun 2004 19:19:01 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241719.i5OHJ1Sj039714@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Simultaneous movements (#2) In-reply-to: Your message of Mon, 21 Jun 2004 21:42:19 +0300. <40D72C0B.7010308@piuha.net> Date: Thu, 24 Jun 2004 19:19:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: There seems to be a number of different cases here: (a) Two mobile nodes getting a new address at the same time, and then being unable to tell each other where they are. This problem is called the rendevouz problem, and is traditionally solved using home agents (Mobile IPv6) or forwarding agents (Host Identity Protocol). Essentially, solving this problem requires the existence of a stable infrastructure node somewhere. Example: roaming laptop to another roaming laptop, no SGW involved. => this is a well known problem with a well known solution clearly outside the charter. (b) Simultanous changes to addresses such that at least one of the new addresses was known by both peers before the change occurred. The primary problem in case (a) was not knowing the new addresses beforehand. Example 1: two SGWs failover to another path. Example 2: roaming laptop gets a new address at the same time as its SGW's primary interface goes down. => in fact this is the same problem than (a) but in a multi-homing context (in place of a mobility one). (a) solution works of course but a simple policy (just try all the other peer addresses you know) too. So I agree to keep (b) but I'd like to put the requirement over policies, not mechanisms (as soon as they provide the other peer address list of course). Regards Francis.Dupont@enst-bretagne.fr PS: the simple policy is simple to describe but not so simple to use because of the source (i.e., own peer address) selection... _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 13:29:09 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02511 for ; Thu, 24 Jun 2004 13:29:09 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B3467FB50E; Thu, 24 Jun 2004 13:29:09 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DC580FB4F0; Thu, 24 Jun 2004 13:29:08 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 057E9FB4F5; Thu, 24 Jun 2004 13:29:08 -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 98BEBFB4DE for ; Thu, 24 Jun 2004 13:29:06 -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 i5OHSlY12349; Thu, 24 Jun 2004 19:28:47 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OHSlSj039806; Thu, 24 Jun 2004 19:28:47 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241728.i5OHSlSj039806@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: Should MOBIKE react to problems not known locally (#NEW) In-reply-to: Your message of Mon, 21 Jun 2004 18:25:48 +0300. <40D6FDFC.7080507@piuha.net> Date: Thu, 24 Jun 2004 19:28:47 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: Should MOBIKE only react to problems that are known to the nodes locally? For instance, if an interface in a host goes down, or it is assigned a new address, then the node knows about this and can tell its peer. Or should MOBIKE also deal with other problems, typically based on the symptom of not getting packets through? For instance, should MOBIKE attempt to do a failover upon seeing - DPD failure - ICMP error - No response to the MOBIKE protocol messages => of course you mean "No responde to the IKE protocol messages" - No incoming payload packets => first this is a policy issue as we don't want to define an extra problem detection mechanism. Second IMHO this is a generic issue, i.e., this should be handled by generic (in opposion to MOBIKE specific) mobility or multi-homing control mechanisms. BTW we'll share the possible security issues of these mechanisms too. And of course MOBIKE mechanisms and policies have to follow indications from this generic control stuff (i.e., my opinion is yes to everything). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 13:58:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05400 for ; Thu, 24 Jun 2004 13:58:05 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id ED04FFB516; Thu, 24 Jun 2004 13:58:04 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 82486FB4F5; Thu, 24 Jun 2004 13:58:02 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A04BCFB500; Thu, 24 Jun 2004 13:58:01 -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 46E70FB4E2 for ; Thu, 24 Jun 2004 13:58:00 -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 i5OHveY15723; Thu, 24 Jun 2004 19:57:40 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OHvdSj039984; Thu, 24 Jun 2004 19:57:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241757.i5OHvdSj039984@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: When to do return-routability tests (#6) In-reply-to: Your message of Wed, 23 Jun 2004 14:53:11 +0300. <40D96F27.2070800@piuha.net> Date: Thu, 24 Jun 2004 19:57:39 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Paul Hoffman / VPNC X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: However, when we talk our scenario, attackers may gain some amplification for their attack, making it easier to launch a bigger attack with the same fixed amount of resources. => there is a little difference with the DNS reflection example: for the victim the traffic is full IPsec garbage, it cannot get an idea of the reflecting application/service for instance. The issue also has to do with the relationship of the two peers using IKEv2. => I agree: usually this relationship includes some kind of trust. When they are part of the same organization, getting a stream of packets from their SGW would lead you to complain to their administration, and the rogue peer would be shut down. => this is the argument used in MIPv6 to avoid an extra return routability check between a mobile node and its home agent. Of course it should be applied to the nomadic client and its security gateway case too. OTOH, this can only be done after the fact, and assumes that the two peers really have a relationship. (Such relationships might not exist in the case of opportunistic IPsec, for instance, or if you used Verisign as your trust root. Both Mobile IPv6 and HIP have the assumption of no relationship between the parties.) => BTW in HIP at most one party can use an anonymous identity so at least one party uses an authenticated identity, so there should be a beginning of relationship (unfortunately usually not for the moving party :-). As Tero pointed out in another e-mail (and Francis has reported earlier), NAT-T has no protection against such issues. => the summary is with a NAT you have no control over the NAT and no trust in it, and the NAT is the box which changes your address. Basically, an authentic packet with a new address causes the traffic to be moved to that address without verification. If you are satisfied with this, the UDP encapsulation overhead, and possibly weaker support for failover, => this weaker support comes from the NAT behavior, i.e., don't expect that something which is known to not work with a NAT in the path works when you use NAT-T without a NAT in the path. Perhaps we should add AH in this list? you could actually use just NAT-T instead of MOBIKE. => as I wrote this is not a stupid option, and obviously it is compatible with NAT-T in all cases (:-)! Here's some reading material related to the issue: - draft-ietf-mip6-ro-sec-00.txt (Section 3.2) - draft-dupont-mipv6-3bombing-00.txt (all of it) - draft-dupont-transient-pseudonat-03.txt (all of it) - draft-vogt-mipv6-credit-based-authorization-00.txt (Section 3) So, here's some of the options we have: => IMHO this is a pure policy option, i.e., we have a lot of time to solve it. - No tests at all. (Then you might ask whether NAT-T is sufficient.) => IMHO it should be the default policy (rationale: when you don't trust the other party please don't run IKE with it). - Mandatory tests all the time, done before the traffic is moved. Implies one RTT delay. => when you'd like to be paranoid, please be paranoid... - Mandatory tests all the time, done in parallel with the traffic movement. No delay, but some small amount of amplification may still be possible. This approach is similar to draft-vogt-mip6- early-binding-updates-00.txt, which was later abandoned for another scheme. => half-backed solution (I don't like it at all). - Some research-class solution to have no delay and still avoid amplification. See draft-vogt-mip6-credit-based-authorization-00.txt. (But these are complicated schemes and very new technology. Might be against our charter.) => I don't like this too and our charter says MOBIKE is an *IETF* WG. - Tests done prior to moving the traffic stream, but allow the tests to be configured off. => make no sense as the issue is about policy: list possible policies, select some of them, elect one as the default policy. Also, we need to decide what level of protection the tests should provide. It seems that we have the following options: - None, no tests. => this is about mechanism so the first item has no meaning. - A party willing to answer is on the path to the claimed address. This is the basic form of return routability test. => IKEv2 provides more (the origin of the answer is always authenticated). - There is an answer from the tested address, and that answer was authenticated (including the address) to be from our peer. => I don't understand what is "including the address" but this is in some other messages... Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 14:10:40 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07474 for ; Thu, 24 Jun 2004 14:10:39 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 99807FB500; Thu, 24 Jun 2004 14:10:39 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 20BABFB500; Thu, 24 Jun 2004 14:10:37 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id A4AE7FB50E; Thu, 24 Jun 2004 14:10:35 -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 93DD4FB4E2 for ; Thu, 24 Jun 2004 14:10:33 -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 i5OIA3Y17063; Thu, 24 Jun 2004 20:10:03 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OIA3Sj040044; Thu, 24 Jun 2004 20:10:03 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241810.i5OIA3Sj040044@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: jari.arkko@piuha.net Subject: Re: [Mobike] Issue: When to do return-routability tests (#6) In-reply-to: Your message of Thu, 24 Jun 2004 10:10:55 +0300. <40DA7E7F.9070601@piuha.net> Date: Thu, 24 Jun 2004 20:10:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: "Dondeti, Lakshminath" , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > We were considering another option (in early May): That an empty > informational exchange for RR verification might not work and that we > should introduce a nonce for liveness of the test. I still like that > option. => if I understand the issue: the attacking peer doesn't get the RR probe but infers its (empty) content and answers... This is a related issue, but partly different too. I agree that empty informational exchanges are not sufficient for an RR test, and a nonce is needed. Basically, an empty informational exchange just proves that the answer came from the peer, but not that it came from the address we wanted to test. => I disagree with your wording, the issue is not it came from the address we wanted to test, it is the peer really got the probe. I guess you could amend my list above as follows; - There was an authenticated answer from the peer, but it is not guaranteed to be from the tested address or path to it (because the peer can construct a response without seeing the request). => I really prefer this wording. The last option corresponds to making an empty informational exchange. I think the first and the last options are not practical options; its either the second or the third option that we should adopt. => so it will be the third (informational exchanges with nonces, BTW IKEv2 doesn't really constraint the contents of informational messages, so this is compatible/available). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 14:30:34 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10244 for ; Thu, 24 Jun 2004 14:30:33 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 37A03FB516; Thu, 24 Jun 2004 14:30:34 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id C45AAFB50E; Thu, 24 Jun 2004 14:30:33 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 2D232FB514; Thu, 24 Jun 2004 14:30:33 -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 08A02FB500 for ; Thu, 24 Jun 2004 14:30:32 -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 i5OIUMq21689; Thu, 24 Jun 2004 20:30:22 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OIUNSj040281; Thu, 24 Jun 2004 20:30:23 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406241830.i5OIUNSj040281@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) In-reply-to: Your message of Thu, 24 Jun 2004 09:52:34 PDT. <004201c45a0b$a5c6b620$861167c0@adithya> Date: Thu, 24 Jun 2004 20:30:23 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , jari.arkko@piuha.net X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > => I believe that there is a real problem but the problem is partially > outside the scope of MOBIKE. I propose to *not* require the support > of multiple simultaneous outer addresses for IPsec SA without a strong > support from the IPsec WG (as something specific in the 2401bis for > instance). I miss something here. => the key word is "simultaneous" I thought RFC 3554 has the support of the IPsec WG. => I am afraid many members of the IPsec WG didn't understand all consequences of RFC 3554. And if I am wrong (I'd like to be) there is or will be clarification in the 2401bis... All we are saying that this address set can change. And changing addresses is the core of MOBIKE. => to change is not the problem. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 14:54:57 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13123 for ; Thu, 24 Jun 2004 14:54:57 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id B016DFB51B; Thu, 24 Jun 2004 14:54:54 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id B97E3FB500; Thu, 24 Jun 2004 14:54:51 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 4BBF8FB50E; Thu, 24 Jun 2004 14:54:50 -0400 (EDT) Received: from smtp811.mail.sc5.yahoo.com (smtp811.mail.sc5.yahoo.com [66.163.170.81]) by machshav.com (Postfix) with SMTP id DCD66FB4F3 for ; Thu, 24 Jun 2004 14:54:49 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 24 Jun 2004 18:54:49 -0000 Message-ID: <009501c45a1c$bb153590$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" References: <200406241658.i5OGwNSj039556@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] Issue: NAT-T interaction (#3) Date: Thu, 24 Jun 2004 11:54:51 -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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Cc: jari.arkko@piuha.net, Jing Xiang , MOBIKE Mailing List , Paul Hoffman / VPNC , Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 > In your previous mail you wrote: > > So, you are saying that when you move behind NAT (the way you > detect this is by sending address update with your address behind NAT, > RR fails, the peer does not know how to reach you anymore, timeout and > then detect NAT), negotiate a new SA (with NAT-T) ? Is that right ? > > => your scenario is wrong: when you move behind NAT your peer detect > this at the first IKE packet it receives from you and even knows how > to reach you. Then it will close the IKE SA and let you restart from It does not know for sure as the address could have been modified by the attacker. It closes the SA because the address on the IP header is not the same as the one in the mobike payload ? Then, it is just a policy issue. It can even try to do RR to see whether it is reachable or not. To avoid 3rd party bombing attack, you need to be able to communicate the external address in a protected way. > the beginning with hopefully NAT detection and NAT-T support. > > At some point in time, there was a discussion about adding NAT-D payloads > in mobike itself. > > => MOBIKE needs something similar and more which can provide as a side > effect NAT detection. But NAT-D itself is not necessary in MOBIKE > and the IPsec WG decided to forbid direct no-NAT-T to NAT-T transition. > That does not mean we cannot explore a similar thing in this WG :-) MOBIKE is about mobility unlike NAT-T. -mohan > Regards > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 15:09:12 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14548 for ; Thu, 24 Jun 2004 15:09:11 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 248B1FB515; Thu, 24 Jun 2004 15:09:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 64758FB500; Thu, 24 Jun 2004 15:09:11 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 41538FB50E; Thu, 24 Jun 2004 15:09:10 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id BD8D2FB4F3 for ; Thu, 24 Jun 2004 15:09:09 -0400 (EDT) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i5OJ8g7X005029; Thu, 24 Jun 2004 15:08:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200406241830.i5OIUNSj040281@givry.rennes.enst-bretagne.fr> References: <200406241830.i5OIUNSj040281@givry.rennes.enst-bretagne.fr> Date: Thu, 24 Jun 2004 15:08:08 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: jari.arkko@piuha.net, Mohan Parthasarathy , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 At 8:30 PM +0200 6/24/04, Francis Dupont wrote: > In your previous mail you wrote: > > > => I believe that there is a real problem but the problem is partially > > outside the scope of MOBIKE. I propose to *not* require the support > > of multiple simultaneous outer addresses for IPsec SA without a strong > > support from the IPsec WG (as something specific in the 2401bis for > > instance). > > I miss something here. > >=> the key word is "simultaneous" > > I thought RFC 3554 has the support of the IPsec WG. > >=> I am afraid many members of the IPsec WG didn't understand all >consequences of RFC 3554. And if I am wrong (I'd like to be) there >is or will be clarification in the 2401bis... 2401bis already mandates support for selector sets that allow a single SA to refer to a set of IP addresses and ports, which is one of the major requirements for SCTP that was not available under 2401. What else do you feel needs to be covered to enable SCTP to work? Steve _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 18:00:26 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16808 for ; Thu, 24 Jun 2004 18:00:26 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5B6DDFB51B; Thu, 24 Jun 2004 18:00:27 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 28D20FB500; Thu, 24 Jun 2004 18:00:26 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 6AF22FB50E; Thu, 24 Jun 2004 18:00:24 -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 4D6EBFB4F3 for ; Thu, 24 Jun 2004 18:00:23 -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 i5OLxeb14139; Thu, 24 Jun 2004 23:59:40 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OLxdSj041287; Thu, 24 Jun 2004 23:59:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406242159.i5OLxdSj041287@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] Issue: NAT-T interaction (#3) In-reply-to: Your message of Thu, 24 Jun 2004 11:54:51 PDT. <009501c45a1c$bb153590$861167c0@adithya> Date: Thu, 24 Jun 2004 23:59:39 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: jari.arkko@piuha.net, Jing Xiang , MOBIKE Mailing List , Paul Hoffman / VPNC , Tero Kivinen X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > and the IPsec WG decided to forbid direct no-NAT-T to NAT-T transition. > That does not mean we cannot explore a similar thing in this WG :-) MOBIKE is about mobility unlike NAT-T. => I disagree: the difference between NAT-T and MOBIKE is not mobility but multi-homing, i.e., not address change but the reacher support of multiple addresses. Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Thu Jun 24 18:38:05 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22611 for ; Thu, 24 Jun 2004 18:38:04 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 8C52EFB51B; Thu, 24 Jun 2004 18:38:06 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 68094FB4F3; Thu, 24 Jun 2004 18:38:04 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 42137FB500; Thu, 24 Jun 2004 18:38:03 -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 1B7AFFB4DE for ; Thu, 24 Jun 2004 18:38: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 i5OMbmb17014; Fri, 25 Jun 2004 00:37:48 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5OMbmSj041416; Fri, 25 Jun 2004 00:37:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406242237.i5OMbmSj041416@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) In-reply-to: Your message of Thu, 24 Jun 2004 15:08:08 EDT. Date: Fri, 25 Jun 2004 00:37:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: jari.arkko@piuha.net, Mohan Parthasarathy , MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: 2401bis already mandates support for selector sets that allow a single SA to refer to a set of IP addresses and ports, => argh! The term "ports" here disturbs me: we are talking about the support of multiple simultaneous *outer* addresses (not traffic selectors aka inner addresses) in the SADB. which is one of the major requirements for SCTP that was not available under 2401. What else do you feel needs to be covered to enable SCTP to work? => in fact this is not necessary to enable SCTP to work. Thanks Francis.Dupont@enst-bretagne.fr PS: the exact quote from RFC 3554 is: Similarly, SAs may have multiple associated source and destination addresses. Thus an SA is identified by the extended triplet ({set of destination addresses}, SPI, Security Protocol). A lookup in the Security Association Database (SADB) using the triplet (Destination Address, SPI, Security Protocol), where Destination Address is any of the negotiated peer addresses, MUST return the same SA. The text becomes with a "may" so this is not a requirement. The detail (introduce by "thus") is about the inbound processing and: - is fully compatible with the RFC 2401bis (lookup using the couple SPI/protocol) at the exception of "source/destination" terminology (RFC 2401bis reserves these to outer addresses and use "local/remote"). - is easy to implement (just ignore the destination address: if the packet comes up to this piece of code it should have a right one :-). Of course for outbound processing there is a peer address selection issue and things are not simple at all. BTW there is a glitch at the beginning of the section 4.1 of the rfc2401bis I-D 02 and only something about the "tunnel header IP source and destination address" (and the strange verb "purport" ???) in 4.4.2 (SAD). _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Fri Jun 25 16:50:59 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12680 for ; Fri, 25 Jun 2004 16:50:59 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id F2F0AFB524; Fri, 25 Jun 2004 16:50:58 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 9F172FB4D7; Fri, 25 Jun 2004 16:50:56 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 081DAFB4D9; Fri, 25 Jun 2004 16:50:55 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id 39BC8FB452 for ; Fri, 25 Jun 2004 16:50:54 -0400 (EDT) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i5PKoe7X003506; Fri, 25 Jun 2004 16:50:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200406242237.i5OMbmSj041416@givry.rennes.enst-bretagne.fr> References: <200406242237.i5OMbmSj041416@givry.rennes.enst-bretagne.fr> Date: Fri, 25 Jun 2004 14:40:58 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: MOBIKE Mailing List , Mohan Parthasarathy , jari.arkko@piuha.net, kseo@bbn.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0593341597==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com --===============0593341597== Content-Type: multipart/alternative; boundary="============_-1123925849==_ma============" --============_-1123925849==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 12:37 AM +0200 6/25/04, Francis Dupont wrote: > In your previous mail you wrote: > > 2401bis already mandates support for selector sets that allow a > single SA to refer to a set of IP addresses and ports, > >=> argh! The term "ports" here disturbs me: we are talking about >the support of multiple simultaneous *outer* addresses (not >traffic selectors aka inner addresses) in the SADB. You are right; ports are irrelevant in this context. Sorry for the confusion. The SCTP requirement is to map sets of S/D addresses to a single SA via the SPD, which we do. The RFC also calls for mapping traffic from a set of destination addresses to a single SA, via the SAD. This is something that 2401bis accommodates, in the discussion of inbound traffic processing in Section 5.2, step 2, so long as we interpret the phrase "If the packet appears to be IPsec protected and it is addressed to this device" as allowing multiple addresses for the IPsec device. We will add a note to clarify this. Steve --============_-1123925849==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13
At 12:37 AM +0200 6/25/04, Francis Dupont wrote:
 In your previous mail you wrote:

   2401bis already mandates support for selector sets that allow a
   single SA to refer to a set of IP addresses and ports,

=> argh! The term "ports" here disturbs me: we are talking about
the support of multiple simultaneous *outer* addresses (not
traffic selectors aka inner addresses) in the SADB.

You are right; ports are irrelevant in this context.

Sorry for the confusion.

The SCTP requirement is to map sets of S/D addresses to a single SA via the SPD, which we do.  The RFC also calls for mapping traffic from a set of destination addresses to a single SA, via the SAD. This is something that 2401bis accommodates, in the discussion of inbound traffic processing in Section 5.2, step 2, so long as we interpret the phrase  "If the packet appears to be IPsec protected and it is addressed to this device" as allowing multiple addresses for the IPsec device. We will add a note to clarify this.

Steve

--============_-1123925849==_ma============-- --===============0593341597== 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 --===============0593341597==-- From mobike-bounces@machshav.com Sat Jun 26 05:26:17 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29780 for ; Sat, 26 Jun 2004 05:26:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id BD8ABFB515; Sat, 26 Jun 2004 05:26:12 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 13E9DFB521; Sat, 26 Jun 2004 05:26:10 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 52194FB523; Sat, 26 Jun 2004 05:26:07 -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 68AF0FB515 for ; Sat, 26 Jun 2004 05:26:05 -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 i5Q9Prp24801; Sat, 26 Jun 2004 11:25:53 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5Q9PpSj050316; Sat, 26 Jun 2004 11:25:52 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406260925.i5Q9PpSj050316@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) In-reply-to: Your message of Fri, 25 Jun 2004 14:40:58 EDT. Date: Sat, 26 Jun 2004 11:25:51 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: MOBIKE Mailing List , Mohan Parthasarathy , jari.arkko@piuha.net, kseo@bbn.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: The SCTP requirement is to map sets of S/D addresses to a single SA via the SPD, which we do. => this is about inner addresses aka traffic selectors as the SPD knows only them, isn't it? The RFC also calls for mapping traffic from a set of destination addresses to a single SA, via the SAD. This is something that 2401bis accommodates, in the discussion of inbound traffic processing in Section 5.2, step 2, so long as we interpret the phrase "If the packet appears to be IPsec protected and it is addressed to this device" as allowing multiple addresses for the IPsec device. We will add a note to clarify this. => fine, so the inbound case is solved by the introduction of suitable flexibility. But the outbound case is not and IMHO to require the support of multiple simultaneous outer addresses is a bad idea. Of course in an IKE context (as MOBIKE) IPsec SAs come by pairs and we can't ignore the outbound issue... Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 28 10:59:53 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09719 for ; Mon, 28 Jun 2004 10:59:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9E884FB4E5; Mon, 28 Jun 2004 10:59:51 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id DDBCAFB4DC; Mon, 28 Jun 2004 10:59:50 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 444A8FB4DF; Mon, 28 Jun 2004 10:59:49 -0400 (EDT) Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by machshav.com (Postfix) with ESMTP id 2BA99FB4DB for ; Mon, 28 Jun 2004 10:59:44 -0400 (EDT) Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id i5SEx97Z023116; Mon, 28 Jun 2004 10:59:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200406260925.i5Q9PpSj050316@givry.rennes.enst-bretagne.fr> References: <200406260925.i5Q9PpSj050316@givry.rennes.enst-bretagne.fr> Date: Mon, 28 Jun 2004 10:52:45 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Cc: MOBIKE Mailing List , Mohan Parthasarathy , jari.arkko@piuha.net, Stephen Kent , kseo@bbn.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 At 11:25 AM +0200 6/26/04, Francis Dupont wrote: > In your previous mail you wrote: > > The SCTP requirement is to map sets of S/D addresses to a single SA > via the SPD, which we do. > >=> this is about inner addresses aka traffic selectors as the SPD >knows only them, isn't it? yes. > The RFC also calls for mapping traffic > from a set of destination addresses to a single SA, via the SAD. This > is something that 2401bis accommodates, in the discussion of inbound > traffic processing in Section 5.2, step 2, so long as we interpret > the phrase "If the packet appears to be IPsec protected and it is > addressed to this device" as allowing multiple addresses for the > IPsec device. We will add a note to clarify this. > >=> fine, so the inbound case is solved by the introduction of >suitable flexibility. But the outbound case is not and IMHO >to require the support of multiple simultaneous outer addresses >is a bad idea. Of course in an IKE context (as MOBIKE) IPsec SAs >come by pairs and we can't ignore the outbound issue... > Yes, outbound is problematic. 2401/bis is not comprehensive in this regard, anyway. Note that we allude to the problem of finding a security gateway that services a set of hosts, but that we don't say exactly how to solve the problem, since there is not Wg agreement on how to do this. Steve _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 28 13:09:49 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16675 for ; Mon, 28 Jun 2004 13:09:48 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 85F27FB4EB; Mon, 28 Jun 2004 13:09:49 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0155DFB4DF; Mon, 28 Jun 2004 13:09:47 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 0E31CFB4E1; Mon, 28 Jun 2004 13:09:45 -0400 (EDT) Received: from smtp810.mail.sc5.yahoo.com (smtp810.mail.sc5.yahoo.com [66.163.170.80]) by machshav.com (Postfix) with SMTP id 97871FB4DC for ; Mon, 28 Jun 2004 13:09:44 -0400 (EDT) Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@192.103.17.134 with login) by smtp810.mail.sc5.yahoo.com with SMTP; 28 Jun 2004 17:09:43 -0000 Message-ID: <00a501c45d32$b47215a0$861167c0@adithya> From: "Mohan Parthasarathy" To: "Francis Dupont" , "Stephen Kent" References: <200406260925.i5Q9PpSj050316@givry.rennes.enst-bretagne.fr> Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) Date: Mon, 28 Jun 2004 10:09:40 -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.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Cc: jari.arkko@piuha.net, MOBIKE Mailing List , kseo@bbn.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 > In your previous mail you wrote: > > The SCTP requirement is to map sets of S/D addresses to a single SA > via the SPD, which we do. > > => this is about inner addresses aka traffic selectors as the SPD > knows only them, isn't it? > > The RFC also calls for mapping traffic > from a set of destination addresses to a single SA, via the SAD. This > is something that 2401bis accommodates, in the discussion of inbound > traffic processing in Section 5.2, step 2, so long as we interpret > the phrase "If the packet appears to be IPsec protected and it is > addressed to this device" as allowing multiple addresses for the > IPsec device. We will add a note to clarify this. > > => fine, so the inbound case is solved by the introduction of > suitable flexibility. But the outbound case is not and IMHO > to require the support of multiple simultaneous outer addresses > is a bad idea. Of course in an IKE context (as MOBIKE) IPsec SAs > come by pairs and we can't ignore the outbound issue... > RFC 3554 allows you to negotiate a single SA for multiple traffic selectors (See section 3). As SAs come in pairs, it applies to both outbound and inbound SAs. So, what is the problem in supporting multiple outer addresses for outbound SA selection ? Is it an implementation problem ? -thanks mohan > Thanks > > Francis.Dupont@enst-bretagne.fr > _______________________________________________ > Mobike mailing list > Mobike@machshav.com > https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 28 15:27:52 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25279 for ; Mon, 28 Jun 2004 15:27:52 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 17282FB4DF; Mon, 28 Jun 2004 15:27:51 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 289C5FB4DF; Mon, 28 Jun 2004 15:27:49 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id D7CF7FB4E1; Mon, 28 Jun 2004 15:27:46 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by machshav.com (Postfix) with ESMTP id EF4F5FB4DA for ; Mon, 28 Jun 2004 15:27:45 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25276; Mon, 28 Jun 2004 15:27:42 -0400 (EDT) Message-Id: <200406281927.PAA25276@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 28 Jun 2004 15:27:42 -0400 Cc: mobike@machshav.com Subject: [Mobike] I-D ACTION:draft-ietf-mobike-design-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Filename : draft-ietf-mobike-design-00.txt Pages : 23 Date : 2004-6-28 This document discusses the potential design decisions in the base MOBIKE (IKEv2 Mobility and Multihoming) protocol. It also tries to provide some background information about different choices and tries to record the decisions made by the working group, so that we do not need to repeat discussion later. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mobike-design-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-mobike-design-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-mobike-design-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-6-28151044.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-mobike-design-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-mobike-design-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-6-28151044.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 Jun 28 17:06:02 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05689 for ; Mon, 28 Jun 2004 17:06:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 798A9FB4EA; Mon, 28 Jun 2004 17:06:03 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 93B3CFB4DC; Mon, 28 Jun 2004 17:06:02 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 73FBAFB4DF; Mon, 28 Jun 2004 17:06:01 -0400 (EDT) Received: from above.proper.com (above.proper.com [208.184.76.39]) by machshav.com (Postfix) with ESMTP id DB131FB4DA for ; Mon, 28 Jun 2004 17:06:00 -0400 (EDT) Received: from [10.20.30.249] (dsl2-63-249-109-252.cruzio.com [63.249.109.252]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id i5SL5sjD012398 for ; Mon, 28 Jun 2004 14:05:55 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: Date: Mon, 28 Jun 2004 14:05:57 -0700 To: mobike@machshav.com From: Paul Hoffman / VPNC Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [Mobike] Discussion of draft-ietf-mobike-design-00.txt X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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. Tero has posted the first draft of the WG's design document. As you can see, there is a lot in there. Instead of replying to the posting announcement, please start a new topic thread for each topic you wish to discuss: this will greatly help us know what is being said. Thanks! --Paul Hoffman, Director --VPN Consortium _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Mon Jun 28 17:41:55 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10358 for ; Mon, 28 Jun 2004 17:41:55 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 77886FB4DC; Mon, 28 Jun 2004 17:41:55 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 656ABFB4DC; Mon, 28 Jun 2004 17:41:54 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 59F8CFB4DF; Mon, 28 Jun 2004 17:41:53 -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 588D6FB4DA for ; Mon, 28 Jun 2004 17:41:52 -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 i5SLfUU05589; Mon, 28 Jun 2004 23:41:30 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i5SLfTSj059270; Mon, 28 Jun 2004 23:41:29 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200406282141.i5SLfTSj059270@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Mohan Parthasarathy" Subject: Re: [Mobike] Issue: Support for IPv4 - IPv6 movements (#13) In-reply-to: Your message of Mon, 28 Jun 2004 10:09:40 PDT. <00a501c45d32$b47215a0$861167c0@adithya> Date: Mon, 28 Jun 2004 23:41:29 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Cc: jari.arkko@piuha.net, MOBIKE Mailing List , Stephen Kent , kseo@bbn.com X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: So, what is the problem in supporting multiple outer addresses for outbound SA selection ? Is it an implementation problem ? => yes, it is an implementation problem: IMHO we should be carefull and do *not* open this can of worms. 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 Tue Jun 29 17:03:18 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20389 for ; Tue, 29 Jun 2004 17:03:17 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 3F48CFB4E0; Tue, 29 Jun 2004 17:03:16 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 0B575FB4D9; Tue, 29 Jun 2004 17:03:15 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id E5252FB4DA; Tue, 29 Jun 2004 17:03:12 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by machshav.com (Postfix) with ESMTP id 4F7AAFB4D8 for ; Tue, 29 Jun 2004 17:03:12 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5TL31b18968; Tue, 29 Jun 2004 17:03:01 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id ; Tue, 29 Jun 2004 17:03:00 -0400 Message-ID: <6204FDDE129D364D8040A98BCCB290EF0EA17D62@zbl6c004.corpeast.baynetworks.com> From: "Jing Xiang" To: Tero Kivinen , MOBIKE Mailing List Subject: RE: [Mobike] Issue: NAT-T interaction (#3) Date: Tue, 29 Jun 2004 17:03:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1418739044==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1418739044== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45E1C.75B51B38" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45E1C.75B51B38 Content-Type: text/plain; charset="ISO-8859-1" Tero, I don't see why we have to make MOBIKE & NAT-T mutually exclusive. e.g. In your just updated draft-ietf-mobike-design-00.txt, it says: "If NAT is detected in the IKE SA creation, that should automatically disable the MOBIKE extensions and use NAT-T." However, currently NAT-T does not provide mechanism for signalling address change. Does that mean we limit MOBIKE to non-NAT environment? If a connection is established using NAT-T, doesn't IKEv2 already specify that "Any authenticated IKE packet or any authenticated UDP encapsulated ESP packet can be used to detect that the IP address or the port has changed."? Since ADDRESS_UPDATE message is authenticated why it can't be used for roaming from NAT cases? Best Regards! /Jing ------_=_NextPart_001_01C45E1C.75B51B38 Content-Type: text/html; charset="ISO-8859-1" RE: [Mobike] Issue: NAT-T interaction (#3)

Tero,
I don't see why we have to make MOBIKE & NAT-T mutually exclusive. e.g.
In your just updated draft-ietf-mobike-design-00.txt, it says:

"If NAT is detected in the IKE SA creation, that should automatically
   disable the MOBIKE extensions and use NAT-T."

However, currently NAT-T does not provide mechanism for signalling address
change. Does that mean we limit MOBIKE to non-NAT environment? If a connection
is established using NAT-T, doesn't IKEv2 already specify that
"Any authenticated IKE packet or any authenticated UDP encapsulated ESP packet can be
used to detect that the IP address or the port has changed."? Since ADDRESS_UPDATE
message is authenticated why it can't be used for roaming from NAT cases?

Best Regards!
/Jing

------_=_NextPart_001_01C45E1C.75B51B38-- --===============1418739044== 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 --===============1418739044==-- From mobike-bounces@machshav.com Wed Jun 30 04:42:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02536 for ; Wed, 30 Jun 2004 04:42:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 9AE83FB4E0; Wed, 30 Jun 2004 04:42:00 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id A5C78FB4D9; Wed, 30 Jun 2004 04:41:58 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 103E6FB4DA; Wed, 30 Jun 2004 04:41:56 -0400 (EDT) Received: from mail.kivinen.iki.fi (unknown [83.145.195.1]) by machshav.com (Postfix) with ESMTP id 4C7A9FB4D8 for ; Wed, 30 Jun 2004 04:41:54 -0400 (EDT) Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.10/8.12.10) with ESMTP id i5U8fpYu012900 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 30 Jun 2004 11:41:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.10/8.12.6/Submit) id i5U8foTh012897; Wed, 30 Jun 2004 11:41:50 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16610.31950.604146.309957@fireball.kivinen.iki.fi> Date: Wed, 30 Jun 2004 11:41:50 +0300 From: Tero Kivinen To: "Jing Xiang" Subject: RE: [Mobike] Issue: NAT-T interaction (#3) In-Reply-To: <6204FDDE129D364D8040A98BCCB290EF0EA17D62@zbl6c004.corpeast.baynetworks.com> References: <6204FDDE129D364D8040A98BCCB290EF0EA17D62@zbl6c004.corpeast.baynetworks.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 10 min X-Total-Time: 10 min Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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 Jing Xiang writes: > I don't see why we have to make MOBIKE & NAT-T mutually exclusive. e.g. > In your just updated draft-ietf-mobike-design-00.txt, it says: > > "If NAT is detected in the IKE SA creation, that should automatically > disable the MOBIKE extensions and use NAT-T." > > However, currently NAT-T does not provide mechanism for signalling address > change. Actually it does. It automatically changes the address whenever it changes. There is no authentication on the change, but it is there. > Does that mean we limit MOBIKE to non-NAT environment? If we want to completely protect agains the 3rd party bombing, we have not other choise. We cannot really reliably authenticate some attackers (NATs) and not authenticate others (real attackers). If we do not care about 3rd party bombing then we can use NAT-T all the time, only thing MOBIKE in that case offers is the multihoming. > If a connection is established using NAT-T, doesn't IKEv2 already > specify that "Any authenticated IKE packet or any authenticated UDP > encapsulated ESP packet can be used to detect that the IP address or > the port has changed."? Since ADDRESS_UPDATE message is > authenticated why it can't be used for roaming from NAT cases? Because the ADDRESS_UPDATE packet specifically FAILS the authentication. The ADDRESS_UPDATE packet contains the IP numbers, and those IP numbers DO NOT match the outer IP-address of the packet, thus it fails. The NAT-T takes address updates from the outer IP-address, in the MOBIKE we take it from inside the packet. The NAT can modify the outer IP-addresses, and there is no way for us to authenticate those changes (unless we change NATs), but NAT cannot modify the IP-address inside the IKE packets, thus the checks for them will fail. We can make transition from NAT-T to MOBIKE and vice versa to work somehow, and we can probably even extend the NAT-T to support multihoming for the IP-addresses not behind the NAT. If we want to complete protection against 3rd party bombing, then we cannot add NAT-T support to MOBIKE (they will be separate protocols). I do not see why we have to combine NAT-T and MOBIKE, I think it is better to keep them separate and make the transtions from one to another work. It is simplier and also offers clear point for the policy decision. These are of course only my own opininons, I know there are people who think otherwise, and I can modify the NAT-T section in the design draft if given actual text. It is very hard for me to try to write something from that point of view, so it would be better to get also some text from someone else... -- kivinen@safenet-inc.com _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 30 06:33:44 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06780 for ; Wed, 30 Jun 2004 06:33:43 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 29F93FB4F1; Wed, 30 Jun 2004 06:33:45 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 95542FB4D9; Wed, 30 Jun 2004 06:33:42 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 1ECE9FB4DA; Wed, 30 Jun 2004 06:33:41 -0400 (EDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by machshav.com (Postfix) with ESMTP id CDB79FB4D8 for ; Wed, 30 Jun 2004 06:33:39 -0400 (EDT) Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5UAXXN00706; Wed, 30 Jun 2004 13:33:33 +0300 (EET DST) X-Scanned: Wed, 30 Jun 2004 13:32:26 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i5UAWQsj031097; Wed, 30 Jun 2004 13:32:26 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00TTXw4i; Wed, 30 Jun 2004 13:32:24 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i5UAWNH26982; Wed, 30 Jun 2004 13:32:23 +0300 (EET DST) Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 30 Jun 2004 13:32:17 +0300 x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 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: NAT-T interaction (#3) Date: Wed, 30 Jun 2004 13:32:16 +0300 Message-ID: <052E0C61B69C3741AFA5FE88ACC775A60227C120@esebe023.ntc.nokia.com> Thread-Topic: [Mobike] Issue: NAT-T interaction (#3) Thread-Index: AcRefkecV/y5RXqdTeWuciZ81rWV7wADBJcw From: To: , X-OriginalArrivalTime: 30 Jun 2004 10:32:17.0396 (UTC) FILETIME=[8429FB40:01C45E8D] X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 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: > > If a connection is established using NAT-T, doesn't IKEv2 already > > specify that "Any authenticated IKE packet or any authenticated UDP > > encapsulated ESP packet can be used to detect that the IP address or > > the port has changed."? Since ADDRESS_UPDATE message is > > authenticated why it can't be used for roaming from NAT cases? >=20 > Because the ADDRESS_UPDATE packet specifically FAILS the > authentication. The ADDRESS_UPDATE packet contains the IP numbers, and > those IP numbers DO NOT match the outer IP-address of the packet, > thus it fails. The NAT-T takes address updates from the outer > IP-address, in the MOBIKE we take it from inside the packet.=20 Note that we have not yet decided (as far as I have understood)=20 that the ADDRESS_UPDATE packet will even contain the IP number (I know it does in your proposal). And even if it does, we have=20 not decided what happens if it does not match the outer IP address.. > We can make transition from NAT-T to MOBIKE and vice versa to work > somehow, and we can probably even extend the NAT-T to support > multihoming for the IP-addresses not behind the NAT. If we want to > complete protection against 3rd party bombing, then we cannot add > NAT-T support to MOBIKE (they will be separate protocols). > > I do not see why we have to combine NAT-T and MOBIKE, I think it is > better to keep them separate and make the transtions from one to > another work. It is simplier and also offers clear point for the > policy decision. I'm still a bit confused by what you mean by "transitions from=20 one to another" and keeping them separate.=20 If you can do this transition without creating a new IKEv2 SA,=20 then it implies that MOBIKE and NAT-T will not be 100% separate,=20 since some IKEv2 message added by MOBIKE will modify state used=20 by NAT-T.=20 Or do you perhaps mean that the initiator has to decide before opening an IKEv2 SA which will be used? Or decide after the first two messages? (This would IMHO be a totally unnecessary=20 restriction.) Best regards, Pasi _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike From mobike-bounces@machshav.com Wed Jun 30 10:42:01 2004 Received: from machshav.com (machshav.com [147.28.0.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21309 for ; Wed, 30 Jun 2004 10:42:01 -0400 (EDT) Received: by machshav.com (Postfix, from userid 512) id 5BD73FB4F1; Wed, 30 Jun 2004 10:42:01 -0400 (EDT) Received: from machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 13534FB4DA; Wed, 30 Jun 2004 10:41:56 -0400 (EDT) Delivered-To: mobike@machshav.com Received: by machshav.com (Postfix, from userid 512) id 7E301FB4DF; Wed, 30 Jun 2004 10:41:54 -0400 (EDT) Received: from zcars04f.nortelnetworks.com (zcars04f.nortelnetworks.com [47.129.242.57]) by machshav.com (Postfix) with ESMTP id 7DCBDFB4D9 for ; Wed, 30 Jun 2004 10:41:53 -0400 (EDT) Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i5UEfc008441; Wed, 30 Jun 2004 10:41:39 -0400 (EDT) Received: by zbl6c012.corpeast.baynetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 30 Jun 2004 10:41:37 -0400 Message-ID: <6204FDDE129D364D8040A98BCCB290EF0EA77249@zbl6c004.corpeast.baynetworks.com> From: "Jing Xiang" To: Tero Kivinen Subject: RE: [Mobike] Issue: NAT-T interaction (#3) Date: Wed, 30 Jun 2004 10:37:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Cc: MOBIKE Mailing List X-BeenThere: mobike@machshav.com X-Mailman-Version: 2.1.4 Precedence: list List-Id: Mobile/Multihoming IKEv2 IETF list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0412401990==" Sender: mobike-bounces@machshav.com Errors-To: mobike-bounces@machshav.com This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0412401990== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C45EAF.CAB8DE9C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C45EAF.CAB8DE9C Content-Type: text/plain; charset="ISO-8859-1" Tero, You are right NAT-T automatically changes the address when it receives an authenticated IKE or ESP packet. With authenticated I thought it means the hash payload(for IKE) & the HMAC(for ESP) check is ok. I don't think it includes address in the payload matches the outer address. So MOBIKE should do the same thing. The address in the ADDRESS_UPDATE payload mismatches outer ip address is an indication of NAT or an attack. I think it should depends on policy one way or the other. Besides, if NAT-T is on, maybe we shouldn't even include address in ADDRESS_UPDATE payload for some cases. Rather than changing the NAT-T section, I would rather us make MOBIKE work in NAT-T cases Best Regards! /Jing -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Wednesday, June 30, 2004 4:42 AM To: Xiang, Jing [BL60:437:EXCH] Cc: MOBIKE Mailing List Subject: RE: [Mobike] Issue: NAT-T interaction (#3) Jing Xiang writes: > I don't see why we have to make MOBIKE & NAT-T mutually exclusive. e.g. > In your just updated draft-ietf-mobike-design-00.txt, it says: > > "If NAT is detected in the IKE SA creation, that should automatically > disable the MOBIKE extensions and use NAT-T." > > However, currently NAT-T does not provide mechanism for signalling address > change. Actually it does. It automatically changes the address whenever it changes. There is no authentication on the change, but it is there. > Does that mean we limit MOBIKE to non-NAT environment? If we want to completely protect agains the 3rd party bombing, we have not other choise. We cannot really reliably authenticate some attackers (NATs) and not authenticate others (real attackers). If we do not care about 3rd party bombing then we can use NAT-T all the time, only thing MOBIKE in that case offers is the multihoming. > If a connection is established using NAT-T, doesn't IKEv2 already > specify that "Any authenticated IKE packet or any authenticated UDP > encapsulated ESP packet can be used to detect that the IP address or > the port has changed."? Since ADDRESS_UPDATE message is > authenticated why it can't be used for roaming from NAT cases? Because the ADDRESS_UPDATE packet specifically FAILS the authentication. The ADDRESS_UPDATE packet contains the IP numbers, and those IP numbers DO NOT match the outer IP-address of the packet, thus it fails. The NAT-T takes address updates from the outer IP-address, in the MOBIKE we take it from inside the packet. The NAT can modify the outer IP-addresses, and there is no way for us to authenticate those changes (unless we change NATs), but NAT cannot modify the IP-address inside the IKE packets, thus the checks for them will fail. We can make transition from NAT-T to MOBIKE and vice versa to work somehow, and we can probably even extend the NAT-T to support multihoming for the IP-addresses not behind the NAT. If we want to complete protection against 3rd party bombing, then we cannot add NAT-T support to MOBIKE (they will be separate protocols). I do not see why we have to combine NAT-T and MOBIKE, I think it is better to keep them separate and make the transtions from one to another work. It is simplier and also offers clear point for the policy decision. These are of course only my own opininons, I know there are people who think otherwise, and I can modify the NAT-T section in the design draft if given actual text. It is very hard for me to try to write something from that point of view, so it would be better to get also some text from someone else... -- kivinen@safenet-inc.com ------_=_NextPart_001_01C45EAF.CAB8DE9C Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Mobike] Issue: NAT-T interaction (#3)

Tero,

You are right NAT-T automatically changes the address = when it receives an authenticated
IKE or ESP packet. With authenticated I thought it = means the hash payload(for IKE) & the  HMAC(for ESP) check is = ok. I don't think it includes address in the payload matches the = outer

address. So MOBIKE should do the same thing. The = address in the ADDRESS_UPDATE
payload mismatches outer ip address is an indication = of NAT or an attack. I think it
should depends on policy one way or the other. = Besides, if NAT-T is on, maybe we shouldn't even include address in = ADDRESS_UPDATE payload for some cases.

Rather than changing the NAT-T section, I would = rather us make MOBIKE work in NAT-T cases

Best Regards!
/Jing


-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Wednesday, June 30, 2004 4:42 AM
To: Xiang, Jing [BL60:437:EXCH]
Cc: MOBIKE Mailing List
Subject: RE: [Mobike] Issue: NAT-T interaction = (#3)


Jing Xiang writes:
> I don't see why we have to make MOBIKE & = NAT-T mutually exclusive. e.g.
> In your just updated = draft-ietf-mobike-design-00.txt, it says:
>
> "If NAT is detected in the IKE SA = creation, that should automatically
>    disable the MOBIKE extensions = and use NAT-T."
>
> However, currently NAT-T does not provide = mechanism for signalling address
> change.

Actually it does. It automatically changes the = address whenever it
changes. There is no authentication on the change, = but it is there.

> Does that mean we limit MOBIKE to non-NAT = environment?

If we want to completely protect agains the 3rd party = bombing, we have
not other choise. We cannot really reliably = authenticate some
attackers (NATs) and not authenticate others (real = attackers).

If we do not care about 3rd party bombing then we can = use NAT-T all
the time, only thing MOBIKE in that case offers is = the multihoming.

> If a connection is established using NAT-T, = doesn't IKEv2 already
> specify that "Any authenticated IKE packet = or any authenticated UDP
> encapsulated ESP packet can be used to detect = that the IP address or
> the port has changed."? Since = ADDRESS_UPDATE message is
> authenticated why it can't be used for roaming = from NAT cases?

Because the ADDRESS_UPDATE packet specifically FAILS = the
authentication. The ADDRESS_UPDATE packet contains = the IP numbers, and
those IP numbers DO NOT match the outer IP-address = of the packet,
thus it fails. The NAT-T takes address updates from = the outer
IP-address, in the MOBIKE we take it from inside the = packet. The NAT
can modify the outer IP-addresses, and there is no = way for us to
authenticate those changes (unless we change NATs), = but NAT cannot
modify the IP-address inside the IKE packets, thus = the checks for them
will fail.

We can make transition from NAT-T to MOBIKE and vice = versa to work
somehow, and we can probably even extend the NAT-T = to support
multihoming for the IP-addresses not behind the NAT. = If we want to
complete protection against 3rd party bombing, then = we cannot add
NAT-T support to MOBIKE (they will be separate = protocols).

I do not see why we have to combine NAT-T and MOBIKE, = I think it is
better to keep them separate and make the transtions = from one to
another work. It is simplier and also offers clear = point for the
policy decision.

These are of course only my own opininons, I know = there are people who
think otherwise, and I can modify the NAT-T section = in the design
draft if given actual text. It is very hard for me = to try to write
something from that point of view, so it would be = better to get also
some text from someone else...
--
kivinen@safenet-inc.com

------_=_NextPart_001_01C45EAF.CAB8DE9C-- --===============0412401990== 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 --===============0412401990==--